On Wed, 2005-09-07 at 14:27 +0100, Mark Adams wrote: > Will do (df_xine didn't want to build for me in the few > moments I had to test: I'll work on it later on). > > When you run it, you'll probably need: > > export DFB_CLE266_UNDERLAY=1 > df_xine -s -l1 <filename> > > You can experiment with -p rgb32 -p rgb16 -p yuy2 and -p yv12 to try > out different pixel formats. On my box, it can't keep up when > outputting to RGB32, takes about 73% CPU with RGB16 and YUY2 and about > 52% CPU for YV12. You may need to change the video aspect ratio > manually with df_xine: hold 'R' and use the numbers 1-4.
Hmmmm...didn't really got much joy with df_xine last night (although I spent most of the time testing vdr output!): all I kept on getting was error messages about not being able to find the DFB output module, even though I rebuilt libxine with directfb output! (This may be more relevant to the softdevice list but I'll post here first because I know some watch both lists!) Did more with vdr though: I am now convinced that it isn't dropping frames, as such, but playing them back at about half speed. It does this for about 10 s when, presumably, a buffer overflows and it jumps forward to 'real time' and starts the cycle again, i.e. 10 s of slow and then a jump. Doing this, it keeps up with a separate system with a dxr3 ouptut device. It behaves like this both with live TV and recordings. Sound is all over the place but that's not really surprising if it is trying to keep it in sync with the video! It is still sitting at about 20-30% CPU usage so I'm not sure where the problem lies. It looks like the framebuffer is only accepting frames about half as often as it should, causing the buffer overload. Any clues for what I should test next? :-s Cheers, Laz _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
