Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - g3gg0

#2826
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 08:02:12 PM


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;
#2827
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 07:40:08 PM
btw. some 30 minute limit may still be existent.
didnt check if this is a snapshot mode restriction only.
#2828
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 07:35:46 PM
0x1E44

that was my wrong somewhere some posts ago
#2829
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 07:09:28 PM
nice.
thanks for testing.
#2830
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 06:05:27 PM
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
#2831
that works reliable without any dropout yet.
#2832
General Help Q&A / Re: What means "dont click me" ?
August 10, 2012, 04:19:50 PM
you can call it "random, undocumented feature or nothing at all, depending on what the developer who compiled the file coded into that test function"-menu ;)
#2833
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 04:15:37 PM
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.
#2834
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 01:36:32 PM
you want to patch what into ML?
#2835
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 10:45:04 AM
well, audio is in 'mdat' atoms.
the pointers to audio/video should be both in 'stco' iirc and these are getting fixed.
#2836
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 10:26:40 AM
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)
#2837
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 10:15:21 AM
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?
#2838
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 10:07:19 AM
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.
#2839
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 09:41:31 AM
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.
#2840
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 12:59:15 AM
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.
#2841
Tragic Lantern / Re: Limits be gone.
August 10, 2012, 12:34:52 AM
i am building a chunk fixer right now.
#2842
Tragic Lantern / Re: Limits be gone.
August 09, 2012, 09:10:33 PM
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
#2843
Tragic Lantern / Re: Limits be gone.
August 09, 2012, 05:27:37 PM
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.
#2844
Tragic Lantern / Re: Limits be gone.
August 09, 2012, 04:41:42 PM
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).
#2845
Tragic Lantern / Re: Limits be gone.
August 09, 2012, 04:16:38 PM
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)
#2846
Tragic Lantern / Re: Limits be gone.
August 09, 2012, 12:59:51 PM
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'?
#2847
Tragic Lantern / Re: Limits be gone.
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)


#2848
fixed youtube link ;)
#2849
Tragic Lantern / Re: Limits be gone.
August 09, 2012, 10:03:13 AM
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.
#2850
Tragic Lantern / Re: Limits be gone.
August 09, 2012, 01:30:19 AM
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)