x264 and Intel's Media Engine / Sandy Bridge

[shon3i]

You are comparing a 4 Core CPU with a 6 Core CPU???
And even better...the 2500K does this with 95W power consumption...will be better not to tell how much the AMD CPU sucks right out of the line But i have roughly same speeds on Phenom X4 9550 which is 95W

[burfadel]

Bulldozer would have to be faster than the Core I, the original Core I was based on the Pentium 4 core, NOT on what we have come to known with the Core series starting with the Core 2.

The Bulldozer would have to be faster than the Core 2 CPU's, single, dual or quad core, otherwise it will be slower than the current phenoms. I think a lot of this anti-bulldozer speculation is just that, anti-bulldozer hence anti-AMD.

There is no way of truly knowing the end performance of a Bulldozer CPU until a final sample is available, and is plugged into an AM3+ motherboard (not yet available) using a release quality BIOS.

Even if someone does get their hands on a Bulldozer CPU to test it, there's no way of doing it without a proper AM3+ motherboard!

[cyberbeing]

It´s said bulldozer won´t even catch the performance of the first generation Core i series, which would be devastating.Bulldozer would have to be faster than the Core I, the original Core I was based on the Pentium 4 core, NOT on what we have come to known with the Core series starting with the Core 2.

burfadel, you are thinking of Core and Core 2 (http://en.wikipedia.org/wiki/Core_%28microarchitecture%29). The first generation Core i series Rodger mentioned would be Core i7, aka Nehalem (http://en.wikipedia.org/wiki/Nehalem_%28microarchitecture%29) (more specifically Bloomfield).

[Sharktooth]

AMD said bulldozer will have 50% more performance then the actual AMD CPU cores at the same clock speed. Also Bulldozer will be a speed demon (very long pipeline, etc...) and breaking the 4 Ghz barrier at stock settings wont be a problem... plus every CPU module will have 2 integer cores (4+4 int pipelines) and 2 128bit FP pipelines (that can be "grouped" when needed). So a 4 macro-cores (modules) CPU will be a real 8 cores CPU.
So, given those informations (admitting they're correct) IF a single core will have 50% more performance than Phenom II cores it will be on par if not better than Sandy Bridge and will have way more headroom for overclocking.

[mandarinka]

No, AMD said that the 16core server bulldozer will have 50% better throughput under full load (each core busy) compared to their current 12core Opteron. That's all she wrote.

Their server marketing guy also said publicly that performance per clock per core will overally be "higher" than with K10 core. He said that because given the architectural changes, there were fears that the performance would actually drop in this reagard. Naturaly, it doesn't sound like you can expect a big gains in IPC. It is not nehalem (or SB) like core with focus on single thread performance. It will have turbo, but so does Intel.

(Edit: I meant 50% better throughput, or 150% throughput of the old one. Clarified, sorry.)

[Sharktooth]

An AMD document obtained by Donanimhaber (http://www.donanimhaber.com/islemci/haberleri/AMD-8-cekirdekli-Bulldozer-islemcisi-Core-i7-950den-50-daha-hizli.htm) web-site claims that an eight-core Bulldozer microprocessor offers 50% higher performance compared to quad-core Intel Core i7-950 with HT microprocessor in games, rendering and multimedia applications. The web-sites does not specify which benchmarks were used. In fact, 50% higher performance versus a quad-core chip does not seem to be bad, especially in games that do not usually take advantage of multi-core chips.
8 cores means 4 modules or 4 macro-cores.

link... (http://www.xbitlabs.com/news/cpu/display/20110114134306_AMD_s_Bulldozer_Microprocessors_Expected_to_Offer_50_Higher_Performance_than_Core_i7_Phenom_II_Chips.html)

[Rodger]

AMD generally has been exagerating the true performance of products in the past. It´s what everybody selling a product does. So sorry, but it´s a little naive to believe that 1:1.
On the other hand those insider reports telling that bulldozer will be more or less powerless could be started from Intel. Intel didn´t always play fair with AMD in the past.
So I guess we´ll have to wait for trustworthy reports/tests from free sites.

[Sharktooth]

This could be trustworthy. Directly from an AMD employee: http://scarletwhore.com/?p=1407
that should be a 8 modules CPU coz a 4 modules CPU seems to be 50% faster than Core i7 950 on 3d rendering.
so all in all BD seems on track with performance, at least on par with sandy bridge if not better coz core i7 2600k is more or less 20% faster than i7 950 on 3d rendering (link (http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i7-2600k-i5-2500k-core-i3-2100-tested/17)) not considering the difference in clock speed in favour of i7 2600k.

[mandarinka]

I don't think those "leaked" slides and benches are to be trusted. They are at least partially suspicious.

(Also sorry about the mistake I made earlier, I meant 150% = +50%; not +150%.)

[CruNcher]

You are comparing a 4 Core CPU with a 6 Core CPU???
And even better...the 2500K does this with 95W power consumption...will be better not to tell how much the AMD CPU sucks right out of the line :rolleyes:

The 2600K with HT will easily knock down any AMD system. Bulldozer hopefully will be able to catch up but it seems and everything points to it...it will be a huge disappointment.

It consumes much less than that in real (TDP is always thermal characteristic not the actual consumption) :) Intel left a lot of headrom though you cant use that on the cheaper ones anymore like you could with the i-3 530 1056 in the start which was super value for the price @ 4 Ghz (guaranteed,and still is imho but old design old socket not future proof) :(
But yeah power consumption is much lower then the X6 and that even in non undervolted state you can save undervolted even more :D

I don't like CB test their are more targeted @ Gamers

http://www.silentpcreview.com/article1143-page5.html
http://www.xbitlabs.com/articles/cpu/display/core-i5-2400s_6.html

PS: My SB arrived (impressive without 24 express) though no Motherboard so i stuck till monday or early next week looking @ the parts ;)

Hehe i like that AMD vs Intel talks its funny that people yet don't understand that AMD wanted never to be on the top but exist a longside of Intel sure the Engineers try to be better but it's not bad if they fail for AMD they just position it differently and i still doubt we see Buldozzer being so much better then many hypothesis off ;)
To much time has past intel released 2 Generations and placed Atom into the market smaller die size research faster Production if @ all it will beat SB by a small margin though that will be fast gained again by Ivy Bridge, the biggest advantage though like in Fusion will be the GPU part and obviously Price (Power Consumption has yet to be seen).
But as many realized Intel is slowly improving @ the GPU level, though their whole driver stack and Video Quality (algorithms) are still not up to the Quality of ATI & Nvidia (actually very few test's and mostly only subjective ones exist) also from a Cross Platform POV :P in that matter Quick Sync encoding is interesting because Fusion is not out yet which will have the same benefits as SB for Encoding (though using ATI/AMDs Encoder which is known to be not as good as Nvidias (especially inside ION which is crazy as its less powerfull yet per SM count) ;).
But many of these things are much more complex to test then any of the reviews i saw so far doing they just go @ the tip of it and make a conclusion from some ISVs 3rd party application (Annandtech showed nicely how to not do it drawing a conclusion into the wild that Nvidias Encoding is of the lowest Quality) :P

[Rodger]

I know :p
http://i55.tinypic.com/1ex35l.jpg

[CruNcher]

Hehe interesting Asus uses the same Nuvoton (Winbond) IC like Asrock or Intel

PS: If you can trust the current rumors MSI licensed Lucidlogix Virtu for their H67 boards

[Rodger]

[QUOTE=CruNcher;1475093PS: If you can trust the current rumors MSI licensed Lucidlogix Virtu for their H67 boards[/QUOTE]

That´s good news, that this idea/technique will be used.
´Cause it sounds good and is surely step in the right direction.

Though it´s kinda step back in time. When we used 3Dfx graphics cards as addon card ONLY for 3D. And your ATI Mach64 did the 2D job :devil:

[CruNcher]

That´s good news, that this idea/technique will be used.
´Cause it sounds good and is surely step in the right direction.

Though it´s kinda step back in time. When we used 3Dfx graphics cards as addon card ONLY for 3D. And your ATI Mach64 did the 2D job :devil:

Hehe sure but the difference is you have 2 DSPs now to use additionally which would mean decoding 5 HD streams simultaneously @ once :D :) and that in the Consumer space price range :D and Live Encoding and all that with a relatively low Power Consumption :)
With the Discrete part turned of (like with Optimus) on non usage but still would be able to accellerate HTML5 for example with very nice Speed and Power Consumption
I mean something @ the Price Range of the Boxee box @ 200$ looks very overpriced with the capabilities of a SB system in the Hand even with the IGP only :).
Fusion though will be better but not give you that CPU power SB delivers and depending on the usage the power difference will be marginal but much more versatile usage possibilities on SB :) (though nothing of this is interesting for Gamers @ least not as long as a new Game console is being build based on SB which would be very efficient, in the consumption range of the Xbox360 but more CPU Power)
Nvidia has to really hurry up with their Project Denver or we gonna see Intel be first their on x86 ;)
Also we shouldn't forget we just in the beginning of CPU+GPU fusions SOC like Desktop x86, so a lot ahead, also from a Consumer POV its a good thing as Hollywood is going to support SB for their 1080p on Cinema release chain because of the strong TPM integration on Win7 and SB :)
So its the first time we gonna see the future of Secure Digital Distribution away from Media like Blu-Ray supported by major Hollywood Studios and carefully researched over several years, though only available to SB + Vista/Win7 users for now :)
Nothing about AMD though if they gonna bring that Hollywood Distro support to their users i guess though we also will see it in the upcoming Buldozzer AM3+ Platform as they can't allow themselves to miss this future train.
Theoretically many older systems and Mainboards should be ready too as subset of TPM (for this Distro usage) was integrated since some time now directly into Chipsets it only needs Vista/Win7 to be utilized :)
Though without the On Demand Hardware AES decryption inside SB and most probably Buldozzer on those old systems it would be to taxing, no good user experience for realtime 1080p high bitrate decryption on older Systems.

Btw Rodger your Overclock result is per se a Guranteed one (inside in the calculated TDP) for every Chip (Board) interesting it gets above 4.6 upto 5 ;)

Finally one of those Commercial Media sites in this case THG goes deeper into the Hardware Encoders though it only tackles the top
http://www.tomshardware.com/reviews/asrock-e350m1-amd-brazos-zacate-apu,2840-6.html
as expected Hardware Decode usage doesn't result in any difference for H.264, unfortunately no Sandy Bridge sample results :(

[kolak]

http://tmpgenc.pegasys-inc.com/en/product/tvmw5_new.html

TMPEG 5 is out- with CUDA, x264 engine and QuickSync.


Andrew

[laserfan]

http://tmpgenc.pegasys-inc.com/en/product/tvmw5_new.html

TMPEG 5 is out- with CUDA, x264 engine and QuickSync.It is remarkable how far this guy/his company has come from tmpgenc beta12a back in 1999!!! :eek:

[CruNcher]

It is remarkable how far this guy/his company has come from tmpgenc beta12a back in 1999!!! :eek:

Hehe yeah they become another ISV though you dont hear about them alot the last big fuzz for them was their DivX Deals and obviously x264.
Im sure also in terms of Encoding they are far more experienced then other ISVs and so the product hopefully the encoder and if its using default profiles will be tweaked accordingly.
If you ask a pole of people which companies they recognize on the US Market

Arcsoft
Cyberlink
InterVideo (now Corel)
Nero
Roxio
Pegasys Inc

Im quiet sure the less will ever have heard about Pegasys Inc, surprisingly a lot will have heard about Arcsoft.

PS: My H67 board arrived,assembling now :)

[Rodger]

don´t forget to exchange it as soon as the working chipset revision is available....about mid April has been said.

[CruNcher]

Sorry but it will still take some time issue
http://software.intel.com/en-us/forums/showthread.php?t=68495&o=a&s=lr
i need to move to Win7, that is really the most user unfriendly aspect imho off Quick Sync, it will force you to Vista/7 neither Nvidia nor AMD do restrict their SDKs that way :(
The Same with Intels OpenCL SDK no XP support anymore
Also i have a hard time getting DXVA1 working on XP too :(
Though this is only officially, but i highly doubt it looks unoficialy the same with ISVs like Cyberlink and Arcsoft having a pretty heavy user base in Asia and their Windows XP has still a much higher Market Share then Vista/7, it would be pretty weak if you cant provide support for it.


Crys out loud so Intel Marketing guys hear it:

http://img830.imageshack.us/img830/8058/dxva1mpeg2only.png

What most Info Applications show

http://img52.imageshack.us/img52/1923/infohd2000.png

Only 1 shines

http://img51.imageshack.us/img51/3118/sisoftihd2000.png

also this is a crazy restriction (why does it need that for quick sync it seems much easier to solve, it sounds like a protected media path restriction not being able to reroute the result only to the connected device Blu-Ray anyone ?, then it also would slowly make sense why XP isn't supported anymore ;) )

http://img153.imageshack.us/img153/6538/displayrequirementsimsd.png

Yeah lets manually switch ports like in the 50s again ;)

[mariush]

Cruncher, please use Alt+Print Screen next time and post the pictures at the normal size, I can barely understand what's written there.

[iwod]

Is DS still around? He hasn't been replying a lot lately.........

[Sharktooth]

yes, i saw he replying in other threads.

EDIT: he probably doesnt reply coz there is NOTHING to add.

[iwod]

I was wondering, if FMA doesn't help, Sandy Bridge 's AVX wont help, would Ivy Bridge 's AVX addition help?
Or will we literally have to make an Hardware version of x264 to gain any more speed?

[Sharktooth]

i dont know of any AVX additions to IB. link?

[LoRd_MuldeR]

I was wondering, if FMA doesn't help, Sandy Bridge 's AVX wont help, would Ivy Bridge 's AVX addition help?

AFAIK what is currently being developed as "Ivy Bridge" is simply the "Sandy Bridge" architecture shrunken to 22 nm (Sand Bridge is 32 nm).

So unless AVX will get a complete overhaul for "Ivy Bridge", it will remain Floating-Point only and thus will be as useless for x264 as it is on the "Sandy Bridge".

(Except for the 3 operator syntax of AVX, which according to the developers can help a tiny bit)

[Sharktooth]

i wonder why intel continues to develop the FP SIMD and leave INT SIMD untouched...

[Manao]

AFAIK what is currently being developed as "Ivy Bridge" is simply the "Sandy Bridge" architecture shrunken to 22 nm (Sand Bridge is 32 nm).

So unless AVX will get a complete overhaul for "Ivy Bridge", it will remain Floating-Point only and thus will be as useless for x264 as it is on the "Sandy Bridge".That doesn't really mean anything. Penryn was "just" a Conroe shrunken to 45nm, but it still has SSE 4.1 and faster SIMD instructions alongside.

[Rodger]

I just realized that a GTX460 is NOT FAST ENOUGH to feed my Sandy Bridge ;)
I´m using DGindexNV and when the GTX460 has to upsize and deinterlace from cropped 544*576 (MTV) to 576p
DGSource("MTV Hits 05-02-2011_03_cut_07.dgi", deinterlace=1, resize_w=720, resize_h=576)
I need to overclock the GTX460 to the max to gain the most power out of my sandy bridge.
It´s often 80fps to 120fps with x264-Setting like
--level 4.1 --nf --direct auto --subme 5 --no-mbtree --trellis 1 --me umh --vbv-bufsize 6000 --vbv-maxrate 6000 --nal-hrd "vbr" --sar 16:11

/EDIT: Since the CPU load is now almost @100% when encoding I can tell that it needs to OC the GTX460 to 800/1600/2060 to get that...WOW ;)

[burfadel]

--subme 5 is quite low, and --no-mbtree and --trellis 1 alos favour more speed than quality.

Try setting --subme 10, omit --no-mbtree, and set trellis to 2. Those settings aren't unrealistic, and the speed of the gtx460 will be less of an issue.

[Rodger]

You´d bomb down an apple with with an atom bomb?
Those are MTV clips 544*576 interlaced and a max bitrate of 3,5Mbit!!!

/edit: I know the bitrate of 2mbit is already overkill. But some vids really benefit from that bitrate.

/EDIT2:
That "--no-mbtree" setting...isn´t that used to stay compliant to Blu-Ray/AVCHD ???
I thought so.

[Didée]

BTW, @Rodger ... are you aware that all (american) music clips on MTV are run through a normconversion box, thus are fieldblended, and that "standard" deinterlacing is about the worst thing you can only do in that case.

(It's OT for this thread, but when I see ppl are doing technical illness, it should be mentioned at least.)

[Rodger]

No I´m not! It´s "MTV Hits" mostly if that matters to you (UK television as much as I know) and normconversion here and there....more or less ALL CLIPS shown there show heavy combing when movement is done.
I tried several methods of deinterlacing in the past and the result of GTX460 with Setting=1 is pretty much among THE BEST I´ve seen! I don´t want the best quality for each clip but a reasonable quality for all music clip sources.

In case you have better input to me, tell me!

[Didée]

Uh, better open a thread in the Avisynth forum. It's not so trivial that everything could be said in two sentences. And it's definetly not related to Sandy Bridge. ;)

[Rodger]

PM me if you like to. You can use your mother language too ;)

[Jumpyshoes]

I am working on an AVX patch for x264, but I only have access to a Sandy Bridge with cygwin. Linux would be a much better development environment. Is anyone willing to give me ssh access to a Linux Sandy Bridge machine?

The current patch is here: https://github.com/DarkShikari/x264-devel/commit/7b98eaa272942971d5085a8b3b77aad1db35435f

[kolak]

I think this is quite new:

http://www.mainconcept.com/products/partner-products/intel/h264avc-encoder-sdk.html


Andrew

[TPoise]

Just read this 20-page rant and I have to say, as an end-user I'm quite dissappointed. (I know, most of you could care less about end-users).

Basically this starts off as an idea for x264 to incorporate some of the Intel Quick Sync ASIC features into x264, and I even saw the other thread from Doom9+1 from the Intel guy that said he wanted to help. It went sort of like this:

Intel Guy: Hi, we want to help!
x264 guy: Why didn't you include us in your chip design?
Intel Guy: Hi, we want to help! I'm an experienced hardware guy that has done several SIMD features. We want to help!
x264 guy: SSE4.1 was useless, it brought me a lot of grief.
x264 guy: meet me on IRC to discuss.
Intel Guy: Hi, we want to help!

I'm not flaming at anybody, but if I was in control of an open source software product, and a CPU manufacturer came my way to offer help in taking advantage of their new hardware features to dramatically increase the speed at which my software executed, I would have been more than delighted. I know, Intel/AMD haven't been helpful in the past, but you have to say that the French guy certainly went out of his way to help the x264 community. The response that was given to the Intel guy made me ashamed to be part of this community, that is the exact kind of arrogance that precedes the downfall of most other products (Firefox comes to mind). Has it occurred to you, Dark Shikari, that the reason they didn't include you on the chip design was because of NDA reasons, so you wouldn't go screaming to AMD about this upcoming functionality? Perhaps they didn't include you because of your prior bias on hardware-assisted x264 encoding?

As mostly an end-user of the x264 product, quality and encoding speeds are my favorite reasons why I used x264, over some other $100 consumer product. However, as source files get larger (Blu-Ray, over-the-air HD streams, etc.) it is tough to keep up with a software-only approach for these large files within a reasonable amount of time. With the added heat/power required for modern day CPUs, a hardware-assisted approach on the surface seems viable. Why can't I, as an end-user, make a choice between high-quality (slower) encodes versus a super-fast QuickSync encode that may not be up to par quality-wise versus the high-quality encode, but is twice as fast at similar bitrates? AnandTech's article went into this, and in their two sample pictures the x86 versus the QuickSync encodes were similar enough to me to choose the QuickSync encode that saves me half the time. Sure, if I want to archive my wedding blu-ray, I would get the highest possible quality, but if I simply want to rip a Blu-Ray for my own "fair use" purposes to watch on my laptop while traveling, you have to admit, QuickSync is incredibly compelling. TomsHardware has benchmarks where QuickSync is 6x as fast as an x86 encode (albeit with a commercial encoder).

It is a shame that we had to go through 20 pages of non-sense to get here. I hope the Intel open source developers continue to work on a patch that will bring QS support to x264 and/or continue to help support commercial vendors with low-level access to QS technology. I dont know deadrats, or nor do I agree with his all of his arguments, but I too feel that the future of encoding is in hardware-assisted features, whether thats CUDA/APP or QuickSync or something else, I don't know. But both Intel/AMD are heavily marketing their hardware-video improvements to end-users, which is why I made the choice to get a Sandy Bridge Core i7. I think it is quite safe to say that QS hardware logic will most likely be included in the next several iterations of Intel chips, possibly with an AMD version as well. As this happens, x264 will be known as the free encoder thats twice as slow with near similar results as other commercial encoders.

And after 20-pages, I'm not even sure what the argument is against using QuickSync, is it because lack of documentation to the hardware ISA? Is it poor encoding results out of the base Intel encoder? Is it because DS feels offended for not being included in on the chip design?

Again, I know all of you could care less about end-users like me, but x264 has pushed me to use a commercial app over their open-source product. I suspect many others will make that choice in a similar direction.

[Firebird]

I even saw the other thread from Doom9+1 from the Intel guy that said he wanted to help
This "Intel guy" disappeared after Dark Shikari asked him about low level QuickSync API.

[IgorC]

Now there are thousand of review about Sandy Bridge and its super fast hardware acceleration encoding. But nobody has asked: '''And quality?''.

[Dark Shikari]

As this happens, x264 will be known as the free encoder thats twice as slow with near similar results as other commercial encoders.MSU's test showed QuickSync giving, at best, similar results to x264's "superfast" preset in both speed and quality. I can see QuickSync fitting into the niche of "applications that don't need decent compression, only performance", but ffmpeg mpeg-2 can do that too.And after 20-pages, I'm not even sure what the argument is against using QuickSync, is it because lack of documentation to the hardware ISA? Is it poor encoding results out of the base Intel encoder? Is it because DS feels offended for not being included in on the chip design?Arguably, because you haven't submitted a patch yet: there's nothing stopping anyone from adding Sandy Bridge hardware support to libx264. I haven't blocked any attempts at this, and I don't plan to. I don't plan to write Sandy Bridge hardware support for x264, but I'm not the only developer, and it's an open source project.

Since the original Intel failure, I have learned quite a bit more about the lower-level details, and I'd quite love to explain more, but unfortunately I am now deep into NDA territory. If this means people are going to blame x264 for QuickSync's failings, well, unfortunately there's not much I can legally do about it anymore.

[TPoise]

Now there are thousand of review about Sandy Bridge and its super fast hardware acceleration encoding. But nobody has asked: '''And quality?''.

Anandtech's article went over this. The quality was comparable to the x86 software encode according to their random blind test with their other three editors. Of course this is only the opinion of three people. I looked at the images and saw no discernible quality issues. And of course you could always stick with software-only if quality is the #1 issue to you. Again, being twice as fast at the same bit rate has to factor into the use of QuickSync somewhere.

[Dark Shikari]

Anandtech's article went over this. The quality was comparable to the x86 software encode according to their random blind test with their other three editors.If you set the bitrate sufficiently high, the quality difference between encoders becomes negligible. This fact can be used to demonstrate absurdities, such as "x264 isn't significantly better than MPEG-2". See this post (http://x264dev.multimedia.cx/archives/472) for a much more in-depth analysis of how to cheat on encoder comparisons.Again, being twice as fast at the same bit rate has to factor into the use of QuickSync somewhere.Twice as fast at what settings? You cannot validly claim "X is faster than Y" if you told Y to go slowly.

[TPoise]

If you set the bitrate sufficiently high, the quality difference between encoders becomes negligible

That's the whole point. So if the quality differences are consistently negligible, why wouldn't you favor the encoder that is magnitudes faster?

Twice as fast at what settings? You cannot validly claim "X is faster than Y" if you told Y to go slowly.

Please refer to the testing methodology of the AnandTech article on the first page of this thread. You may also refer to the TomsHardware benchmark comparisons (http://www.tomshardware.com/reviews/sandy-bridge-core-i7-2600k-core-i5-2500k,2833-5.html). Although quality isn't discussed with that article you can see a 3x speed-up against CUDA-based encodes, and 6x against software-only encodes using a commercial product, MediaExpresso. Another TomsHardware benchmark of Quick Sync against the AMD Llano APU can be found here (http://www.tomshardware.com/reviews/a8-3500m-llano-apu,2959-20.html). Outside of the obvious hardware differences, we're talking 46 seconds versus 3:13 minutes.

Not trying to begin another quality vs. performance argument, so I'll just leave it at that to let you deal with the facts on your own. Again, it doesn't matter whatever x264 decides to do or not to do, my opinion as an end-user matters very little to the x264 team.

[IgorC]

Intel's Quick Sync isn't any better or faster than x264

http://compression.ru/video/codec_comparison/h264_2011/
http://compression.ru/video/codec_comparison/h264_2011/mpeg-4_avc_h264_video_codecs_comparison.pdf


Please, do not refer us to hardware guys. They have no clue what quality of the video stands for. Doom9's forum is the right place to talk about this.

[TPoise]

Intel's Quick Sync isn't any better or faster than x264

http://compression.ru/video/codec_comparison/h264_2011/
http://compression.ru/video/codec_comparison/h264_2011/mpeg-4_avc_h264_video_codecs_comparison.pdf



Thank you for these links. The conclusion presented from the PDF state a viable case that shows the Intel Transcoder (using Quick Sync) is in the same league as x264 as far as both speed and quality. But back to the original point of this thread, wouldn't a customized version of x264 using low-level Quick Sync optimizations be (many times) faster than the software-only encoding?

Perhaps even my non-technical understanding of how the technology works may not allow for this. I was sort of thinking that QS is like SSE or MMX, where certain low-level operations are available to run over the "Quick Sync" hardware logic instead of the standard x86 execution path.

[LoRd_MuldeR]

Thank you for these links. The conclusion presented from the PDF state a viable case that shows the Intel Transcoder (using´) is in the same league as x264 as far as both speed and quality. But back to the original point of this thread, wouldn't a customized version of x264 using low-level Quick Sync optimizations be (many times) faster than the software-only encoding?

As long as Intel does not expose an API to use low-level Quick Sync functions for use in third-party encoders, this question is pointless...

Perhaps even my non-technical understanding of how the technology works may not allow for this. I was sort of thinking that QS is like SSE or MMX, where certain low-level operations are available to run over the "Quick Sync" hardware logic instead of the standard x86 execution path.

It apparently is not. As far as I understand, it is partly software and partly hardware. And the hardware part isn't available for other encoders.

So from a developers point of few, Quick Sync is more like a "black box" that implements a complete encoder and which you would use instead of other encoders (like libx264).

[nurbs]

The Anandtech comparison he mentions is probably this one: http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i7-2600k-i5-2500k-core-i3-2100-tested/9

They don't use x264, but Arcsoft Media Converter 7 (Mainconcept?). No mention of settings, only profile (main) and bitrates.

I've got 2 of the three movies they tested. I did them with --crf 21 --tune film --preset veryslow --bframes 3 at 1280*yyy. Both of them have two stereo audio tracks. Dark Knight came out at 2.4 GB and Casino Royale at 1.41 GB. Both of the movies are about 150 minutes long and the audio is probably around 300 kbps in total. I'm too lazy to do the math, but the bitrates Anandtech used are definitely on the high end of what is required for good quality, even with faster settings.

[CruNcher]

In the early version Arcsoft MC7 used for Nvidia a modified X264 with GPU support, they also have a Encoder based on CUDA (it looks like their own Research work) but it's weak though runs full offloaded, to what i could see it seems they switch to that one on weaker systems most probably Atom/ION :)

Not sure though what they do now they most probably added a OpenCL Encoder too for ATI and most probably fixed some bugs for the X264 GPU one (it has some nasty chroma issues @ low bitrate very high quantization above 30), most tests show the X264 GPU Encoder results (when Nvidia Cards are tested, though in a rather save bitrate zone the bugs doesn't shine trough as much their) :)
They practicaly implement every API they get their hands on and some of their own R&D stuff (though mostly in a buggy state)

[hajj_3]

Since the original Intel failure, I have learned quite a bit more about the lower-level details, and I'd quite love to explain more, but unfortunately I am now deep into NDA territory. If this means people are going to blame x264 for QuickSync's failings, well, unfortunately there's not much I can legally do about it anymore.

does that mean you are now technically able to allow some parts of x264 encoding to be done by quicksync? If so is this support going to be added?

Has AMD contacted you about making llano or bulldozer work well with x264 in a similar way to quicksync?

[Dark Shikari]

does that mean you are now technically able to allow some parts of x264 encoding to be done by quicksync? If so is this support going to be added?Maybe yes, probably not. There are some pretty devastating technical limitations.

Has AMD contacted you about making llano or bulldozer work well with x264 in a similar way to quicksync?AMD has never contacted anyone on the x264 team for any reason ever, nor have I heard of plans to add encoding hardware to any AMD CPU.