Tests of df_xine using Terry Barnaby's deinterlace test videos from
http://www.kingcot.eclipse.co.uk/unichrome/tvoutTest.html (N.B. the
original version, interlace_test.mpeg: the new versions with correct
aspect ratios, or something like that, just displays a really screwed up
picture which I put down to xine rather than the actual output device).
Screwed up doesn't mean very much.
I've not had much luck with xine getting aspect ratios right (but I've mainly been feeding it MPEG transport streams -- perhaps its better with video elementary streams or program streams). If you think the interlace test patterns are getting screwed up, bear in mind that any vertical scaling of the image will definitely make it look wrong.
Output from df_xine -v2 -l0 interlace_test.mpeg (until I killed it after
a few seconds):
CPU usage is maxed out (not really surprising for this layer!) but the
picture quality on both CRT monitor and TV is good but definitely not
deinterlaced.
Now you're confusing me. We're not trying to get a deinterlaced picture. If you've got an interlaced source and an interlaced display you want the rest of the chain to be complete transparent. For this to work you need the frames to be displayed with the right field order at the far end, synchronised with the scan of the display (both dealt with by my patches) and you need to ensure that no vertical scaling or filtering or deinterlacing happens anywhere in the chain.
If that test video clip is the one I think it is, it should have things moving around smoothly with no juddering (when it's wrong, you see moving objects as double). To be able to describe what's actually happening, you really need to have seen the image in three ways: single-field, wrong field-parity and correct.
BTW, I think you will need df_xine -s -l1 (I don't have the code to hand to check that but the -s certainly won't do any harm if it's not required).
(I also seem to remember, now I come to think of it, that some of the interlace test images I've seen actually have the opposite field parity to that used for broadcast and DVD MPEG video -- I don't know if that applies here or not but you could try changing the '1' to '2' in the argument to the vsync ioctl in (I think) uc_overlay.c and see what happens: if that helps with the test images you still need to change it back again).
> video_out_dfb: frame format changed to 720x576 YV12
> video_out: throwing away image with pts 61204 because it's too old
(diff : 6520).
(diff : 6520).
> CPU usage for this was ca. 50% but the picture was really flickery.
> I think it was deinterlacing properly, though. Presumably, it's
> throwing away the frames to keep up.
That's a bit of a mystery. That's the optimal frame format and xine should have no problem keeping up. Just see if '-s' makes any difference.
That's a bit of a mystery. That's the optimal frame format and xine should have no problem keeping up. Just see if '-s' makes any difference.
Again though, I think you're confusing terms. There should be no deinterlacing so I don't know what you mean by 'deinterlacing properly'.
Mark
_______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
