Nouveau - Jun 2009 - Syncing to vblank for interlaced video modes

Hello,

I'll start by applauding your efforts to make an open source driver for nv
hardware.  I imagine it is a very difficult task trying to reverse engineer
hardware and produce something useful and featureful.

I wish to make a change to the nouveau source.  You might say I am considering
becoming a nouveau developer.  I am one of those crazy nutters who connects my
nvidia card directly to a television via a vga2scart cable using interlaced
video modes.  As you are probably aware, interlaced video signals generate two
alternating half frames or 'fields', which the interlaced display
cleverly weaves together to form a full picture.

DVD playing software typically works by generating a progressive video stream by
combining two consecutive (first and second) fields to produce a full
progressive frame.  For the purpose of displaying true interlaced video (e.g.
DVD) to an interlaced television, without using deinterlacing, the full video
frames need to be written to the linear video buffer during the retrace after
the second frame is drawn, so that both fields are ready to be output in correct
order to the display.

The current proprietary drivers from nVidia synchronise buffer updates to the
retrace after each single half frame is drawn, which for the most part is not
satisfactory.  The symptoms of this are explained very well in this post ->
http://www.nvnews.net/vbulletin/showthread.php?t=95836

If I understand, the nouveau drivers currently use the standard vga crtc
registers to detect video retrace, and this results in the same behaviour. 
According to specifications I have seen from AMD, at least one Radeon series has
registers which tell which field(first or second) is currently being drawn, and
which field will be next.  I'm going to assume the nVidia cards have
something similar, and I'm hoping someone may either a) know this
information already so I can make a pretty simple change or b) suggest a way
that I might find out this information.

Sincerely,

Jamie.

-- 
Jamie Smith <hutts at internode.on.net>

On Sun, Jun 14, 2009 at 8:32 AM, Jamie Smith<hutts at internode.on.net>
wrote:
> Hello,
>
> I wish to make a change to the nouveau source.  You might say I am
considering becoming a nouveau developer.  I am one of those crazy nutters who
connects my nvidia card directly to a television via a vga2scart cable using
interlaced video modes.  As you are probably aware, interlaced video signals
generate two alternating half frames or 'fields', which the interlaced
display cleverly weaves together to form a full picture.
>
> DVD playing software typically works by generating a progressive video
stream by combining two consecutive (first and second) fields to produce a full
progressive frame.  For the purpose of displaying true interlaced video (e.g.
DVD) to an interlaced television, without using deinterlacing, the full video
frames need to be written to the linear video buffer during the retrace after
the second frame is drawn, so that both fields are ready to be output in correct
order to the display.
>
> The current proprietary drivers from nVidia synchronise buffer updates to
the retrace after each single half frame is drawn, which for the most part is
not satisfactory.  The symptoms of this are explained very well in this post
-> http://www.nvnews.net/vbulletin/showthread.php?t=95836
>
> If I understand, the nouveau drivers currently use the standard vga crtc
registers to detect video retrace, and this results in the same behaviour. 
According to specifications I have seen from AMD, at least one Radeon series has
registers which tell which field(first or second) is currently being drawn, and
which field will be next.  I'm going to assume the nVidia cards have
something similar, and I'm hoping someone may either a) know this
information already so I can make a pretty simple change or b) suggest a way
that I might find out this information.
Hi,

Younes Manton <younes.m at gmail.com> wrote:
> Jamie Smith<hutts at internode.on.net> wrote:
>> I am one of those crazy nutters who connects my nvidia card
>> directly to a television via a vga2scart cable using interlaced
>> video modes.
>> For the purpose of displaying true interlaced video (e.g. DVD) to
>> an interlaced television, without using deinterlacing, the full
>> video frames need to be written to the linear video buffer during
>> the retrace after the second frame is drawn, so that both fields
>> are ready to be output in correct order to the display.
Alternatively, it would probably be enough to write the frames
in the right order, i.e. write the even frame when the card displays
the even frame, etc.
>> If I understand, the nouveau drivers currently use the standard vga
>> crtc registers to detect video retrace, and this results in the same
>> behaviour.  According to specifications I have seen from AMD, at
>> least one Radeon series has registers which tell which field(first
>> or second) is currently being drawn, and which field will be next.
The register 0x600808 (PCRTC_RASTER) contains this information in bit 20
(0=even, 1=odd), at least for older cards. I have no idea if this register
is valid on your concrete hardware (and I don't even now which hardware
that is).
> If I understand you correctly you want the same image to be displayed
> for two frames, i.e. when the tv is showing the first and second
> fields.
> There's no parameter for that in Xv to know which field a particular
> XvPutImage corresponds to as far as I know. 
And that's the main problem, actually. There's the X SYNC extension

http://lesstif.sourceforge.net/doc/super-ux/g1ae04e/chap9.html

which provides synchronization counters that can be used to make this
information available (this has been discussed on the xorg mailing
list some years ago, BTW).

So you'd have to patch Noveau to provide a SYNC counter (maybe on
request), where the lowest bit of the sync counter should reflect if
it's an even or odd field, and then you've to patch your favorite
movie player to make use of this information and, say, delay for
one frame when it starts playing but the current field is odd, so that
even fields fall on even fields. You'd probably also need to take
any delays caused buffering into account.

Doable, but not easy.

- Dirk

On Mon, Jun 15, 2009 at 08:44:26AM +0100, Alistair Buxton
wrote:
> 2009/6/15 Dirk Thierbach <dthierbach at gmx.de>:
> > On Sun, Jun 14, 2009 at 11:56:45PM +0100, Alistair Buxton wrote:
> >> Stupid question: Given the presence of a register which indicates
the
> >> current field, why can't NVWaitVSync simply wait until the end
of the
> >> second field, by doing whatever it does twice iff it is called
during
> >> the first field?
> >
> > Because then you'd effectively halve the frame rate in interlaced
> > modes, unless you somehow queue all the information for the second
> > half-frame.
> That isn't a problem, because you show both fields at the same time,
> and let the video card cut them up. You still get 50 fields per
> second, same as source.
Ok, I think I understand now what you mean.

But that will only work in the very particular case that you're
displaying a video full-screen, with the *intention* to let the
hardware do the interlacing. Which doesn't match the usual usage
of Xv, for example. So you're introducing a special case without
marking it as a special case explicitely. That's a bad idea in
my book. KISS.
> mplayer and vlc both do it. 
But only when displaying video full-screen and they know the card
is in interlaced mode, I assume? Otherwise, that would be plain stupid,
because it will generate artifacts for every other use. Like displaying
the movie in a window.
> They can also split the fields and scale vertically as you describe
> (vlc calls it bob deinterlacing) but at extra CPU cost.
Not if Xv does the scaling via hardware.
> > If you just combine two adjacent half-frames, you get the typical
> > comb-style ragged edges on fast moving objects.
> 
> That's what happens on a none-interlaced display. On an interlaced
> display it will look fine of course. So I can't see any problems with
> this method.
See above. It's a very special case, it behaves different in that special
case, it will break if the client doesn't know it behaves different and
wants to use it for other purpose (say, displaying a non-interlaced
source on an interlaced display).

Why not use a method that works in all cases? Which is to give the
client explicit knowledge about which half-field is displayed
currently. Then the client can decide what to do.

- Dirk