FYI, I've just downloaded the interlace tests you refer to from http://www.kingcot.eclipse.co.uk/unichrome/tvoutTest.html. Here's what happens on my machine (VIA EPIA MII-12000, 512 MB RAM, Fedora Core 3, various patches):
df_xine -l0 interlace_test2.mpg - picture entirely as described on the web site except that the field parity drifts in and out such that the white bar is sometimes moving very smoothly and sometimes a bit juddery; 60% CPU usage (RGB16)
df_xine -s -l0 interlace_test2.mpg - picture entirely as described on the web site with the field parity remaining constant but being randomly correct or incorrect; 60% CPU usage (RGB16)
df_xine -s -l1 interlace_test2.mpg - black screen
export DFB_CLE266_UNDERLAY=1
df_xine -s -l1 interlace_test2.mpg - picture entirely as described on the web site but always showing incorrect field parity; 36% CPU usage (YV12)
df_xine -s -l1 -p rgb16 interlace_test2.mpg - picture entirely as described on the web site but always showing incorrect field parity; 60% CPU usage (RGB16)
df_xine -s -l1 tv.mpg (some captured broadcast TV) - always correct field parity; 52% CPU usage (YV12)
Conclusions:
The file interlace_test2.mpg has _incorrect_ field parity (at least it's opposite to broadcast TV). This I have since confirmed by looking at a decoded frame: field 2 is clearly on the even lines (0, 2, 4 etc.).
My patches only alter layer _1_ to provide correct frame synchronisation (normally you wouldn't be displaying interlaced material on layer 0 so this seems reasonable)
In all cases, my machine copes fine with the workload.
You say you can't get interlace_test2.mpg to display at all with df_xine which suggests you still have some fundamental problems to sort out.
Mark
_______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
