This is a continuation of the thread here.
Recent Recap
A lot has transpired since that thread reached its conclusion - an owner in China was able to reset the thermal timer and bypass the cooling-off period by removing the clock battery. A few weeks prior to that I had proposed an experiment to do the same by inhibiting the camera's ability to save its thermal management to NVRAM by removing the main battery. I repeated proposed the same experiment here with more details. Once word of the China clock-battery spread (thanks to EOSHD) I was finally able to get a volunteer for the main-battery experiment, which was successfully performed by J Marus ,then later by Matt Granger, Electroholic Anonymous, and Andrew Reid, the latter two of which demonstrated recording 8K for 50 minutes over multiple battery-removal sessions without any special cooling/fridge tests.
I'm going to keep this thread focused on the technical investigation and not spend too much on theories centered around marketing/segmentation/crippling. Those are well handled in other forums such as EOSHD and YouTube.
New Revelations - workaround for corrupt video file
While the hack was important in revealing new details about Canon's thermal management it's not meant to serve as an actual workaround since it requires pulling the battery while the video is still be recording (otherwise the camera saves the thermal state to NVRAM when the user stops a recording). This renders the video unplayable/unusable. Instead of a fully-formed .MP4 file the technique leaves a .DAT file, which represents the mdat atom of the video file (video+audio frames) but is missing all the MP4 container metadata to play or use the fie.
While working on tools to reconstruct the missing MP4 container metadata, an EOSHD forum poster the name of J- proposed a brilliant workaround to use FAT32-formatted cards, which would force the camera to split up a continuous recording into 4GB splits (due to FAT32's 4GB per-file limitation). It wasn't clear if this technique would avoid the NRAM-saving that's seen when stopping a recording. After experimenting on my Canon RP I found it does avoid the NVRAM when writing the 4GB splits, and more importantly, it was later verified on a R5 by Electroholic Anonymous here.
So far this FAT32 trick only works on SD cards - neither Electroholic Anonymous or Hoka Key have been able to get the camera to accept a FAT32-formatted CFE card. Normally the camera will only format cards <= 32GB as FAT32, using exFAT for larger capacity cards. This limitation has been worked around by formatting the cards under Linux - Windows 10 wont let your format cards > 32GB as FAT32 (but will mount them) and the camera wont accept FAT32 cards formatted under OSX. More details here.
So there is now a plausible workaround that includes saving the entire recorded video sans the last 4GB lost after a battery pull (which is only about 45 seconds for an 8K video).
Recent Recap
A lot has transpired since that thread reached its conclusion - an owner in China was able to reset the thermal timer and bypass the cooling-off period by removing the clock battery. A few weeks prior to that I had proposed an experiment to do the same by inhibiting the camera's ability to save its thermal management to NVRAM by removing the main battery. I repeated proposed the same experiment here with more details. Once word of the China clock-battery spread (thanks to EOSHD) I was finally able to get a volunteer for the main-battery experiment, which was successfully performed by J Marus ,then later by Matt Granger, Electroholic Anonymous, and Andrew Reid, the latter two of which demonstrated recording 8K for 50 minutes over multiple battery-removal sessions without any special cooling/fridge tests.
I'm going to keep this thread focused on the technical investigation and not spend too much on theories centered around marketing/segmentation/crippling. Those are well handled in other forums such as EOSHD and YouTube.
New Revelations - workaround for corrupt video file
While the hack was important in revealing new details about Canon's thermal management it's not meant to serve as an actual workaround since it requires pulling the battery while the video is still be recording (otherwise the camera saves the thermal state to NVRAM when the user stops a recording). This renders the video unplayable/unusable. Instead of a fully-formed .MP4 file the technique leaves a .DAT file, which represents the mdat atom of the video file (video+audio frames) but is missing all the MP4 container metadata to play or use the fie.
While working on tools to reconstruct the missing MP4 container metadata, an EOSHD forum poster the name of J- proposed a brilliant workaround to use FAT32-formatted cards, which would force the camera to split up a continuous recording into 4GB splits (due to FAT32's 4GB per-file limitation). It wasn't clear if this technique would avoid the NRAM-saving that's seen when stopping a recording. After experimenting on my Canon RP I found it does avoid the NVRAM when writing the 4GB splits, and more importantly, it was later verified on a R5 by Electroholic Anonymous here.
So far this FAT32 trick only works on SD cards - neither Electroholic Anonymous or Hoka Key have been able to get the camera to accept a FAT32-formatted CFE card. Normally the camera will only format cards <= 32GB as FAT32, using exFAT for larger capacity cards. This limitation has been worked around by formatting the cards under Linux - Windows 10 wont let your format cards > 32GB as FAT32 (but will mount them) and the camera wont accept FAT32 cards formatted under OSX. More details here.
So there is now a plausible workaround that includes saving the entire recorded video sans the last 4GB lost after a battery pull (which is only about 45 seconds for an 8K video).