Re: [libdc1394-devel] detecting torn images

[Andy G. <and...@es...>]

Hi David,

thank you for your very detailed answer. It has been very useful.

Here are some answers to your questions :

David Moore wrote:
> On Mon, 2007-05-21 at 22:26 +0200, Andy Gotz wrote:
>   
>> All torn images have a horizontal swap at the hor. pixel 384. Out of 5 
>> torn images there are 3 that also have a vertical swap but all 3 at a 
>> different vert. pixel value.
>>     
>
> Could you send some examples?  The examples should be zoomed to 100%.
> Also, please tell me what packet size you are using for the image
> transfer and the color coding.
>
>   

For the packet size I use USE_MAX_AVAIL. We do not use colour because 
all our cameras are monchrome so far. I have attached a split image. I 
do not know if it zoomed the way you want it.
>> This often (almost always?) happens just after our weekly cron jobs run 
>> at 4 am in the morning (the most common command in the cron is 
>> makewhatis) on different pc's reading out 1, 2 or 3 cameras at 15 
>> frames/sec.
>>
>>     
>
> Dropped packets are usually a result of heavy bus activity, so this is
> consistent with that.
>
>   
>> We see the following error messages in the system log file :
>>
>> video1394_0: Waking up iso dma ctx=2
>>
>>     
>
> That means that your app didn't keep up with draining the buffers, and
> the queue stopped and had to be restarted once you dequeued enough
> packets.  This is probably a symptom of the general system slowdown
> caused by your cron jobs.  This in itself should not corrupt any frames
> though.
>
>   
>> My question is is there any way we can detect that an image is torn by 
>> analysing the  reply from the dc1394 calls or looking at the returned 
>> data ? If we could do this I can fix the torn images by stopping and 
>> starting the iso transmission.
>>     
>
> No, there is generally no way to detect this.  Unfortunately this is a
> limitation of the IIDC specification.  We may achieve greater robustness
> once we switch to the new Juju stack, but not with video1394.
>
>   

OK

> Does it automatically recover from the tearing after your cron jobs, or
> does it stay "stuck" for all successive frames?
>
>   

Stays stuck for all successive frames until I stop and start the iso 
transmission again.

> Here's a heuristic you could try:
>
> Generally the frame _following_ a corrupt frame will be dropped.  Thus,
> if your camera has a steady frame rate, examine the timestamps of each
> frame.  If a timestamp value suggests that there was a missing frame,
> it's a good bet that the frame _prior_ to that missing frame is corrupt.
> Try it and see.
>
>   

Thanks for this tip. Don Murray of PGR also gave me a good tip to detect 
the problem by inserting the frame counter in the image.

Andy