Motion Detection too slow?

[slchdk]

mx3: sent you an email.

I also don't see any way to post an attachment here.

[na560]

I've run mx3's find_diffs and find_u32s on an a530 and an a560 and uncovered the addresses for speeding up motion detection.
The addresses for the a530 match with the a540 and the relevant code is:

Code: [Select]

void *vid_get_viewport_live_fb()
{
//    return (void*)0x0;
    void **fb=(void **)0x5288;
    unsigned char buff = *((unsigned char*)0x5298);
    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }
    return fb[buff];
}

For the a560 vid_get_viewport_live_fb should be:

Code: [Select]

void *vid_get_viewport_live_fb()
{
//    return (void*)0x0;
    void **fb=(void **)0x64F0;
    unsigned char buff = *((unsigned char*)0x6500);
    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }
    return fb[buff];
}
I tested these changes with fudgey's MDFB script and got a 40-50 ms speedup.
Could a developer please add these changes to a future Trunk revision? Thanks.

[reyalp]

Added svn 772

[TonyH]

For A700 firmware version 100b, the relevant locations (thanks, mx3!) are 0x5264 & 0x5274.

void *vid_get_viewport_live_fb()
{
//    return (void*)0x0;
    void **fb=(void **)0x5264;
    unsigned char buff = *((unsigned char*)0x5274);
    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }
    return fb[buff];
}

gives a similar speedup (40-50ms) as above.

[fudgey]

a700 added in svn trunk revision 773, http://tools.assembla.com/chdk/changeset/773

[tvkas]

I just completed this process and got the following result for my S5 IS

Code: [Select]

void **fb=(void **)0x2304;
    unsigned char buff = *((unsigned char*)0x2314);
    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }
    return fb[buff];
However, when I went to compile my fresh new version I got the following"

========== C:\CHDK\TRUNK\TRUNK776\BIN\LOGS\ERR-S5IS-101B.TXT ==========

boot.c: In function '_time':
boot.c:1710: warning: no return statement in function returning non-void
boot.c: In function 'task_blinker':
boot.c:1756: warning: implicit declaration of function 'msleep'
lib.c: In function 'vid_get_viewport_live_fb':
lib.c:38: error: parameter 'fb' is initialized
lib.c:39: error: parameter 'buff' is initialized
lib.c:40: error: expected declaration specifiers before 'if'
lib.c:43: error: expected declaration specifiers before 'else'
lib.c:46: error: expected declaration specifiers before 'return'
lib.c:39: error: declaration for parameter 'buff' but no such parameter
lib.c:38: error: declaration for parameter 'fb' but no such parameter
C:\CHDK\gcc4\bin\gmake[4]: *** [lib.o] Error 1
C:\CHDK\gcc4\bin\gmake[3]: *** [all-recursive] Error 1
C:\CHDK\gcc4\bin\gmake[2]: *** [all-recursive] Error 1
C:\CHDK\gcc4\bin\gmake[1]: *** [all-recursive] Error 1
gmake: *** [all-recursive] Error 1


So now I am really out of my league. I strugled just to get to this part!  Can anybody advise?? Now what do I do?

[tvkas]

O.K. found my simple code erroe and corrected with:

Code: [Select]

void *vid_get_viewport_live_fb()
{
//    return (void*)0x0;
    void **fb=(void **)0x2304;
    unsigned char buff = *((unsigned char*)0x2314);
    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }
    return fb[buff];
}
This didn't work -  I spent all day on this.

I went back to the table and rechecked my work and MX3's postings and came up with the following...

Code: [Select]

void *vid_get_viewport_live_fb()
{
    void **fb=(void **)0x21E8;
    unsigned char buff = *((unsigned char*)0x23f8);
    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }
    return fb[buff];
}
I think it works!  But I can not be sure... I compiled and uploaded to my card. Tested and saw no improvement over stock for my camera. I was getting 100 to 150 on the test and after saw maybe a gray 80 to 130. I mean it was a little improvement but not the 40-50 I was reading about. Now perhaps I have something wrong still. Here are the numbers I got

Code: [Select]

(0x00D27A60 + 0x1900 = 0x00D29360) bytes: 3F480
(0x00DA6360 + 0x1900 = 0x00DA7C60) bytes: 3F480
(0x00E24C60 + 0x1900 = 0x00E26560) bytes: 3F480And...

Code: [Select]

[0x000021E8] : 10D29360
[0x00002268] : 10D29360
[0x00002304] : 10D29360
[0x00002308] : 10DA7C60
[0x0000230C] : 10E26560
[0x0000A69C] : 10D29360
[0x0000A6C8] : 10D29360
[0x0000A6CC] : 10D29360
[0x0000A70C] : 10D29360
[0x000B859C] : 10D29360
[0x000DD87C] : 10D29360
[0x00304008] : 10DA7C60
[0x003140E0] : 10D29360
[0x003140E4] : 10D29360
What I can say is that it at least worked! The first try just crached the MD script. It just stopped working... This is at least still taking pictures. If anybody sees an error in my numbers I am open to suggestions. I am very new at this and virtually have no idea what I am doing.

[nonno]

i'm not a skilled programmer and i'm not inside the chdk project (never looked at the source) so i ask you if the latest enhancements are already available for the A650 in latest chdk versions. If not, I'm ready to cooperate following your directives.

[mx3]

... so i ask you if the latest enhancements are already available for the A650 in latest chdk versions.

these "enhancements" (3 buffers processing) are not available in current trunk (revision 778) for a650

[Anaglyphic]

Since this thread is still updated, I will post it here, but MAN this is getting long...  This is for an SX100, fw 100c...

Hi guys! OK so it's been a year or so since mx3's "lazy way" - I pulled revision 781 and looked at chdk/platform/sx100is/sub/100c/lib.c:

Code: [Select]

void *vid_get_viewport_live_fb()
{
        return (void*)0;//0x10670ee0;
}
So since that looked unmodified, I proceeded with the lazy steps outlined in many places... but of course it would turn out different. Everyone says "the three addresses" but I get 4?

Code: [Select]

--snip--
(0x005AE8B0 + 0x1900 = 0x005B01B0) bytes: 180
(0x005AEA90 + 0x1900 = 0x005B0390) bytes: 180
(0x005AEC70 + 0x1900 = 0x005B0570) bytes: 180
(0x005C0DD0 + 0x1900 = 0x005C26D0) bytes: 3F480
(0x00658BD0 + 0x1900 = 0x0065A4D0) bytes: 3F480
(0x006D74D0 + 0x1900 = 0x006D8DD0) bytes: 3F480
(0x00755DD0 + 0x1900 = 0x007576D0) bytes: 3F480

Not knowing how to proceed, I ran find_u32s twice, once with the first 3 & again with the last 3:

Code: [Select]

first3refs.txt

[0x000020F0] : 1065A4D0
[0x0000215C] : 1065A4D0
[0x000021E4] : 1065A4D0 <---
[0x000021E8] : 106D8DD0 <---
[0x000021F0] : 105C26D0 <--- off by 0x8
[0x000028F0] : 105C26D0
[0x00002900] : 105C26D0
[0x00002910] : 105C26D0
[0x00009914] : 106D8DD0
[0x00009940] : 1065A4D0
[0x00009944] : 1065A4D0
[0x00009978] : 105C26D0
[0x00009984] : 1065A4D0
[0x00018A00] : 105C26D0
[0x000BC6D4] : 1065A4D0
[0x000E1FD8] : 1065A4D0
[0x001EBFBC] : 105C26D0
[0x00304008] : 1065A4D0
[0x00304408] : 105C26D0
[0x003140E0] : 1065A4D0
[0x003140E4] : 1065A4D0
[0x01FDC0A0] : 1065A4D0


Code: [Select]

last3refs.txt

[0x000020F0] : 1065A4D0
[0x0000215C] : 1065A4D0
[0x000021E4] : 1065A4D0 <---
[0x000021E8] : 106D8DD0 <---
[0x000021EC] : 107576D0 <---
[0x00009914] : 106D8DD0
[0x00009940] : 1065A4D0
[0x00009944] : 1065A4D0
[0x00009984] : 1065A4D0
[0x000BC6D4] : 1065A4D0
[0x000E1FD8] : 1065A4D0
[0x00304008] : 1065A4D0
[0x003140E0] : 1065A4D0
[0x003140E4] : 1065A4D0
[0x01FDC0A0] : 1065A4D0

Well, at any rate, none of those addresses +10 had the current buffer flag - so I started manually browsing... painful. Then I found Jucifer's post where he says the A720's buffer pointer is buffer 0 address - 0x14C... and since everything detects the SX100 -as- a A720... sure enough, 0x00002098 has the magic byte that is auto-updating a value of 0/1/2.

I've compiled 781 and tested it with MDFB-080914, the results are... unimpressive! :< It's the same as the original way. Ah well.

If I did it correctly, that is. I'm not sure because I don't see any dramatic (or even minimal) improvement.... If it's done correctly, the addresses below work and could be included:

Code: [Select]

    void **fb=(void **)0x21E4;
    unsigned char buff = *((unsigned char*)0x2098);
    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }
    return fb[buff];

I'm still confused about that 4th address. It's there by the same offset 0x4... but the buffer pointer only jumps between 0-2.

[fudgey]

If I did it correctly, that is. I'm not sure because I don't see any dramatic (or even minimal) improvement.... If it's done correctly, the addresses below work and could be included:

Exactly how are you measuring? You can't tell the difference without a reasonably accurate measuring tool (some applications have been released for this as you hopefully know) and MDFB must be in fast mode of course, because otherwise you're just measuring how long it takes to determine exposure and focus. And you should take a sufficient number of measurements (50 should be enough to reliably see if there's a difference) on both firmwares.

If you use one of the programs that flash stuff on a PC display and fail to get good results (around 100 ms, mostly below with optimized MD and a less consistent result but probably never above 300 ms with non-optimized MD), try a different monitor/computer/operating system as they aren't born equal in terms of display speed and behavior.

[Anaglyphic]

Hi,

Hey, no, it's not a complaint just an observation... if the logic and subsequent patch are correct, who knows, maybe I was one of the lucky people that had a camera that was fast at reading the display data from the start.

Prior to the change, using MDFB optimized for speed, it was always in the 90-140ms range, according to DG's web based thingie... (on a fast LCD, 2ms g-t-g, with vsync disabled)

After making the change, compiling (I still use an older gcc-arm 3.4.6 / binutils 2.17 build environment under linux, but I doubt this matters) and taking it for a test-drive, it was for the most part exactly the same. It's 100-120ms shots, never a 90 or 140. So it does appear it's working, as searching around here shows others where there wasn't a noticeable speed improvement, but it did "tighten up" the timings on both ends of the range...

[fudgey]

Prior to the change, using MDFB optimized for speed, it was always in the 90-140ms range, according to DG's web based thingie... (on a fast LCD, 2ms g-t-g, with vsync disabled)

After making the change, compiling (I still use an older gcc-arm 3.4.6 / binutils 2.17 build environment under linux, but I doubt this matters) and taking it for a test-drive, it was for the most part exactly the same. It's 100-120ms shots, never a 90 or 140. So it does appear it's working, as searching around here shows others where there wasn't a noticeable speed improvement, but it did "tighten up" the timings on both ends of the range...

10 ms is not much of a difference here even with a fairly large number of experiments, but if you think unoptimized MD was faster on occasion compared to your optimized MD, you could be reading the wrong buffer. I mean, maybe you aren't reading the most recent one but the one from before that instead. The range would then be tighter because it's always of the same age and by luck faster than unoptimized average.

As you know, this patch does not improve the maximum speed of MD, it just makes that maximum speed to happen always. If you have 4 buffers, without optimization you'll get fastest response 25% of the time... if you optimized to the wrong buffer you are never getting the best speed... which is why it would be good to be sure you've maxed out the speed before we commit this to svn.

[Anaglyphic]

[fudgey]

Committed to svn:
http://tools.assembla.com/chdk/changeset/783

(3) Interestingly, the good shots were mostly in groups of 3 and evenly spaced! eg. #25-26-27, 46-47-48, 67-68-69, etc. Relevance?

You're operating two devices running crystal stabilized clocks. It's possible that your 4 second delay is too accurate and causes aliasing (with the display buffer update phase or with some other unknown periodic thing that causes variance in MD reaction time). I noticed similar things in my old tests which is why I stopped the measurement process manually a few times during each test series to induce a human random delay. If my memory serves, I didn't go far enough to verify that this had any effect on the results; just figured it wouldn't ruin the tests either.