Menu
▾
▴
Re: [Motion-user] libjpeg-turbo
|
From: Steve G. <sg...@gm...> - 2014-07-14 14:23:54
|
Actually it's probably encode or decode, but like I stated before the camera with native JPEG uses 1.7% to stream where YUYV camera uses 60%. GStreamer must encode YUYV frames to JPEG (this was more efficient then letting OpenCV grab the frame since it converts it to a Mat and I only need to decode 3 FPS for motion detection). The trick I use is that instead of doing inline encoding I save motion videos as MJPEG, thus I do not need to re-encode each frame. This takes almost no extra CPU. Then I submit the video to be encoded using OpenCV in another process, but you could use ffmpeg or gstreamer if they can read the X-Timestamp and create a VFR like H.264. OpenCV will use both cores if you compile with TBB. I also compile with NEON extensions as well. This has worked out for me pretty well on dual core ARM devices and doesn't impact capture even if 100% of the CPU is used during encoding. On Mon, Jul 14, 2014 at 4:56 AM, tosiara <to...@gm...> wrote: > Changing to YUYV palette drops motion's cpu usage during idle from 65% to > 38%. Kinda workaround for lower framerates (usually YUYV has maximum 10fps > while MJPEG can support 30fps). > > But I'm still curious: why MJPEG decode is co cpu expensive on ARM > platforms? > > > On Sun, Jul 13, 2014 at 7:45 PM, Steve Goldsmith <sg...@gm...> wrote: > >> OK, then that's really odd, since my 1280x720 @ 10 FPS JPEG camera uses >> only 1.7% of a single core. Can you try gstreamer and see what the results >> are? 80% for a native JPEG camera is not acceptable. Maybe isolate Motion >> decoding from frame acquisition? >> >> >> On Sun, Jul 13, 2014 at 12:39 PM, tosiara <to...@gm...> wrote: >> >>> Steve, >>> >>> I use a webcam which has MJPEG stream. >>> When I switch to RAW stream motion uses less cpu. But I need mjpeg, >>> because camera gives more fps with this format >>> >>> >>> On Sun, Jul 13, 2014 at 6:05 PM, Steve Goldsmith <sg...@gm...> >>> wrote: >>> >>>> My idle time using a MK808 dual core ARM at 1.2 MHz yielding ~19% idle >>>> time using 720P @ 10 FPS (the core obtaining the frames uses 1.7%). When >>>> you say v4l I'm assuming you are using a USB camera without native JPEG >>>> (i.e. RAW frames). I'm using gstreamer 1.0 to create a MJPEG stream from a >>>> USB camera. >>>> >>>> Tasks: 76 total, 1 running, 75 sleeping, 0 stopped, 0 zombie >>>> %Cpu(s): 19.1 us, 3.3 sy, 0.0 ni, 68.5 id, 0.2 wa, 0.0 hi, 8.9 >>>> si, 0.0 st >>>> KiB Mem: 971208 total, 324064 used, 647144 free, 101672 buffers >>>> KiB Swap: 0 total, 0 used, 0 free. 91164 cached >>>> Mem >>>> >>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ >>>> COMMAND >>>> 790 servadm+ 20 0 85864 26776 9904 S 58.2 2.8 589:17.13 >>>> python >>>> 856 servadm+ 20 0 53632 12892 10336 S 1.7 1.3 14:02.79 >>>> gst-launch+ >>>> >>>> Idle using raw frames 1280x960 @ 8 FPS uses ~60% CPU. >>>> >>>> Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie >>>> %Cpu(s): 60.3 us, 2.6 sy, 0.0 ni, 36.1 id, 0.0 wa, 0.0 hi, 1.0 >>>> si, 0.0 st >>>> KiB Mem: 971208 total, 547204 used, 424004 free, 141964 buffers >>>> KiB Swap: 0 total, 0 used, 0 free. 258440 cached >>>> Mem >>>> >>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ >>>> COMMAND >>>> 6873 servadm+ 20 0 91916 31788 9828 R 67.4 3.3 26459:37 >>>> python >>>> 6885 servadm+ 20 0 50324 14896 12852 S 60.7 1.5 23934:25 >>>> gst-launch+ >>>> >>>> Idle using raw frames (I'm processing more RAW pixels than you are >>>> 9216000 vs 9830400) and it's 25% more efficient without a turbo libjpeg. >>>> Maybe try using gstreamer for encoding and use it like a netcam in Motion. >>>> I haven't used Motion for a while now, so I'm not sure how to help beyond >>>> that. Switching to a USB camera with native JPEG encoding would fix the >>>> issue as well... >>>> >>>> gst-launch-1.0 v4l2src, timeout=15 ! video/x-raw, framerate=15/2, >>>> width=1280, height=960 ! jpegenc ! multipartmux boundary=cvp ! >>>> tcpclientsink port=9999 >>>> >>>> >>>> On Sun, Jul 13, 2014 at 4:53 AM, tosiara <to...@gm...> wrote: >>>> >>>>> Hi all, >>>>> >>>>> has anyone tried or heard anything about how could motion benefit from >>>>> libjpeg-turbo? This libjpeg wrapper has some ARM optimization and motion >>>>> supports turbo since SVN 544. However I can't make it faster. Either I'm >>>>> doing it wrong, or... >>>>> >>>>> I was expecting to get performance boost as it described for x86 >>>>> platform: >>>>> http://www.lavrsen.dk/foswiki/bin/view/Motion/FeatureRequest2010x04x14x082244 >>>>> >>>>> Current performance bottleneck for an ARM device (dual core A20, >>>>> reading V4L MJPEG) is: >>>>> >>>>> Each sample counts as 0.01 seconds. >>>>> % cumulative self self total >>>>> time seconds seconds calls ms/call ms/call name >>>>> 33.53 3.43 3.43 176 19.49 19.49 >>>>> *decode_jpeg_raw* >>>>> 22.87 5.77 2.34 90 26.00 26.00 >>>>> alg_diff_standard >>>>> 21.21 7.94 2.17 91 23.85 23.85 >>>>> alg_update_reference_frame >>>>> 16.62 9.64 1.70 176 9.66 29.15 mjpegtoyuv420p >>>>> >>>>> This way capturing 720p@10fps uses 80% of the cpu when idle. Top user >>>>> is *decode_jpeg_raw*. In other words, decoding JPEG frames utilizes >>>>> complete one core of the cpu. Which results in frame drops when video >>>>> encoding starts. >>>>> >>>>> Reducing cpu usage for JPEG decoding by using SIMD optimized libjpeg >>>>> would give motion more power for video encoding and reduce frame drops. >>>>> >>>>> Anyone tried (and succeeded) libjpeg-turbo on ARM? >>>>> >>>>> Thanks >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Motion-user mailing list >>>>> Mot...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/motion-user >>>>> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome >>>>> >>>>> >>>> >>>> >>>> -- >>>> Steven P. Goldsmith >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Motion-user mailing list >>>> Mot...@li... >>>> https://lists.sourceforge.net/lists/listinfo/motion-user >>>> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Motion-user mailing list >>> Mot...@li... >>> https://lists.sourceforge.net/lists/listinfo/motion-user >>> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome >>> >>> >> >> >> -- >> Steven P. Goldsmith >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Motion-user mailing list >> Mot...@li... >> https://lists.sourceforge.net/lists/listinfo/motion-user >> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome >> >> > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck® > Code Sight™ - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Motion-user mailing list > Mot...@li... > https://lists.sourceforge.net/lists/listinfo/motion-user > http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome > > -- Steven P. Goldsmith |
