These are chat archives for P2PSP/MediaSources-server
IMHO, the media server should run on the same machine where the splitters (or splitters manager) is running, so it can create/check/whatever directly
Great, this will make a lot of things easier eg. authenticity of data, securing communication, process maintenance etc. We don't even need the first two right now!
I had imagined the media server as "router" point: if I wanted to create a new channel, I use a call of the REST API, so that by means of a HTTP POST I send the video, indicating the channel name, video parameters, etc.
the media server would create the splitter for that new channel and would return information about the connection; this information could be queried later (e.g., if someone get the list of channels, etc.)
Yes, this is exactly what I had in my mind too! One more thing though, how do you plan to send HTTP POST request? I mean client could be anything ranging from curl, some separate client to p2psp, p2psp qt based GUI, to a simple HTML form to create that channel, Media server won't care and definitely handle it well, but do you have something in mind from where HTTP POST request comes for while I'll be working on it?
the media server could also "link" the video stream to the splitter, this would be great
Could you explain what you mean by linking the video stream to splitter? Since a sample splitter command is like this -
./splitter --source_addr 127.0.0.1 --source_port 8080 --splitter_port 8001 --channel BBB.ogv --header_size 30000
Do you mean by linking it is automatically passing source address and port to splitter process? Or do you mean MediaServer will consume the Video Stream itself first, eg buffering up to some length and then give it to the splitter process, which IMO is unnecessary level of indirection :/. Or is it entirely other thing that I'm missing out?
another easier approach would be that, in order to create a new channel, the API call would be as "hey media server, I'm a video source, and I want to create a channel; give me a splitter and a connection info"
the problem with this approach is that the media server can not control when the video source stops/break
Well there are ways to detect if a video broke down/source is unresponsive and not sending data, via 1. polling - which means simply checking video source for streaming data, if it is sending anything at all! Eg. the video source might be transmitting udp/tcp/ or through some different protocol and we can keep checking in a time interval, very small amount of data and then discarding packets since we don't need them. After a certain timeout, if the source still isn't sending anything, we can assume it's broken down! 2. Watching for splitter process to write something on stdin/stderr pipes, we can offload this task to splitter processes we've launched for that particular video source, and when they write something preferably on stderr, our MediaServer could easily catch it and detect that the video has broke down.. This seems more apt to me since stderr is also attached to terminal so in case no MediaServer is present, it still displays the error code, but both are viable ways to detect it.