If the client connections are anything like multiview (are told of where everything is), then cutting to a double-panzer for example could be done by just pop up a 'multikill' button, and they can click it to see the shot in a window as it happens. Because of the delayed transmition, the 'multikill' button could appear before the frag happens (from the clients POV), allowing them time to select it so that it could still be played back 'in-sync' with the stream. You don't need a window in which to show the shot or anything - you could simply save where their camera is (freeview/specing a player etc), then force their camera into say panzer-cam for the panzer shot, then backup the camera view they had before. That would require some meta-data to be sent between the ETTV master and client, but you only need send over the time the shot will occur, and what camera angles/types to use for the 'replay'.bani wrote:this would be incredibly difficult, and due to the way q3 works it would require roughly double the bandwidth for viewers. (eg 8k/sec -> 16k/sec) for the duration of the replay-in-window.
(in that case, it's not really a replay - just a way of ensuring they get to see the shot by moving their camera into wherever the action is)
The other way to do 'replays' would be client side, with the client parsing the stream, and when it finds a multi-frag, cutting to the shot. That would require some buffering for look-ahead to find the multifrags, but wouldn't need any more meta-data between ETTV master and slave.
If actual replays (showing a shot froma different angle after it's happened so you can watch it over again) double the bandwidth needed, then I could see why that won't happen...