docmoore

Merry Christmas vignette from the R5 ....
https://youtu.be/3vYaZpx4lOk
Best wishes for a wonderful holiday and a better New Year ....

Merry Christmas vignette from the R5 ....
https://youtu.be/3vYaZpx4lOk
Best wishes for a wonderful holiday and a better New Year ....

gorgeous footage and truly a voice that needs to be heard.
Not the homogenized drivel that seems to be the standard music fare these days ...
Reminiscent of Sean Rowe ... better sense of timing and swing.
Canon CPS has had my 1DX III for a month ... and are struggling to admit a problem with my specific camera ...
So looking at a replacement ...

Hey all - I've been using the R5 extensively on a variety of shoots the past couple of months and have absolutely loved it. The AF is spot-on, the HQ 4k modes are gorgeous, the user experience is amazing, the 120fps is the best I've used outside of the C300 III.
So far, I have had zero overheating issues. The timer in 4k HQ has gone down from 25-minutes to 20-minutes a couple of times, but have never had any issues. 
Just released last night is a music video I directed, shot, and edited. Outside of some tripod shots, I'd say 90% of the shoot was shot on the R5. Youtube compression sucks so there seems to be some artifacts, but they aren't present in the 4k ProRes export.
Enjoy!
 

Point taken ... I do not use variables ... buy a set of decent NDs and meter the scene ...
If your ND adds a shift to green ... throw it away ... get one with hard stops and decent color.
 

Just watched the Pro-AV stream ... where one of the contributors uses a C200 (couple of them) and transitioned to the C300 MK III. He is a
professional "colourist" hired to correct others video.
https://www.imdb.com/name/nm8304151/
His take is that the picture out of the DGO sensor in XF_AVC All I is preferable to the Raw out of the C200. The DR of the sensor, low noise and color
obviates the need for RAW ... and with the new Canon Speed Booster the lack of FF may be a non-issue. So the best sensor in his mind
is the one in the C70 ...
I have begun a conversation with my dealer about dropping the 1 DX III for the C 70 ... and I have all MF glass. Canon have not addressed a flaw
in their Raw acquisition ... still getting corrupted frames in the lowest frame rate with their favored CFExpress cards ... great color workflow and
resolution but chasing bad frames adds 3X the time a normal render ...

Just watched the Pro-AV stream ... where one of the contributors uses a C200 (couple of them) and transitioned to the C300 MK III. He is a
professional "colourist" hired to correct others video.
https://www.imdb.com/name/nm8304151/
His take is that the picture out of the DGO sensor in XF_AVC All I is preferable to the Raw out of the C200. The DR of the sensor, low noise and color
obviates the need for RAW ... and with the new Canon Speed Booster the lack of FF may be a non-issue. So the best sensor in his mind
is the one in the C70 ...
I have begun a conversation with my dealer about dropping the 1 DX III for the C 70 ... and I have all MF glass. Canon have not addressed a flaw
in their Raw acquisition ... still getting corrupted frames in the lowest frame rate with their favored CFExpress cards ... great color workflow and
resolution but chasing bad frames adds 3X the time a normal render ...

Just watched the Pro-AV stream ... where one of the contributors uses a C200 (couple of them) and transitioned to the C300 MK III. He is a
professional "colourist" hired to correct others video.
https://www.imdb.com/name/nm8304151/
His take is that the picture out of the DGO sensor in XF_AVC All I is preferable to the Raw out of the C200. The DR of the sensor, low noise and color
obviates the need for RAW ... and with the new Canon Speed Booster the lack of FF may be a non-issue. So the best sensor in his mind
is the one in the C70 ...
I have begun a conversation with my dealer about dropping the 1 DX III for the C 70 ... and I have all MF glass. Canon have not addressed a flaw
in their Raw acquisition ... still getting corrupted frames in the lowest frame rate with their favored CFExpress cards ... great color workflow and
resolution but chasing bad frames adds 3X the time a normal render ...

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:

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.

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

Made a lot of progress on understanding the .DAT files. Using my Canon RP as a test bed, I recorded two 1:00 videos, one regularly and the other power-interrupted. I then copied the entire SD card for each case as a file image to my system for analysis. Prior to recording video each SD was prepared by fully wiping it with dd, then formatting in the camera. I also went back to FAT32 because it's easier to analyze those structures than exFAT.
This yields two very similar filesystem images. For the regularly-recorded video SD image I see a single data file (MVI_0478.MP4 in this specific case). However if I analyze the directory entries in the FAT32 structure I see a second file that's been deleted, named ?VI_047.DAT. The '?' is there because the file has been deleted (0xE5 is the FAT32 marker to indicate a deleted directory entry), meaning its original name is MVI_0478.DAT. Even though MVI_0478.DAT has been deleted its FAT32 cluster location and most-recent file size is still available in the directory entry.
Looking at the contents of the .DAT I see an "mdat" field. This is the raw MP4 data holding the video/data of the video - it's called an "mdat atom" in MP4 container parlance. The size of the .DAT file is exactly 128KB less than the size of the .MP4. What's more, the on-SD location of the .DAT is exactly 128KB after the .MP4, which means the two files are actually contiguous with each other.
So the camera wrote the .DAT first (while recording the video) but left 128KB before it pre-allocated in the FAT32 cluster table. When the video recording stopped it then wrote the 128KB before the .DAT, which contains all the other MP4 atoms necessary to represent the file, including the 'moov atom' which was reported missing when trying to recover the .DAT as .MP4 earlier using open-source recovery tools (failed because it's missing the full 128KB .MP4 header).
The 128KB MP4 container header stuff + mdat atom content represents the full MP4 file.
So the .DAT files we're seeing for the interrupted recordings on the R5 are the actual raw video/audio data sans the proper 128KB MP4 header area.
On my Canon RP the .DAT directory entry is missing for the interrupt recording. However if I go to the location on the interrupted-SD image as where the .DAT file exists on the good-SD image I see the mdat data. So it appears that on my RP the camera writes to this area during recording without first setting the directory entry to reflect that area is allocated. If you're able to see the .DAT files from your 1DX that means the behavior of that camera is different. Not sure how the R5 acts. Either way, recovering the .DAT file for my RP is trivial because I know what cluster it begins on by comparing it to the good-SD image.
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

Thanks for the files. Tried two separate automated MP4 repair programs/scripts, both of which support reading the headers/metdata from the "good" file and attempt to graft that data over those missing elements in the bad file, specifically the missing moov atom in the corrupt file. No joy so far. Oddly when I examine the "good" file the moov atom is actually at the beginning of the file - I expected it to be at the end since that's what's missing from the corrupt file. It might be that Canon relocates the moov atom to the front after a successful recording end. It's usually placed at the beginning of files to facilitate better streaming as the file is being downloaded. Or it might be that IsoBuster didn't recover the file correctly. I'll keep digging.
Here's the Atom data from the good file, obtained from AtomicParsley <filename> -T
Atom ftyp @ 0 of size: 28, ends @ 28
Atom moov @ 28 of size: 262116, ends @ 262144
     Atom uuid=85c0b687-820f-11e0-8111-f4ce462b6a48 @ 36 of size: 65750, ends @ 65786
     Atom udta @ 65786 of size: 2056, ends @ 67842
         Atom manu @ 65794 of size: 20, ends @ 65814                     ~
         Atom modl @ 65814 of size: 38, ends @ 65852                     ~
         Atom urat @ 65852 of size: 16, ends @ 65868                     ~
         Atom free @ 65868 of size: 1974, ends @ 67842
     Atom mvhd @ 67842 of size: 108, ends @ 67950
     Atom trak @ 67950 of size: 16328, ends @ 84278
         Atom tkhd @ 67958 of size: 92, ends @ 68050
         Atom edts @ 68050 of size: 36, ends @ 68086
             Atom elst @ 68058 of size: 28, ends @ 68086
         Atom mdia @ 68086 of size: 16192, ends @ 84278
             Atom mdhd @ 68094 of size: 32, ends @ 68126
             Atom hdlr @ 68126 of size: 33, ends @ 68159
             Atom minf @ 68159 of size: 16119, ends @ 84278
                 Atom vmhd @ 68167 of size: 20, ends @ 68187
                 Atom dinf @ 68187 of size: 36, ends @ 68223
                     Atom dref @ 68195 of size: 28, ends @ 68223
                 Atom stbl @ 68223 of size: 16055, ends @ 84278
                     Atom stsd @ 68231 of size: 311, ends @ 68542
                         Atom hvc1 @ 68247 of size: 295, ends @ 68542             ~
                     Atom stts @ 68542 of size: 24, ends @ 68566
                     Atom stss @ 68566 of size: 296, ends @ 68862
                     Atom ctts @ 68862 of size: 4472, ends @ 73334
                     Atom stsc @ 73334 of size: 28, ends @ 73362
                     Atom stsz @ 73362 of size: 3364, ends @ 76726
                     Atom co64 @ 76726 of size: 6704, ends @ 83430
                     Atom sdtp @ 83430 of size: 848, ends @ 84278
     Atom trak @ 84278 of size: 8276, ends @ 92554
         Atom tkhd @ 84286 of size: 92, ends @ 84378
         Atom edts @ 84378 of size: 36, ends @ 84414
             Atom elst @ 84386 of size: 28, ends @ 84414
         Atom mdia @ 84414 of size: 8140, ends @ 92554
             Atom mdhd @ 84422 of size: 32, ends @ 84454
             Atom hdlr @ 84454 of size: 33, ends @ 84487
             Atom minf @ 84487 of size: 8067, ends @ 92554
                 Atom smhd @ 84495 of size: 16, ends @ 84511
                 Atom dinf @ 84511 of size: 36, ends @ 84547
                     Atom dref @ 84519 of size: 28, ends @ 84547
                 Atom stbl @ 84547 of size: 8007, ends @ 92554
                     Atom stsd @ 84555 of size: 103, ends @ 84658
                         Atom mp4a @ 84571 of size: 87, ends @ 84658
                             Atom esds @ 84607 of size: 51, ends @ 84658
                     Atom stts @ 84658 of size: 24, ends @ 84682
                     Atom stsc @ 84682 of size: 748, ends @ 85430
                     Atom stsz @ 85430 of size: 6548, ends @ 91978
                     Atom co64 @ 91978 of size: 576, ends @ 92554
     Atom trak @ 92554 of size: 947, ends @ 93501
         Atom tkhd @ 92562 of size: 92, ends @ 92654
         Atom mdia @ 92654 of size: 847, ends @ 93501
             Atom mdhd @ 92662 of size: 32, ends @ 92694
             Atom hdlr @ 92694 of size: 33, ends @ 92727
             Atom minf @ 92727 of size: 774, ends @ 93501
                 Atom nmhd @ 92735 of size: 12, ends @ 92747
                 Atom dinf @ 92747 of size: 36, ends @ 92783
                     Atom dref @ 92755 of size: 28, ends @ 92783
                 Atom stbl @ 92783 of size: 718, ends @ 93501
                     Atom stsd @ 92791 of size: 50, ends @ 92841
                         Atom tmcd @ 92807 of size: 34, ends @ 92841
                     Atom stts @ 92841 of size: 24, ends @ 92865
                     Atom stsc @ 92865 of size: 40, ends @ 92905
                     Atom stsz @ 92905 of size: 20, ends @ 92925
                     Atom co64 @ 92925 of size: 576, ends @ 93501
     Atom free @ 93501 of size: 168643, ends @ 262144
Atom mdat @ 262144 of size: 730194240 (^), ends @ 0
             (^)denotes a 64-bit atom length
 ~ denotes an unknown atom
------------------------------------------------------
Total size: 730456384 bytes; 66 atoms total. AtomicParsley version: 0.9.0 (utf16)
Media data: 730194240 bytes; 262144 bytes all other atoms (0.036% atom overhead).
Total free atom space: 170617 bytes; 0.023% waste. Padding available: 1974 bytes.
------------------------------------------------------

Just ran a short clip on my 1DXIII pulled the battery and extracted the DAT file to my desktop. ISObuster attempted to convert it to mpg but the resulting file
was unplayable in VLC, unrecognized by FF:Works and Davinci Resolve Studio. The conversion in ISObuster was at 2.1MB/s ... so even if it were readable the length of time
to convert would be untenable.

Good call @docmoore. Just downloaded IsoBuster and it found the .mp4. It wont let me attempt to extract it without buying a license.  I'll search out a few other free/open-source solutions first before biting the bullet on the purchase.
Here's a screenshot of the recovery:

Might give IsoBuster a try ... I have recovered a ton of stuff when the FAT was completely corrupted ... mainly from DVD/CDs
It will dump any information it finds and is usually able to tell the type of file from the structure.

Might give IsoBuster a try ... I have recovered a ton of stuff when the FAT was completely corrupted ... mainly from DVD/CDs
It will dump any information it finds and is usually able to tell the type of file from the structure.

YouTube compression :   >1440 VP9   <1440 AC1
 
think that defined for me the resolution I need to upload ... as AC1 is very poor.
I routinely upload 2K to Vimeo ... always 4K to YouTube. Vimeo charges for space while YouTube does not charge 

This seems the best photo camera ever made from canon
45mpix, 12/20fps, great ibis, low noise, af tracking seems great too with both RF and EF lenses, great photodr, cfexpress
from nfs test the overheating are on pair with what canon says. 
 
imo chance of a recall almost 0
 
Unfortunately as video workhorse is a bit too compromised.....  I wish it could do for every high end mode minute it would recover with a minute cool down.... 

YouTube compression :   >1440 VP9   <1440 AC1
 
think that defined for me the resolution I need to upload ... as AC1 is very poor.
I routinely upload 2K to Vimeo ... always 4K to YouTube. Vimeo charges for space while YouTube does not charge 

YouTube compression :   >1440 VP9   <1440 AC1
 
think that defined for me the resolution I need to upload ... as AC1 is very poor.
I routinely upload 2K to Vimeo ... always 4K to YouTube. Vimeo charges for space while YouTube does not charge 

When engineers wore pocket protectors and used slide-rules.

I believe that Sony just changed the threshold for the shutdown due to temps ....
Electrons flowing through any path with resistance generates heat ... the more electrons per unit time ... the higher the heat generated at the
same level of resistance. All cinema cameras have fans ... big ones ... my old RED Epic could dry your hair ... from the airflow and heat. Looks like
in spite of a new sensor design the engineers (or their supervisors) chose to ignore the impact of this ... on the camera and ultimately on their
company. When I render 4K DCI video from 5.5K RAW ... Canon CRM files ... the AMD Radeon VII in my MacPro heats up my room and generates enough noise
that I usually leave until it has finished due to the three fans on the card running at max speeds.
I doubt that the S1H fan could keep up with the heat load if it were moving 8K files.
BM with their new BRAW for 12K has significantly dropped the compute load ... if it can be rendered on a MacBook Pro.
Do not see that coming from Canon ... and RAW usually is not overly compute intensive just writing to a card in camera.
I assume that the CFExpress cards contribute a bit to the overall heat load as writing from mine to the computer heats it significantly.

Like this ....
 

 

Yes to keep from lifting the shadows and dealing with noise ... Clog2 more so than Clog3 ... but I always tend to underexpose ... if you blow the highlights
you are done ... since you cannot guage exposure with the in camera Clog ... it is a bit of a guess as to how it will translate when you work with the
Raw. Clog2 gives a bit more dynamic range to play with in post ... but may be a bit noisier than Clog3 where the shadows are crushed a bit more.
However ... if you do not blow the highlights the amount of recovery is very good with Clog2.