Re: [Motion-user] Lumenera problem on v3.2.3 (now duplicate images)

[Kenneth L. <ke...@la...>]

>A couple of questions:
>
>The thread that grabs the picture from the netcam (jpeg or mjpeg) is 
>seperate from the thread that
>processes motion, correct?  So if the netcam thread delivers a duplicate 
>image to motion, will
>motion do the same processing on it?  Or when it sees that the image is 
>just a duplicate, will it
>abort processing on that image and move on?

Motion currently does not know if an image from a camera is the same it 
fetched maybe half a second ago.
Can you guarantee that the jpeg from an indoor camera in an office after 
hours would not keep on sending the same jpeg again and again. We want to 
be able to connect to the webcam and see for our selves that indeed the 
picture is there and noone is there.

Someone may want to detect that an image suddenly changes and then we want 
to process every frame to ensure the Motion detection works.


>I'd prefer the latter for a few reasons.  First (is selfish) I upload the 
>images, and duplicate
>images are just a waste of bandwidth.  Second, when compiling them into 
>video streams, the
>duplicate images cause an inconsistent playback speed.  Third, a netcam 
>will vary it's exposure
>time from 1ms during daylight to 1000ms (or whatever) at night, and motion 
>should be able to
>handle this wide range of framerates.

To know that a jpeg image is the same we have to download it first.
Unless you are lucky and the netcam sets some headers with a timestamp. I 
do not believe we can count on that from all netcams.

To save bandwidth you should run your camera in mjpeg mode if possible and 
set the framerate IN THE CAMERA to the one you want.
Then the camera decides when to send an image and it should always be a 
fresh image from the camera.


>As I said I dislike the duplicate images, and I agree that .5 would avoid 
>them in almost any
>circumstance, so I like that.  When motion asks the netcam thread for the 
>image, and the image
>isn't available yet, what exactly will wait?  Will the parent thread wait 
>for control to return
>from the netcam?  Or will the parent thread continue cycling through the 
>other threads in the
>meantime?

Each camera thread runs independently from the others.
One camera thread waiting does not at all affect the others.

http://www.lavrsen.dk/twiki/bin/view/Motion/OverviewOfThreadsInMotion


>For example, if I have a netcam that increases exposure to 500 ms at 
>night, then will motion stop
>processing the other cameras while it waits for the netcam thread to 
>return an image for up to .5
>seconds?  That could be a problem, especially with a mix of cameras all 
>running under the same
>parent thread.  Would it slow down all the other cameras to match the 
>single slowest camera in the
>group because it keeps stopping on that one waiting for the next image?

No. The other cameras continues at full speed.

Kenneth


-- 
Kenneth Lavrsen,
Glostrup, Denmark
ke...@la...
Home Page - http://www.lavrsen.dk