Hi,
after Ville found out why df_xine inverts colors when using a Matrox CRTC2, I was able to get correct output by commenting out the line in DirectFB-extra/samples/df_xine/control.c in dfx_control_correction where "value" is assigned 0x8000. Well, this may work for my CRTC2, but I haven't found out what it does on the primary head. Just wanted to report that something like this would work for CRTC2, and Claudio should consider this (please ;-) !).
Yet, I don't understand why setting color adjustments to 0x8000 on start may cause problems with the CRTC2.
Ville, could you explain me, please?
However, I have other issues with df_xine on CRTC2. As the CRTC2 is outputting an interlaced signal for a normal TV (PAL 4:3 in my case), I'm expecting df_xine to be able to play interlaced material (like I have from several DVDs, or with DVB material when using df_xine as a viewer for the VDR-xine plugin) on the CRTC2 by just leaving it interlaced and just take care of the field parity order I'm specifying, as the output device, my TV, is interlaced too, anyway. Nevertheless, there is no difference in the specified field parity option in df_xine, the picture has wrong field order specific artifacts, especially viewable on quick horizontal movements, scrolling text banners for example). Such a thing does not happen with mplayer/dfbmga for example. I even tried single/double/triple buffering, with and without V-Sync, but there is no change. Is there something specific I could try, or is this part of the code not yet working as expected?
Currently the -f,--fieldparity option takes only effect when you specify -d,--deinterlace.
-- Regards, Claudio Ciccani
[EMAIL PROTECTED] http://directfb.org http://sf.net/projects/php-directfb
_______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
