Yes, you are completely right here. MPlayer decodes frames in planar YV12 format to system memory, then when it is time to display the decoded frame, it moves frame data from system memory to framebuffer (*) converting it to YUV420 or YUV422 format in the process (format names according to Epson documentation) and initiates asynchronous DMA transfer of frame data from the framebuffer to LCD controller memory. We don't need to wait for the completion of this transfer, and start decoding the next frame immediately. Anyway, after the next frame is decoded, we can't write next frame data to the framebuffer unless we are sure that the previous transfer to the LCD controller memory is complete at this point. We get a stall here if the graphics bus is not fast enough to complete the transfer in time (and this stall gets higher if tearsync is enabled as we additionally need to wait for the next screen refresh cycle).

The process of copying from system memory to framebuffer with color format conversion is a small gap, where graphics bus is not used (and graphics bus bandwidth is a scarce resource). Fortunately copying is quite fast and does not take too much time, but improvements in this area can help to avoid some framedrops for high resolution movies playback with tearsync enabled (and tearsync is always enabled for video). We could use something like 'page flipping' if we had enough framebuffer memory.

(*) actually framebuffer physically is a region of the system memory too (unless it is that SRAM which is allocated for Xv overlay, which is not used by mplayer anyway).