Clock

One of the trickiest things is clocking and synchronisation.
Since the system clock and the source clocks will not be perfectly
synchronised with each other, we need to pick a master clock.  The
master clock should match the clock of whichever source we are taking
audio from since audio discontinuities are so undesirable.  Latency
between the source and the mixer is variable so we will need to
generate a clock indepdently and adjust the rate to match the rolling
average frame rate from that source.

We should use a high-priority thread to implement the clock.  At each
frame interval it will take a video frame off each input queue that
has one available and add an item to the output queue specifying the
input frames and mixer settings for the output frame.  Where no new
input frame is available it should repeat the previous frame.  (Note
this should only ever happen for video.)

Frame storage

For each input frame we keep both the original DV data and the
decoded data, since we can usually copy across the DV data rather
than reencoding it.

The thread(s) servicing sources will parse the DIF blocks and assemble
complete frames.  (So long as we keep using TCP then this is trivial.)

Decoding and encoding

Initially no encoding will be needed.  The thread servicing the output
queue will copy encoded audio and video data from sources.

Q: At what point and in what thread do we decode frames for display?
