Re: Syncing to vblank for interlaced video modes

Re: Syncing to vblank for interlaced video modes

[Dirk Thierbach]

Younes Manton <younes.m-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Jamie Smith<hutts-CkBdp7X+a1oIQCUVoCVjmQ@public.gmane.org> 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

Re: Syncing to vblank for interlaced video modes

[Alistair Buxton]

Good to see discussion of this issue, it's been plaguing me for ages.

In order to drive my PAL TV I had to patch nouveau to reduce minimum
dot clock, as described here:

http://bugs.freedesktop.org/show_bug.cgi?id=20298

Same is required for nv but not nvidia.

Also, afaik, nv/nouveau does not support interlaced modes at all.

-- 
Alistair Buxton
a.j.buxton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: Syncing to vblank for interlaced video modes

[Alistair Buxton]

2009/6/14 Alistair Buxton <a.j.buxton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> Good to see discussion of this issue, it's been plaguing me for ages.
>
> In order to drive my PAL TV I had to patch nouveau to reduce minimum
> dot clock, as described here:
>
> http://bugs.freedesktop.org/show_bug.cgi?id=20298
>
> Same is required for nv but not nvidia.
>
> Also, afaik, nv/nouveau does not support interlaced modes at all.
>
> --
> Alistair Buxton
> a.j.buxton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>

Oops, my bug was fixed and I didn't notice ... thanks :)

Also, it is only needed to get square(ish) pixels in none-interlaced modes.

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? This method shouldn't require any patches in player
software, since by default they treat the two interlaced fields as a
single frame, and can swap the field order if necessary.

-- 
Alistair Buxton
a.j.buxton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: Syncing to vblank for interlaced video modes

[Dirk Thierbach]

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.

> This method shouldn't require any patches in player software, since
> by default they treat the two interlaced fields as a single frame,

They do? I thought they they'd just treat every half-frame as a whole
frame by scaling it up vertically. Which player actually does that?

If you just combine two adjacent half-frames, you get the typical
comb-style ragged edges on fast moving objects.

Interlace *is* actually intended to give increased temporal resolution.
With nearly the same spatial resolution, because the human brain
compensates. If you treat two half-frames as one frame, you loose
that.

- Dirk

Re: Syncing to vblank for interlaced video modes

[Dirk Thierbach]

On Mon, Jun 15, 2009 at 08:44:26AM +0100, Alistair Buxton wrote:
> 2009/6/15 Dirk Thierbach <dthierbach-Mmb7MZpHnFY@public.gmane.org>:
> > 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

Re: Syncing to vblank for interlaced video modes

[Alistair Buxton]

2009/6/15 Dirk Thierbach <dthierbach-Mmb7MZpHnFY@public.gmane.org>:
> On Mon, Jun 15, 2009 at 08:44:26AM +0100, Alistair Buxton wrote:
>> 2009/6/15 Dirk Thierbach <dthierbach-Mmb7MZpHnFY@public.gmane.org>:
>> > 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.

Yes, that is exactly the intention, for eg a mythtv STB which only
ever plays interlaced video which is the same size as the screen.

>> 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.

No, they do it in window mode too, and regardless of display mode.
Unless you specifically specify that you want deinterlacing, they keep
both fields as a single frame. mplayer detects the framerate of an
interlaced mpeg2 as 25 fps. When the vsync is at 50hz (per field)
mplayer is ignoring every other vsync anyway. The problem then is that
it has a 50% chance of ignoring the wrong vsync.

>> 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).

Good point.

> 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.

I mainly don't like the idea of having to patch all players ever made,
plus the driver side is also more complex. But it does seem the more
flexible solution.

At the moment I can't even get interlaced mode to work because I have
a NV18 card, but I'm working on it.

-- 
Alistair Buxton
a.j.buxton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: Syncing to vblank for interlaced video modes

[Jamie Smith]

Hi Again,

It seems I've triggered off much more discussion than I originally thought I would provoke.  I forgot to actually state what I was proposing to do, but it appears that people have worked it out.

> >> > 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?

Yes, this is what I'm proposing.  A server option that modifies the behaviour of the sync code so that if a) the option is set and b) the current video mode is interlaced, then wait until after the second field has been drawn before flipping pages/updating buffers etc.

> >> > Because then you'd effectively halve the frame rate in interlaced
> >> > modes, unless you somehow queue all the information for the second
> >> > half-frame.

Yes you would but that'd not necessarily a bad thing on an interlaced display.  You'll have slower but less juddering animation with full solid frames.

> >> 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.

Actually it's a much simpler situation as I described above.  Full screen/windowed mode is not a factor.  My proposal does KISS.

> Yes, that is exactly the intention, for eg a mythtv STB which only
> ever plays interlaced video which is the same size as the screen.
> 
> >> 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.
> 
> No, they do it in window mode too, and regardless of display mode.
> Unless you specifically specify that you want deinterlacing, they keep
> both fields as a single frame. mplayer detects the framerate of an
> interlaced mpeg2 as 25 fps. When the vsync is at 50hz (per field)
> mplayer is ignoring every other vsync anyway. The problem then is that
> it has a 50% chance of ignoring the wrong vsync.

I can confirm that xine does it too.  They all do it as far as I know.  It makes sense to do it this way, windowed or full screen, and that is what creates the artifacts on a progressive display, and why the need for deinterlacing to begin with.  Old interlaced CRTCs have their own magic deinterlacing, and LCDs try to replicate that.

>> 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).
> 
> Good point.
>
> > 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.
> 

OK I've got lots to say on this topic:  The days of applications having direct control and awareness of the video hardware (or any hardware really these days) are dead as DOS.  (OK I know about Freedos, I used to use it)... The OS is charge of this sort of thing.  X11 is a perfect example - it never exposed any such details to the application layer.

Today's applications are not written to know about or even care about how many FPS the video is capable of or whether it is interlaced.  Because of this principle, delaying the sync on an interlaced display until the second field only will not break applications showing progressive content on an interlaced display.  They might want to show 60 fps content, but they'll just do their best and drop the other 30 frames they can't display on a 60HZ interlaced display.

Updating an interlaced display on every field is only useful to applications which are generating video source in real time specifically for an interlaced display (think standard television broadcasts).  Showing a progressive source updating at full refresh rate on an interlaced display is messy at best.  The second field is going to be not one but two frames ahead of the first in the best case.

> I mainly don't like the idea of having to patch all players ever made,
> plus the driver side is also more complex. But it does seem the more
> flexible solution.
> 

If the driver is changed as I suggest, not only will players benefit, but so will any other software that outputs animation to an interlaced display.  If implemented as an extra server option, then users need never know of its existence if they don't need its effect.  I really don't seen any drawbacks to this strategy, so if I'm missing something please let me know.

> At the moment I can't even get interlaced mode to work because I have
> a NV18 card, but I'm working on it.

To answer Dirk's original query, my card is a plain Geforce 6600 (NV 25 I think?).  It does interlaced just fine.
-- 
Jamie Smith <hutts-CkBdp7X+a1oIQCUVoCVjmQ@public.gmane.org>

Re: Syncing to vblank for interlaced video modes

[Maarten Maathuis]

It's a NV43, NV25 is the Geforce Ti 4x00 series iirc.

Re: Syncing to vblank for interlaced video modes

[Dirk Thierbach]

On Tue, Jun 16, 2009 at 12:14:05AM +1000, Jamie Smith wrote:

> Yes, this is what I'm proposing.  A server option that modifies the
> behaviour of the sync code so that if a) the option is set and b)
> the current video mode is interlaced, then wait until after the
> second field has been drawn before flipping pages/updating buffers
> etc.

>>>>> Because then you'd effectively halve the frame rate in interlaced
>>>>> modes, unless you somehow queue all the information for the second
>>>>> half-frame.

> Yes you would but that'd not necessarily a bad thing on an
> interlaced display.  You'll have slower but less juddering animation
> with full solid frames.

Then the question is why the used interlace for TVs in the first place :-)
The purpose really is to get better resolution in time, trading of
vertical resolution.

And whether this is used or not should be decided on a per application
basis.

>>> 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.

> Actually it's a much simpler situation as I described above.  Full
> screen/windowed mode is not a factor.  

Yes, it is, because it requires the application to put the information
for two half-frames in one frame, if it wants to use the full frame rate.

If the video overlay is not full screen and the video source doesn't
have the same amount of lines as the TV screen, then that is not so
easy. So interesting things already happen when you try to play an
NTSC movie on a PAL screen, say.

> My proposal does KISS.

Your proposal is simple in the sense that it requires least effort to
get the special case you're interested in working. That's called sometimes
"a quick hack" :-)

It's *not* simple in the sense that it provides a uniform interface to
the application. You have a special case, that behaves differently
from the usual case when (a) the nouveau driver is used, (b) the
option is enabled, (c) interlaced mode is active, and maybe (d) at a
particular frame rate.

So the application needs to know that in this particular case, one
frame will be displayed in two half-frames. In all other cases, one
frame will be displayed as one frame, whether halved or not.

OTOH, with the SYNC extension, the application only needs to check
if the extension is available and there's a counter present, it can
sync interlaced source material to that counter. All other applications
work like before. Say, when you want to play a game, it will output
animated frames at full 50/60Hz and nearly full vertical solution
(because the eye compensates).

> I can confirm that xine does it too.  

I'm using xine myself, and I've never noticed that (but maybe
I changed the default to deinterlacing long ago and forgot).

> They all do it as far as I know.  

I don't doubt that all movie players can do "weaving" on demand,
but I really don't think that this means this is the only sensible way.

> It makes sense to do it this way, windowed or full screen, and that
> is what creates the artifacts on a progressive display, and why the
> need for deinterlacing to begin with.

Exactly. So it actually *doesn't* make sense to do it this way. Because
it causes artifacts. It's just very easy to do, from a programming
point of view.

> Old interlaced CRTCs have their own magic deinterlacing, 

They do? I've worked with monitors that needed interlaced modes for
higher resolutions back then, and I've never seen any "magic
deinterlacing". It's the eye and the brain which do that.

> and LCDs try to replicate that.

LCDs have the problem that they can't display interlaced material in the
same way as CRTs can, so they *need* some way to make up for that deficit.
Usually not with very good results.

> OK I've got lots to say on this topic: The days of applications
> having direct control and awareness of the video hardware (or any
> hardware really these days) are dead as DOS.  

This is now getting really philosophical, but just in case: We're not
talking about control on the register level. We're talking about the extra
information needed to deal with interlaced vs. non-interlaced display
in the case you want to show information that is already in interlaced 
format. Showing non-interlaced material on an interlaced display already
works fine, but the problem with your proposal is that you want to change
this second case by giving it half the framerate. If it were not for this
side-effect (breaks all applications except full screen movie playing),
I'd have no objections.

> Today's applications are not written to know about or even care
> about how many FPS the video is capable of or whether it is interlaced.

And the reason for that is that on modern monitors, the frame rate is
high enough, so there's no need to care. That's *not* true for the TV
standard, which is old, which is why you run into a problem here in the
first place. If every TV could display non-interlaced 100Hz images,
we wouldn't have this discussion :-)

> Because of this principle, delaying the sync on an interlaced
> display until the second field only will not break applications
> showing progressive content on an interlaced display.  They might
> want to show 60 fps content, but they'll just do their best and drop
> the other 30 frames they can't display on a 60HZ interlaced display.

Which is bad, because they *could* have 60fps. And for my definition
of "break", this breaks them. It's not that they would crash, but they
are forced to behave worse than they could, and they can't do anything 
about it.

> Updating an interlaced display on every field is only useful to
> applications which are generating video source in real time

No. Updating on every field is useful for all applications which want
to display their output in the best possible quality.

> If the driver is changed as I suggest, not only will players
> benefit, but so will any other software that outputs animation to an
> interlaced display.

No. They won't benefit, on the contrary, they'll have output in lower
quality. Displaying one field twice decreases smoothness and decreases
temporal resolution.

Think of it this way: The reason for an interlaced image when TV
was introduced was limited bandwidth. If a non-interlaced image at
25fps is so much better than an interlaced-image at 50fps, why did
they even use interlace in the first place? They just could have designed
TVs differently. Why didn't they?

- Dirk

Re: Syncing to vblank for interlaced video modes

[Alistair Buxton]

On 15 June 2009 14:14, Jamie Smith <hutts@internode.on.net> wrote:
> Hi Again,
>
> It seems I've triggered off much more discussion than I originally thought I would provoke.  I forgot to actually state what I was proposing to do, but it appears that people have worked it out.
>
>> >> > 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?
>
> Yes, this is what I'm proposing.  A server option that modifies the behaviour of the sync code so that if a) the option is set and b) the current video mode is interlaced, then wait until after the second field has been drawn before flipping pages/updating buffers etc.

[snip debate about whether this is a good idea]

I have been thinking about this problem recently and I have come to
the conclusion that it isn't necessary to change the vblank interrupt
frequency or add any special hooks to let the player know which field
is being shown. No drivers changes should be needed at all. It only
requires that players are more smart about how they display interlaced
content to the screen.

At the moment, every player I know of, when interlacing is disabled,
just does simple weaving. This is bad as when you display it on an
interlaced screen there is no way to know which field will get
displayed first. But there is a better way. If, each time the player
receives a vblank interrupt, it draws the next field into the display
(ie updating every other line on the framebuffer, and leaving the
other lines alone) then each field is in the framebuffer for 1 whole
frame, and no matter which framebuffer field is currently shown, the
next one will always contain the correct next field.

Effectively it is weaving, but instead of weaving each frame's field
pair, the frame rate is doubled by weaving every sequential field pair
even if they belong to different frames. So, assuming lower-field
first, it would produce frames composed like:
(1L,nothing),(1L,1U),(2L,1U),(2L,2U),(3L,2U),(3L,3U)...

Why it works is kind of hard to explain without a diagram so I have made one:

http://al.robotfuzz.com/~al/nouveau/path7109.png

Anyway, since no driver changes are needed, this is now offtopic. But
does anyone know a player that can do what I am describing? Or maybe
this method of playback has a special name I am not aware of?

-- 
Alistair Buxton
a.j.buxton@gmail.com
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Syncing to vblank for interlaced video modes

[Younes Manton]

On Tue, Feb 9, 2010 at 12:50 PM, Alistair Buxton <a.j.buxton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 15 June 2009 14:14, Jamie Smith <hutts-CkBdp7X+a1oIQCUVoCVjmQ@public.gmane.org> wrote:
>> Hi Again,
>>
>> It seems I've triggered off much more discussion than I originally thought I would provoke.  I forgot to actually state what I was proposing to do, but it appears that people have worked it out.
>>
>>> >> > 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?
>>
>> Yes, this is what I'm proposing.  A server option that modifies the behaviour of the sync code so that if a) the option is set and b) the current video mode is interlaced, then wait until after the second field has been drawn before flipping pages/updating buffers etc.
>
> [snip debate about whether this is a good idea]
>
> I have been thinking about this problem recently and I have come to
> the conclusion that it isn't necessary to change the vblank interrupt
> frequency or add any special hooks to let the player know which field
> is being shown. No drivers changes should be needed at all. It only
> requires that players are more smart about how they display interlaced
> content to the screen.
>
> At the moment, every player I know of, when interlacing is disabled,
> just does simple weaving. This is bad as when you display it on an
> interlaced screen there is no way to know which field will get
> displayed first. But there is a better way. If, each time the player
> receives a vblank interrupt, it draws the next field into the display
> (ie updating every other line on the framebuffer, and leaving the
> other lines alone) then each field is in the framebuffer for 1 whole
> frame, and no matter which framebuffer field is currently shown, the
> next one will always contain the correct next field.
>
> Effectively it is weaving, but instead of weaving each frame's field
> pair, the frame rate is doubled by weaving every sequential field pair
> even if they belong to different frames. So, assuming lower-field
> first, it would produce frames composed like:
> (1L,nothing),(1L,1U),(2L,1U),(2L,2U),(3L,2U),(3L,3U)...
>
> Why it works is kind of hard to explain without a diagram so I have made one:
>
> http://al.robotfuzz.com/~al/nouveau/path7109.png
>
> Anyway, since no driver changes are needed, this is now offtopic. But
> does anyone know a player that can do what I am describing? Or maybe
> this method of playback has a special name I am not aware of?

The problem with that is that the player is typically not copying to
the actual frame buffer, or even the same buffer that was copied to in
previous frames. It's copying to some buffer that's not guaranteed to
contain anything specific, let alone the previously copied content.

Re: Syncing to vblank for interlaced video modes

[Alistair Buxton]

On 9 February 2010 18:21, Younes Manton <younes.m@gmail.com> wrote:
> On Tue, Feb 9, 2010 at 12:50 PM, Alistair Buxton <a.j.buxton@gmail.com> wrote:
>> On 15 June 2009 14:14, Jamie Smith <hutts@internode.on.net> wrote:
>>> Hi Again,
>>>
>>> It seems I've triggered off much more discussion than I originally thought I would provoke.  I forgot to actually state what I was proposing to do, but it appears that people have worked it out.
>>>
>>>> >> > 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?
>>>
>>> Yes, this is what I'm proposing.  A server option that modifies the behaviour of the sync code so that if a) the option is set and b) the current video mode is interlaced, then wait until after the second field has been drawn before flipping pages/updating buffers etc.
>>
>> [snip debate about whether this is a good idea]
>>
>> I have been thinking about this problem recently and I have come to
>> the conclusion that it isn't necessary to change the vblank interrupt
>> frequency or add any special hooks to let the player know which field
>> is being shown. No drivers changes should be needed at all. It only
>> requires that players are more smart about how they display interlaced
>> content to the screen.
>>
>> At the moment, every player I know of, when interlacing is disabled,
>> just does simple weaving. This is bad as when you display it on an
>> interlaced screen there is no way to know which field will get
>> displayed first. But there is a better way. If, each time the player
>> receives a vblank interrupt, it draws the next field into the display
>> (ie updating every other line on the framebuffer, and leaving the
>> other lines alone) then each field is in the framebuffer for 1 whole
>> frame, and no matter which framebuffer field is currently shown, the
>> next one will always contain the correct next field.
>>
>> Effectively it is weaving, but instead of weaving each frame's field
>> pair, the frame rate is doubled by weaving every sequential field pair
>> even if they belong to different frames. So, assuming lower-field
>> first, it would produce frames composed like:
>> (1L,nothing),(1L,1U),(2L,1U),(2L,2U),(3L,2U),(3L,3U)...
>>
>> Why it works is kind of hard to explain without a diagram so I have made one:
>>
>> http://al.robotfuzz.com/~al/nouveau/path7109.png
>>
>> Anyway, since no driver changes are needed, this is now offtopic. But
>> does anyone know a player that can do what I am describing? Or maybe
>> this method of playback has a special name I am not aware of?
>
> The problem with that is that the player is typically not copying to
> the actual frame buffer, or even the same buffer that was copied to in
> previous frames. It's copying to some buffer that's not guaranteed to
> contain anything specific, let alone the previously copied content.
>

I was talking about a hypothetical logical framebuffer inside the
player, not the real hardware.

The operation I described is sometimes called "double weave":

http://avisynth.org/mediawiki/DoubleWeave

It is very close to what mplayer's "tfields" filter does in mode 1.
Close enough that I was able to implement it and test it, and the
results are very good. No more juddering / out of order fields and no
deinterlacing artifacts. It was only necessary to duplicate the mode 1
functionality and comment the deint() calls. It should be easy enough
to implement this in any other player.

Here is my patch against the mplayer package from ubuntu:

http://al.robotfuzz.com/~al/nouveau/99-double-weave.patch

It adds a new mode to tfields. Use it like: "mplayer -vf tfields=5 yourfile.mpg"

So, in conclusion, no vblank hacks or other driver changes are needed
to support interlace-on-interlace.

-- 
Alistair Buxton
a.j.buxton@gmail.com
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Syncing to vblank for interlaced video modes

[Jamie Smith]

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-CkBdp7X+a1oIQCUVoCVjmQ@public.gmane.org>

Re: Syncing to vblank for interlaced video modes

[Younes Manton]

On Sun, Jun 14, 2009 at 8:32 AM, Jamie Smith<hutts-CkBdp7X+a1oIQCUVoCVjmQ@public.gmane.org> 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,

From my understanding, for textured video we stick a commands in the
fifo that basically sleep the channel until the start of the next
vblank. Look for NVWaitVSync. We call it in the various
NV*PutTexturedImage functions. I think the overlay is (probably)
automatically locked to the vblank.

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. In fact I'm not even sure
if Xv knows anything about interlaced video, seems we just get full
frames from the player and display them. XvMC seems a little better,
XvMCPutSurface has first and second field params, so you would then
sync only after the 2nd field is drawn I take it?