and by ridiculous i mean absolutely ridiculous:
tom's hardware did what is probably the most thorough look at cuda, quick sync and app in a long time, maybe even the best comparison ever. they did image quality comparisons, decoder, encoder, you name it.
look at the graph on the above linked page and check out the encoding times for quick sync, they took a 31.2 gb blu-ray and transcoded it to an ipad friendly 3 mb/s 720p profile and the encode times were, get this, 19:35 with the "performance" settings and 23:22 with the "quality" settings.
that's just sick, being able to take a full blu-ray movie and being able to transcode it at what is roughly 3 times the playback frame rate?!? just incredible.
i can't wait to see someone release an open source app where all the options for quick sync are adjustable, to see what it can do with all the settings maxed out, such as motion estimation range and type, number of b frames, preprocessing, etc.
+ Reply to Thread
Results 1 to 3 of 3
I'd wait and see some real times from real users .. I suspect that the speed's wont be anywhere near what is stated on that review. I still cant figure what's best with that review. Be3tter to wait for the ivy dale,(shes a lovely girl) where the ability to use quicksync and a discrete gfx card might be allowed, or someone hacks/works around the quicksync so your not stuck using the equivalent of an Mx440 for gfx.Corned beef is now made to a higher standard than at any time in history.
The electronic components of the power part adopted a lot of Rubycons.
as far as QS is concerned, we won't see the full potential of it until someone decides to build an app that exploits all the features of the sdk.
i actually downloaded the sdk and documentation and was pouring through all the code samples and was trying to put together a front end for media sdk, but i'm afraid my windows api programming skills are not up to the task. i was going to ask over at the doom9 forums if anyone was interested in jumping in on the project but they are such a bunch of *******s over their that i figured the hell with them.
i did put in a request with stan, the media coder developer, to support sdk in a future release, but have received no answer thus far.
what i was wondering is if clarkdale cpu's can take advantage of the hardware decode capabilities of the sdk, maybe someone with a clarkdale can test it out with the latest tmpg.