This is a followup to the (very) old thread "[directfb-users] [Softdevice-devel] viafb + cle266mpegdec + TVout : field parity status and patches" and more recent "[Softdevice-devel] viafb, TVout, field parity, DirectFB, cle266 HW decoding".
Hello again :-) I still have problems with field parity on TV-out. I check everything
one more time. I can't figure anything regarding wrong patches, version, etc.
No patches should be required any more. All this stuff should work if you have linux-viafb from DirectFB CVS and DirectFB-rc4 or later. The only obvious difference I see with Laz's working setup is his MII12k
vs. my M10k (with unichrome-revision=17 vs. unichrome-revision=3)
Presumably that means he also has a different TV encoder? That may be something to do with it but hopefully not. I finally tested Mark Adams suggestion dated 2006-10-09 18:32 :
------------------------ Try adding a printk in viafb_wait_for_sync (via_fbobj.c), just before it returns: printk(KERN_INFO "wait vsync: %d %d %d\n", field_option, p->irq_cnt & 1, ret);
OK, so we see this: Feb 11 11:39:47 vdr kernel: wait vsync: 3 0 25
Feb 11 11:39:47 vdr last message repeated 2 times Feb 11 11:39:47 vdr kernel: wait vsync: 3 1 25 Feb 11 11:39:47 vdr last message repeated 2 times Feb 11 11:39:47 vdr kernel: wait vsync: 3 0 25 Feb 11 11:39:47 vdr last message repeated 2 times Feb 11 11:39:47 vdr kernel: wait vsync: 3 1 25 Feb 11 11:39:47 vdr kernel: wait vsync: 3 1 25
field_option 3 is a wait for a kernel-assisted flip to complete. The 25's (HZ/10) mean that the wait calls are returning immediately (presumably because a fair amount of processing was required to get the next frame ready and the previous frame had been displayed by that point). The mixture of 0's and 1's means that the video is sometimes on the top field and sometimes on the bottom when the wait happens. All that is fine provided that you're using triple buffering. That's perhaps something I should enforce when this method is being used and fall back to the old method if not. Are you using triple buffering? Can you try using df_xine (from DirectFB-extra)? This I know to work perfectly on my hardware and it would be a good starting point to see if this works for you before going much further. I think I've asked this before but I don't remember you reporting back what the result was. Use something like: df_xine -m 720x576 -l 1 -b triple -f top <filename> There are some more useful tests we can do if we still don't find out what's happening but try the above first. Cheers, Mark
_______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
