VLC front and back. VLC has a VLS server and a SAP channel lineup. the SAP channel lineup uses XML. So including it would be a breeze.
Differnt Streaming/Networking issues, "a mind Game" (1 Viewer)
- Thread starter tom1502
- Start date
Germany
Since there has not been any video streaming development within MP and it is more of a "mind game" curently I thought that maybe we should look to see what the future could hold wiht other major companies pushing digital media. The reason I say this is due to an online article ("Why the media centre PC is destined for the home office") I read this morning on CNET. One sentence popped out to me - it was "Shortly, Intel will release a range of "digital media adapters", which connect to your existing home theatre components (e.g. your TV, stereo system, etc) and can stream content wirelessly from any Viiv-certified PC."
That caused me to search on Intel's web site for the key words "digital media adapters" and I found the following web page: "Adding Your TV and Stereo to Your Wireless Network" under their Digital Home.
Should we look at what Intel is doing and how it will affect MediaPortal?
Mike
That caused me to search on Intel's web site for the key words "digital media adapters" and I found the following web page: "Adding Your TV and Stereo to Your Wireless Network" under their Digital Home.
Should we look at what Intel is doing and how it will affect MediaPortal?
Mike
- Thread starter
- #44
quick n dirty:
absolutely interesting point, but afaik intel is using MCE, which does not support DVB-s,c in an acceptable way... but lets see what comes!
I think VIIV will be interesting, especialle the core duo centrinos as MediaCenter CPU!
Cheers Thomas
absolutely interesting point, but afaik intel is using MCE, which does not support DVB-s,c in an acceptable way... but lets see what comes!
I think VIIV will be interesting, especialle the core duo centrinos as MediaCenter CPU!
Cheers Thomas
I'm sorry to butt in, but I have to pick up on this point. The only extra hardware requirement for timeshifting client side would be maybe 2-10Gb more hard drive space (depending on how long you want the timeshift buffer to be).thechad said:
I've noticed a few comments in this thread that point towards using a more powerful server and a less powerful client with what seem to me to be little understanding of what actually happens in each part of the process.
The most cpu intensive part of the process by far is actually decoding and displaying the video, especially for HD. For HD without DxVA you'll need at the very least a 2Ghz machine. With DxVA or for SD you can get away with less cpu power, but you still need a decent video card that supports DirectX 9.
Capturing from the Tuner/Capture Device to Timeshift Buffer uses almost no cpu power. The most intensive part of the capture process would be disk access. It requires the hard disk to write at up to the same data rate as full transport stream. That's about 2.5 Mb/s from memory, which is far less than the limit of hard drives. You can easily save several transport streams to disk simultaneously.
Assuming that the sever is just saving the timeshifting buffers not decoding or display the video then you would get away with using quite a low end system. The only requirement might be to make sure the hard drives are fast enough if you want to capture lots of streams at once.
As pointed out already, the most limiting factor is going to be network bandwidth so there needs to be an effort to reduce the number of streams going across the network at once. I think bear's idea offers the best way to reduce network load. The problem raised is how to timeshift to a time before the client starts watching. I would suggest that the easiest way to fix this is to have the client always running in the background saving it's own timeshift buffer. Then when the user starts watching they already have a timeshift buffer built up.
Nate
Hate to throw another spanner into the works, but let's say you have 2 TV cards, does that mean the client will timeshift both streams in the background?
That becomes a fair bit of bandwidth when you have a few clients running...
I guess there has to be a line drawn somewhere... Does MCE or mythtv allow this; if so, how does it handle it?
BTW, are you the same 'nate' as in the dvbowners forum?
Sam
That becomes a fair bit of bandwidth when you have a few clients running...
I guess there has to be a line drawn somewhere... Does MCE or mythtv allow this; if so, how does it handle it?
BTW, are you the same 'nate' as in the dvbowners forum?
Sam
It's been a while since I studied networking, but I think multicasting results in more or less the same network utilisation regardless of the number of clients.samuel337 said:
The client should be able to timeshift as many streams as the network can carry.
If user 1 starts watching channel 1 on client 1 then client 2 can start timeshifting channel 1.
Then if user 2 then starts watching channel 2 on client 2 then client 1 can start timeshifting channel 2 as well.
Basically maxiumum the number of streams multicast on the network at any one time will be up to the number of tuners in the server.
Someone mentioned earlier in the thread that mythtv shares timeshiting files using NFS. I have no idea how MCE is handling streaming.
yes. I drop in here every now and then to see what's going on.
Would be nice to see your input on a more than every now and then basis, be a champ nate and start working with Frodo and the guys!!!
Ok, I'm slightly lost.
It seems to me that the best way to split MP in to a client/server is though the use of being able to add a NetworkTvCard as a 'fake' tv card in the MP setup, and have it act as a stub to a real card somewhere on the network. Surely there is a common interface in MP for all TV cards?
Then you could use webservices (of whatever flavour) to make accessing the card over the network completely transparent. The client would send and recieve data to the NetworkTvCard stub which would then pass it over the network to a recieving interface, that would then interact with the actual hardware card, (which would be unaware the client was remote).
From a setup perspective, the client is simply a full MP install using the NetworkTvCard as its tuner, and the server would be a stripped down version of the bit of MP core that deals with the hardware, (before the common interface that I'm just guessing exists). Then doing all the stuff like timeshifting and so on would be performed on the client, as the NetworkTvCard would just act like a regular card waiting to be told what to do.
Of course the main issue is bandwidth. But, the raw signal coming from a DVB-T card is probably 6MB/s right? Of course it'll be a lot higher for HDTV, but there is no reason why a HDTV signal couldn't be transcoded on the server first to say MPEG4, (although this would be potentially difficult getting the existing MP framework to deal with this, unless it was transcoded back in to MPEG2 on the NetworkTvCard stub - messy but easy). Besides, if you wanna stream HDTV, you gotta realise you'll need a network to shift that much data, there's no point sugar coating it.
For multiple users, I think with some TV cards you can get them to act like multiple cards anyway right? I'm not just talking the dual tuner variety, but there are also cards that can do picture on/in picture setups, even when the channels are in different transport streams. My Compro T300 seems to be able to do this with no loss of quality, (although I could well be proved wrong on this). The point is, each card (or each virtual card in the potential case of my Compro) could have its own webservice to be used by whoever wants it. Of course, the problem then is in multi-user scenarios finding which card(s) are free, (which I think was previously descussed by the use of a broker?).
Anyway, thats my 2p. ;0) Feel free to harshly knock whatever I've written.
It seems to me that the best way to split MP in to a client/server is though the use of being able to add a NetworkTvCard as a 'fake' tv card in the MP setup, and have it act as a stub to a real card somewhere on the network. Surely there is a common interface in MP for all TV cards?
Then you could use webservices (of whatever flavour) to make accessing the card over the network completely transparent. The client would send and recieve data to the NetworkTvCard stub which would then pass it over the network to a recieving interface, that would then interact with the actual hardware card, (which would be unaware the client was remote).
From a setup perspective, the client is simply a full MP install using the NetworkTvCard as its tuner, and the server would be a stripped down version of the bit of MP core that deals with the hardware, (before the common interface that I'm just guessing exists). Then doing all the stuff like timeshifting and so on would be performed on the client, as the NetworkTvCard would just act like a regular card waiting to be told what to do.
Of course the main issue is bandwidth. But, the raw signal coming from a DVB-T card is probably 6MB/s right? Of course it'll be a lot higher for HDTV, but there is no reason why a HDTV signal couldn't be transcoded on the server first to say MPEG4, (although this would be potentially difficult getting the existing MP framework to deal with this, unless it was transcoded back in to MPEG2 on the NetworkTvCard stub - messy but easy). Besides, if you wanna stream HDTV, you gotta realise you'll need a network to shift that much data, there's no point sugar coating it.
For multiple users, I think with some TV cards you can get them to act like multiple cards anyway right? I'm not just talking the dual tuner variety, but there are also cards that can do picture on/in picture setups, even when the channels are in different transport streams. My Compro T300 seems to be able to do this with no loss of quality, (although I could well be proved wrong on this). The point is, each card (or each virtual card in the potential case of my Compro) could have its own webservice to be used by whoever wants it. Of course, the problem then is in multi-user scenarios finding which card(s) are free, (which I think was previously descussed by the use of a broker?).
Anyway, thats my 2p. ;0) Feel free to harshly knock whatever I've written.