If we have to move forward in the coverage area of QW, we need something much easier to handle.
When I was originally involved in developing QTV ideas this was part of my vision. That voice commentary for games would be accessible directly in the stream.

Would work something like this:

Big game coming up, qtv stream link is pasted and you connect with ezquake like now. But you have the option of writing qtv_commentary in console to switch commentary on/off.

No mumble, teamspeak, ventrilo, shoutcast stuff... commentary track directly in stream. This would also work the other way, once match is over the commentary is saved somehow. Either directly in demo, or much like you have dvdrip movies with subtitles like Rounders-CD1.avi + Rounders-CD1.srt.

With more and more media being streamed to masses via sites like own3d.net and similar sites where do we want to take QW next? Continue with QTV and a commentary stream like i described above or some kind of combo of the above and other media streaming options that we are using today also.

Today we have pretty nice stream options with own3d.net that Zalon has put a lot of work into. But it's also a lot of work to setup for matches etc. The post match work for the commentators is even harder. You have to record the mumble, cut it up with audio processing programs, package them together with mvd, upload etc.. lot of work for admins and other volunteers.

This is a major reason IMO why commentary packages are not published after matches and it's also a great loss for the scene. It's annoying to have to start mp3 files and sync with demos etc. Think if you can just download mvd and commentary is included.

There are people willing and able to do great coverage and commentary... but those same people want do just that.. cover the games. They don't wanna be bothered for hours after the game with post-game processing and boring work that both requires quite some technical skills and patience.

Maybe the commentator, who is also using QTV, can use some "commentary mode". Since he is on the QTV, he must be streaming the MVD live, how about if his client auto records the commentary direct to the mvd to a secondary audio track? Some kind of way so that commentator, after match is done, will have in his QW dir some ready-2-go package. The commentary recording will start the second the demo is being recorded, i guess at start of countdown.. allowing the commentator in those 10 seconds to do a brief comment like "EQL Finals season 12, between team1 and team2, current score is 1-0 for team2"

Are there any smart people out there who has some interest and skills to make this happen?
Any feedback, ideas etc. are welcome here.

That's a very good idea. In the old days people used to use Qizmo as a voice-com.
I've been dreaming about Camquake for spectators. But unfortunately Jogi hasn't been able to solve all the problems yet, and it won't be ready for EQL finals/never. Why would it be cool to have camquake for spectators? Imagine camera runs, rocket cameras, all kind of fancy shit U've seen in qw-movies LIVE with commentary.

I believe that if we can improve the way of spectating game s, it will make QW more popular, even among the people who're currently playing. In my eyes QW-scene is in a good shape mostly because of incredibly interesting QHlan matches and these EQL finals. It's a really inspiring to watch good games and listen good commentary, it makes u wanna play some QW.

I need to update my qtv proxy some time. :s

/qtv_commentary 1
+ camquake
this would be freakin' AWSOME, and I think everyone would enjoy spectating even more!

If just /follow would work when free floating, then only the "camera guy" would actually need camquake

stop bullying me into working in camquake again!

commentator must send voice upstream, otherwise he's just talking to him/herself.
live commentary beats dead commentary...
you don't want a situation where people might prefer to watch the game offline purely because it has commentary. or something.

lol

Why can't ezquake for example send all audio played on pc (excluding quake sounds) to QTV stream, that relay that to QTV streamers? He could still sit on mumble or another voice program, with his co-commentator, but end-users just wouldn't have to connect to those servers, but can get the commentator directly with QTV stream.

if you're capturing audio, you might as well capture the original, instead of capturing it, compressing it, decompressing it, before recapturing it in your quake client. Less risk of annoying msn(for example) popup sounds too.
Just need to send it upstream and then broadcast it out downstream.
The question is how far upstream should it go? Presumably to the top-tier proxy, before going downstream. Its much simpler if the commentators are connected to the top proxy directly as it can more easily not echo such voice (echos feel like you're constantly getting interrupted and generally results in slightly stuttery/hesitant speech despite knowing its yourself). Plus there's no offsets in voice-vs-game latency depending on where you are in the tree, assuming the commentators are at the 'top'.
The question is, who chooses which comentator you're listening to (specifically which ones to not filter), the client, or the proxy?

The simplest solution is to require the commentators to connect to the game server itself, and then everything would just trickle down naturally. Then QTV proxies don't even need to be aware that there is voice, and the client can ignore commentators the same as they could in mvds.

What's best?

The last one you mention, but then the commentators can't utilize the QTV functionality...

I'm guessing that if it's done from the server, then the voice will be in-sync for the QTV viewer right? Both for someone using a 1 second delay, and the for one who is using a 10second delay?

There is the issue with recording tho, as we need to get all commentators recorded.

I guess commentators are on mumble/vent? So why not upstream one of commentators to the top proxy (or even qw server so voice will be in mvd demo on server also) and to get rid of echo commentator(who did upstreamming) can have something like cl_qtv_ignore_autio 1. To record qtv stream commentator (or anyone who qtving) can just type /mvdrecord in ezquake and record all maps played in one mvd file. Well, you can type mvdstop at map end and mvdrecord again if you want to split it, or later use some utility to split it. Ah, and /mvdrecord ALREDY exist in ezquake, it was done for cutting particular moment from mvd demo but it can also be used for saving qtv stream u are watching.

Regarding second solution where commentators are on the game server, well it probably more simple way but I whould prefer first method so commentators are not splitted from the qtv users. However, adding voice support to normal gaming is pretty MUST HAVE feature in my opinion. And I whould be glad if we use something that you alredy added in FTESV/FTECLIENT, but it was marked like FOR TESTING PURPOSES ONLY PROTOCOL MAYBE CHANGED etc etc, so I never bothered to check it, but if we did not add it even in beta state it whould be never added. And by adding I mean ofc adding it to the most hated mainstream server/clients, read ezq/mvdsv. Two clients(ezq/fte) should be enough to force rest clients(there any?) to support this extension? Voice is probably last thing which current qw lacks in my opinion, ofc there is mumble and such but its kinda hassle and uncommon in mixs for example and you will be able voice-chat/blame/trashtalk with anyone in prewar and such... whould be nice. :E

<3

Agree on something, go code

I trash-talked with Spike the other day using mm3 in FTE, that worked well

But please no clientside recorded mvd's, keep it server side!. We don't want the same issues as they had in Q3, where some retard forget to press record, or he lags or some shit so the recording is missing parts of the game.

I would prefer that the voice was split from the mvd tho, because we will end with quite big demo files + break compatibility with older clients. Also there are a lot who just want the demo. I can however understand that this is harder to do, right?

are you joking or is there any behind the scenes hatred to ezquake?

currently any such qtv commentators are assumed to be on vent/mumble, as there's no well-tested, wide-spread alternative. however, separate mumble/vent and qtv is clumsy, unintuitive, and remains separate once recorded. Better to let qtv support voice directly (everything uses the speex codec anyway, nowadays).


I agree that splitting commentators from qtv-spectators is bad karma, but you still have the issue of tcp buffering and associated delays.
FTE does support voip now, I'm happy enough with the network protocol, and it seems that a few people are already using it on some TF servers (at this point in time, capturing is available only via directsound, so only windows users are able to talk, but any can hear).
The problem is that it has no QTV-specific integration. Using spectators as your commentators can work as is, but yes, I agree, bad karma. And I'm aware that I'm repeating myself, but I expect that the time delays due to tcp, both receiving and sending to commentators, would amount to at least a second of delay between a frag and a 'yay!' being heard from the commentator. If they're directly on the server, it'll be much better synced.
As to whether this is tolerable or prefered or not is anyone's guess, I suppose non-commentators could be given an extra delay in order to sync audio.
I guess the solution is that of implement it and see, and hack in some artificial latency to cope with it.


Integrated voice chat is much simpler for randomized team type mods, or coop, as found on the TF servers. FFA games might result in a lot of swearing. And my biggest personal issue may be soundboards... Particuarly arnie... Otherwise its nice to have the option, might help community building. You don't have to leave it enabled.
There are other engines around, eg quakeforge seems to be in a period of revival right now.
But yeah, if ezquake is able to silently ignore voice chat in mvds, and its actually used, then other engines wouldn't have a choice in the matter. Bad karma. But a tool to strip voice from mvds would do the job just fine. Presumably a stats parser tool could be tweeked for it. Alternatively use a different demo packet type, and get bigfoot to adapt his mvd fixer for it, could also be useful in qtv proxies for filtering voice to choose which commentator to retain so you can allow different people to comment upon the same game on the same proxy (or to mute idiots without wasting your bandwidth, or that of the proxy).
If you, qqshka, have a suggestion as to the mvd packet type to use, feel free to suggest one, though I believe they are all defined. From memory, the clientcommand packets used in qwd are not used in mvd, perhaps those could be reused? Is that safe? Sane? Any way to give sane error messages in older clients?

For me the problem can be decomposed into two separate parts:
1) easy playback of commantary
- We should not forget that at the moment the popularity of live.quakeworld.nu vs. qtv.quakeworld.nu is about 40% vs. 60%, so it's a question whether this thing is "worth it". Personally I'm really hesitant and looking for rather "cheap" solutions, than what is proposed above, like duplicating whole functionality of mumble and moving it to QTV or qwsv.
First simple approach: QTV could just broadcast the URL of public audio stream with commentary (mms:// http:// mumble:// ) and let the clients do whatever they can do with that. (at least say "unsupported audio protocol xxx://". This could be added to MetaQTV for example.

2) easy recording
The second part of the problem is recording. I'm not convinced it's worth the hassle, I mean the imaginary coder will spend a couple of days coding a system for automated recording, categorizing, selecting and downloading of audio streams, while the only thing that is supplied here is single person pressing "record" and "stop" buttons. Adding a functionality that'd play mvd+mp3 from an archive simultaneously is easy.

for 2), when next mumble version goes stable, we will have record function in mumble.

I still liked the inbuilt voip in FTE a lot tho, but I see a lot of issues with it.

Some of the issues I can see regarding it is:
Privacy issue, I'm not sure that all players want spectators and qtv viewers to be able to hear their mm3 chat.
If it's kept on the server level, commentators will lack qtv features.
Demo files with voice recordings will have a quite large filesize.
Breaking compatibility for demos with older clients.
Using servers with voip disabled for the commentated matches.
How do we handle who is allowed to speak during commentating sessions?

Especially the first and the last on my list are the bigger issues imho. I'm guessing the privacy issue could be handled by a simple setinfo setting, where you disallow the server to stream your voice to anyone else than your teammates. How to use it during commentated matches is a different matter tho, I don't see any easy way to go about that.

Today the content provider (read: commentators), can control who is allowed to talk, this is handled by voicing people in the live commentary channel on the qw.nu mumble server. If someone who doesn't have voice on that channel wants to commentate a match, that is possible by either using one of the channels created for that purpose, or by creating his own channel.

If the same kind of control needs to be build into the qw server it sounds overkill to me, and even if it was added... We would still have the issue on how to control it? If it's handled by the server, then the commentators needs login/auth/admin/rcon/vip/whatever on every server that is to be used for that purpose and that is impossible. If it's handled by the mod with public commands, what is to stop anyone from fucking it up before/during a match?

Then there is recording, if this is handled client side, we are no further than we are today. We will still get fucked recordings if the client crash, user forget to record, user lags, whatever. I've seen this in Q3 and it was a big problem, I really would like to avoid that in qw. Server recordings would fix this tho, but that will require commentators to be spectators and we are then back to the qtv/access issue again.

Another thing regarding spectators, is the whole ghosting issue and I can see problems getting commentators on the server, and not being able to force nospecs anymore.

Just to make it clear, I'm not in any way putting this feature down, I think it's awesome... It was so nice to just bind a button to +voip and then being able to use mm3 with my teammates. But as I see it, there is a long way from using it with 3 teammates to using it for commentating matches with 100 people around.

Hi, I'm taniwha from QuakeForge, and I'm the slacker that rxr and ParadokS approached long enough ago to make me want to cry. I'm happy to say that I've been fairly active in the QF code for the last 5 or so months.

Anyway, this page (my own machine, not yet on the QF site) gives an overview of my vision of what qtv should be like (as of 2004), and its current status (as of January 2010/now).

QF is already using a modified mvd stream for qtv, so putting voip into that would be a non-issue. With appropriate void encoding (for legal reasons, not mp3), it shouldn't be that much bigger.

Regarding client compatibility, as the mvd stream is already modified (for encapsulation in the low-level qw protocol, and packet-loss tolerance), any proxies doing recording would either record using the modified mvd stream (allowing voip to be recorded as well) and utilities could be used to extract the two streams, or the proxy could record the two separately (or both ways at once). Note that the code is not yet at this stage.

One very important point regarding recording: right now, the QF qw-server is perfectly capable of both qtv streaming and mvd recording at the same time. Of course, the server recorded demo would not have commentary.

QF qw-server has theoretical support for KTPro ("sv_progs_ext ktpro" before map load). I would very much appreciate any feedback on how well/if it works. I would like any feedback on QF's qtv itself as well.

[edit]It seems I may be a tad out of date: it looks like KTX is the thing to support (currently investigating).

Yes I doubt too that TCP able to handle it, that why I think we should just upstream audio stream from the mumble.


I don't get that part. As I recall mvd is just a sort of container for slightly modified QW protocol messages, and nothing is ignored, besides qizmo voice (svc_qizmovoice 83) yet its not related to mvd. So I think using some new svc whould be OK and one who interested in playing it in qwcl 2.33 can do some tool (extend qwdtools for example) for stripping it from qwd. New svc should trigger nice error message in all clients though. However this new svc should contain something to identify voice source, user id or something, qtv assign ids for all clients too(and ezquake have info which user id assigned for qtv user, assuming there no chaining), so it can be used both on qw server and in qtv but there should be something that let client know this voice from qtv or qw server since ids can conflict. Using ids allow muting and showing who is talking. Probably there should be sent voice source position in 3d space, so you can use voice positioning like mumble But that above it just random thoughts.

it was a joke, but yes ofc there some haters but its offtopic

Hi. Probably you should join irc? quakenet you know? #quakeworld #ezquake #fte etc. Probably you already did it.


That all need testing, so one have to set up server/proxy and you have to ask few(as much as possibile) players to test it. So if you intouch with Paradosk it should not be the problem though.


Myeah, either support KTX or one have to write something like that in qc, rxr give away sources of KtPro so it probably can be used as start point, well latest ktpro is quite good too though, so it can be used as end point , even I favor KTX but that is not surprise since I am author.

There no point for cheap solution since voip for qw server alredy done in FTE, all you need is to figure out how to make it non abuseable. Whole feature mute or per user mute does not look like a hard task(mute can be done server side or client side or both). In team games voice sended for mates only, specs treated as own team, but that is obvious/native like with mm2. The only problem is that QTV uses TCP so I doubt you can really use voice here because of latency so upstreamming of commentators mumble voice to qtv (and thus back to qtv users) looks quite native, even that whould be delayed though. About abuse on qtv, well, it can be solved too, like you type /commentator on qtv to became one, qtv clients whould have ability to turn/join this commentator on with some command "/listen nick" or maybe rather all commentators are hearable by default and you have ability to mute particular or something, since normally there should be only one commentator. There can be something like "/votecommentator" to gain commentators rights or "/commentator password" you can imagine different schemas even I against password protected commentators rights since it make qtv configuring harder and need to spread password between commentators somehow. Password is probably needed just to ban/kick really abusive persons.

So, probably allow shit load of commentators but just listen to right one?


I don't get this part, personally I think external voice in mp3 or whatever format is a no go, since it too hard to sync with demo, I can press pause/fastforward/slowmotion and syncing it together... no thx. Voice incapsulated in normal qw protocol (qwd/mvd) is a way to go, that a cheap solution

That depends on the player, can't see why the same features (pause/fastforward/slowmotion) shouldn't be possible when having voice in it's own file?

anything other than demospeed=1 will need to mute voice as it won't sync up at all without (could play it back at a different rate, but that's silly, could be amusing though, yay chipmunks).
Regarding separate files for voice, you end up with issues if two demos with the same name exist. You also need to use two separate download requests to download such a demo from a server. Playback needs to sync audio basically by playing two demos simultaneously. Two sets of counters, etc. If there is no audio, you're left with a voice file with lots of timing info and nothing else, with dummy packets, and all sorts of messyness. You also have people distributing just the mvd, because they don't realise they need to grab the voice recording too. Putting it in the mvd keeps it as a single and complete package - more idiot proof, if you will, but won't play in older clients unless they're modded to know how to ignore it.
However, the two biggest advantages of a separate file are 1: audio can easily be stripped for size or compatibiilty. 2: You can re-record audio at a later time.

Anything sent from a qw server can end up in a .qwd file. If you have team chat, you _will_ encounter those svcs. Thus voice in mvds as just new svcs is cheap because its basically free, assuming the client supports it for regular chat. If its easy to add code to skip over it in other clients, or there's a tool to strip it, and so long as the default is to not record voice (allowing other engines to add it depending on the feature's actual demand instead of forcing it because noone can be bothered to switch it off), my only real concern here is fuhquake itself, but there have been mvdsv changes that already broke compatibility there anyway.

qq, commentary is always much more interesting to hear when there are two people arguing about the game, or from different perspectives in a team game, or so. In such a situation, they need to hear each other with a low latency so they don't interrupt each other so much.

Probably I fail to explain what I mean with upstreamming of mumble commentators chat. So, there is qtv, mumble and two commentators (A-commentator and B-commentator). Commentators talking on the mumble, so they hear each other with low latency and such, however ONE of commentators (say A-commentator) upstream this whole mumble audio stream (A+B) to the qtv so qtv users able to hear both commentators with minor latency (0.5s or something). Since commentators using qtv too they _must_ mute voice from the qtv for echo preventing.

((A-commentator + B-commentator) mumble) -> ezquake -> qtv -> qtv_clients

I did not say it is NOT possible, but it is HARD to implement, require particular media player (should be OS independant, lol?) with particular abilities and such and yet I am not even willing to think about it when there more native/cheap solution on the surface with extending QW protocol with voice, this is even ALREADY done in FTE...