Re: FIELD_ALTERNATE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Gabor Kerenyi <wom@xxxxxxxxxxx> writes:

> No problem, on the Euresys card there is a chip which outputs
> the correct field and I can get the signal through GPIO.

Oh.  Ok.

> I tried to capture at full framerate but the result was not good
> enough. The frame rate was max. 2.5 fps/channel (4 channels).
> Previously I used FIELD_SEQ_TB and at that time I could
> manage to get 2.5 to 3.8 fps/channel. (for very short time 4.4)
> That time I used an algorithm something like this in the IRQ handler:
> 
> CapturePicture
> IF COUNTER>0 OR FIRST_FRAME=TOP
> 		switch channel
> 		IF (FIRST_FRAME=TOP) buffer->reserved[1]=TOP
> 		ELSE buffer->reserved[1]=BOTTOM
> 		COUNTER=0;
> ELSE
> 	COUNTER=COUNTER+1
> FI

Well, the driver absolutely isn't designed to be able to play such
tricks.  It pretty much depends on the "sync to start of odd field"
and "sync to start of even field" RISC instructions getting things
right.  It's probably very hard to fit in the external source telling
which field this really is.

Just fixing the field tag in the irq handler (after capture, at the
point where also the timestamp ist set) isn't a big issue.

I suspect the bt878 just throws away a field once it notices the field
order is out of sync.  And I absolutely don't see a way around that,
you can't fixup the sync risc instructions easily ...

> The disadvantage is when the second capture is made and we
> use the first field not the second one in the buffer we would not
> need to capture the second field.

If you don't need it you can already switch the input at that point...

  Gerd

-- 
/join #zonenkinder





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux