x264 and Intel's Media Engine / Sandy Bridge

[deadrats]

Originally Posted by imcold

fevh264. Coding style is similar, but compared to x264 it's just a toy. As for relative performance, from my exp.: mpeg1-like decoder (with some assembly) translated from pascal to c was ~5-10% faster; gcc vs. Freepascal/fpc, 32bits. In case of x264, it would be worse (fpc can't inline assembly funcs etc.).

cool, thanks for the link, i know it sounds silly but back when i was in high school we were taught basic, then fortran, then pascal and even in college the first few comp sci classes were in pascal, including the object oriented ones, then you were taught c. now you go straight to c++, it's probably better, but there were things i liked about fortran and pascal.

[7oby]

Originally Posted by Dark Shikari

AFAIK, the Sandy Bridge shipping in January will not have the transcoding engine. You're going to be waiting quite a while.

I justed looked over to Anands latest review regarding the transcoding engine. Quite interesting (also in comparision to CUDA):
http://www.anandtech.com/show/4083/t...-2100-tested/9

And it seems to be shipping. Can you elaborate on the status or future of the work with Francois Piednoel (intel)? I read the interesting irc-log.

[Dark Shikari]

Originally Posted by 7oby

I justed looked over to Anands latest review regarding the transcoding engine. Quite interesting (also in comparision to CUDA):
http://www.anandtech.com/show/4083/t...-2100-tested/9

And it seems to be shipping. Can you elaborate on the status or future of the work with Francois Piednoel (intel)? I read the interesting irc-log.

There is no status. Nothing has happened. I haven't talked to him in weeks.

He was the one who told me that the Media Engine wasn't going to be in the first SB release. Apparently he was wrong about that, too.

I'm sick of dealing with incompetent companies like this. Now we have yet another fast-but-terrible hardware encoder -- for free on a popular CPU, nonetheless -- that helps nobody, instead of an accelerated x264.

[ajp_anton]

Originally Posted by Dark Shikari

"2 128-bit ALUs per core" doesn't seem to be a very big selling point to me, considering that the i7 had 3!

Well Bulldozer cores aren't meant to be comparable to the cores in other CPUs. The "cores" are much smaller, and a similarly sized and priced CPU would have twice the number of cores in BD.
Also I don't know if this helps anything here, but I read that BD is designed to be a high frequency (netburst) type CPU.

[hajj_3]

would be nice if intel created parts of their next cpu that hardware accelerate x264 encoding, that would literally be a dream come true, i can't even imagine how quick it could be. Now that x264 has a commercial license available may intel might think about doing this.

[LoRd_MuldeR]

Originally Posted by hajj_3

would be nice if intel created parts of their next cpu that hardware accelerate x264 encoding, that would literally be a dream come true, i can't even imagine how quick it could be. Now that x264 has a commercial license available may intel might think about doing this.

Apparently they missed their big chance to do so with Sandy Bridge by making the new AVX extension FP-only

[hajj_3]

ivy bridge the 22nm version of sandy bridge is out in 2H 2010, lets hope they add support then. Maybe USB3, esata 6gbps, pci-e 3.0 and lightpeak might be in ivy bridge. Esata 6gbps hasn't been ratified yet btw, but is due to soon. I won't be upgrading until desktops with all these technologies are available at a low price.

[kosmonaut]

Originally Posted by Dark Shikari

There is no status. Nothing has happened. I haven't talked to him in weeks.

He was the one who told me that the Media Engine wasn't going to be in the first SB release. Apparently he was wrong about that, too.

I'm sick of dealing with incompetent companies like this. Now we have yet another fast-but-terrible hardware encoder -- for free on a popular CPU, nonetheless -- that helps nobody, instead of an accelerated x264.

And now with bonus DRM!

[Sharktooth]

sarcasm...

[aegisofrime]

Maybe you guys can approach AMD this time. Enough hardware sites use x264 as part of their benchmark package to make cooperation with x264 an attractive marketing strategy.

Not forgetting all the people out there who use x264 too.

[kieranrk]

Originally Posted by aegisofrime

Maybe you guys can approach AMD this time. Enough hardware sites use x264 as part of their benchmark package to make cooperation with x264 an attractive marketing strategy.

I've been there...done that. Request went to the head of developer relations at AMD and was ignored.

[aegisofrime]

Originally Posted by kieranrk

I've been there...done that. Request went to the head of developer relations at AMD and was ignored.

Gah >.<

Well, their own loss then. :/

[wlee15]

Originally Posted by Dark Shikari

The Core 2 and Core i7 have three arithmetic units: execution units 0, 1, and 5. On the Core i7, 0 and 5 can do SIMD add/sub/shuffle and 1 can do SIMD multiplies. All three can do bitmath and all three can do most scalar operations. I omitted some things they can do (float, etc) that I don't care about for simplicity. Check Agner's site for more details.

Download Cygwin or MinGW, use make. You won't build x264 without a configure/make script combo.

I do believe that each Bulldozer floating point/vector cluster has 4 128-bit ALU. Interestingly enough 2 of those units are dedicated SIMD integer units while another is capable of executing IMAC instructions from AMD new XOP instruction set.

[deadrats]

Originally Posted by Dark Shikari

I'm sick of dealing with incompetent companies like this. Now we have yet another fast-but-terrible hardware encoder -- for free on a popular CPU, nonetheless -- that helps nobody, instead of an accelerated x264.

2 things come to mind:

1) in what way is the fixed function hardware encoder/decoder "terrible"?

the screen shots in the anandtech review are practically indistinguishable from the software encoded screenshots.

2) how is it that x264 can't be modified to benefit from quick sync? i downloaded the intel media sdk and looked through the documentation and it seems intel has made it fairly easy (much easier than via cuda, that's for sure) to access various built in functions, including SAD (which i know you tried to get working via cuda as far back as 2007).

then there's this reality, and i hope this doesn't come off as me trolling or trying to start something:

let's assume that x264, in it's present form, at low bit rates offers much better image quality than the fixed function quick sync version, who cares? you have acknowledged in other posts that once the bit rate is raised the quality difference between encoders starts disappearing.

when you consider that a single frame of 1080p is composed of over 2 million pixels, at a frame rate of 30fps that's 60 million pixels, it's absurd to encode at bit rates of 10 mb/s, which works out to 6 pixels per bit, something many x264 users seem to be fond of doing. there's a reason that movie studios encode their blu-rays at 30+ mb/s.

as i said, just want to give you the perspective of an end user, i would much rather use the quick sync encoder, raise the bit rate and encode 1080p video at 15 mb/s at almost 100 fps than use x264, use half the bit rate and only encode at 15-20 fps (depending on source) using the ultra fast preset on my x4 620.

i know you're proud of your encoder and i know you have put a lot of work into getting it to the point it is now, but even a blind man can see that software based encoding is a dinosaur, only the most ardent masochist that has a fetish for bit rate starving encodes is going to choose x264 (or even the new xvid rc1 release, a much improved version) and sit through encode times anywhere between 4 and 10 times slower than quick sync.

most will probably realize that a 1.5tb hdd costs less than $100 and that blu-rays can hold 25-50 gigs of data and say "f" it, i'll just crank up the bit rate a bit and be done with my transcode in a fraction of the time.

i strongly suggest that if x264 can't be made to benefit from quick sync that perhaps you rethink your approach and maybe start a new h264 encoder from scratch, using the things you have learned coding x264 to create a quick sync accelerated high quality version of x264.

i know i'm probably going to get flamed for this but mark my words, software based encoders will soon be a thing of the past, intel and amd have cross licensing agreements, after a short amount of time each company can use the other's technology.

within a year amd cpu's will feature amd branded quick sync, by then most major video editing apps should support the technology (cyberlink, arcsoft, adobe, corel and movavi are already on board and there's no doubt pegasys will jump on the bandwagon as well).

stop being obstinate, stop with the "useless pile of" (insert adjective du jour), stop with the "it's useless for x264", stop with the attitude that "my encoder is the greatest and everything else is a pile of crap" and start finding a way to give the end users what they want, you're a professional programmer damn it, program!

[deadrats]

Originally Posted by kosmonaut

And now with bonus DRM!

what "bonus" drm are you talking about?

the content you create using quick sync doesn't automatically have drm, but a content creator using a custom app can encode drm protected content using quick sync.

this is no different than any current app that targets the professional market, i can create a drm protected h264 video right now using microsoft's expression encoder pro (which by the way is a very high quality h264 encoder), you can create drm protected audio streams, vc-1 streams, there's nothing insidious about quick sync, intel is just making sure that a feature the professional market wants is present on their cpu.

if you don't like it, stick with x264, be happy with frame rates of 20 fps for high bit rate hi def content and stop spreading FUD.

[ranpha]

Originally Posted by deadrats

when you consider that a single frame of 1080p is composed of over 2 million pixels, at a frame rate of 30fps that's 60 million pixels, it's absurd to encode at bit rates of 10 mb/s, which works out to 6 pixels per bit, something many x264 users seem to be fond of doing. there's a reason that movie studios encode their blu-rays at 30+ mb/s.

Why encode at 30Mb+ when you can encode at 10Mb/s and still retain the same quality? Do you like your Blu-ray backups large?

[kolak]

Originally Posted by aegisofrime

Gah >.<

Well, their own loss then. :/

Do you think that it's so easy to go to eg. AMD with an offer
You can have the best product, but without knowing correct person you will achieve nothing There are so many very good solutions which died and so many crap one which got implemented- very common and normal.


Andrew

[deadrats]

Originally Posted by ranpha

Why encode at 30Mb+ when you can encode at 10Mb/s and still retain the same quality? Do you like your Blu-ray backups large?

this is an absurd question, if you could achieve the same quality at 10 mb/s using x264 as you can with something like cce-hd or blu-code at 30+ mb/s; do you really think that the professional movie studios would spend 40-70+ grand on a per seat license to acquire those encoders? don't you think they would try and save a butt load of dough and use the legally free open source alternative?

furthermore, a blu-ray disk holds up to 25-50 gigs of data and as i said a 1.5tb hdd costs under $100 (i currently have 3 of them), you feel like saving the space for a rainy day?

but perhaps the biggest reason for not bit rate starving an encode is the fact that the math says it's a stupid thing to do:

a 1920x1080p frame has 2073600 pixels, at 30 frames per second that works out to 62208000 pixels every second. at a bit rate of 10 million bits per second (10 mb/s) that's means every bit has to represent 6.2 pixels.

if i remember correctly, with uncompressed video, each pixel is 8 bits, that means that you are using less than 1/48th the bit rate as what the uncompressed source would be.

that's just flat out ridiculous and even more ridiculous is the thought that somehow any encoder at 10 mb/s is going to match the quality of another encoder at 30 mb/s.

download the demo for main concept's cuda powered encoder and run 2 test encodes, at sane bit rates, say 15 mb/s for 1080p, one with said gpu powered encoder and one with x264, i defy anyone to tell me which is which without looking at the water mark main concept places on the video in the demo version.

x264 quickly loses it's quality advantage once you let the bit rate fly.

[poisondeathray]

Originally Posted by deadrats

download the demo for main concept's cuda powered encoder and run 2 test encodes, at sane bit rates, say 15 mb/s for 1080p, one with said gpu powered encoder and one with x264, i defy anyone to tell me which is which without looking at the water mark main concept places on the video in the demo version.

x264 quickly loses it's quality advantage once you let the bit rate fly.

It also depends on the content.

You're probably testing on low quality stuff (or think youtube looks great.)

For example, go look at the park run sequence (or the original SGI film scan is available too), there is a night/day difference between encoders even at 30Mb/s (regular viewing, not even pixel peeping or frame by frame examination) , even with mainconcepts' full featured software SDK encoder (not the gimped versions or even the cuda version)

These GPU encoders have a place, but so far they are not suitable for any type of high quality encoding. They are passable for low quality devices and definitely encode faster on things like dual core laptops than software based x264

[deadrats]

@savage:

re #1: while the anandtech article didn't test with x264 they did provide uncompressed png's for comparison and quite frankly the quick sync encodes can hardly be called "horrible" (unless you have an anti-intel, pro "your own personal baby that you coded" agenda.

re #2: i don't care how much whiskey you drink, you will never see any test in which x264 encodes a 15 mb/s 1080p video at anything approaching 100fps. the commonly used x264 hd benchmark which takes a 720p mpeg-2 and transcodes it to a 4 mb/s 720p x264 only hits about 40fps, quick sync in a similar test hits 200fps.

re #3: there's nothing that says an app has to use said drm, it's just available so that people can create apps that allow content creators to protect their content. this is nothing new, drm has been around for years, m$ and apple both have offered drm in their encoding apps for years, intel has just decided to to the same with their offering. the video/audio streams don't automatically include drm just because they are encoded via quick sync.

re #4: the proof is in the pudding, try a test encode at blu-ray bit rates using x264 and mc's cuda powered encoder and then come talk to me.

re "flaming DS": not at all, i'm just tired of seeing one excuse after another from him, he rips on gpu powered accelerators, he rips on avx, now he rips on quick sync, well the facts don't support his contentions: gpu powered encoders exist and offer very good quality at realistic bit rates, main concept has 2 gpu powered encoders, a cuda based one and an open cl based one, there is an open cl based gpu encoder for os x, there is an ffmpeg based gpu powered dx9 based mpeg-2 encoder available as a plug in for adobe's products (as well as a vfw plug in), sony has an excellent (albiet slow) gpu powered encoder, all the major players have signed up for quick sync and a look through the docs show that the fixed function capabilities of quick sync are quite formidable, there are functions for sum of absolute differences, sum of square difference, sum of absolute hadamard transformed difference, functions for deinterlacing, resizing, denoising, detail enhancement, color conversion and enhancement, the list is endless, if you can think of it, there's a function for it.

i realize in this forum DS is unto God, that he can do no wrong, but you guys need to look at things objectively and see if the facts support the myth.