On Saturday 10 September 2005 11:24, Mark Adams wrote: > > 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.
;-) By this, I mean that the it is doing something really freaky with the image so that the TV is filled with lots of coloured horizontal lines which seem to move about at random: sort of like an encrypted channel, or something, where the scan lines (or bits of them?!!) aren't being shown in the correct places. It's hard to describe! > 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. I'll have a go at generating a few sections of ES streams. > 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. Sorry. By not deinterlaced in this context, I mean that there are lots of interlace artifacts in the picture, i.e. jagged diagonals and horizontal motion. By deinterlaced (below) I mean that there are no such artifacts and the picture looks as it should. > 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. This is what I'm aiming for, even if I'm not being very clear. > 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 don't think -s had any obvious effect when I tried it but I'll have another go. > (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). The test videos I have have a 'correct' version and a 'reversed' version with the fields reversed. > > video_out_dfb: frame format changed to 720x576 YV12 > > video_out: throwing away image with pts 61204 because it's too old > > (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. I'm sure it is because it is trying to keep A-V sync and it is having to throw frames away to keep up because it isn't playing the frames correctly somehow. I will try with an ES stream, i.e. just video, to see if I get the same bizarre speed variations and frame-dropping. > Again though, I think you're confusing terms. There should be no > deinterlacing so I don't know what you mean by 'deinterlacing properly'. Hopefully I've explained that above. At the moment, playing stuff back with df_xine to the correct layer (without -s but I'll try that in a bit) gives a picture without interlace artifacts but the speed varies! What are you using to get your best playback? df_xine? I'm away for a week but I'll try to get some of this tested... Cheers, Laz _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
