Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - heder

#1
Camera-specific Development / Re: Canon 7D Mark II
March 10, 2024, 04:03:03 PM
tiny status update ..

I have been programming in few weeks only with little progress. I was trying to get FPS override to run on the 7D2 but found it was pretty different from the other camera (due to multiple core,ICU,Omar) so I ended up hijacking the Marius/ICU engio_write function in such a way that it would play nice with fps-engio.c. That only worked somewhat and after crashing my camera too many times, I got bored and left the project for a week. On most occuations video stream would freezes and very seldom the camera would reboot, making the system  useless. Today I finally found a solution  :) : ONLY when enabling FPS override in Canons 60 fps mode and using "Exact FPS mode" then everything works a like a charm, so for now fps override will be limited to 60 fps using "Exact FPS mode".   

The last thing I need atm is getting the record button to play nicely with MLV, and when I can push the repo to public domain.

#2
Camera-specific Development / Re: Canon 7D Mark II
February 10, 2024, 01:29:41 PM
That is indeed interesting what you what you have found, keep digging. I only had a few minutes this morning to look and now in sitting in Copenhagen Airport waiting for next plane to Cairo. I wont have any time the next week, but i will be shooting some RAW video. After our trip I will continue and finalize the cleanup of my build also Ill convert some of the RAW footage and upload it to YouTube.
#3
Camera-specific Development / Re: 200D shoots raw video
February 09, 2024, 04:38:03 PM
Congrats on the success!, I guess with a little SD OC'ing this camera will do just fine.

check firmware for "SDR104" string = 104MB/S,
check firmware for "SDR50" string = 50MB/S,

So I guess that the camera is currently running in SDR50 mode, but is SDR104 string present ? Also i'm Curious to know, If you go into zoom mode (x5,x10) what is the native resolution ?
#4
User Introduction / Re: Hello
February 07, 2024, 06:59:02 AM
Welcome :)
#5
Camera-specific Development / Re: Canon 7D Mark II
February 05, 2024, 07:25:23 AM
Quote from: names_are_hard on February 04, 2024, 11:44:39 PM
Nope, because I had no idea I should look there.  This code is really poorly organised.  There's different sensor size values in at least three different files, and they all interact.  Feels like a simpler system must be possible.  Why are some per cam values in platform/XXD, where you can find them, some are in src/random_file.c, where you can't, and some are in modules/random/random.c?  Ugh.

Thank you for coming back and teaching me this impossible ancient knowledge :)

The per cam stuff in raw.c should probably be moved into platform, right?

It's kind of patching on patches, but no one took the time to fix it completely. The ML group was also very much result oriented, which is why we got result so fast (end users never really give us credit for good programming), but there is also a price to pay for that.  Alex did a great work, but even he could no do everything. And yes specific camera defines should go in platform/XXD.

#6
Camera-specific Development / Re: Canon 7D Mark II
February 04, 2024, 10:46:05 PM
Quote from: names_are_hard on February 04, 2024, 03:29:57 PM
It's a code problem in mlv, not sure where yet.  It's producing an output file that claims to be 1920 * 1080, but contains data that is 2096 * 1164 (the correct size of the image).  mlvdump, and mlvapp, seem to be trusting the 1920 * 1080 fields, but filling the display from the 2096 wide data, so everything is the wrong colours and skewed.  I can see both values inside the file:


https://i.imgur.com/XR89GXZ.png

Time to learn mlv format and fix the code I guess.

Did you set the correct black borders values in raw.c ?


        /**
         * The RAW file has unused areas, usually black; we need to skip them.
         *
         * To find the skip values, start with 0,
         * load the RAW in your favorite photo editor (e.g. ufraw+gimp),
         * then find the usable area, read the coords and plug the skip values here.
         *
         * Try to use even offsets only, otherwise the colors will be screwed up.
         */
        #ifdef CONFIG_5D2
        skip_top        = zoom ?   52 : 18;
        skip_left       = 160;
        #endif

        #ifdef CONFIG_5D3
        skip_top        = zoom ?   60 : mv720 ?  20 :   28;
        skip_left       = 146;
        skip_right      = 2;
        #endif

        #ifdef CONFIG_6D
        /* same skip offsets in 1080p and 720p; top/left bar is the same in x5 zoom as well */
        skip_top        = 28;
        skip_left       = 80;
        skip_right      = zoom ? 0  : 10;
        #endif

        #ifdef CONFIG_500D
        // FIXME: are these values correct for 1080p or 720p? (which of them?)
        skip_top    = 24;
        skip_left   = zoom ? 64 : 74;
        #endif

        #if defined(CONFIG_550D) || defined(CONFIG_600D)
        // FIXME: are these values correct for 720p and crop modes?
        skip_top    = 26;
        skip_left   = zoom ? 0 : 152;
        skip_right  = zoom ? 0 : 2;
        #endif

        #ifdef CONFIG_1100D
        skip_top = 16;
        skip_left = zoom ? 72 : 68;
        #endif

        #ifdef CONFIG_60D
        skip_top    = 26;
        skip_left   = zoom ? 0 : mv640crop ? 150 : 152;
        skip_right  = zoom ? 0 : mv640crop ? 0 : 2;
        #endif

        #ifdef CONFIG_50D
        skip_top    =  26;
        skip_left   =  zoom ? 64: 74;
        skip_right  = 0;
        #endif

        #if defined(CONFIG_EOSM) || defined(CONFIG_700D) || defined(CONFIG_650D) || defined(CONFIG_100D)
        skip_top    = 28;
        skip_left   = 72;
        skip_right  = 0;
        #ifdef CONFIG_100D
        /* 720p: H=727-1, last valid line at y=723, 2 white lines at bottom */
        /* VRAM dumps, please: http://www.magiclantern.fm/forum/index.php?topic=12375.0 */
        skip_bottom = zoom ? 0 : mv1080crop ? 0 : mv720 ? 2 : 0;
        #else
        /* 720p: H=726+1, last valid line at y=723, 3 white lines at bottom */
        /* 1080p: H=1189+1, 2 white lines at bottom */
        /* x5 zoom: H=1107+1, no bad lines at bottom; 1108-28=1080 */
        /* 1080 crop: H=1059+1, no bad lines at bottom */
        skip_bottom = zoom ? 0 : mv1080crop ? 0 : mv720 ? 3 : 2;
        #endif
        #endif

        #ifdef CONFIG_7D
        // FIXME: are these values correct for 720p and crop modes?
        skip_top    = 26;
        skip_left   = zoom ? 0 : 256;
        #endif

        #if defined(CONFIG_70D)
        skip_top    = 28;
        skip_left   = 144; // 146 could work, too
        skip_right  = zoom ? 0 : 8;
        #endif

        #ifdef CONFIG_7D2
        skip_top    = 0;
        skip_left   = 0;
        skip_left   = 0;
        skip_right  = 0;
        #endif

#7
Camera-specific Development / Re: Canon 7D Mark II
February 03, 2024, 11:14:50 PM
Quote from: Danne on February 02, 2024, 11:42:34 PM
You can check card spanning implementation on mlv_lite here. @Ilia3101 effort.
https://bitbucket.org/Dannephoto/magic-lantern_dannephoto_git/src/master/
https://bitbucket.org/Dannephoto/magic-lantern_dannephoto_git/src/master/modules/mlv_lite/mlv_lite.c

Quote from: theBilalFakhouri on February 03, 2024, 03:31:09 AM
This commit adds card spanning support for mlv_lite might help you too.

Thats awesome!, that feature is absolutely fantastic, one less problem to deal with.

Quote from: names_are_hard on February 03, 2024, 03:00:31 PM
Unfortunately, I still have some last problem to work out; the video data captured from 200D is scrambled when mlv_lite is used.  I think perhaps some bad offset or width calculation - if I manually capture the buffer the data is correct.  There are lots of hard-coded constants, it's been quite tedious to debug things :(

One scenario is that the timing is wrong, i.e. the module_cbr syncronization call that ends up in mlv_lite:process_frame() needs to be correct, otherwise the frame will be "data noise". on 7D2 I had to guess and hijack different function before I got lucky.
#8
Camera-specific Development / Re: Canon 7D Mark II
February 02, 2024, 09:53:35 AM
Brief update.

Sorry too little time for discord  :(

I'm cleaning the old hack repo and making a new clean one. Updating to the newest mlv_lite and creating a version with direct buffering so all can use this if they need it. Also inforcing that both ICU(Marius) and Omar cores uses shamem, should make fps override easy to use. Next milestone will be around 7th of Marts. The biggest issue atm is missing edmac api, as all the functions are located on Omar, but I know for a fact that ICU(Marius) does use edmac channels (firmware string "mossy") so it's possible to use edmac from ICU(Marius). Also I will look into card spamming on mlv_lite as this could enable 3k@14bit recording ~ 195 MiB/s ..

* clean repo
* fix start/stop record activation issues
* Enforce Marius to use shamem
* Enable fps override
* Investigate card spanning on mlv_rec
* Investigate how allocate more memory
#9
Quote from: reddeercity on February 02, 2024, 06:35:05 AM
After seeing considerable work on D6 (7d mrkii heder)  &  D7& D8(names_are_hard)   8)
Its inspired me to finish some unfinished magic lantern business on the 5D2 & 50D

Yes, come back and help lighting up the development  :)


Quote from: reddeercity on February 02, 2024, 06:35:05 AM
see screen shot , how do i add "gcc 4.8.3 or check for it ,

#10
Camera-specific Development / Re: Canon 7D Mark II
January 31, 2024, 03:23:04 PM
Yes, and it's to pretty important for FPS engio override.  It's lucky for us that ICU/Marius seems to set the FPS registers via this function and even more luck, it's located in RAM so we even can hijack it (if needed). We'll properly need to log the FPS registers values (0xD0006008. 0xD0006014) for the different canon fps to find the pixel clock needed in fps-engio.c, either via the canon log (it call DryOsDebugMessage) or via hijacking.
#11
Camera-specific Development / Re: Canon 40D
January 29, 2024, 03:22:37 PM
None, atm. I can't get the motion-jpeg color's correctly. There are so many registers involved and unknowns that I'd sort of put that on hold. I can get the YUV scaled correctly, it's really fine. But when I transfer this YUV image to the jpeg-engine, the jpeg color's become incorrectly. I thought it was just hue shifted but I was wrong. The image above looks pretty, but its wrong.
#12
Camera-specific Development / Re: Canon 7D Mark II
January 24, 2024, 09:18:24 AM
I re-encoded the raw 14 bits stream into 16 bits unsigned stream, saved it, and loaded it into gimp. Gimp can load RAW images if they're
encoded correctly (Grey little endian 16 bits).


#include <stdio.h>
#include <stdlib.h>
#include "string.h"

int main(int argc, char *argv[])
{
    FILE *f;
    unsigned int length;
    unsigned short *u16;
    unsigned short *bayer;

    f = fopen(argv[1],"r");
    if (f==NULL || argc != 3)
    {
      printf("No such file. Input argument is : filename length\n");
      return -1;
    }

    sscanf(argv[2],"%d",&length);

    u16 = malloc(2*length);
    bayer = malloc(length);

    memset(u16,0x0,2*length);
    memset(bayer,0x0,length);

    fread(bayer,1,length,f);

    int k=1,i=0;
   
    for (i=0;i<length;i+=8)
    {   

      u16[i+0] =                               (bayer[k+0] & 0xFFFC) >> 2;
      u16[i+1] = (bayer[k+0] & 0x0003) << 12 | (bayer[k+1] & 0xFFF0) >> 4;
      u16[i+2] = (bayer[k+1] & 0x000F) << 10 | (bayer[k+2] & 0xFF00) >> 6;
      u16[i+3] = (bayer[k+2] & 0x003F) << 8  | (bayer[k+3] & 0xFC00) >> 8;
      u16[i+4] = (bayer[k+3] & 0x00FF) << 6  | (bayer[k+4] & 0xF000) >> 10;
      u16[i+5] = (bayer[k+4] & 0x03FF) << 4  | (bayer[k+5] & 0xC000) >> 12;
      u16[i+6] = (bayer[k+5] & 0x0FFF) << 2  | (bayer[k+6] & 0x3000) >> 14;
      u16[i+7] = (bayer[k+6] & 0x3FFF) << 0;
      k+= 7;     
    }

    FILE *fout = fopen("output.data","w+");
    fwrite(u16,1,i*2,fout);
    fclose(fout);   

    return 0;
}



I used this on a RAW dump from sensor https://drive.google.com/file/d/1mhUpk9ju65U3oGHgyxbSqMW4hUfXCdx4/view?usp=sharing and got



#13
Camera-specific Development / Re: Canon 7D Mark II
January 23, 2024, 05:09:08 PM
Quote from: names_are_hard on January 23, 2024, 03:33:23 PM
That's why I'm asking questions about how you see edmac usage change when *you* call it.  So I can try to find the buffer *without* looking for the bayer data directly, since that doesn't happen here (or, perhaps the buffer is reused quickly and my logging isn't fast enough, etc).

The way I found the RAW EDMAC channel on 40D and 7D2  was starting LiveView and by reading the uint32_t value from all MEM(EDMAC_CHANNEL + 0x10) before and after call("lv_save_raw"). The channel that changed from 0 to something was the RAW EDMAC channel.
#14
Camera-specific Development / Re: Canon 7D Mark II
January 23, 2024, 03:15:59 PM
Dont mind vsync, it's not critical for now.

With no EngDrvOut and shamem and inlined code, this is going to be hell. So let do some sane checking..

1. Does "lv_save_raw" exist as a string in ghidra ?. It might also have changed name, like on the 7D2 I cant find any more "fdump" its now called "fdumpall" or "oldfdumpall", search for "save_raw" and investigate those places.

2. All those call("func_name") will be registered somewhere using a registerfunction call, like


registerfunction(pointer to "func_name", function pointer *_func);


The _func will be called when someone perform the call("func_name"). In 7D2 look up the address 0xfe0abde0 here you will see lots of registering


  FUN_fe100a6a(s__dumpall_fe0ac0cc + 4,0,s__dumpall_fe0ac0cc._0_4_);
  FUN_fe100a6a(s_dumpfall_fe0ac0dc,0,DAT_fe0ac0d8);
  FUN_fe100a6a(s_olddumpall_fe0ac0ec,0,DAT_fe0ac0e8);
  FUN_fe100a6a(s_olddumpfall_fe0ac0fc,0,DAT_fe0ac0f8);
  FUN_fe100a6a(s_grepall_fe0ac10c,0,DAT_fe0ac108);
  FUN_fe100a6a(s_dumpentire_fe0ac118,0,DAT_fe0ac114);
  FUN_fe100a6a(&DAT_fe0ac128,0,DAT_fe0ac124);
  FUN_fe100a6a(s_DisablePowerSave_fe0ab5cc,0,DAT_fe0ac124);
  FUN_fe100a6a(s_EnablePowerSave_fe0ab5e0,0,DAT_fe0ac12c);
  FUN_fe100a6a(s_SetTuningFlag_fe0ac154,0,DAT_fe0ac150);
...
...


FUN_fe100a6a = register call name .

There's many functions around in the code, even a call("grepall",?) function ???
#15
Camera-specific Development / Re: Canon 7D Mark II
January 23, 2024, 06:52:09 AM
Hooking only works when the FW calls the StartEDmac function, on many occasion they don't but only EngDrvOut. If you want to see what is happening you'll need to dig deep and find the function that trigger lv_save_raw. All those function call("func") is registered somewhere and each "func" has a function attached to it.  But the easyway to find the RAW EDMAC is quite simple. Dump all EDMAC address into a file. To do this, please use shamem_read because it's stores more EDMAC values. If you don't have shamem_read when you can still read the first registers of each EDMAC using the MEM(...) macro were you can access fro 0x0 to 0xC in each EDMAC but using shamem_read you get all. The next code (see below) values is inside Liveview before doing the call("lv_save_raw"), look carefully at 0xD0004200, it's all zeros. This is before I found shamem_read, so I had to use MEM(...) and could only read from 0x0 to 0xC using the MEM(..) macro.


*************************************
Edmac = 0xD0004000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x405A8F40
0xC = 0x0
*************************************
Edmac = 0xD0004200
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004300
0x0 = 0x1
0x4 = 0x0
0x8 = 0x126E9E0
0xC = 0x0
*************************************
Edmac = 0xD0004400
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004500
0x0 = 0x0
0x4 = 0x0
0x8 = 0x20000000
0xC = 0x0
*************************************
Edmac = 0xD0004600
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004800
0x0 = 0x1
0x4 = 0x0
0x8 = 0x9B2D80
0xC = 0x0
*************************************
Edmac = 0xD0004900
0x0 = 0x1
0x4 = 0x0
0x8 = 0x46DB80
0xC = 0x0
*************************************
Edmac = 0xD0004A00
0x0 = 0x1
0x4 = 0x0
0x8 = 0x9584B8
0xC = 0x0
*************************************
Edmac = 0xD0004B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x16BAEF40
0xC = 0x0
*************************************
Edmac = 0xD0004E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026200
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026400
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026500
0x0 = 0x8
0x4 = 0x0
0x8 = 0x1617A000
0xC = 0x79
*************************************
Edmac = 0xD0026600
0x0 = 0x0
0x4 = 0x0
0x8 = 0x15D3EBA0
0xC = 0x14
*************************************
Edmac = 0xD0026700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026800
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1840715A
0xC = 0x0
*************************************
Edmac = 0xD0026900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026A00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x15D38700
0xC = 0x1FEF
*************************************
Edmac = 0xD0026B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x15C8D200
0xC = 0x1FC2
*************************************
Edmac = 0xD0026C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x18543000
0xC = 0x0
*************************************
Edmac = 0xD0030100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1A683C00
0xC = 0x0
*************************************
Edmac = 0xD0030200
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1A684400
0xC = 0x0
*************************************
Edmac = 0xD0030300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x40ABF4F0
0xC = 0x0
*************************************
Edmac = 0xD0030400
0x0 = 0x8
0x4 = 0x0
0x8 = 0xAA9928
0xC = 0x0
*************************************
Edmac = 0xD0030500
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030600
0x0 = 0x1
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030800
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x405BFF24
0xC = 0x0
************************************
Edmac = 0xD0030A00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1835FB80
0xC = 0x0
*************************************
Edmac = 0xD0030B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x409EA314
0xC = 0x0
*************************************
Edmac = 0xD0030E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0


Then I found shamem_read and also turned on call("lv_save_raw"), when I dumped all EDMAC again and now look at 0xD0004200, now it non-zero and 0xD0004210 = 0x42B0D90, this is the configuration in "EDMAC internals" post that a1ex says describes as "Simplest WxH"


xb * (yb+1)        (xb repeated yb times)


0xD0004210 = 0x42B0D90 ==> (0x042B0000 | 0x00000D90)==> Simplest HxW = 1068(H) x 3472(W)   ==> 1984(W) x 1068(H) @ 14 bits.

So the RAW EDMAC transfers a bayer image of size 1984(W) x 1068(H) @ 14 bits. This is including black border, to find the borders you'll need to save the RAW image and investigate the raw bytes, or get mlv_lite or similar to save a mlv video with (borders 0,0,0,0) and check the image.


*************************************
Edmac = 0xD0004000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004200
0x0 = 0x2
0x4 = 0x20301008
0x8 = 0x1A67C000
0xC = 0x0
0x10 = 0x42B0D90
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004300
0x0 = 0x4
0x4 = 0x20008000
0x8 = 0x1288800
0xC = 0x0
0x10 = 0x19705A0
0x14 = 0x0
0x18 = 0x20
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004400
0x0 = 0x1
0x4 = 0x60000000
0x8 = 0x3180D00
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004500
0x0 = 0x4
0x4 = 0x20008000
0x8 = 0x1F02E000
0xC = 0x0
0x10 = 0x4370F00
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004600
0x0 = 0x4
0x4 = 0x60000000
0x8 = 0x31EB200
0xC = 0x4A
0x10 = 0x1000
0x14 = 0x1000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004800
0x0 = 0x4
0x4 = 0x0
0x8 = 0xAB32B8
0xC = 0x0
0x10 = 0xDF07D0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x20001000
*************************************
Edmac = 0xD0004900
0x0 = 0x4
0x4 = 0x20001000
0x8 = 0x46D8E8
0xC = 0x0
0x10 = 0xDF07D0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x20001000
*************************************
Edmac = 0xD0004A00
0x0 = 0x4
0x4 = 0x0
0x8 = 0xA5AB88
0xC = 0x0
0x10 = 0x42B0008
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x60000000
*************************************
Edmac = 0xD0004B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004C00
0x0 = 0x4
0x4 = 0x60000000
0x8 = 0x3180D00
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004D00
0x0 = 0x4
0x4 = 0x20000000
0x8 = 0x16F3E800
0xC = 0x0
0x10 = 0x3FB0E30
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0xB
0x14 = 0xC0000030
0x18 = 0x1
0x1C = 0x0
0x20 = 0x0
0x24 = 0x33
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026000
0x0 = 0x1
0x4 = 0x60000000
0x8 = 0x32AA400
0xC = 0x12
0x10 = 0xC00
0x14 = 0x1000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026200
0x0 = 0x4
0x4 = 0x20000000
0x8 = 0x1A49DBC0
0xC = 0x0
0x10 = 0x160050
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026400
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026500
0x0 = 0x2
0x4 = 0x60001008
0x8 = 0x0
0xC = 0x79
0x10 = 0x1EC0
0x14 = 0x8000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026600
0x0 = 0x2
0x4 = 0x60001008
0x8 = 0x0
0xC = 0x39
0x10 = 0x7610
0x14 = 0x8000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026800
0x0 = 0x4
0x4 = 0x20000000
0x8 = 0x1A478000
0xC = 0x0
0x10 = 0x11C03B6
0x14 = 0x0
0x18 = 0x14A
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026A00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x0
0xC = 0x1FFF
0x10 = 0xFFFE
0x14 = 0xFFFE
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026B00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x0
0xC = 0x1FFF
0x10 = 0xFFFE
0x14 = 0xFFFE
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030000
0x0 = 0x4
0x4 = 0x0
0x8 = 0x1830A800
0xC = 0x0
0x10 = 0x1670500
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030100
0x0 = 0x6
0x4 = 0x300008
0x8 = 0x1A685A00
0xC = 0x0
0x10 = 0xF01E0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030200
0x0 = 0x6
0x4 = 0x40300008
0x8 = 0x1A683E00
0xC = 0x0
0x10 = 0xC0200
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030400
0x0 = 0x6
0x4 = 0x300008
0x8 = 0xBACC80
0xC = 0x0
0x10 = 0x28
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030500
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030600
0x0 = 0x4
0x4 = 0x0
0x8 = 0x3397300
0xC = 0x0
0x10 = 0x3B00A0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030800
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030A00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x183166A6
0xC = 0x0
0x10 = 0x11A03B2
0x14 = 0x0
0x18 = 0x14E
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030B00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x184D2800
0xC = 0x0
0x10 = 0x1DF0500
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0

#16
Camera-specific Development / Re: Canon 7D Mark II
January 22, 2024, 04:45:45 PM
Yea, we're abit to early on. I need a little more time to make thing pretty. The quick and dirty port was only to prepare for my next travel. My next task is to complete direct buffering and push it to a repo, so it becomes usefull for all. But I need to understand all the EDMAC offsets first.


#17
Reverse Engineering / Re: EDMAC internals
January 22, 2024, 04:38:34 PM
Here's is the image from the patent.


We're using offsets with positive values (edmac_memcpy), but here they're are showed with negative offsets. This is quite a power full dma engine.

  • After xn (XNUMA) times xa copies, the last xb can actually move inside the last xa copy, If off1b is negative
  • After the first xa copy, you can overwrite the first xa if you make off1a negative
  • If xb is zero bytes but off1b is negative, the new pitch  will become new_pitch = old_pitch - off1b (I think so .. )
  • I'm going to stop here .. too many options ..
#18
Camera-specific Development / Re: Canon 7D Mark II
January 21, 2024, 12:29:44 PM
Quote from: names_are_hard on January 19, 2024, 04:25:48 PM
I suspect I've already done similar with 200D, but not using mlv_lite.   Much nicer putting it there but was easier hacking it in to test.  I was missing the lv_save_raw step - I can capture full sensor, but it's YUV 422 and already resized to 1080.  Maybe we can get both cams working at the same time :)

Direct buffering is always possible, even if it's only a temporary solution. The YUV422 (EDMAC) is always available (and it should be possible to re-size it, did that on 40D), but the save requirements is much worse than the raw format.
#19
Camera-specific Development / Re: Canon 7D Mark II
January 21, 2024, 12:15:11 PM
I finally got a little time to test the build with a fast CF card, turned out it was indeed a Sandisk UDMA-7 Extreme card (but limited to 120 MB/s), a little resume form the test (24 and 25 fps)

  • No vsync/tearing issues, vsync hijack location is valid :), this was critical
  • UDMA-7 card, zoom(x1),  1984x1068x14 bits (active area 1832x1044), direct buffering,limited RAM ~ 250MB,  continuously shooting 
  • UDMA-7 card, zoom(x10), 3616x1348x14 bits (active area 3472x1320), direct buffering,limited RAM ~ 250MB,  you get max 24-70 frames
#20
Camera-specific Development / Re: Canon 7D Mark II
January 19, 2024, 01:03:36 PM
The experimental 7D2 "hacky" repo with RAW video.

the code was been stored as a single zip file, rather than a git repo and temporary on google drive. Its was messy repo. I have used some time to make it less messy.  Take what you need and put it into the repo, don't wait for me to submit it, that will take forever for me, as my time is limited. I will try .. to explain that I have done. 

https://drive.google.com/file/d/1GeoqHV1r1D4EOAy702CAhAMYYsnOHZHD/view?usp=drive_link

* addlog

In the code you'll see addlog() .. it's must my own version of a similar DryOsDebugMessage, just regards those.

* vsync hack
vsync_func (state-objects.cpp) is called once per frame in LiveViev. This execute all modules frame syncronization (CBR_VSYNC). The vsync_func is normally called from the LiveHandlerapp handler, but on the 7D2 the stubs has not been found. This one is necessary for all modules that requires a frame syncronization, like mlv_rec and mlv_lite. They way I solved this was by hijacking function located in RAM. I used "olddumpfall","dumpfall" to dump the DryOsDebugMessages to card and analyzed them. Found some functions what there called on a regular basis, one seemed to interrupt functions. To make this work I implemented a thumb-2 BL_INST_T2 which could be used to hijack a BL instruction in thumb-2 mode in RAM and make the code jump somewhere else. It makes the same result as BL_INST but in thumb-2 mode. The max jump is (24 bits?) and the instruction size is 4(!) bytes, really messy instruction and hard to implement). The BL_INST_T2 code is worth getting into the new branch.  I then used the BL_INST_T2 to hijack a DryOsDebugMessage and instead called vsync_func() for frame synchronization

1. BL_INST_T2 hijacks a instruction (run_test_2,debug.c) which will call private vsync function in function-override.c
2. private vsync function in is used to compute frametime and then it calls the vsync_function in state_objects.c
3. vsync_function in state_objects.c execute module CBR_VSYNC.
4. fps-engio.c is alo hacked and uses the frametime from function-override.c to return correct value via fps_get_current_x1000()

* raw video (raw.c)
I had to do some hacks in raw.c (CONFIG_7D2) to get everything to work. The raw width and height is decoded from the RAW EDMAC by looking at the EDMAC sizes register. I'm actually using shamem_read() from Omar. The Omar code on this particularly function is position independent and the shamem memory is located inside RAM so reading the EDMAC shamem values works as intended. The border values (black border around RAW image) in raw liveview is hardcoded to 0, so I can do direct buffering. Also I needed to avoid some code (there's a odd return somehwere) that crashed the camera, some additional info that raw.c api provides, but which is strictly not needed.

* mlv Lite (mlv_lite.c)
I'm using a old mlv_lite only supporting 14 bits. The new module was complex so I decided to use the old mlv_lite from the vxworks brach instead. This did not work either so I had to do some hacks were as-well. I could not get CBR_KEYPRESS / raw_rec_keypress_cbr() to start the camera, maybe because some functions returning if the camera is idle or not does not work as intended. raw_rec_keypress_cbr() was changed for the worse. I'm using a run_test_alt() in debug.c to set a flag so I can start recording (start_stop_RAW_recording) when setting this flag and performing HALFSHUTTER_PRESSED then it will start recording.

Direct buffering: Inside mlv_lite.c I force the width,height to be maximum (from value returned via the raw.c api) so I can do direct buffering. That is important because then mlv_lite will allocate buffer images which is equal size to the EDMAC canon raw video buffers. The direct buffering is done in  raw_rec_vsync_cbr()/process_frame(). raw_rec_vsync_cbr is called once per frame and changes Canon EDMAC buffer to our own temporary buffer using raw_lv_redirect_edmac(), then -(normally)  we would use EDMAC copy in process_frame() to copy the pixels from this buffer into our array of images  that will be saved. This is now changed so we skip the EDMAC copy and just change Canon EDMAC buffer into the right image in our save image buffer array. This only works when we use the entire image format. Mlv_lite also has a autocheck (all versions) that the buffer are in fact filled with the RAW image (there a signature check), this still works, so that if you get dropped frames, the recording will stop. 

* Changed some code: Somewhere in mlv_lite I also needed to skip/change? some code, AFAIR was due to skipping code in raw.c. ML video needs alot of information like black levels ect, so the MLV header regarding these additional information it not fully correct. Black level is around 2048(?).

* Somehwere along the line: I lost the ability to compile module correctly (module_string.h could not be created), so currently only mlv_lite is enabled and I have a module_string.h from a clean branch included, and when it compiles. If you make a complete clean, the module_string.h will disapeer, compilation will then fails.

And finally .. Start recording on this hacky,wacky bleeding edge build:

1 start the camera
2 enable mlv_lite module
3 reboot the camera
4.Enable RAW recoding in ML, the format is fixed and can't be changed, Enable SRM memory!.
5 Select debug menu -> vsync
6 Go in to LiveView recording mode (not LiveView photo mode)
7 Select debug menu -> start recording
8 Do half shutter press once or twice to start record

To stop recording do 7+8 again. Sometimes when pressing a button it's like ML gets the button command twice, and then it does not work, just exit video recording mode and start from 6.

-R-O-A-D---M-A-P-

I have no roadmap for the 7D2, other that at some point in time, says around April .. but not the 1st  ;D we should make a barebone build with RAW video enabled available to everyone.

#21
Camera-specific Development / Re: Canon 7D Mark II
January 19, 2024, 12:20:28 PM
Quote from: names_are_hard on January 18, 2024, 05:42:24 PM
...
I don't know what this "direct buffering" is that Heder mentions, but I'm hoping when I see the code it will be easy to port to other cams.
...

Buffering in mlv_lite, click to expand images


  • A: Sensor
  • B: Canon Liveview RAW image buffers
  • C: ML (mlv_lite,mlv_rec) double RAW buffers
  • D: ML image (save) buffers
  • E: CF/SD card slot



When we enable RAW, call("lv_save_raw), canon firmware will create a "RAW" EDMAC transfer from sensor (A) to its own buffers (B). The size of the RAW images is set by canon. (I know on some builds you can mess with the sizes, but this is NOT portable and re-useable on all platforms)



When we start mlv_lite or mlv_rec recording ML re-routes the "RAW" EDMAC destination from canon buffers (A) to our own ML buffers (C). Both Canon and ML buffers are equal size. Then ML will create an additional EDMAC transfer, that performs a sub-image copy to the user format (i.e. user requested width and height). the final image ends in the save buffer (D) before being written to CF/SD card (E).

Doing it in this way will make the code portable and re-useable between builds and cameras, that is pretty important. We cant have too many #ifdef if the code, itwill kill the project. Also keep in mind that on many camera it's not the internal hardware , sensors, memory that is a problem, it's the maximum save bandwidth on the CF/SD cards, thus using a smaller format (if possible) less bit (is possible), overclocking CF/SD card (if possible) if what you want to achieve your goals.



Direct Buffering.

The last option is direct buffering, which is more simple but also less good in terms of options. Here we re-route the "RAW" EDMAC image directly into the save buffers and save them to CF/SD cards. This can also be done in a portable and re-useable way. BUT we can't control the width and height in a proper portable and re-useable way. We're kinda locked to the width and height that canon chooses.

Pros

  • Easy to implement
  • Works without finding the EDMAC stubs, good for an early build

Cons

  • No width and height control
  • You need a fast CF/SD card for shooting continuously

Should this approch go into the code ? .. I have no idea.  We will need to get the EDMAC stubs/code running correctly, it's mandatory for a proper build, but until we get there, direct buffering is a cheap way of getting RAW video out of the camera. If saving on both CF+SD is possible in parallel, when even the 3616 x 1348 x 14 bits in zoom mode is possible, but the file sizes will suck.
#22
Camera-specific Development / Re: Canon 7D Mark II
January 18, 2024, 09:25:20 AM
Quote from: Walter Schulz on January 18, 2024, 07:42:13 AM
7D2 is using 3x3 binning as 5D3. So moiré/aliasing should not be a big concern using full sensor.

But why UDMA-6 CF? Cam supports UDMA-7.

I did not see any moiré/aliasing so far, I'll have to do some more testing today.

Yes the camera support UDMA-7, but I never got to the point of buying a UDMA-7 card, as my old camera (40D) is PIO mode only. But I will need to upgrade soon. Btw. in Zoom (x5,x10) mode the format goes to 3616 x 1348, not bad for a beginning, yet that requires around 195 MiB/s at 24 fps, which can only be achieved if we can use both cards slots at the same time.


#23
Camera-specific Development / Re: Canon 7D Mark II
January 17, 2024, 11:54:39 PM
The code is pure spaghetti carbonára  :P. I was hacking for a whole month, nothing worked until I used direct buffering, turned out it worked. But the direct buffering only works on the full stream, i.e. full image, but for a beginning it's quite useful. I have not pushed the code into git I will check-in the mlv_lite in tomorrow. The magic is done in mlv_lite process_frame(), only changed a few lines of code.

#24
Camera-specific Development / Re: Canon 7D Mark II
January 17, 2024, 10:53:04 PM
I have RAW video up and running. I'm going to Egypt next month Giza, Luxor and the valley on the kings and the Nile, was there 24 years ago, going back so I'm really excited. But going there without ML RAW video is bad karma, so I had to investigate every possible way of getting the camera to do as I wish.

  • Tryed ordinary DMA failed, failed it's too slow in LV mode
  • Tryed Omar EDMAC functions .. failed, they're not compatible
  • Tryed Recreating all edmac functions .. failed
  • Tryed direct buffering (edmac not needed) using 14 bits .. success 8) using a very old mlv_lite module
Im was recording the entire RAW buffer including black border, 1984x1068x14bits,  around 85 MiB/s for 24 fps. I will try to record a large file using a fast CF card ( DMA-6)  in the following days to see if I get frame drops. The following video was recording using 25 fps, and recoded to H.264



#25
Camera-specific Development / Re: Canon 7D Mark II
January 06, 2024, 11:12:15 PM
The Master ICU processor has a "DSEngio" engio write (0x00013ea0) function which is used to activate LiveView (0x00017c24), including FPS registers, it's set all the standard FPS registers - but a the new address range 0xD00060{08,10,0c,14}.  This is quite usefull. Inside this engio write function there is a DryOsDebugMessage for each write, I can hijack this DryOsDebugMessage and investigate everything that the master writes. This write is not backup'ed in the shamem_read (shamem seems to only be controlled by the Master Omar processor).

I have created a BL_INST_T2 which performs the same actions as BL_INST but in thumb2 mode, that can be used to hijack instruction BL instructions in thumb2 mode - but ofc only in RAM, also it can only jump +/-22 bits, but this ain't a problem on the 7D2 ML starts around 0x1CC440 which is less than 22 bits from 0x0.