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
