Messages

@rbrune -- You seem to have gotten deep into this, any progress or comments?

I'm still here and reading about whats going on - but currently lack time to further fiddle around with my EOSM. When I have some more free time I will continue with it

Thanks for all the testing dfort!

The thing I want to try next is to log the register settings for real mv1080 mode and see if setting those like we set 3x3 mode results in a filled up buffer. Or even try to do that while in the 600D crop hack mode buffer.
Another approach would be to just use the current 3x3 crop mode and try to only modify the registers that set start read line and end read line.

Higher fps is another story. It could even be that the timing in the liveview pseudo mv720 mode is prohibitive to reading out more lines. I have the feeling that Canon might have done all of this on the EOS M just to save some power since live view is basically always on.

[10 bit]

No you misunderstood , I'm talking about 3x crop mode not full frame with the new 10-12 raw_rec (mlv lite) with a1ex update fine resolution's , in 10 bit & 14 bit in 3xCrop mode 1072 is maximum vertical and 12bit can be expanded to 1076 on the same build . It shouldn't matter if it's 10 , 12 or 14 bit the  vertical resolution in 3x crop should not change & yes I understand what happen with the code . If you check out the full MLV 2.0+audio in 3x crop mode the maximum vertical resolution is 1076 and of course in 12bit (mlv2.0) @ 2144x1076 all frames are clean with Canon Liveview .

Edit: On MLV 2.0 with bit range reduction (10-12bit) update in 3x Crop the maximum vertical resolution stays the same thou out all 3 bit ranges of 1076

No, he is right, the bit depth matters. You can check with some simple math:

Code Select Expand


((2152*1072*10bit)/8bit)/16bytes = 180230
((2152*1072*12bit)/8bit)/16bytes = 216276
((2152*1072*14bit)/8bit)/16bytes = 252322

((2152*1076*10bit)/8bit)/16bytes = 180902.5
((2152*1076*12bit)/8bit)/16bytes = 217083
((2152*1076*14bit)/8bit)/16bytes = 253263.5

Only modes that give an integer value are valid and can be used to record with. So yes you can record with 12bit @ 2152x1076 but not with 10/14bit.

That looks very familiar. Looks like some of the PREFERRED_RAW_TYPE settings I was trying out searching for something that showed no focus pixels.

http://www.magiclantern.fm/forum/index.php?topic=5601.msg175416#msg175416

@rbrune -- could you push your work branch to bitbucket so we can check it out?

Sure, here you go:

https://bitbucket.org/rbrune/magic-lantern/branch/crop_rec_raw_video_10bit_12bit

It's a mix of the 10/12bit, crop_rec and raw_fixes branches.

That's interesting. So, as long as you don't press the shutter halfway, you get a valid 1808 x 1188 stream?

This is how it looks like when recorded with raw_rec at 1728x1154, it usually stops after a couple frames or doesn't even start.

First couple frames are with activated crop_rec 3x3 and the latter frames from a recording without (aka standard EOSM liveview) that I did immediately afterwards (one can see that the image parts, bottom left and right, are still leftovers from the 3x3 recording).

By looking at the individual DNG files it seems one could get a couple more usable lines when using crop_rec 3x3 instead of standard mv720, maybe 698 instead of 692.

@A1ex:

so I looked at your raw fixes branch and tried if I can also retrieve the LV RAW resolution by reading 0xC0F06800/4:

Code Select Expand


    #ifdef CONFIG_EOSM
    uint32_t top_left = shamem_read(0xC0F06800);
    uint32_t bot_right = shamem_read(0xC0F06804);
    *width  = ((bot_right & 0xFFFF) - (top_left & 0xFFFF)) * 4;   // Column is /4 instead of /8
    *height = (bot_right >> 16) - (top_left >> 16) - 1;         
    printf("res %d %d\n", *width, *height);
    //*width  = video_mode_crop ? 1872 : 1808;
    //*height = video_mode_crop ? 1060 : 727;
    return 1;
    #endif


The resolution I get from 600D crop mode is 1872 x 1058 which seems to be fine.
During normal EOSM liveview mode I get 1808 x 1188 but when I do a half-shutter button press to autofocus it goes to 1808 x 725 and then quickly goes back to 1808 x 1188. Needless to say that raw recording does only work in crop mode with these width/height values.
Something really weird is going on in this standy mv720 liveview mode.

Getting this thread back on topic. I still try to get true mv1080 and mv720 with 60fps working.

Using the dm-spy-experiments branch I tried to see if I can isolate a function that changes the camera into mv1080 mode when normal h264 recording starts.
So far I came up with the following:

Normal operation to recording 1080

Code Select Expand


       Evf:00014b0c:ad:03: PATH_Select S:0 Z:10000 R:0 DZ:0 SM:1 SV:0 DT:0
       Evf:00014ca0:ad:03: PathDriveMode Change: 11->6
       Evf:ff37b5e8:ad:03: GetPathDriveInfo[6]
       Evf:ff50478c:ad:03: Rec_HD_SelectPath LCD


Normal operation to HDMI output

Code Select Expand


       Evf:00014b0c:ad:03: PATH_Select S:1 Z:10000 R:1 DZ:0 SM:1 SV:0 DT:0
       Evf:ff37b5e8:ad:03: GetPathDriveInfo[11]
       Evf:ff509db8:ad:03: RecStandby_x1_60fps_SelectPath HDMI(480)


HDMI output back to normal operation

Code Select Expand


       Evf:00014b0c:ad:03: PATH_Select S:1 Z:10000 R:1 DZ:0 SM:1 SV:0 DT:0
       Evf:ff37b5e8:ad:03: GetPathDriveInfo[11]
       Evf:ff509d90:ad:03: RecStandby_x1_60fps_SelectPath LCD


So it seems the PATH_Select function decides if the camera should change the Evf mode (from mode 11 to mode 6). I hooked the PATH_Select function and overwrote the struct pointed to by reg0 to with the values that evaluate to the Rec_HD mode 11 inside PATH_Select like this:

Code Select Expand


PATH_SELECT = 0x14ac4;
MEM_PATH_SELECT = 0xe92d4030;
patch_hook_function(PATH_SELECT, MEM_PATH_SELECT, &path_select_hook, "evf_mode: PATH_select hook");


Code Select Expand


static void path_select_hook(uint32_t* regs, uint32_t* stack, uint32_t pc)
{   
    uint32_t *mode_struct = (uint32_t *) regs[0];   
    printf("mode_struct: %x %x %x %x\n %x %x %x %x\n %x %x %x %x\n %x\n",
                                      mode_struct[0], mode_struct[1], mode_struct[2], mode_struct[3],
                                      mode_struct[4], mode_struct[5], mode_struct[6], mode_struct[7],
                                      mode_struct[8], mode_struct[9], mode_struct[10], mode_struct[11],
                                      mode_struct[17]);
   
    if (is_EOSM)
    {
        switch(evf_mode_index)
        {
            case LV_REC_MV1080_24FPS:
                mode_struct[0] = 1;
                mode_struct[2] = 0;
                mode_struct[3] = 0;
                mode_struct[5] = 1;
                break;
        }
    }   
}


Sadly when I activate the hook the live view freezes as soon as the PATH_Select function is called, e.g. by switching to info view and back or by half pressing shutter to focus. Deactivating the hook returns everything to normal.
Interestingly though is that under Debug Image buffers and EDMAC channel 1 change:

Code Select Expand


Before Image buffers: 720x480, 960x639
After Image buffers: 720x480, 1728x1151

Before EDMAC[1]: 1920x639
After EDMAC[1]: 3456x1151


So I'm not sure what's going on, if my hook is working as intended (need to log debug msgs while hooked) and certainly not sure if I'm actually looking in the right place.

Yes, it's very easy to find from get_current_task. It reads current_task->taskId, and and in tasks.h, taskId is at offset 0x40 in struct task.

For CURRENT_INTERRUPT_ADDR (optional, but very useful for low-level research), you can find instructions in qemu/scripts/debug-logging.gdb (qemu branch).

Thanks!
Much easier than expected. I made a pull request for the current_task stub.
The log is way more detailed than I expected.

I will take a look at CURRENT_INTERRUPT_ADDR tonight.

I'm trying to get the current dm-spy-experiments running on EOSM, is there an easy way to find the current_task address in RAM?
It is missing from the stubs and I'm not sure what to look for. Can I retrieve/reduce it by using get_current_task?

This was done over the course of say 10 hours. It was done using battery rotation and card rotation. When I had live view one for say one full battery session, then the next battery I didn't have live view on. After checking the footage, there is a change in frame size dimensions. If you are saying that is not something that ML should be doing, then maybe it could be attributed to lens drift or something?

Card rotation? Maybe you simply had different ML settings saved on each card?

With preview set to Canon, do you still get crashes?

When set to Canon the EOSM crashes when stopping the first 10bit recording.
With ML B&W or Hacked it crashes when starting the second 10bit recording but the first records fine.

I think we need to get the ML black and white preview working on the EOSM - the incorrectly setup LV for 10/12bit is probably messing with the camera and making it crash.

I had not but gave it a quick try. Recording in 10bit with 3x3 mode worked for me on the EOSM.

After playing with it some more I noticed that my EOSM crashes (screen freezes and I can hear the lens/AF working but no reaction to button presses) when I try to record a second 10bit mlv after a first one (with/without crop_mode).
Can someone confirm this? (just record a 10bit mlv stop, wait a couple second and immediately record a second one).

@rbrune -- Have you tried merging your crop_rec with raw_video_10bit_12bit? If you have a branch for that in your repository I can compile a new set of test builds. I'd do it myself but I'm not nearly the coder you are and am busy with some other projects at the moment.

I had not but gave it a quick try. Recording in 10bit with 3x3 mode worked for me on the EOSM (of course without live preview, that still needs fixing on the EOSM).
Here you go:
https://bitbucket.org/rbrune/magic-lantern/branch/crop_rec_raw_video_10bit_12bit

@DeafEyeJedi -- in 48/50p the vertical resolution is 1.67x smaller, which kills details and causes aliasing and moire. Most of wide angle shots are quite bad.

Switching to canon 25/24p mode and then overriding to 37fps means much more detail for me. BIG chance for me, crippled resolution in 48p mode was a reason for me to start looking for a new camera.

You should check out the crop_rec module that is in development, it allows you to record in 48/50p without the vertical squeeze.

Just wanted to let you know. Not trying to be a jerk. Still wondering if true mv1080 would have less aliasing..I've been taping plastic in front of the sensor to try to make a fake vaf. . Funny thing is the best one so far was taping a piece of 35mm film in front. Not practical at all though cause I lose a stop or more of light. Does help with the aliasing though..

This mv720 mode with 3x3 binning has exactly the same amount of aliasing as mv1080 would have. It is 3 horizontal columns binned while recording every third line. The EOSM won't ever have the quality of 5D3 binning where pixels are binned in both horizontal and vertical direction - at least as far as we know this is part of the digic processing in the 5D3.

Confirmed working on EOSM, however grayscale preview is broken (all you see is the last LV frame before you hit record), only tried with crop hack

If I remember correctly the grayscale preview was always broken on the M - or did that work at one point?
Regardless, this sounds like I really need to figure out a way to increase the frame size for raw recording on the M now.

@rbrune - Quick test on your latest binary and centering looks good. I only checked the 3x3 720p (1x wide) setting.

Noticed you have dot_tune in your modules. It shouldn't be in there for the EOSM. I see DeafEyeJedi had problems with it on your previous binary when he turned it on.

The focus pixel removal tools still aren't working. I'll need more time to figure it out but the way it works is that it uses the raw buffer size for that camera model to determine what focus pixel map file (fpm) to use. It looks like crop_rec (3x3) has the same 1734x693 raw buffer size as "regular" 720p mode (3x5) so this is going to be a challenge.

The focus pixel removal function also looks at the Crop and Pan values to figure out what portion of the fpm file to use. mlv_dump -v is reporting these values:

Code Select Expand

    Crop: 304x28
     Pan: 298x28


Yes, the focus pixel removal needs to be adapted. A1ex suggested a new internal structure that will be saved out in the mlv file that would make fixing focus pixels easier and compatible with the crop_rec module.

I just pushed some new code to the pull request. The recorded area is now centered.

Here's a build to play around with, it includes the auto update code from a1ex:

https://drive.google.com/open?id=0B5FJDsqHlkJ6RmVrcUVXYk1kTHc

I helped a 60D user with this problem a while back. Here's how we fixed it:

http://www.magiclantern.fm/forum/index.php?topic=16912.0

It's a little different in this case.
mlv_rec tries to center the recording area inside the area of the sensor that is read out. What is off here is that the area of the sensor that is read out is not centered anymore after switching to 3x3 binning. What needs to be done is getting the cmos_hook working and changing the start read out line for the read sensor area.

@rbrune

Sorry for some offtopic

As I understood you managed to switch subsampling inside of mv720? So it might be possible now to make 48/50/60fps RAW on 5D3 without stretching using same method?

Check out the crop_rec module thread linked in the post above you. That does exactly that - but don't credit me, it is not my work.
I just tried if we can get 3x3 working in the mv720 mode on the EOSM and after a1ex pointed me towards the crop_rec mode I just added some preliminary support for the EOSM. After the weekend I will try to tackle the remaining issues of which the most important one is probably to center the recording area.

In case someone wants to play around with it:
https://drive.google.com/file/d/0B5FJDsqHlkJ6TVNXS1Y0MWF0dXM/view?usp=sharing

Activate the crop_rec and mlv_rec module. Under video set the crop to 3x3 mode, switch to play mode or to a canon menu for a second to make the override work and then go ahead and record mlv. Be aware that the preview is stretched.

0x11640 is good. I usually do these adjustments are to avoid cache conflicts (not the case here, because this address is in RAM) or to avoid backend quirks (for example, older versions of patch hooks could not be placed on a branch). Here, both addresses will work, but 0x11640 is the actual start address for the function.

MEM_ADTG_WRITE is just a safety check.

That works really well. I made a pull request into the crop_rec branch.

Issues so far:
- I had to deactivate the cmos_hook, even without it changing values it results in black preview data from the sensor
- mlv_rec assumes that the EOS is in 3x5 mode when calculating the squeeze factor. I removed that for now. Maybe we can check the crop.preset value there?
- the preview in 3x3 override mode is of course now stretched. Not sure if that can easily be fixed

Very nice. Sounds like a great addition to the crop_rec module.

The code there is be fairly generic - you can see the actual mode patches are done under "if (is_5D3)" blocks. It's written that way to make it easier to accommodate other models.

Great, I'm looking through the module right now. Some questions popup.

In crop_rec ADTG_WRITE for the 5D3 is defined as 0x11640 but in adtg_gui ADTG_WRITE_FUNC is 0x11644 - since the idea is to place the hook, how would I determine a good position, I assume the difference is based on that?
And what is the purpose of MEM_ADTG_WRITE / the second argument (orig_instr) to patch_hook_function? Following the code I assume this is just a safety measure to check the memory content before patching?

[single 1x1 crop mode frame recorded with mlv_rec]

After a long time I finally had time to fiddle around a little bit.

Using adtg_gui I overrode the ADTG 800C register that controls the vertical line skipping to switch from 3x5 (0x4) to 3x3 (0x2) line skipping mode. To successfully record an mlv file I also changed mlv_rec.c to ignore the special squeeze factor calculation that assumes the EOSM is always in mv720 mode.
To get the camera to accept the overridden register one has to use the INFO button to switch into Canons menu and display modes and back into magic lantern. The preview image should be stretched when it worked.

Here example 1x1, 3x5 and 3x3 frames from the exact same spot, with the same 22mm lens and the same mlv_rec resolution settings.

What I'm not sure about is how to properly implement this in a way that is conveniently usable - and acceptable for the main branch version of Magiclantern. 

single 1x1 crop mode frame recorded with mlv_rec


single 3x5 mv720 squeeze mode frame recorded with mlv_rec


single 3x3 frame recorded with mlv_rec overriding ADTG2[800C]=2