By Date: <-- -->
By Thread: <-- -->

Add V4L2_FIELD_ALTERNATE support to SAA7134

HI, Chis

Chris Byrne wrote: 
Hartmut Hackmann wrote:

Hi, Chris

Chris Byrne wrote:

- Adds V4L2_FIELD_ALTERNATE support to the saa7134 driver
- Fixed field swap in non-interlaced modes (bottom = top)

Signed-off-by: Chris Byrne <chris.byrne (at) monstavision.com>

<snip>

I must say:
I don't understand your second patch because at non-interlace,
top and bottom field are identical by definition.


Sorry, I wasn't being clear. By non-interlaced modes I am referring to non interleaving modes (e.g. V4L2_FIELD_TOP, V4L2_FIELD_BOTTOM) which only contain a single field. This is in contrast to say V4L2_FIELD_INTERLACED which returns both fields interleaved to create a single frame.

Perhaps I'm misunderstanding you but the top and bottom fields are not identical. There is a one line offset difference between them. Depending on your input it can be quite obvious when they are swapped.

So you are talking about capturing only one field type out of a regular
interlaced input?
The expression Top or bottom field is misleading. It depends on which
of the half lines you drop. I need to roll this up myself but as far as
i remember, the definition top or bottom field depends on whether you are
in the 50Hz world or in the 60Hz world.
If you change things here you do not even have to keep the line interleaving
into account but also the time sequence.

I don't claim that things are perfectly right in the current implementation,
but i know that things go right with known applications in interlaced mode
and i am afraid of breaking something here.

How about:
- Corrected top and bottom fields being swapped when capturing fields instead of frames

Maybe, but lets check everything carefully before we do this.

But you should set the option noninterlaced=1 to saa7134.ko
We should make this the default, it can be left active at
interlace.


I'm unsure what this would accomplish. Setting this forces the field identification to toggle regardless of the input. Problem is that the fields are being misidentified in the first place.

Thats not correct. It forces the field ID to toggle even at non interlaced
input. This is necessary to get both DMA buffer types filled. In the case
of interlace, the field ID will be resynchronised at the first transition
to an odd field. So in worst case, the first frame is wrong but afterwards,
things definitely are right.

I can imagine 2 reasons for your corrupted image problem:
- either a buffer collision
- or a DMA buffer overflow in the SAA7134 due to excessive
  load on the PCI bus. Note that there is a recovery algorithm
  that prevents total image corruption.


Ok, thanks. I'll have a look to see if the recovery algorithm is taking effect. It is just very strange that the same line is being corrupted on two different machines.

The recovery occurs inside the SAA713x.
Not sure but i guess that your patch swaps the buffer handling. Things should
work as follows: Lets assume we capture the odd (first) field. The DMA engine
will use register set 1. At vsync, the engine automatically switches to
register set 2 and issue an interrupt with the flag for field 1. The driver
now has 1 field time to prepare the buffer for the next odd field (and to
update the appropriate registers). At the next vsync the same happens for the
other register set.
If you now swap things on only one side, the timing becomes critical.

This sounds trivial but it is not easy to observe. This bug existed in the TS
interface and it took a long time before i noticed and corrected this.

Best regards
   Hartmut

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list