H.264 GPU-Assisted Playback

[kaboom]

Hello all,

I'll have a nice little project to set up where I'll be playing either MP4s or MKVs containing H.264 video or 'straight' H.264 files. Bitrate will be between 3 and 6 Mbps. Occasionally, I'll have 8 - 10 from the source files.

In an effort to get the sharpest picture/maximum video bandwidth, I will be 'real-time sharpening.' Either with VLC (Sigma Sharpen from 1/3 to 1/2 of FS) or ffdshow (Unsharp Mask at 85) via MPC. I will also need to 'zoom' in while playing back the 16:9 format since I will be feeding 'old' equipment- slightly more easily done in MPC with its continuous playback zoom.

Not a word about 'being stuck in the past' please! And besides that, I cannot stand when the video is 'wider than widescreen.' Such as when video on an HDTV has horizontal blank space at the top and bottom of the picture. I will "do something" about that... It's also nice to zoom in so the DOGs are no longer visible.

I find it hard to go with NVidia because of all the BGA issues. However, comparing these two...

http://www.newegg.com/Product/Produc...82E16814129143

http://www.newegg.com/Product/Produc...82E16814130395

...shows that one could get more than double the performance with the 9500 GT, for less than half the cost of the Radeon HD 4550. Also, twice the memory on a bus twice as wide. Of course, one is DDR3, the other is DDR2...
I also wouldn't put it past anyone to have used 'demo cards' with different caps for those pix.

If you look at those two cards, you'll notice that the ATI is missing a cap. I've traced it out with several pix, and found that the missing cap (C695, component side) is an input filter to a buck converter. Q701 is the high side MOSFET, Q702 is low side, L701 output inductor, C725 output cap. No problem for me to add the missing cap. As it is, that buck converter's 'input cap' is C636, almost on the other end of the board. Or the cap(s) filtering power to the PCI-E slot, if it happens to be closer electrically.

Now on the NVidia card, they left out a MOSFET, Q3, in that card's buck converter. I'm a little suspicious of that. If the missing component is a low side MOSFET used for synchronous rectification, then that ckt has half the capacity it should have. That's ASSuming they didn't use one MOSFET with half the RdS/twice the ampacity of the two it would've had originally- in that case, it wouldn't matter.

I'd appreciate feedback, specifically, heat/BGA soldering issues, cards/GPUs dying for "no reason" and so on. If any of you have suggestions for a better or different card, please give me your ideas. $150 or less, and it must have S-video and VGA outputs, and fit a PCI-Express 2 x16 slot. VGA via DVI with those adapter plugs is also acceptable.

And please, no BS about requiring a "500 watt" power supply if the added load is, at most, 65W or so in the case of the 9500 GT. If I wanted any of that nonsense, I'd hang out with antecrep.

Thanks in advance,
-Paul

[Uranium-235]

Re: H.264 GPU-Assisted Playback

I've had no nvidia video cards bga die on me, only motherboards, but your expirence might differ

I mean, my names paul tooo

[Colt45ws]

Re: H.264 GPU-Assisted Playback

I looked up the 9500GT. It looks like the chip underwent a die shrink at some point from 65 to 55nm. That might explain the missing component if they used the same board.
My dedicated HTPC uses a G210. Something like 13 watts power draw. If I did it again I probably would have gone with a GT220 for a bit more power as I seen some tests done with the G210 showed it wasnt up to a whole lot of filtering. However, my G210 OCs like mad. I can max out the scale in the MSI tool.
btw, when I bought it, I looked at the pics, and I seen rubys so I didnt have any qualms about those. When I actually got the card it had polys. I went Yay! Upgrade!

[toastygoodness]

Re: H.264 GPU-Assisted Playback

it's not actually twice, more like 96 vs 130 GFLOPS...

ah crap s-video is so hard to find now...

i try to avoid nV now due to all that bga fun, but i'd go for the cheaper solution. if you need an LP card, keep in mind that even if the pic show's a LP card with a FP backplane, you can usually get the LP backplane for free from the mfg (incl. or just contact them).

[kaboom]

Re: H.264 GPU-Assisted Playback

it's not actually twice, more like 96 vs 130

Hehe...

I had fill rate and memory bandwidth stuck in my head.

I'd rather have a full-height card than an LP. A taller card could take a bigger heatsink if it ever seemed inadequate. The board is also secured better- more anchor points on the full size card.

In the case of that particular 4550 card, the full-height bracket does not have a threaded boss to take a screw from the hole I've marked. Therefore, in order to hold at that point, I'd have to solder a small piece of angle to the full-height bracket and drill it so it would hold the board.

In any case, I'll 'pre-oil' the fan and do an AS-5 job on the heatsink when I get whichever card. I don't plan on having any problems... The 9500 is tempting...



-Paul

[toastygoodness]

Re: H.264 GPU-Assisted Playback

don't use AS5 for gpus, use something like arctic ceramique or arctic cooling mx-2, if the heatsink doesn't use screws, ceramique will stick better and mx-2 dries out slower than AS5. AS5 requires constant changing, so it's really only viable for CPUs, unless you enjoy changing GPU heatsinks heh.

i'd guess you have to go for the 9500; just wondering, why do you need s-video?

[kaboom]

Re: H.264 GPU-Assisted Playback

The heatsink is attached with screws that go through the board. I'll use AS-5, thank you.

S-video is to feed VCRs. I happen to have a recording from the early-mid 90's back when downlinks to the CATV headends were nice fat 6.5+ MHz channels, with some nice wide deviation FM carrying everything.

I've got several recordings that make those awful "3 hours plus extras" over-compressed DVDs look like the garbage they are. These weren't even S/VHS recordings...

MPEG-2 may have been great, back in 1988. The fact that DVDs even use that nasty old shit years later is disgusting.

This is a gross over-exaggeration, but imagine a light gray remote control with slightly darker buttons. Run that through the nightmarish juggernaut that is MPEG-2 at bitrates typically used on DVDs. 1.25-3 Mbps. -Any- motion at all, not just rapid motion, will cause the following. The 'rectangular' outline of the remote will follow the movement, but the inner 'filled' areas will sort of 'float,' with the buttons 'wobbulating' and not following anything. Gimme a break...

Let's top that with Dish Net(won't)work. YUCK! What they call 'SD' is a whole 1.25 Mbps feed and their 'HD' still occupies less bandwidth than one of those old FM downlinks, even after "uncompressing."

Take a computer monitor now. Let's leave both sync lines connected and set the scan format to 1280x1024. All the goobers will scream the praises of having "lotsa lines" but disconnect the three mini coaxes and now you have ZERO bandwidth and a blank raster.

The extreme case:
Take a 10th or 15th generation video tape copy. Lousy picture, right? But the pundits will "specify" that the number of scan lines is exactly the same as that of a studio quality signal. Which it is, as long as sync is maintained. See how it is?

While the number of lines is the same in either case, the master is pristine compared to the 10th gen copy. "Well, if the number of lines is the same, how come there is such a difference in quality?" Bandwidth.

(As well as chroma and sync issues)

In all fairness, H.264 after decompression gives -much- better quality/higher bandwidth in the outgoing signal than MPEG-2.

A few years ago, one of the receivers at our headend lost the downlink for ESPN. The receiver was outputting its status screen over the whole HFC cable plant. Some parameters were displayed, including bitrate of the rx signal. How much do you think it was for ESPN at SD? Try 25+ Mbps! I think it was 'DV' compression. The big-big-brother of those "MiniDV" camcorders.

Sloppy connections and poor SNRs are what gave 'analog cable' its lousy reputation. But now, with 6-8 'logical channels' over only a few MHz, not even RG-11 can save us. If anything, digital cable only masks lousy line conditions, that is, until the SNR and/or levels are so bad that the set-top rx has nothing to work with. AKA- the "freezing picture."

But I digress,
-Paul