Limits be gone.

[1%]

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?

[a1ex]

Sounds like this can work by patching Canon code somehow.

The hard way: examples in boot-hack.c and liveview.c (by finding a pointer to some Canon function, and changing that one to a relocated version of Canon code - which is patched). Only possible for functions called via pointers.

The easy way: g3gg0 has  a bleeding edge hack for this - it works by altering instruction and data cache, so you can patch a small number of ROM addresses. I'll try to understand how to use it and figure out.

[Michael Zöller]

Been waiting for you to try your hands on these... Veeeery interesting...

[nanomad]

Keep in mind that bypassing the 4G limit on FAT32 leads to baad things

[1%]

Forget fat32, format your cards to exfat. Seems faster anyway.

G3gg0 way sounds the best.

Hahaha, I remember him from nokiafree

[a1ex]

I'd rather try to mangle the file pointer and create a new file when the 4 GB limit is reached.

[1%]

That would be compatible with both I guess.

Then we can record till CMOS burns out

[3pointedit]

CMOS burnout? Need liquid cooling like astrophotographers   Continous recording for the win.

[g3gg0]

i would recommend this method:

1) hook the check function
2) when coming near the 4GB limit, signal some ML thread to open another file (async in low prio task)
3) when hitting 4GB limit, use the file handle ML created and continue writing there
4) tell ML the old file handle and ask to close that file (again async in low prio task)

that would enable seamless video recording without any loss. in theory

[1%]

Would opening another file cause the recording to stop if the card can't keep up?

For me to try this is going to require a bit of learning.

[nanomad]

I don't think so, opening a file uses virtually no CPU and I hope Canon allows a fair amount of file handlers to be open at the same time....

[g3gg0]

(tried to send this message some days ago, but the forum told me, i would spam )

i looked at the code you found, but its just the code that checks if appending is possible.
also i dont think that "just continuing" writing will work. i bet, you get files of size 0+ after 4GB.
copying to PC will for sure make problems.

will look into this in spare time again.

br,
g3gg0

[1%]

I would think the exfat routines are different than fat32 so there would be no hard coded limit as it is not in the exfat spec and FS is different.

Maybe write a function to correct file size after movie recording is finished?

[g3gg0]

first progress here on 600D. (although not working fully)
you have to format card in exFAT format.
if you use FAT, the file will definitely be truncated to zero.

Code Select Expand


    uint32_t *movRec = *((uint32_t**)0x1E40);
   
    /* set maximum to 0x3FFFFFFFF bytes (16GiB) */
    movRec[80] = 0x00000003;
    movRec[81] = 0xFFFFFFFF;


this increases the recording limit to 16GiB, but after 4GiB the file only gives a white noise and no video anymore in VLC.
already late, dont have time to find the reason right now. maybe its VLC, because in hex editor the file doesnt look corrupted.
not sure. maybe i am wrong.

initialized here:

Code Select Expand


str_MVR_Initialize
...
ROM:FF04E5EC 00 00 E0 E3                 MOV     R0, 0xFFFFFFFF  ; set maximum size
ROM:FF04E5F0 10 70 84 E5                 STR     R7, [R4,#0x10]
ROM:FF04E5F4 40 01 84 E5                 STR     R0, [R4,#0x140] ; lower 32 bits
ROM:FF04E5F8 00 50 A0 E3                 MOV     R5, #0
ROM:FF04E5FC 02 0C 84 E2                 ADD     R0, R4, #0x200
ROM:FF04E600 44 51 84 E5                 STR     R5, [R4,#0x144] ; upper 32 bits


any 600D user with proper toolchain wants to try?
http://upload.g3gg0.de/pub_files/774d811f625071bfbd66d7d7f1e71e93/autoexec.bin
click "dont click me" while recording.

[g3gg0]

an alternative for finding the right addresses would be

0xFF04E88C void mvrAppendCheckSetRecLimit ( uint32_t max_bytes, uint32_t max_seconds)

[g3gg0]

i updated the file for 600D in post above as it didnt work clean:

http://upload.g3gg0.de/pub_files/774d811f625071bfbd66d7d7f1e71e93/autoexec.bin

now just press "dont click me" and *then* you can start recording..

top bar shows:
R0: (upper 32 bit max size) R1: (lower 32 bit max size) R2: (upper 32 bit current size) R3: (lower 32 bit current size)

can anyone try if the 4GiB file limit is still true?
bitrate viewer at least shows no errors, but a clean, constant bit rate.
VLC still fails to play beyond 4GiB

[ilguercio]

What about other players?
Can you build something for 50D as well so i can try?

[g3gg0]

unfortunately i dont have 50D firmware, nor did i ananlyze it.

well, tried with windows media, it aborted after some seconds.
adobe premiere elements simply hangs when i just add the 4.2GiB file to the project...

[ilguercio]

I thought it was just digic related stuff

[Alia5]

will try tomorrow or tonight!

[3pointedit]

although AVI related this thread suggests tyhat it is a corrupt header that may be at fault?
http://www.avidemux.org/smf/index.php?topic=8810.0
I guess the format just isn't designed to accomodate the extra length. Perhaps the camera insists on files with a 4gb chunksize? Perhaps there would be a way to modify the header in post? I doubt that the camera would be able to play sucha  file back either

[g3gg0]

it really seems to be a quicktime 4GiB problem.
but cannot find details about the exact header structure, why this is a problem and what we can do about.

anyone can help?

edit: this seems to be a quicktime MPEG-2 playback component issue.
but as i tried VLC, i doubt its the same reason..

so i still home that someone with proper video editing tools will be so kind to look at such a file

[Malcolm Debono]

Do you have any build that I can try out on a 60D? I believe that would be faster than transferring a file greater than 4gb 

[g3gg0]

tried with avidemux and it fails also. simply cannot seek behind 4GiB mark.

hmm i dont have any decoded firmware files for 60D here.
5D / 5DII / 5DIII / 7D / 550D / 600D thats all i have atm.

anyone else has IDA and the decrypted firmware files?

[Michael Zöller]

I'd love to help, but I just returned a 550d I did some tests on, so only my 5d2 here. I wanted to try but I just did some tests and I'm afraid the 5d2 does not support exFAT...