On 9 February 2010 18:21, Younes Manton <[email protected]> wrote: > On Tue, Feb 9, 2010 at 12:50 PM, Alistair Buxton <[email protected]> wrote: >> On 15 June 2009 14:14, Jamie Smith <[email protected]> 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 [email protected] _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
