Add V4L2_FIELD_ALTERNATE support to SAA7134
- From: Chris Byrne <chris.byrne (at) monstavision.com>
- Date: Fri, 05 May 2006 10:30:02 +1200
Hartmut Hackmann wrote:
So you are talking about capturing only one field type out of a regular
interlaced input?
Yes, or in the case of V4L2_FIELD_ALTERNATE both fields one at a time.
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.
Personally I find the terms top and bottom confusing. I much prefer
referring to them as odd and even.
If you change things here you do not even have to keep the line
interleaving
into account but also the time sequence.
Correct. Without temporal seperation there would be no need for
deinterlacers...
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.
I understand and share the same concern. However, if you have a look at
saa7134-video.c in saa7134_irq_video_done (last function in the file):
http://linuxtv.org/hg/v4l-dvb?f=6553e1eaa6ca;file=linux/drivers/media/video/saa7134/saa7134-video.c;style=gitweb
In the current code:
For 'interlaced' modes (V4L2_FIELD_HAS_BOTH is true) we mark the top
field as being seen when (status & 0x10) == 0x00.
Otherwise when waiting for a top field (V4L2_FIELD_TOP) we _don't_
accept fields if ((status & 0x10) != 0x10). In other words we _accept_
the field as top if ((status & 0x10) == 0x10) or from another view
((status & 0x10) != 0x00)
Which means the top field for
frames: (status & 0x10) == 0x00
fields: (status & 0x10) != 0x00
So one of those conditions has to be wrong. Now based on observation I
would say the fields condition is incorrect. This is also backed up by a
post by Billy Biggs on 21st March 2003 who pointed out the fields in a
frame were swapped. A patch was applied to correct this but:
"Note this inversion will only apply to interlaced capturing, not to
single fields." - Tom Zoerner
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.
Thing is this line corruption occurs even without my patch...
Also if there was corruption of this nature I would expect some sort of
tearing where the top portion of the image has been overwritten.
Thanks for your help,
Chris
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list