From: Ken A S. <ks...@se...> - 2007-11-28 22:31:23
|
I am running motion on a resource limited box. I was wondering if it could do a motion calc on a lower resolution (like 352x288) but store image/movies at full (say 640x480) resolution. I looked at the alg.c code (alg-diff, alg-diff-fast, and alg-diff-standard) to try and figure this out but am I am hindered by not being a c-programmer. It seems that perhaps doing the motion pixel comparison only on, say, every 3rd row and column (where the 3 might be a configurable parameter) would be pretty equivalent to using a lower resolution calc. It seem that it would be quicker (less resource intensive) and still be quite representative for evaluating the full image. Think of it as stripe-ing the image both horiz. and vertically and evaluating only the strips. Does this make sense and how does it compare to the current algorithm? Thanks in advance. Ken -- Ken A Scott ks...@se... |
From: Joerg W. <mo...@al...> - 2007-11-29 08:59:10
|
Ken, when Motion is idle, we do not evaluate every pixel, but a very limited subset only. Only when Motion suspects something interresting, the full image is inspected. Do you actually have any kind of resource problems today or is that just a question about how to best save resources in order not to get any resource problems? Maybe you can post your config and describe some more detail about how you are using motion. We could then have a closer look and give some advice. It is also important to know what version of Motion you are running. Brgds Joerg. Am Mittwoch, 28. November 2007 23:31 schrieb Ken A Scott: > I am running motion on a resource limited box. I was wondering > if it could do a motion calc on a lower resolution (like 352x288) > but store image/movies at full (say 640x480) resolution. > I looked at the alg.c code (alg-diff, alg-diff-fast, and > alg-diff-standard) to try and figure this out but am I am > hindered by not being a c-programmer. It seems that perhaps > doing the motion pixel comparison only on, say, every 3rd row > and column (where the 3 might be a configurable parameter) would > be pretty equivalent to using a lower resolution calc. It seem > that it would be quicker (less resource intensive) and still be > quite representative for evaluating the full image. Think of it > as stripe-ing the image both horiz. and vertically and evaluating > only the strips. > Does this make sense and how does it compare to the current > algorithm? > Thanks in advance. > Ken |