AMD Radeon.care@HEXUS
LinkBack URL
About LinkBacks
No, hrlslcbr he was referring to me, I think Jonas is happy that you are saying it again for him for my benefitOriginally Posted by hrlslcbr
Thing is, like many, I have suffered with conexant chips, but one can finally manage, by much madness, to encode up watchable stuff (kids videos to MPEG1).
So I was eager for the 550Pro, but these delays had led to my finally throwing in the towel and buying a Hauppauge 150, only to take it back the next day. Why?
Well, as satnav4 said, the winTV task processor use is higher when watching with the H150 (20 - 25%) and it is obviously the WinTV 2000 preview mode eating resources: with the conexant chip, it's about 4 - 10%, because this old card doesn't have preview.
My test was to feed the 150 a composite signal to encode from my VCR: I didn't test s-video, still haven't bought a cable
So I'm watching a small screen of the video I'm encoding, on 1024 X 768, and now I'm seeing the processor WinTV task at a constant 50% with spikes of up to 75%. If the H150's hardware is doing the encoding, why is the processor suddenly in a sweat handling this data stream? All it has to do is recieve the data stream from the H150, already nicely encoded up in the card's hardware, and dump it to my 7200 slave drive. This is on a box with no memory resident programs running: nigh-on a dedicated box (I have a seperate OS for this as I've always been using this conexant chip).
Now, if switching to s-video makes this jump go away (taking a cue from what satnav4 says about these cards), I've acted prematurely in taking the unit back. Should've just broken down and bought the s-video cable!
If you look at the hardware schematics, it's clear BOTH the H150 and the 550Pro cards encode to MPEG using their on-board hardware. Trust me, jonaslasky, this point was stressed way back and I didn't miss it. The PC has to decode the stream to display it. Normal stuff. Furthermore, even if the preview is eating resources, it should not affect the quality of the encode, nor it's audio synch, because the encoding should be happening on the card, not on the PC. And true enough, none of my tests had any flaws in the audio/video quality. Unfortunately this doesn't prove the H150 did the encoding of the composite signal: my processor may be just a smoothy. Of course what you see on the screen may jump and glitch a little, because the processor gets fed up at throwing resources at resolving the display, and craps that up to give itself some air, and that should be enough for it to recover it's wits and get on with encoding.
What I mean is it is a common feature of digital video software that the encoder gets to hog resources, and the decoding for display gets a lower priority. It's a safeguard engineers build into the code to preserve encoding quality.
My fear was that 50% processor use and higher for the WinTV task was too high to trust. At that rate, given you'll also be wanting to use your PC for doing something else, there will be errors on the encode on occasion, because the processor has got too many balls in the air all the time.
I expected a slight drag, from the 20-25% used to decode the data stream and display the image, up to 28-30%, figuring 3% or so would be the energy needed to transfer the encoded data to my 7200 speed slave disk. But no, it's not 3%, it's 30% on the composite channel. Ten times more than it should be.
I can't be bothered to go dig out the post someone made about the 550 Pro on composite running a console game, where he said he had a high processor use like I experienced.
It's odd.
Unfortunately I couldn't test the antenna input: that is, straight airwave broadcast: my antenna here is all mucked up.
Plus this is all H150 talk, and this topic is the 550Pro.
If someone does a similar test with the 550 Pro (puts on a video, runs the signal via composite to the 550Pro, then encodes the signal while watching), and gets only a small processor hit on the running task: basically, just the use that decoding the signal to the display requires, and the use that sending the encoded data to a slave drive requires, then I accept that either my poor PC has some "other" problem other than the general tiredness of it's boss, or the Hauppauge product has messed up its implementation of the composite channel. Or I had a duff H150 card, by lack of chance. I remember people have commented on their findings regarding this, but it's an archeological dig at this point to find out if they were encoding using an antenna, composite or s-video feed.
I regret I didn't try BeyondTV. It may handle these things better than the H150's native software, and my worries are therefore misplaced and all caused by dodgy hauppauge soft
satnav4, you said you'd made a satisfactory encode, but you hadn't said if you felt the 550Pro quality exceeded the H150. I'm curious...
