Difference between revisions of "QuakeTV"

From QWiki
*>Renzo
m (Add note on opening UDP port)
 
(14 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 
QuakeTV is a common name for applications with a common purpose - to broadcast Quake matches to big amount of observers.
 
QuakeTV is a common name for applications with a common purpose - to broadcast Quake matches to big amount of observers.
 +
[[Image:Qtv.jpg|Quake TV homepage]]
  
 +
'''Bandwidth requirements'''<br>
  
−
'''The differences between QTV observer and Qizmo observer'''
+
* 4on4 match takes around 7kB/s
 +
* 2on2 match takes around 3kB/s
 +
* 1on1 match takes ardoun 1,5kB/s
 +
* QTV to server takes ALWAYS only 7kB/s max (depending on the game mode)
 +
** One QTV connected, 4 ports running 4on4 would be 1*4*7kB/s = 28kB/s between QTV and Servers
 +
* QTV to client takes number of clients * 7kB/s max (depending on game mode)
 +
** One QTV connected, 4 ports running 4on4 each, 10 specs on each  = 1*4*10*7kB/s = 280kB/s
 +
 
 +
 
 +
'''Requirements'''<br>
 +
 
 +
* ezQuake 1.9 build 2105 or newer, or
 +
* FTE 3343 or newer
 +
 
 +
 
 +
== Common client commands ==
 +
 
 +
'''/cmd users''' or '''/qtvusers''' to check connected clients <br>
 +
 
 +
'''/cmd lastscores''' similar to KTX lastscores command<br>
 +
 
 +
'''/demo_autotrack 1/0''' uses KTX autotrack information stored in the stream (so they should be identical in KTX and 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==
 +
 
 +
To connect to a qtv server:
 +
Windows:
 +
running "/register_qwurl_protocol" in the windows based ezquake client will do the work to register a qw:// URL handler
 +
 
 +
Linux:
 +
launches ezquake with command line arguments to immediately execute a "/qwurl" command.
 +
Example:
 +
ezquake-linux-x86_64 +qwurl qw://3@qw.foppa.dk:28000/qtvplay
 +
 
 +
 
 +
Obsolete:
 +
Can be found here:
 +
http://ezquake.sourceforge.net/docs/?vars-multiview-demos#qtv_adjustbuffer
 +
 
 +
== Clientside variables for FTE ==
 +
 
 +
'''QTVCL_EZTVEXTENSIONS'''<br>
 +
Enables extensions unique for EZTV such as chat support.
 +
 
 +
 
 +
== Servers ==
 +
* http://qtv.quakeworld.nu
 +
 
 +
 
 +
== Differences between QTV observer and Qizmo observer ==
  
 
{| class="wikitable" style="text-align:left;border: 1px solid grey" border="1"
 
{| class="wikitable" style="text-align:left;border: 1px solid grey" border="1"
Line 12: Line 65:
 
|-
 
|-
 
! Spectalk
 
! Spectalk
−
| yes || yes (delayed 500ms) || QTV chat requires ezQuake 1.9
+
| yes || yes (delayed 500ms) || QTV chat requires ezQuake 1.9 or FTE 3343
 
|-
 
|-
 
! Maxspectators
 
! Maxspectators
Line 52: Line 105:
 
! Ignore properties
 
! Ignore properties
 
| yes || no
 
| yes || no
 +
|-
 +
! Multiview
 +
| no || up to 4 players/screens || requires compatible client
 
|}
 
|}
  
 +
== Troubleshooting ==
  
−
'''Requirements'''<br>
+
'''Problem: QTV is not responding to UDP status command'''<br>
−
ezQuake 1.9 build 2105 or newer
+
This is most likely due to port 28000 not accepting connections.
−
 
+
<pre>sudo ufw allow 28000/udp</pre>
−
 
 
−
== Common client commands ==
 
  
−
'''/cmd users''' or '''/qtvusers''' to check connected clients <br>
 
−
 
−
'''/cmd lastscores''' similar to KTX lastscores command<br>
 
−
 
−
'''/demo_autotrack 1/0''' uses KTX autotrack information stored in the stream (so they should be identical in KTX and 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>
 
−
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.<br>
 
−
 
−
 
−
'''QTV_ADJUSTBUFFER 0/1'''<br>
 
−
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.
 
−
<br>
 
−
 
−
'''QTV_ADJUSTLOWSTART'''<br>
 
−
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.<br>
 
−
 
−
 
−
'''QTV_ADJUSTHIGHSTART'''<br>
 
−
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.<br><br>
 
−
 
−
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.<br><br>
 
−
 
−
RECOMMENDATION: Leave the values at 1 (100%) or change them by 20%-30% at the most.<br>
 
−
 
−
 
−
'''QTV_ADJUSTMINSPEED'''<br>
 
−
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.<br>
 
−
 
−
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.<br>
 
−
 
−
NOTE2: Allowing to slow down too much is noticeable!
 
−
 
−
 
−
'''QTV_ADJUSTMAXSPEED'''<br>
 
−
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.<br>
 
−
 
−
NOTE1: Usually during map changes the buffertime becomes exessive. This starts to delay chat and commands at some point.<br>
 
−
 
−
NOTE2: Too high playback speed is really noticeable!<br>
 
−
 
−
 
−
RECOMMENDATIONS:<br>
 
−
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.<br>
 
−
 
−
All of this info can also be found from [http://qw-dev.net/wiki/qtv 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.
 
−
 
−
== Servers ==
 
−
* [http://www.quakeworld.tv http://www.quakeworld.tv]
 
−
* [http://qw.suomicom.fi:28000/nowplaying http://qw.suomicom.fi:28000/nowplaying]
 
  
 
== Related pages ==
 
== Related pages ==
Line 125: Line 123:
  
 
== External Links ==
 
== External Links ==
−
* [http://qtv.qw-dev.net/ QTV homepage]
+
* [https://github.com/qwassoc/qtv QTV homepage]
−
* [http://qw-dev.net/wiki/qtv QTV's own wiki!]
 
 
* [http://www.quakeworld.nu/forum/viewtopic.php?id=2789 HOWTO: QTV finetuning and clientside commands at [[QuakeWorld.nu]]]
 
* [http://www.quakeworld.nu/forum/viewtopic.php?id=2789 HOWTO: QTV finetuning and clientside commands at [[QuakeWorld.nu]]]
 
* [http://www.quakeworld.nu/news/202/&c=28 Source: QTV clientside finetuning guide at [[QuakeWorld.nu]]]
 
* [http://www.quakeworld.nu/news/202/&c=28 Source: QTV clientside finetuning guide at [[QuakeWorld.nu]]]

Latest revision as of 11:56, 13 November 2024

QuakeTV is a common name for applications with a common purpose - to broadcast Quake matches to big amount of observers. Quake TV homepage

Bandwidth requirements

  • 4on4 match takes around 7kB/s
  • 2on2 match takes around 3kB/s
  • 1on1 match takes ardoun 1,5kB/s
  • QTV to server takes ALWAYS only 7kB/s max (depending on the game mode)
    • One QTV connected, 4 ports running 4on4 would be 1*4*7kB/s = 28kB/s between QTV and Servers
  • QTV to client takes number of clients * 7kB/s max (depending on game mode)
    • One QTV connected, 4 ports running 4on4 each, 10 specs on each = 1*4*10*7kB/s = 280kB/s


Requirements

  • ezQuake 1.9 build 2105 or newer, or
  • FTE 3343 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

To connect to a qtv server: Windows: running "/register_qwurl_protocol" in the windows based ezquake client will do the work to register a qw:// URL handler

Linux: launches ezquake with command line arguments to immediately execute a "/qwurl" command. Example: ezquake-linux-x86_64 +qwurl qw://3@qw.foppa.dk:28000/qtvplay


Obsolete: Can be found here: http://ezquake.sourceforge.net/docs/?vars-multiview-demos#qtv_adjustbuffer

Clientside variables for FTE

QTVCL_EZTVEXTENSIONS
Enables extensions unique for EZTV such as chat support.


Servers


Differences between QTV observer and Qizmo observer

Ability/features Qizmo QuakeTV Remarks
Spectalk yes yes (delayed 500ms) QTV chat requires ezQuake 1.9 or FTE 3343
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
Multiview no up to 4 players/screens requires compatible client

Troubleshooting

Problem: QTV is not responding to UDP status command
This is most likely due to port 28000 not accepting connections. 

sudo ufw allow 28000/udp


Related pages

External Links

Retrieved from "https://www.quakeworld.nu/w/index.php?title=QuakeTV&oldid=66614"