Differnt Streaming/Networking issues, "a mind Game" (3 Viewers)
- Thread starter tom1502
- Start date
Germany
tom1502 said:
Well the point is that it's not currently implemented into MP. My comment was only as an idea to consider since I know that BeyondTV uses WME to stream video to other clients.
The only problem however (which I should have mentioned before and I apologize), is BTV can only stream video via WME if you have a software encoder card.
BTV also has a server/client setup which will let you stream video (from your hardware encoder card) by running a front end on another computer. Ideally this is what a lot of people would like to see I'm sure.
thechad said:
It won't actually be that easy - problem being, what happens when you want to rewind to a spot before you started watching on the client? Its not that hard (relatively) to stream the video, its more that it'll be harder to implement the timeshifting features. If a directshow filter was used to stream tv, it will mean that each client will have an individual graph on the server, even if it is viewing the same channel, as well as the graph used by the server to timeshift the channel. When the show needs to be rewinded, a command will need to be sent to the server from the client to do so., ditto with all other video functions, as well as channel changes.
For minimal change, i.e. using the existing infrastructure in MP, a better solution would involve the temporary buffer file being played by clients, with the clients in control of rewinding it, fast-forwarding it etc (essentially, like multiple computers playing the same video file on a server). Commands would need to be sent to the server when a channel change is required, and the server will then decide on who has the right to do so before switching. Of course, this solution won't be as clean and easy to setup as a uPNP or directshow filter solution.
tom1502 said:
Seriously, I don't think it's possible with the current 100MBPS network infrastructure to run the entire MP interface over the network. Have you used MP via VNC? That's usable, but definitely not for daily use. Somehow, I doubt VLC will be any better at that. It will be better if you eliminate all the fancy graphics/animation features like MS does with the normal MCE extenders (i.e. not the xbox 360 one), but still... The keyboard inputs and remote inputs bit is very easy...in fact you can already send these inputs over the network from any computer using the MP-webinterface, among other things.
I think if there's any feasible client-server solution out there, its got to involve a client app, and a server app. I think the main goal that people have is to be able to use it in another room; not using it on a very-slow/dumb client.
Sam
p.s. phew...that must be one of my longest posts :-D
- Thread starter
- #14
Hi,
the Timeshifting issue of the clients is definitely a problem. I think one solution could be, to let each client buffer his recieved stream in a file, and just allow him to timeshift within this file...
I still think, and agree there with you, that a client-app and a server-app is necessary!
All other solutions will just be tinkered solutions...
So can anyone explain me / post me informative links about these DirectShow stuff?
What is the Problem with a graph for each client?
Wont it make most sense to just stream the file to the Network, no matter how many clients recieve this? So as soon as the first client connects to MP, the streaming starts( maybe just start streaming the timeshifting file - so only if timeshift is active, streaming is possible). Therby, we could implement the ability to use timeshifting features(Pause, FWD, REW, etc.) on the server, but with effect for every client who uses this "Timeshifting file"...
Is MP already able, if multiple TV-Cards are available to timeshift multiple channels? Because then you could give the client the option to choose, which card he wants to use!
What do you think?
Cheers
Tom
the Timeshifting issue of the clients is definitely a problem. I think one solution could be, to let each client buffer his recieved stream in a file, and just allow him to timeshift within this file...
I still think, and agree there with you, that a client-app and a server-app is necessary!
All other solutions will just be tinkered solutions...
So can anyone explain me / post me informative links about these DirectShow stuff?
What is the Problem with a graph for each client?
Wont it make most sense to just stream the file to the Network, no matter how many clients recieve this? So as soon as the first client connects to MP, the streaming starts( maybe just start streaming the timeshifting file - so only if timeshift is active, streaming is possible). Therby, we could implement the ability to use timeshifting features(Pause, FWD, REW, etc.) on the server, but with effect for every client who uses this "Timeshifting file"...
Is MP already able, if multiple TV-Cards are available to timeshift multiple channels? Because then you could give the client the option to choose, which card he wants to use!
What do you think?
Cheers
Tom
tom1502 said:
You're not understanding me here. That's ok, but the problem arises when let say, the server permanently timeshifts. Now, when a client starts up and requests the TV stream, there's no problem there. But what if they want to view footage that was timeshifted by the server, but before the client was started?
That's a big, big topic. Try going to google, and doing a search for directshow site:msdn.microsoft.com .tom1502 said:
tom1502 said:
Nothing; just requires a lot of processing power.
But doesn't that mean every client has to be viewing the same thing exactly, i.e. I can't rewind one client, but watch it live on another? The above problem still isn't solved either...tom1502 said:
Of course, each client can have its own TV card on the server, but I think that's just wasting resources and impractical.
Sam
- Thread starter
- #16
Well this could be solved with a worker thread pool, so for each incoming client conexion, a own thread will be created starting to stream, but then no multicast(is this the correct word for it) is possible, so 1 client, 1 stream...
But is there any scenario where you, in your home have multiple clients who require different positions in the timeshifting buffers?!
new IDEA:
why not making such a thread pool, and let the client decide if he wants to use this stream or wants to open another one?!
[/quote]
tom1502 said:
Yes, that is definitely a case in my house, particularly when watching sporting events. Let's say two people were watching it on different computers, and one person gets a phone call - he'd want to pause his so he can come back later and pick up where he left off.
I think the new idea is, well...complicated for a user. I think we should look to what other systems, such as mythTV and MCE and see how they're doing it. But that's just my opinion...let's see what others think.
Sam
- Thread starter
- #18
Well i dont like watching other concepts... well getting ideas yes, but build into own systems... NO!
So what about this thread pool stuff? Then it depends on Network-bandwidth how many conexions should be accepted!
So what about this thread pool stuff? Then it depends on Network-bandwidth how many conexions should be accepted!
tom1502 said:
Um... I don't know how you interpreted it, but all I meant was looking at the other systems and see how they implemented this, then maybe take that idea and build on it if needed.
Thread-pooling - good idea, build I think it needs to a bit more transparent. I don't think the user should have to deal with selecting a certain stream etc. Besides, sometimes its better if one person doesn't know what the other users are watching. Maybe, let's say user 1 is watching channel 1 live on a client. Now, user 2 comes along on another screen and decides to watch channel 1 live too. Suddenly, the phone rings and user 2 needs to pause the stream. The client should automatically start another thread on the server and connect itself to it, then pause it.
So now, user 1 and user 2 are watching individual threads, but the whole process is transparent.
Sam