Magic Lantern Forum

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?

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.

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

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

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

G3gg0 way sounds the best.

Hahaha, I remember him from nokiafree

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

That would be compatible with both I guess.

Then we can record till CMOS burns out :)

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

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 :)

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.

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....

(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

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?

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.


    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:

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.

an alternative for finding the right addresses would be

0xFF04E88C void mvrAppendCheckSetRecLimit ( uint32_t max_bytes, uint32_t max_seconds)

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

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

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...

I thought it was just digic related stuff :)

will try tomorrow or tonight!

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 :(

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 :)

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  :D

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?

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... :(

for all cameras:

http://upload.g3gg0.de/pub_files/f23cf5caa18af51a912658eac3834ce4/autoexec.bin
(removed some of my bad-ass hacks in the startup code, so it is stock init code again ;) )

it will scan for the MovieRecorder object in memory and display the memory addresses it found in the top line.
in the second line you will see the maximum and current file size.
the file size will get patched for 16GiB limit. (0x3FFFFFFFF)

maybe it works for other models than 600D.

WARNING: Make sure you use exFAT filesystem.
Beware! Your files, your card or even your CAMERA may get damaged

(although i dont think your camera will take any damage)

How to make the EXFAT card to load ML, I can't make it bootable so far...
Ok, found maybe: http://www.zenoshrdlu.com/macboot/macboot.html

use this:
http://chdk.wikia.com/wiki/EOScard

Quote from: g3gg0 on August 05, 2012, 03:09:11 AM
use this:
http://chdk.wikia.com/wiki/EOScard

I'm on mac, but solved and about to update make_bootable.sh found this also: https://groups.google.com/d/msg/ml-devel/EWHU5ukyMt4/eAIeNAt9pl4J
it should be added to the source...

in the end used  macboot, now trying it.

EDIT:
recorded a 6Gb file, i can see it till 8:27 then image freeze but video is still played (no audio recorded)

I formatted my 8GB CF card as exFAT and made it bootable with EOS card but the camera does not recognize it as properly formatted.

Quote from: ilguercio on August 05, 2012, 06:11:11 AM
I formatted my 8GB CF card as exFAT and made it bootable with EOS card but the camera does not recognize it as properly formatted.

50D supports exfat?

Quote from: scrax on August 05, 2012, 06:40:25 AM
50D supports exfat?

I guess not :D
Recording limits are not my main concern but if there is a way to get around them, why not?
Have you had any success yet?
What if you disable sound? (just a thought)

Ok, I'm going to mess with it now. Finally have some time :)

I know this is not a wishlist, but if possible, a multi-file solution that works through modifying the file pointer would probably be a better solution considering many camera do not support exFAT.

Headers are likely incorrect. Decoding freezes in most players and tools because MOV and AVI containers seem to behave poorly with files over 4gb, esp as written. The actual stream data is fine and I can scrub it in avidemux. I'm trying to figure a way to save it without causing problems. In avi mode it splits it automatically but files are unplayable. In mp4 mode I have the same problem... but the data IS there and valid.

I cannot seek or go frame by frame (after 4gb) but if I scrub with the mouse it works and I can stop on any frame. The file doesn't seem to want to work sequentially.

Does the autoexec.bin above (reply 25) work with the 60D? If so, I'm willing to try it out.

He said all cameras and its the size of a unified so I assume so... .G3gg0 isn't using movie remap?

hi,

thanks for testing!
i hoped that the solution for the models with exFAT support would be just increasing the max size.
so we would have a clean solution for these cameras.
unfortunately we now face a MOV issue with 4GiB files. annoying :(

so the next step is to analyze the MovieRecorder object and file writing routines to find
a sane location where to add multi-file support.
this is more than just remapping file pointer to another file, since then we would end up with
the same problems as we have with exFAT now: MOV-container issues later when merging the files.

we actually have to clean up and close the file properly and then reopen the next movie file for writing.
this is more a MovRec StateObject issue.

I can't get anything to "fix" the file. I'll keep trying tho.

It's funny as I was just looking at a 5+Gb h264 .mov file the other day. Didn't have an issue playing it from memory. It was created by the compressor we have at work. So I guess 4+gb files are valid for QT.

I can't figure out how to record a longer video on a 60D. Card is formatted in exFAT and used EOScard to make it bootable. ML runs fine and I can see the text after clicking the 'Don't click me' button (before starting recording). However, I'm still getting the 'recording has been stopped automatically' error after around 13 minutes. Sound is also disabled.

Quote from: Malcolm Debono on August 06, 2012, 11:13:33 AM
I can't figure out how to record a longer video on a 60D. Card is formatted in exFAT and used EOScard to make it bootable. ML runs fine and I can see the text after clicking the 'Don't click me' button (before starting recording). However, I'm still getting the 'recording has been stopped automatically' error after around 13 minutes. Sound is also disabled.

how big was the file you recorded?

did the line show:
    max: 0x3FFFFFFFF cur: 0x000(counting up)
?

It did. Both files are 3.98gb

Edit: tried it again. Max is increasing while curr is staying the same.

Don't know if it's relevant, but I'm using a Sandisk 16gb card.

what is "cur" saying exactly?

It remains a bunch of zeros.

okay thanks, will update the demo firmware tonight,
i guess, we are just off a few bytes in the target structure.

Great. thanks :)

sorry, didnt have time tonight. will try this night.

no worries :)

Its not off on 600D is it? I guess I'll have to hex edit the files and see what happens at the break.

http://upload.g3gg0.de/pub_files/b9221309f4c40b3ee0e8db28515bebca/autoexec.bin

i added some autodetection.
can you 60D guys try? :)
thanks :)

Can someone upload a video file >4gb with the error?

Quote from: g3gg0 on August 07, 2012, 11:29:26 PM
http://upload.g3gg0.de/pub_files/b9221309f4c40b3ee0e8db28515bebca/autoexec.bin

i added some autodetection.
can you 60D guys try? :)
thanks :)

Thanks! Will try it now :)

Edit: Movie recording stopped automatically at curr: 00004B35000000000. The curr value is increasing now and max value stays the same (unlike previously). Clip is less than 13 minutes.

Edit 2: Tried again and still didn't manage to get longer recordings. Both clips are 3.98gb. I'm using a Sandisk 16gb formatted in exFAT. Is that right?

yes, thats correct.
hmm give me some minutes to think about it.

I tried the latest and recorded a 7.4gb file. I can confirm max stays the same and current changes as the camera writes.

Weird it doesn't work on 60D. I'm using a 32g class 10 card... I don't have a 16g to try. I haven't tried it on my fast card yet but I assume it will work the same.

Quote from: Malcolm Debono on August 08, 2012, 01:02:51 AM
Edit: Movie recording stopped automatically at curr: 00004B35000000000.

00004B35(hex) = 19253(dec)
19253 / 60 / 25 = 12min 50sec

true?
then this is not the file size, but the frame count :)

ok lets search for the file size. i will upload a new file tonight.

Figured out a little.

Normal movie ends like this:


73 6B 69 70 00 00 01 44 43 4E 44 42 46 5F 29 20 46 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 45 5F 29 20 44 5F 29 20 44 5F 29 20 44 5F 29 20 44 5F 29 20 44 5F 29 20 44 5F 29 20 44 5F 29 20 44 5F 29 20 44 5F 29 20 44 5F 29 20 44 5F 29 20



Long movie ends like:


73 6B 69 70 00 01 10 EC 43 4E 44 42 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 66 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 67 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 68 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 69 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6A 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18 6B 75 25 18



Latter is much longer and full of interesting ascii writings. Board limits kinda truncate the last one but you get the point.

Also I looked at 3.99 GB (4294967295 bytes). After it goes to FFFFFFFC it starts over from 00000012 in the hex editor.... BUT if I start scrubbing the offsets go back to normal... this mimics the sequential read and scrubbing behaviour....how do I fix this?

Could this have something to do with the 4GB quicktime limit?

QuoteThe co64 atom for a track lists the offsets for the various chunks that comprise a media track. These offsets are absolute offsets within the file starting from offset 0. Note that this atom allows for 64-bit offsets which is necessary for QuickTime files exceeding 4 gigabytes. Smaller files can save space in this table by using the stco atom which only allows for 32-bit offsets.

http://wiki.multimedia.cx/index.php?title=QuickTime_container#co64

and
https://developer.apple.com/quicktime/icefloe/dispatch022.html

This is very helpful... I need a mov atom display/editor. I have a feeling this is part of it. I saw some of the atoms in the file and now I know what "skip" means.

Maybe exiftool?
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/QuickTime.html#SampleTable
http://www.sno.phy.queensu.ca/~phil/exiftool/

thanks for the hint with exiftool.
hmm looking deeper into my file...

EXIFtool says MovieDataSize is 235351288(dec), 0x0E072CF8(hex).
looking into that file, i see "mdat" start at 0x30008
this means, mdat ends at 0x0E0A2D00 - but it ends at 0x10E0A2D00.

looking at the qt container structure, right before mdat i see a 0x0E072D00 hex value.
so the .mov container structure seems to be organized like:
[4 byte size header+data] [4 byte type] [n byte data]

and since the size is 32 bit, we already have an overflow there with payload > 4GiB.
so the .mov container the camera uses seems causing severe problems with large movies.

this explains why windows media player will fail to play more than a few seconds (maybe only 0x0E072D00 bytes)
still it doesnt explain, why vlc can play the video at all until it reaches the 4GiB mark.
i would expect that VLC honors the buggy - overflowed length field..

weird...
now... what?

from: http://multimedia.cx/mirror/qtff-2007-09-04.pdf

Extended Size
If the size field of an atom is set to 1, the type field is followed by a 64-bit extended size
field, which contains the actual size of the atom as a 64-bit unsigned integer. This is used when
the size of a media data atom exceeds 2^32 bytes.

and images show, if the size is 0, the section is as large as the file.
patched that, but still vlc cannot play :(

http://www.jongbel.com/download/AtomBoxStudio_Trial.msi

this tool is quite helpful for analyzing the structure

Thanks, I've been looking for solutions all day... seems there is now a cottage industry for "movie repair" which shares a lot with the spyware crew. I found a cycorder repair script that didn't work and some java atop repairer that I'm still trying to run (hate java).

I tried copying everything out of a good movie and combining it but the hex editor crashed. Seems offsets end at 3.99gb and if you sequentially read it doesn't acknowledge the new larger file size. If you start scrubbing and stopping it places the correct offset returns. I'll keep trying things. Saving the overflow on its own and adding a new header to it is something I'm gong to try.

Also what about stripping the stream out and putting on a new container with co64

if you need a 64 bit capable hex editor, use HxD

I have 3 boxen...

1. Laptop for dev Centrino/1.5gb ram
2. Main Pc for rendering with 16gb ram and all that fun stuff.
3. "HTPC" 2gb ram but x64

Box 2 is out today.


I was doing it on 1 in linux... I extracted the raw stream with that tool but I'm still having issues with it. I want to recontainerize it but avidemux can't recognize it now :( it is a .avc1 (or .avc?) file.

There are totally corrupted atoms:

Good: http://www.qfpost.com/file/d?g=LLdismoQi (http://www.qfpost.com/file/d?g=LLdismoQi)
Bad: http://www.qfpost.com/file/d?g=fPqFuiWiL (http://www.qfpost.com/file/d?g=fPqFuiWiL)


I think the lengths for the different atoms are simply wrong and thats why it looks like it has funny names. Mdat should extend all the way till skip in the end. Instead its cut into a couple of cunks and skip is ignored. I think this is related to the chunk table in one of the other atoms. I'll try to use the program (while I still can) and modify that.

thats because mdat is 0x000000011BE38A40 bytes long, but the length is saved as 0x1BE38A40.
the upper 32 bits are truncated. tried to modify the chunk length to 64 bit, but still i get white noise in vlc after 4GiB

and i am sure we have problem because of the sync entries or such things :)
we have to patch 'stco' to  'co64' atoms, adding the upper 32 bits on heuristics (overflow detection)


FF2C8404: 'stsz%s : AtomType[stsz]' FF2C8188
FF2C841C: 'movrAnalyzeStszAtom' FF2C81B4
FF2C8434: '%s : stsz Analyze Error(%#x)' FF2C822C
FF2C8454: 'stco%s : AtomType[stco]' FF2C8238
FF2C846C: '%s : stco Analyze Error(%#x)' FF2C8280
FF2C848C: '%s : Size Error(Total:%d)(Temp:%d)'


Is in firmware.

If you are on OSX and registered as a developer (it's free) there is a tool called Atom Inspector.

https://developer.apple.com/downloads/index.action?q=quicktime

Quote
Atom Inspector is a tool for viewing and editing atom resources in QuickTime movie and MP4 files. It provides functionality such as incremental atom search, atom specific data views and hexadecimal display mode. Atom Inspector requires a Mac running Mac OS X 10.5.7 or later.

Thats good because the trial on the windows app is only 7 days. If co64 functionality can be patched into sto or co64 is usable but hidden somehow then I think we can write good files the first time and have a clean solution.

i analysed the writer routines in camera.
its possible to extend the features, but only when we can use cache hacks (they cause yet unclear side effects on 60D)
and if we put a lot of patchwork into the firmware using that hacks.

or

we open, parse and fix the file after it was recorded.
plus we can combine that with a "merger" that would be necessary for cameras not supporting exFAT to join the seperated files.

g3gg0, sorry what do you mean by that? A non-exFAT camera could record long faulty files or would they record sequences of a broken file to be repaired in post?

task:
allow recordings >4GiB with all cameras

problems:
a) camera limits recording to 4GiB
b) FAT does not support files > 4GiB, some cameras support exFAT, some not
d) camera uses .mov with 32-bit tags only, which woll overflow and for sure cause trouble

solutions:
a) we can patch that "max length" field (success on 600D, others will follow)
b) we can either use exFAT or hook the writer routines to split the huge container into separate files (first works, second not yet)
c) we can patch camera firmware (a lot of work and very model-specific) or build a fixer that corrects the file afterwards (preferred)

Did some search on google and found this perl script, maybe it could help for patching the file?

QuoteUpdate (2012-02-18): Vladimir Ivanov has contributed an updated version of the script – it now handles 64-bit QuickTime files properly and can also extend 32-bit files to 64-bit if they grow above the limit because of the hidden container. There's also a new option to temporarily modify the hybrid file in a way that makes it possible to change the TrueCrypt password of the encrypted volume.

http://keyj.emphy.de/files/tcsteg2.py
http://keyj.emphy.de/real-steganography-with-truecrypt/

okay it seems just to do one part.

the .mov file has so called "atoms" which have a 4 byte size field in front of the field name.
that tool patches these size fields.
but we have to patch stco to co64 atoms. the script 'just' uses the atom that is required.
we have to fix stuff in the atoms.


i have one problem with patching container. tried to patch the size of 'mdat' to use 64 bit sizes.
that didnt work - the file could not be played back.
then i just made the section before (some filler) by 8 byte smaller  (the 64 bit length i added) and the file played.
so there might be an absolute reference into the mdat section somewhere, but didnt find anything :(
did you see anything that might be a absolute pointer into 'mdat'?

I agree the file repairer is much much faster. If one is made we're pretty much complete on 600d.


Did you look at the chunk offset table? That has a bunch of absolute addresses for the chunks and they are ~32bit

0x00000000000106CF stco <Size : 0x00000000000003B0> Chunk Offset Atom/Box
                             

yep.

the absolute addresses you see in the dumper, are not in the file. these are the adresses, the dumper uses.
only the lengths are in the atom structure.

edit: oh sorry, misunderstood your post.
true, thats the table we must patch.
but the offsets there are "from the start of mdat section", so they are no absolut file positions (at least the QT docs said that iirc)

So it still didn't play after you patched chunk table and mdat? When I tweaked mdat file size there were still 2 more "fake" mdats in the dumper. (i was trying to make it into 1) But I never patched the chunks.


My first chunk is at ~0x38008

my mdat is at 0x0000000000038000 mdat <Size : 0x000000001BE38A40> Movie Data Atom/Box

i just patched the size of mdat by setting size to 1 and adding 8 byte extended length.
video didnt play anymore.

stco positions are relative to mdat data payload start, so i dont have to patch them (except of 32->64 bit conversion).

Do the mdat sections from the corrupt file collapse into 1 in the atom dumper?

0x38008... with a 64bit size this start isn't affected? Or are all of these populated automatically?

Also, sync samples have a length in them and chunks have an address... the numbers seem to match up so each sync sample = 1 chunk except there is 1 less sync sample?


Sample-To-Chunk Table
                                          (      0) First Chunk :       1, Samples Per Chunk :       1, Sample Description ID :       1
                              0x000000000001198B stsz <Size : 0x00000000000110F8> Sample Size Atom/Box
                                   


                                          (      0) Sample Size :   99788
                                          (      1) Sample Size :   78896
                                   

                                          (  17463) Sample Size :  246228
                                          (  17464) Sample Size :  337912
                             

                                          (      0) Chunk Offset :  0x00038008
                                          (      1) Chunk Offset :  0x000505D4
                                          (  17462) Chunk Offset :  0x1BD900B0
                                          (  17463) Chunk Offset :  0x1BDE2074
                                          (  17464) Chunk Offset :  0x1BE1E248

Also... maybe the players don't understand large sizes for stco/mdat? Need to look at how a real 64bit mov file is laid out.

my wrong:

Note that offsets are file offsets, not the offset into any atom within the file (for example, a 'mdat'
atom). This permits referring to media data in files without any atom structure. However , be careful
when constructing a self-contained QuickTime file with its metadata (movie atom) at the front because
the size of the movie atom affects the chunk offsets to the media data.

the offsets ARE absolute. then the mdat patching problem makes sense.

If anybody has a over 4gb AVC/h.264 .mov that plays, installing the atom dumper and exporting the headers would help us.

I`m rendering one with 20 minutes, I`ll dump the header.

What can be done for cameras which don't support exFAT?

Quote from: g3gg0 on August 09, 2012, 10:47:00 AM
task:
allow recordings >4GiB with all cameras

problems:
a) camera limits recording to 4GiB
b) FAT does not support files > 4GiB, some cameras support exFAT, some not
d) camera uses .mov with 32-bit tags only, which woll overflow and for sure cause trouble

solutions:
a) we can patch that "max length" field (success on 600D, others will follow)
b) we can either use exFAT or hook the writer routines to split the huge container into separate files (first works, second not yet)
c) we can patch camera firmware (a lot of work and very model-specific) or build a fixer that corrects the file afterwards (preferred)

already explained

Ok, looks like you're trying your best. I wish you some success.

Ok here it is.

It is around 15 minutes with the size of 7.6 GB

I`m not a developer of any kind so this is educated guess.

From AtomBoxStudio I`ve exported structure

http://www.megafileupload.com/en/file/363853/Exported-Structure-zip.html (http://www.megafileupload.com/en/file/363853/Exported-Structure-zip.html)


And this is under Movie Header Atom/Box:
0x00000001E98DBDD0   74 00 00 00 00 00 05 21 93 6D 6F 6F 76 00 00 00   t......!.moov...
0x00000001E98DBDE0   6C 6D 76 68 64 00 00 00 00 CC 49 B6 84 CC 49 C6   lmvhd....ÌI¶.ÌIÆ
0x00000001E98DBDF0   B2 00 00 75 30 01 9D 60 78 00 01 00 00 01 00 00   ²..u0..`x.......
0x00000001E98DBE00   00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00   ................
0x00000001E98DBE10   00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00   ................
0x00000001E98DBE20   00 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00   .........@......
0x00000001E98DBE30   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x00000001E98DBE40   00 00 00 00 00 00 00 00 04 00 04 F7 48 74 72 61   ...........÷Htra
0x00000001E98DBE50   6B 00 00 00 5C 74 6B 68 64 00 00 00 0F CC 49 B6   k...\tkhd....ÌI¶
0x00000001E98DBE60   84 CC 49 C6 B2 00 00 00 01 00 00 00 00 01 9D 60   .ÌIƲ..........`
0x00000001E98DBE70   78 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   x...............
0x00000001E98DBE80   00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x00000001E98DBE90   00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x00000001E98DBEA0   00 40 00 00 00 07 80 00 00 04 38 00 00 00 00 00   [email protected].....
0x00000001E98DBEB0   18 6C 6F 61 64 00 00 00 00 00 00 00 00 00 00 00   .load...........
0x00000001E98DBEC0   00 00 00 01 00 00 00 00 24 65 64 74 73 00 00 00   ........$edts...
0x00000001E98DBED0   1C 65 6C 73 74 00 00 00 00 00 00 00 01 01 9D 60   .elst..........`
0x00000001E98DBEE0   78 00 00 00 00 00 01 00 00 00 00 00 14 74 72 65   x............tre
0x00000001E98DBEF0   66 00 00 00 0C 74 6D 63 64 00 00 00 03 00 04 F6   f....tmcd......ö
0x00000001E98DBF00   94 6D 64 69 61 00 00 00 20 6D 64 68 64 00 00 00   .mdia... mdhd...
0x00000001E98DBF10   00 CC 49 B6 84 CC 49 C6 B2 00 00 75 30 01 9D 60   .ÌI¶.ÌIƲ..u0..`
0x00000001E98DBF20   78 00 00 00 00 00 00 00 3A 68 64 6C 72 00 00 00   x.......:hdlr...
0x00000001E98DBF30   00 6D 68 6C 72 76 69 64 65 61 70 70 6C 00 00 00   .mhlrvideappl...
0x00000001E98DBF40   00 00 01 00 23 19 41 70 70 6C 65 20 56 69 64 65   ....#.Apple Vide
0x00000001E98DBF50   6F 20 4D 65 64 69 61 20 48 61 6E 64 6C 65 72 00   o Media Handler.
0x00000001E98DBF60   04 F6 32 6D 69 6E 66 00 00 00 14 76 6D 68 64 00   .ö2minf....vmhd.
0x00000001E98DBF70   00 00 01 00 40 80 00 80 00 80 00 00 00 00 39 68   [email protected]
0x00000001E98DBF80   64 6C 72 00 00 00 00 64 68 6C 72 61 6C 69 73 61   dlr....dhlralisa
0x00000001E98DBF90   70 70 6C 00 00 00 01 00 01 00 2E 18 41 70 70 6C   ppl.........Appl
0x00000001E98DBFA0   65 20 41 6C 69 61 73 20 44 61 74 61 20 48 61 6E   e Alias Data Han
0x00000001E98DBFB0   64 6C 65 72 00 00 00 24 64 69 6E 66 00 00 00 1C   dler...$dinf....
0x00000001E98DBFC0   64 72 65 66 00 00 00 00 00 00 00 01 00 00 00 0C   dref............
0x00000001E98DBFD0   61 6C 69 73 00 00 00 01 00 04 F5 B9 73 74 62 6C   alis......õ¹stbl
0x00000001E98DBFE0   00 00 00 B9 73 74 73 64 00 00 00 00 00 00 00 01   ...¹stsd........
0x00000001E98DBFF0   00 00 00 A9 61 76 63 31 00 00 00 00 00 00 00 01   ...©avc1........
0x00000001E98DC000   00 01 00 01 61 70 70 6C 00 00 00 00 00 00 04 00   ....appl........
0x00000001E98DC010   07 80 04 38 00 48 00 00 00 48 00 00 00 00 00 00   ...8.H...H......
0x00000001E98DC020   00 01 05 48 2E 32 36 34 00 00 00 00 00 00 00 00   ...H.264........
0x00000001E98DC030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x00000001E98DC040   00 00 00 18 FF FF 00 00 00 12 63 6F 6C 72 6E 63   ....ÿÿ....colrnc
0x00000001E98DC050   6C 63 00 01 00 01 00 01 00 00 00 10 70 61 73 70   lc..........pasp
0x00000001E98DC060   00 00 07 80 00 00 07 80 00 00 00 2D 61 76 63 43   ...........-avcC
0x00000001E98DC070   01 4D 40 33 FF 01 00 16 27 4D 40 33 A9 18 0F 00   .M@3ÿ...'M@3©...
0x00000001E98DC080   44 FC B8 03 50 10 10 1B 6C 2B 5E F7 C0 40 01 00   Dü¸.P...l+^÷À@..
0x00000001E98DC090   04 28 DE 09 C8 00 00 00 00 00 00 00 18 73 74 74   .(Þ.È........stt
0x00000001E98DC0A0   73 00 00 00 00 00 00 00 01 00 00 69 B8 00 00 03   s..........i¸...
0x00000001E98DC0B0   E9 00 00 00 1C 73 74 73 63 00 00 00 00 00 00 00   é....stsc.......

I hope I`ve dumped it ok, if not tell me how.

Cheerz

i am building a chunk fixer right now.

600D users who have files larger than 4GiB: try this!
http://upload.g3gg0.de/pub_files/6ed398407e34c3fb2b443923f6f9295e/EOSMovieFixer.exe

(updated)

linux/mac osx users: run it with mono. should work.

Good work, I. Don't have the 600d so can't try. How did you solve the patching?

Not running under wine. it just quits out. What about patch in place so you don't have to re-save? Too risky?


Also patch for ML so I can combine this with 600D audio. Although I have not tried running over 4gb with sound yet. So far 4.5gb and 5gb movies fixed perfectly. I need to try that 7gb movie next. Now I can record a ~64gb file :)

you do not need wine, use mono. its a .NET program.
didnt try, but its as simple as hello world. it will work for sure.

as explained above, patching flash routines would be possible but
a) highly model/version dependent
b) a lot of work
c) not clear if it will cause severe side effects

so i chose the "safe" way of fixing the file afterwards.

No, I mean patch the file in place instead of saving new copy. Or are you pretty much rewriting the file anyway when you make the addresses 64bit?

1. i am reading all atoms, their positions and the reference into source file.
2. if encountering a 'mdat' section, i try to find its end by adding 0x0100000000 (32 bit overflow bug)
3. then i read the 'stco' section content, extract the offsets relative to 'mdat' start. (original is absolute file position)
4. in the next step i patch 'stco' to 'co64' which contains 64 bit pointers
5. then i calculate the new size of all atoms
6. after that i update the newly created 'co64' section with pointers not relative to 'mdat', but the absolute file position
7. as last step the whole file is written to disk using the new atoms

so yes, i am rewriting the *whole* .mov file. not just patching some bits.

reason for rewriting:
canon kinda reserves the first 0x30000 bytes in the file for headers, pointers etc.
but i am not sure if it this is constant or if i can be sure that all models have that.

i could rely on that offset and try to patch the header contents only.
but the main work is reading/parsing/extending header atoms, and thats something i dont want to do in C.
i could do it in C, but that would be either ugly as hell or it would be really a lot of work.
nothing i would do for fun :)

so the solution to patch it later on computer is my favorite, because we can merge split files there too.
(other models without exFAT would require it anyway)

as the program is simplest .NET, it will run on linux/osx as well.
i am using windows forms (buttons, treeview and textbox) BinaryReader, BinaryWriter and Open/SaveFileDialog.
i do not expect that it wont work in mono ;) maybe the .NET version can be lowered, but i think mono can run .NET 3.x
can you try it?

I was missing a bunch of stuff from mono like the forms, it runs now. Its easy enough to fix the files after. The other part sounds like too much work. I wonder what sound will do, I have not tried a movie with audio, thats up tomorrow since its 320am here. Or did you patch for that already?

uuhm patching audio?
no need. everthing is getting fixed.
the file should be perfect afterwards. (and even smaller since i clean up the unnecessary atoms)

There was a separate atom for audio I believe.

I'm missing Open/SaveFileDialog. from mono, not sure which package its in.

Lulz, it pops under.


It was:

0x0000000000010B34 smhd <Size : 0x0000000000000010> Sound Media Information Header Atom/Box

and sowt data + its chunks.

well, audio is in 'mdat' atoms.
the pointers to audio/video should be both in 'stco' iirc and these are getting fixed.

I see. File saved successfully on linux. Is this possible to patch into ML or do you have to disable the startup hacks, etrc. I want to add it to my repo.

you want to patch what into ML?

I think there is two kind of patches that would be possible:

1. Patch the record function, so when you press rec the camera start with a new 64-bit .mov file from the beginning.

2. Make a new function in ML, that can patch 32-bit clips after you have recorded then like EOSMovieFixer.exe


I think 1% talks about 2 and you about 1 or?

Quote from: g3gg0 on August 10, 2012, 10:15:21 AM
i could rely on that offset and try to patch the header contents only.
but the main work is reading/parsing/extending header atoms, and thats something i dont want to do in C.
i could do it in C, but that would be either ugly as hell or it would be really a lot of work.
nothing i would do for fun :)
so the solution to patch it later on computer is my favorite, because we can merge split files there too.
(other models without exFAT would require it anyway)

Quote from: g3gg0
as explained above, patching flash routines would be possible but
a) highly model/version dependent
b) a lot of work
c) not clear if it will cause severe side effects

so i chose the "safe" way of fixing the file afterwards.

i see, i already explained why i prefer patching it afterwards and not 1) or 2).

we could do that in camera, but why do we want to do that pain in the ass?
so we can play back the whole file in camera? or that we dont have to prepare that files before we can use them on pc?
i think the small advantage of having that done automatically doesnt justify the effort at all.

my personal estimations in order of "cleanest process first":
- firmware patch so 64 bit movies are written: 4 weeks
- magic lantern feature that rewrites .mov: 2 weeks
- pc program that rewrites/patches/cleans .mov: 1 day (already done)

i would really stop here. we have a movie fixer and now just have to enable the firmware to record >4GiB.
we should save our resources for other things now.

Quoteenable the firmware to record >4GiB

Well I probably wasn't making any sense last night but what I meant is that I want to do this in my own repo so I have move remap, sound, etc and not just a bin that doesn't have these options. Its good the way it, just want to use it. :)

Quote from: g3gg0 on August 10, 2012, 04:15:37 PM

i would really stop here. we have a movie fixer and now just have to enable the firmware to record >4GiB.
we should save our resources for other things now.

Second that




What about seamless recording with fat32 only camera?

Quote from: g3gg0 on August 09, 2012, 10:47:00 AM
task:
allow recordings >4GiB with all cameras

problems:
a) camera limits recording to 4GiB
b) FAT does not support files > 4GiB, some cameras support exFAT, some not
d) camera uses .mov with 32-bit tags only, which woll overflow and for sure cause trouble

solutions:
a) we can patch that "max length" field (success on 600D, others will follow)
b) we can either use exFAT or hook the writer routines to split the huge container into separate files (first works, second not yet)
c) we can patch camera firmware (a lot of work and very model-specific) or build a fixer that corrects the file afterwards (preferred)

highlighted text, todo

Confirmed movies with audio record as they should and the patcher works with them.

*Also no issues with overheating so far on 20 minute movies. Haven't tried > 30 minutes yet.

nice.
thanks for testing.

Thanks for the effort. I obviously second the g3gg0's approach for <4gb files.
Can you do enable it for other cameras or should we wait for a1ex?

Tried adding this to bitrate.c and don't click me for good measure.

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


My movies still stop. I'm probably doing something wrong. At first it says 40 minutes record time then it goes down and down and down. Even if I run the function again while I'm recording (it just blanks for a second).

0x1E44

that was my wrong somewhere some posts ago

btw. some 30 minute limit may still be existent.
didnt check if this is a snapshot mode restriction only.

I'll try it out on 64g card when battery recharges. Still not working... should the function go in a different place. I notice that my bpm prints of the 2 locations disappear when I hit record. Maybe that has something to do with it.

* I got it to work manually but not automatically yet.



uint32_t autodetect_movierecorder()
{
    for(uint32_t addr = 0; addr < 0x01000000; addr += 4)
    {
        uint32_t *ptr = (uint32_t *)addr;
       
        /* first element pointer into flash? */
        if((ptr[0] & 0xFF000000) != 0xFF000000)
        {
            continue;
        }
        /* second element pointer into ram? */
        if((ptr[1] & 0xFF000000) != 0x00000000)
        {
            continue;
        }
        /* third element pointer into ram? */
        if((ptr[2] & 0xFF000000) != 0x00000000)
        {
            continue;
        }
       
        /* is it a pointer to "MovieRecorder" string? */
        if(strcmp("MovieRecorder", (const char *)ptr[0]))
        {
            continue;
        }
       
        /* check for StateObject and TaskClass */
        uint32_t *state_ptr = (uint32_t *)ptr[1];
        uint32_t *task_ptr = (uint32_t *)ptr[2];
       
        /* StateObject: first element pointer into flash? */
        if((state_ptr[0] & 0xFF000000) != 0xFF000000)
        {
            continue;
        }
       
        /* StateObject: is it a pointer to "MovieRecorder" string? */
        if(strcmp("StateObject", (const char *)state_ptr[0]))
        {
            continue;
        }
       
        /* TaskClass: first element pointer into flash? */
        if((task_ptr[0] & 0xFF000000) != 0xFF000000)
        {
            continue;
        }
       
        /* TaskClass: is it a pointer to "MovieRecorder" string? */
        if(strcmp("TaskClass", (const char *)task_ptr[0]))
        {
            continue;
        }
   
        return addr;
    }
   
    return 0;
}

uint32_t autodetect_movierecorder_ptr()
{
    uint32_t obj = autodetect_movierecorder();
   
    if(obj)
    {
        for(uint32_t addr = 0x1000; addr < 0x01000000; addr += 4)
        {
            uint32_t *ptr = (uint32_t *)addr;
           
            if(ptr[0] == obj)
            {
                return addr;
            }
        }
    }
    return 0;
}

uint32_t autodetect_movierecorder_maxsize_pos()
{
    uint32_t *obj = (uint32_t *)autodetect_movierecorder();
   
    if(obj)
    {
        for(uint32_t offset = 0; offset < 100; offset += 2)
        {
            if((obj[offset] == 0xFFFFFFFF) && (obj[offset+1] == 0))
            {
                return offset;
            }
        }
    }
    return 0;
}

void run_test()
{
    uint32_t objPtr = autodetect_movierecorder_ptr();
    uint32_t offsetMax = autodetect_movierecorder_maxsize_pos();
   
    if(objPtr && offsetMax)
    {
        uint32_t *movRec = *((uint32_t**)objPtr);
        uint32_t offsetCur = 74;
       
        /* set maximum to 0x3FFFFFFFF bytes (16GiB) */
        movRec[offsetMax+1] = 0x00000003;
        movRec[offsetMax] = 0xFFFFFFFF;
       
        if(offsetMax != 80)
        {
            offsetCur = 80;
        }
       
        while(1)
        {
            msleep(100);
            bmp_printf(FONT_SMALL, 10,40, "Object: 0x%08X  Ptr: 0x%08X  Off: %d", movRec, objPtr, offsetMax);
            bmp_printf(FONT_SMALL, 10,50, "max: %08X%08X cur:%08X%08X", movRec[offsetMax+1], movRec[offsetMax], movRec[offsetCur+1], movRec[offsetCur]);
        }     
    }
    else
    {
        uint32_t loops = 0;
        while(loops++ < 100)
        {
            msleep(50);
            bmp_printf(FONT_SMALL, 10,10, "Object/MaxPos not found");
        }
    }
    return;


Thanks, I think my problem is running the function when the rec button is pressed. I'm trying to throw it in shoot.c somewhere.

you have to run that function *before* recording!

I did it like this, have to test it out. I keep chewing through batteries for some reason.. I know debug info won't show up but shouldn't it run the function before pressing the rec button or am I being dumb?


Fixed and working in next commit: https://bitbucket.org/OtherOnePercent/tragic-lantern/changeset/af9112f96756facb50a5975dd710e300a01be797


https://bitbucket.org/OtherOnePercent/tragic-lantern/changeset/9fa9fd018aad20f97091b7019dad014afe1c2149

8)


*well... seemingly comes on only in remapped movie mode but that's ok for me.

how to use the file fixer on osx with mono?
installed mono and then:
mono /Users/scrax/Desktop/EOSMovieFixer.exe
opened an icon like for a new program but no window

Do you have everything installed that you need, windows forms, etc? I was missing tons of stuff and at first it didn't open, then things were missing, and now 100% when I run it from the command line. Just open dialog pops up under the main window.

Quote from: scrax on August 10, 2012, 11:14:11 PM
how to use the file fixer on osx with mono?
installed mono and then:
mono /Users/scrax/Desktop/EOSMovieFixer.exe
opened an icon like for a new program but no window

My was very slow on a 6 core macbook pro when I opened file dialog it was to slow. With my home computer with amd turion x2 with with windows 7 it was much faster. Try to wait :-*

Quote from: jonas18z on August 11, 2012, 04:29:55 AM
My was very slow on a 6 core macbook pro when I opened file dialog it was to slow. With my home computer with amd turion x2 with with windows 7 it was much faster. Try to wait :-*

jonas18z, have installed only the MonoFramework-MRE-2.10.9_11.macos10.xamarin.x86.dmg on Lion with x11? Thanks!
you were right... but so slow is not usable, there is needed more time to open mono than to do all the other stuff...

by the way off course on win it's faster, it's native...

I'm trying to test this workflow but having to install mono just for loading 24KB of converter is not really a good solution, I have no clue how and what but isn't there a more portable/crossplatform framework than .NET for this stuff?

Is the source to EOSMovieFixer publicly available?

not yet, but will be, i think.

Wasn't really any slower for me in linux. Strange that mono on osx is different.You might as well run a virtual machine instead. Not only for 1 20kb converter but for all of the other utilities that aren't cross platform.

Quote from: 1% on August 11, 2012, 04:59:08 PM
Wasn't really any slower for me in linux. Strange that mono on osx is different.You might as well run a virtual machine instead. Not only for 1 20kb converter but for all of the other utilities that aren't cross platform.

On linux x11 is default i think but on mac you have to load it up before starting to see the icon and the all other stuff, this is the first thing I think that could make differences in loading it.

virtual machine makes a really slower boot and I hate the idea of spending money for a faster os and then slowing it down with win. This  and avisynth (but last one has alternatives) are the only utility that don't works on osx for what I know since all other linux solutions are working also on osx. avisynth will run in wine, slowly like mono.

There is a  special developer package for Mac from mono that is supposed to "make an .app from an .exe", maybe that will result in a faster or at least not mono dependent patcher?

EDIT: I have that error in terminal when using mono with the patcher:

Aug 11 14:05:09 MacBookPro-di-tomare.local mono[2741] <Error>: kCGErrorInvalidConnection: CGSGetWindowTags: Invalid connection

Why would the emulator start at boot. My vmware stuff starts pretty fast and I can pause/restore it whenever. You don't have to bootcamp a real ver of windows.


Windows, linux, osx. I've run them all and they're about the same. Try the exe to app, its probably the easiest to get it native for the other people.

to be honest.
we are still in experimental phase and determining which method is the best and if it will work at all.
at the moment i really dont care about perfectness.
it will work for every user good enough.

next step is to test it for other models and then to enable 4GiB file splitting. ;)

It works very well right now on 600D exfat. Thanks!

Quote from: 1% on August 12, 2012, 04:24:47 AM
Why would the emulator start at boot. My vmware stuff starts pretty fast and I can pause/restore it whenever. You don't have to bootcamp a real ver of windows.


Windows, linux, osx. I've run them all and they're about the same. Try the exe to app, its probably the easiest to get it native for the other people.

maybe is just parallels that starts at boot? It needs to load all his kext and it's a lot of stuff for maybe even not using it in most of my session.
maybe I've used a wrong way to just ask for a script instead of an exe also in future when other things are mature, just  because i've passed 8 month converting silent pics with wine and with the script it's really more fun to use and automate (so way faster).

for the exe to app I think I'll try but source is need I suppose.

I wish I could use the scripts, they seem better but I edit media on a win box and I hack away on linux. So I have to combine hdr manually but for silent pics there is a really good program. Needs to be a better way to make everyone on all platforms happy for all the things ML does which need post/merging,etc.


*Below still works for me.

ok, update again.

http://upload.g3gg0.de/pub_files/a5e5655bdfa7454e8d970d2505aa0d47/autoexec.bin

can all camera users try what is being detected when pressing "dont click me"?
the exact values are not that important, i care more about if the 4GiB limit is disabled or if there is some error message.

thanks.

if this doesnt work on 60D, try this one (also working on all cameras) and tell about "f:1" or "f:0" being displayed

http://upload.g3gg0.de/pub_files/b1c16b181c80a6e8cbe823c70977a1a6/autoexec.bin

On 550D:

Object not found
Object: -- Ptr: 0x00001E70 Off: 0000

I'm still trying to find my card reader  :-\

@thba74:
thanks.
for the 550D it seems the maximum file size is 0xFF000000 (4080MiB).

also, the size_t type is 32 bits, so we cannot simply tell MovieRecorder to record longer and concentrate on splitting files. (or use exFAT as done with 600D)

i guess 550D user will have to stick to movie-restart. sorry.

Is max rec sec at 0x148? It is 7070h which is 28something in decimal.... or is it calculated from the file size? I tried changing it to a lower number to stop recording but it has not. I haven't tried recording over 30 minutes yet.


*I tried setting this offset to 70 but recording did not stop sooner. Instead it stopped right at 30 minutes.

on 600D its the size in seconds. 0x0707 which is 1799 seconds

I'll try higher values but why didn't it stop when I set it lower?

Or did I just set it to 1792 seconds because the ordering of the numbers is different?

Tried setting it with no luck (changed but limit remains), there must be a limit at another spot. Will keep looking.

On 50D
Object/MaxPos not found
Object: -- Ptr: 0x00001ED8  0ff: 0000

What's the response for the 50D?

So no prolonged recording for 550D ?  :-\

For older cameras it might not be this simple.

Quotethe size_t type is 32 bits, so we cannot simply tell MovieRecorder to record longer and concentrate on splitting files. (or use exFAT as done with 600D)

I tried doubling the limit, just changing 7 to F and limit still remains. I looked in the firmware and don't see any other spot for it.


DryosDebugMsg(BYTE((unk_R4->off_0x4)->off_0xC), 22, 'MVR_APPENDCHECK_30MINOVER', HALFWORD(unk_SP->off_0x8))


unk_SP->off_0x8

Also see this: delay_allocate_maybe((aAJ_0x1EEC_MovieRecorderPtr_struct_0x00_0x04_taskName.off_0x4 /*0x1E44*/)->off_0x8


Is this possible 2nd location for 30 minute limit? Just current rec time?


off topic but I also found this:

NSTUB(0xFF04E9E4, mvrSetBitRate)

div_maybe(0x100000*BYTE(*(arg0)), 8*(aAJ_0x1EEC_MovieRecorderPtr_struct_0x00_0x04_taskName.off_0x4 /*0x1E44*/)->off_0x1E4) => ret_div_maybe_FF04EA00
(aAJ_0x1EEC_MovieRecorderPtr_struct_0x00_0x04_taskName.off_0x4 /*0x1E44*/)->off_0x3A8 = ret_div_maybe_FF04EA00

Also functions to dump a single YUV frame (is this silent pic or not used before?).

Just for the information

Both the 5D mark III and 650D/T4i have a native solution. Here is a quote from manual:

QuoteEven if you shoot a movie exceeding 4GB, you can keep shooting without interruption. Approx 30sec. before the movie reaches the 4GB file size, the elapsed shooting time or time code displayed in the movie-shooting image will start blinking. If you keep shooting the movie and the file size exceeds 4 GB, a new movie file will be created automatically and the elapsed shooting time or time code will stop blinking. When you play back the movie, you will have to play the individual movie files. Movie files cannot play back consecutively automatically. After the movie playback ends, selec the next movie to play.

Oh and the maximum record time is of course 29min and 59sec.

Quote from: 1% on August 17, 2012, 10:08:52 PM
I tried doubling the limit, just changing 7 to F and limit still remains. I looked in the firmware and don't see any other spot for it.

DryosDebugMsg(BYTE((unk_R4->off_0x4)->off_0xC), 22, 'MVR_APPENDCHECK_30MINOVER', HALFWORD(unk_SP->off_0x8))

MVR_APPENDCHECK_30MINOVER is the check for clip mode, not for normal recording.

you tried to double what limit on which camera and which limit do you still hit?

600D. I tried to double 0x148 by changing the 7's to E's but if MVR_APPENDCHECK_30MINOVER is for a different mode than that explains it. 30 minute is the only limit I hit... and probably 16gb but that is expected.

Also, what are you using to disassemble? Private tool? I don't see this part in alex's arm console:

ROM:FF04E5EC 00 00 E0 E3                 MOV     R0, 0xFFFFFFFF <<<<

I get:

FF04E5EC:   e3e00000    mvn   r0, #0

I wanted to look for maxrecsec value elsewhere but its no use if not all values are shown.

i am using IDA pro.




#if 1
    uint32_t objPtr = autodetect_movierecorder_ptr();
    uint32_t offsetMax = autodetect_movierecorder_maxsize_pos();
    uint32_t offsetMaxFailed = 0;
   
   
    if(!offsetMax)
    {
        offsetMaxFailed = 1;
#ifdef CONFIG_60D
        offsetMax = 76;
#endif   
    }
   
    if(objPtr && offsetMax)
    {
        uint32_t *movRec = *((uint32_t**)objPtr);
        uint32_t offsetCur = offsetMax - 0x06;
       
        /* set maximum to 0x3FFFFFFFF bytes (16GiB) and time to 180 minutes */
        movRec[offsetMax+2] = 180*60 - 1;
        movRec[offsetMax+1] = 0x00000003;
        movRec[offsetMax] = 0xFFFFFFFF;
       
        while(1)
        {
            msleep(100);
            bmp_printf(FONT_SMALL, 10,40, "Object: 0x%08X  Ptr: 0x%08X  Off: %04X  f: %d", movRec, objPtr, offsetMax, offsetMaxFailed);
            bmp_printf(FONT_SMALL, 10,50, "max: %08X%08X cur:%08X%08X", movRec[offsetMax+1], movRec[offsetMax], movRec[offsetCur+1], movRec[offsetCur]);
        }
    }
    else
    {
        uint32_t loops = 0;
        while(loops++ < 100)
        {
            msleep(50);
            bmp_printf(FONT_SMALL, 10,10, "Object/MaxPos not found");
            bmp_printf(FONT_SMALL, 10,20, "Object: --  Ptr: 0x%08X  Off: %04X", objPtr, offsetMax);
        }
    }
#endif



Thanks! Will test.

Even with limit time properly set, the camera still stops at 30 minutes. :(

I made a 60D bin here:

https://bitbucket.org/OtherOnePercent/tragic-lantern/downloads/autoexec.bin.exfat.60D

Hopefully those guys have better luck today.

will check the 60D firmware these days. i made that patch for 600D, but didnt test 30 minute limit yet ;)

I already tried e's, F's and properly written integer like you put. When I drop the time down the recording doesn't stop sooner. Can't find any other spot where the limit would be. I recorded black so the camera is not overheating nor crossing 4gb.

Given that SD video (640x480) can record for longer (especially recording black), I guess there is a kill switch in there somewhere for that EU regulation.

Howdy.  I have a 60D and I'm specifically interested in the >4GB movie feature.  Would whoever tried this on the 60D before please let me know if it worked, and share the build?

—John

A question about accepting the 4GB video limit and the possibility of seamless recording stop and start - do you guys think that PicoC could be used to create a script that would start a new file in the background at a preset limit; say 12 or 13min, and then continue recording? Or would it be too much to run the video record and script at the same time?

Thanks

There is one piece of encoder hardware and one LV buffer. Its already seamless over 4gb, new cameras just cut it up afterwards... was kind of disappointing.

Ah, so let me see if I understand this (I'm trying to educate myself) - is it the fact of the single encoder and buffer that causes ML to lose a couple of seconds in between stop/start?

And I'm not sure I get the idea of "new cameras just cut it up afterwards"...would you mind a bit of explanation?

Thanks

You lose the seconds when the dat is being turned into a file you can play. You see a flurry of write activity after you press stop... this is what's happening. You can't just start another file in the background, the encoder has to be reinitialized to know where to write, etc.

New cameras split up the movie and convert it at the end. They're a little quicker so the gap is less. Someone with DigicIV timecode should measure the gap vs digicV.

The only way to be truly seamless would be to break the 30 minute limit and keep writing to the same file.

I'm definitely starting to get it now - thanks for the explanation, that was quite helpful. I appreciate you taking the time.

I have a 60D - how can I measure the gap? I'll certainly make the attempt if it would be at all helpful.

Try recording a digital stopwatch.  Like this maybe.  http://www.online-stopwatch.com/

That makes sense - for some reason I thought it would be something more involved -  :P

Thanks

2 clips at 1920, 24fps, 1/47, default bit rate. I started the timer several seconds in; last frame of first clip was at 12:11.58, the first frame of the second clip was at 12:13.00. So, 1.42 seconds on DIGIC 4.

Gotta test on digic V but wow... its only ~2 seconds.

Quote from: PKVariance on March 15, 2013, 07:17:49 PM
2 clips at 1920, 24fps, 1/47, default bit rate. I started the timer several seconds in; last frame of first clip was at 12:11.58, the first frame of the second clip was at 12:13.00. So, 1.42 seconds on DIGIC 4.

I beleve ( oldo I am only awake for 10 min ) that I spotted a calculation error
13:00 - 11:58. = 01:02 seconds. And not 01:42. Or was it a typo?

Quote from: blade on March 16, 2013, 08:39:45 AM
I beleve ( oldo I am only awake for 10 min ) that I spotted a calculation error
13:00 - 11:58. = 01:02 seconds. And not 01:42. Or was it a typo?

There is 100 msec in 1 sec. Not 60.

My bad!!!  Thanx

Quote from: 1% on March 16, 2013, 04:23:22 AM
Gotta test on digic V but wow... its only ~2 seconds.

That was my reaction as well - just for fun , I timed the stop/restart method of pressing the record button twice during filming and can't get much better than around 5 seconds. One of the many reasons to love ML...

Where are we at with the 600D and recording longer than 12 minutes or 4 GB?  It seems like we still don't have a stable release?  I read the first two pages and the last one.  My church is looking to purchase a dslr in a particular price range (used t3i price range) but my pastor wants to be able to safely and soundly record for longer than 12 or 4GB.  Any help is much appreciated.  I personally have a 650D but I'm really shooting for this one listing on ebay for a t3i with a shoulder rig.

Quote from: InFocusAV on April 24, 2013, 12:53:22 AM
I personally have a 650D but I'm really shooting for this one listing on ebay for a t3i with a shoulder rig.

For real, you can record up to 30 mins even without ML if you have DIGIC V camera. 650D is DIGIC V. It will split video automatically in 4 GB parts.

With this topic's ML you can record up to 30 min in one file without splitting on 600D.

Quote from: Rush on April 24, 2013, 01:01:16 AM
For real, you can record up to 30 mins even without ML if you have DIGIC V camera. 650D is DIGIC V. It will split video automatically in 4 GB parts.

With this topic's ML you can record up to 30 min in one file without splitting on 600D.

How easy is the transfer to the computer?  My church edits with iMovie (I know...) so I might have to convert the files for them but I'm dealing with volunteers that don't know much. Do I have to format my sd card for exfat?

600D:
Record with hacks, trasfer to SD card, rewrite movie with eosmoviefixer

650D:
Transfer to Sd card.. much easier. Benefit to the 600D is audio controls and crop mode. Things that probably don't matter to volunteers at a church.

Quote from: 1% on April 24, 2013, 03:03:55 AM
600D:
Record with hacks, trasfer to SD card, rewrite movie with eosmoviefixer

650D:
Transfer to Sd card.. much easier. Benefit to the 600D is audio controls and crop mode. Things that probably don't matter to volunteers at a church.

Define "hacks." Also, is eosmoviefixer a free program or can I just throw all clips on a timeline and put them back to back?  How are the audio controls on the 600D better than on the 650D? Thank you for the help.

My builds had the "over 4gb" hack. G3gg0 made the program to fix the movies so they would play back. You rewrite them and THEN they go in the time-line.

600D has audio monitoring and full IC control. 650D is still brand new ML territory.

Quote from: 1% on April 24, 2013, 03:48:04 AM
My builds had the "over 4gb" hack. G3gg0 made the program to fix the movies so they would play back. You rewrite them and THEN they go in the time-line.

600D has audio monitoring and full IC control. 650D is still brand new ML territory.

How long does it take to "rewrite them" in this program.  The simpler the better.  IC? I cant wait for ML on the 650D for audio monitoring but I thought you were referring to stock attributes.  I'm really leery of getting the t3i because I have to be able to train everyone on DSLR shooting AND ML which I'm not extremely keen on and don't know the buttons and quick keys for it.  Money's always a problem.

I guess as fast as your hard drive writes.

Stock 650D will cut the 30minute clip into 4gb sections without any processing.

I tried http://photography-on-the.net/forum/showthread.php?t=1232870 on my 600d and it works.
I tried with Nightly's but no go. Can it be included. Or did I do something wrong.

Yea, its not in the nightly.

1%,

I know it wasn't included back when  you last posted in this thread but is it included now with the latest nightlys or should I install your newmem.zip build over top of the current nightly? (600d)

Should still be in the TL repo for 600D. I don't think it ever went in the nighties.