omxmotion - Raspberry Pi Forums

this may of interest some.

i've been interested in openmax , pi's camera module while now, , got around doing them both. using h.264 encoder's motion vector output, i've knocked simple motion detection , capture program. it's bit basic, seems work.

currently, supports 'heatmap' of regions monitor, 64-128 frames (as compiled out of box) of pre-trigger recording, variable length post-motion recording, variable bitrate output, , ability dump last 65536 frames of motion vectors pngs (which useful debugging). @ 16mb/s, uses around 40% cpu on un-overclocked pi model b (original 256mb version) in around 14mb ram. it's limited 1920x1088 atm (as can't see crop camera's output image).

there appear bug somewhere, in frames appear corrupted. not sure what's going on there, i'll spot @ point. might abuse of h.264, i'm not seeing errors on playback.

it's available @ https://github.com/dickontoo/omxmotion. questions, shout.

brave man going il. ok allegedly open, except proposals got accepted never rolled spec, pig work in form. quick @ android codec handling (omxcodec.cpp) give idea on quirks google had accept work different manufacturers' kit. full credit getting going, don't expect support.

reading code:

code: select all

/* clock doesn't bloody work reason. ignore bit. */

when recording you're not waiting start event, want know wall time each frame. if present, audio used sync wall clock sampling rate. setup set clock stopped, components ready run, start clock. components told of clock state update , start running (iirc in il spec). don't appear using buffer timestamps, has no impact, , timestamp has limited use in case anyway.
video has no reference clock - running off same stc wall clock.

nframeheight can multiple of 2. nsliceheight needs multiple of 16.
nframewidth can multiple of 2, nstride has constraints (multiple of 32 yuv formats). you've found, set 0 , component should set appropriately you.

cropping output image? ie change field of view, or after totally different resolution somewhere?
fov can controlled through omx_indexconfigcommondigitalzoom straight centred zoom (and reduce output resolution if want crop), omx_indexconfiginputcroppercentages arbitrary crop (and again alter output resolution). either case affect whole encode path, motion vectors looking @ different portion of image.
hardware can't produce multiple arbitrary resolutions, i'm afraid can't totally different resolution.

corrupted frames? form of corruption? i'm assuming it's not 0 motion vectors off i-frame prediction @ whatever intra-i rate is.

raspberrypi