I FIGURED OUT WHY THE VIDEO IS 320x224 Square decided that the best way to intermix movie data and 3D data was to manually place the video bitmap into VRAM via the the CPU and not by using an MDEC DMA transfer. This allowed the engine to manually lay down video data and then paint the 3D model on top when it was needed.
Sadly, due to data bus bandwidth limitations, You can only transfer so much data to the GPU from the CPU before it overflows. To get around this, Square decided to send the video data using twenty 24x224 "strips", pushing them into the VRAM with a write/flush/write/flush/write/flush loop. There isn't enough bandwidth between the CPU and the GPU to make the strip longer.
If the made the strip more narrow, (and therefore longer so it will go to 240), they would run into pixel data alignment issues.
If the strip was made to the next logical pixel data boundary(8x240), the the video would have required too many cache flushes, therefore slowing down the FPS.
In the end, the resolution tradeoff didn't hurt the video quality, so the resolution stuck.
It also has the added benefit of more Color Look Up Tables to be tucked away at the bottom of the viewport.
I have screenshot of the VRAM in mid-write so show what I mean. You can see it linked
hereOn the right and side is the GPU's Command chain for that vsync, where it is laying down the 24x224 strips and flushing the cache after every write.
And that should put an end to that argument
== EDIT ==
And, when the move flips from 24-bit to 16-bit the strips become 16x224 this allows them to use the same program loop with perfectly aligned pixel boundaries with the same amount of cache flushes. With less data, this frees up some bandwith to draw 3d polys on the screen before vsync.
This post is the proud winner of my prestigious "post of the day" award. ~Covarr