vid_get_viewport_live_fb in video mode - General Discussion and Assistance - CHDK Forum

vid_get_viewport_live_fb in video mode

  • 10 Replies
  • 599 Views
*

Offline reyalp

  • ******
  • 12630
vid_get_viewport_live_fb in video mode
« on: 30 / March / 2020, 02:14:01 »
Advertisements
A number of ports have code like
Code: [Select]
void *vid_get_viewport_live_fb()
{
    if (MODE_IS_VIDEO(mode_get()))
        return viewport_buffers[0];     // Video only seems to use the first viewport buffer.

    // Hopefully return the most recently used viewport buffer so that motion detect, histogram, zebra and edge overly are using current image data
    return viewport_buffers[(active_viewport_buffer-1)&3];
}
I discovered on my cameras with this logic (sx160, elph130, elph180) that it isn't quite correct. On sx160 and elph130, active_viewport_buffer goes from 0-2 in video mode and when video is recording, instead of 0-3 in still mode. elph180 uses 0-3 in all cases, and so does not need a special case for video.

This is noticeable as low apparent frame rate running PTP live view, and running MD_Tune.bas.
PTP live view testing verifies that the buffers are actually used. If you leave the 0-3 logic on the cameras that do 0-2 in video, you see old data or garbage every few frames, while the 0-2 logic displays correctly.

This shouldn't be a big deal for most users, but in r5452, I checked in updates for those cameras.

The attached patch displays active_viewport_buffer and vid_get_viewport_live_fb() values.

edit:
Some cameras, like sx50 and g15 apparently use 8 buffers https://chdk.setepontos.com/index.php?topic=8932.msg98593#msg98593
« Last Edit: 30 / March / 2020, 02:22:24 by reyalp »
Don't forget what the H stands for.

*

Offline blackhole

  • *****
  • 768
  • A590IS 101b
    • Planetary astrophotography
Re: vid_get_viewport_live_fb in video mode
« Reply #1 on: 30 / March / 2020, 14:38:32 »
The SX410 also uses 0-3 in video mode.
Attached is a patch that also includes some changes to KeyMap (low zoom speed) for the SX410.
« Last Edit: 30 / March / 2020, 14:41:00 by blackhole »

*

Offline srsa_4c

  • ******
  • 4239
Re: vid_get_viewport_live_fb in video mode
« Reply #2 on: 30 / March / 2020, 17:12:42 »
Ixus150 is also a 0..3 model in (all?) photo/video modes.
The attached patch displays active_viewport_buffer and vid_get_viewport_live_fb() values.
That's both too fast for the eye and not fortunate for 25FPS cameras due to the cycle time (20ms * 4 if I'm not wrong).
I seem to recall doing a visualization for this (but can't find a patch). Something like displaying 1-2-3 dozen encountered values of active_viewport_buffer on screen, in a row. Sampling would need to be done in a different task (physw, for example), but that complexity is already too much for a temporarily used debug feature.

*

Offline reyalp

  • ******
  • 12630
Re: vid_get_viewport_live_fb in video mode
« Reply #3 on: 30 / March / 2020, 17:35:07 »
That's both too fast for the eye and not fortunate for 25FPS cameras due to the cycle time (20ms * 4 if I'm not wrong).
On my cameras at least, I found watching it for a little while was enough to figure out the range of values that appear. chdkptp frame rate can be adjusted to slow down or shift the sampling, though not the underlying spytask sampling.

Quote
Ixus150 is also a 0..3 model in (all?) photo/video modes.
The SX410 also uses 0-3 in video mode.
Seems common to be common to newer cameras.

Also for completeness, this shouldn't affect digic 6 since those ports do a brute force search for the current address.
Don't forget what the H stands for.


Re: vid_get_viewport_live_fb in video mode
« Reply #4 on: 30 / March / 2020, 18:56:33 »
Apparently some CHDK posts don't implement active_viewport_buffer.

So far that includes the A560, ixus120, G10, and G16.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 12630
Re: vid_get_viewport_live_fb in video mode
« Reply #5 on: 30 / March / 2020, 22:33:31 »
Apparently some CHDK posts don't implement active_viewport_buffer.

So far that includes the A560, ixus120, G10, and G16.
Many older ports access the variable directly in lib.c (g10 is an example)

Also, many of these cameras appear to use 3 buffers in the normal case, so probably don't need a special case for video.

G16 and other digic 6 use different logic that shouldn't be affected.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4239
Re: vid_get_viewport_live_fb in video mode
« Reply #6 on: 31 / March / 2020, 16:52:56 »
Here's a possible visualization, for ports where active_viewport_buffer is declared.
The added debug line starts with viewport numbers in order as seen and ends with an approximate frames per second value (10x of the actual FPS to avoid floating point). It turned out that 25 fps for live view is more common than I thought.
Can be activated at compilation time with OPT_VIEWPORT_DEBUG=1.
@reyalp
In case I decide to add this, is shooting_update_state() an appropriate place for such debug code? I chose it because it is called from an unconditional part of  kbd_process() .

*

Offline reyalp

  • ******
  • 12630
Re: vid_get_viewport_live_fb in video mode
« Reply #7 on: 01 / April / 2020, 02:23:59 »
Here's a possible visualization, for ports where active_viewport_buffer is declared.
The added debug line starts with viewport numbers in order as seen and ends with an approximate frames per second value (10x of the actual FPS to avoid floating point). It turned out that 25 fps for live view is more common than I thought.
Can be activated at compilation time with OPT_VIEWPORT_DEBUG=1.
That's very nice. Thanks.
Interestingly, on elph130 and elph180 FPS is 25 in normal live view and HD video recording, 30 in half press and VGA video. Haven't checked other cams.
edit:
Similar on sx160. Also, in very low light the frame rate goes down, to values ranging from 16 to 8.
D10 is 30 fps in live view and half press, also lower in low light.

Quote
In case I decide to add this, is shooting_update_state() an appropriate place for such debug code? I chose it because it is called from an unconditional part of  kbd_process() .
Seems fine to me for a debug thing like this.

Checked in, along with patch from blackhole and update for ixus150.
« Last Edit: 05 / April / 2020, 01:27:07 by reyalp »
Don't forget what the H stands for.


*

Offline reyalp

  • ******
  • 12630
Re: vid_get_viewport_live_fb in video mode
« Reply #8 on: 12 / April / 2020, 00:59:04 »
From looking at a few of these, I found some things that might be useful in the sig finders.

I've been using LiveImageTool.Pause to find viewport_buffers and active_viewport_buffer where it isn't already found.
The first (only) call is function that calls TakeSemaphoreStrictly, WaitForAnyEventFlagStrictly and then some function that references viewport_buffers (sx160 100a ff84d51c, elph130 100 ff076810)

That final function searches viewport_buffers for the current viewport address (similar to what we do on digic 6) and returns an index. On some cameras like sx160, the number of entries searched is a constant. On others like elph130, it's a byte field in the same structure as active_viewport_buffer which reflects the number buffers used (4 in still, 3 in video rec)

edit:
It appears that at least some of the 8 buffer cams use 4 in video https://chdk.setepontos.com/index.php?topic=14030.msg143180#msg143180
« Last Edit: 12 / April / 2020, 19:15:05 by reyalp »
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3156
    • Photos
Re: vid_get_viewport_live_fb in video mode
« Reply #9 on: 12 / April / 2020, 21:30:20 »
Here's a possible visualization, for ports where active_viewport_buffer is declared.
The added debug line starts with viewport numbers in order as seen and ends with an approximate frames per second value (10x of the actual FPS to avoid floating point). It turned out that 25 fps for live view is more common than I thought.
Can be activated at compilation time with OPT_VIEWPORT_DEBUG=1.
@reyalp
In case I decide to add this, is shooting_update_state() an appropriate place for such debug code? I chose it because it is called from an unconditional part of  kbd_process() .


This is really cool :)
Just tried it with the G12 and it showed me the 4 buffer assumption for still shooting was correct; but video was wrong - it uses 3 buffers.


Now I need to do all the other cameras.


Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)

 

Related Topics