Hi there, I'm wanting to get some advice on the possibility of some broadcasting tools that will help with some of the challenges we have at TFLIVE. If you haven't heard of TFLIVE, we are currently the main broadcasting group for Australian 6v6 TF2.
The situation
Our main problem at the moment is the lack of crossover between the people who a) Have relevant game knowledge, b) have the internet to stream (Australian internet is a bit dire) and c) want to do the whole thing. I have been looking into who is around, and I have determined that the best way to move forward would be to have the ability to decouple the Broadcaster/producer and the Cameraman. I'm thinking of multiple ways to do this, and wanting advice and input from anyone who knows about these sorts of things. Mainly, I want to be able to make the cameraman slide into the role with minimal setup.
First Idea: STV cameraman
I've looked into Source TV and it appears to have the ability to have a "cameraman" who directs the camera for other users watching an STV stream. From what I've read, you have to have the cameraman inside the actual server watching in real time, which in most common setups would prevent the cameramans ability to react to what the casters are saying.
If it was possible to act in this role from an STV, that would be ideal, but I'm not sure if that's possible. Its problems could be alleviated by having STVs with multiple delay lengths (a private STV for casters with zero delay, and a public STV with the standard 90s delay) but I'm not sure how possible that would be or what the infrastructure would look like.
This would be the most ideal situation because if it does work, it would only require a game client for the "cameraman" to get right into it. This would make it the easiest for him to be any community member with decent game knowledge.
Second Idea: Client RCON
Some way to execute commands remotely on a foreign client, either from another client or from an external application. This would require some programming from our based casting plugin coders (or someone else who is interested), and I know at least one was looking into an external console that could be used outside the game. Would obviously require much more setup for the cameraman, but it would be fairly intuitive once we get it going. Probably a command with a prefix like rcon, but executes the command on both the local client and the foreign client. That way we could use the casting commands set up in the casting plugins already to select players. Unsure if the spec_next spec_prev commands will be ok to use in this setup.
Mainly I'm just looking for general advice on how this might work. I'm unsure about the benefit that other communities might have with this, but I believe that decoupling the producer from the cameraman may provide some pretty good benefits for large casts such as finals and should help increase quality.
Hi there, I'm wanting to get some advice on the possibility of some broadcasting tools that will help with some of the challenges we have at TFLIVE. If you haven't heard of TFLIVE, we are currently the main broadcasting group for Australian 6v6 TF2.
[b]The situation[/b]
Our main problem at the moment is the lack of crossover between the people who a) Have relevant game knowledge, b) have the internet to stream (Australian internet is a bit dire) and c) want to do the whole thing. I have been looking into who is around, and I have determined that the best way to move forward would be to have the ability to decouple the Broadcaster/producer and the Cameraman. I'm thinking of multiple ways to do this, and wanting advice and input from anyone who knows about these sorts of things. Mainly, I want to be able to make the cameraman slide into the role with minimal setup.
[b]First Idea: STV cameraman[/b]
I've looked into Source TV and it appears to have the ability to have a "cameraman" who directs the camera for other users watching an STV stream. From what I've read, you have to have the cameraman inside the actual server watching in real time, which in most common setups would prevent the cameramans ability to react to what the casters are saying.
If it was possible to act in this role from an STV, that would be ideal, but I'm not sure if that's possible. Its problems could be alleviated by having STVs with multiple delay lengths (a private STV for casters with zero delay, and a public STV with the standard 90s delay) but I'm not sure how possible that would be or what the infrastructure would look like.
This would be the most ideal situation because if it does work, it would only require a game client for the "cameraman" to get right into it. This would make it the easiest for him to be any community member with decent game knowledge.
[b]Second Idea: Client RCON[/b]
Some way to execute commands remotely on a foreign client, either from another client or from an external application. This would require some programming from our based casting plugin coders (or someone else who is interested), and I know at least one was looking into an external console that could be used outside the game. Would obviously require much more setup for the cameraman, but it would be fairly intuitive once we get it going. Probably a command with a prefix like rcon, but executes the command on both the local client and the foreign client. That way we could use the casting commands set up in the casting plugins already to select players. Unsure if the spec_next spec_prev commands will be ok to use in this setup.
Mainly I'm just looking for general advice on how this might work. I'm unsure about the benefit that other communities might have with this, but I believe that decoupling the producer from the cameraman may provide some pretty good benefits for large casts such as finals and should help increase quality.
I've asked about the STV Cameraman myself a handful of times, but I don't think anybody followed up on it. It might be plausible.
The second idea seems interesting, but I'm not sure of the execution. Are you talking about the Streaming Computer being controlled remotely?
I've asked about the STV Cameraman myself a handful of times, but I don't think anybody followed up on it. It might be plausible.
The second idea seems interesting, but I'm not sure of the execution. Are you talking about the Streaming Computer being controlled remotely?
I have considered something like the "client RCON" before, but given that it's fairly complex to implement, I've held off since I didn't know whether it would be any practical use.
Of course, if there is something that could be done with it, I can look more seriously into a possible implentation.
I have considered something like the "client RCON" before, but given that it's fairly complex to implement, I've held off since I didn't know whether it would be any practical use.
Of course, if there is something that could be done with it, I can look more seriously into a possible implentation.
LKincheloeI've asked about the STV Cameraman myself a handful of times, but I don't think anybody followed up on it. It might be plausible.
I looked at the documentation on the source developer community. It appears that it's only for an in server client. I'm not sure if this can be solved with a server plugin for the STV relay, but that seems pretty complex as I don't think that client position is transmitted back to the relay at all.
LKincheloeThe second idea seems interesting, but I'm not sure of the execution. Are you talking about the Streaming Computer being controlled remotely?
Yes, essentially. Basically remote commands being inserted over a network rather than by someone sitting at the computer.
thesupremecommanderI have considered something like the "client RCON" before, but given that it's fairly complex to implement, I've held off since I didn't know whether it would be any practical use.
Of course, if there is something that could be done with it, I can look more seriously into a possible implentation.
<3
The more I think about it the more the remote RCON would be useful.
[quote=LKincheloe]I've asked about the STV Cameraman myself a handful of times, but I don't think anybody followed up on it. It might be plausible.[/quote]
I looked at the documentation on the source developer community. It appears that it's only for an in server client. I'm not sure if this can be solved with a server plugin for the STV relay, but that seems pretty complex as I don't think that client position is transmitted back to the relay at all.
[quote=LKincheloe]
The second idea seems interesting, but I'm not sure of the execution. Are you talking about the Streaming Computer being controlled remotely?[/quote]
Yes, essentially. Basically remote commands being inserted over a network rather than by someone sitting at the computer.
[quote=thesupremecommander]I have considered something like the "client RCON" before, but given that it's fairly complex to implement, I've held off since I didn't know whether it would be any practical use.
Of course, if there is something that could be done with it, I can look more seriously into a possible implentation.[/quote]
<3
The more I think about it the more the remote RCON would be useful.
The Second idea is the right choice.
The First idea affects both casters and spectators in the STV.
The Second idea is the right choice.
The First idea affects both casters and spectators in the STV.
AndKenneththesupremecommanderI have considered something like the "client RCON" before, but given that it's fairly complex to implement, I've held off since I didn't know whether it would be any practical use.
Of course, if there is something that could be done with it, I can look more seriously into a possible implentation.
<3
The more I think about it the more the remote RCON would be useful.
Well, I don't think that strictly slapping on the RCON protocol would work, because you'd have a load of issues with getting the stuff to work around a firewall, which means you'd either be limited to servers on LAN, opening yourself to denial-of-service attacks, or coding an incredibly complex solution.
I was thinking of an implementation in WebSockets, a la OBS Remote used in TotH 2014, but since that would require designing a client application as well, I'd probably need some help so that I don't go crazy. (Unfortunately, from what I understand, the people who have the necessary experience are currently occupied with other important projects.)
turtsmcgurtshttp://www.hlsw.org/
That's a server application.
[quote=AndKenneth][quote=thesupremecommander]I have considered something like the "client RCON" before, but given that it's fairly complex to implement, I've held off since I didn't know whether it would be any practical use.
Of course, if there is something that could be done with it, I can look more seriously into a possible implentation.[/quote]
<3
The more I think about it the more the remote RCON would be useful.[/quote]
Well, I don't think that strictly slapping on the RCON protocol would work, because you'd have a load of issues with getting the stuff to work around a firewall, which means you'd either be limited to servers on LAN, opening yourself to denial-of-service attacks, or coding an incredibly complex solution.
I was thinking of an implementation in WebSockets, a la OBS Remote used in TotH 2014, but since that would require designing a client application as well, I'd probably need some help so that I don't go crazy. (Unfortunately, from what I understand, the people who have the necessary experience are currently occupied with other important projects.)
[quote=turtsmcgurts]http://www.hlsw.org/[/quote]
That's a server application.
thesupremecommanderbut since that would require designing a client application as well, I'd probably need some help so that I don't go crazy. (Unfortunately, from what I understand, the people who have the necessary experience are currently occupied with other important projects.)
not websockets but it achieves half of what's requested from the OP out of the box. people will need to open a port, though.
http://msdn.microsoft.com/en-us/library/bew39x2a
a friend and I did a tf2 related project with this and I was trying to find it so I could let you see how it works because with 30 minutes it should work perfectly for OP's purpose (it's that similar), but I don't think I have it anymore due to a formatting. when my friend comes online i'll ask him.
[quote=thesupremecommander]but since that would require designing a client application as well, I'd probably need some help so that I don't go crazy. (Unfortunately, from what I understand, the people who have the necessary experience are currently occupied with other important projects.)[/quote]
not websockets but it achieves half of what's requested from the OP out of the box. people will need to open a port, though.
http://msdn.microsoft.com/en-us/library/bew39x2a
a friend and I did a tf2 related project with this and I was trying to find it so I could let you see how it works because with 30 minutes it should work perfectly for OP's purpose (it's that similar), but I don't think I have it anymore due to a formatting. when my friend comes online i'll ask him.
Seems like that would be unnecessarily complicating a lot of things by requiring the .NET framework to be integrated (I've never even heard of C++ and the .NET framework being a thing).
That's why I'm leaning towards WebSockets, because there are libraries out there for C++ that work nicely.
Seems like that would be unnecessarily complicating a lot of things by requiring the .NET framework to be integrated (I've never even heard of C++ and the .NET framework being a thing).
That's why I'm leaning towards WebSockets, because there are libraries out there for C++ that work nicely.
AndKennethSecond Idea: Client RCON
Is the idea behind this to be able to change in-game/camera settings without bringing up a console? I.E. on casts when the caster needs to make some quick change to FOV you often see them bring up the console in the middle of a game. Maybe there are other uses for this feature but this was the most obvious one that came to my mind.
I did however just intuitively realize (and maybe the pro-casters out there already do this), that you could effectively do this by binding a key to exec a particular CFG, and then edit that CFG outside of the game to perform whatever commands you want to take effect within the game.
Say you need to change status spec outlines, you write in commands.cfg a few commands and then you hit your bind to run commands.cfg after saving the file outside of TF2.
[quote=AndKenneth][b]Second Idea: Client RCON[/b][/quote]
Is the idea behind this to be able to change in-game/camera settings without bringing up a console? I.E. on casts when the caster needs to make some quick change to FOV you often see them bring up the console in the middle of a game. Maybe there are other uses for this feature but this was the most obvious one that came to my mind.
I did however just intuitively realize (and maybe the pro-casters out there already do this), that you could effectively do this by binding a key to exec a particular CFG, and then edit that CFG outside of the game to perform whatever commands you want to take effect within the game.
Say you need to change status spec outlines, you write in commands.cfg a few commands and then you hit your bind to run commands.cfg after saving the file outside of TF2.
I believe that the original idea was to have someone able to control the camera without physically being at the cameraman's computer, so that the camera and the casters would be better synced (i.e. the camera is following the caster's control and thus viewers see what he/she is seeing).
Of course, what you've said is accurate, but having an external console would probably be more intuitive and easy to use than simply editing a config file.
I believe that the original idea was to have someone able to control the camera without physically being at the cameraman's computer, so that the camera and the casters would be better synced (i.e. the camera is following the caster's control and thus viewers see what he/she is seeing).
Of course, what you've said is accurate, but having an external console would probably be more intuitive and easy to use than simply editing a config file.