Circular buffer functionality

[gsh]

I've added some functionality into raspivid to implement a circular buffer recording mode, to get it you'll need to build the code for yourself

Code: Select all

on Raspberry Pi do this:

# git clone https://github.com/raspberrypi/userland
# cd userland
# ./buildme

What does this mean?

Basically the video is recorded continuously into a large memory buffer until it either receives a keypress or a SIGUSR1 signal from another application, it then writes the contents of the memory buffer into the file.

Why is it good, basically it means it doesn't keep writing video to the disk and therefore saves your SD card but gives you full speed H264 HD video terminating at the trigger time.

Usage:

Code: Select all

# raspivid -c -o [filename] {-k -s} -t [time_ms] -b [bitrate_bps]

Example:

Code: Select all

Record to circular buffer at rate of 10MBit and record 5 seconds, terminate by keypress

# raspivid -c -o out.h264 -k -t 5000 -b 10000000

Now you want to know what's the point of triggering on a signal...

So what you want to do is download the audio trigger software

Code: Select all

# git clone https://github.com/ghollingworth/audio_trigger
# make
# raspivid -c -o out.h264 -s &
# arecord -D hw:0,1 -f S16_LE | ./audio_trigger `pidof raspivid`
# omxplayer out.h264

What's it useful for:

1) Set up raspberry pi pointing at you on a golf range
2) start raspivid
3) hit the ball
4) watch the video


Just to note: It's not perfect yet, there are a few bugs in the way I track I-frames in the circular buffer but it works for five second clips (seems to have trouble with shorter clips...) Also I could do with fixing up audio_trigger to have a few more options such as a post trigger delay (to catch the follow through) and of course it's crying out for James to get the 90fps and 120fps options running!

[poing]

Great, I'll have a look later.

This would also be useful for a dashcam where you can press a button to record back in time or coupled with a shock sensor to help prove your innocence after a crash (while you could delete it if you're not that innocent )

[gsh]

Precisely the type of use I had in mind, a microphone would probably also work (just difficult to get the thresholds right)

Just to note I've changed the command line for my application, now just do

audio_trigger -h to list the commands:

example now is:

arecord -D hw:1,0 -f S16_LE | ./audio_trigger -p `pidof raspivid` -d 500 -t 200

This will send a signal to the raspivid process after a delay of 500ms after seeing a sound power greater than 200

Gordon

[mikerr]

Good idea on the delay after trigger before sending the signal
- then you get a video of a few seconds before AND video after the button press/trigger.

[ethanol100]

Thank you for the nice new feature, a circular buffer is a really useful.

I have modified your code a bit to be able to specify a time duration before and after getting a signal or keypress. It will fill the circular buffer, after getting the signal or keypress, it starts to write the new frames directly to a file. When it finished the recording, it fills the beginning of the file with the circular buffer.

Changes can be found here:https://github.com/ethanol100/userland/tree/preAndPost

There are many possibilities to trigger the second event(now it just changes to the simple timeout method, but you could use a second signal to stop the recording...) and a more general way would be better.

[gsh]

I'm not sure why this is required? What specifically is it you are trying to do ?

Gordon

[Steven Boelens]

I'm not sure why this is required? What specifically is it you are trying to do ?

Gordon

I can imagine several scenarios where pre and post timeouts would be usefull.
As dash-cam: When in a collision (auto-detected with accelerometer) I would like the 30 seconds before the crash as well as 1 minute after the crash.
As a burgler alarm: I would also like a few seconds before the alarm but also the first minute or so after the alarm was triggered.

You could also simply delay the trigger a minute and then (only using the pre feature) write the last minute and a half.

But then: If the RPi would die in the car-crash after 10 seconds (due to perhaps a second car crashing into a pileup) what would be recorded?
In case of the delayed trigger: Nothing. In case of the trigger with pre and post: the 30 seconds before the crash and the first 10 seconds after.

The same holds for the burgler alarm. If the burgler should happen to short-circuit the RPi nothing would be recorded in case of the delayed trigger. But with pre and post timeouts you would at least have something...

Steven.

[ethanol100]

I'm not sure why this is required? What specifically is it you are trying to do ?

Gordon

It is not required at all, it is just a small enhancement. I just would prefer a more generic method, your implementation is for a very specific use case. You can only take a video of prior defined fixed length, you are not able to pause recording or to split files. Do not get me wrong, the code is perfect for your use case. The modifications are really only some quick ideas and sugestions.

The advantages of my modifications:
a) record longer than fitting into memory: how much time can you put in the buffer? Default bitrate is 17MBIt/s, so about two minutes, if you would like to save three minutes( two before and one after the trigger)? you need to decrease quality.
b) It is difficult to delay a keypress event. (You could put a key behind a dart board and trigger the recording when a dart hits it, but how would you delay it?)

I would prefer even a more generic aproach, i.e. to connect the circular buffer directly to the "start/stop" recording events, then it could be used without limitations, but this would need major rearrangements/rewrite of the code.

One simple use case - a bird feeder: imagine a sensor detecting when a bird is eating. You get two events, entering the feeder and leaving the feeder. I would like to use the first event to trigger the ring buffer and the second event to trigger some delayed stop of the recording. Then again activate the ringbuffer and wait for the next bird... If I could just run raspivid with "raspivid -s -c 2000 --stop-delay 2000 -t 0 -o birds.h264", the user would be in full control of how raspivid starts and stops the recording.

I will think about it, but I see a big potential of many additional use cases.

[gsh]

Ah sorry I hadn't understood that post trigger it would continue to write to the SD card...

Makes sense... As for post trigger time, the circular buffer can do that fine if you just delay the signal like I do with audio_trigger. But as you say it means lots of memory (or very low bitrate) if you want to record lots (i.e. minutes)

Gordon

[gsh]

Submit a pull request to userland...

[AndrewS]

Reminds me of a wildlife documentary I saw where they were using a high-speed camera to film dolphins (or maybe it was whales) jumping out of the water. IIRC the camera they were using had some kind of circular buffer, and when they pressed the button after seeing a dolphin jumping out of the water, it then wrote out the 10 seconds from before the button-press as well as the next 30 seconds to the slower storage memory. Or something like that anyway

[Chris_Reynolds]

I remember that one, it was whales - amazing footage.

I've been spoofing something like this with my PIR triggered birdcam, I had raspivid taking 30 seconds vids and if a PIR interrupt occurred during the 30s it kept the vid, if not it deleted it.

The circular buffer is a much better idea, I'll be playing with it later - thanks Gordon.

[mogabe]

Is the preview in the begining of the buffer or at the end of the buffer using this new functionallity?

I would like have it set up so the preview is delayed 30 seconds and when i push a key the previous 5 seconds of the preview is written to the SD.

Some thing like the golf idea:
Hit the ball.
Go and watch the delayed preview
If it was a good swing, push a button to save it.
Repeat without restarting raspivid.

Is this an thing to add in the sourcecode? If it is i might try to do it.

[jamesh]

I'm afraid the preview is live. The only way I can think of to delay preview for any appreciable time would be to encode the data, store it in a buffer, and replay it at the delay period. This wouldn't be possible in 1080p30 as you will run out of GPU horsepower (encode/decode at same time). You might be able to use two Pi's to do it and stream encoded data from one to the other.

Some back of envelope calcs....1080p30 raw takes about 3MB/frame. So about 95MB/s. Not enough memory to an sensible delay. Encoded is about 1/50th of that, so about 2MB/s (thinking bits per second, 15 to 16Mbits/s is about right for decent image quality). So you get a lot of seconds available - 100MB = 50s. More than enough, the difficulty is decoding the buffer later whilst still encoding.

Interesting. I might, if I have time, have a play with something like that to see how well it works. I think a new app would be necessary though, don't want to clutter up raspistill too much - it's already getting a bit unwieldy.

[mogabe]

I did this in 720p30fps using pipes. Something like:
raspivid | circular buffer | hello_video
That worked very good. But gave me no option to save certain segments of the video.

Please let us know if you play around with something.

[ethanol100]

I'm afraid the preview is live. The only way I can think of to delay preview for any appreciable time would be to encode the data, store it in a buffer, and replay it at the delay period. This wouldn't be possible in 1080p30 as you will run out of GPU horsepower (encode/decode at same time). You might be able to use two Pi's to do it and stream encoded data from one to the other.

Wouldn't the --penc option do something similar to encode and decode at the same time? Couldn't we store the buffer into another mmal pool prior to sending to the preview? And returning each buffer back to the pool, then we could even loop through the pool and wait until a key is pressed(ie. enter to save, esc to discard the recording)?

And we could pause encoding while looking at the recorded part and restart encoding after we have decide if we want to keep the last recording. Then we should have enough "horse" power. Something like instant replay.

[jamesh]

I'm afraid the preview is live. The only way I can think of to delay preview for any appreciable time would be to encode the data, store it in a buffer, and replay it at the delay period. This wouldn't be possible in 1080p30 as you will run out of GPU horsepower (encode/decode at same time). You might be able to use two Pi's to do it and stream encoded data from one to the other.

Wouldn't the --penc option do something similar to encode and decode at the same time? Couldn't we store the buffer into another mmal pool prior to sending to the preview? And returning each buffer back to the pool, then we could even loop through the pool and wait until a key is pressed(ie. enter to save, esc to discard the recording)?

And we could pause encoding while looking at the recorded part and restart encoding after we have decide if we want to keep the last recording. Then we should have enough "horse" power. Something like instant replay.

Not really, any sort of delay requires buffering. The preview is the same resolution as the recording (maybe scaled to the display), but I wonder if you have a small preview you could buffer that as raw YUV. WOUdl reduce total time for delay, but might allow you to delay the preview with the decode step.

[gaitskell]

Is there a way to built in elementary logic into the new buffer option to create a trigger to save the circular buffer if the video frames change significantly? A motion trigger, without using an external PIR, or audio?

I would like to implement this at 90 fps/VGA video mode.

Thanks,

[AndrewS]

Is there a way to built in elementary logic into the new buffer option to create a trigger to save the circular buffer if the video frames change significantly? A motion trigger, without using an external PIR, or audio?

I would like to implement this at 90 fps/VGA video mode.

It might be possible to do something like that using the picamera Python library, but you'll probably have to do quite a bit of experimentation...

[charliedk]

Hi everyone!

Was looking for a code like this and finally found it! Can someone, please, answer a couple of questions

I want to implement this program, the ethanol100 modified code, with the piface digital io and activate the recording trough a external signal.

How can I add the piface library to this project?
Piface Library http://piface.github.io/libpifacedigital/

In wich part of the code must i write the digital reading interruption? I know the correct file is Raspivid.c but i can't see where to put them.

[jherard]

HI, im soo confuse on how to use circular buffer, can someone guide me please
this command line:
raspiyuv --rgb --timelapse 250 --timeout 10000 (can be run infinitly if wanted) --width 320 --height 240 --output /home/pi/camera/image_%05d --verbose --nopreview -bm

i wanna run, it with somekind of ring buffer, like python code buffer so i can process images use it to try and detect obstacles, when moving.
this takes iamges 4fps, which give us 0.25ms for image processing.

i hope someone can help me thank you, apologise in advance if this is not the right place i read about the post and
it mentioned circular buffer.

[ripop]

I want something that does almost exactly what this does, but for audio only (not video). Any ideas how to modify this code for that purpose, or pointers to other projects? Thanks.

[Dwek]

Hi,

I'm continually getting a Kernel panic when running the below command.
Can I confirm that the updated version of raspivid works on the latest version of RASPBIAN.

raspivid -c -o out.h264 -k -t 5000 -b 10000000

I'm under time pressure to get a live 4-5sec delay loop going from a raspberry Pi B using a Pi Cam via HDMI for use for archery practice. i.e. pointed at the archer for them to review between arrows.
Initially I would be OK with the audio trigger or a simple in memory continual loop (no recording is OK). Prefer no keyboard and auto start.

Second phase considerations over time:
1/ Storage of the 4-5 sec of recorded (delayed playback windows only) video onto the SD card, over a session of up to 2 hrs. This would be used to review the practice session (just the action) by the archer or the coach. A recommendation based on resolution and record duration for the SD card size (didn't want waste money getting the wrong size. Maybe just buy a 64G).
2/ Maybe a foot button and/or movement option for playback of previous 4-5 sec if the environment is noisy. Option to be provided without keyboard. i.e. simple to use, options to be selected via momentary switches.
3/ Nice to think it could be used as a stills camera which stores onto the SD Card.
4/ wifi access to get the video storage off the SD card.
5/ method to playback stored video on the device on the primary display without the use of a keyboard. It would be cool to have the option to playback on the archery range, before taking the Pi inside to review. I'm looking at using a 12V monitor and 12V to USB converter to power the unit where powerpoints don't exist.
7/ Second camera option to also record the target. This would be great if a picture in picture option was provided. Makes it great to review archer position/stature and result (the arrow hit the target).
Need a long cord or BT/Wifi between cameras to achieve field distance without the need for expensive optics. Maybe another Raspberry Pi could be used for this.

Is there a clone image available with a version that I can load to get the first part going?

This is not for commercial sale or profit. I'm just trying to help a mate out who is practicing for a competition.

Thanks in advance.
Appreciate any assistance.

[Iconic Zombie]

So... I'm sorry that I'm that guy. I'm new to Rbp and I am trying to rig one up to a CCTV camera and delay the live feed for a few seconds to use it as an instant replay device. I manage a trampoline park, we have 3 lanes and three cameras, I can get a unit for each. I want to have an intermittent delay on what the camera picks up. Any thoughts?

[jpencausse]

Hi,
Does this feature still require to compile the code ?

My use case is:
1. I have an external trigger (anything: HTTP request, IoT, sound, etc ...)
2. I start/call Raspivid using CLI: It store the 5s pre-buffer + the following video
3. I stop/call Raspivid using CLI: It stop recording
4. Otherwise it stops after a given timeout

- I understand I must set a duration ? Is there a way not to set a duration to stop it when I want ?
- I want to call CLI throught NodeJS and send clips later in Wifi did someone already did that ?
- What about chaining event start/stop/start/stop ?
- Any tutorial on this coool feature ?

Thanks !