Difference between revisions of "QuakeTV"
*>Renzo m |
*>Renzo m |
||
| Line 11: | Line 11: | ||
!width="300px"| Remarks | !width="300px"| Remarks | ||
|- | |- | ||
| − | ! | + | ! Spectalk |
| − | | yes || yes || QTV chat requires ezQuake 1.9 | + | | yes || yes (delayed 500ms) || QTV chat requires ezQuake 1.9 |
|- | |- | ||
| − | ! | + | ! Maxspectators |
| ~100 || thousands | | ~100 || thousands | ||
|- | |- | ||
| − | ! | + | ! Bandwidth usage |
| max server allowed || 7kB/s 4on4 || depends on the number of players | | max server allowed || 7kB/s 4on4 || depends on the number of players | ||
|- | |- | ||
| − | ! | + | ! Server cpu usage |
| same as for player || 0% || on 2GHz K8-cpu one player takes 1% cpu | | same as for player || 0% || on 2GHz K8-cpu one player takes 1% cpu | ||
|- | |- | ||
| − | ! | + | ! Autotrack |
| yes || yes | | yes || yes | ||
|- | |- | ||
| − | ! | + | ! Follow commentator |
| always || switchable | | always || switchable | ||
|- | |- | ||
| − | ! | + | ! Weapon stats |
| +wp_stats || +cl_wpstats || +cl_wpstats can be modified! | | +wp_stats || +cl_wpstats || +cl_wpstats can be modified! | ||
|- | |- | ||
| − | ! | + | ! Ability to track anyone |
| no || yes | | no || yes | ||
|- | |- | ||
| − | ! | + | ! Smooth experience |
| sometimes || the best possible || QTV/MVD data will be interpolated | | sometimes || the best possible || QTV/MVD data will be interpolated | ||
|- | |- | ||
| − | ! | + | ! Finetuning |
| no || yes || check QTV wiki for more info | | no || yes || check QTV wiki for more info | ||
|- | |- | ||
| − | ! | + | ! Vulnerable to network lag |
| yes || not playback || QTV chat could be delayed (finetuning possible) | | yes || not playback || QTV chat could be delayed (finetuning possible) | ||
| + | |- | ||
| + | ! Delayed playback | ||
| + | | realtime || delayed || QTV: 1s delay during prewar, 7-10s delay during game | ||
| + | |- | ||
| + | ! Flood protection | ||
| + | | no || yes || can be configured in QTV | ||
| + | |- | ||
| + | ! Ignore properties | ||
| + | | yes || no | ||
|} | |} | ||
| Line 60: | Line 69: | ||
'''/autotrack''' with ezQuake 1.9 stable will be the same as above. So you can use your existing 'autotrack' bind for the same function while on QTV<br> | '''/autotrack''' with ezQuake 1.9 stable will be the same as above. So you can use your existing 'autotrack' bind for the same function while on QTV<br> | ||
| − | == | + | == Clientside variables == |
| + | |||
| + | ''for ezQuake'' | ||
'''QTV_BUFFERTIME 0.5'''<br> | '''QTV_BUFFERTIME 0.5'''<br> | ||
Revision as of 18:45, 9 May 2008
QuakeTV is a common name for applications with a common purpose - to broadcast Quake matches to big amount of observers.
The differences between QTV observer and Qizmo observer
| Ability/features | Qizmo | QuakeTV | Remarks |
|---|---|---|---|
| Spectalk | yes | yes (delayed 500ms) | QTV chat requires ezQuake 1.9 |
| Maxspectators | ~100 | thousands | |
| Bandwidth usage | max server allowed | 7kB/s 4on4 | depends on the number of players |
| Server cpu usage | same as for player | 0% | on 2GHz K8-cpu one player takes 1% cpu |
| Autotrack | yes | yes | |
| Follow commentator | always | switchable | |
| Weapon stats | +wp_stats | +cl_wpstats | +cl_wpstats can be modified! |
| Ability to track anyone | no | yes | |
| Smooth experience | sometimes | the best possible | QTV/MVD data will be interpolated |
| Finetuning | no | yes | check QTV wiki for more info |
| Vulnerable to network lag | yes | not playback | QTV chat could be delayed (finetuning possible) |
| Delayed playback | realtime | delayed | QTV: 1s delay during prewar, 7-10s delay during game |
| Flood protection | no | yes | can be configured in QTV |
| Ignore properties | yes | no |
Requirements
ezQuake 1.9 build 2105 or newer
Common client commands
/cmd users or /qtvusers to check connected clients
/cmd lastscores similar to KTX lastscores command
/demo_autotrack 1/0 uses KTX autotrack information stored in the stream (so they should be identical in KTX and QTV).
/autotrack with ezQuake 1.9 stable will be the same as above. So you can use your existing 'autotrack' bind for the same function while on QTV
Clientside variables
for ezQuake
QTV_BUFFERTIME 0.5
Basically defines the amount of buffer ezQuake buffers from QTV stream and the default value is set to 0.5 (500ms). You can try changing this to different values but notice that 0.2 (200ms) is the lowest allowed value.
QTV_ADJUSTBUFFER 0/1
Enables automatic finetuning of the QTV_BUFFERTIME buffer. This means that your client is trying to keep the set QTV_BUFFERTIME by variating playback speed. So if the buffer falls short of 500ms it will slow down the playback and if the buffer gets excessive for some reason then the playback speed is increased. After the buffer level is back on the configured value, 100% playback speed is set. NOTE: Enabling this feature limits QTV_BUFFERTIME to a minimum of 0.5 (500ms) while higher values can still be set.
QTV_ADJUSTLOWSTART
Tells QTV_ADJUSTBUFFER when to start slowing down the playback speed of the stream so buffer level can climb back to normal. The value 0.8 means 80% of the configured buffertime, for example if you have set the buffertime to 0.5 (500ms) then it would start slowing the playback speed at buffer level of 0.8*500ms=400ms mark until the buffer reaches 500ms again.
QTV_ADJUSTHIGHSTART
Tells QTV_ADJUSTBUFFER when to start speeding up the playback speed of the stream so buffer level can fall down to normal. The value 1.2 means 120% of the configured buffertime, for example if you have set the buffertime to 0.5 (500ms) then it would start speeding up the playback speed at buffer level of 1.2*500ms=600ms until the buffer reaches 500ms again.
WARNING: Do not set too low value for lowstart and too high value for highstart. Setting too low value for lowstart could mean running out of the buffer before enough slowdown has happened and in this case, playback would pause for a moment. Setting too high value for highstart causes more lag on giving commands (cmd users) and chatting.
RECOMMENDATION: Leave the values at 1 (100%) or change them by 20%-30% at the most.
QTV_ADJUSTMINSPEED
Defines the slowest possible playback speed when starting to run out of buffer. Value 1 means 100% speed and value 0.5 means 50% of the normal playback speed.
NOTE1: Not allowing to slow down enough, buffer level might still drop down to zero if there were longer network lag. This causes pausing during playback.
NOTE2: Allowing to slow down too much is noticeable!
QTV_ADJUSTMAXSPEED
Defines the highest possible playback speed during excessive buffertime. Again, value 1 means 100% playback speed while 1.5 means 150% of the normal speed.
NOTE1: Usually during map changes the buffertime becomes exessive. This starts to delay chat and commands at some point.
NOTE2: Too high playback speed is really noticeable!
RECOMMENDATIONS:
Let the speed variate less over longer periods of time. For example 5-10% playback speed increase/decrease over 2 seconds isn't as noticeable as 25% speed increase over half seconds. Minspeed should be 0.9 - 0.95 while maxspeed should be 1.05 - 1.10.
All of this info can also be found from QTV wiki. Try experimenting different values for the best performance. I personally use default buffertime, default low/highstart and 0.9 minspeed and 1.1 maxspeed. With these changes the chat will not get delayed and most of the time I get no buffer underruns (pauses) but 500ms is still quite a short time for these values so I might want to consider actually increasing the qtv_buffertime a bit.
Client command scr_qtvbuffer 1 gives more detailed statistics about the buffer size and demo playback speed.
- written by Renzo.