A couple of idea's (Announcer/Replays)

Forum for discussing ET TV

Moderators: Forum moderators, developers

User avatar
KingJackaL
Posts: 666
Joined: Thu Jan 08, 2004 3:47 pm
Location: ChCh, NZ
Contact:

Post by KingJackaL »

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.
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'.

(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... ;)
User avatar
bani
Site Admin
Posts: 2780
Joined: Sun Jul 21, 2002 3:58 am
Contact:

Post by bani »

KingJackaL wrote:
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.
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.
such a feature would probably delay ettv release until 2005.
User avatar
KingJackaL
Posts: 666
Joined: Thu Jan 08, 2004 3:47 pm
Location: ChCh, NZ
Contact:

Post by KingJackaL »

bani wrote:
KingJackaL wrote:
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.
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.
such a feature would probably delay ettv release until 2005.
Haha, THEN GET RID OF IT! :D

Yeah, I was just musing the possibility for any ETTV2 or whatever ( given working out good camera angles, recording announcer sounds etc would all take a copious amount of time ).
Post Reply