ProcessTwoInTwoOutLosslessPath

[andy kh]

Wonderful work@dfort n ErwinH

[ErwinH]

I also tried to get this running on the 600D, but I can't get the dm-spy-experiments branch running on the 600D. The led blinks, once per second for a few times, then it blinks fast and it starts over. Same for the startup-log builds. (even the older ones). Am I missing something?

Finding the stubs was easy, except for the setflags bit of course.

Code Select Expand

    if (is_camera("600D", "1.0.2"))
    {
        /* ProcessTwoInTwoOutJpegPath, 600D 1.0.2 */
        TTL_SetArgs     = (void *) 0xFF2155E0;      /* fills TTJ_Args struct; PictureSize(Mem1ToRaw) */
        TTL_Prepare     = (void *) 0xFF2FE354;      /* called right after ProcessTwoInTwoOutJpegPath(R) Start(%d); */
                                                    /* calls [TTJ] GetPathResources and sets up the encoder for RAW */
        TTL_RegisterCBR = (void *) 0xFF2FD424;      /* RegisterTwoInTwoOutJpegPathCompleteCBR */
        TTL_SetFlags    = (void *) set_flags_600D;  /* this function is also inline on 600D??? */
        TTL_Start       = (void *) 0xFF2FE3C4;      /* called next; starts the EDmac transfers */
        TTL_Stop        = (void *) 0xFF2FE3FC;      /* called right after sssStopMem1ToRawPath */
        TTL_Finish      = (void *) 0xFF2FE434;      /* called next; calls UnlockEngineResources and returns output size from JpCoreCompleteCBR */
    }

[a1ex]

Sorry for delay - was a bit away from ML lately, so anything that required more than a 5-minute break went to the back burner. Nice to see the progress - now the questions:

1) the null pointer warning appears to be false - both my 700D ROMs have that magic value. A sure way to tell would be to compare with a ROM from a 700D that never had ML on it - for example, the ROM backup saved during ML installation. If anyone made a backup copy of those ROMs (easily recognized by their boot flag status), they could be useful.

Detailed analysis: I get the magic value 0xA5A5A5A5 at the following offsets:
- 0xa5403c: that's in the middle of other magic values with similar patterns (e.g. 34 34 34 34 A5 A5 A5 A5 E5 E5 E5 E5 F1 F1 F1 F1). This pattern is also present in the firmware update from Canon.
- 0xc950e4, 0xc950e8, 0xc950ec, 0xc950f0. This is in the data area, not present in Canon's update and not recognized by my property parser either. Not sure what's up with it, but there are similar patterns nearby.
- 0xc95bd0, 0xc95bd4, 0xc95bd8, 0xc95bdc: same as above.
- 0xc9f1b0, 0xc9f1b4: like the first one, except it's not present in Canon's update.
- 0xfdb4b0: same as above.

2) Buffers - this was a bit of guesswork. On 5D3, I've assumed the raw buffer allocated by Canon is at least as big as the maximum resolution - the one from 5x zoom. With dm-spy-experiments I've found out a possible size for that buffer (commit 1ee9679 => 0x1cae000, so about 30 MB). Experimentally I've found out that was wrong - the buffer was overwritten by something else.

Another interesting discovery - as soon as leaving LiveView, a small part of Canon's default raw buffer (0x4d31a000) was overwritten near 0x4d600000 - about 2.9MB after its beginning. If we always stay in LiveView, things should be fine - however, we are using the "paused" LiveView for various things, so I wanted to play safe and pick a buffer that's not going to be overwritten when doing that. So I took whatever was not overwritten - found by trial and error between 0x4d600100 and 0x4ee00000: about 24 MB. Enough for 4K, but not for full-res (in 14-bit). For that (extreme) case, the only way to allocate a contiguous chunk of memory was with the SRM backend from Canon - they use it as raw buffer for still photo capture. It's very tricky to use - the buffers have to be freed in exactly the same order as allocated, there's a BUSY sign printed on the screen while this buffer is allocated, while this sign is on the screen it also locks up the UI as soon as you move a scrollwheel, and so on. For that reason, I went for something very hackish - intentional use after free for this buffer (assuming Canon code won't use or move the SRM buffers while in LiveView). It's not very robust, but it's only used with full-res LiveView (since that's the only case we need more than 25 MB for one frame).

To see the memory map, and find out what areas might be free, there is CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP. Without it, the RAM is not cleared at boot, so you'll get different results (and likely not relevant) every time you boot.

Then, once you have guessed a possibly free memory region, you'll need to test it somehow to make sure nobody overwrites it (at least during LiveView). There is some test code for that in the RscMgr_memory branch, but it's nothing fancy - you could just fill the buffer with something and check whether it's still unchanged, in a loop.

RAW_LV_BUFFER_ALLOC_SIZE is how much we need for a full-res image (max W * max H * 14/8).

3) Regarding 07573f3 - that's a bit difficult to do in C (since the arrays have different lengths for different camera models). See for example mpu.c in the QEMU branch for a similar situation.

Tip: the ResLock entries do not depend on the firmware version (they probably depend only on the DIGIC generation), so you can use is_camera("5D3", "*") to cover all versions.

4) 600D LED blink means "out of memory". You could remove some features in features.h (you can even boot with an empty features.h, also comment out CONFIG_RAW* and related entries, e.g. EDMAC, and - on 600D - also remove audio-lapis.o from Makefile.setup.default). [ todo: allow compiling without features on all models, and include this on jenkins ]

Another todo for me: integrate dfort's 700D crop_rec in the 4K branch [DONE], and merge the non-4K changes (e.g. without memory hacks) into mainline (WIP in the raw_fixes branch).

[ErwinH]

1) I altered the scan_A5A5 routine so it won't trip over A5A5A5A5 at these addresses:
0xF8C950E4 - 0xF8C950F0
0xF8C95BD0 - 0xF8C95BDC
0xF8C9F1B0 - 0xF8C9F1B4
If they do appear at another location it will show the warning again.

I haven't had a good look at the buffers yet.

3) I've combined the resources for the 700D * and the 5D3 *. It is working on my 700D and should work on the 5D3. Hope this is a solution you can live with.

I wasn't able to get a compressed Full Resoution Silent Picture DNG but it did work for Simple Silent:

Found the issue with the FRSP. Tricking the compressor in half the height, double the width makes it fail. Removing the width * 2 and height / 2 does grab the lossless dng. I don't know if they are valid, but Rawtherapee and Resolve 14 accept them.

P.S. Here are the entry points for lossless decompression on the 700D. I do get a lot of malloc errors, but replacing malloc with fio_malloc @mlv_play.c:2220 fixed those.

Code Select Expand

    if (is_camera("700D", "1.1.4"))
    {
        Setup_DecodeLosslessRawPath = (void*)0xFF4294DC;
        Start_DecodeLosslessPath = (void*)0xFF4295A4;
        Cleanup_DecodeLosslessPath = (void*)0xFF429708;
    }

[ErwinH]

Did a "short" testrun, recording 16:9 using 11 bits lossless compression.

Code Select Expand


    FPS         : 25.000000
...
    Frames Video: 23504
...
    Res:  1736x976
...
     ISO:        800
...
     Time: 942568.613000 ms
...
   Frame: #23503


Only thing is the battery went out of juice Tomorrow I'll be recording an interview and will be using this camera as my second (backup) camera, using plugin power. Let's see if we can fill up the SD card without interruption.

[Danne]

Eosm maybe?
Awesome progress.

[dfort]

Eosm maybe?

I was thinking the same thing. The main sticking point would be to figure out if this applies to the EOSM and if so, how to find the proper values.

Code Select Expand

static void set_flags_700D()
{
    EngDrvOut(0xC0F37010, (shamem_read(0xC0F37010) & 0xFFE3FFFF) | 0xC0000);
    EngDrvOut(0xC0F3704C, (shamem_read(0xC0F3704C) & 0xFFFFFFC0) | 0x20);
    EngDrvOut(0xC0F37074, (shamem_read(0xC0F37074) & 0xFFC0FFFF) | 0x180000);
    EngDrvOut(0xC0F37078, (shamem_read(0xC0F37078) & 0xFFC0FFFF) | 0x180000);
}

BTW -- The 700D can now use some of the crop_rec module resolutions. With lossless compression maybe we can start experimenting with some of the other crop_rec options?

[a1ex]

The EOS M and 650D should be very similar. 100D uses the same pattern, only the code was refactored a bit. EOS M2 is likely similar to 100D. 70D and 6D are more like 5D3 (TwoInTwoOutLosslessPath). All these models are very good choices for low-hanging fruits.

BTW, 700D might also work with FF36B2D8 TTL_SetFlags. There are two versions of StartTwoInTwoOutJpegPath - one of them (the one I've looked at back then) has this function inline, the other one calls it.

Whatever these flags do, they also worked on 5D3 (with TTJ routines), so they are probably common to all DIGIC 5 models.

Interesting notice about doubling the width no longer needed; will look into it, but not right now.

[ErwinH]

The doubling only has to be removed for the FRSP, the mlv do need half the height, double the width. I'm not really sure about the simple silent pictures.

I'll test the other option for the set flags later and match it to the 600D and check if that works.

The real test today was a bit of a dissapointment. Recording at 1736x976 wasn't continyous... It stopped after 33000 frames (because the card was full)

[dfort]

Recording 33000 frames was a disappointment?

I took the latest crop_rec_4k_700d branch from ErwinH's bitbucket repository, merged in the latest crop_rec_4k changes and got the crop_rec module working. That should give you 60fps raw recording though the image size needs to be scaled down to get continuous recording. Here is a link to the branch I'm working on. Yeah, I'm going to attempt once again to get lossless compression working on the EOSM.

I'm still not able to record lossless compressed Full Resolution Silent Stills on the 700D. I was able to get a screenshot of the error message.



Just to make sure that the 5D3 didn't break with all these changes I compiled for the 5D3.113 from my working branch and YIKES! The null pointer warning message came up! Rather unnerving but I went ahead and shot some FRSP frames and lossless compression is working on that camera.

[ErwinH]

Oops. I forgot to change the test for 0XE5E5E5E5. it should continue if it is 0XE5E5E5E5 and not if it''s something else.

[a1ex]

Rather unnerving but I went ahead and shot some FRSP frames and lossless compression is working on that camera.

Really? I'm currently trying to take some full-res frames and I'm getting the above errors on 5D3.123...

(I've started from the current 4K experimental build, and went back to first known good build with lossless silent pictures - but that one isn't working either...)

[ErwinH]

For the 700D the solution was to remove the * 2 and / 2 in these statements.

Code Select Expand

TTL_Args.xRes = width * 2;
    TTL_Args.yRes = height / 2;

[dfort]

Interesting -- I just grabbed the current 5D3.113 crop_rec_4k build from the experiments download page and it displays that "Raw error, falling back to YUV overlays" message though it does save a lossless full-res DNG frame. I might have missed the message because the LiveView screen was displaying the null pointer message which pretty much takes over the entire screen.

[a1ex]

Figured it out - I've been compressing the raw data in place (reusing the memory buffer); however, the overlays no longer had a valid raw buffer. Will disable that (though I might have to re-think the memory management).

Back then, I must have tested it with global draw off...

A bigger trouble I have is with full-res LiveView snapshots (crop_rec enabled and set to Full-res LV, silent pictures set to Simple). Regular (uncompressed) DNG works fine. Lossless DNG usually locks up the camera, though it's not 100% repeatable.

I might have missed the message because the LiveView screen was displaying the null pointer message which pretty much takes over the entire screen.

If that was on 5D3, I should take a look at your ROM.

[dfort]

For the 700D the solution was to remove the * 2 and / 2 in these statements.

Code Select Expand

TTL_Args.xRes = width * 2;
    TTL_Args.yRes = height / 2;

Yep--that works. Able to capture full-res silent with that "fix" on both the 700D and 5D3.

Found most of the addresses on the EOSM but am stumped in a few spots.

[dfort]

Lossless compression working on the EOSM.

https://bitbucket.org/daniel_fort/magic-lantern/branch/crop_rec_4k_700d_eosm

A bit hackish. When in doubt I just used the 700D values but it is working. Did continuous recording, 23.98 fps at 1648 x 696 using the crop_rec module.

[Danne]

 
Hopefully reach my eosm on sunday. This thread is rockin'! And in the crop_rec module. The best.

[dfort]

Processed in Switch of course.


Sent from my iPhone using Tapatalk

[DeafEyeJedi]

Exciting news. On my way home from work. Can't wait to grab the EOSM out and do you have a build to share or do I need to try compiling again?

[mothaibaphoto]

Figured it out - I've been compressing the raw data in place (reusing the memory buffer); however, the overlays no longer had a valid raw buffer.

Is that a reason I get the "Raw error, falling back to YUV overlays" message when trying to shoot full-res silent compressed DNG? After searching the forum i decided that it was my camera sensor fault.
Here is detailed description of what i did and what i get:
with crop_rec_4k.2017Jun19.5D3113 i activated ettr and silent modules, Auto ETTR configured to "Press Set".
Than, i can expose with Set and take image with half press.
I see that "Raw error, falling back to YUV overlays" message on preview, but everything is OK. Next, i activated intervalometer, and first what i noticed is Auto ETTR now "Always ON" on its own.
As far as i understand, ETTR can calculate exposure with low res liveview image and after taking image with that hi res image - this is how it used to work on previous builds with intervalometer and ETTR configured to "Press Set".
This explains why in poor light conditions when liveview is extremely amplified, ETTR failed to get correct exposure until you start intervalometer and take couple frames.
And now it looks like i can't get correct exposure either - because ETTR is liveview only, and, moreover, not RAW based?

[a1ex]

Correct - ETTR also relies on the raw buffer, which was overwritten. Just pushed the fix (but didn't test this scenario).

Also went ahead and pulled ErwinH's and dfort's changes for 700D/EOSM and did some minor cleanups. Didn't pull the null pointer changes yet (want to test them in QEMU first).

[ErwinH]

The null pointer changes are incorrect. Both tests are reversed. Do other cameras then the 5D3 incorporate this test since they can't be affected by the same bug.

[dfort]

Also went ahead and pulled ErwinH's and dfort's changes for 700D/EOSM and did some minor cleanups.

Great!

Noticed that a change I made to mlv_play for the EOSM that I later reverted got merged. Also, ErwinH's 700D change didn't get merged. As a result that module won't build.

[dfort]

The 5D3 likes the latest changes but 700D and EOSM are complaining.

Only mlv_lite active, Lossless 14bit.

Code Select Expand

ML ASSERT:
fullsize_buffers[1] == UNCACHEABLE(raw_info.buffer)
at mlv_lite.c:1379 (free_buffers), task raw_rec_task
lv:1 mode:3

raw_rec_task stack: 1acd08 [1acdd0-1abdd0]
0xUNKNOWN  @ bba0:1acdc8
0x00ABCC14 @ ac1140:1acd48
0x0007F5E4 @ abcc74:1acd38
0x0007EF68 @ 7f644:1acd08

Magic Lantern version : Nightly.2017Aug19.700D114
Mercurial changeset   : 024351174cb1 (crop_rec_4k) tip
Built on 2017-08-19 21:34:59 UTC by rosiefort@RosieFoComputer.
Free Memory  : 128K + 3206K

Code Select Expand

ML ASSERT:
fullsize_buffers[1] == UNCACHEABLE(raw_info.buffer)
at mlv_lite.c:1379 (free_buffers), task raw_rec_task
lv:1 mode:3

raw_rec_task stack: 1ded18 [1dede0-1ddde0]
0xUNKNOWN  @ c380:1dedd8
0x00AB4A34 @ ab8f60:1ded58
0x0009EBC8 @ ab4a94:1ded48
0x0009E548 @ 9ec28:1ded18

Magic Lantern version : Nightly.2017Aug19.EOSM202
Mercurial changeset   : 024351174cb1 (crop_rec_4k) tip
Built on 2017-08-19 21:39:42 UTC by rosiefort@RosieFoComputer.
Free Memory  : 161K + 3404K