Two Circular Streams Possible?

[gabedowney]

For a sports training application I'm trying to design something that will initiate a circular buffer, and on trigger record the past x seconds and next x seconds, auto-convert from h264 to mp4, and then play, ultimately re-looping back into the buffer.

I have that working using python and cribbing from the python picamera documentation. What I'm trying to achieve is to add a second circular buffer that will record at a different FPS, resolution, etc.

Is it possible to record two circular buffers and record as outlined above on one pi and camera? I can paste code, but if it's an impossibility I don't know if that's germane. And I have essentially no programming background, but happy to research as needed.

Thanks for any insight.

[jbeale]

I'm pretty sure that you cannot record at two different frame rates at once, with the possible exception of integer sub-multiples (eg. drop every other frame). I haven't heard of anyone trying to do more than one pre-trigger buffer.

[gabedowney]

Thanks for the reply, that's what I was suspecting. It does look like Openmax could do it, but everything I've read leads me to think that's beyond my capabilities. Any other alternatives you can think of (other than that)?

[6by9]

No, openmax can't do it. Whilst the camera component has both preview and video encode ports, the resolutions must match (or you get no preview output), and the encode framerate takes precedence to the preview port

[gabedowney]

This might be a dumb question - but is the preview aspect the issue? Would it be possible to simultaneously record at different fps without preview? Thought being, I could record from circular buffers/streams (not sure if the terminology is interchangeable) on trigger, change to mp4 (or whatever), and replay on command following the recording if preview is the sticking point.

[6by9]

No, unless you drop of frames to give an integer reduction in frame rate as jbeale has already suggested.
You have a single sensor producing frames at a specified rate. There is no way you can produce an arbitrary framerate from that without some very involved interpolation between frames.

Note that if you want to do an integer reduction, you will have to encode the two streams independently as H264 uses previous frames for reference, so you can't drop those frames.

Looking at your original requirement, raspivid will almost do that for you with the trigger mode. If you take that, and then also set a counter to record the next N frames too, you've got the H264 source frames you wanted.

[gabedowney]

Sounds good, thanks again to you both for the guidance. I'll play towards that end for a bit -- if nothing else maybe I can just slo-mo omxplayer on the replay. Sub-ideal but a decent workaround.

[toli0002]

Hi gabedowney

My Daughter is into Gymnastics and could really use a training Cam that replay's the last 15 seconds.
May I ask if you could share some coding of your "sports training application"?

Thanks' in advance

Regards toli0002

[gabedowney]

By all means, this is pretty rough and somewhat tailored to a specific need, but I'm sure that it can be adapted to work. I have a few notes in there which hopefully will help. I currently have a keyboard trigger in there, ultimately I plan to use a laser-break or something similar instead, but this is a stand-in for now. The test video thing is simply a place-holder for slow-mo if I can figure that out, my intention being to replay in real speed, then slow motion, then real speed again (the test video is part of a different project where I want it to sync up with a 'perfect' example. It's all stolen from one place or another and cobbled together, if you find any good fixes please let me know and if I can be of any help feel free to contact directly gdowney@ku.edu:

from __future__ import print_function
try:
input = raw_input
except NameError:
pass

import io
import sys
import picamera
from select import select
import subprocess
from subprocess import call
from subprocess import Popen
import os
import time

#The various /media/test1/… files are on a jump drive, used to test importing and exporting files for view through the pi and for not overly writing to and erasing the SD Card. Test Repo is #output for video capture, Test Videos is stock footage.

cmd = “MP4Box –add /media/test1/TestRepo/wtest.h264 /media/test1/TestRepo/wtest.mp4”
omx = “omxplayer /media/test1/TestRepo/wtest.mp4”
omxs = “omxplayer /media/test1/TestVideos/Lindberg.avi”

#Parameters for recording – 1080P for 25-30fps being primary objective; start circular stream, start recording and overwriting from circular stream. 9 seconds seems about proper amount of #recording time, that will need to be adjusted eventually.
#keyboard inputs (q and w) used temporarily to simulate triggered event

with picamera.PiCamera() as camera:
camera.resolution = (1920,1080)
camera.vflip = True
camera.hflip = True
camera.exposure_mode = ‘sports’
camera.start_preview()
stream = picamera.PiCameraCircularIO(camera, seconds = 9)
camera.start_recording(stream, format=’h264’)
while camera.recording:
while True:
camera.wait_recording(0.5)
r, w, x = select([sys.stdin], [], [], 0.5)
if r:
break
c = input()
if c == ‘q’:
camera.stop_recording()
camera.stop_preview()
elif c == ‘w’:
time.sleep(5)
with stream.lock:
for frame in stream.frame:
if frame.header:
stream.seek(frame.position)
break
with io.open(‘/media/test1/TestRepo/wtest.h264’, ‘wb’) as output:
while True:
buf = stream.read()
if not buf:
break
output.write(buf)

#Convert video file from h264 to mp4 via MP4Box
call([cmd],shell=True)
camera.stop_preview()
#Play video via omxplayer
call([omx],shell=True)
#Play video in slow motion (incomplete). Lindberg video is used simply as a different file to better recognize slow motion attempts, eventually this will be the same video replayed.
call([omxs],shell=True)
camera.start_preview()
os.remove(“/media/test1/TestRepo/wtest.h264”)
os.rename(“/media/test1/TestRepo/wtest.mp4”, time.strftime(“/media/test1/TestRepo/%y%m%d%H%M%S.mp4”)