interlaced video question for you XV experts

[Matthias Hopf]

> |>Doing that properly usually requires to have at least the 2 next fields
> |>in advance in memory and the driver trigger the switch on the vblank irq
> |>to get perfectly sync'd, with the ability for the driver to "drop" a
> |>frame if it notices that it missed a field in order to never cause a
> |>field inversion. So the driver must know which field is contained in
> |>which buffer and which field will be displayed at next interrupt.

Typically the driver will have a weaved image that consists of 2 fields,
but the hardware will output one field after the other. Whether the
hardware gives you an interrupt on both fields, or only on the top field
or only on the bottom field is hardware dependend.

I tried to find that out on NVidia chips, but I've pretty much given up
on that topic. Maybe I'll try again some day. Maybe not, I'm more
interested in progressive video nowadays (mostly due to these common
problems).

Note there is no principal ordering, I prefer topfieldfirst, as it looks
more - err - like the natural way of doing it.
This has nothing to do with NTSC or PAL. Why should it, these are just
color encoding and resolution standards. It all depends on hardware.

> | So now I'm trying to figure out how you would tell a radeon chip to do
> | this. I see how to do this with a 640x525 buffer and set the output to

You mean x480 (NTSC)? The remaining lines are for sync & black shoulder
only, you should never ever have to mess with them, the chip should do
it.

> | Would I use a 640x262 buffer, set output to 60Hz interlaced with
> | DOUBLE_SCAN, and then swap the buffers on each vsync interrupt?
> | DOUBLE_SCAN causes each line to be read twice but since I swapped the
> | buffers it outputs two different halves of the frame.

Then you would get progressive scanned weaved fields. Effectively the
same as if you weaved the two fields together into a regular
framebuffer and output that one progressively.

There is another problem that could arise:
Most of the encoders have a 5 or even 7-tap line filter. As long as
this filter is enabled, you have to do interlaced material natively
or you will automatically blend the two fields together, which creates
horrible ghost images as well. On some of the chips you can either
disable this filter, or choose a native resolution like XXXx480 or
XXXx576. In these modes the filter is typically disabled, as you don't
need any deflickering.

> On interlace devices, it could make sense... but do TV-capable cards
> really output interlace to the TV-converter? I can only speak for SiS
> cards and they do not. The video bridge (=TV converter) takes care of
> converting non-interlaced output to interlace, and there is no way to
> control or find out which field is being shown at a certain time. So
> synchonizing is impossible.

It all depends how the encoder chip (Chrontel, BT, etc.) is set up.

AFAIK several graphics chips are not capable of feeding an interlaced
data stream to the encoder (SiS could very well be one of them). Others
can, but will only do with both the graphics chip and the encoder are
set up for interlaced material.

I *can* output interlaced material on almost any NVidia cards with TV
output I tried so far. But as long as the synchronization issue isn't
solved, this is no solution for me.

CU

Matthias

-- 
Matthias Hopf <mhopf at suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de