Re: Dropped fields with saa7134 (BMK MPEX)

[Björn Axelsson <bjorn.axelsson@xxxxxxxxxx>]

Hi Hartmut,

On Fri, 2005-12-23 at 01:00 +0100, Hartmut Hackmann wrote:
> Hi, Bjoern
> 
> Björn Axelsson wrote:
> > Hi,
> > while capturing raw interlaced PAL streams from a BMK MPEX card using
> > mmaped buffers I experience dropped fields. This means that the driver
> > doesn't fill in any data on the lines belonging to the field, and that
> > the frame timestamp is offset half a frame. 
> > 
> > It is always the top (first) field that is dropped, and never the bottom
> > field. This also happens quite often, about once every five minutes. It
> > doesn't seem to depend on CPU usage, since I'm not running out of
> > buffers.
> > 
> > I'm capturing on a dual opteron and kernel 2.6.12 with the realtime
> > preemption patch.
> > It looks to me like some sort of DMA congestion or just a missed
> > interrupt, but maybe someone else has experienced this and/or knows a
> > solution.
> > 
> > PS. Is there any official method of detecting dropped fields when
> > capturing in interlaced mode? My current solution is to write a known
> > value to the first two lines of the buffers before enqueing them, and
> > then checking for that value after a deque. 
> > 
> This should be investigated more closely.

Thank you. 

> You say you lose roughly 1 field out of 15000 and this quite regularly?

The "five minutes" estimation was a bad guess. Having measured it
exactly I see that I lose a field regularly every 46.32 seconds, with
some apparently random outliers (see below for data)

> For me this sounds not like a IRQ handling issue but more or less a time
> slip problem. I haven't dealt with the upper layers of the driver yet.
> Are you aware that in most environments really all time bases are not
> synchronised? This holds for the system clock vs video rate as well as
> video vs sound? The latter issue can be solved in the saa7134.

This sounds excellent. Are you thinking of the audio_clock_tweak module
parameter? Can a good value for the tweak be calculated automatically
from the field drop period?

> The problem might also come from the signal source since the saa7134
> has to follow the input field sequence. Please try the following:
> Switch to a av input but don't apply any signal. This causes the ICs
> timebase to run free at the nominal rate. Do the field drops occur
> here as well?

Yes, but with another period, though.

Here's some data I collected just now for a few minutes worth of
capturing:

Without video input (free running time base):
 Frames with dropped top field. 
 Timestamp            Time delta to previous drop
 1135300590.238291    -
 1135300629.943462    39.705171
 1135300715.964612    86.021150
 1135300755.669783    39.705171
 1135300795.374954    39.705171
 1135300835.080125    39.705171
 1135300921.101276    86.021151
 1135300960.806447    39.705171

With PAL video input from a camcorder (from tape):
 Frames with dropped top field. 
 Timestamp            Time delta to previous drop
 1135301106.389802    -
 1135301152.711798    46.321996
 1135301185.794221    33.082423
 1135301232.116218    46.321997
 1135301278.438215    46.321997
 1135301324.760211    46.321996
 1135301371.082205    46.321994
 1135301417.404195    46.321990
 1135301463.726183    46.321988
 1135301543.129589    79.403406
 1135301589.451559    46.321970
 1135301635.773537    46.321978

If it helps I can send you the complete logs (a few 100k of frame
timestamps) off-list.

> Ps: I will be out for some days and not be able to reply.

That is understandable. Have a happy holiday! :-)

-- 
Björn Axelsson                    Phone: +46-(0)90-200 13 02
Intinor AB                          Fax: +46-(0)920-757 10
www.intinor.se
Interactive Television & Digital Media Distribution

--

Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list