Topics

So i booted back into win7, yay, now my right hand doesn't burn anymore from the thinkpad GPU..

It was easy so far:
1. Install Mingw + Msys from the installer
2. Install python, add a copy named python2.exe
3. Add zip from http://gnuwin32.sourceforge.net/ and put it in c:\mingw\bin
4. Add paths for python, mingw, msys to windows paths
5. Download pre built arm toolchain and throw it in a path with no spaces
6. Set path in makefile.user

So now I can make -C and all that fun stuff... but what to do about truncate? its missing. I don't want to install bulky ass cygwin.

So call works fine like this:

call("somename", parameter);

But what if I don't have the name or want to call by address? Is it possible to find it or feed call a pointer with the address?

I ask because I can call on the 7D master but its by name, arg1 is a pointer but all canon examples use it like call. I know its defined in ML with a const char as the first argument, when I tried feeding a pointer to it, didn't seem to work.

Komputerbay is telling me that 64gb cards should work with exfat on 7D. In my experience its not working and telling me to reformat the card.

To bootflag the camera I used the booton/bootoff first... they are from a previous firmware version and are huge for an installer. I also remember exfat support being broken at some point a long time ago in ML.

Anyone remember why and what the fix was? One of the perks of this camera is that it supports files > 4gb. If the installer is breaking support a new one has to be made and the damage undone.... Exfat strings ARE in the firmware. I assumed it only worked for 128gb cards but I have no such card and no way to test.

What are your experiences.

So far on 6D

No HDMI

Idle : dc3100
Real: d43100

HDMI 1080 returns the same.

From the log:

LVx1_GetVramParam(W:1620 H:1080)[ff0c0fd4]LVx1_GetVramParam(W:1620 H:1080)[ff0c0fd4]
SetBitmapVramAddress BitmapAddr:0x40d3c008
SetBitmapVramAddress BitmapAddr:0x40dbc008

Investigating EOSM, I found the datasheet matches the AK4950 more or less like 650D.

Datasheet: http://www.qfpost.com/file/d?g=EzOHAZuIw

Audio IC read/write is a bit different now, not sure how to use it. I took some logs and tried a bit.
There is i2c_read, i2c_write and locali2c_read/write

NSTUB(0xFF339490, i2c_write)

#NSTUB(0xFF3463F8, i2c_read) //"normal" write
NSTUB(0xFF346230, i2c_read) // "local" write

The normal one just calls the former and reading reg 00, which is the power reg returns 390... but only to DM log.. if I try int something = local_i2c_write(0x00) I get a big fat 0 and 390 in the dm log.

The commands also change like this.


From the log:
PowerMicAmp
I2C > [2c] 14
localI2C_Write : 301
I2C_Write retry 2c 1 89

So writing 14 to 2C somehow becomes 301 and the retry command doesn't make sense to me either. There are some wrappers for read/write too but they haven't produced much better results.

:PEOSM produces the most coherent logs so a good target for analysis, 650D probably too... 6D is more obfuscated.

SetAudioALCVolumeIn
I2C > [02] 08
I2C done 1
I2C > [20] cd

SetFilterRecOn - bunch of EQs
I2C > [83] 0f 7e 29
I2C > [84] f0 81 d8
I2C > [86] 0e fc 53
I2C > [89] 09 97 5f
I2C > [8a] 09 97 5f
I2C > [8c] fc d1 42
I2C > [8f] 01 b1 d2
I2C > [90] 01 b1 d2
I2C > [91] 00 00 00
I2C > [92] 09 3c d4
I2C > [93] 00 00 00
I2C > [99] 11 93 19
I2C > [9a] f5 da 73
I2C > [9b] 00 00 00
I2C > [9c] 0c 46 f9
I2C > [9d] 00 00 00
I2C > [a0] 10 34 a9
I2C > [a1] e1 5f a3
I2C > [a2] 0e f7 19
I2C > [a3] 1e a0 5e
I2C > [a4] f0 d4 3f
I2C > [a5] 1e a0 5f

Random commands... so 83 = 390?
I2C > [0b] 07
I2C > [2c] 17
I2C > [2d] 09
I2C > [2e] 0e
I2C done 39
I2C > [00] 83
I2C done 1

locali2c_read makes while recording:
localI2C_Read : 390
localI2C_Read : 364

So 5d3 seems to be the only DigicV that can do FPS override without updating from EVF state. I limited timer A to fix banding like 5D3 and it seems to have gone down/gone away. However shooting dark stuff at higher ISO last night I noticed massive amounts of stuck pixels in the shadows.

My theory is that when timer B is at one value for extended periods of time this is the result. Canon is constantly flipping it "naturally" so perhaps this is necessary for the sensor. A possible fix could be flipping timer b +/- some tiny value from update to update. Would this screw up overall frame rate? Thoughts?

Raw zebras are going nuts on 600D in movie mode... made worse with a fully manual lens.

Underexpo zebras have a bunch of boxes that show up on screen... in zoom mode only underexposed zebras show up and don't redraw as often. Zoomed out the overexpo zebaras have problems like the underexposed ones. In photo mode they seem OK.

Some videos:

I think TG_FREQ_NTSC_SHUTTER might be wrong on some digic V. Where do I find this? Copying 5d3 for 6D seemed to give better shutter speeds but still didn't seem correct.

So recently found a problem with 6D not starting voice tags in QR mode. I fixed it by doing the unpress event instead of the press event.

I though I was in the clear but on 600D the same problem shows up. I fixed it by using event 4C... then it turned out the zoom shortcut also stopped working.

Seems recent changes to GUI handling did something where its missing events. When I turn on event viewer I see all of them but for some reason ML gui isn't responding.

I pulled latest 600D nightly to see if it was my issue and its not. Zoom shortcut is dead there too. Also booting nightly I got 100MB shoot malloc.. so 4MB is still gone but seems like there is a discrepancy here too.

Ok, so I've discovered we don't need the debugmsg hack for the bottom bar.

EOS_M
UNAVI_FEEDBACK_TIMER_ACTIVE (MEM(0x5D858) == 0x2)

6D
UNAVI_FEEDBACK_TIMER_ACTIVE (MEM(0x8418c) == 0x2)

Look around that DebugMsg locaton near all of the 0x17 values and you'll see an int that goes 1 or 3 when in LV but 2 when you hold h/s and bottom bar is displayed. You will find the value for remaining 2 cameras.


Its pretty reliable... then we can just move the Mem(location) = 0 to where its currently running HideUnaviFeedbackTimer.

BTW: ALL of those functions are wrong. That location is always 0x17 and running this function does nothing.

Need to find the function that creates/draws the bar in the first place (and probably changes this value). There is probably another location you can set to 0. I have been unsuccessful at cache hacking anything around there... the bar still displays, nothing hides. Also metering is seperate and redraws when exposure changes over both 6D and EOS M... even with the previous debugmesg.

The setting of the location to 0 kills it but I guess an update to metering resets that 0 again. So any ideas where the bar is actually spawned?

I got most things on new 113 working with 6D.

I've noticed a slight problem with focus box auto-hide. When display filter is enabled the box never hides. Something keeps resetting the afframe countdown and calling afframe_set_dirty().

When filter is off the box auto hides but the spot meter keeps getting redrawn and hidden. I notice when the mem browser is up it slows down a bit.

Would this be the product of a missing const or stub? Any hints?

So I got this bright (or dumb) idea to set digic registers for H264 directly. Right now I can alter the memory locations and the parameters get set.... But I think syncing with evf_state per frame and just writing the registers might be a faster way to do it and result in better videos.

Most of the registers appear readable, hopefully in real time. Getting them at each frame might let me avoid patching so many canon functions and this might apply to the other digicIV cameras.


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

Code Select Expand


c0e10000:      102
c0e1000c:     8090
c0e10024:  452a0a8
c0e1002c:     4000
c0e10040:      600
c0e10050:      900
c0e10060:        5
c0e10080:   440078
c0e100b0:     24f4
c0e100c0:  1280142
c0e100d0:    1001a
c0e100e0:   750007
c0e100fc:      200
c0e10800:  8000100
c0e10804:  8400100
c0e10808:  8800100
c0e1080c:  8a00100
c0e10824:  51ba5b0
c0e10924:  51f4c98
c0e10928:   88d340
c0e1092c:   8be400

c0e14000:      102
c0e1400c:     8090
c0e14024:  561d67c
c0e1402c:     4000
c0e14040:      600
c0e14050:      900
c0e14060:        5
c0e14080:   440078
c0e140b0:     2598
c0e140c0:  1280142
c0e140d0:    1001a
c0e140e0:   750005
c0e140fc:     2200
c0e14800:  8000100
c0e14804:  8400100
c0e14808:  8800100
c0e1480c:  8a00100
c0e14824:  5c46f80
c0e14924:  5cf353c
c0e14928:   88d340
c0e1492c:   8be400

c0e18000:      300
c0e1800c:     8090
c0e18024:  60d4500
c0e1802c:     4000
c0e18040:      600
c0e18060:        5
c0e18080:   440078
c0e180b0:     255b
c0e180c0:  1280142
c0e180d0:    1001a
c0e180e0:   750007
c0e180fc:      200
c0e18800:  8000100
c0e18804:  8400100
c0e18808:  8800100
c0e1880c:  8a00100
c0e18824:  6766934
c0e18924:  6766934
c0e18928:   88d340
c0e1892c:   8be400

c0e1c000:      102
c0e1c00c:     a090
c0e1c024:  6856674
c0e1c02c:     4000
c0e1c040:      600
c0e1c060:        5
c0e1c080:   440 078
c0e1c0b0:     2528
c0e1c0c0:  1280142
c0e1c0d0:    1001a
c0e1c0e0:   750005 <- SLice
c0e1c0fc:      200
c0e1c800:  8000100
c0e1c804:  8400100
c0e1c808:  8800100
c0e1c80c:  8a00100
c0e1c824:  70d4b60
c0e1c924:  70d4b60
c0e1c928:   88d340
c0e1c92c:   8be400



This is  a stock dump.. seems each family is for a different mode (or frame type?). Will have to deduce which goes with which. Slice register is readable so should see it flipping about while recording.

So I did some digic poking, disappointed I still can't figure out what's crashing tether.

Found a couple of interesting things:

FPS override isn't calculating the timer A right. I can get very low fps (less than .2fps) without lines at least for a little bit. I can also crank it up to 60fps in 1080p but after 34 the image collapses. Timer B IS changeable.. it just gets reset right away. It lets you push fps further, both lower and higher.

Image effects are around c0f078XX... much weird stuff in there. Including one register that stretches out the image, almost like crop mode.

Code Select Expand



C0f0 787c - freeze lv - can swap YUV but img frozen
c0f0 7804 - Subtract to stretch image and change U/V
7884 - Color skips, can make blue DOF lines fucks with color, can pixelate, make purple
     7888 - horiz lines
     7814 - Change colors all crazy
     7824 - Magentas and greens
     782c - reds value was 100000
     7838 - Make everything purple.. .actually can pick red/other colors
c0f0 6008 - super low FPS .2 something - timer A, calculations wrong?
600C - same but for different mode I think
     6014 - Low FPS keeps getting reset Timer B
     6020 - Make everything flash like HDR video


So image effects on digicV do exist, just I'm not sure what does what yet.

The resizing effect

http://youtu.be/Q5D8JcgHJck


Tiles?

http://youtu.be/3h8C9Pn_nRg

c0f1 a01C - Looks like heat camera value = F

Initially shoot_malloc seemed to work fine.

I had an error in the card test and I fixed it like this:

Code Select Expand


    if (bufsize > 1024*1024) bmp_printf(FONT_MED, x, y += font_med.height, "read test skipped: buffer=%d\n", bufsize);
    else
    {
        //void* buf = alloc_dma_memory(bufsize);
void* buf = shoot_malloc(bufsize);
       


Worked fine for a while... I did r/w tests on my cards. Today I got a new UHS card:




Someone else is complaining about formatting also throwing a shoot malloc error.

Code Select Expand

"estart your camera (shoot_malloc err)." :R

But shoot_malloc passes the stubs test and it seemed to work not too long ago.

Code Select Expand


[Pass] p = alloc_dma_memory(256*1024) => 0x4089a8dc
[Pass] UNCACHEABLE(p) => 0x4089a8dc
[Pass] CACHEABLE(p) => 0x89a8dc
[Pass] UNCACHEABLE(CACHEABLE(p)) => 0x4089a8dc
       free_dma_memory(p)
[Pass] p = (void*)shoot_malloc(24*1024*1024) => 0x427bc074
[Pass] UNCACHEABLE(p) => 0x427bc074
       shoot_free(p)
       m11 = MALLOC_FREE_MEMORY => 0x6f640
       m12 = GetFreeMemForAllocateMemory() => 0x2f4e0c


Only fails on date... which doesn't seem related.

Code Select Expand



[FAIL] ABS(mod(t1-t0, 1048576)/1000 - 250) => 0x2c
       LoadCalendarFromRTC( &now )
       s0 = now.tm_sec => 0x1e
       Date/time: 2013/03/08 18:27:30
       msleep(1500)
       LoadCalendarFromRTC( &now )
       s1 = now.tm_sec => 0x1f


The stop now waits for an event from the DMA? I don't quite get how beep does the asif stop calls.

Start
[ASIF] asifAIntDmaDac(0x104)

Stop?

[ASIF] asifAIntDmaDac(0x101)


Asif stops, good and bad:

Code Select Expand


SetVolumeOut : Volume(3)
[ACTRL] _ACTRL_SetAudioParam [2](3,0,0)
[ACTRL] actrlASetPlayParam : 2
[ACTRL]  [S]Vol : (3)
[ACTRL] actrlEventDispatch : (ST=0, EV=0, P=0x5a1034)
[ACTRL] _ACTRL_SetAudioParam : Wait FuncSync
[ASIF] StartASIFDMADAC
[ASIF] asifAStartDmaDac
[ASIF] asifEventDispatch : (ST=1, EV=1, P=0x5a1034)
[ASIF] StartASIFDMADAC : Wait FuncSync
[ASIF] StartASIFDMADAC END
[ASIF] _DmaDAIntHandler
[ASIF] asifAIntDmaDac(0x104)
[ASIF] asifAIntDmaDac : Zero Blk Done
[ASIF] asifEventDispatch : (ST=1, EV=0, P=0x104)


[ASIF] _DmaDAIntHandler
[ASIF] asifAIntDmaDac(0x101)
[ASIF] asifAIntDmaDac : All Blk Done
[ASIF] StopASIFDMADAC
[ASIF] StopASIFDMADAC : Wait FuncSync

[ASIF] StopASIFDMADAC :  EV_STOP_DMA_DAC (time out)
[ASIF] StopASIFDMADAC Err END
[ASIF] asifEventDispatch : (ST=1, EV=0, P=0x101)
[ASIF] asifAStopDmaDac
[ASIF] asifEventDispatch : (ST=0, EV=2, P=0xd087e8)


SetVolumeOut : Volume(3)
[ACTRL] _ACTRL_SetAudioParam [2](3,0,0)
[ACTRL] actrlASetPlayParam : 2
[ACTRL]  [S]Vol : (3)
[ACTRL] actrlEventDispatch : (ST=0, EV=0, P=0xc8793c)
[ACTRL] _ACTRL_SetAudioParam : Wait FuncSync
[ASIF] StartASIFDMADAC
[ASIF] asifAStartDmaDac
[ASIF] asifEventDispatch : (ST=1, EV=1, P=0xc8793c)
[ASIF] StartASIFDMADAC : Wait FuncSync
[ASIF] StartASIFDMADAC END
[ASIF] _DmaDAIntHandler
[ASIF] asifAIntDmaDac(0x104)
[ASIF] asifAIntDmaDac : Zero Blk Done
[ASIF] asifEventDispatch : (ST=1, EV=0, P=0x104)


[ASIF] _DmaDAIntHandler
[ASIF] asifAIntDmaDac(0x101)
[ASIF] asifAIntDmaDac : All Blk Done
[ASIF] StopASIFDMADAC
[ASIF] StopASIFDMADAC : Wait FuncSync

[ASIF] StopASIFDMADAC :  EV_STOP_DMA_DAC (time out)
[ASIF] StopASIFDMADAC Err END
[ASIF] asifEventDispatch : (ST=1, EV=0, P=0x101)
[ASIF] asifAStopDmaDac
[ASIF] asifEventDispatch : (ST=0, EV=2, P=0xd087e8)
[ASIF] asifAFuncIgnore : Give FuncSync
[ASIF] asifEventDispatch : (ST=0, EV=2, P=0xd087e8)
[ASIF] StopASIFDMADAC END

SetVolumeOut : Volume(3)
[ACTRL] _ACTRL_SetAudioParam [2](3,0,0)
[ACTRL] actrlASetPlayParam : 2
[ACTRL]  [S]Vol : (3)
[ACTRL] actrlEventDispatch : (ST=0, EV=0, P=0xc8793c)
[ACTRL] _ACTRL_SetAudioParam : Wait FuncSync
[ASIF] StartASIFDMADAC
[ASIF] asifAStartDmaDac
[ASIF] asifEventDispatch : (ST=1, EV=1, P=0xc8793c)
[ASIF] StartASIFDMADAC : Wait FuncSync
[ASIF] StartASIFDMADAC END
[ASIF] _DmaDAIntHandler
[ASIF] asifAIntDmaDac(0x104)
[ASIF] asifAIntDmaDac : Zero Blk Done
[ASIF] asifEventDispatch : (ST=1, EV=0, P=0x104)

[ASIF] _DmaDAIntHandler
[ASIF] asifAIntDmaDac(0x101)
[ASIF] asifAIntDmaDac : All Blk Done
[ASIF] StopASIFDMADAC
[ASIF] StopASIFDMADAC : Wait FuncSync



I've been trying to fix the high res silent pics but have a few Qs.

In consts.h

Real Sensor res:
#define SENSOR_RES_X 5472
#define SENSOR_RES_Y 3648

5x zoom buffer size is size is 1104x736 so multiplied by 5
#define SENSOR_RES_X 5520
#define SENSOR_RES_Y 3680

But from printing afframe[2], afframe [3] coordinates for center in regular lv and "x1" zoom mode are 2460 x 1456
In 5x mode this changes to 2184x1456
In 10x its 2640x1648

So I set it by the formula of center *2 for 5x mode
#define SENSOR_RES_X 4368
#define SENSOR_RES_Y 2912

Is this correct?

Also notice that when AF is off vs on the lowest X you can move to changes. In 5x it starts at 24, in 1x its 0.
The Y is weird, its 285 in x1 mode and 301 in x5 mode.

So when I change

    int x0 = (SENSOR_RES_X - NC * 1104) / 2;
    int y0 = (SENSOR_RES_Y - NL * 736) / 2;

do I have to subtract these values? to get correct 0,0? I can get the pics lined up with the 5x sensor res but they repeat the first line and move over a column.

From playing with it more, it seems a math problem. The size doesn't want to divide evenly by 5 and not sure if the LV buffer size matches with coordinates in the zoom box.

I think the above line sets the start point and then it moves in the loop below it.

[Transform8x8Flag = 2]

So I figured out some stuff about H.264 INI. bitrate.c 5d3/6D will have to be different. Had a start from what was discussed in the I/P thread.

The file:

Code Select Expand



Transform8x8Flag = 2
Profile = 100
Level = 51
BitRate = 110000000
EntropyCodingMode = 1
IntraPicInitQP = 5
InterPicInitQP = 5
QpOffsetForB = 0
MinQpI = 1
MinQpP = 1
MinQpB = 1
MaxQpI = 13
MaxQpP = 13
MaxQpB = 13
MinBitrate = 60000000
MaxBitrate = 110000000
SarWidth = 0
SarHeight = 0
AspectRatioIdc = 1
VideoFmtAndVspFlag = 81
VideoFullRangeFlag = 1
TimingInfoPresentFlag = 0
RateControlEnable = 1
ScalingMatrices = 0
pScalingMatrixAddr[0] = 0
pScalingMatrixAddr[1] = 0
pScalingMatrixAddr[2] = 0
pScalingMatrixAddr[3] = 0
pScalingMatrixAddr[4] = 0
pScalingMatrixAddr[5] = 0



Transform8x8Flag = 2 Transform flag. Already set to enabled.
Profile = 100 Cannot be changed. Camera has no other profiles loaded.
Level = 51 Can change this lower. 50 is all I've tried so far. But why?
BitRate = 110000000 Target bit rate for CBR/Rate Control. Adhered to for CBR more. Loosly in RC. Max is ~200-300
EntropyCodingMode = 1 1 is CABAC 0 is CAVLC
IntraPicInitQP = 5 Initial QP for inter and intra frames. Limit of 7 for "rate control" mode.
InterPicInitQP = 5 But a limit of 1 for CBR/VBR... haven't tried 0. MUCH better than any digic IV.
QpOffsetForB = 0 Have not tried but probably QP offset for B frames. I guess can be lower or higher than I.
MinQpI = 1 Min QPs for all modes. Can be 7 in RC, can be at least 1 in the other modes. Not strictly adhered
MinQpP = 1 to for VBR and CBR it seems. There can only be 13 QPs in any mode. 7-20 or 1-13 are a start.
MinQpB = 1
MaxQpI = 13  Max QP for modes that switch QP like VBR and RC. RC will only do 6-20 I believe. VBR will do
MaxQpP = 13 1-13 which seems best.
MaxQpB = 13
MinBitrate = 60000000 Min and Max for the VBR function. Don't do anything in other modes but I think max
MaxBitrate = 110000000 has to match target bit rate or you will get a crash.

RateControlEnable = 1

0= CBR - Stays at initQP and tries to get to the target bit rate. Should change QPs but really doesn't in any consistent way. Can use all QPs. 0 should be tried. Drops video when buffer or complexity is too high. Will record with audio and won't stop until sync is lost, which is real reason why audio stops w/ high bit rate, not buffer.

1 = VBR - Uses Min/Max and I think target. Also seems to switch QPs to keep rate in check. Initial QP can't be 1 I think or it won't switch. I set 5 and it hovered around 2, using 1-13 range. If you have settings too high, camera may freeze. I like this mode the best so far.

2 = Standard buffer saving function like tragic lantern but slightly faster and more stoppy. This is what you get by default but we have no good access to the MVR config. I think its on another proc. Will keep BR pretty low and can only use QPs 7-20. I should try with 1-13 again. It kicks in at the 1st buffer square now but still has a tendency to stop. Should have emphasized buffer and not frame size/prediction, tsk tsk.

ScalingMatrices = 0 Need to test this as I think it means you can put custom scaling matrixes to the encoder. The other fields are for address so I guess you load them into memory and then it uses them. Finding how this works would give a big boost to quality according to what I've read.


Other stuff:

Loading the INI can produce a lot of Err70s. Some of these should be patched I think. Some are from settings being incorrect. Sometimes it does it just because it feels like it. A good idea is to wait till the config finishes loading and the text is off the screen.

Another option will be to set the params 1 at a time from memory and not a file. This would make things a bunch easier. The only other solution is to auto-load configs or edit the files with ML and then make the camera reload them.
Having to load the config every start and hope it doesn't error 70 is a pain.

On 6D params are uploaded:
NSTUB(0xFF1F130C, str:ChangeIVAParam_ls_can_open._Transform8x8Flag_P)

Maybe there are others hidden somewhere or we can gain control of the video encoder. The future looks promising. The present is at least 100MBps with LOW qps and audio working.

RateControl will use 1-13, the crash happens if you let it use more than 13 qps.

Code Select Expand



average DRF                 7.200181
standard deviation          5.679766
max DRF                     13
                           
DRF=1                       219 ( 19.837 %) ####
DRF=2                       337 ( 30.525 %) ######
DRF=3                         0 (  0.000 %)
DRF=4                         1 (  0.091 %)
DRF=5                         2 (  0.181 %)
DRF=6                         2 (  0.181 %)
DRF=7                         2 (  0.181 %)
DRF=8                         1 (  0.091 %)
DRF=9                         1 (  0.091 %)
DRF=10                        1 (  0.091 %)
DRF=11                        2 (  0.181 %)
DRF=12                        1 (  0.091 %)
DRF=13                      535 ( 48.460 %) ##########
DRF>13                        0 (  0.000 %)
                           
I-slices average DRF        7.200181
I-slices std. deviation     5.679766
I-slices max DRF            13


You can build from source and look for bugs. Taking off the pitch did not fix it. Its like FS buffer address is off.

Threw my commits in here:

https://bitbucket.org/OtherOnePercent/tragic-lantern-6d/commits/all

You can copy into ML repository whatever is good.

I tried to use my built flash recently and it would not fire even though it was raised and the flash icon was on. Any changes that messed with flash recently (i.e. flash tweaks)?

Also AF stuck in "quick mode" on P, AV,TV, etc. - 3rd party flash in LV does this.

All shoot.c related? It might have dumped a log.

Hmm.. doesn't fire with magic off either... I see black mark on flash, did the bulb die?

Ok, I found the picq toggler and enabled it.

On 600D: MRAW is reported as 7776x1296. Says 10MP Plays back fine in camera and so far in FS viewer. 11-19MB
SRAW - 2592x1728 reported size. 8-12MB a pop. Plays back OK... actually has the icon when pressing info in the player.

Lightroom shows no love... trying gimp/UFRAW next.

Canon Pic selection is pink and all funky but who cares. So far no ill effects.

Ok, sraw converts just fine but MRAW says there is data corruption... probably size is set incorrectly and UFRAW doesn't let you change that. The image is there but all screwed up like bad magic zoom because of incorrect dimensions.

There is a separate LVREC and ENCO on 600D.

NSTUB(0xFF10D1D0, str:[LVREC]MVR_[LVREC]GMT_MVR)


NSTUB(0xFF10D464, str:Gmt\GmtMovieState.c_[GMT][LVREC]_gmtRecStart)
NSTUB(0xFF10D758, str:[GMT][LVREC]_gmtEncodeStopMotion)

Seems separate from the MVR. Does it make the LV image? Separate recorder/encoder of some sort? PTP?

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?

The new task changes seemed to speed up fine detail peaking for me.

What about canon tasks? I see priority and # of canon tasks is pretty high but some seem useless like face detection, etc.

Can any of the canon tasks be killed or re-prioritized?

So  I've had stereo wav enable for a while now like this:

Code Select Expand


SetSamplingRate(48000, 6);
  MEM(0xC092011C) = 6; //SetASIFADCModeInterleaveINT16

    // 1 = mono uint8
    // 3 = stereo uint8
    // 4 = mono int16
    // 6 = stereo int16
    // => bit 2 = 16bit, bit 1 = stereo, bit 0 = 8bit


I really like the separate wav function but working on the sync and testing further I notice that I get strange dropouts which cause distortion or stutters every once in a while. Like a chunk was lost or mis-timed.

The dropouts look like this:



A clearer one (look in the middle):




And sound like this:

http://www.qfpost.com/file/d?g=sWMNfOzgH

Any ideas on what is happening? Does it come from buffer/write/etc?

I've tried making the buffer bigger

Code Select Expand

#define QBUF_SIZE 8

But it doesn't seem to help. Any ideas on how to try and fix this?

The vram menu is messed up on the 600D. The fonts were set really small which isn't a problem with scrolling, I think I can fix that. The problem is that when I change the settings I can't see anything, usually set is what makes a menu transparent and in this case it does not. The changes revert before I can see what they do.

I wanted to fix full screen magic zoom for crop mode. I assume tweaking the parameters would help to see what is wrong, pitch, LV address, etc.

Since 4:2:2 is still off and could be shaky. A feature request gave me an idea.

Can we set 1080P (or others) mode to encode at actual LV buffer size and save all of the bits being wasted from resizing? I know JPcore is configured for specific modes but I think this is just for sensor area/line skip and quality. RequestH264 encode is called with a fixed size but has other parameters.

How do I hijack this function and replace 1920x1080 with real LV size while still passing the other parameters? Wouldn't crop 1700x1000 or whathaveyou be better at 100mbps than 1080P at the same?

Ok from my reading of FW and understanding this is what I gather.

600D can use:

CF Cards? - Driver components are there, I think HW is not.
SD Cards - Over DMA and SDIO (I think for eyefi cards, otherwise "CERES" in FW
USB - Called "HDD" in firmware and intertwined with PTP. Seems to imply can treat USB as storage


SD:
NSTUB(0xFF4F6D98, SD_ReConfiguration_0)

DMA mode has a few speeds officially:

Set Hi-Speed Mode( 24MHz )
Set Hi-Speed Mode( 48MHz )

Also can SD_SetBusWidth

There is also an MMC mode probably for slower access.

Set MMC Mode( 48MHz )'
'Set MMC Mode( 16MHz )'
'Set MMC Mode( 24MHz )'

And MMC_Set_Bus_Width


Are fast cards using 48mhz, highest bus width?
Can clock be raised for UHS cards (at least to full 50mhz) since in theory they would keep up. Can USB be used as storage, is PTP the bottleneck or the interface?


------
Ok, more info:

Mode is picked here:

Code Select Expand


if NE((sd_device.off_0x34 /*0x15780*/ & 0x2)):
        DryosDebugMsg(0x23, 0x3, 'Set Hi-Speed Mode( 48MHz )', sd_device.off_0x34 /*0x15780*/) => ret_DryosDebugMsg_FF4F6E48
        AJ_guess_SD_related_Storage_wait(0x1, 0x3) => ret_AJ_guess_SD_related_Storage_wait_FF4F6E6C
    if EQ((sd_device.off_0x34 /*0x15780*/ & 0x2)):
        DryosDebugMsg(0x23, 0x3, 'Set Hi-Speed Mode( 24MHz )', sd_device.off_0x34 /*0x15780*/) => ret_DryosDebugMsg_FF4F6E60
        AJ_guess_SD_related_Storage_wait(0x1, 0x2) => ret_AJ_guess_SD_related_Storage_wait_FF4F6E6C



But if you look at how that function is called:

Code Select Expand



AJ_SDCom_related__Storage_wait+24: AJ_guess_SD_related_Storage_wait(arg0, arg0)
ResetCard_maybe+56: AJ_guess_SD_related_Storage_wait(1, 0)
SD_ReConfiguration_0+212: AJ_guess_SD_related_Storage_wait(1, 2)
SD_ReConfiguration_0+648: AJ_guess_SD_related_Storage_wait(1, 2)
str:8MHz_eCreate_4MHz_WIDTH_4BIT_WIDTH_1BIT+528: AJ_guess_SD_related_Storage_wait(1, 2)
str:8MHz_eCreate_4MHz_WIDTH_4BIT_WIDTH_1BIT+632: AJ_guess_SD_related_Storage_wait(1, 1)
str:8MHz_eCreate_4MHz_WIDTH_4BIT_WIDTH_1BIT+948: AJ_guess_SD_related_Storage_wait(1, 1)
str:8MHz_eCreate_4MHz_WIDTH_4BIT_WIDTH_1BIT+992: AJ_guess_SD_related_Storage_wait(1, 2)
str:8MHz_eCreate_4MHz_WIDTH_4BIT_WIDTH_1BIT+1196: AJ_guess_SD_related_Storage_wait(1, 2)
str:8MHz_eCreate_4MHz_WIDTH_4BIT_WIDTH_1BIT+1240: AJ_guess_SD_related_Storage_wait(1, 1)


AJ_guess_SD_related_Storage_wait(1, 3) never appears and SDCOM is related to SDIO. How can I check mode being used?

----

Tried calling: AJ_guess_SD_related_Storage_wait(0x1, 0x3);

Did not affect speed test but sd card flashes when this command is run.

Running AJ_guess_SD_related_Storage_wait(0x1, 0x1);

Buffer fills sooner.

Running
Running AJ_guess_SD_related_Storage_wait(0x1, 0x6);

128K buffer write speed goes up to 11.1MB however. from 10.2 and its reproduceable.

From the register map:

Code Select Expand


0xC0400004 [32]  Clock selection
                   Bitmask
                   0x03000000 SD/MMC clock selection bits
                      0 unknown
                      1 16MHz
                      2 24MHz
                      3 48MHz

0xC0400008 [32]  Clock control
                   Bitmask - configures which module gets system clock
                   0x00000002 Engio LCLK
                   0x00000004 (ASIF related too)
                   0x00000008 SD/MMC clock 1
                   0x00000100 Display PWM module
                   0x00000400 Timer #0
                   0x00000800 Timer #1
                   0x00001000 Timer #2
                   0x00200000 SIO clock
                   0x01000000 DMA module #0 (fIPCClk)
                   0x02000000 ASIF
                   0x10000000 SD/MMC clock 2


Both of these registers read as 0 for me on digic poke.

I've tried setting deblocking filter through the canon functions but its a crapshoot. Sometimes it changes, sometimes it says invalid value. Sometimes it says nothing at all. Logging Jpcore is difficult because the log is flooded with engine writes (good for figuring out encoder, I guess?).

Values for the filter are -6 to 6.

The 2 functions do this:
NSTUB(0xFF1E3228, str:[JPCORE]_DBFALPHA_DBFBETA)

aAJ_JpcoreSliceqpdD_Qscale_0x00_to_0x20.off_0x1 /*0x6CE1*/ = BYTE((arg0 & 0xF)) -Alpha
aAJ_JpcoreSliceqpdD_Qscale_0x00_to_0x20.off_0x2 /*0x6CE2*/ = BYTE((arg1 & 0xF)) -Beta

and

NSTUB(0xFF1C94E0, mvrSetDeblockingFilter)
str:[JPCORE]_DBFALPHA_DBFBETA(BYTE(*(arg0)), BYTE(arg0->off_0x4)) => ret_str:[JPCORE]_DBFALPHA_DBFBETA_FF1C9514 - Setting B from A + something?




I've used mvrSetDeblockingFilter and got these results. Some B values aren't valid and the function sets something else like B to 1 or 7, etc.

How do I compute this from the signed integers so I can skip calling functions?

Code Select Expand


Deblocking Filter:

A=-6   1800752394  6B554D0A
B=-6   175118849   A701A01

A=-5   1800752395 6B554D0B
B=-6   1918960965 72610545

a=-4   1880752396 701A010C
b=-6   208673281  C701A01

a=0 1880752384 701A0100
b=0 7346689    701A01

a=6 1880752390 701A0106
b=6 108009985  6701A01

a=3 1880752387  701A0103
b=3 57678337    3701A01

-3 1703949    1A000D
-3 218110464  D001A00


Which one to get?

By arc style stabilizer I mean this:

http://www.ebay.com/itm/KAMERAR-Steadicam-Video-Stabilizer-for-DSLR-Mirrorless-Camera-Camcorders-DSLRs-/120909897563?pt=LH_DefaultDomain_0&hash=item1c26ca9f5b

Flycam:

http://www.amazon.com/Flycam-Nano-Quick-Release-Camcorders/dp/B005IMAEHY/ref=sr_1_3?ie=UTF8&qid=1345350202&sr=8-3&keywords=flycam+nano

JPCORE is fairly interesting but not many have looked at it yet.

Seems to have configs at 0x6CE0... is this like a new MVR config?
Does it control qscale? Related to both pics and video...

; 0xff1e2404: pointer to 0x6CE0 (aAJ_JpcoreSliceqpdD_Qscale_0x00_to_0x20)

NSTUB(0xFF1E2B3C, AJ_setup_JpcoreSliceqpdD_Qscale_in_struct)


NSTUB(0xFF1E32A0, AJ_struct_0xC0E10000)

NSTUB(0xFF1E3768, AJ_struct_0x8FB8_p2)

NSTUB(0xFF1E3A78, AJ_JPCORECMP)

Only for photos or do we have 4:2:2 already, untapped?

NSTUB(0xFF1E3BC0, AJ_JPCORE_SetEncodeYuv422LosslessParam)
NSTUB(0xFF1E3AE8, SetEncodeLosslessParam)

All paramaters in here?

NSTUB(0xFF1E3310, AJ_JPCORE_SetEncodeH264Parameter)


Maybe GH2 can be beaten after all?


Jpcore H.264 Parameters:

; *'[JPCORE] SetEncodeH264Parameter 0 %d,%d,%d'
; *'[JPCORE] JP62_SIZER %#lx'
   ?
FF1E3568:   e28f2f47    add   r2, pc, #284   ; *'[JPCORE] JP62_SEQCR1 %#lx'
*'[JPCORE] JP62_PICCR1 %#lx'
*'[JPCORE] JP62_MISCR %#lx'
*'[JPCORE] H264_SPS_PPS JP62_OPMR3 %#lx'
; *'[JPCORE] JP62_SLCR1 %#lx'
*'[JPCORE] JP62_SLCR2 %#lx'


More: ff1e2000.htm

This is controlling the hardware encoder, is it not?

Jpcore is also present on other cameras and CHDK has been changing things in it.

Being a crappy programmer I'm not sure how to handle this.

NSTUB(0xFF04E88C, str:Max_FileSize_dMBytes_RecSec)

FF04F6D4:   e24f2ed5    sub   r2, pc, #3408   ; *'Max FileSize = %dMBytes(0x%08x - 0x%08x) : '

FF04F938:   e28f2070    add   r2, pc, #112   ; *'MVR_APPENDCHECK_4GBYTEOVER

FF04F968:   e28f205c    add   r2, pc, #92   ; *'MVR_APPENDCHECK_30MINOVER'

FF04F3C0:   e28f00e4    add   r0, pc, #228   ; *'mvrAppendCheckSetRecLimit'

FF04F3CC:   e28f00f8    add   r0, pc, #248   ; *'mvrAppendCheckValid'
FF04F3D8:   e28f0f41    add   r0, pc, #260   ; *'mvrAppendCheckInValid'

NSTUB(0xFF04F5E0, str:Recoding_dMBytes_VideoSnapTime_MVR_APPENDCHECK)

FF04F768:   e28f2f5f    add   r2, pc, #380   ; *'MVR_APPENDCHECK_NOTVIDEOSNAP'


How do I force append checks to be valid and skip limits?

So I formatted my SDHC to exFat via win7. So far so good and performance seems a tiny bit improved.

What I'm wondering is if there is any truth to the SD format utility and them saying that built in format is wrong and will cause performance loss? All I notice is that allocation size is 32kb on both Fat32 and exFat but windows default is something else. I kept it 32kb. No lost performance that I can see.

Does the SD formatter do ANYTHING else? Will camera internally format SDHC as fat32? I know the SD utility does and won't let you pick exFat.

What are your experiences?

Also if you stream join 2 4gb MOV files will the built in player play the whole thing? I can only stream cut to AVI or MP4 so I haven't been able to try it.