x264 and Intel's Media Engine / Sandy Bridge [Archive] - Page 4

Dark Shikari

11th January 2011, 01:14

what happened to francois and all that working together business for x264 prototype? was it just for show ?

or did the you scare him off :pIntel are incompetent, lazy, bureaucratic idiots. They don't even care about the companies they invest millions of dollars in, let alone "open source". It's practically their job to produce cool tools that nobody can use.

Note this doesn't mean there aren't smart, competent people there. They're just crippled by the bad organization.

I see. But where exactly is the encoder implemented then?

Is it implemented in some Intel-provided library that makes use of these "hardware tools" through some undocumented API or is it implemented inside the CPU as firmware/microcode?Combination.

LoRd_MuldeR

11th January 2011, 01:27

Combination.

Okay. But then from a programmers point of view QuickSiny is "black box", isn't it? You either use their encoder library to replace your software encoder or you don't use it at all.

And, if the undocumented API to the "hardware tools" ever gets revealed/reverse-engineered, do you think there is a chance we can do something "valuable" with it?

Dark Shikari

11th January 2011, 01:31

Okay. But then from a programmers point of view QuickSiny is "black box", isn't it? You either use their encoder library to replace your software encoder or you don't use it at all.Yes .

deadrats

11th January 2011, 02:12

No, it's a set of hardware tools that can be used to make an encoder. They just don't expose the API for this, so it's a useless pile of silicon.

see, this is the type of crap you spew that makes me want to scream. if you download the intel media sdk and read through the documentation you'll see that it has 2 "faces": 1) there are fixed functions that can be used to accelerate many different parts of the video encoding, decoding and pre/post processing chain as well as fully programmable silicon that you can custom program.

the hardware is easily accessed by anyone that has ever coded via the windows api, specifically dx9 and the functions are easily called.

for instance there is a built in SAD function, if you knew what you were doing you could call that from within x264 (of course such a version of x264 would be windows specific).

there is ample documentation as well as source code samples:

http://software.intel.com/en-us/articles/media/

one caveat, you'll have to compile your app with either vc or intel's c compiler.

deadrats

11th January 2011, 02:20

Okay. But then from a programmers point of view QuickSiny is "black box", isn't it? You either use their encoder library to replace your software encoder or you don't use it at all.

And, if the undocumented API to the "hardware tools" ever gets revealed/reverse-engineered, do you think there is a chance we can do something "valuable" with it?

DS evidently doesn't know what he's talking about or he has some hidden agenda to promote FUD, the api is fully documented and exposed and reading through all the documentation does lead one to believe that it most certainly is not an "all or nothing deal", it does look like you can pick and choose buffet style:

http://software.intel.com/en-us/articles/intel-media-software-development-kit-an-architectural-overview/

do yourselves a favor, read through the documentation and see for yourselves exactly what quick sync brings to the table, i think you'll agree with me that it holds lots of promise.

kieranrk

11th January 2011, 02:30

There is no SAD function as far as I can see in the SDK.

Dark Shikari

11th January 2011, 02:42

DS evidently doesn't know what he's talking about or he has some hidden agenda to promote FUD, the api is fully documented and exposed and reading through all the documentation does lead one to believe that it most certainly is not an "all or nothing deal", it does look like you can pick and choose buffet style:

http://software.intel.com/en-us/articles/intel-media-software-development-kit-an-architectural-overview/

do yourselves a favor, read through the documentation and see for yourselves exactly what quick sync brings to the table, i think you'll agree with me that it holds lots of promise.The high level API is documented. It lets you "encode H.264" through Intel's terrible encoder. It is beyond useless to x264.

The low level API is not documented. It lets you do "motion search" or "encode a macroblock" or other parts of an H.264 encoder. It would be useful to x264. Many parts of it involve microcode, such as the motion search pattern. It is impossible to load microcode onto an Intel chip without secret software, tools, and probably private keys that only Intel has. This is to prevent viruses and such from abusing the ability to modify microcode.

I thought you apologized for being a jerk to me a week or two ago? Or did that go out the window, and now you're going to go crazy insulting me again and claiming that I'm an evil ignorant Intel hater who's out to get you?

deadrats

11th January 2011, 03:51

There is no SAD function as far as I can see in the SDK.

page 116 of the intel media sdk manual pdf, the name of the function is MFX_COSTTYPE_SAD, there is also ssd and sahtd functions.

kieranrk

11th January 2011, 03:57

page 116 of the intel media sdk manual pdf, the name of the function is MFX_COSTTYPE_SAD, there is also ssd and sahtd functions.

Those are parameters to their encoder.

deadrats

11th January 2011, 04:27

I thought you apologized for being a jerk to me a week or two ago? Or did that go out the window, and now you're going to go crazy insulting me again and claiming that I'm an evil ignorant Intel hater who's out to get you?

first things first, the truth of the matter is that you have been a jerk to many people over the years, especially when anyone had the "audacity" to ask you about gpu acceleration with regards to x264. at times you have responded with either dismissal to outright contempt for the person asking the question.

hell, you ripped into that intel developer that offered to help you modify x264 to work with QS by ridiculing his work on sse4. well how many simd instructions have created? i'm not surprised he disappeared, i would have told you to go "f" yourself from the get go.

furthermore you have made it a personal campaign to spread FUD with regards to any encoder other than x264 and have attacked anyone that ever conducted a test in which x264 was not a clear winner.

what's more galling is that people with no programming knowledge have tended to listen to you because of your status as lead developer of x264 and i keep seeing people say some truly stupid things with regard to gpu's, in many video related forums.

my apology to you was given, and warranted, because i had made some incorrect assumptions concerning the programming decisions you made with regards to x264, facts which certainly did lend credence to many of the objections you had raised with regards to gpu accelerating x264.

that does not mean that i won't call you out when you say something patently ridiculous. quick sync has barely been released and you have already dismissed it as useless, you have already made factually incorrect statements about it and people that by their own admission don't even know what quick sync is, does or how it works have already decided it sucks because you have proclaimed it's so.

well i'm sorry, i have a mind of my own and amble programming experience, and i also know that the proof is in the pudding, the thing you are already proclaiming as useless is already being included in consumer grade software, including an app by the first company to license your software.

if you're looking for people that will kiss your ass, tell you how great you and your software is and will believe anything you say without question, then you and i won't be getting along all that well.

if however you want some honest feedback, then we can engage in meaningful dialog.

i'm telling you as an end user i have little to no interest in any software based encoder that will tie up my cpu to maximum usage for hours at a time. i would much rather have a QS based encoder that runs at 100fps for 1080p content, leaves my cpu at idle, even if it means that i have to use some more bit rate.

if you couldn't care less, if as far as you're concerned i can go "f" myself and the horse i rode in on, so be it.

all i know is that people won't put up with encoding times that are 2-4 times as slow for too long.

deadrats

11th January 2011, 04:39

Those are parameters to their encoder.

technically they are parameters that are passed to a SAD function within the encoder but the documentation makes it clear that it can be used independently of any other part of the encoder.

the mistake many people seem to be making is in thinking that QS works the way a normal hardware encoding chip does, that is not the case, the documentation makes it clear that it's more like a software encoder that runs on dedicated hardware, you are free to pick and choose which parts you want to use.

Dark Shikari

11th January 2011, 04:41

well i'm sorry, i have a mind of my own and amble programming experience, and i also know that the proof is in the pudding, the thing you are already proclaiming as useless is already being included in consumer grade software, including an app by the first company to license your software.Plenty of things which are crap get used in software, "professional" and "consumer" grade, all the time.

If an H.264 is significantly worse than Ateme, Mainconcept, and x264 in all relevant use-cases, it is crap. As far as I can tell, the default Media SDK encoder is crap.

I would love to be able to make a better one. But Intel apparently doesn't want their chips to be useful.

the mistake many people seem to be making is in thinking that QS works the way a normal hardware encoding chip does, that is not the case, the documentation makes it clear that it's more like a software encoder that runs on dedicated hardware, you are free to pick and choose which parts you want to use.Actually, that is the way a normal hardware encoding chip works. The OMAP4 is probably a good example: it has a number of asynchronous ASICs, each hooked up to minimal ARM controllers, connected via SRAM. Now, please stop talking about things you are clueless about.

Mixer73

11th January 2011, 07:40

I'm watching this with interest - I've been on the wrong end of DS' razor tongue but I did ask a stupid question... More than once. I think brilliant people can be short like this - they just don't appreciate that other people don't understand things like they do. Or they get frustrated because people don't try. Cal DS whatever you like, but his contributions to this environment stand on their own.

I don't know one end of these encoders from the other apart from the fact that x264 lets me store lots and lots of programs in a small space, and on an i7 it doesn't take too long to do.

For realtime transcoding I can see some value in these solutions but anybody who would use them for something you're going to keep has rocks in their head (IMO).

I cannot see what the Quick Sync offers that isn't already offered in poor quality GPU encoders - (apart from being cheaper by being integrated) and being not as obviously horrible on the quality. I just have zero use for a really fast but poor quality encoder.

Perhaps DS can correct me if I am wrong but I can spend time and cook a nice dinner or I can just stick a whole heap of shit in the microwave and call it dinner, yes it will be quicker, but will the result make me happy? I'd rather spend the time, and savor the moment.

aegisofrime

11th January 2011, 08:05

One advantage Quick Sync has over GPUs is that since it's integrated with the CPU, there's much less latency. With the GPU one concern is that even if you can offload some of x264's functions onto the GPU, it will take too long for the data to travel back and forth, nullifying any performance gains.

At least, that's what I remember DS saying about GPU offloading.

What I can see from my n00b eyes is that while Quick Sync has potential for usage by x264, this potential has been destroyed by Intel not allowing low level access to it.

GodofaGap

11th January 2011, 10:07

weasel_

11th January 2011, 14:26

I cannot see what the Quick Sync offers that isn't already offered in poor quality GPU encoders .
better speed ,cheaper...
but same shity quality

shroomM

11th January 2011, 14:56

I think that any discussion about the quality and speed of QuickSync is pointless until one can actually reproduce the results published on Anandtech.

"Lossless PNGs" on their review are 2000x1160 (1080p version) and 1360x614 (720p version). How is that lossless? Obviously they were resized.
We don't even know how they were captured in the first place. Also, there's no PNG of the original frame to compare to.

weasel_

11th January 2011, 15:29

quote from there
"With Quick Sync you can have both(speed and quality), and better performance than we’ve ever seen from any transcoding solution in desktops or notebooks"
+
2,000 x 1,160

That test is pointless
and write by somebody who are incompetent

Zerofool

11th January 2011, 15:29

I just want to add something. If I understand correctly, Quick Sync can only be used when the integrated GPU is used, meaning you'll need a H67 board. These boards, however, do not offer any CPU overclocking abilities (aside of TurboBoost), so everyone who wants to OC their CPU (it's a shame not to) will get a P67 board (and dedicated powerful graphics card), and therefor, won't be able to use Quick Sync even if they wanted to. Well, at least until the Z67 chipset is released, that is.

weasel_

11th January 2011, 15:35

http://www.anandtech.com/show/4113/lucid-enables-quick-sync-with-discrete-graphics-on-sandy-bridge

popper

11th January 2011, 15:44

Except many don't care much about quality and will happily broadcast 1080i @ 4mbit that looks worse than SD.

Yep- as I said- even if x264 is free and so great almost no one uses it, because it's a business and there is more political decision made than logical :)

Andrew

so, kolak what's probably needed then, given Today's industry standards,
is a X Brand 264 and 262 (aka mpeg2) with a broadcast encoder with at least OBE-RT for real-time 24/7 operation and OBE-VoD when dealing with file-based workflows,
HD/SD-SDI card for SDI input,ASI card for ASI input and/or output,
MKV, YUV2, Y4M, etc, because some Pro is going to want to use an X brand vp8 in the future OC
and Raw UDP, RTP/UDP, Multicast IGMP v2, Unicast, RTSP, RTMP etc.

under a commercial and Open licence and a Red Hat 5.x or Centos 5.x 64-bit or Ubuntu 10.x 64-bit OS to run this Hardware as a basic requirement ?

but then how do you get ANYWHERE NEAR that 100 Mega Byte raw 8 bit for the home playback use that deadrats wants ?...

.... given that even the Very latest world standard DVB (2) spec http://www.dvb.org/technology/standards/a133_DVB-T2_Imp_Guide.pdf as used in the EU and many professional IPTV businesses Only allow at 64-QAM 24.1 Mbit/s, and 36.1 Mbit/s at 256-QAM for Everything including the video/Audio stream etc :devil: and why did they state in
4.2 Background design principles
c) T2 should not re-invent solutions if they already exist within other DVB standards

perhaps they should have re-invented and given deadrats his 100 Mega Byte/s Plus other overheads Home TS stream.

Oops those damned professional DVB Business pirates looking to Encode and stream at low bit rates just so they can make profits,and put several channels on that 36.1 Mbit/s Or far less wireless carrier, is it wrong !

Zerofool

11th January 2011, 16:08

http://www.anandtech.com/show/4113/lucid-enables-quick-sync-with-discrete-graphics-on-sandy-bridge
That only allows you to use a dedicated gfx card on the same H67 board, and still be able to use Quick Sync. It doesn't change the situation with P67 boards (overclock). But yeah, it's still a nice thing to have.

popper

11th January 2011, 17:01

That only allows you to use a dedicated gfx card on the same H67 board, and still be able to use Quick Sync. It doesn't change the situation with P67 boards (overclock). But yeah, it's still a nice thing to have.

so wait, only the cheapest LOW END H67 Sandy Bridge motherboards will work, these are not something a professional High bit rate Encoder guy would be using then, as they are slow and dont have Pro Raid etc on them....

so what's deadrats on about then, given he states he's a Home user and so Doesn't have access to Pro masters, only low BR bit rates at best, and even lower TS DVB/CAM OC.

and if he's got the BR and wants to keep so called mathematical transparency then what purpose does ANY encoder serve For him?, a ripped BR TS takes up the same space on a HD as the file on the BR. so NO re-encoding required.... for him.

kypec

11th January 2011, 17:34

... and if he's got the BR and wants to keep so called mathematical transparency then what purpose does ANY encoder serve For him?, a ripped BR TS takes up the same space on a HD as the file on the BR. so NO re-encoding required.... for him.
He just loves re-encoding for no real benefits, that's all.:p
Or perhaps he never heard about re-muxing either...He would be so amazed to see what transfer speeds can be obtained with those AND no quality loss whatsoever!

mariush

11th January 2011, 18:04

That only allows you to use a dedicated gfx card on the same H67 board, and still be able to use Quick Sync. It doesn't change the situation with P67 boards (overclock). But yeah, it's still a nice thing to have.

Is it just me that wonders what's the point of this?

You're buying a 250$ cpu, a 350$ motherboard and a 400$ video card just to use Quick Sync?

That's 1000$ to get faster Youtube quality videos? Who are they kidding....

hajj_3

11th January 2011, 18:18

i'm pretty sure you don't need a video card, you use the built-in gpu that is in the new intel chips. Core i5 starts at £136 and £70 for H67 board or £90 for a P67 board.

popper

11th January 2011, 18:25

He just loves re-encoding for no real benefits, that's all.:p

Or perhaps he never heard about re-muxing either...He would be so amazed to see what transfer speeds can be obtained with those AND no quality loss whatsoever!

does that make him a cool or crazy kitty then
You decide :)
http://kittywigs.com/img/blue1.jpg

kolak

11th January 2011, 18:32

so, kolak what's probably needed then, given Today's industry standards,
is a X Brand 264 and 262 (aka mpeg2) with a broadcast encoder with at least OBE-RT for real-time 24/7 operation and OBE-VoD when dealing with file-based workflows,
HD/SD-SDI card for SDI input,ASI card for ASI input and/or output,
MKV, YUV2, Y4M, etc, because some Pro is going to want to use an X brand vp8 in the future OC
and Raw UDP, RTP/UDP, Multicast IGMP v2, Unicast, RTSP, RTMP etc.

under a commercial and Open licence and a Red Hat 5.x or Centos 5.x 64-bit or Ubuntu 10.x 64-bit OS to run this Hardware as a basic requirement ?

but then how do you get ANYWHERE NEAR that 100 Mega Byte raw 8 bit for the home playback use that deadrats wants ?...

.... given that even the Very latest world standard DVB (2) spec http://www.dvb.org/technology/standards/a133_DVB-T2_Imp_Guide.pdf as used in the EU and many professional IPTV businesses Only allow at 64-QAM 24.1 Mbit/s, and 36.1 Mbit/s at 256-QAM for Everything including the video/Audio stream etc :devil: and why did they state in
4.2 Background design principles
c) T2 should not re-invent solutions if they already exist within other DVB standards

perhaps they should have re-invented and given deadrats his 100 Mega Byte/s Plus other overheads Home TS stream.

Oops those damned professional DVB Business pirates looking to Encode and stream at low bit rates just so they can make profits,and put several channels on that 36.1 Mbit/s Or far less wireless carrier, is it wrong !

That's why you have BD as a premium delivery format.
Broadcast is still way behind in terms of quality.

Andrew

ckmox

11th January 2011, 19:09

The high level API is documented. It lets you "encode H.264" through Intel's terrible encoder. It is beyond useless to x264.

The low level API is not documented. It lets you do "motion search" or "encode a macroblock" or other parts of an H.264 encoder. It would be useful to x264. Many parts of it involve microcode, such as the motion search pattern. It is impossible to load microcode onto an Intel chip without secret software, tools, and probably private keys that only Intel has. This is to prevent viruses and such from abusing the ability to modify microcode.

ill add another speculation that if Intel expose the documentation for those low level API then Sandy Bridge Anti-Piracy Movie Streaming feature that i heard may become insecure and that will make Hollywood pissed off at Intel

so i guess hackers are the hope for this, they will reverse engineer this quick sync feature :devil:

popper

11th January 2011, 19:24

Is it just me that wonders what's the point of this?

You're buying a 250$ cpu, a 350$ motherboard and a 400$ video card just to use Quick Sync?

That's 1000$ to get faster Youtube quality videos? Who are they kidding....

your prices are off .... but
it seems the main purpose of the so called Intel Quick Sync ASIC is to keep Intel relevant and market share up in the post ARM video ASIC Encoding world perhaps.

this Freescale quad A9/NEON SIMD (along with solo/dual) being mass produced some time this year for instance.

http://www.linuxfordevices.com/c/a/News/Freescale-iMX-6/
"The video coprocessor, meanwhile, is said in the dual or quad versions to support 1080p60 H.264 video decode. It also provides for 720p60 encode of H.264, with "1080p planned," says Freescale. Separately, Freescale refers to a 1080p30 encode feature, but it is unclear whether this will be available in the initial release or is the aforementioned "planned" feature.

The i.MX 6's image processing unit (IPU) supports a whopping four displays via HDMI 1.4, and offers stereoscopic image sensor support for 3D imaging, says the company."

Arm and Linux being especially relevant when you consider that AMD's combined DRM/UVD Decode ASIC IS NOT Even officially recognised or even supported in Linux the Key ARM OS, never mind that they dont support any official or planed HW Encode, AMD market share will potentially fall perhaps by a lot it seems right now.

and with the Free ARM and Intel ASIC Encoders/Decoders included as standard and generic in all CPU's from now on, is AMD even relevant (given they even run assembly slower than Intel) to your next upgrade/extra device now ?.

Didée

11th January 2011, 19:41

i'm pretty sure you don't need a video card, you use the built-in gpu that is in the new intel chips. Core i5 starts at £136 and £70 for H67 board or £90 for a P67 board.
But then, those midrange SB's have HD2000 graphics with only 6 stream processors - opposed to the 12 stream processors in HD3000. With HD3000 only present in the more expensive "K" models (2500K, 2600K).

If the touting is "Quick Sync is double as fast as anything else", that of course refers to HD3000. If 12 shaders are "double as fast", what speed do you expect from only 6 shaders? :D

popper

11th January 2011, 20:05

But then, those midrange SB's have HD2000 graphics with only 6 stream processors - opposed to the 12 stream processors in HD3000. With HD3000 only present in the more expensive "K" models (2500K, 2600K).

If the touting is "Quick Sync is double as fast as anything else", that of course refers to HD3000. If 12 shaders are "double as fast", what speed do you expect from only 6 shaders? :D

well if your not going to pay the little bit extra for the K or just get an i7 then you can always over-clock it but you may NEED the K to get to 5GHz :D
http://www.overclock3d.net/reviews/cpu_mainboard/i7_2600k_i5_2500k_2300_1155_sandy_bridge_review/8

Didée

11th January 2011, 20:27

well if your not going to pay the little bit extra for the K or just get an i7 then you can always over-clock it but you may NEED the K to get to 5GHz :D
http://www.overclock3d.net/reviews/cpu_mainboard/i7_2600k_i5_2500k_2300_1155_sandy_bridge_review/8
An irrelevant statement that is.

To be able to overclock, you need a "K". To be able to use the iGPU, you (currently) need a board that doesn't allow overclocking. End of story.
(Bus clocking from 100 to 101~105 doesn't really count as "OC".)

Z68 probably will change the situation, but that's future. As of now, you need to pay for an OC CPU, with the regression that you cannot OC it. Only then you can use QuickSync. Hooray!

Besides, the applications featuring QuickSync supposely are all payware ... or not? :D

kieranrk

11th January 2011, 21:53

That's why you have BD as a premium delivery format.
Broadcast is still way behind in terms of quality.

Andrew

You say that but Premiere Germany used to broadcast films that were better quality than the Blu-Ray, mainly because VC-1 sucked.

King Kong was a classic example of this. Our friend jarod can provide you with comparison screenshots.

kolak

11th January 2011, 22:16

You say that but Premiere Germany used to broadcast films that were better quality than the Blu-Ray, mainly because VC-1 sucked.

King Kong was a classic example of this. Our friend jarod can provide you with comparison screenshots.

Old days- but not a case now. Even if you can find some examples average broadcast HD channel is no near average BD quality.

Andrew

kieranrk

11th January 2011, 22:33

Old days- but not a case now. Even if you can find some examples average broadcast HD channel is no near average BD quality.

Andrew

Assuming the sources were good I'd speculate some of the current VC-1 releases would be outclassed by 10-15mbit H.264 assuming the H.264 encoder was good.

kolak

11th January 2011, 22:54

Yes- but you're talking about rare cases. Almost all studios use AVC- only one VC1 :)

Andrew

kieranrk

11th January 2011, 22:55

Yes- but you're talking about rare cases. Almost all studios use AVC- only one VC1 :)

But nonetheless releases from that particular studio are major releases and considered by the public to be the "Gold Standard" for Blu-Ray.

mp3dom

11th January 2011, 22:55

You say that but Premiere Germany used to broadcast films that were better quality than the Blu-Ray, mainly because VC-1 sucked.

Too many variables here, for example the VC-1 implementation (PEP/PSE, MainConcept, other brand etc.), bitrate used, settings used, 1pass/2pass/3pass (if available) encoded, was the technician competent enough, etc, etc.

But nonetheless releases from that particular studio are major releases and considered by the public to be the "Gold Standard" for Blu-Ray.
Which is the studio? (Warner?). We already knows that the average public is not well trained about quality. Only a small amount can distinguish from a real good work and a quite good/discrete work. Just put an eye to some bluray reviews floating around the web. Unless completely destoyed work, most of the times all BD have 3/5 or 4/5 on the video side.

kolak

11th January 2011, 22:56

No - they are joke, not golden standard. Sony's current releases are decent, Criterion's and Disney's.

Andrew

mp3dom

11th January 2011, 23:05

Disney knows how to do the job, and above all, knows how to made proper restoration (excluding the tons of money spent for the restoration)

kieranrk

11th January 2011, 23:23

No - they are joke, not golden standard. Sony's current releases are decent, Criterion's and Disney's.

My point is the public aren't aware of that.

deadrats

12th January 2011, 01:02

If an H.264 is significantly worse than Ateme, Mainconcept, and x264 in all relevant use-cases, it is crap. As far as I can tell, the default Media SDK encoder is crap.

answer me one question and i will leave you alone:

how exactly do you know QS is crap? what metrics are you basing this on? considering SB has barely been out for a week and encoding apps that use it aren't even available to the general public yet, how can you come to such a conclusion with such certainty?

how about before you declare said technology as useless and a pile of <insert derogatory adjective du jour> you actually wait until you get some hardware and we have a chance to test it out thoroughly?

don't you think that might be a more prudent approach?

LoRd_MuldeR

12th January 2011, 01:29

answer me one question and i will leave you alone:

how exactly do you know QS is crap? what metrics are you basing this on? considering SB has barely been out for a week and encoding apps that use it aren't even available to the general public yet, how can you come to such a conclusion with such certainty?

how about before you declare said technology as useless and a pile of <insert derogatory adjective du jour> you actually wait until you get some hardware and we have a chance to test it out thoroughly?

don't you think that might be a more prudent approach?

(1) It doesn't matter what "encoding app" you use, because as soon as QuickSync is involved, all the encoding work is done by QuickSync and there's nothing left to do for the application. So we can expect the results from all "QuickSync" enabled apps look identical, except for application-specific pre-processing maybe.

(2) While we can't know for sure until there is a meaningful comparison available, experience shows that hardware encoders - and I'm referring to hardware encoders that are available to consumers, not about some fancy $10.000+ devices, produce quality that is unacceptable (for people who do care). So from previous experience we can expect that QuickSync won't be anywhere near the state-of-the-art software encoders. Even if QuickSync would produce significant better quality than those "CUDA" encoders (which doesn't mean much), it would still be significant worse than state-of-the-art software encoders. If QuickSync was able to play in the same league as state-of-the-art software encoders, this would mean such an enormous jump ahead compared to previous hardware encoders, that this is highly doubtful at least.

(3) The fact that significant parts of QuickSync are "fixed" in hardware and even the software components are "closed" means that there aren't any future improvements to be expected - at least not without replacing the hardware with the next generation. At the same time the state-of-the-art software encoders will continue to evolve, as they have done over the years...

deadrats

12th January 2011, 02:58

experience shows that hardware encoders - and I'm referring to hardware encoders that are available to consumers, not about some fancy $10.000+ devices, produce quality that is unacceptable

i submit to you that it may be time to reevaluate your (plural, as in everyone that worships at the alter of x264) perceptions of hardware based encoders. i downloaded the latest version of tmpg express (the japanese version, the english version isn't released yet) and after spending sometime figuring out how to use it (i don't speak japanese), i performed a number of test encodes: dvd to mp4 @ 720x480 16:9 @ 2.5 mb/s and a blu-ray rip of an adult BD: 1080p @ 15 mb/s to mp4 1080p @ 10 mb/s.

i did the tests using cbr, 128 kb/s aac, using the integrated x264 they licensed from DS and the included cuda encoder, all settings were left at default as i don't know what they say (remember, it's in japanese).

2 things jumped out at me from my tests:

1) the pegasys team has focused on high quality encodes, there was no perceptible differences between the cuda and the x264 encodes, in either test. from a quality perspective, both encoders did themselves proud.

2) the cuda encoder is so much faster than the x264 implementation that it boggles the mind. 2-3 times faster across the board.

the test hardware was a x4 620, 4 gigs ddr2 800mhz, gts 250 1gb, source and target hdd are 5400 rpm "ultra density" drives (benchmark faster than 10k raptors from a few years ago).

as soon as the english version is available i will conduct more extensive testing, but thus far, x264's case isn't that strong.