2 new buffers for record mode found - canon a530 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1] 2   Go Down

2 new buffers for record mode found - canon a530

  • 13 Replies
  • 6595 Views
*

Offline mmziom

  • *
  • 6
2 new buffers for record mode found - canon a530
« on: 23 / May / 2014, 16:35:46 »
Advertisements
Hello all!

That's my first post on the forum. I'd like to congrat all of You for running this great forum and helping CHDK being developed. Keep on great work!

I'm writing an application that uses ptpcam code (v1.0), extended by me and compiled into 146KB shared library. I'm currently playing around with liveview captured from address returned by *vid_get_viewport_fb() on my old, sweet a530 cam. According to the wiki it's "single-buffered" (whatever that means).

When I was increasing the exposure time in M mode, I noticed that although the liveview on my camera's screen runs relatively smoothly, in my app it's much more laggy. That's true also for CHDK PTP gui. My conclusion was that the camera use some additional buffers for liveview, although *vid_get_viewport_live_fb() on a530 returns 0.

For a530 viewport is 1080x240bytes. I thought that if I already display liveview from *vid_get_viewport_fb() I can try displaying data from neighbouring memory locations. By iterating the pointer with my app showing the 1080x240bytes converted from YCbCr 4:1:1 to 360x240pixel RGB bitmap, I found the 2 undocumented buffers for liveview: starting at 2.7 and 5.4 buffer lengths from 0x10605748.

So addidionaly for the buffer at 0x10605748 there is one at 0x106B0508 and 0x1075B2C8. I don't think it's of great importance for on camera functions, but for liveview capture with ptp, it makes a difference, especially for slow shutter speeds.

I'll further inspect in what order are those buffers displayed, but some help would be appreciated. If somebody wants, I can share my (unfinished yet, c# WPF app) and ptpcam 1.0 extended and made into 16KB shared library. Maybe You can find other buffers for Your camera model.

Greetings,
Michał
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: 2 new buffers for record mode found - canon a530
« Reply #1 on: 24 / May / 2014, 12:03:50 »
Hi,

I'm trying to clarify a few things.
Quote from: mmziom on 23 / May / 2014, 16:35:46
I'm currently playing around with liveview captured from address returned by *vid_get_viewport_fb() on my old, sweet a530 cam. According to the wiki it's "single-buffered" (whatever that means).
vid_get_viewport_fb() provides a static address, that means only one of the 3 liveview buffers. When vid_get_viewport_live_fb() is implemented on camera, you can get the same refresh rate as the LCD (but only theoretically, you won't be able to transfer all that data at 30fps over USB, and of course you won't get a perfect synch). The same generation a540 does have a correct vid_get_viewport_live_fb() implementation, shouldn't be hard to do the same for the a530.
See http://chdk.wikia.com/wiki/Frame_buffers and its links.

There are people around here who are interfacing cameras with computers, they may find a different PTP client implementation useful.
Logged
*

Offline mmziom

  • *
  • 6
Re: 2 new buffers for record mode found - canon a530
« Reply #2 on: 24 / May / 2014, 15:01:09 »
srsa_4c, thank You for the reply. That was helpful.
Quote
See http://chdk.wikia.com/wiki/Frame_buffers and its links
I had read that wiki page before, but I'll check the links. Thanks.

Quote
The same generation a540 does have a correct vid_get_viewport_live_fb() implementation
I checked the implementation for a540. So there is a memory location storing pointer to 1st, 2nd and 3rd buffer (3*4bytes) and one 1-byte variable (buff) storing index of buffer... I guess currently being updated. That makes sense. Would be nice to have those addresses for my camera. I think finding *fb is not hard as it should store 0x10605748, 0x106B0508 and 0x1075B2C8. Finding buff (so that index of current buffer) may be harder. I'll check the links from aforementioned wiki page. Maybe they will guide me how to do this. But if somebody can direct me, that'd be nice.

Quote
you can get the same refresh rate as the LCD (but only theoretically
That's ok. Looks like the buffers are updated less frequently with slower shutter speeds - stuttering on single buffer is really pronounced. That 2 other buffers may come in handy.

Quote
you won't be able to transfer all that data at 30fps over USB, and of course you won't get a perfect synch)
I'm not sure about that. Getting one buffer takes me 25-40ms. That means 25-40fps, so there are drops below 30fps. However Getting 3x more bytes (1080*240*3=759.375kB) takes me less that triple of that (60-75ms on average). Unfurtunately that's for getting n-consecutive bytes starting from given address. I wonder if ptp can send request for 3 memory areas and get it in one transaction, so that there is overhead for initiating only 1 transfer instead of 3.

Quote
There are people around here who are interfacing cameras with computers, they may find a different PTP client implementation useful.
I have that in mind. I'm not sure if it's ok I'm basing on the old ptpcam (v1.0). I chose that one because of simplicity and compactness. And also because I don't know quite how to compile newer versions. I don't think it's a problem, as long as that old ptpcam works properly (however I'm not sure about that as there is a code fragment printing a message
Code: [Select]
else if ( major != PTP_CHDK_VERSION_MAJOR || minor < PTP_CHDK_VERSION_MINOR )
    {
      printf("error: camera has unsupported camera version %i.%i; some functionality may be missing or cause unintented consequences\n",major,minor);
    } that I ignore in method to connect with camera rewritten by me.
Logged
*

Offline reyalp

  • ******
  • 14128
Re: 2 new buffers for record mode found - canon a530
« Reply #3 on: 24 / May / 2014, 17:26:59 »
Quote from: mmziom on 24 / May / 2014, 15:01:09
Maybe they will guide me how to do this. But if somebody can direct me, that'd be nice.
The usual approach is to look at the disassembly of a similar generation camera that is already known, and find the corresponding code in your firmware.

Quote
That's ok. Looks like the buffers are updated less frequently with slower shutter speeds - stuttering on single buffer is really pronounced.
I think this is correct, in low light the live view exposure time becomes to long to support the normal live view update rate.

Quote
I'm not sure about that. Getting one buffer takes me 25-40ms.
That's what I see with a540 as well. Note that on these cameras, the buffer size depends somewhat on shooting mode and digital zoom. However in chdkptp at least, you won't get anywhere close to 30 FPS in practice, because transfer and rendering are sequential.

Quote
I wonder if ptp can send request for 3 memory areas and get it in one transaction, so that there is overhead for initiating only 1 transfer instead of 3.
Maybe I'm missing something, but this doesn't make sense to me. You want the most recent buffer, not getting them all at once.

In any case, you can only transfer one address per send_data. You can do multiple send_data calls in a single transaction (live view already does this for the meta data) but there is substantial overhead.

If the frame buffers were close together, it might be faster to grab all 3 at once and ignore the stuff in between, but this would require a new live view protocol... and anyway, you want the most recent buffer, not all 3 at a given point in time.

Quote
I have that in mind. I'm not sure if it's ok I'm basing on the old ptpcam (v1.0). I chose that one because of simplicity and compactness.
I'm not sure what you mean by ptpcam 1.0. There were various forks to support the CHDK extension. There are some significant bugs affecting PTP operations in the early versions. The main one that comes to mind is the one related to packet size that caused certain sized transfers to fail on some cameras. The corresponding chdkptp change is http://trac.assembla.com/chdkptp/changeset/258/trunk
I'm not sure if it was ever fixed in any of the ptpcam sources (i thought it was in the chdkde source, but it looks like it wasn't...)

chdkptp is also derived from the ptpcam source, but I have re-written substantial parts of it.
Quote
that I ignore in method to connect with camera rewritten by me.
For future compatibility, you should check the CHDK protocol version. This is documented in the chdk ptp.h file.
Logged
Don't forget what the H stands for.
*

Offline nafraf

  • *****
  • 1308
Re: 2 new buffers for record mode found - canon a530
« Reply #4 on: 24 / May / 2014, 17:35:32 »
Same values for a540 and a530?

a540:
Code: [Select]
loc_ffc93908:
ffc93908:       e59f30ac        ldr     r3, [pc, #172]  ; ffc939bc: (00005298)
ffc9390c:       e59f20ac        ldr     r2, [pc, #172]  ; ffc939c0: (00005288)
ffc93910:       e5d30000        ldrb    r0, [r3]
ffc93914:       e7921100        ldr     r1, [r2, r0, lsl #2]
ffc93918:       e3a00000        mov     r0, #0
ffc9391c:       ebff7442        bl      loc_ffc70a2c

a530
Code: [Select]
loc_ffc902d4:
ffc902d4:       e59f30b0        ldr     r3, [pc, #176]  ; ffc9038c: (00005298)
ffc902d8:       e59f20b0        ldr     r2, [pc, #176]  ; ffc90390: (00005288)
ffc902dc:       e5d30000        ldrb    r0, [r3]
ffc902e0:       e7921100        ldr     r1, [r2, r0, lsl #2]
ffc902e4:       e3a00000        mov     r0, #0
ffc902e8:       ebff81ca        bl      loc_ffc70a18
Logged
*

Offline mmziom

  • *
  • 6
Re: 2 new buffers for record mode found - canon a530
« Reply #5 on: 24 / May / 2014, 20:05:21 »
Thanks nafraf. I'm a noob if it comes to assembly. I only see that (00005298) and (00005288) are there for both cameras, preceded by the same instructions. I'll make use of those addresses in my code tomorrow.

Quote
Maybe I'm missing something, but this doesn't make sense to me. You want the most recent buffer, not getting them all at once.
Ok, I agree. If code from a540 works, so the index of buffer is known, I need only that buffer. But to get the index or address of the most recent buffer I need to read that index and then read the buffer, so there is some overhead to this. Could be done nicely by one call to lua function, but calling lua takes 300ms or so, at least in the ptpcam I'm using. I can't quite figure out how is the liveview buffer obtained in chdkptp, though.


Quote
I'm not sure what you mean by ptpcam 1.0. There were various forks to support the CHDK extension. There are some significant bugs affecting PTP operations in the early versions.
Ok, thanks for pointing that. I'll try to move to the newest ptpcam.

Quote
However in chdkptp at least, you won't get anywhere close to 30 FPS in practice, because transfer and rendering are sequential.
You're right. I get about 22fps in chdkptp. Is "Frame last ms" shown there a rendering time? It shows 8ms, sometimes lower on my laptop. However my c# application achieve 24-32fps (measured in 0.5s periods), fluctuating over time. Measured rendering time take 2.5-4ms per frame on average. So it's 30fps+ at times (with several drops, though).
Logged
*

Offline reyalp

  • ******
  • 14128
Re: 2 new buffers for record mode found - canon a530
« Reply #6 on: 24 / May / 2014, 20:39:44 »
Quote from: mmziom on 24 / May / 2014, 20:05:21
I can't quite figure out how is the liveview buffer obtained in chdkptp, though.
The current CHDK trunk includes a PTP command for this: PTP_CHDK_GetDisplayData. This can get the live view as well as the bitmap and bitmap palette. It also includes all the dimensions needed to render the view correctly (though not all ports currently return this correctly).

See http://trac.assembla.com/chdk/browser/trunk/core/ptp.h for the PTP command and http://trac.assembla.com/chdk/browser/trunk/core/live_view.h for the format of the returned data, and http://trac.assembla.com/chdk/browser/trunk/core/live_view.c for the actual code that returns the data.

You can find the client side of this in the chdkptp source:
http://trac.assembla.com/chdkptp/browser/trunk/ptp.c#L2355
Quote
Ok, thanks for pointing that. I'll try to move to the newest ptpcam.
Again, I don't know what version you were referring to, or what the "newest" is. Since that bug is apparently not fixed in the chdkde source, I'm not sure it's fixed in any released ptpcam version. However, it should be straightforward to apply the same change to your ptpcam source.

Edit:
Discussion of that bug can be found here: http://chdk.setepontos.com/index.php?topic=4338.msg87299#msg87299

Quote
You're right. I get about 22fps in chdkptp. Is "Frame last ms" shown there a rendering time? It shows 8ms,
Yes, that is the rendering time, although there's some other overhead that isn't included. In principle, you could render one frame while the next frame was being read over USB. The chdkptp code isn't really optimized for speed, 10 FPS is fine to see what's going on.
« Last Edit: 25 / May / 2014, 14:36:42 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline mmziom

  • *
  • 6
Re: 2 new buffers for record mode found - canon a530
« Reply #7 on: 25 / May / 2014, 07:00:44 »
Quote
The chdkptp code isn't really optimized for speed, 10 FPS is fine to see what's going on.
Ok that's fine. I don't know the LCD refresh rate, but I checked the rate at which the index of buffer used changed (by polling byte on 0x5298 memory location, if the value modulo 3 increased by one I counted it as a new frame, increase by 2 would mean the frame (or 4 or 7 of them...) was skipped. My findings for my camera:
- shutter speeds of 1/13s and faster: ~23.2 fps on average
- 1/10s: ~22.9fps
- 1/5s:   ~11.5fps
- 0"3s and longer: ~7.95-8 fps

Quote
See http://trac.assembla.com/chdk/browser/trunk/core/ptp.h for the PTP command and http://trac.assembla.com/chdk/browser/trunk/core/live_view.h for the format of the returned date, and http://trac.assembla.com/chdk/browser/trunk/core/live_view.c for the actual code that returns the data.

You can find the client side of this in the chdkptp source:
http://trac.assembla.com/chdkptp/browser/trunk/ptp.c#L2355
Ok, thanks for pointing me to those files. I'll analyze the code.

Quote
Again, I don't know what version you were referring to, or what the "newest" is. Since that bug is apparently not fixed in the chdkde source, I'm not sure it's fixed in any released ptpcam version. However, it should be straightforward to apply the same change to your ptpcam source.
Well, honestly, me neither. I think I'll switch to the ptpcam version used by chdkptp (I'll try to compile those files in chdkptp trunk that are from ptpcam, plus my code).
Logged
*

Offline nafraf

  • *****
  • 1308
Re: 2 new buffers for record mode found - canon a530
« Reply #8 on: 26 / May / 2014, 10:34:02 »
@mmziom
a530 vid_get_viewport_live_fb() updated in trunk (changeset 3347) and stable version (changeset 3348)
Thanks
Logged
*

Offline reyalp

  • ******
  • 14128
Re: 2 new buffers for record mode found - canon a530
« Reply #9 on: 26 / May / 2014, 14:28:05 »
Quote from: nafraf on 26 / May / 2014, 10:34:02
@mmziom
a530 vid_get_viewport_live_fb() updated in trunk (changeset 3347) and stable version (changeset 3348)
Thanks
@mmziom
you could check MD response with and without this change http://chdk.wikia.com/wiki/Testing#MD_tune.bas although given the a540 is correct and the values are the same, it's probably fine.

Also worth noting that vid_get_viewport_live_fb() is set up to get the current frame buffer which means you may see more tearing than you saw with the old version. For maximum visual quality it would be better to get the previous frame, but we would need a different function to avoid impacting MD performance.
Logged
Don't forget what the H stands for.
Pages: [1] 2   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal