it is not that bad. The interface is not serial (i.e. 1 bit) and should be able to pump 640x480 at 25fps in 12bit YUV mode, see
http://www.gossamer-threads.com/list...rs/22014#22014
Bitrate matters only for decoding (=CPU time) and is not relevant to 'slow' RFBI interface. If I understand it correctly the limitation is that mplayer does not decode frames in advance so everything is time critical and decoding of each frame must wait until previous frame is displayed (i.e. sent to epson chip over rfbi). That's because it is done directly to internal video ram[1] (the only place from which it can be sent via DMA (= no overhead) to epson chip over RFBI) . If we had one extra frame in internal video buffer, decoding frame and displaying frame could be decoupled with no waits. If we even had more frames we could smooth out short more CPU intensive (high motion) scenes.

1. internal video ram is for 770 in normal RAM (64MB SDRAM), for N800 there is one 800x480 plane in SDRAM and one 640x480 plane in internal OMAP2 SRAM, this one is usable via Xv extension as video overlay.

EDIT: maybe mplayer does decode frame in advance to some off-screen memory but then it still must wait for display update to finish so it can do the final copy to video memory (possibly with conversion to specific videochip framebuffer format) without overwriting previous (still not fully transferred) frame. Maybe Serge will correct me if he cares to explain it one more time :-)