that's a non-interlaced source on an interlaced display. try bob & weave. Does the g400 have a flicker filter?
On Sat, 2004-11-06 at 01:56 +0100, Lucian Muresan wrote: > Stefan Lucke wrote: > > On Donnerstag, 4. November 2004 15:22, Lucian Muresan wrote: > ... > >> so far) this has yet to be written :-). The DirtectFB videoout of > >> softdevice > >> as it is now, uses wrong field parity order, which is very bad on an > >> interlaced TV, especially on fast movements and scrolling text, especially > > > > What kind of effects do you see ? > > Now I tried s-video out and I see some kind of blocked stripes. > > That is, one big horizontal stripe is left from the next. and this seems to > > be > > a scaling issue. Width is reported as 720 pixels and so the whole picture > > will be scaled down (scaler assumes square pixel). > > I'm seeing a sort of smearing on fast movements, sometimes it looks like > comb artifacts, sometimes like some big blocks bundled in horizontal > stripes. Depending on the movements' speed matching a certain relation > (ratio? multiple?) to the framerate, these effects do or do not appear. > the fact is, they're more likely to appear on faster movements like > sports events or horizontal scrolling newstickers. The bigger blocking > appears more likely on almost vertical edges when moving horizontally > (imagine for example football players running in the field, or even try > to find such a programme and see for yourself). > You could try this: Just record a short sequence of such material and > replay it within VDR/softdevice/DFB on TV, and then with > > mplayer -vo dfbmga:buffermode=single:fieldparity=bottom > > and you will notice how good they look alike, and then try > > mplayer -vo dfbmga:buffermode=triple:fieldparity=top > > on the same recording (first time I said "wow!"). Maybe the buffering > isn't the most important thing here, but triple helps stabilizing the > picture even when using the wrong parity. And I forgot one thing: dfbmga > also uses vertical sync, this could also matter a great deal in the > output quality. > > Maybe softdevice shouldn't even try to use 768 pixels wide surfaces when > outputting to TV through the second head of a matrox. For the first > head, there are 4:3 resolutions with square pixels available, but I > guess not for the second, see below. > > > I cannot specify 768 width in /etc/directfbrc. This will cause a segfault > > on "scrSurface = dfb->CreateSurface (scrDsc);" allthough 768 is reported > > as supported: > > [dfb] Supported video Modes are: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL > > PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > > > > Nov 5 19:44:19 bodega1 kernel: matroxfb: cannot set xres to 720, rounded > > up to 768 > > Yes, AFAIK, for crtc2 only 720x576 is supported for PAL, or 720x480 for > NTSC (see DirectFB/gfxdrivers/matrox/matrox_[screen_]crtc2.c), which are > both standard video resolutions (well, at least still "usual" nowadays), > so yes, the pixels aren't sqare, but that shouldn't be a problem. I > think what DFB reports as supported has only something to do with > /etc/fb.modes, but unfortunately not taking into account that you set up > crtc2 in /etc/directfbrc, then I think in case of Matrox cards, only the > code in the 2 files mentioned above is relevant. > > Just for reference, if you compare vdr replay and mplayer like above, my > /etc/directfbrc: > > mode=720x576 > depth=32 > primary-layer=2 > matrox-crtc2 > matrox-sgram > matrox-tv-standard=pal > matrox-cable-type=scart-rgb > > disable-module=joystick > disable-module=ps2mouse > disable-module=lirc > > > > Lucian Muresan >
