Ok, time for some very heavy technical stuff...
Lets start with a NTSC ColecoVision (60Hz):
Z80 Frequency: 3,579,545
Scanlines per frame: 262.5
Active scanlines: 192
VBlank scanlines: 70.5
Z80 cycles per frame: ~59,671
Z80 cycles per scanline: ~227
Necessary delay between VDP accesses during active display: 28 cycles
Maximum number of VDP accesses during active scanline: 227/28 = 8 -> 1.5KB for all 192 active scanlines (worst case for 262 scanlies -> 2KB)
1 sample/scanline -> 262 lines x 60 frames = 15.35kHz
So, total transfer rate from CF:
- video: 9KB/movie frame x 12 movie frames = 108KB/s
- sound: 15.35KB/s
- Total: 123.35KB/s
All would be fine if it wasn't for the game logic. The movie format is 256x144, which needs to be loaded during 5 frames. That means 28~29 movie lines per frame. A movie line is 64 bytes long (32 bytes pattern, 32 bytes color), so we need 1856 VDP transfer per frame, plus 262 audio transfers per frame, for a total of 2118 transfer. Now supposing that each transfer takes 28 cycles (which isn't always true), we get 59,304 CPU cycles per frames. Very close to the total available cycles per frame. Now, if I can get 9 transfers per scanline (8 bytes for video and a byte for sound), then I would reduce the number of used cycles to: 232 scanlines worth of video/audio * 227 cycles/scanline + 30 scanlines worth of audio only * 28 cycles (worst case) = 53504 cycles.
That gives us 6,000 free cycles per frame. If the code is broken into 5 pieces (because we need 5 frames for each movie frame), that would give us 30,000 free cycles per movie frame for game logic. That is basically half of the total CPU cycles we normally get per frame, which is reasonable for a simple game like DL.
While I believe the video player would be fairly simple to implement, integrating the player with game logic and still keeping everything in sync would be quite a challenge, though an interesting one...