Progress: I have applied your patch and rebuilt DirectFB. This has solved the colour problem (was this expected?!!)
Yes!!
and my CPU usage has dropped to about 25-30% when viewing DVB-T channels in vdr (was ca. 90%!).
Curious. Don't understand that. Are you sure nothing else changed at the same time?
I've not really looked into the code for it myself and I'm no way an expert on different colour formats, etc.
OK. The thing is that accelerated blitting of YUY2 or YV12 surfaces is not supported so you will have poor performance if these are being attempted. However, the video decode is probably direct from system memory onto the layer surface so this may not be a factor. Instead, the amount of data being transferred to video memory may be a significant factor in which case more compact formats will work better (YV12 being the best in this respect).
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.
I'll also test running vdr as root to see if that makes any difference.
If you've applied my patch, this won't make too much of a difference but xine-lib does try to raise the priority of certain threads if it can so reliability may improve a bit.
Mark
_______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
