Darkwind & Hackeron Motion Patching
Description of Patch
- smooth_video: bool - as explained in http://www.lavrsen.dk/twiki/bin/view/Motion/SmoothVideoFromEventStartToStop
- extpipe: string - forks a process and writes raw yuv420 to stdin
- useextpipe: bool - enables or disable the use of extpipe
- maxdetect_fps: int - allows you to change motion detection fps without affecting output framerate
- cameraname: string - allows you to set camera and use from %e
- text_user: string - allows you to use an extra text_variable (e.g. for audio device) and use with %g
- force_framerate: bool - if set to yes, forces framerate set - useful with smooth_video
- %e = value defined by cameraname
- %g = value defined by text_user
- %fps = movie fps
- %us = microsecond
- STATIC_OBJECT_TIME increased to 30
- Lightswitch changed from 5 to 20 frames
- Gap is no longer ignored if max_movie_time is set
Effective Use of extpipe
This is the command use I with extpipe to achieve realtime 8x25fps x264 encoding:
- mencoder -noskip -demuxer rawvideo -rawvideo w=640:h=480:i420 -ovc x264 -x264encopts bframes=3:frameref=1:subq=2:scenecut=-1:nob_adapt:threads=1:keyint=1000:8x8dct:vbv_bufsize=4000:crf=22:partitions=i8x8,i4x4:vbv_maxrate=1000:no-chroma-me -vf pp=lb,denoise3d=8:6:24:4 -of avi -o "%f.avi" - -fps %fps
To explain the command:
- -noskip ensures duplicate frames are not dropped so if you're recording audio, you get perfect a/v sync
- -demuxer rawvideo -rawvideo w=640:h=480:i420 makes sure motion understands the stream piped by motion
- -x264encopts play with these to increase encoding performance and or quality. crf=22 is fair quality at high framerate, try increasing it for better compression or reducing it down to 16 or 12 at lower framerate.
- -vf pp=lb,denoise3d=8:6:24:4 basic deinterlacing and denoising, improves compression a lot but blurs text.
- -of avi -o "%f.avi" - -fps %fps sets output file format and makes sure the correct fps is used.
Absolutely Amazing Results
Here is top showing 8x25fps detecting and 7 mencoder processes encoding x264 and the CPU is still 34% idle! (Intel Core2Quad
top - 12:45:20 up 7:46, 4 users, load average: 1.86, 0.88, 0.79 Tasks: 125 total, 4 running, 121 sleeping, 0 stopped, 0 zombie Cpu(s): 13.1%us, 9.6%sy, 43.0%ni, 34.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 1028096k total, 1018728k used, 9368k free, 24468k buffers Swap: 3012148k total, 29184k used, 2982964k free, 462020k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4730 fusecctv 39 19 58068 17m 2232 S 27 1.8 0:05.93 mencoder 4412 fusecctv 39 19 58320 18m 2232 S 26 1.8 0:08.96 mencoder 4431 fusecctv 39 19 58324 17m 2232 S 26 1.8 0:08.80 mencoder 4438 fusecctv 39 19 58632 18m 2232 R 25 1.8 0:09.19 mencoder 4394 fusecctv 39 19 58476 18m 2232 S 25 1.8 0:08.85 mencoder 4424 fusecctv 39 19 58140 17m 2232 S 25 1.8 0:08.75 mencoder 4467 fusecctv 39 19 58332 17m 2232 R 25 1.8 0:08.52 mencoder 4362 fusecctv 20 0 136m 28m 4416 S 10 2.9 0:03.37 motion 4374 fusecctv 20 0 200m 28m 4416 S 10 2.9 0:03.31 motion 4360 fusecctv 20 0 136m 28m 4416 S 10 2.9 0:03.40 motion 4372 fusecctv 20 0 136m 28m 4416 S 10 2.9 0:03.42 motion 4356 fusecctv 20 0 136m 28m 4416 S 9 2.9 0:03.00 motion 4364 fusecctv 20 0 200m 28m 4416 S 9 2.9 0:02.93 motion 4369 fusecctv 20 0 136m 28m 4416 S 9 2.9 0:03.13 motion 4358 fusecctv 20 0 136m 28m 4416 S 4 2.8 0:01.73 motion
Installation of Patch
Download the patch file. If it is packed as a gz or tar.gz unpack it first. Then copy it to the motion source directory and issue the command (assuming the patch file is called filename_of_patch_file.diff)
patch < filename_of_patch_file.diff
Then re-build Motion and test the patch.
Change History of Patch
External pipe patch included in svn trunk r395 , added some missing features like create path when destination doesn't exist.
- 28 Jul 2008
Have looked at the smooth_video part. There is some parts of it that needs improvments.
1. Increase the ring buffer by one and keep on entry as "previous" image. This to avoid copy the picture to improve performance. This can be tricky to get right but I think the performance is important.
2. Timestamping of the images. If using a v4l device the driver can timestamp the image when it is captured. This patch timestamps the images when the motion lops take the image from the video layer. V4l2 layer have buffered 4 frames and gives out the oldest one. This results in a timestamp that is at least 4 frames old. So use the driver timestamp it can be even more accurate timestamp / smother video. The problem here is that I don't know how the plans is for v4 and plug ins. Is it possible to let the driver / video capture layer timestamp the images?
3. Code to output images to video is both in process_image_ring and motion loop. I think it is best to only have it on one place, in process_image_ring.
- 05 Aug 2008
To respond to Dag's comments:
1) This certainly sounds reasonable. I'll take a look at implementing this.
2) While that may be true, I haven't changed the location of the timestamping from previous versions; just the resolution. Someone care to take a stab at moving the timestamp elsewhere? =)
3) Again, I'd certainly agree that having the code in one place is better than two. Placing it in process_image_ring, as it's written today, would cause the same issues as seen before when there was motion, then a lull, then motion again; tens, if not hundreds of frames were sent to the encoder, resulting in poor performance and lost motion events. I'll take a stab at this one too and post the resulting patch for testing.
Perhaps smooth_video is a bad name for the option; it DOES create smooth video output, but it does so by simply outputting every frame from motion_detected - precap_frames to the end of the event.
- 06 Aug 2008
Currently active http://www.lavrsen.dk/twiki/bin/view/Motion/SmoothVideoFromEventStartToStop
Others have been integrated in trunk, discarted or need more work.
- 25 Oct 2008