Media Director with video capture

[jamo]

Hi Everyone

Some advice please- I believe the recommendation is to put the video capture card into the core. My planned layout at present (I'm planning the system but have already done most of the network wiring) has the core sitting in the closet with the Gig switch and ADSL modem but a long way from the satellite decoder.

My plan was to have a media director in the TV room with the capture card, then the output from the satellite decoder would be fed to the MD capture card and presumably magically through to the core for redistribution / recording etc.

Firstly, is this possible or does the capture card have to be on the core?

And, if so, what are the issues going to be? The most obvious to me seem to be that if you're capturing video directly to the core you don't use bandwidth on the network line between core and switch... the capture input arrives via the PCI bus instead. So any time video is captured it's narrowing the bottleneck to the core. Are there other factors?

I'm trying to think why I don't want the core in the TV room..... apart from noise and space.... when I remember the reason, I'll post back.

[toppot]

Hi Everyone

Some advice please- I believe the recommendation is to put the video capture card into the core. My planned layout at present (I'm planning the system but have already done most of the network wiring) has the core sitting in the closet with the Gig switch and ADSL modem but a long way from the satellite decoder.

My plan was to have a media director in the TV room with the capture card, then the output from the satellite decoder would be fed to the MD capture card and presumably magically through to the core for redistribution / recording etc.

Firstly, is this possible or does the capture card have to be on the core?

And, if so, what are the issues going to be? The most obvious to me seem to be that if you're capturing video directly to the core you don't use bandwidth on the network line between core and switch... the capture input arrives via the PCI bus instead. So any time video is captured it's narrowing the bottleneck to the core. Are there other factors?

I'm trying to think why I don't want the core in the TV room..... apart from noise and space.... when I remember the reason, I'll post back.

You should not worry too much about the bandwidth - even a digital HD ts stream will probably not exceed 10 Mbits, you have 1000!!
Most obvious reason to put capture card in the core is that the core is supposed (by concept) to run 24/7, a MD could be turned off, thus disabling other MDs from utilizing services provided by this MD..

There is nothing wrong with capturing on a MD, and then providing it to the rest of the network (if you use MythTV - with VDR it is not so obvious), but please be aware that you can "capture" by 2 fundamentally different concepts. One being a stand alone sat receiver and then capturing via a framegrabber card, the other being direct digital tuner in the MD (or core). The advantage of using a discrete sat box is that descrambling will work just by inserting your subscription card - no fuss. Disadvantage is that you need to control the sat box, probably via I/R (some could be via LAN), and that you only have one tuner (actually one MUX) available. This means that you can only record/watch/"distribute in the home" one live tv channel a the time. Even with 2 tuners in the sat box.

If you go for a digital tuner card you can simultaneously record all channels on a transponder (from 1 to 10), and with 2 tuners any combination possible... And if you put those in the core this would be a service that will run very transparent, which with MythTV scheduling becomes very powerful. With i.e. 2 cards with each 2 tuners, you could watch/record 20+ channels at the same time, provided they are on the 4 transponders you would tune to. There is no "encoding" to be done, since all the system does in reality is to transport raw data, and this with bandwidths way below what most systems can handle very easily!!

Main disadvantage: If you have a paid subscription you would need to have MythTV to use a so called softcam (decoder), and another program (or server) must act as a card reader. In concept it is easy, elegant and well supported. In reality it proves a hassle for many. It probably goes beyond the scope of this thread, but please let me know if you need to understand the concept, and a path how to implement this.

My first advise to you would be to read and understand how MythTV is constructed with one "Master-Backend" (runs on the Core), a number of "backends" (runs on each MD or Core that has tuner/framegrabber cards) and one "Frontend" per MD. This concept is actually easy, elegant and well supported :-)

Good luck with whatever choice you make - and be sure that support is near. You a not likely to make everything work in the first go, but it actually is very possible to get reliable systems up running - even for us "normal humans" 

-Tony

[bugui]

Hi Tony,
I'm very interested in the way that mythtv could record multiple channels of a paid subscription (DirecTV in my case), and I see that you know a lot on this.

Could you help to me to understand and drop some links to read?

Thanks in advance
Bugui

[jamo]

Tony

Thanks for the detailed and informative response. Definitely some food for thought there.

The reason I was concerned about bandwidth was that prior to setting up MCE for myself, I've been using the LTSP (k12 Linux) to serve my FC13 installation to thin-clients (old, pxe-boot diskless laptops) at my various network points. By doing this I've been able to play music at least at various nodes in the house as well as any other normal computer tasks I need to do. It's pretty cool for a start but I've noticed the video is really slow. I assume the reasons are that
a) The clients have 10/100 (maybe even just 10 Mbs) LAN cards
b) I don't have a network switch yet and I'm making do with an old 10/100 hub
c) I suspect the clients are very thin    ... in that I'm not 100% sure how LTSP does it's processing but I presume it is almost a case of the server running the application and only the graphics stuff being rendered by the client... sort of like remote X.... if so, my understanding of the Linux MCE Media Director is that it is a rather "thicker" client in that the media applications will run on the client as well as the graphic server, video and audio decoding etc with just the raw (usually compressed) data being passed from the server down the network.

Whatever the case, your response has made me confident that when I put the Gig switch in and ensure all internal devices have Gig cards... things should be good.

In terms of the two manners in which TV signal can be captured, that is most interesting. Certainly, as you say, the method of capturing the raw satellite signal and then decoding it in software is very appealing and elegant. And, as you point out, there is more potential there.... however, in my case I think I'll have to start with the alternative- capture the video output itself from the satellite decoder. The reasons are-
1) The provider is a pay provider with a "smart" card which would involve the card reader part that you refer to. Not impossible, as you say, but some extra effort and research required.
2) I'm based in South Africa and I don't think there are many here who have gone this route before me so support and assistance from the community regarding the particulars of our local Sat-tv provider are going to be rather scarce... not to mention the fact that I'm sure their programming schedule is not available electronically.
3) The local provider is not that fantastic ito options  so I don't often find there is a situation where I can find more than one channel at a time I want to watch!
4) My current decoder does already have some fairly neat PVR and dual-view functionality built in which means that I'm already serving an alternative stream to my tenant (in a flatlet on the property) and I'm able to schedule and record already via the PVR. If I implented soln 2 that would basically replace this fuctionality but.... I'd have to give my tenant access to my MCE installation. I think that can happen further down the line. Perhaps when my current (old) PVR packs up and I'm forced to upgrade... I could potentially just use MCE instead of a new decoder?? Exciting future ahead.

Many thanks againf or the comments and assistance.

James

[toppot]

Hi James,

I have commented a bit below:

a) The clients have 10/100 (maybe even just 10 Mbs) LAN cards
b) I don't have a network switch yet and I'm making do with an old 10/100 hub

Wow, the only thing worse than a 10/100 LAN is when the bandwidth is shared in a hub... Just like with wireless, which also explains why everybody should shy away from WiFi. You definitely need to upgrade here!

c) I suspect the clients are very thin    ... in that I'm not 100% sure how LTSP does it's processing but I presume it is almost a case of the server running the application and only the graphics stuff being rendered by the client... sort of like remote X.... if so, my understanding of the Linux MCE Media Director is that it is a rather "thicker" client in that the media applications will run on the client as well as the graphic server, video and audio decoding etc with just the raw (usually compressed) data being passed from the server down the network.

Funny term "very" thin 
You are absolutely right that LTSP is utilizing thin clients, and that LMCE is nothing like that, it is just diskless clients. One thing to remember though - thin clients need "fat" network bandwidth - fat clients could do with less (Although diskless clients boot and loads faster on fast networks). I am not sure how LTSP is handling video, but unless it is somehow tailored for this, you need a quite fast network to experience flawless video. Just due to the nature of the technology.

Whatever the case, your response has made me confident that when I put the Gig switch in and ensure all internal devices have Gig cards... things should be good.

Right again, but put importance of the Gigabit backbone structure - and the card in the Core should also be Gigabit. The individual nodes could be 100 Mbit, that is less critical - therefore you should not worry if a potential MD only has 100Mbit (but Nvidia GFX).

In terms of the two manners in which TV signal can be captured, that is most interesting. Certainly, as you say, the method of capturing the raw satellite signal and then decoding it in software is very appealing and elegant. And, as you point out, there is more potential there.... however, in my case I think I'll have to start with the alternative- capture the video output itself from the satellite decoder. The reasons are-
1) The provider is a pay provider with a "smart" card which would involve the card reader part that you refer to. Not impossible, as you say, but some extra effort and research required.

Yes, but probably worth the effort, espicially considering what you (and I) mention below:

2) I'm based in South Africa and I don't think there are many here who have gone this route before me so support and assistance from the community regarding the particulars of our local Sat-tv provider are going to be rather scarce... not to mention the fact that I'm sure their programming schedule is not available electronically.

To my understanding the systems used should be very well supported on the decoding part, meaning you can find support in Europe since the same system is also used by some European providers. I am not going to link (due to policy reasons) to info on how to move forward should you go this way - but I can be reached outside of the public foras...As to my understanding EPG via sat in South Africa (I assume MultiChoice South Africa (DSTV)?) is only sending "Now" and "Next" via EIT - but there should be xml grabbers for you. Consider looking here: http://www.mythtv.org/wiki/South_Africa_MUG

3) The local provider is not that fantastic ito options  so I don't often find there is a situation where I can find more than one channel at a time I want to watch!

Poor you  Does that also include your tenant only desiring the same as you?

4) My current decoder does already have some fairly neat PVR and dual-view functionality built in which means that I'm already serving an alternative stream to my tenant (in a flatlet on the property) and I'm able to schedule and record already via the PVR. If I implented soln 2 that would basically replace this fuctionality but.... I'd have to give my tenant access to my MCE installation. I think that can happen further down the line. Perhaps when my current (old) PVR packs up and I'm forced to upgrade... I could potentially just use MCE instead of a new decoder?? Exciting future ahead.

Then I would warn you a bit. Not entirely sure which decoder you have, but if you are serving an individual selectable stream/channel to your tennant then you probably could grab this to Myth, but I foresee quite some tinkering to get LMCE to control both streams of the receiver. Which make and model is this? And how does your tenant switch channel??

You could end in a situation where you actually feel that performance (functionality) from your LMCE based system could feel inferior to your current setup, and you don't want that  On the other hand, if you keep your current sat box then LMCE would perhaps feel a bit "bolted on", and it should be the other way round, LMCE should become the core to which functionality is added..

Good luck with further investigations

- Tony

[jamo]

Hi Tony

Thanks again for the informative feedback. My current DSTV setup is as follows-

I have the SD dual-view PVR decoder which only does standard definition channels but has built-in PVR and dual-view functionality. The Dual-View means that (as I understand it) the decoder can output two simulataneous channels. It does this by sending output on the RF-OUT on two different frequencies. So you can connect TVs to the TV-OUT and either tune them to frequency #1 (and get whatever channel is selected there) or frequency #2 ( and get whatever channel is selected there). There are actually two coax outputs, labelled TV1 and TV2 respectively but I think they probably do much the same thing... it just means you don't have to have a splitter.

For control of the two streams, you use IR remotes and just flip them to a different (freq?) to control the different streams. On the tenant side, there is an IR "eye' connected inline on the coax cable which somehow allows the decoder to pick up IR signals encoded onto the coax coming back to the system. So you can point either remote at either the decoder itself or the "eye" and, depending which "freq" on the remote is selected, control one or the other stream. Then you can see either stream from either RF-OUT if you tune to the appropriate channel.

Either stream can watch channels or control the PVR so both can watch and record movies as well. The problem comes in, naturally, because you can delete each other's recordings.... grrr.

Now... if I am understanding correctly, you are saying that MythTV embedded in LMCE could effectively replace my entire system? In other words I'd (THEORETICALLY) be able to plug the coax input(s) from the LNBs on my sat dish directly into a tv-tuner card in my core, plug my subscriber DSTV smart-card into some kind of card-reader and then install and set-up software to magically combine the two to send channels of my selection to any media director on the system?

That *must* be taking it a bit far, surely?

[toppot]

Now... if I am understanding correctly, you are saying that MythTV embedded in LMCE could effectively replace my entire system? In other words I'd (THEORETICALLY) be able to plug the coax input(s) from the LNBs on my sat dish directly into a tv-tuner card in my core, plug my subscriber DSTV smart-card into some kind of card-reader and then install and set-up software to magically combine the two to send channels of my selection to any media director on the system?

That *must* be taking it a bit far, surely?

Hi James,

Sorry I missed your post

This is actually not "taking it far" at all - this is done all the time with various DVB inputs (DVB T, C or in your case S for sat). The only part not completely standard (and done all the time with great success) is the decoding part. It is not rocket science, but policy reasons prevent me from guiding you in these matters. Such a solution would also allow you to experience MUCH better tv quality for 2 reasons (granted you have a flat screen TV with digital input HDMI or DVI):

1. You would be enabled to watch HD channels (you don't have many, and this is actually not going to be the biggest improvement!)
2. You are going to experience a digital signal being fed directly (some post-processing is taking place, but nothing that seriously should alter the quality) to a digital panel - no conversion made. In your current setup you are (RF) modulating the digital DVB-S signal to analog, and then demodulating it back in the TV tuner (and probably then an A/D conversation if you have a flatscreen TV). These 2 (3) conversation really F*** up quality.

To experience the effect of this best, find somebody that has a DVB box that can output to a TV either via HDMI (or DVI) and via composite - or even RF) to a TV. And then switch between connections from the box to the TV. You will experience the quality improvements from analog to full digital being greater than the improvements from digital SD to digital HD!!

Let me know if you need more pointers :-)

-Tony