Support for Video Buffer lower than 1000

[emjas92]

Because the Video Buffer setting is based on frame memory size rather than time, the minimum of 1000 still results in many minutes of black frames at night before the motion is detected (security lights come on).

I'd appreciate it if the setting could be decreased further as I'd still like to capture a few seconds before the motion event in case the light is already on.

Currently setting the buffer to <1000 breaks motion detection altogether (camera runs, but no motion is detected).

I'm happy to try update and compile the code myself if you think this is possible and can point me in the right direction.

Thanks again.

[roberttidey]

I am not sure at the moment why that would affect motion sensing but I'll investigate when I get a bit of time.

The core raspimjpeg code is at https://github.com/roberttidey/userland

under host_applications/linux/apps/raspicam

The buffer size is set in RaspiMCam.c using function cam_set_buffer ()

It is based on the video bit rate setting and this defaults to 17Mb/s which can be quite a bit higher than what is seen in a well compressed static scene. One thing you could try is reducing that setting.

[username7291]

Yes should not affect detection, i use 800 at the moment. MD works, be sure to enter at all "Period Start" "md 1;" Im still playing around with the remaining Video bugs. Open RaspiMCam.c and below cb_wptr = (cb_wptr + buffer->length) % cb_len; you paste: if (iframe_buff_wpos-iframe_buff_rpos>4) iframe_buff_rpos = (iframe_buff_rpos + 1) % IFRAME_BUFSIZE; That keeps last 4 keyframes(about 1 second Video), and drops everything else in the buffer(if any).

I use that to check if the overwrite check in the Code fails. The Intraframes should set to 4 with my configuration, but the debug output shows 5-8(on Days) means in a 800mS(880 kbytes) Buffer match 2000mS and 8 iframes?! Site effect of this Test is that the time from Motion Detection is shorter and should be constant, IF the MMAL_PARAMETER_INTRAPERIOD function is without issues.

[roberttidey]

Thanks for your work on this; sounds good.

I'd like to integrate in when finalised.

Couple of questions.

When you drop all but last 4 keyframes is that limiting the amount of video before motion that can be configured. One thought if it make sense is to make the 4 configurable or based on the buffer size parameter instead.

When you say 'check if overwrite check fails' are you referring to other code or is that just manually checking debug output?

[username7291]

In the h264encoder_buffer_callback there is a while() that checks if the new buffer from mmal overwrite a exists iframe. If it increase the rpos. That with 4 is just for checking if this works cause some videos are still have errors at the beginning(within the pre buffer). That fix the problem of absolute darkness of emjas. For public use it must be calculated. The number of iframes is set by the intraperiod, thats calculated by (videobufferfps)/4000. Means at 800 about 4/sec at 920 about 5/sec and so on. The Video Buffer size (bitrate/8videobuffer)/1000. If you want to make the mS user setting to work right you have to calculate that on the Intraperiod. It means too the videobuffer is a bit bigger/not always used at 100%, but the mS would be much more accurate. There is too a function that request an iframe if 1/4 of the bufferlen no iframe arrived(that should not required). The iframe request or changing intra while going from over buffer->record or special number of intra maybe could be too the cause of the remaining Video errors.