Hi folks, let me explain the subject a little. Back in april of this year, "Prelude" posted a fix to a problem he reported himself few weeks before, in the thread "df_xine and fieldparity (g400 maven TV-out)", http://mail.directfb.org/pipermail/directfb-users/2005-March/000110.html http://mail.directfb.org/pipermail/directfb-users/2005-April/000151.html At that time I also tried the patch and was impressed at first glance when seeng that df_xine is also capable to display the video correctly on my Matrox G400 TV-out (so no need for deinterlacing actually, just coorect field parity matters). Ever since I forgot about that fix and after some upgrades to DirectFB-extra, I had again terrible judder on the TV with df_xine, no matter if I used it for displaying VDR, a DVD or any other video, and no matter what combination of parameters I tried (vsync, deinterlace, fieldorder, buffermode, hwstretch). Now as I wanted to give df_xine again a try to configure it for playing DVDs and displaying VDR within Freevo, I rememberd I've seen it once displaying frames correctly and dug and found again Prelude's fix and applied it.
Well, now I found out that the fix is far from perfect and I'm missing the point why. It was about modifying the input argument "ratio" of the callback function dfx_output_cb in context.c (right at the start, line 53-54), like ratio = (double) width / height; Now this is influencing "update_area" in case the execution does not enter the subsequent "if" block, and also this aspect ratio itself (I haven't understood which aspect ratio is meant, that of the video frame, or that of the screen on which the frame is to be displayed). Te result is, that with this fix, I'm getting smooth frames, in lip-sync and no field-parity artefacts or judder whatsowever, BUT if I switch VDR to channel broadcasting some weird frame size in the MPEG2 stream, like 544x576, or even worse, 378x576 (I think, that would be MTV Italy), the frames are not stretched correctly horizontally to the 720 pixel width, so I'm seeing thick vertical black borders (image is centered). So the fix introduces a serios aspect ratio problem, which is hardly noticeable on 703x576 material (strange numbers, I know, but the're reported by df_xine), does not matter on real 720x576, but simply is too obvious on those "economy" broadcasts with very few horizontal pixels. I have to admit, there is absolutely no judder in the picture with this fix, but without it, it's unwatchable. So I'm asking the gurus around here, what's actually happening? I'm not at home right now, but I think I'll incorporate some more debugging between the code blocks in that function, to see how those numbers change and to actually see what path the execution follows (I don't know any other debugging method under linux, as I'm only working whith MS-VC++ and it's debugger under windows so far). Lucian _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
