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

[William M. B. <wb...@mm...>]

aaron barrus said:
> --- "William M. Brack" <wb...@mm...> wrote:
>> OK, that was better.  The basic problem was caused by the "boundary-string"
>> for this camera.  The stream header has the string enclosed in quotation
>> marks
>> and (although that is legal according to specs) it is very unusual (no other
>> camera which I have tested had this problem).  Anyway, I have fixed that,
>> and
>> it should be available on tomorrow's (i.e. August 20) "daily snap".  Please
>> try it when you have the time, and let me know the results.
>>
>> Bill
>>
>
> Hi Bill,
>
> This morning I installed the daily snap motion-20050822-090555.  The boundary
> string being
> enclosed in quotes is solved and it connected to the netcam successfully.

Glad to hear that the first problem is solved!

> But it appears that the
> netcam buffer is now filling with duplicate images like I'd seen in an earlier
> version.  My
> framerate is set to 5, and I'm getting two or three duplicate images at a
> time.  Before it was
> because the image buffer hadn't filled up in time for the next image
> comparison, so it just
> grabbed the last image that was in the buffer and used it.
>
> If I grab the individual .jpg files seperately, instead of connecting to the
> mjpeg stream, the
> behavior is the same (duplicate images).
>
> I reverted back to 3.2.1 and the problem went away again.  So it must be
> something that has
> changed between 3.2.1 and the latest daily snap.
>
> Is there anything I could send to help fix this?  Has nobody else experienced
> this problem? I
> remember it was a big deal about a year ago.
>
> Thanks!
>
> Aaron

Well, the current handling of netcams is a complete re-write, so it's not too
surprising that there will be some differences.  With regard to "duplicate
images", I would suspect that it is more a problem related to the transfer
rate of the data than to the logic of the code.

With the "sniff" file which you previously supplied, the actual JPEG image for
the first frame had a Content-length of 270,642 bytes.  I don't know what kind
of a network connection you are using between your camera and the machine
running Motion, but that is a lot of data (probably close to 2 megabits by the
time HTTP and TCP overhead is included).

For your interest, the logic of the current netcam code sets up an independent
"thread" to take care of the camera (irrespective of whether it's streaming or
not).  If it's streaming, the thread fetches the data as fast as it's
available; if it's not streaming, the thread requests the next frame as soon
as the main Motion loop asks for the current one.

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 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?

Regards,

Bill