Canon 7D Mark II

[Walter Schulz]

7D2 has just 20.2 Megapixel and pixel-wise it comes to 5.472x3.648 pixels. Have fun glueing some additional pixels for 6k.

[mlrocks]

Roughly 6k. 5.4k 1x1 14 bit color depth uncompressed raw is golden, even for the next several decades.

[vastunghia]

Well, if 3840 = 4K, then 5472 = 5.7K

But 14-bit 1x1 5.7K would require something in the range 250 - 300 MB/s I guess, even with 1:2.5 aspect ratio and 24 fps.

[Walter Schulz]

5472 x (5472:2.5) x 24 x 14 x 0.4 / 8 =  192 MByte/s

216 in benchmark - 10 percent for overhead (est.) = 194.4 MByte

Close call.

[vastunghia]

You are right for sure Walter, but I cannot understand where I’m wrong. Please advice.

With your formula

3840 x ( 3840 : 2.5 ) x 24 x 14 x 0.4 / 8 = 95 MByte/s.

However with UHD my personal experience is that it is difficult to get less than 130 MBytes/s. Typically I will get something more in the range 140-150 (no continuous rec but often long enough for short clips).

What am I missing?

[Walter Schulz]

Nothing I guess!

Have to play around a bit with 5D3 go get a better understanding how this cam behaves in high res MLV recording.

The only thing we know for now: 7D2 seems not hampered by 5D3's interface limit. Both cards work the same speed in single card benchmark and combined.

[vastunghia]

Cool.

What does 0.4 in your formula stand for anyway? Expected compression ratio?

[a.sintes]

( 3840 * ( 3840 / 2.5 ) * 23.976 * 14 ) / ( 8 * 1024 * 1024 ) = 236MB/s
  ^ width       a.r. ^   fps ^  bit dpth.^      ^---^--------^ bits to Bytes to KB to MB conversion

x0.4 in @WalterSchulz computation is the lossless compression ratio, which seems quite optimistic to me depending of the overall video exposure and the ISO (close to 100=less noise pattern=better compression): if you just increase it slightly to x0.5 then you get ~118MB/s, which sounds more realistic in real conditions with potential partial overexposures.

[mlrocks]

5472 x (5472:2.5) x 24 x 14 x 0.4 / 8 =  192 MByte/s

216 in benchmark - 10 percent for overhead (est.) = 194.4 MByte

Close call.

If sd is overclocked to 240 mhz, maybe can add another 40 MB/s. 

[mlrocks]

( 3840 * ( 3840 / 2.5 ) * 23.976 * 14 ) / ( 8 * 1024 * 1024 ) = 236MB/s
  ^ width       a.r. ^   fps ^  bit dpth.^      ^---^--------^ bits to Bytes to KB to MB conversion

x0.4 in @WalterSchulz computation is the lossless compression ratio, which seems quite optimistic to me depending of the overall video exposure and the ISO (close to 100=less noise pattern=better compression): if you just increase it slightly to x0.5 then you get ~118MB/s, which sounds more realistic in real conditions with potential partial overexposures.

In my experience, wide angle shots with heavy foliage the ratio is about 0.7, which is the worst scenario.

[mlrocks]

the more important and practical is if 7d2 can do uhd 60p lossless 14 bit or even 10 bit raw. this makes ml on par with other high end cinema cameras. many cameras claim they can do 4k or 6k 120p or 240p, but typically there is cropping or dual iso disabled. etc, the sensor readout is not fast enough. so 4k 60p raw is very practical.

[names_are_hard]

7D2 can't do raw of any kind at present.  This card speed test isn't touching the sensor, we have no idea of the capabilities.

The most important thing is getting things working, not dreaming about 60fps!

Certainly, there is potential.  We need more devs.

[heder]

I have started to search for the remaining stubs, I hope that this task can be compled before newyear. The only thing I'll try to work on (beside finding stubs) is the the advanced intervalometer, because I would like to have it working before my winter/ski/christmas holiday in Sweden. 

[names_are_hard]

Which stubs do you mean?  The 7D2 has all stubs found that I'd expect *given what we know how to do* for D678X cams.  Some stubs probably no longer exist.  Some likely exist but in an altered form, EDMAC is probably in this category.  The pattern of calls to DMA related functions is quite different on 200d, at least.  Haven't checked a D6 in detail.

[heder]

A guess a few stubs is missing if you want to do some debugging ect.

I have the intervalometer running, but need to test is in all condition and all modes, which required me to find DISPLAY_IS_ON, so once I have tested it thoroughly I will push the code.

[names_are_hard]

I guess it depends how you want to debug   For that cam I don't have a cable made up, so I mostly used Qemu or bmp_printf().  Not ideal.

For intervalometer, that makes sense, I misunderstood the context.  Yes, you'll have to find new stuff for enabling features.

Are you finding it stable so far?  I haven't tested much at all with 7D2, just did enough work to get barebones GUI working and benchmarks.

Looking forward to a "new" feature   Nice to have someone else joining in on these new cams - and hopefully intervalometer will be an easy port to other models.

[kitor]

We found intervalometer broken at least on D8 - Canon evproc used for that crashes the camera (null pointer) if previous shot was unsuccessful. Otherwise it worked - wonder if that's an issue on D6.

[names_are_hard]

Oh yeah, I remember that now - this could be forced by not letting the AF lock, if I'm thinking of the same thing.

[kitor]

Yes, that was the crash trigger for me - if AF was enabled and didn't lock. We use factory mode functions underneath so it is not surprising they have edge cases.
I spent a few days looking for a better way to make a photo from code but was unsuccessful.

[Walter Schulz]

Sorry to interrupt. Don't know if it is related:
Legacy ML's intervalometer disables AF. If you use ML feature "Use Autofocus" and AF fails to lock you get this one:
https://foss.heptapod.net/magic-lantern/magic-lantern/-/issues/2923

Is your intervalometer code different?

EDIT: Didn't try to find out the build corrupting AF feature. I assume it worked once upon a time.

[heder]

So far I have only testet it lightly, but in all modes, with and without focus enabled, with and without flash, no crashes yet, seems to be pretty stable and solid. Only bulb mode (dial B) does not shoot if you don't enable bulb timer in ML, but I guess that is the way is should work.

I also been looking for the size of the SRM buffers (to complete the memory system), but failed to find the size, yet it seems it does not matter what size you set the SRM buffer to, the exmem system still works. Tried different sizes (32,33,34,35MB) and all times I succesfully got 5 buffers.

Another thing, less good, once I have executed "dont press me button" with any code more than 8-9 times, the executing time for the next "dont press me button" test takes longer and longer time, feels odd and incorrect. All I did in that run_test code was
foo += 0x100000.

[names_are_hard]

Good to hear it's pretty stable for you.

SRM works differently (and badly) on Digic 7, where I have spent most time.  Haven't looked at it at all on 6.  Consequently I don't know much about this system.

I'd have to see the code to guess at a cause for the "don't click me" behaviour.  Fork my repo and push a branch?

[heder]

I will try to push the code tomorrow, next week I might need to go traveling, so I'll be busy for the whole week.

Turned out I wasn't pushing my luck with regards to SRM memory, there a limit just above 36MB, so I'll do a bruteforce run and find the correct limit. . Read the exmem.c code check what srm_malloc_crb returns ... 0x2314000 

[heder]

EDMAC address on 7D2. On all other cameras the engine DMA address range was 0xC0Fxxxxx but on the 7D2 it's 0xD00xxxx

0xD0004x00 ; x = channel
0xD0026x00 ; x = channel
0xD0030x00 ; x = channel

I did not find 0xD0027x00

[names_are_hard]

Yup, this is the same on 200D.  On that cam, there's an array starting at 0x66264, where each element is something like: {uint32_t channel_addr, uint32_t ModeInfo}.

I think it's the same EDMAC device, or at least the API is very similar, mapped to a different address.  There's a partial write up in my post here:
https://www.magiclantern.fm/forum/index.php?topic=26249.msg245565#msg245565

In Kitor's dumps of the tables from various cams you can see the 0xd0004000 range is used on various D7 and D8 cams.

Please note most EDMAC related functions now take a struct, which holds two channels, rather than two functions being used, each taking one channel.  This means (I think!) that there are no direct equivalents to the EDMAC stubs for D45 cams.  One such struct is roughly described here:
https://github.com/reticulatedpines/magiclantern_simplified/commit/7a67edc5011d27c7080c6c940385328ab3aae82e#diff-9450d43dd0c51c7b781f01100a2d37e9ef1903d6a16fcf51be40b03f3d8aed38R693

Comparing 650d to 200d, I see for example that c0f2b000 is used in the same way d002b000 is for 200d.  So quite probably just the base address of the device has changed.  I don't have experience working with EDMAC on older cams.  Do you know of a good writeup anywhere?  I'm finding lots of similarities, but I don't have a good idea of what to do with them.