Line Skips, DZOOM, YUV resizing. Real HD?

[1%]

So my camera went haywire after silent pics (or something else?) who knows. But in dzoom mode I can resize the YUV buffer. Not only can I do this while recording but if I disable zoom blocking (ML) at rest too (although it quickly resets). Seems that line skips, sensor viewing window and "zoom" are controllable on 600D (others?). The firmware functions are pretty complicated so maybe some people better at assembly (and graphics) can look too.

You can watch the fun here:

https://bitbucket.org/hudson/magic-lantern/changeset/a11ebaaa526fb6cf83010db69252cb7d5b57aac4

Since the changeset will be buried I figured I'd start a thread. Anyways:

Waku is the sizing doohickey. It prints messages like [GMT][WAKU].

NSTUB(0xFF1094D0, str:wCmosHskipStart_wCmosVskipStart) - Controls CMOS Line Skipping

NSTUB(0xFF1031C8, str:[GMT][WAKU]_LvMode_ImgW_WinW) - Controls dzoom somehow.

NSTUB(0xFF276C78, str:TestErr_Test1_Test2_Test3_Test4_Test5_Test6_Te) - Strange test function which tests:

NSTUB(0xFF276B58, str:[LVDS]_DTS_GetExactDataOffset) - Returns 25 a lot which I guess is regular 1.0 zoom.

NSTUB(0xFF106B48, str:Gmt\GmtWakuState.c_[WAKU]_gmtPclvAvailable_[GM) - Might help resize MJPEGs?

NSTUB(0xFF103364, str:[WAKU]_UpdateImageMagnify) - Calls the other functions.

NSTUB(0xFF10316C, str:[GMT][WAKU]_DZoomRatio) - Blocks zooms under 100.


Function start: sub_FF13539C - unnamed called by str:PTPRspnd\PtpDps\PtpOperationDs.c_PtpReSizeJpeg+4: - seems to do a LOT of stuff related to PTP. Maybe would help with finally making jpegs without the cable.


So on and so forth....

WAKU also controls face detection which makes me hope that can be set to 0,0 and free up some processing power. But with the other stuff a 1:1 crop mode or full HDMI (which I think is 4:1:1, boooo) might be possible. The available image area from the logs is over 2k but the recorder will never record over 1920x1080 so the best that can be done is bigger MJPEGs, silent pics or actual HD, HD. Moving the crop mode zoom "window" also seems conceptually possible, as does altering sensor area being used. Full sensor is resized to that 2K.

Since this seems to be doable on the fly and crop mode YUV is bigger than regular zoom mode, I think messing with stuff here and cache hacking the errors out may accomplish something nice and not just camera freezes like altering W/H of the recorder did. There's a bunch of unnamed/unexplored functions too. Thoughts?

[ilguercio]

NSTUB(0xFF1094D0, str:wCmosHskipStart_wCmosVskipStart) - Controls CMOS Line Skipping
Yummy...
Good luck with that, it's been a long time since no mayor discovery has been made. Time for another one

[1%]

This stuff has lots of parameters  If you took out line skips I assume either image would zoom or processor would work harder. Not sure how to control all of these.

But for face detection:

NSTUB(0xFF104BE0, str:[GMT][WAKU]_gmtStopAFFace)

but it has str:[GMT][WAKU]_gmtStopAFFace(arg0)

And:

NSTUB(0xFF106788, str:[GMT][WAKU]_gmtStopWakuFace) which might be a property.

prop_request_change(33882123, 1652 + arg0,

There is also: [GMT] GMT_CONTINUOUSAF_Start' and a TV version of the same. Other cameras have this? Or does 600D have the same as T4i? Not called much.

Trying to run these functions did seem to drop CPU usage but it went right back up when it restarts.

There is some sort of LV recorder:

FF10D654:   '[GMT][LVREC] gmtRecStart'

There is also the motion manager, which I'm not sure what it does. Seems canon has its own motion detection?

And FF10E1D4:   '[ENCO] ENCODE_StartEncodeJpeg'

Another encoder exists for LV. Maybe related to face detection? Could be xploited to make big face detection jpegs vs using PTP since they can be resized (have seen ~400x400 in logs). I do see the face detection jpegs in ram when not connected. A lot of these functions don't seem to show up in the logs even though they have debug messages.

[nanomad]

GMT_CONTINUOUSAF_Start it could be related to the AF drive modes (AI servo and such)

[1%]

Possible, forgot about them. But only called a few times from stuff that didn't look related.

Looking at HDMI, since bars are drawn and this place seems more appropriate.... I think HDMI is "lucky angel" regular LV is quark?

NSTUB(0xFF485FF0, str:MainMovieAspectFrame_MainOutLine) inner and outer frame?

Code Select Expand


FF4861BC: STRING: 'LiveViewDrawUtility.c AspectLeftFrame X(%d) Y(%d) W(%d) H(%d)' FF485F64
FF4861FC: STRING: 'LiveViewDrawUtility.c AspectRightFrame X(%d) Y(%d) W(%d) H(%d)' FF485F8C
FF48623C: ff662ce4 ; *'***** SetLvMovieAspectFrameAndOuterFrameToWinSystemWithRefresh hDialog NULL !!' FF486014
FF486240: STRING: 'SetLvMovieAspectFrameAndOuterFrameToWinSystemWithRefresh' FF4860D4
FF48627C: STRING: '***** VramArea W=0 or H=0 R(%d)W(%d)H(%d)' FF48615C
FF4862A8: STRING: '***** VisibleArea W=0 or H=0 R(%d)W(%d)H(%d)'



NSTUB(0xFF44616C, str:CONNECT_VIDEO_HDMI_v2) - Has stuff about trimming.

NSTUB(0xFF02CBD0, str:RscMgr.c_NumOfFreeLiveViewAngel_MAX_LV_ANGEL) - dunno...

NSTUB(0xFF02A434, str:RscMgr.c_NumOfFreeLiveViewAngel_LV_ANGEL_SIZE) - related

The above aren't so interesting but this is:

NSTUB(0xFF37B1BC, str:Avail_Image_AH_Avail_Vram_Avail_VisibleArea_Av)

[1%]

Got a thought: Couldn't raw video be recorded more easily at the smaller YUV sizes?

[a1ex]

Of course it can.

It isn't raw, just uncompressed

[1%]

Lots of sizes to chose from, 3.1x to 10x. Still It would be 4:2:2 and maybe not stop after 30 seconds.

[a1ex]

On 600D, I think you can even use large buffers with shoot_malloc and redirect the YUV EDMAC buffer. On 60D it seems to work.

On 5D3 it doesn't

[1%]

Wonder if this resizing stuff would work on other cameras. They put in the dzoom functions, maybe they didn't take them out of future models.

[a1ex]

The dzoom stuff is on 60D and 5D3. On 60D, I could bring some dialog boxes suggesting digital zoom, but no image.

Try enabling memspy for digic registers (say starting at C0F00000), then zoom in and out and see which ones are changed. I've got this list with this method:

http://magiclantern.wikia.com/wiki/Register_Map/Clean_HDMI

[1%]

So we have to figure out how the zooming actually happens. I can make a list after work. Changed registers could also be in the functions at least partially.

Register log would work for this too? Easier than reading them off the screen.

[1%]

Ok here are some logs:

1x zoom : http://codepad.org/HcJGjQEq
3x zoom: http://codepad.org/7bveSpDe
4x zoom (recording): http://codepad.org/d2ZvnZPS
5x zoom (recording): http://codepad.org/adF1c2nT
7.2 zoom (recording): http://codepad.org/J2ztFPvU
10x zoom (recording): http://codepad.org/KDZPDgsL

Should be able to see what changes with a diff.

I compared all with diffuse but I can't save the changes to a new file.

[1%]

*0x8A48, *0x8A54, *0x8A50, *0x8A4C - These control Dzoom Step

0x55b0 - table for image size and zoom I think. Called by un named subs from dzoom/waku/line skip functions

These set up encoder for dzoom:

*0x6268 = ret_CreateResLockEntry_FF1C85C4
*0x618C = arg0->off_0x10
*0x61A8 = arg0->off_0x14
*0x61C4 = arg0->off_0x18
*0x61E0 = arg0->off_0x1C
*0x61FC = arg0->off_0x20
*0x622C = arg0->off_0x24
*0x6230 = arg0->off_0x28
*0x6168 = arg0->off_0x34
*0x6170 = arg0->off_0x38
*0x616C = arg0->off_0x2C
*0x6174 = arg0->off_0x30
*0x6120 = 1
*0x6274 = arg1
*0x627C = arg2
*0x6284 = arg3

Line skip (and I think size?) registers are in :

NSTUB(0xFF1094D0, str:wCmosHskipStart_wCmosVskipStart)

i.e.
0xe3500805
0xe59f1edc
0xe51f164c
0xe51f1660


0xff1087b0: pointer to 0xe59f1edc
0xff109734: pointer to 0xe5980020
0xff109750: pointer to 0xe1d400b0
0xff1096f0: pointer to 0xe1a00003


0xff10b520: pointer to 0xe51f1634
0xff109640: pointer to 0xe2855001
0xff10964c: pointer to 0xe1d400b4
0xff1095e0: pointer to 0xe5980020

[a1ex]

I'm pretty sure HSKIP/VSKIP refer to the zoom box offset (you can move around the 5x zoom window quite smoothly). Maybe it can be useful for subject tracking while trying to manually focus it?

See also: http://magiclantern.wikia.com/wiki/Register_Map/60D#Digital_panning_.28moving_the_LiveView_box_around.29

[1%]

Going to keep looking and dump 0x8a and 0x55. Maybe I should do H.264 log while recording.. and manually pull out the digic log differences.

Other functions using dzoom:
NSTUB(0xFF2EC734, str:[XXX]_AngleAdjust_ImgX_SrcW_YYY_AspectNumerato)

NSTUB(0xFF1031C8, str:[GMT][WAKU]_LvMode_ImgW_WinW)
NSTUB(0xFF23E508, CalcAfFrameVramPosition)

Many unnamed subs like:
sub_FF568DC0
sub_FF56B7E8

Magic zoom? Or crop frame?
NSTUB(0xFF02FFA0, AJ_something_SetCroppingFrameLocation)

There is an unused crop VGA mode, I think.

NSTUB(0xFF1C845C, InitializeH264EncodeForCropVGA)

There is a regular VGA just like this.
NSTUB(0xFF1C83C0, InitializeH264EncodeForVGA)


Separate H264 settings for both 25(24?)P and 30P. All in the 0x6100/0x6200 area.