I have built MPlayer (CVS as of yesterday) with both standard framebuffer/mga support as well as directfb (CVS as of yesterday as well) support. I edited the vo_directfb.c driver and turned on the "flipping" flag for use with my G400 enabled machine. On that machine I have used the matroxset utilty to reroute CRTC1 to the 2nd head so that I get BES enabled output on my TV.
I have noticed two significant differences between using MPlayer with
the standard framebuffer/mga kernel driver combination and directfb
drivers:
1. Playback using framebuffer/mga is smoother than using directfb. I
use CNN as my benchmark for doing "smoothness" testing because
they have that nice smooth scrolling, left to right news ticker on
the bottom of the screen. Much like the stock tickers on stock
report channels in fact.
Anyway, when I use the framebuffer/mga combination, the playback
is about as smooth as it's going to get with an MPEG1 (640x480 @
29.97 frames/s) file due to the fact that the source is not
interlaced and therefore each frame is displayed for two cycles
(fields).
However when I play back the same file with the directfb output
driver, the ticker is quite a bit more juddery. I cannot slow
down the output and display frame by frame but it appears that
sometimes an old frame (2-3 frames old) is getting recycled as the
scrolling text seems to have a back and forth jerky motion. I
don't know how many frames are being buffered to the hardware for
vsync flipping but perhaps an older frame is not being replaced
quickly enough and it's getting redisplayed?
2. CPU usage seems to be significantly higher with directfb than with
the standard framebuffer/mga combination. When I play my 640x480
@ 29.97fps file using the framebuffer/mga combination, it consumes
about 55% of my TB Athlon 800Mhz CPU. The exact same file played
back through the directfb driver comsumes 85% of the same CPU.
Is this extra CPU usage to be expected using directfb?
b.
--
Brian J. Murrell
msg00788/pgp00000.pgp
Description: PGP signature
