Hello All, I have just uploaded a new build of mplayer (mplayer_1.0rc1-maemo.3) to garage, which implements some experimental and not yet clean video output method using hardware YUV colorspace and direct access to framebuffer. It's not quite usable as framebuffer access is not allowed when running mplayer as ordinary user (framebuffer device is owned by root:video with 660 permissions). Also right now there are problems with keyboard input and other applications may cause some flicker effect (for example clock applet or google search applet overlap fullscreen video when thay are redrawn). Surely all these problems can be fixed by implementing hybrid x11/framebuffer code where x11 is responsible for keyboard input and sets video mode so that no other application draws over a screen area used by mplayer.
But having a plain framebuffer access creates an interesting possibility. Looks like mplayer can coexist with other applicaitons nicely and if they provide some rectangular area for video output, mplayer can be used from them in slave mode (http://www.mplayerhq.hu/DOCS/tech/slave.txt). Mplayer just needs to be extended to accept some command line option or slave option to specify/change screen region that it will use for video playback. Also I noticed that there is some initiative to control video players using d-bus: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-December/048067.html So maybe someone can develop a more advanced gui frontend for mplayer with all the eye candy and convenient gui controls. Let me know if you are interested in this idea and need some help or more information from me. Also thanks to Frantisek Dufka for Epson chip documentation, having full and reliable information adds a certain level of confidence and encourages development (I needed a confirmation that Epson chip supports only packed YUV formats and no planar formats are really available). Next come current benchmark results (mplayer_1.0rc1-maemo.3) showing some recent improvements, you can skip this part if you are not interested. Tested with the following video file (its first 100 seconds): VIDEO: [DIV3] 640x480 24bpp 23.976 fps 779.1 kbps (95.1 kbyte/s) Without hardware YUV colorspace support (-vo x11): # mplayer -endpos 100 -benchmark -vo x11 -nosound -quiet ... SwScaler: using unscaled yuv420p -> bgr565 special converter BENCHMARKs: VC: 122.215s VO: 90.458s A: 0.000s Sys: 1.769s = 214.442s BENCHMARK%: VC: 56.9918% VO: 42.1831% A: 0.0000% Sys: 0.8250% = 100.0000% Now using framebuffer output with YUV422 colorspace (-vo nokia770): # mplayer -endpos 100 -benchmark -vo nokia770 -nosound -quiet testfile.avi ... SwScaler: using unscaled yuv420p -> yuyv422 special converter BENCHMARKs: VC: 121.282s VO: 31.538s A: 0.000s Sys: 1.577s = 154.397s BENCHMARK%: VC: 78.5517% VO: 20.4267% A: 0.0000% Sys: 1.0216% = 100.0000% VC - is the raw time it took to decode this video fragment VO - is the time it took to display it on screen (performing color conversion) = - is a total time including decoding and displaying (preferably this number should stay below 100 seconds is we want to play this video in realtime) So no playback for 640x480 videos yet, but we got a bit closer to it (and lower bitrate/resolution videos should be supported better with less battery power consumption). Another interesting possibility is to relay video scaling and color conversion (planer -> packed YUV) to DSP. This method is used by dspfbsink gstreamer plugin and another nice feature is that dsp tasks are accessibe for ordinary user. But I'll post some more details and thoughts a bit later in another message. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
