initial support for Hauppuage HD-PVR (5 Viewers)

[Blue Energy]

Ah - yes, I see. You have a relatively very fast processor and very very fast disk. I checked out s couple of the other systems links as well. As it turns out, though, it isn't helpful to know only the manufacturer of the disk for this. We need to know the model as well. I plan to attempt to look-up the relative specs of each drive used for recording HD and see whether a pattern develops between the go and no-gos.

As for processors, it would be helpful if you listed the entire name of your processor. For instance, Wile E. lists using an "Intel Core 2 Quad 2.66". But - there are several of those and they don't all have the same capability. Still - of the three systems I currently know at least something about... presuming that Wile E. is using the least powerful processor that meets the above description, there is possibly the beginning of an interesting trend:



USER EXPERIENCE PROCESSOR RELATIVE PROCESSOR POWER
------------- ------------------ -------------------------------------------- ------------------------------------
mdg78 Positive Intel Core2 Quad Q9400 @ 2.66GHz 3,809
Wile E. Positive Intel Core2 Quad Q8400 @ 2.66GHz 3,665
sjeffrey Not Positive Intel Core2 Duo E8400 @ 3.00GHz 2,244


Obviously, it's too small a sample size to know much from this. But, with more data - we could fill in the blanks. By the way, I'm using this site for the relative processor power comparisons:

PassMark Intel vs AMD CPU Benchmarks - High End

Oh, yeah. HTML and spaces. My chart looks pretty bad. Hopefully you can read it anyway. I wonder if there's some way to do charts in this (very nice) forum system?

 

[mdg78]

First to BlueEnergy-

Yes, I have good success (what I term good at least) with HD-PVR and MP. Yes, my specs are correct in my profile. I have a intel Q9400 processor. My timeshifting directory is on a 2TB drive, Hitatchi deskstar that is 7200rpm. My system has 8GB ram. Also, I don't know how much the HD-PVR uses the GPU, but I use an onboard nVidia 9400 gpu.

Ixian- Whereas I do get stuttering occasionally that requires a pause, that occurs very rarely, so is not a big deal to us to hit the pause buttion. Our HTPC is set up downstairs in a separate room and tied to a projector, so switiching to the cable box isn't an option for us either due mainly to inputs on the pj. My wife is aware of needing to occasionally press the pause, and she is really the only other person who uses it. For us, it is extremely stable and we're happy with it. We don't have multiple clients set up around the house, but have been considering adding one if we get another screen. We *might* soon, though we may have to move soon, and may change the layout completely. I have set up another computer about 1-2 mo ago to work as a client just to see how it worked and for the 1/2hr-1hr I had it up and running it was really smooth, but I wouldn't count that as a good test. I'm also considering building a dedicated server and using multiple clients, but time and money are issues obviously. (Hope this makes sense to someone other than myself)

 

[WileECoyote]

Removed....

 

[Blue Energy]

Merry Christmas everyone!

WileE - I downloaded your video and watched it last night. It took over 30 minutes to get it, I think. I had never seen MePo in action before, so I found it very interesting. As you have said, it seems to work pretty nearly flawlessly. I would like it I think.

First to BlueEnergy-

Yes, I have good success (what I term good at least) with HD-PVR and MP. Yes, my specs are correct in my profile. I have a intel Q9400 processor. My timeshifting directory is on a 2TB drive, Hitatchi deskstar that is 7200rpm. My system has 8GB ram. Also, I don't know how much the HD-PVR uses the GPU, but I use an onboard nVidia 9400 gpu.

I looked up your graphics card and it does claim to be able to be able to handle an H.264 encoded signal. I don't know for sure, but I would be very surprised if the HD PVR used your graphics card at all, since it is only involved in the initial capture of the video (and it's conversion to H.264). But, if your video card couldn't handle that format then it would be up to MePo and your processor to do it. I don't know enough about MePo to know whether it even does that conversion - but, I suspect that it would be very processor intensive if it did.

The great thing about H.264 is that it takes less room to store. The potentially bad thing about it is that it has to be uncompressed, like a zip file but in a continuous stream, very shortly before viewing - and with a deadline for completion. If whatever it is that accomplishes this can't meet the deadline - there would be stuttering.

I presume that there is a buffer to store some uncompressed video data under any circumstance. If Windows wants the processor or the disk for a little while for whatever reason - it just takes it. If your buffer isn't big enough to last until Windows is done - there would be stuttering.

Same with disk. Time shifting might cause a lot of uncompressed data to have to be buffered. It takes more disk throughput to move multiple streams of data around in realtime. If the disk can't handle the additional load - there would be stuttering.

If, for whatever reason MePo does NOT make use of the graphics card to accomplish the decompression, I would think that H.264 increases the hardware requirement just because of the need to decompress in addition to formatting the screen etc. As a result, maybe the usual minimum hardware requirements are not sufficient for a system using H.264. This is my working theory as to why some people using HD PVR have success and others do not.

If any of this is correct then we'd have to figure out what the new minimum threshold was for each component. My idea is that we can do that just by comparing systems that work great with systems that work pretty well with systems that don't work well at all. If we can come up with numbers to represent each of the components - like that handy chart of processors and their relative processing power - with enough data it we could almost graph them against success: above this number, success; below this one, failure; in between - partial success.

 

[mm1352000]

Blue Energy: You've got things mostly right there, but here is a fuller explanation...

Generally speaking, to display an analog TV channel in MediaPortal the incoming TV signals have to be digitally encoded. Many analog TV cards have hardware encoders to do this. This includes the HDPVR. The HDPVR is somewhat unique in that it encodes into h.264 rather than MPEG 2. Encoding into MPEG 2 in real time can be done in software by most relatively modern high end computers (this is what is done for tuners that don't have hardware encoders). The results aren't necessarily as good as those that would be produced by a hardware encoder, but the point is that it can be done. Encoding to h.264 is a different story. Most high end computers just aren't fast enough (yet ) to use software encoders to encode h.264 with decent quality in real time. If there is a problem at this stage then you'll possibly see video corruption, stuttering, dropped frames, video-audio sync drift etc.

Anyhow, once the TV signal has been digitally encoded, TV Server is responsible for writing the resulting stream to your HDD for timeshifting and/or recording. That requires almost no processing power, but of course the HDD must be fast enough to write the data that is being thrown at it, along with the data coming from any other applications that are running at the same time. Many people use dedicated HDDs (or even RAM drives) for timeshifting/recording to ensure that the HDD has the best chance possible of keeping up with the stream. Most 7200rpm drives shouldn't have any trouble. To give you an indication, I was recording 3 1080i streams just last night without a hitch D). If the HDD is highly fragmented (free space is not continuous => the drive has to move the write head more) or the spindle speed is slower (eg. 5400rpm "green" drives) then there is more chance that the HDD won't keep up. If there is a problem here then you'll also see corruption, stuttering, dropped frames, jitter etc.

MediaPortal is responsible for taking the contents of the timeshift file or recording and "playing" it. This requires the digital stream (video + audio) to be decoded, and that is where codecs come in. Codecs are small pieces of software that know how to decode one or more specific media formats (for example MPEG 2 video, AAC, h.264, MP3). MediaPortal builds what is called a graph to connect the timeshift file to the video and audio renders (whose job it is to display the video on screen and pass the audio to the soundcard) with the codecs that you choose to use in MediaPortal configuration. Many people seem to have codec trouble. Often it is because they choose the wrong codecs for the job - codecs that can't work together, can't be used by MediaPortal (not compatible for whatever reason), don't support the required media types, or don't support particular elements of the digital stream that you're trying to watch (this is about how the encoders did things when they created the stream). All of these problems are generally grouped together and called "codec compatibility issues". If you have a problem here then you'll see dropped frames, stuttering, no video, no audio, video-audio sync problems etc.

The intensive part of the decoding process is handled by the codecs. They usually use the CPU's processing power, however some newer video codecs (eg. Cyberlink) are able to use the video card. This is what is known as hardware acceleration. It only works if both the video codec and the video card support it. If it works, it can greatly reduce the load on your CPU, freeing it up to do other things. Of course the load doesn't just go away; it gets shifted onto the GPU, which has dedicated hardware that does the job more efficiently. There *usually* isn't a problem with hardware acceleration - it either works or it doesn't...

The rest of the decoding is just passing the stream around, and that has to happen in a timely fashion. The stream has to go from the HDD into memory for decoding, and then from memory into the video/audio buffer for display/playback. The biggest potential failure here is the HDD - it has to read the stream at real-time speed. This is usually much easier than writing in real-time, however the same caveats as for creating the timeshift/recording file apply (other applications using the HDD, 5400rpm spindle speed etc.).

Hope that aids understanding

 

[Blue Energy]

Thank-you for that explanation! I wonder why the codec is required at all for decompression when the graphics card supports the format?

So, what I gleen from your excellent primer is that the typical bottlenecks here are disk speed and mismatched codec/gcard. These days, needing a faster hard drive is easy to fix. Mismatched codec and graphics card though... how do you assure that the card you're using is capable of working with the codec besides assuring that the graphics card says that it supports h.246? Of the three respondants so far, all three use graphics cards which claim to support h.246 - but ones system doesn't work very well. Would you conclude that his difficulty is elsewhere or is claiming h.246 in gcard specs not necessarily specific enough?

As for Hard Drives - I'm planning to check the throughput claims by the manufacturer if I get responses regarding the specific drives. If that doesn't pan out as a difference maker - there is a big difference in processing power between the one system that doesn't work and the two that do. If all other things are relatively equal, presuming no user error, it must be the processor.

 

[mm1352000]

Thank-you for that explanation! I wonder why the codec is required at all for decompression when the graphics card supports the format?

It is not just decompression - it is "decoding". Hence the word [en]codec[ode]; a sort of a collision between encode and decode. Yes there is decompression involved, but there are a lot of other "smarts" used to avoid storing redundant bits. Clever tricks that exploit what we know about how eyes and ears work and what video and audio streams contain that can only really work with video or audio. Don't forget MPEG 2 and h.264 are "lossy" as well (information is lost when you use those formats to store data), as opposed to compression which tends to be lossless.
Why do we need codecs? Well, something has to tell the graphics card/DxVA hardware what to decode, and that is the codecs' job. It interacts with the hardware acceleration interface exposed by the video card driver. The video card doesn't "support formats" per se. Rather, it provides hardware that can be directed by a driver to decode certain media formats. I'd imagine some dedicated hardware is also used, but it is not as if the video card knows what to do by itself.

So, what I gleen from your excellent primer is that the typical bottlenecks here are disk speed and mismatched codec/gcard.

Yes, the HDD is a significant bottleneck and the cause of many issues, as is the CPU (potentially) if it is used for decoding. Mismatched codec and video card isn't so much of a factor as mismatched encoder and decoder pairs or to a lesser extent mismatched video and audio codec pairs. h.264 is a huge standard. There is wiggle room within the standard to implement things in different ways, as well as optional parts/features that need only be used if (for example) you are trying to squash the video into the absolutely smallest number of bits possible. We'd like to thing that the broadcasters' encoding equipment all adheres to the standard, however the encoders they use do things in slightly different ways. Some codecs might handle streams produced by certain encoders better than others. In the worst cases a codec might not be able to handle the streams at all. The same applies to hardware acceleration. Hardware acceleration issues are less common, but they do exist.

Mismatched codec and graphics card though... how do you assure that the card you're using is capable of working with the codec besides assuring that the graphics card says that it supports h.246?

To be honest, there isn't much you can do other than getting advice from other people who watch the same channels as you and have a similar video card to you. There is also DxVA checker which allows you to check what h.264 "sub formats" a video card can handle, however at the end of the day it is really trial and error.

Of the three respondants so far, all three use graphics cards which claim to support h.246 - but ones system doesn't work very well. Would you conclude that his difficulty is elsewhere or is claiming h.246 in gcard specs not necessarily specific enough?

I wouldn't be looking at the graphics card. I'd look at (in this order):
1. HDD.
2. Codec.
3. Driver.
4. Hardware revision.
5. Source material.

As for Hard Drives - I'm planning to check the throughput claims by the manufacturer if I get responses regarding the specific drives.

It is easy to get bad HDD performance with the new 4kB "advanced format" drives that are starting to become common. You have to format them correctly or performance really goes down the tubes. That should be something you keep in mind...

If that doesn't pan out as a difference maker - there is a big difference in processing power between the one system that doesn't work and the two that do. If all other things are relatively equal, presuming no user error, it must be the processor.

CPU only really matters if you're not using hardware accelerated h.264 decoding.

Don't forget that you all have different cable providers and potentially different hardware revisions and driver versions of the HDPVR. The reason for the first point should be obvious (source format), although perhaps not too relevant given we're talking about analog signals. The same consideration applies to the final two points. Hauppauge might have changed the encoder parameters (=> slight changes in output format => codec compatibility considerations) over time as they fixed issues and learnt how to get the best out of the hardware.

 

[Blue Energy]

Thanks again for a very useful reply.

To be honest, there isn't much you can do other than getting advice from other people who watch the same channels as you and have a similar video card to you. There is also DxVA checker which allows you to check what h.264 "sub formats" a video card can handle, however at the end of the day it is really trial and error.

Wow! What an effective and useful 'standard'!

CPU only really matters if you're not using hardware accelerated h.264 decoding.

Might one be able to use Task Manager to check for excessive CPU use prior to video problems as a check for lack of h.264 acceleration?

Don't forget that you all have different cable providers and potentially different hardware revisions and driver versions of the HDPVR. The reason for the first point should be obvious (source format), although perhaps not too relevant given we're talking about analog signals. The same consideration applies to the final two points. Hauppauge might have changed the encoder parameters (=> slight changes in output format => codec compatibility considerations) over time as they fixed issues and learnt how to get the best out of the hardware.

I was thinking that I read somewhere that in the US the cable delivery format standard is fixed by law so that, if hardware works for one cable company - it will work for all. Is this a myth?

It's easy enough to upgrade your HD PVR firmware - but, I guess there's nothing you can do about a difference in hardware.

Here's something I'm wondering - Does MePo/.Net prefer 32 over 64 bit in OS? I was thinking that it would be good to finally move into W7/64 and take advantage of the additional addressing space by adding more RAM. Are there any problems I should know about with using a 64 bit version of Windows?

 

[mm1352000]

To be honest, there isn't much you can do other than getting advice from other people who watch the same channels as you and have a similar video card to you. There is also DxVA checker which allows you to check what h.264 "sub formats" a video card can handle, however at the end of the day it is really trial and error.

Wow! What an effective and useful 'standard'!

It isn't quite as bad as it sounds. I'm sure the video card designers do their best to provide robust support for all features/profiles/levels in the standard. What I meant was that if you really want to be certain that such-and-such a codec will work with a certain family of video cards and content from such-and-such a provider then you're only going to know for sure by trying. In most cases it should work. The key point is that it is not easy to know what features the broadcaster uses so you can't check against the codec and video card...

CPU only really matters if you're not using hardware accelerated h.264 decoding.

Might one be able to use Task Manager to check for excessive CPU use prior to video problems as a check for lack of h.264 acceleration?

Absolutely - that is the easiest way to tell (in real time) whether hardware acceleration is being used or not.

I was thinking that I read somewhere that in the US the cable delivery format standard is fixed by law so that, if hardware works for one cable company - it will work for all. Is this a myth?

No idea. New Zealand doesn't really have to worry about more than one pay TV provider

It's easy enough to upgrade your HD PVR firmware - but, I guess there's nothing you can do about a difference in hardware.

Yup. I don't know if Hauppauge openly share the changes that they make or even that they have made multiple hardware revisions. You'd like to think that the hardware changes are transparent to the user and compensated for by firmware/driver changes.

Here's something I'm wondering - Does MePo/.Net prefer 32 over 64 bit in OS? I was thinking that it would be good to finally move into W7/64 and take advantage of the additional addressing space by adding more RAM. Are there any problems I should know about with using a 64 bit version of Windows?

.NET is a software development framework that can support either 32 or 64 bit application development. It is up to the developer to decide which option (or both) they would like to target. MediaPortal is 32 bit. There is very little advantage to having more than 4GB of RAM for MediaPortal only. No comment regarding problems with 64 bit Windows. My personal experience is very limited in that domain...

 

[Blue Energy]

The key point is that it is not easy to know what features the broadcaster uses so you can't check against the codec and video card...

I guess that in this case the 'broadcaster' resolves to 'Haupauge' though, right - since the HD PVR is doing the conversion into h.264 regardless where the original signal comes from? Since there is only the one, wouldn't that make it easier to accomplish?

Overall, though, in spite of having no reason to believe that the hardware I buy will work at all with an HD PVR, and no way to figure out what will work other than to ask someone who has already gone in blind and gotten lucky - I feel more confident that this will work out for me for some reason. I think I'm going to try it.

I figure that I will get a small, very fast, SSD to do timeshifting and use a 1 TB Barracuda that I already have sitting around to do OS and storage. The SSD might also help with the I/O difficulty that was reported in that other thread until it is ultimately resolved (or in case that it isn't). I think that I won't go in for a very fast processor in hopes that the gcard will do the acceleration - but I'll still get a decent one. I'm hoping to use this machine for multiple things. It will ultimately take the place of my office machine - so I'd like plenty of RAM and a gcard capable of playing curent games, but also programming and hosting a database. I haven't decided on a graphics card yet. People in the MythTV world recommend Nvidia - but that just seems to be because of the availability of Linux drivers for them. I won't be running Linux on this box, so that shouldn't matter. I'm kind of leaning toward an ASUS card with an ATI 6870 in it for the combination of power and quietness/coolness over something with an Nvidia GeForce GTX 460 in it. It seems to edge it out in performance. I'll try to buy it (whatever it ends up being) from someplace where I can exchange it if it won't do Haupauge's version of h.264 flawlessly.