I just tested QTV with sassa

it's amazing, and it's frickin easy to setup too

I know this has already been said, but people (admins?) need to do this!

1. download a new mvdsv build!
2. put "mvd_streamport 4000" (or some other port, just get a standard port for it like we have with 28000 qizmos!) in the server config

and then anyone can setup a qtv server just by doing this!

1. start qtv
2. connect <serverip>:4000
3. mvdport 29000 (tcp)
(4. port 29000) (udp)

and then! anyone can do a connect <qtv server ip>:29000 and watch qtv!

it's amazing! try it yourselves!

the latest mvdsv got some bugs that needs to be fixed if I recall corectly? (can some1 confirm?)

I think if those bugs are fixed then this is a "go-go"

I tried it and it worked fucking great....

yeah, unfortunately new mvdsv has some bugs. bug vvd and disconnect to fix them!!

this looks promesing.

this should take specing to the next level.. please implement this in competitions as soon as possbile

How much bandwidth does it use?

it use 15 fps from the server compaired to the 77fps the player use!

should be something like (20 minute mvd demo size / 1200) * 8 kbit/s?

most interesting.
which servers are supporting QTV at the moment?

off topic: about that 15fps thing.. After the security module has been released for ezQuake and independent physics 1 is allowed in tournaments people are going to play with 100-200 fps and the bandwidth usage is doubled, i hope servers can take this..

Independend physics means independent of the server fps? This means that it won't affect bandwidth between server and client, right?

nope, its client side not server side

i assume the code behind this already involves a lot of protocol forwarding...therefore is it conceivable to suggest that it could be expanded to allow it to perform routing like qizmo?

it would be nice to have a server set up to automatically route any client that connects to another server elsewhere, then static 'forwarders' could be setup on the ideal route between certain countries and a destination server

then two different ips can be given out to each country that is competing

well camera mode is generally just someone with 'autotrack' turned on, so people can just individually have that enabled (if they want it) while speccing the streamed qtv/mvd

.qwz != .qwd.zip , it is a proprietary compression format that nobody managed to decipher however, it would be trivial to allow zquake/ezquake to directly playback .mvd.gz (as created by mvdsv using GPL gzip format)

voice comm would be clean and nice to be directly done in-client but its significant work that probably nobody can be bothered to do considering teamspeak etc.

it would also be nice to have mvd allow a 'commentary' sound track to be mixed into the sounds of the mvd and played back alongside it

ah ok

anyhow i think .gz makes most sense currently as that is the format demos are likely to be downloaded directly from the mvdsv in - and hence allows immediate playback after downloading from within the qwcl.exe

files download from ch-tv in a .zip file are much less important as they can easily be extracted as part of the manual download process as you are already outside quake so its not really that big a need to playback .zip files

although...it is worth noting that adding support for .mvd.gz would also add support for .mvd.zip

i.e. you would also be able to playback .zip files as long as they only contain a single file (the .mvd)

this is the difference between gzip and pkzip/zip, gzip only compresses single files (it is up to you to build archives using tar if you want those) whereas pkzip/zip involves an archive process to store more than one file - the actual compression is the same.

Data compression and packet repeat.

actually, FTE supports playing .gz zipped files (both from your harddrive and from typing something like playdemo http://whatever/whatever.gz). Also, FTEQTV could be used for both routing and you won't need to follow one person anymore.. it'll be as if everyone is connected to the server.

i think he wanted the one camera thing so that you could make sure you were watching the same pov as the person who is giving commentary

Linux QTV proxy seems to be pretty stable


It's the same thing with precompiled and compiled version (2666, happens when client connects to the QTV proxy that is connected to the server).

so when do we see this thing in action?

I'd like to know too. Can someone please clarify what's lacking or whatever to make this happen?

ive only gotten the last version to work with about 20 fps, with and without the recommended "choke" option.

the support (if you manage to get an answer from anyone) consists mostly of "it should work."

a few notes about QTV and what i read here:
1) ezQuake's fps-independent physics have no power on your bandwidth usage.
2) 5 specs with 77FPS (client doesnt matter) is like 25 QTV proxy's.
QTV ~ 15 MVD-packets per second.
QW playder ~ 77 QW-packets per second.

Even if we assume MVD packet is 10 times bigger that QW one --> QTV > Qizmo. // For match-spectating ofc.

When we can see this in action:
When server admins upgrade their servers to fresh mvdsv. When there will be more public QTV's.


My opinion: It will take at least one year.

I dont saw smart way to admin QTV stuff with current MVDSV - thats a real problem (All QTV slots are full of random specs --> camera cant connect).
Currently QTV cant replace qizmo. I'm not reading FTV changelogs for last month, but if there are ability to reroute ( local_qwcl-->qizmo1-->FTV-->qizmo2-->server - eah, if FTV is going to replace qizmo it _MUST_ be compitable with qizmo 2.91 as rerouting proxy) - it's time to discuss it here

So what we got? Very very old servers (because of dead-admins. i found all alive admins slowly updating to 0.19.20 - thats good), and qizmo... Well ofc. server admins can hosts: qw-server, qizmo port, FTV port. But it's better to make new qw proxy . We only need QTV feature, reroute feature, may be packet repeat (nice feature if you have packetloss with broadband ).


P.S. All alive server admins - if you run mvdsv, it's stringly recommended to update to 0.19.20. KTPro is remote shell on you box, last mvdsv have some hacks for KTPro bugs (if we fix KTPro bug with mvdsv it is HACK!).

Empezar: That was a bug introduced with the .qw say command, unfortunatly.
There should be a partial workaround - use fteqwcl and interpolation - qtv: choke 1, client: cl_nolerp 0
My private dev versions don't have this issue - I just need to commit some time.

Disconnect: QTV uses TCP. TCP merges smaller packets into larger packets as appropriate, so not only does it send about 20 frames per second, but it also sends only two or three packets a second! Of course, because it's derived from multiview stuff, the server is free to change the packet rate. Also, TCP is oriented around reliable efficient delivery of data, so there are no redundant deltas as in the standard qw protocols.
Because all the data is stream based, it is entirly plausable to add stream compression.
I do still intend to adapt the protocol to use passwords, which will make it more consistant with various internet standards and ultimatly make it more adaptable in future (like supporting compression).

mvdsv really needs a self auto-updating feature

I can imagine it now!



]connect example.qwsv.com
Connected
The Place Of Two Deaths
------------------------------------
Checking sounds
Checking models
Checking skins
]say Hey everyone, I'm going to make the server update to fix a minor bug, shouldn't take too long
Player: Hey everyone, I'm going to make the server update to fix a minor bug, shouldn't take too long
]say Here goes nothing!
Player: Here goes nothing!
]rcon sv_update
Downloading...
Server is shuting down for update, please reconnect.
Server disconnected.
]reconnect
Connecting to example.qwsv.com...
Connecting to example.qwsv.com...
Connecting to example.qwsv.com...
Connected
Connection lost or aborted
]reconnect
Connecting to example.qwsv.com...
Connecting to example.qwsv.com...
Connecting to example.qwsv.com...
Connected
Connection lost or aborted
]quit




Ahh yes. Automated updates would rule!
If I ever implement it, please remember not to copy my code. Thanks.

i was thinking more along the lines of it auto updating at something like 5am if connected players == 0

FTE QuakeTV Guide
(I don't know why FTEQW guys still didn't copy this to their homepage, it's available since January 2006, I told them about this page personally at least twice, with permission to copy it.)
Replacing Qizmo with FTEQTV is something that will take you away from the real purpose of why FTEQTV has been made. Why don't you stick to talk about why it's not being used already? I've seen some servers with new MVDSV build running, why there are no Quake TVs around?
BTW does MVDSV still crash when QTV (dis)connects from/to it?

mvdsv dont have auto-update feature. It have a something like a backdor that can be used for updates (if we are talking about security - this feature is backdoor). Run mvdsv with -enablelocalcommand, and let it execute pwd.cfg where you have:
sv_crypts_rcons 1 // evil wifi hackers cant snatch your rcons
master_rcon_passowrd @_V3rY_str()nG_p@$$w0rD_<even more charactes here>

Use any other mvdsv/ktx settings. Yes. mvdsv/ktx. KTPRO + mvdsv -enablelocalcommand = INSANLY UNSAFE, because of KTPro bugs.

Few days later if wish to upgrade ktx to cresh cvs version for example. What you have to do:
1) run ezQuake
2) rcon_password <thats long unreadable string>
3) connect your.server:port
4) cmd techlogin $rcon_password
5) rcon localcommand rm ./ktx/qwprogs.qvm
6) cmd upload ktx/qwprogs.qvm ktx/qwprogs.qvm (I assume you have ktx directory inside your quake root folder both on clint and server side)
7) rcon restart

Same way you can upload fresh mvdsv executable.

P.S. "-enablelocalcommand" is extremly insecure in case of KTPro usage. It seems to be fine with other mods. Empty master_password also more secure, but it seems you only can brute-force it .



Auto-update feature is a bit hard for mvdsv :E. And no system daemons must have it. It is server admin's job to update his software. Even he run his server with windows (hello BLT servers).

OK.. so not a single public QuakeTV up by now (at least for testing purposes)?

i was watching Quake3 CPL Nordic through its GTV mod.. i don't know how that works, but i was having a smooth speccing experience with multiview (implemented recently) and there were ~500 spectators