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

[aaron b. <as_...@ya...>]

--- Kenneth Lavrsen <ke...@la...> wrote:

> Motion 3.2.3 has the following feature.
> 
> 
> JPEG Netcams
> - Motion tries to fetch an image once every 1/framerate seconds.
> - When the netcam fails to deliver an image - motion simply copies the 
> previous image to fill in and maintain the framerate. This gives the 
> duplicate images.
> - If the netcam fails for 30 seconds the duplicate images are replaced by a 
> grey image with an error message
> 
> MJPEG
> - Here the netcam sets the pace. Motion receives pictures at the rate the 
> camera decides (and has been set up for).
> - If Motion is set for a framerate lower than the camera it throw away some 
> of the images.
> - If Motion is set for a framerate higher than the camera it adds duplicate 
> images.
> - If the netcam fails for 30 seconds the duplicate images are replaced by a 
> grey image with an error message

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?

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.

> Now obviously this duplicate image thing may not be 100% smart.
> So in the next version we try to be more flexible.
> There is one requirement. We MUST run through the motion main loop once per 
> second and better twice per second. Otherwise certain services such as 
> allowing webcams to connect and maintain the webcam stream will not work.
> 
> The current two ideas we work with are.
> 
> JPEG
> - Motion fetches an image once every 1/framerate
> - If the camera is slow Motion will WAIT a limited period.
> - If the period times out Motion will add a copy of the previous image. So 
> only duplicate images when the Netcam gets really slow or disconnected.
> - If the netcam fails for 30 seconds the duplicate images are replaced by a 
> grey image with an error message
> 
> MJPEG
> - Here the netcam sets the pace. Motion receives pictures at the rate the 
> camera decides (and has been set up for).
> - If Motion is set for a framerate lower than the camera it throw away some 
> of the images.
> - If Motion is set for a framerate higher than the camera it will wait a 
> certain limited period for the next image to arrive. The arrival of an 
> image will reset the loop timer so that Motion will not try and catch up 
> but just timeshift a little each time it waits. The result is that Motion 
> in reality runs at the framerate of the network camera.
> - If the netcam fails for 30 seconds the duplicate images are replaced by a 
> grey image with an error message
> 
> The LIMITED period can be set to different values with different results. I 
> have no plan to make it a configurable parameter. We have been discussing a 
> 1/framerate period. This requires that the framerate of Motion is MAX 1 
> higher than the mjpeg stream. And it does not leave much time for a delay 
> of a jpeg camera before duplicate images are added. But it does gove more 
> images to feed to a movie file so it does not jump in speed.
> 
> What I am thinking is better is a fixed 0.5 second timeout. It ensures that 
> the webcam feature works and it makes Motion much easier to setup and will 
> cause much less duplicate images. I think this is the best solution but I 
> am open to oppinions.

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?

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?



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs