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

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

--- "William M. Brack" <wb...@mm...> wrote:
>
> <snip>
>
> When the main Motion loop asks for a frame (which is controlled by your
> "framerate"), it is given the last complete frame obtained by the camera
> handling thread.  If this last complete frame is a duplicate, it is marked as
> such (if you run with a non-zero debug level this will be logged as
> "vid_return_code 6").  If this condition continues for more than 30 seconds
> (this would likely indicate that the camera has died, or some other service
> interruption) Motion will supply a "Grey Picture" with some text indicating
> the condition.

I've been playing with it more today.  The problem I had yesterday was that it was actually saving
files that were duplicates.  I don't know why - I was getting about five frames per second, but
two or three of them at a time would be duplicates.  I would expect motion to recognize the
duplicate (like you say it does), and ignore it and wait until the next frame is available.

After your reply I turned on debugging and watched it give me the "vid_return_code 6" message
between every frame.  But it's not saving the duplicate images anymore, and I can't *make* it do
it any more either.  If I slow the camera waaaaay down to 1000 ms exposure times (one frame per
second), then motion just waits with the "vid_return_code 6" until the next frame is delivered. 
Just like I'd expect it to.

I played with the image size vs. framerate and found that motion gets about five fps with 250k
frames at 2048x1536.  So I'm leaving it at that for now.  The computer and camera are connected
via one Cisco 3600 at full duplex / 100mbit, so I can't imagine I could get the LAN speed any
higher.

> I really don't know anything about the Lumenera camera.  Would it be
> reasonable for you to reduce the image size / quality?  If not, would it make
> sense to reduce your framerate?  Can you suggest an enhancement to the logic I
> described which would help?

I was going to suggest that motion drop duplicate frames instead of save them - but since it
appears to be doing that, I'm happy.  Maybe those duplicates were a fluke?!  I can't think of
anything I've changed.  Motion seems to be doing it's job correctly now.

FYI, I've noticed that I can get motion to saturate 100% of CPU time now, where I never could get
it over about 50% before.  I assume this is because the frame-grabber thread runs in parallel with
the motion-comparing thread, and so it can keep the cpu busy comparing frames faster.  I'm getting
better framerates on netcams with this version than I ever got with previous versions.

Aaron


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