Motion - Darkwind Hackeron Motion Patching
You are here: Foswiki>Motion Web>DarkwindHackeronMotionPatching (25 Oct 2008, AngelCarpintero)Edit Attach

Darkwind & Hackeron Motion Patching

Description of Patch

New Options

  • 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
New Variables
  • %e = value defined by cameraname
  • %g = value defined by text_user
  • %fps = movie fps
  • %us = microsecond
Changes
  • STATIC_OBJECT_TIME increased to 30
  • Lightswitch changed from 5 to 20 frames
Fixes
  • 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 Q6600):
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

  • 1.0 Initial revision

Discussion and Comments

External pipe patch included in svn trunk r395 , added some missing features like create path when destination doesn't exist.

-- AngelCarpintero - 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.

-- DagErlandsson - 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.

-- BillPayne - 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.

-- AngelCarpintero - 25 Oct 2008


Topic revision: r8 - 25 Oct 2008, AngelCarpintero
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Please do not email Kenneth for support questions (read why). Use the Support Requests page or join the Mailing List.
This website only use harmless session cookies. See Cookie Policy for details. By using this website you accept the use of these cookies.