x264 and Intel's Media Engine / Sandy Bridge

[deadrats]

Originally Posted by Dark Shikari

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]

Originally Posted by kieranrk

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]

Originally Posted by deadrats

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.

Originally Posted by deadrats

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]

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]

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]

Originally Posted by deadrats

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.

Then spend all this time trolling on writing a patch for x264 instead and prove others wrong. Seems like a more productive way to settle this than yet another useless eweenie contest.

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

It seems you haven't been around this forum for long.

You have no idea what kind of speed people are willing to accept, as long as it is free and better quality.

[weasel_]

Originally Posted by Mixer73

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]

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_]

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]

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_]

http://www.anandtech.com/show/4113/l...n-sandy-bridge

[popper]

Originally Posted by kieranrk

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

Originally Posted by kolak

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/standa..._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 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]

Originally Posted by weasel_

http://www.anandtech.com/show/4113/l...n-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]

Originally Posted by Zerofool

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]

Originally Posted by popper

... 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.
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]

Originally Posted by Zerofool

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]

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]

Originally Posted by kypec

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

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

[kolak]

Originally Posted by popper

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/standa..._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 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]

Originally Posted by Dark Shikari

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