HD PVR set up in vista x64

[mashakos]

Its because we're talking about two different things. I'm talking about a slight delay between the input signal and what you see/hear on the screen. It sounds like you're talking about a delay between the audio and video.

This A/V sync problem you describe probably relates to the decoders you're using.

hmmm

I'm connecting the PS3 directly to my audio reciever, not the HD PVR. Does that explain it?

[sub]

Yep, most likely.

There will always be a delay introduced as the signal goes through the HD-PVR and the directshow layers, so you really need the video to be going through the same path to ensure they're in sync.

[mashakos]

Yep, most likely.

There will always be a delay introduced as the signal goes through the HD-PVR and the directshow layers, so you really need the video to be going through the same path to ensure they're in sync.

EDIT: dumb question.

I'll try and see if the HD PVR can output 5.1 dolby surround unscathed...

[sub]

I dont know - I've never done it myself.

[whurlston]

yeah... I was wondering why Hauppauge didn't go for firewire :/

USB 2.0 is 480Mbps, Firewire (IEEE 1394a) is 400Mbps. Even Firewire 800 (IEEE 1394b) is nowhere near enough for raw analog HD video. In fact, you would need a pretty impressive RAID array to capture raw analog HD video. Here is a chart showing transfer rates needed for various 4:2:2 video:

Code:

Standard Definition
Frame Size                  MB/second       MB/minute      GB/hour
720x486/29.97fps (NTSC)       21.5            1288          75.5
720x576/25fps (PAL)           21.2           1274.4          75

High Definition
1280x720p/59.94fps            106.8          6409.7         375.6
1920x1080/50i                 100.3          6020.5         352.8
1920x1080/59.94i               120           7199.9         421.9

Notice that these values are megaBYTES, the transfer rate of Firewire is 400 megaBITS (8 bits = 1 byte). Contrast the above rates with 9 GB/hour for MPEG-2 encoded OTA HD.

[mashakos]

I thought uncompressed 1080p was ~ 300 megabytes / sec ?

USB 2.0 runs at 480 Megabits / sec so that's 60 megabytes / sec ...

EDIT: crap, firewire is in bits


Obviously uncompressed is not practical for recording. Streaming is a different story. My ram has a bandwidth of 1.1 Gbytes / sec. Don't know how fast the video ram is but it's way faster than my system ram. For streaming and live tv it's quiet capable of handling uncompressed 1080p.

If only there was hardware for it...

[whurlston]

I thought uncompressed 1080p was ~ 300 megabytes / sec ?

USB 2.0 runs at 480 Megabits / sec so that's 60 megabytes / sec ...

EDIT: crap, firewire is in bits


Obviously uncompressed is not practical for recording. Streaming is a different story. My ram has a bandwidth of 1.1 Gbytes / sec. Don't know how fast the video ram is but it's way faster than my system ram. For streaming and live tv it's quiet capable of handling uncompressed 1080p.

If only there was hardware for it...

You're still passing the same amount of data so USB/Firewire would still not work. I once asked stranger89 on AVS about a theoretical DirectShow encoder filter and here was his answer:

Theoretically, a realtime software compressor would need bus bandwidth (PCI/PCIe/PCI-X) for uncompressed HD. That could be 4:2:0 to 4:4:4, 4:2:0 requiring 12*1920*1080*29.97 ~ 750Mbps, 4:4:4 requiring ~ 1.5Gbps, and 4:2:2 requiring ~1Gbps.

Note that PCI is basically incapable of the last two, and probably even the first isn't practical.

That's just the one-way bandwidth, card to ram (over PCI/PCIe/PCI-X), and why there are no PCI HD capture cards.

Now, you need to double that (at least) because the data must be read in and out of memory as fast as it's created, maybe multiple times.

Now that you've got compressed data, that 20-50Mbps stream would need to travel back over the PCIe/PCI-X bus and to the HDD, so basically:

Bandwidth needed for realtime software compressed HD:
20-50Mbps to the HDD
0.75-1.5Gbps (+50Mbps) over PCIe/PCI-X
1.5-3.0Gbps (or potentially several times that) CPU memory bandwidth

And then of course the horsepower to compress it. Looks like even the Q6600 can only pull off about half realtime.

A streaming filter would require the same bandwidth but you wouldn't need the horsepower for encoding. But keep in mind that the above bandwith would be just for receiving the data and you would still need additional bandwidth for other Windows tasks.

[mashakos]

I'll have to relegate the HD PVR to recording from a future HD reciever, what a letdown...

a few people seem to be having luck with the Black Magic Intensity Pro where live streaming is concerned. There were complaints about the uncompressed stream but those with high end PC's claim it's not an issue.

I'll check with Blackmagic's support.

Does GBPVR recognise the Blackmagic Intensity Pro? If not are there any plans for supporting it?

I hope so! If the Intensity Pro turns out to be a good solution for live streaming having it in combination with the GBPVR would be literally the ideal solution to my problem.

[sub]

I'll have to relegate the HD PVR to recording from a future HD reciever, what a letdown...

Its a great device for its intended purpose. Unfortunately you wanted it to do something else.

Does GBPVR recognise the Blackmagic Intensity Pro? If not are there any plans for supporting it?

I hope so! If the Intensity Pro turns out to be a good solution for live streaming having it in combination with the GBPVR would be literally the ideal solution to my problem.

Sorry, no it doesnt currently support this device, and unlikely to in the future. The main purpose of GB-PVR is recording, and it uses hardware encoders to do this. The Intensity Pro has no encoder, so is not a good match. I also dont have one, which means I cant even experiment with the idea.

[mashakos]

ah, too bad. I really like the unobtrusive GBPVR interface, and the fact that it takes 1 second to start and shut down.