Distributed movie rendering strategy

During distributed movie rendering, each server renders an entire frame at a time. This has pros and cons:

Pros:
Automatic load balancing. Since each server works at its own pace, servers can have different amounts of CPU power and remain fully utilized. Less powerful servers simply process less frames.

Optimal network usage. Sending entire frames minimizes transaction overhead, and allows the maximum potential for network streaming.

Cons:
Client receives rendered frames in arbitrary order. The client must reorder the frames before they can be written to a movie stream.

The proposed solutions to the arbitrary order problem are:

1) Write all the received frames to disk as uncompressed bitmaps, and defer creating the movie until all frames have been rendered.

Pros:
Simple to implement.
Doesn't require additional memory.
Allows recovery of a partially completed job.

Cons:
Requires huge amounts of disk space; must have sufficient disk space to store the entire movie as uncompressed bitmaps, even if the resulting movie will be compressed.

2) Store uncompressed frames--in memory or on disk--only as needed to resolve holes in the frame sequence.

Pros: Uses much less disk space; can create a compressed movie directly, without storing the entire movie as uncompressed bitmaps first.

Cons:
Complicated to implement.
Server failures must be handled carefully to prevent sequence holes from persisting.
If unresolved frames are stored in memory, could exceed available memory, especially if number of servers is large.
No way to recover a partially completed job.

Ideally both methods would be supported, allowing the user to choose the trade-off.