x264 and Intel's Media Engine / Sandy Bridge

[royia]

As we all know by now, Sandy Bridge will have Media Engine built in with video Encoding capabilities:
http://www.anandtech.com/show/3922/intels-sandy-bridge-architecture-exposed

and:
http://www.anandtech.com/show/3922/intels-sandy-bridge-architecture-exposed/6

In light of this thread:
http://forum.doom9.org/showthread.php?t=155234

Do you think the Media Engine is doomed as well?
Or could it be used to accelerate, at least to some level, x.264?

What about the AVX instructions, do they hold any promise?

[MatMaul]

What about the AVX instructions, do they hold any promise?
If I understood correctly it adds wider floating point instructions which is useless for x264.

[burfadel]

The real question is AMD's SSE5 instruction set (well, collection), and FMA4.

[royia]

You say the Media Engine will not accelerate any sub routine in x.264?

[mariush]

According to DS which posted something about it on doom9+1, that "engine" is similar to an already existing Broadcom encoder chip and Intel may just have licensed it from them and included it in their chips - if this is the case it's nothing really innovative.
The actual performance would also be barely enough to encode an 1080p in real time (40-50fps) , using some relatively poor quality settings ... x264 is already much better optimized and gives much more speed on better quality compared to than this "engine".

Just see this quote:


The video encode engine is a brand new addition to Sandy Bridge. Intel is being light on the details of the encoder but we saw a demo where Intel took a ~3 minute 1080p 30Mbps source video and transcoded it to a 640 x 360 iPhone video format. The total process took 14 seconds and completed at a rate of roughly 400 frames per second.


Run a similar test with x264 and see how fast you can encode the clip using preset --fast or --veryfast.. Encoding something to 640x480 (though personally I really think it was 480x360 as video was for iPod/iPhone but whatever) is not hard.

[royia]

Could you link to the discussion?
Thanks.

Because when I encode 720x576 using x.264 I don't get any more than 20fps.

[LoRd_MuldeR]

As always, when those "fps" numbers are presented, they mean absolutely nothing, if they aren't put into a relation to quality and bitrate!

If that so called "Media Engine" encodes at 50 fps, but delivers quality like x264 with preset "fast" or "veryfast", then it will be of very limited use for us :rolleyes:

And, as always with "hardware" encoders, I would expected that the "speed -vs- quality" options will be restricted, if existent at all.

Moreover, if they simply flange-mounted an "encoder chip" to their CPU, you must think of it as a "black box", which you can either use (as a replacement for a software encoder like x264) or not use at all.

Hence it probably can't be used to accelerate (or take over) only a specific "sub routine" of x264. Anyway, the thing is called "x264" not "x.264" ;)

[mariush]

T:\Winfast>x264_new --bitrate 2000 --preset veryfast -o out.mp4 "Video0914-0100(
TV35).mpg"
ffms [info]: 768x576p 1:1 @ 25/1 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1
[46.3%] 626/1351 frames, 117.82 fps, 2056.03 kb/s, eta 0:00:06


On a Q6600 overclocked at 3 Ghz. With medium, it goes down to about 30 fps.


roya: No point linking to the other forum, as it's just a general discussion about the new features in that processor, not something particular about this video engine.

Otherwise, I agree with Mulder, it won't be something exposed like SSE or MMX instructions... I believe it will probably be something like DXVA and programmers will probably just be able to configure some parameters exposed through the video driver. It won't be something like Cuda or OpenCL, which allows you to offload some parts or all the computing in the processors.

[Snowknight26]

By the way, it's either H.264 or x264. Since there's no middle ground, hopefully you can distinguish the two (and start using the correct one! :O).

[iwod]

Just when i saw the hardware encoder inside Sandy Bridge, i was thinking this Encoder would be great for Mobile Devices. On iPhone the quality would be unnoticeable given the source is HD unless it is very poor encoder.

Users would not have to worry about anything, just drag whatever they have and itunes would automatically transcode those into compatible format @ very fast rate. I dont know which encoder they used, but the one from Power VR would get you more then 1000fps encoding, that is a hour long movie would take less then 2 Min!!!!!!!!!!

[Blue_MiSfit]

unless it is very poor encoder.


It will be. But the results will probably be "good enough" for most casuals to transcode their pirated episodes of True Blood for their PMPs, plus it will be built into the bloody CPU.... so yeah I see this (or similar technology) being fairly successful in coming years.

Derek

[iwod]

Well Depending on your view on it, i wont classify it as poor ( yet ), it is only x264 is so good.

I just read this here
http://lee.hdgreetings.com/2010/09/intel-cpu-vs-nvidia-gpu-video-transcoding.html

It seems a delicate hardware encoder aren't much faster then x264 fastest pure CPU solution. I was expecting something like Power VR
http://www.imgtec.com/powervr/powervr-vxe.asp

Which encodes at 1000+ fps...

[Audionut]

i wont classify it as poor ( yet ), it is only x264 is so good.

Just because something is good, doesn't mean the other isn't poor.

Which encodes at 1000+ fps...

x264 --preset ultrafast --crf 40 -o h:\test.mkv h:\test.avi
ffms [info]: 640x360p 1:1 @ 30000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Baseline, level 3.0
x264 [info]: frame I:29 Avg QP:38.00 size: 6631
x264 [info]: frame P:7032 Avg QP:41.15 size: 833
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 8.9% 0.0% 0.0% P16..4: 17.6% 0.0% 0.0% 0.0% 0.0% skip:73.5%
x264 [info]: coded y,uvDC,uvAC intra: 10.7% 33.3% 8.0% inter: 2.8% 4.5% 0.2%
x264 [info]: i16 v,h,dc,p: 36% 28% 23% 12%
x264 [info]: i8c dc,h,v,p: 67% 16% 14% 3%
x264 [info]: kb/s:205.43

aborted at input frame 7067, output frame 7061
encoded 7061 frames, 606.77 fps, 205.48 kb/s

Q6600 @ 3.2

If I was to drop the resolution abit more and clock it @3.6, I reckon I could hit 1000fps too. :cool:

[iwod]

Wow... sorry i dont have such powerful hardware. If that is the case then what is the point of a dedicated Hardware Encoder on a fast CPU like Sandy Bridge?

[Audionut]

If that is the case then what is the point of a dedicated Hardware Encoder on a fast CPU like Sandy Bridge?

It will make Intel money.

[iwod]

Doesn't make any sense, How does Intel make money from have a Hardware Encoder? No one will buy Sandy Bridge because of a Hardware encoder if Sandy Bridge in itself is already performing much better then the Hardware Encoder. Both in terms of quality and speed.

People Buy Sandy Bridge because it is a Great Chip all around.

So if the Hardware encoder are not faster nor produce better quality then a software encoder, what is the point ?

[Audionut]

what is the point ?

Money. Bragging rights.

"Hey dude, my new Intel computer encodes my new Dora episodes at wicked speeds."

AMD has something just as useless. Now Intel does too.

And I would think that there would be plenty of people who would base some of the purchasing decision on the fact that it has a 'dedicated hardware encoder'.

Honestly, There's a great many things in the world where you think, what's the point.

[royia]

I guess too naive to think it would be flexible enough to allow some acceleration of at least the sub routines all H.264 encoders share.
Someone should just fax AMD / Intel the perfect SIMD instruction set and hardware block to give us x264 in good quality mode with speed over 120fps :-).

[aegisofrime]

Money. Bragging rights.

"Hey dude, my new Intel computer encodes my new Dora episodes at wicked speeds."

AMD has something just as useless. Now Intel does too.

And I would think that there would be plenty of people who would base some of the purchasing decision on the fact that it has a 'dedicated hardware encoder'.

Honestly, There's a great many things in the world where you think, what's the point.

If you are talking about AMD's AVIVIO encoder... Now that's something that is REALLY useless.

[Sharktooth]

Avivo is different. it uses GPU acceleration... it's not just some silicon stuffed into the CPU.

[iwod]

Hey dude, my new Intel computer encodes my new Dora episodes at wicked speeds.

That is exactly my point, my new Intel Computer would encode my new Dora episodes WITH or WITHOUT the hardware encoder at wicked speeds!!!!!

I seriously hope the final version of Sandy Bridge hardware encoder will be much faster then what is currently being tested.

[aegisofrime]

Avivo is different. it uses GPU acceleration... it's not just some silicon stuffed into the CPU.

From what I read and from my own experience with my Radeon 4870, it doesn't use the GPU. It's just a H.264 encoder that uses the CPU, the reason why it's somewhat fast is because it turns off all quality features.

There are plenty of reviews of it, and you will find that the quality it produces is downright awful, perhaps the worst of all H.264 encoders out there.

[Audionut]

Avivo is different. it uses GPU acceleration...

No it doesn't.

That is exactly my point, my new Intel Computer would encode my new Dora episodes WITH or WITHOUT the hardware encoder at wicked speeds!!!!!

Yeah, most people on this board know that. But with the right marketing, I'm sure there are thousands of people who buy it thinking it's the best and fastest encoder based on the media encoder component.

[jpl]

I think the intended benefit of Media Engine is reduced power consumption. It may be the same speed as the CPU running flat out at max speed, but the hardware encoder will use much less power.

This would be most beneficial for mobile devices when running on battery.

[Sharktooth]

No it doesn't.
proof please.
http://www.dinoxpc.com/articolo/schedevideo_avivo_affair_images/utilizzo_gpu.jpg
from this SS avivo WORKS using the GPU (GPU usage ~20% on a 4870).
your statement is simply not true: http://en.wikipedia.org/wiki/ATI_Avivo#ATI_Avivo_Video_Converter

Edit: Btw, a software solution is different than a hardware solution. SandyBridge's media engine is crappy and you have it in your CPU. No possibilities to improve it unless a new silicon... Avivo is a software using GPU HW and can be improved anytime.

[mariush]

I remember reading somewhere (don't ask me, in the driver release notes or somewhere) AVIVO only uses GPU to accelerate DECODING of some content - MPEG 2 in particular and possibly VC-1 too. It does not use the GPU at the actual encoding process.

[Sharktooth]

that's on unsupported GPUs. the screenshot is self explanatory. you wont see any GPU usage from decoding a video source since decoding uses a dedicated silicon (UVD) not the GPU.
if you want to try the latest xcode (avivo converter) get it here: http://www.atizone.it/download?object=file&objid=8450
it needs catalyst 10.9 and a recent ati card though.

[mariush]

Well, with my 4850 (which should be supported, don't you agree?), the only place I can see some GPU acceleration is when transcoding a VOB (720x480) to the MPEG-2 profile:

http://savedonthe.net/image/679/gpucoding.png

You can see the gray line was at 0% all the time I tried MP4 1080p to MP4 720p, to MPEG2 720p and then went up to 15% gpu and increased gpu processor frequency when I started the VOB to MPEG-2 process.

This video converter is super crappy anyway - it reloads the video each time you go from one tab to another and each time you move the slider (I have about 20 Haali splitter icons in the system tray now - i'll have to kill the ccc process to get rid of them ) and is overall not so optimized.

[Sharktooth]

i didnt say it was any good... ;)
however i dont know it 4850 is supported and i dont even know if the software makes choices depending on the CPU model/frequencies.
what i know is it is developed using stream sdk and "sometimes" it uses GPU acceleration and those cases were different with different xcode versions.

[Caroliano]

There is one thing that this hardware encoder will definitely bet by far x264: fps and quality per watt. Maybe a good thing for laptops. Other than that, seems like a little waste of 3mm^2 of silicon.

[Sharktooth]

encoding with a laptop... anyone that buys a laptop for encoding is insane...
OTOH x264 could deliver better performance and quality on a laptop too.

[Audionut]

proof please.

No, it's not in hardware since there is a "cracked" avivio encoder that runs on EVERY video card...


from this SS avivo WORKS using the GPU (GPU usage ~20% on a 4870).

the transcode acceleration will not be ready by that time. ATI has committed to delivering the transcode acceleration by the end of this year,


Nice to see that in 5 years they've managed to get the GPU usage to 20%.

And here we have speculation that it is from decoding, not encoding. Can you prove that 20% is being used to encode!

[Sharktooth]

as i said it's developed using stream sdk. also, UVD usage (that's the silicon used for decoding) is not measured in the GPU usage since it's a standalone unit.

[Caroliano]

encoding with a laptop... anyone that buys a laptop for encoding is insane...
OTOH x264 could deliver better performance and quality on a laptop too.
You don't need to "buy it for encoding" to encode in it. And I said performance and quality PER WATT. In a laptop this can mean how many hours you can encode on one charge, as a benchmark.

[Didée]

Some days ago...

CPU: Intel i7-860
GPU: GeForce GT240

Source: 1280x720@50fps, Avi/Huffyuv


CUDA @ default / --bitrate 4150: 94 fps

x264_x64 --preset superfast: 101 fps

Results: LINK (http://www.mediafire.com/?d6xb7m46ua4l6iv) (~13MB, MediaFire)
With GPU/Hardware encoding becoming more popular, the world will be flooded with bad quality videos.

[iwod]

encoding with a laptop... anyone that buys a laptop for encoding is insane...
OTOH x264 could deliver better performance and quality on a laptop too.

Well, you can now finally drag all kinds of Video into iPhone and the Hardware encoder will do the transcoding for you at decent speed ( i wouldn't say very fast unless it is 1000fps + ) .

Even at 450 fps, 120 Min Video would still takes 6 min..... not including the time to transfer that file to iPhone........

[deekey777]

From what I read and from my own experience with my Radeon 4870, it doesn't use the GPU. It's just a H.264 encoder that uses the CPU, the reason why it's somewhat fast is because it turns off all quality features.
Try this one:
http://www.cyberlink.com/downloads/trials/mediaespresso/download_en_US.html
Your HD4870 will encode videos to H.264 (eg for PS3) or MPEG2. And if you enable video decoding over GPU, your HD4870 will encode with UVD clocks.

There are plenty of reviews of it, and you will find that the quality it produces is downright awful, perhaps the worst of all H.264 encoders out there.
I've played with the MSE several times: You get the best result, when MSE lets the graphics card decode the video and the CPU encode it. For me (HD4850&Q6600) it was the best way: Same speed and much better quality.

(But MSE is still piece of s...)

[bsoft]

(Sorry to reopen a dormant thread, but SB is shipping soon so this will affect a lot of people)

Anyone who's comparing the performance of the Intel Sandy Bridge media engine to x264 is missing the point. The SB media engine is not really about permanent transcoding.

You're going to get better results with a software encoder. Always. Hardware is harder to implement and there are real cost/power constraints that x264 doesn't have to face because it can always just use more time.

SB's H.264 encoder is good where low CPU usage is more important than high bitrate efficiency. Want to stream your StarCraft II matches without stealing CPU time from the game? Want to stream to your DLNA TV or WiDi device without killing your battery? Want to watch a recorded program on your smartphone or tablet without sucking down 100W from the wall?

For these uses, how fast the SB streaming engine is doesn't matter - as long as it's at least realtime. Hell, in the LAN cases how efficient it is doesn't matter much either, since you can always throw more bitrate at the problem.

No matter how good x264 is you can't get away from the fact that it keeps the CPU busy. Busy CPUs mean crappy battery life. Busy CPUs mean that there are less cycles for other tasks.

Does the prospect of being able to screencast to my TV with near-zero CPU load interest me? You bet it does.

[Dark Shikari]

(Sorry to reopen a dormant thread, but SB is shipping soon so this will affect a lot of people)AFAIK, the Sandy Bridge shipping in January will not have the transcoding engine. You're going to be waiting quite a while.

[aegisofrime]

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

May I ask where you heard that from? I have not seen anything saying that on the usual tech news sites.

[saint-francis]

DS have you have the ability to see results of x264 on the new SB? Is there going to be any gain? I'm not really sure what the point of this up coming SB is.

[LoRd_MuldeR]

DS have you have the ability to see results of x264 on the new SB? Is there going to be any gain? I'm not really sure what the point of this up coming SB is.

AVX (Advanced Vector Extensions) should help x264, I guess - if new AVX-optimized assembly is written.

But AFAIK the first Sandy Bridge generation will only support AVX with 256-Bit registers, rather than the full 512-Bit. Still that's twice the size of the SSE registers.

Also you'll need Windows 7 with SP-1 to be able to use AVX. Or some recent Linux kernel ;)

[poisondeathray]

AVX (Advanced Vector Extensions) should help x264, I guess - if new AVX-optimized assembly is written.

But AFAIK the first Sandy Bridge generation will only support AVX with 256-Bit registers, rather than the full 512-Bit. Still that's twice the size of the SSE registers.

Also you'll need Windows 7 with SP-1 to be able to use AVX. Or some recent Linux kernel ;)

I think D.S. said AVX wasn't going to be useful for x264



What about 256bit AVX? Each module can process only one at time (AFAIK) and x264 will surely support these new instructions (I hope eheh)

Float-only, thus a useless pile of tripe.


http://doom10.org/index.php?topic=514.0

[LoRd_MuldeR]

Didn't know that AVX is FP-only. That's a pity...

[deadrats]

I think D.S. said AVX wasn't going to be useful for x264.


if i had a dollar for every time his darkness has said something that didn't make any sense i would be a rich man by now.

he says avx is "Float-only, thus a useless pile of tripe" yet what he fails to mention is that he could convert the code to floating point, there's nothing that says it must be integer based.

as a very simple example if you have the following code snippet:

for ( a = 1; a < 100001; a++ )
for ( b = 1; b < 100001; b++ )
{
ab = a * b;
}

and use the following variable declaration:

int a, b, ab;

you cause the above to be executed on the alu (integer unit), if however you do this:

float a, b, ab;

it's executed using the floating point registers.

depending on the compiler you can even do something like this:

_m128i a, b, ab;

and perform a scalar calculation using the sse registers (there's a bit more code required than just that, but you get the idea).

yes, it would be a lot of work to rewrite the code to take advantage of the new avx registers and it's contingent on gcc supporting the required assembler instructions (he could always spend the dough and buy a copy of intel's compiler, though he would also need a copy of visual c++), but there's nothing inherently integer based about the code (other than that's they way he wants it) and there's nothing really standing in his way from changing it to take advantage of the sandy bridge's capabilities. (<--in all fairness, if he did do this he would need to maintain 2 versions of x264, one for cpu's that support avx and one for those that don't and he may not be willing to do that).

[Dark Shikari]

he says avx is "Float-only, thus a useless pile of tripe" yet what he fails to mention is that he could convert the code to floating point, there's nothing that says it must be integer based.Of course. You could convert it to floating point, and it would be at least 2 times slower, even with AVX, because you can only fit 8 floating point values in an AVX register, compared to 16 pixel values in an SSE register. It might be worthwhile if the AVX registers were 512-bit or 1024-bit, but at only 256-bit, it's not enough to justify a switch. There's also the additional problem of floating point instructions generally being slower than integer instructions, but even ignoring that, it's probably not worth it.

Anyways, since you're such a genius, write me a 16x16 SAD function that uses AVX and floating point input and runs in under 35 clock cycles (the speed of the SSE implementation on a Core i7). Here's the code for the C (with uint8_t converted to float):

static float sad_16x16( float *pix1, int stride_pix1, float *pix2, int stride_pix2 )
{
float sum = 0;
for( int y = 0; y < 16; y++ )
{
for( int x = 0; x < 16; x++ )
sum += fabs( pix1[x] - pix2[x] );
pix1 += stride_pix1;
pix2 += stride_pix2;
}
return sum;
}

I'll make it easy on you; you can assume the inputs are aligned (they aren't in reality).

[Sharktooth]

pwned...
FP math is ALWAYS slower than INT math, unless your have a CPU with ridiculously big FP registers.
also FP math leads to precision problems over time... unless you use a ridiculously high FP precision...
that said, INT math is a way better solution.

[deadrats]

Anyways, since you're such a genius, write me a 16x16 SAD function that uses AVX and floating point input and runs in under 35 clock cycles (the speed of the SSE implementation on a Core i7). Here's the code for the C (with uint8_t converted to float)

i just realized you're using 8 bit int's, all this time i thought you were using 32 bit int's, now the various objections you have raised make sense.

as for the homework assignment, i will gladly admit that i can't do it, but i will throw you a bone and use an excuse that you are fond of: company x hasn't sufficiently documented technology y, so it's their fault not mine.

simply replace x with intel and y with avx.

and here's some more excuses: i don't own an avx enabled cpu and i don't have a compiler that supports that instruction set (i don't think gcc supports it yet).

but i'm man enough to admit that like most people i don't know how to code with avx instructions...yet.

[Dark Shikari]

i just realized you're using 8 bit int's, all this time i thought you were using 32 bit int's, now the various objections you have raised make sense.Exactly -- that's the real power of integer SIMD -- the fact that you can get more throughput by using smaller data types.

Pixels are only 8-bit, and transform intermediates (as well as DCT coefficients) are only 16-bit. x264 makes very minimal use of anything larger than 16-bit.

Ironically, with integer SIMD, the variety of instructions available for 32-bit is actually rather lacking. For 16-bit, for example, you have pmulhw, pmullw, pmulhrsw, and pmaddwd for multiplication, providing a pretty good variety of instructions. For 32-bit, you basically only have pmulld and pmuldq -- the former of which is slow and SSE4-only, and the latter of which only does two multiplies, hardly justifying SIMD at all.

[deadrats]

Exactly -- that's the real power of integer SIMD -- the fact that you can get more throughput by using smaller data types.

Pixels are only 8-bit, and transform intermediates (as well as DCT coefficients) are only 16-bit. x264 makes very minimal use of anything larger than 16-bit.

Ironically, with integer SIMD, the variety of instructions available for 32-bit is actually rather lacking. For 16-bit, for example, you have pmulhw, pmullw, pmulhrsw, and pmaddwd for multiplication, providing a pretty good variety of instructions. For 32-bit, you basically only have pmulld and pmuldq -- the former of which is slow and SSE4-only, and the latter of which only does two multiplies, hardly justifying SIMD at all.

you know, it seems i owe you an apology, all this time i was reading various posts you made as well as some of the things you had written in your "diary of an x264 developer" and a lot of what you said struck me as absurd. now it all makes sense.

on the topic of gpu accelerated encoding, is one of the reasons you have claimed that for any given number of threads a cpu will be faster because with the cpu you can use 8 bit and 16 bit int's and with cuda (and it's brethren) you have to use 32 bit int's minimum?

is it also safe to assume that bulldozer, with it's 2 128 bit alu's per core, will be THE cpu to get for x264 encoding?

2 more quick questions: you recently signed a licensing agreement with pegasys and reading some of the press releases it seems that you created a parallel "commercial friendly" license under which you licenses x264 llc (that is the name of the commercial variant, is it not?). does this not violate the spirit, if not the letter, of the gpl?

i know many companies consider the gpl an "infectious" license, but doesn't the gpl explicitly forbid taking gpl'd code and making closed source? does it not also require that any derivative work also be gpl'd?

by creating a parallel licensing scheme haven't you a) created a derivative that's not gpl'd, b) opened the door for companies to create derivatives that are not gpl'd, c) opened the door for companies to close source the x264 code they license from you, d) and perhaps most importantly open the door for a company to make some simple changes and try and claim copyright to that, a claim that they could use to prevent you from making similar changes to the gpl'd version of x264?

lastly, i'm wondering what ide do you use during the development of x264, i'm assuming you use gcc to build the executables but do you use a front end like code blocks or dev-c++? also what, if any optimization options do you use? do you target any specific architecture, simply use -O3, a combination?

thanks.

[LoRd_MuldeR]

Commercial usage is perfectly fine for GPL'd software. The license clearly says that you are allowed to use the software for any purpose, explicitly including commercial purposes.

Moreover commercial development/distribution and OpenSource are not necessarily contradictory. Just think about commercial Linux distributions, like RHEL.

Last but not least, the authors of x264 could decide to continue the development of their software under some CloseSource license at any time, because they own the copyright.

However they certainly do not have to do this in order to be able to license their software commercially. And there's absoloutely no indication of such a plan at this time.

(I think the "commercial" license of x264 is more related to patent issues and/or support contracts. Something that is important for companies who use x264 in their products)

[J_Darnley]

The commercial license for x264 just frees companies from releasing all code they link with x264 as GPL. Each company that wishes to do this must obtain a license. It explicitly does not cover the AVC patent license. All useful code changes will be committed as GPL into x264 therefore letting everyone use them.

tl;dr LURK MOAR

[deadrats]

Last but not least, the authors of x264 could decide to continue the development of their software under some CloseSource license at any time, because they own the copyright.


see i'm not entirely sure that they do. as i understand it, x264 was originally created by someone else and then the two lead developers took ever and continued development. it's also my understanding that x264 was originally released under the gpl and the terms of the gpl dictate that any derivative work also be gpl'd.

lastly, my view of gpl'd software has always been that once it's gpl'd it's the same as being put into the public domain, copyright laws do not allow one to take something out of the public domain, not even whoever put it there in the first place.

http://www.gnu.org/licenses/gpl.html

i interpret the gpl to mean that you are not permitted to take a gpl'd product and release it under an alternate licensing scheme, not even if you're the person who gpl'd it in the first place.

i'm interested in hearing DS' take on this...

[kieranrk]

Copyright owners can license code however they like. All the copyright holders were contacted and agreed to the commercial licence.

[LoRd_MuldeR]

see i'm not entirely sure that they do. as i understand it, x264 was originally created by someone else and then the two lead developers took ever and continued development. it's also my understanding that x264 was originally released under the gpl and the terms of the gpl dictate that any derivative work also be gpl'd.

lastly, my view of gpl'd software has always been that once it's gpl'd it's the same as being put into the public domain, copyright laws do not allow one to take something out of the public domain, not even whoever put it there in the first place.

http://www.gnu.org/licenses/gpl.html

i interpret the gpl to mean that you are not permitted to take a gpl'd product and release it under an alternate licensing scheme, not even if you're the person who gpl'd it in the first place.

i'm interested in hearing DS' take on this...

If all copyright owners, i.e. all people who contributed code (that is still used), agree, then the code can be released under a different license, of course. This still applies, even if the software was released under the GPL before. So the authors could decide to move to a CloseSource license, if they wanted to. Still in that case all the code that had previously been released under GPL would remain under the GPL. So even if the "main" development would continue under a ClosedSource license, anybody could simply take the last GPL'd version of the software and continue using it as-is. You would even be free to start your own development (fork) from that version - under the restrictions of the GPL. And to make this clear again: Offering a software under a commercial license doesn't require or imply that the software is going to be CloseSource. And currently there is absolutely no indication that the x264 developers have any plans for moving to a CloseSource license. So what is the point of all this off-topic discussion please ???

[b66pak]

when money was invented the platonic love was gone...so anything is possible...
_

[Dark Shikari]

you know, it seems i owe you an apology, all this time i was reading various posts you made as well as some of the things you had written in your "diary of an x264 developer" and a lot of what you said struck me as absurd. now it all makes sense.All is forgiven :)

on the topic of gpu accelerated encoding, is one of the reasons you have claimed that for any given number of threads a cpu will be faster because with the cpu you can use 8 bit and 16 bit int's and with cuda (and it's brethren) you have to use 32 bit int's minimum?This is one of the reasons that GPUs tend to have less advantage than one would otherwise expect. The real problems are more obnoxious than that; this is just a reason why the raw performance gain is lower.

Note some of this has changed recently; ATI added an instruction to do a SAD of 4 8-bit integers, for example.

is it also safe to assume that bulldozer, with it's 2 128 bit alu's per core, will be THE cpu to get for x264 encoding?"2 128-bit ALUs per core" doesn't seem to be a very big selling point to me, considering that the i7 had 3!

2 more quick questions: you recently signed a licensing agreement with pegasys and reading some of the press releases it seems that you created a parallel "commercial friendly" license under which you licenses x264 llc (that is the name of the commercial variant, is it not?). does this not violate the spirit, if not the letter, of the gpl?

i know many companies consider the gpl an "infectious" license, but doesn't the gpl explicitly forbid taking gpl'd code and making closed source? does it not also require that any derivative work also be gpl'd?

by creating a parallel licensing scheme haven't you a) created a derivative that's not gpl'd, b) opened the door for companies to create derivatives that are not gpl'd, c) opened the door for companies to close source the x264 code they license from you, d) and perhaps most importantly open the door for a company to make some simple changes and try and claim copyright to that, a claim that they could use to prevent you from making similar changes to the gpl'd version of x264?

1. The GPL is "infectious" in that if you link GPL software to any software, that software must become GPL.

2. Any copyright holder is free to release their work under any license. Releasing something as GPL does not mean you can't release it as something else too. Many popular software programs are available under multiple licenses: a popular example is Firefox, which I recall is triple-licensed. A popular example of commercially-licensed GPL software is MySQL.

3. Companies are required under our license to (if we ask) give us all of their changes to x264 back to us. Furthermore, they sign over their rights to those changes -- we get co-ownership of them, allowing us to do whatever we want with them -- including release them as GPL along with the rest of x264. This means there won't be proprietary forks. I would not have gotten agreement from the other developers without this promise -- nor would I have supported the plan myself. This is why I consider it in the spirit of the GPL: it still ensures that all improvements make it back to the community, which is what the GPL is really all about.

Note there may be patches we don't release, but only because we don't consider them useful. If someone asks, we'll probably still be happy to go get it anyways. An example is a patch that adds UTF-16 path support for statsfiles, something I consider utterly useless.

lastly, i'm wondering what ide do you use during the development of x264, i'm assuming you use gcc to build the executables but do you use a front end like code blocks or dev-c++? also what, if any optimization options do you use? do you target any specific architecture, simply use -O3, a combination?

thanks.Notepad++ is my "IDE". Optimization options are just the default x264 builds with.

[deadrats]

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

the core i7 has three 128 bit alu's?!? are you sure? i know the P4 had 3 alu's, 2 were double pumped, 1 ran at cpu clock speed and the single pumped one was the one that handled the boolean decisions, such as if/else, case/switch and the like, the double pumped alu's were strictly for math purposes.

i know that starting with the core 2 intel went to a single cycle sse engine and a 4 wide architecture but i thought the biggest difference that the core i7 brought, other than the cache improvements, was that it extended the core 2's ability to fuse 32 bit instructions and treat them as one to 64 bit instructions, i never heard anything about it having 3 128 bit alu's.

to hear amd say it bulldozer's 128 bit alu's are something never before seen in a desktop cpu.

Notepad++ is my "IDE". Optimization options are just the default x264 builds with.

notepad++, huh? that's pretty hard core, kind of like my old linux/unix instructors used make us write our code in vi and point gcc to the saved .c file, lol.

this is going to sound like an amateur question but it's been a while since i built a project like x264 without using make on a linux system, how would i go about building x264 on a vista system just with gcc? i want to run a couple of experiments with various optimization options, just to see what kind of speed up, if any, is possible.

i'm also thinking of using c to pascal, c to fortran and c to basic translators to port the code over to the respective languages, so that i may see a) what it would look like in said languages and b) what the relative performance of a good pascal, fortran and basic compiler would be in relation to gcc.

[Dark Shikari]

the core i7 has three 128 bit alu's?!? are you sure? i know the P4 had 3 alu's, 2 were double pumped, 1 ran at cpu clock speed and the single pumped one was the one that handled the boolean decisions, such as if/else, case/switch and the like, the double pumped alu's were strictly for math purposes.

i know that starting with the core 2 intel went to a single cycle sse engine and a 4 wide architecture but i thought the biggest difference that the core i7 brought, other than the cache improvements, was that it extended the core 2's ability to fuse 32 bit instructions and treat them as one to 64 bit instructions, i never heard anything about it having 3 128 bit alu's.

to hear amd say it bulldozer's 128 bit alu's are something never before seen in a desktop cpu.

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.

this is going to sound like an amateur question but it's been a while since i built a project like x264 without using make on a linux system, how would i go about building x264 on a vista system just with gcc? i want to run a couple of experiments with various optimization options, just to see what kind of speed up, if any, is possible.Download Cygwin or MinGW, use make. You won't build x264 without a configure/make script combo.

[imcold]

i'm also thinking of using c to pascal, c to fortran and c to basic translators to port the code over to the respective languages, so that i may see a) what it would look like in said languages and b) what the relative performance of a good pascal, fortran and basic compiler would be in relation to gcc.

I doubt you'll go far just by translator, but if you want to see how an encoder in it would "look like" in pascal, there is an encoder written in it already: fevh264 (https://sourceforge.net/projects/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.).

[deadrats]

fevh264 (https://sourceforge.net/projects/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]

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/the-sandy-bridge-review-intel-core-i5-2600k-i5-2500k-and-core-i3-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]

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/the-sandy-bridge-review-intel-core-i5-2600k-i5-2500k-and-core-i3-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]

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

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 :p

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

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 (http://www.engadget.com/2011/01/03/intel-to-launch-insider-movie-service-with-1080p-content-widi-2/)! :rolleyes:

[Sharktooth]

sarcasm (http://www.youtube.com/watch?v=BxroiTRg7Tg)...

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

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]

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]

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]

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]

And now with bonus DRM (http://www.engadget.com/2011/01/03/intel-to-launch-insider-movie-service-with-1080p-content-widi-2/)! :rolleyes:

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]

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]

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]

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]

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.

[shon3i]

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. No we just use our eyes, thats all.

Second, you comparing two encoders like ferrari and tractor, both can reach speeds of 200km/h, downhill....

[weasel_]

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.

There is test x264 vs some cuda encoder i dont remember what
Use search ...
U will see how much x264 is better at same bitrate...
Half blind people will see that

There is no hardware encoder that is better in quality-wise then x264


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.
And what facts u gave ?

AT REALISTIC bitrate ? hahahaah

What is main point of encoder ?
Keep quality at smallest bitrate posible ...
So compare x264 to that encoders you named at low bitrate and u will see for yourself.
At big bitrate every encoder in world will be good. Shon3i gave good example for tractor and ferrari :)

[deadrats]

So compare x264 to that encoders you named at low bitrate and u will see for yourself.
At big bitrate every encoder in world will be good. Shon3i gave good example for tractor and ferrari :)

what is this bizarre fascination that people have with bit rate starving their encodes?

a dvd 9 can hold 8.5 gigs of data, blu-ray can hold up to 50 gigs and we have hard drives in the 3 terabyte range, why would you use ridiculously low bit rates for any encode?

it reminds me of that seinfeld episode where kramer is test driving the saab, the needle hits "e" and he and the salesman decide to see how far they can go before they run out of gas and the car stalls.

all i know is that i just priced out a new SB based build, i can get a good motherboard for $125, a 2500k for $180 and 4 gigs of ddr3 for about $100, as soon as i get my tax refund i'm switching to SB and i'll use the transcoding engine that allows me to encode 1080p at 100fps and you guys can stick with the software based encoder and keep telling yourselves that the quality is much better and it's just as fast as quick sync.

when you sober up, the rest of the world will be waiting for you...

[weasel_]

And what is point of encoder ?
Encoding at same bitrate as source ? :facepalm:


i'm switching to SB and i'll use the transcoding engine that allows me to encode 1080p at 100fps

Great, have fun....

and you guys can stick with the software based encoder and keep telling yourselves that the quality is much better and it's just as fast as quick sync.

:stupid:

[LoRd_MuldeR]

what is this bizarre fascination that people have with bit rate starving their encodes?

a dvd 9 can hold 8.5 gigs of data, blu-ray can hold up to 50 gigs and we have hard drives in the 3 terabyte range, why would you use ridiculously low bit rates for any encode?

Using bitrates that are too high is a common mistake done in encoder comparisons. As a matter of fact, you can always increase the bitrate until the differences between the competing encoders vanish. That's because at a certain bitrate even the worst encoder in the test will look "transparent" and then it is impossible for any of the other encoders to give better quality. Of course such test is absolutely meaningless! For this reason you must pick a bitrate where the differences between the different encoders are still clearly visible - at least if your goal is to learn something from your test. IMO the typical BluRay bitrates are too high for an encoder comparison. Remember: BluRay was designed with MPEG-2 in mind, so the available bitrates are actually higher than what a good H.264 encoder needs to retain "transparent" quality...

(Needless to mention that running the test at an absurdly low bitrate and then concluding that all encoders in the test look "horrible" would be just as meaningless)

[deadrats]

IMO the typical BluRay bitrates are too high for an encoder comparison. Remember: BluRay was designed with MPEG-2 in mind, so the available bitrates are actually higher than what a good H.264 encoder needs to retain "transparent" quality...


that is not true, blu-ray was designed from the get go with all three major compression schemes in mind, avc, mpeg-2 and vc-1 as well as a boat load of audio compression schemes:

http://www.blu-ray.com/faq/

i do think that you touched on an important thought process, it does seem that x264 proponents are of the mind set that blu-ray bit rates are too high, they forget that uncompressed 8bit 1080p29.97 video uses 119 mega bytes per second, so even a bit rate of 30 mega bits per second is on the low side, x264 users seem convinced that they can drop that all the way to 10 mega bits per second (and lower) for 1080p29.97 video and somehow still maintain the same quality.

just because they can't see the differences using the consumer grade 20 inch monitors coupled to their gaming graphics cards does not mean that the quality is the same, just that they need to look at the math, get their cataracts operated on and lay off the wild turkey.

personally i think the "bit rate starve" mentality has it's origins in piracy and file sharing, people eager to conserve bandwidth so they try to transcode to as low a bit rate as possible so that downloads and uploads complete faster.

it's silly, if you could achieve the same quality level these companies would never have invested millions in hd-dvd and blu-ray technology, they would have stuck with dvd9 and extended the spec to include h264/vc-1.

[mp3dom]

Using bitrates that are too high is a common mistake done in encoder comparisons. You can always increase the bitrate until the differences between the competing encoders vanish. That's because at a certain bitrate even the worst encoder in the test will look "transparent" and then it is impossible for any of the other encoders to give even better quality. Of course such test is absolutely meaningless! For this reason you must pick a bitrate where the differences between the different encoders are still clearly visible - at least if you want to learn something from your test.
You're right... it's surely useless to compare a 1080p source at 100 Mbps range.


IMO the typical BluRay bitrates are too high for an encoder comparison. Remember: BluRay was designed with MPEG-2 in mind, so the available bitrates are actually higher than what a good H.264 encoder needs to retain "transparent" quality...
I disagree. Personally I think 40 Mbps can be enough only most of the times. In particular, for sensitive parts (gradients, fine details, subtle grain, fades, all of the above mixed with complex parts etc) if you see the source and then the compressed file (even during playback) you can easily spot the differences if you've a 'trained' eye (and sometimes even an 'eye' is enough :)). The "pro" here is that the final customer doesn't have the master as a reference to see if the problem is on the master or came up after compression.
Probably in this "field" all the encoders have rooms for improvements (I think but above all I wish).
Just as a note: this (http://forum.doom9.org/showthread.php?p=1458884#post1458884) 40 days old "quick" comparison was made with an average bitrate of 35Mbps (with max set to full 40 Mbps). Considering your post, this result would qualify x264 as 'bad' (which, I think first of all, is not true), but anyway clearly demonstrate that even 35Mbps average can be not enough (for both encoders).


personally i think the "bit rate starve" mentality has it's origins in piracy and file sharing, people eager to conserve bandwidth so they try to transcode to as low a bit rate as possible so that downloads and uploads complete faster.

I completely agree with you, even if it's true that a lot of times even official BDs have an average bitrate of 15-20 Mbps which (to me) is again low.

[deadrats]

And what is point of encoder ?
Encoding at same bitrate as source ?


you are absolutely correct, i personally believe that there are only a few reasons to transcode something, like if the source is too dimly lit, the color saturation is off, the source is noisy and you are trying to fix said video or the aspect ratio is wrong and you can't fix it via manipulation of flags.

in these cases the output should equal the input, i.e. size and bit rate in = size and bit rate out.

in all other cases you are better off simply buying another hdd (at $90 for 1.5tb it's quite affordable).

[shon3i]

The whole point here is efficiency of some standard. I can't understand why then all of these standards and improvements if there is no real difference. H264 is made to be better than MPEG2. Otherwise why not keep Lossless.

Like for example one car spent 8 liters and another spent 15 liters, both driving at 160km/h. And someone then says that is impossible. And all cars need to spent 15 litres and higher to be faster.

that is not true, blu-ray was designed from the get go with all three major compression schemes in mind, avc, mpeg-2 and vc-1 as well as a boat load of audio compression schemes:What LoRd_MuldeR is want to say is that huge bitrates is reserved in first place for MPEG2 encoders.

[LoRd_MuldeR]

that is not true, blu-ray was designed from the get go with all three major compression schemes in mind, avc, mpeg-2 and vc-1 as well as a boat load of audio compression schemes:

http://www.blu-ray.com/faq/

I know that in the final spec three formats are allowed (H.264, VC-1 and MPEG-2). Still MPEG-2 is by far the least efficient of those three supported video formats. And in the design of BluRay disc the bitrate (space) requirement was necessarily defined by the least efficient format that was going to be supported, i.e. by MPEG-2.

i do think that you touched on an important thought process, it does seem that x264 proponents are of the mind set that blu-ray bit rates are too high, they forget that uncompressed 8bit 1080p29.97 video uses 119 mega bytes per second, so even a bit rate of 30 mega bits per second is on the low side

So what is the point? Even old MPEG-2 can give decent quality at 20-40 MBit/s for HD content.

If state-of-the-art formats/encoders, such as H.264/x264, have proven that transparent quality can be preserved at even lower bitrates, then THAT is the reference other formats/encoders have to be compared to.

(To give yet another car analogy: If you can choose between a Trabi and a Ferrari, would you pick the Trabi, just because both of them are significant faster than an oxcart? ^^)

x264 users seem convinced that they can drop that all the way to 10 mega bits per second (and lower) for 1080p29.97 video and somehow still maintain the same quality.

Being convinced of something that is a matter of facts seems logically to me ;)

just because they can't see the differences using the consumer grade 20 inch monitors coupled to their gaming graphics cards does not mean that the quality is the same, just that they need to look at the math, get their cataracts operated on and lay off the wild turkey.

personally i think the "bit rate starve" mentality has it's origins in piracy and file sharing, people eager to conserve bandwidth so they try to transcode to as low a bit rate as possible so that downloads and uploads complete faster.

it's silly, if you could achieve the same quality level these companies would never have invested millions in hd-dvd and blu-ray technology, they would have stuck with dvd9 and extended the spec to include h264/vc-1.

It seems all your argumentation goes like this: If you have enough bitrate available that you can waste for hiding the weaknesses of a "bad" (i.e. inefficient) encoder, then using the "bad" encoder is bearable, even though with a "good" (i.e. more efficient) encoder you could have retained the same quality at a much lower bitrate or a better quality at the same bitrate.

There's nothing surprising or interesting about that...

(And indeed using DVD-9 with H.264 and a good encoder would have been perfectly sufficient for distributing HD movies, but of course the industry prefers selling new hardware for new disc formats!)

[AnonCrow]

what is this bizarre fascination that people have with bit rate starving their encodes?Quite simply, because it can be done - or optimally, because it shouldn't be possible. Such as any meaningful application in 256 bytes, or a GUI, a webserver and a graphical webbrowser on a C64.
In the grand scheme of things: from a company perspective, sure, it's cheaper to pump more CPU power and bytes into something, rather than spend a few years optimizing the code.

if you could achieve the same quality level these companies would never have invested millions in hd-dvd and blu-ray technology, they would have stuck with dvd9 and extended the spec to include h264/vc-1
Then they wouldn't have been able to sell more hardware to ignorant consumers.

i personally believe that there are only a few reasons to transcode something, like if the source is too dimly lit, the color saturation is off, the source is noisy and you are trying to fix said video or the aspect ratio is wrong and you can't fix it via manipulation of flags.
All of those can already be changed at runtime in any decent player. If the source is grainy and you want encode a degrained version of it, surely the bit-rate would drop a lot if you were encoding at the same quality ?
What about downscaling the video for various different resolutions, or simply downscaling it from 1080i to 720p if the the source really doesn't have that much optical resolution to begin with ?
Also, you nicely ignored the fact that weasel was somewhat flabbergasted with your ideas. Though I'm sure you were a little too, when Windows 7 was released, and you noticed that it had the same or in same parts even lower system requitements than Windows Vista - ignoring the fact that if eg. MS spent the better part of a decade to optimize it (or really rebuild it from scratch), it'd run happily on a 486 /w 32 MB RAM.
Continuing on the car MPG examples: Any people/companies competing for maximum fuel efficiency must be crazy then, even if they manage an order of magnitude more efficient use of whatever fuel used than a typical car (with a real-looking car).

Disclaimer: no, I'm not a Mac user, I'm an Amiga user

[deadrats]

It seems all your argumentation goes like this: If you have enough bitrate available that you can waste for hiding the weaknesses of a "bad" (i.e. inefficient) encoder, then using the "bad" encoder is bearable, even though with a "good" (i.e. more efficient) encoder you could have retained the same quality at a much lower bitrate or a better quality at the same bitrate.


you almost got it, you just need to expand on it a bit: if you can eliminate any quality difference between encoders with enough bit rate AND storage is not a consideration thanks to huge hard drives at very reasonable prices AND a hardware based encoder at 4 times the bit rate is 5-10 times as fast as the little darling of the open source community, then why suffer using the much slower encoder?

x264 is the fastest software based encoder when using the "ultra fast" preset, i'll grant you that. be that as it may, using a x4 620, transcoding a 1080p blu-ray rip to a 15 mb/s h264 with ac3 audio mkv i'm lucky if i see 15 fps, tops.

an SB cpu, using the quick sync engine, did a similar test on anandtech at 100 fps and that's without stressing any of the cpu cores.

according to that very same review, a 6 core 12 thread core i7 980x completes the encoding pass of the x264 hd benchmark at 49 fps. downloading the benchmark and examining the test file as well as the benchmark script shows that the source is a 720p mpeg-2 and the encode target is a 4 mb/s 720p h264, no audio with the priority set to "real time".

what does one need to be smoking to conclude that using x264 to encode a 4 mb/s 720 h264 at 49fps (if you'r lucky), with your cpu maxed out and priority set to real time is preferable to using the quick sync engine to encode a 15 mb/s 1080p, with audio no less, at 100 fps?

furthermore, what kind of reality distortion field is needed to believe that an x264 encode, done at 4 mb/s and 720p will somehow be of higher quality than an encode done at 15 mb/s and 1080p?

are all x264 users also mac users?

[kolak]

Pointless discussion :)

One group talks about encodes which are transparent to the source at very high level, other about something which looks good and is as small as possible (mainly for ripping and sharing over net)

BD was created to give best possible quality for mass consumer (DVD started being not good enough on massive new TVs) and its 40Mbits is good enough to deliver it. It's not overdone, even for x264.

Saying that x264 can achieve the same at 10Mbit as BD at 30Mbit is not true at all.
If x264 can achieve the same transparency at 10Mbit than great- we can put whole series on 1 BD. It also means that other encoders can be improved.

x264 can achieve much more than other encoders at 10Mbit, but it's no near close to transparency, which is achieved on BD discs.
Question is if average consumer does need such a good quality like BD? He could probably live with much lower, but TVs getting bigger and bigger and heavily compressed footage will start being soft, blurred, not detailed.

As deadrats said- don't turn DS into GOD- because he would done almost nothing without all doom9 members- it's their big job for all encodes and reporting any problems and giving suggestions. Many companies have great programmers, but it's lack of testing time, which stops them to make their product better. x264 has biggest testing community ever and free!

Quality wise x264 is as good as pro encoders for BD usage (with some stronger points and some weaker), but in terms of worflow/features/speed lot worse, so none of big studio use it.

In terms of other usage x264 is great and has clear quality advantage, but even so, most of the paid web content is not encoded with x264, but with Carbon Coder, Ateme and other hardware solution mainly because of the workflow.

x264 is an engine- needs GUI and other bits around it to be more popular.

Andrew

[LoRd_MuldeR]

you almost got it, you just need to expand on it a bit: if you can eliminate any quality difference between encoders with enough bit rate AND storage is not a consideration thanks to huge hard drives at very reasonable prices AND a hardware based encoder at 4 times the bit rate is 5-10 times as fast as the little darling of the open source community, then why suffer using the much slower encoder?

Still the same argumentation of yours: If you don't need/want a "good" (efficient) encoder to begin with, because you are willing to waste enough bitrate so that even a "bad" (inefficient) encoder will deliver decent quality, then indeed you won't benefit from a "good" encoder and the "bad" encoder will be sufficient for your particular needs. Still this does NOT make the "bad" encoder any better or the "good" encoder any worse. It just constructs a scenario where there's nothing for the "good" encoder to gain, because nothing is expected. Most important that argumentation does NOT add anything valuable to the discussion!

x264 is the fastest software based encoder when using the "ultra fast" preset, i'll grant you that. be that as it may, using a x4 620, transcoding a 1080p blu-ray rip to a 15 mb/s h264 with ac3 audio mkv i'm lucky if i see 15 fps, tops.

an SB cpu, using the quick sync engine, did a similar test on anandtech at 100 fps and that's without stressing any of the cpu cores.

With such fancy "speed comparisons" you must be extremely careful! In particular the following two things must be ensured:

(1) Both encodes must come out the same average bitrate. If the one encoder came out at a higher average bitrate than the other one it encoded at a lower compression efficiency and thus had an unfair advantage in the speed comparison.

(2) Both encodes must come out the same visual quality. If the one encoder produced a lower visual quality than the one, it encoded at a lower compression efficiency and thus had an unfair advantage in the speed comparison.

Unless these points are ensured, the FPS numbers are absolutely meaningless. And I'm very suspicious about that :rolleyes:

[deadrats]

What about downscaling the video for various different resolutions, or simply downscaling it from 1080i to 720p if the the source really doesn't have that much optical resolution to begin with ?

what?!? seriously? if something is transfered from film at 1080i then i'm going to go out on a limb and say that it has more than sufficient "optical" resolution (as opposed to what, anal resolution? LOL), likewise if it's a program recorded from hdtv it will still have enough of whatever you refer to as "optical" resolution.

why would you down rez it to 720p, i'm pretty sure i know what you're going to say, i just really want to read it for myself.

Also, you nicely ignored the fact that weasel was somewhat flabbergasted with your ideas.

le weasel was "flabbergasted" because he seems to have spent to much time worshiping at the x264 alter and stopped thinking for himself. most people react with disbelief when you first pull the veil that has been blinding them away from their eyes.

Though I'm sure you were a little too, when Windows 7 was released, and you noticed that it had the same or in same parts even lower system requitements than Windows Vista - ignoring the fact that if eg. MS spent the better part of a decade to optimize it (or really rebuild it from scratch), it'd run happily on a 486 /w 32 MB RAM.

1) i wasn't surprised, i expected microsoft to use a superior malloc() library, i expected them to rework the thread scheduler and i expected them to gpu accelerate more of the gui, specifically the 2d parts.

microsoft made a number of minor mistakes with vista, like changing the memory management model so that vista assumes that any free ram is wasted ram and caches all available ram as a consequence. win 7 does the same thing but the superior malloc() library is better at allocating and releasing ram as needed.

furthermore vista was the first to feature a fully gpu accelerated gui (for the 3d portions, xp featured partial acceleration), using win 7 leads me to believe that m$ extended that acceleration to 2d surfaces.

in so far as win 7 running on a 486, i don't care how much you optimized the code, if all of it was done using hand coded assembler, it still wouldn't run on an 486 cpu, the windows api, at least the dx parts, have been sse optimized since dx6 (back in the win2k days, modern windows Oses are all 32/64/128 bit hybrids, maybe an embedded version of win 7 could run on a 486 but that's it.

[kolak]

....
(And indeed using DVD-9 with H.264 and a good encoder would have been perfectly sufficient for distributing HD movies, but of course the industry prefers selling new hardware for new disc formats!)

I would say HD DVD with proper encoding would be good enough, but for how long?
We have 3D already and that would be end of HD DVD...
or.... your DVD-9 would be already to small to deliver 3D movies.


Andrew

[shon3i]

furthermore, what kind of reality distortion field is needed to believe that an x264 encode, done at 4 mb/s and 720p will somehow be of higher quality than an encode done at 15 mb/s and 1080p?
You tell us? Just remember higher values not always better.

Anyway there is encoder efficiency which work with human perception that control how to use bits and not spent on less noticeable things

x264 can achieve much more than other encoders at 10Mbit, but it's no near close to transparency, which is achieved on BD discs.Sorry I disagree, Blu-Rays start to be horrible and horrible, so exactly how we can say that is something transparent which look like....

[deadrats]

and just like that software based x264 encoding is dead:

http://tmpgenc.pegasys-inc.com/ja/download/tvmw5.html#trial

the english version will be available soon, in addition to licensing x264, pegasys will feature the cuda h264 encoder and support for quick sync.

stick a fork in x264, it's done.

[kolak]

Sorry I disagree, Blu-Rays start to be horrible and horrible, so exactly how we can say that is something transparent which look like....

Whatever it's, x264 at 10Mbit is worse:)

Something like Island trailer at 28mbit was good enough.


Andrew

[Jarod Middelman]

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.


Indeed we use our eyes, but i agree with deadrats, i like blocks aswell.

http://x264.nl/dump/blocks.png

[ranpha]

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?


Blu-rays is not only where H.264 can be used. There is also this thing called digital broadcast where it also can be used.

And trust me, you can save BILLIONS of dollars if you can save bandwidth within that industry. Imagine the saving a company can get if it can get away with broadcasting a 8Mb/s H.264 stream if it has the same quality as a 40Mb/s stream.

[weasel_]

you are absolutely correct, i personally believe that there are only a few reasons to transcode something, like if the source is too dimly lit, the color saturation is off, the source is noisy and you are trying to fix said video or the aspect ratio is wrong and you can't fix it via manipulation of flags.

in these cases the output should equal the input, i.e. size and bit rate in = size and bit rate out.

in all other cases you are better off simply buying another hdd (at $90 for 1.5tb it's quite affordable).
What you presonaly belive is your thing.
Point of encoder is like shon3i said efficiency.And there is nothing else to belive.
It would be still same if 50TB =100$... that dont change nothing..


BD was created to give best possible quality for mass consumer (DVD started being not good enough on massive new TVs) and its 40Mbits is good enough to deliver it. It's not overdone, even for x264.

40Mbit for blu ray its not overdone for x264 ?
Are you really Serious ?


Saying that x264 can achieve the same at 10Mbit as BD at 30Mbit is not true at all.
If x264 can achieve the same transparency at 10Mbit than great- we can put whole series on 1 BD. It also means that other encoders can be improved.

Of course not by reeencoding bluray then must be some lose no mother what bitrate we use becouse it`s not lossless codec
with same stream x264 whoud achive SAME qualitu at MUCH SMALLER bitrate

Whatever it's, x264 at 10Mbit is worse:)
Something like Island trailer at 28mbit was good enough.
Andrew
GREAT argument :)
Depend on movie...
A lot movies will look transparent with 10Mbit x264


In terms of other usage x264 is great and has clear quality advantage, but even so, most of the paid web content is not encoded with x264, but with Carbon Coder, Ateme and other hardware solution mainly because of the workflow.

First u must understand what is transparensy and u DONT.
It`s not mean that BR and x264@10MB are metematical equal
transparensy is subjectiv and for most people there is no difference even on very large display.

" result is perceptually indistinguishable from the uncompressed input, then the compression can be declared to be transparent"


le weasel was "flabbergasted" because he seems to have spent to much time worshiping at the x264 alter and stopped thinking for himself. most people react with disbelief when you first pull the veil that has been blinding them away from their eyes.

Great. Rly. i can`t wait.
Start pulling with some arguments and comparisons

[mariush]

That's true.. in Romania for example we have here about 10-15 tv stations but i think there will be only 2 or 3 channels for DVB-T (over the air digital tv) .
A company that has 4 channels would rather mux all four in a 24 mbps (or whatever it is) ... one 1080i 10mbps for their generalist station, 3 x 4.5 mbps 720p for their news/ entertainment/women (recipes and fashion) stations.

But unfortunately I don't think x264 is there today... though all tv stations here drag their feet regarding dvb-t, it's unlikely we'll have anything all over the country by 2014-2015. We have just 2 or 3 tv stations in a few cities (2-3 emitters on some high hills doing tests)

[kieranrk]

And trust me, you can save BILLIONS of dollars if you can save bandwidth within that industry. Imagine the saving a company can get if it can get away with broadcasting a 8Mb/s H.264 stream if it has the same quality as a 40Mb/s stream.

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

[Jarod Middelman]

With x264 they can run it at 2mbit!

[Chikuzen]

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.

oh, Dark Shikari is unto God:eek:

if so, what should we call akupenguin:confused:

[ckmox]

oh, Dark Shikari is unto God:eek:

if so, what should we call akupenguin:confused:

lol

anyway when you think of h264 what comes to mind is better compression so that means saving more bitrate so this kind of statement
what is this bizarre fascination that people have with bit rate starving their encodes?


is fail

x264 is just being true to the notion of better compression among all the h264 encoders out there

[casio7131]

Quote:
Originally Posted by deadrats View Post
that is not true, blu-ray was designed from the get go with all three major compression schemes in mind, avc, mpeg-2 and vc-1 as well as a boat load of audio compression schemes:

http://www.blu-ray.com/faq/
I know that in the final spec three formats are allowed (H.264, VC-1 and MPEG-2). Still MPEG-2 is by far the least efficient of those three supported video formats. And in the design of BluRay disc the bitrate (space) requirement was necessarily defined by the least efficient format that was going to be supported, i.e. by MPEG-2.
i don't believe that bluray was designed "from the get go" with all 3 codecs - i think that it was originally designed only for mpeg2 (hence the reason for 25-50gb discs) and the other 2 codecs, vc1 and h264, were added later on (after hddvd decided to use 3 codecs).

note: this comes from my memory and based on info given by amirm on avsforum (who was a hddvd guy from microsoft), so take this post how you like.

[ajp_anton]

the screen shots in the anandtech review are practically indistinguishable from the software encoded screenshots.Maybe because the software used sucks?

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.You don't have Quick Sync on your x4 620. If you have QS, you also have a fast CPU. My i7 920 does 70% of the speed of QS on x264 ultrafast (tried to replicate Anandtech's tests). Sandy Bridge will improve this a little. I don't know which looks better, but you just said you don't care.

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.You are more likely to transcode into a portable device with a small, expensive and non-upgradable flash memory.

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?Yes.

[wlee15]

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?


And do you know whats much faster than Intel QuickSync, not encoding at all.

[kolak]

What you presonaly belive is your thing.
Point of encoder is like shon3i said efficiency.And there is nothing else to belive.
It would be still same if 50TB =100$... that dont change nothing..


40Mbit for blu ray its not overdone for x264 ?
Are you really Serious ?




How many uncompressed film sources have you seen? (so you can have idea how it does look before any compression)

Passing 25Mbit x264 is not obviously any better than pro encoders and there is still lots compressed in this videos. Many sources have obvious compression artefacts even at 35Mbits. 40mbits is not overdone for BD at all. You can use 20Mbit as average and 40 as max and it will be "used" almost on every source.

BD was not designed to match BD rips quality:)

I've done 200 BDs disc and seen many masters and no one will convince me that x264 at 10Mbit achieves transparency- definately not, who has "x264 lover" in his nick description :)

I use x264 a lot also and know what it can do. If people are happy with 10Mbits we can do 3 movies on one BD- will save lots of money for studios and consumers :)

Andrew

[kolak]

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

[hajj_3]

and just like that software based x264 encoding is dead:

http://tmpgenc.pegasys-inc.com/ja/download/tvmw5.html#trial

the english version will be available soon, in addition to licensing x264, pegasys will feature the cuda h264 encoder and support for quick sync.

stick a fork in x264, it's done.

I think the hardware encoding isn't for x264 but instead of the other h264 codec that they use, mainconcept or something.

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

it looks like if you have nvidia card it uses cuda and if you have a new intel cpu it uses the intel sdk. Neither of which support x264 as far as i'm aware. We need intel, nvidia or amd to add support for hardware decoding, 3rd party vendors like tmpgenc can't do that as far as i'm aware.

[weasel_]

^^ Of course isn`t for x264 :)

How many uncompressed film sources have you seen? (so you can have idea how it does look before any compression)


Dont know 300-400, 200 150 dont count...
I can have better idea then you.


Passing 25Mbit x264 is not obviously any better than pro encoders

Ferrari going dowinhiill is not obviusly faster then tractor going downhill.
U cant compare encoders at big bitrate, just like u cant compare speed of vehicle when they falling from clif or going downhill :)


40mbits is not overdone for BD at all

its not for mpeg-2 only


Ive done 200 BDs disc and seen many masters and no one will convince me that x264 at 10Mbit achieves transparency

LIKE I alrady said ( u can read on page beofre this)
Depend on movie.
Some heavy grain movie need a lot more then 10 , some cgi movie need less then 10.
If u done 200Bd disc u shoud know that.
dont worry
I dont even want to convince sombody who think only one bitrate is identicly good for all movie.

[aegisofrime]

I think that all deadrats is trying to say is to consider things from the perspective of the end-user. Your average Joe probably cares a lot more about speed than quality, or rather, encoding efficiency. I do all my encodes at preset="slower". My brother will probably kill himself waiting for the same encode to finish.

I took a look at the Quick Sync review, and it's really not too shabby. I think that deadrats' points are these:

1. Quick Sync will probably be a standard feature on both Intel and AMD CPUs from now on.
2. Since it's there, why not use it?
3. Bring what DS and Team has learned from x264, and apply that to make use of Quick Sync, bringing extra speed and the quality we have all grown to love from x264.

[poisondeathray]

1. Quick Sync will probably be a standard feature on both Intel and AMD CPUs from now on.

AMD ? You sure about that?




I'm waiting for properly done review on quality, speed. (or speed at certain quality, or top quality... there are so many holes in that "video encoding part" of the review)

[LoRd_MuldeR]

I think that all deadrats is trying to say is to consider things from the perspective of the end-user. Your average Joe probably cares a lot more about speed than quality, or rather, encoding efficiency.

If you have an encoder with good compression efficiency you can always choose "faster" settings in order to sacrifice quality for speed, so you can find yourself the best compromise between quality and speed. But if you have one of those "created for fancy fps numbers" hardware-encoders you get bad quality encodes in relatively short time, but you can't go anywhere from there...

(The problem with Average Joe is that he probably will never compare the output form different encoders and thus never knows how much better his encodes could have looked ^^)

[kolak]

LIKE I alrady said ( u can read on page beofre this)
Depend on movie.
Some heavy grain movie need a lot more then 10 , some cgi movie need less then 10.
If u done 200Bd disc u shoud know that.
dont worry
I dont even want to convince sombody who think only one bitrate is identicly good for all movie.

That's exactly why 40Mbit is not overkill for BD. It gives you possibility to achive very high transparency for every movie or every scene in particular movie.

Please stop saying that x264 at 10Mbit achives the same quality as found on BD disc because it's simply not true at all.

If you say that x264 at 10Mbits give good enough quality for average user than fine- your opinion, but it's not BD quality.

Encode Island trailer at 10Mbit and 30mbit and check if they look the same. This is quite easy source compared to others, even if it has lots of fast motion.

I remeber when some people wehere showing Big Bunny saying- look good HD at 2Mbit :)


Andrew

[weasel_]

Rly u asking me that ? u dont know basic stuff that much ?

x264 ITS NOT LOSLESS encoder. I cant get same quality by reencidng something with lossy encoder at 1/3 bitrate no mother of how good encoder is.
U asking imposible and something that even noob in video world shouldnt ask.
Give me master that studio have.
And i will encode with x264 in 10Mb with same quality as studio encode with h264 @ 30Mbit...

What i can with bluray source is to get transparanet encode with much less bitrate. pls read what i wrote.... transpart is not same quality , it perceptually indistinguishablesame from source , and that is all imporant.

[kolak]

It's about preceptual quality for home user and BD offers very high, but even so there are still users, who complain:)

There is no problem to do 10Mbit encodes for BD- if it will be accepted than everything will get cheaper.

I bet you if you did study with typical film source, watched on eg. 42inch TV, BD would be voted better quality than 10Mbit x264 encode.

Island trailer raw source is available- good luck with 10Mbit :)
I think I still have it- can encode for you with x264 at 10Mbit.

Andrew

[weasel_]

They didnt complain about blu ray quality becosue h264 and bitrate...
They complani about other aspect of master quality ( like gladiator with lot of filtrering for example DNR and EE )
They done latter remaster version with simillar bitrate and 3x better quality..
THAT why people complain not about bitrate..
If raw is encoded in x264 @15mbit for bluray nobody will complain about to litlle bitrate.
U must understand that x264 is much more efficient then mpeg2 h264 ... and will get same quality with less bitrate ( of coruse if we encode same soruce , not by your theory of comapring : reencoding bluray with lossy codec and then compare qualtity = its very stipid ).On page before u asked me to get same qualuity with lossy codec... i still cant belive u asked fo that.


There is no problem to do 10Mbit encodes for BD ..
NOW there is no problem.. but 1 year ago x264 wasn`t Blu-ray-compatible .

[mp3dom]

What i can with bluray source is to get transparanet encode with much less bitrate. pls read what i wrote.... transpart is not same quality , it perceptually indistinguishablesame from source , and that is all imporant.
I read that with 10 Mbps you can achieve a quality that with *your* eyes, *your* tv-set and *your* taste seems transparent. Something that is so many subjective and variable to be negligible. :rolleyes:

[LoRd_MuldeR]

x264 ITS NOT LOSLESS encoder. I cant get same quality by reencidng something with lossy encoder at 1/3 bitrate no mother of how good encoder is.

x264 does have a "true" lossless mode, which is mathematically lossless. That mode, of course, isn't suitable for BluRay authoring/backup.

However you can produce "visually lossless" (transparent) encodes with x264 easily by using something like CRF=18 and the resulting bitrates usually won't be that high.

Moreover you must keep in mind that under normal conditions you won't compare the encoded video frame-by-frame against the source, but watch the video "in motion" without having the original source at hand.

Therefore "visually lossless" is still overkill for a final encode. "Very good" is sufficient here and that's what x264 in my experience will usually deliver at CRF=20-22 with (often) surprisingly low bit rates...

(Another thing to consider is that there is a difference between re-encoding a source that already was compressed in a lossy way, like BluRay source, and encoding straight from the original lossless source)

[weasel_]

Of course i know of lossless mode in x264 :) but generaly use of x264 isn`t that that why i said x264 is not lossless

and i writing in 4-5 post same as you but they cant or dont want to understand.
We cant get mathematically same but we can get visually indistinguishablesame and that is caleld transparent.

But even if we have source at hand and waching one after another ... with crf 18 or litle less nobody can distinguish encode from source.
Only when we can is when we get screenshot and fast swiching or even zooming on some part.

[mp3dom]

Are we serious? O_o?
Maybe I've "overstimated" the movie 'fanatics' but what I want to achieve with an encode is to be close as much as possible to the original master. Not to encode in a quality that a user cannot distinguish from the source (since also it doesn't have the master to compare to). For the latter basically it's only necessary to provide an encode that doesn't show high macroblocks or excessive distortion during playback and nothing more. For the most of the users during playback it will be perfectly fine. Personally even if a 10Mbps is 'transparent' (highly doubt this, but let's say is true) I'm not satisfied at all, I'm not satisfied at all even at 35 Mbps to be honest since for delicate footage the result can be too much different from the source (different without creating visible macroblocks) and this happends with *every* h264 encoder I've tested so far.

[weasel_]

agree but still even if u have source u cant tell difrence by waching one after another

and stop saying 10Mbitps

Its not same bitrate needed for Cgi movie for some avrage drama nad for some heavy grain action....so stop saying 10mbit
For some movie 10mbit is to much, for some is good, for some is not enough.

[kolak]

agree but still if u have source u cant tell difrence by waching one after another

and stop saying 10Mbitps

Its not same bitrate needed for Cgi movie for some avrage drama nad for some heavy grain action....so stop saying 10mbit
For some movie 10mbit is to much, for some is good, for some is not enough.

Hehehe- we know this :)

What is your 10mbit for grainy, complicated source?


Andrew

[weasel_]

bad choice :)

it will need more bitrate to get transparent but still less then bluray bitrate
Heavy grain and complicate movie is litle % of all movies ;)

[mp3dom]

For some is good probably because they're most of the times statics (drama?) with 2.35:1 aspect ratios. In that case I agree with you but it's quite uncommon footage. Also you understimate CGI footage. You'll be surprised to see how much bitrate a CGI scene can eat if you want to preserve fine details like color smoothing (unless the footage is only flat colors of course). And if you add CGI scene with fine details (smoothing to preserve) + complex parts in the same time you'll see that 40 Mbps is not enough (macroblocks with smooth gradients or no macroblocks with absurd color banding? Which one do you prefer? :))

[kolak]

bad choice :)

it will need more bitrate to get transparent but still less then bluray bitrate
Heavy grain and complicate movie is litle % of all movies ;)

It's more than you expect.
Only new movies have nice, clean masters.

Give me number please, since you know it all so well.

Andrew

[weasel_]

mp3dom :
I know, i saw that i some latest cgi movies ;)
I never say 10mbit is enough for all movies...
I just saying x264 can make transparent encode with a lot less bitrate then h264/vc1/mpeg2 ;)

kolak:Heavy grain and complicate movie that need x264@16,17,18... and more bitrate to be transparent ?
I dont know exact number but its very small :)

[kolak]

Don't forget about 50/60i content which is mostly full frame.
Your 16Mbit becames quikcly 25Mbit with peeks 30Mbit+

So we established that BD limit is not overdone :) (or that BD can't be used for interlaced content).

Andrew

[weasel_]

we established ?
You look on yourself at plural ?

[kolak]

Ok- you established.
Based on your estimation and obvious facts. It's your job :)

Andrew

[Didée]

Short reminder - back to topic:

Presumably SB QuickSync can achieve transparency on 1080p at 100~150 mbit.

[kolak]

Probably :)

[weasel_]

^^ and that is good becouse of there speed ?
Assume bluray encode done with SB QuickSync @10-15Mbit ... that`s not transparant even to people who are partial blind :)
Ok- you established.
Based on your estimation and obvious facts. It's your job :)

Andrew

what facts ?
Fact that 90% of movie with x264 get transparent at bitrate less then 15mbit ?

And what bitrate hardware encode need for same quality ? 10 time more :devil:

[kolak]

I never used a hardware encoder in my life :)

Yes and BD is for 100% cases, so it's established :)


Andrew

[weasel_]

@40Mbit : Bravo BD

And 20Mbit x264 is for 100% cases , still half less bitrate
so it`s established ;)

[kolak]

Average- add peek and than established and about what is currently used :)

Andrew

[weasel_]

OK , still is a significant less then bluray encoders need for same quality ;)

[kolak]

OK , still is a significant less then bluray encoders need for same quality ;)

What Blu-ray encoders have you tried?

[weasel_]

that is rhetorical question ?
and still i will answer :

I dont need to try everything in this world to know quality and efficiency of that.


Are you saying that bluray encoders will give same quality as x264 on 10-15mbit bitrate ?
OR that they need same bitrate for identical quality ?

not only x264... MC and much more encoders are better then 3 encoderes used in BluRay.



And we rly need to get back to topic and topic is :
how bad SB encoder will be

[deadrats]

I think the hardware encoding isn't for x264 but instead of the other h264 codec that they use, mainconcept or something.

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

it looks like if you have nvidia card it uses cuda and if you have a new intel cpu it uses the intel sdk. Neither of which support x264 as far as i'm aware. We need intel, nvidia or amd to add support for hardware decoding, 3rd party vendors like tmpgenc can't do that as far as i'm aware.

i'm well aware of this, i made a mistake, i meant to say that all software based h264 encoding, including x264, is dead.

[deadrats]

I think that all deadrats is trying to say is to consider things from the perspective of the end-user. Your average Joe probably cares a lot more about speed than quality, or rather, encoding efficiency. I do all my encodes at preset="slower". My brother will probably kill himself waiting for the same encode to finish.

I took a look at the Quick Sync review, and it's really not too shabby. I think that deadrats' points are these:

1. Quick Sync will probably be a standard feature on both Intel and AMD CPUs from now on.
2. Since it's there, why not use it?
3. Bring what DS and Team has learned from x264, and apply that to make use of Quick Sync, bringing extra speed and the quality we have all grown to love from x264.

WOW!!! someone actually understood exactly the message i was trying to convey.

i was starting to think that i was typing in swahili.

[deadrats]

Short reminder - back to topic:

Presumably SB QuickSync can achieve transparency on 1080p at 100~150 mbit.

where the hell did you get this from? the only review thus far that has screenshots shows that the x86 encode and the quick sync encode, 1080p@15mb/s, are identical.

the beauty of quick sync is that it's also present on dual core SB cpu's, so you can buy a low end processor and still get the same encoding speed.

hardware encoding is the future and something to be embraced, as soon as i get my tax refund i plan on building a SB based setup. when that happens i'll use the latest tmpg express, which uses x264 for software encoding and supports quick sync to put this debate to rest.

[dj_tjerk]

WOW!!! someone actually understood exactly the message i was trying to convey.

i was starting to think that i was typing in swahili.

And what about your claim that the so-called "software" encoders are dying? Where do you put the line between a hardware encoder and software encoder when the cpus offer many optimized instructions commonly used in video encoding or decoding?

Though I'm not really sure what Quick Sync is and how it can be used; but if it's some extra hardware implementations on the cpu and Intel is not putting up any fences to protect their baby's internals, I see no reason not to see it as an extended instruction set of some sort that your so-called "software encoders" can use. (Or am I totally wrong here?)

[LoRd_MuldeR]

Though I'm not really sure what Quick Sync is and how it can be used; but if it's some extra hardware implementations on the cpu and Intel is not putting up any fences to protect their baby's internals, I see no reason not to see it as an extended instruction set of some sort that your so-called "software encoders" can use. (Or am I totally wrong here?)

Apparently it is a complete encoder in hardware, which you can either use as a "black box" instead of a software encoder or not use at all.

It is not an instruction set extension that can be used in (existing) software encoders, like the MMX/SSE extensions...

[Dark Shikari]

Apparently it is a complete encoder in hardware, which you can either use as a "black box" instead of a software encoder or not use at all.

It is not an instruction set extension that can be used in software encoders, like the MMX/SSE extensions...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.

[LoRd_MuldeR]

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.

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?

[poisondeathray]

They just don't expose the API for this, so it's a useless pile of silicon.


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 :p

[Dark Shikari]

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]

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]

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]

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]

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]

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

[Dark Shikari]

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]

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]

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]

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]

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]

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]

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]

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. :p

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

[weasel_]

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/lucid-enables-quick-sync-with-discrete-graphics-on-sandy-bridge

[popper]

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]

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]

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]

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

Andrew

[kieranrk]

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]

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]

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

Andrew

[mp3dom]

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]

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]

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]

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]

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.

[Blue_MiSfit]

Please do! Until then I for one would be utterly shocked if we're on the same page as you with regard to "no perceptible differences between the cuda and the x264 encodes"!

I've evaluated the professional CUDA encoders and they were all rather awful compared to x264 or Mainconcept. I find it EXTREMELY difficult to believe that a consumer CUDA encoder could even hold a candle...

Some sample would sure be nice! Mind doing a few quick test encodes for us?

Derek

[weasel_]

deadrats:U get same quality with cuda encoder and x264 ? :facepalm:
u done imposible ( or you use some shity x264 settings)
then u dont know how to use x264.

Can u post sample or screenshots and settings
read this (first post use worst posible x264 settings ) continue reading and see ss comparison what users post..

http://forum.doom9.org/showthread.php?t=148276

[Didée]

Result from a test I did some weeks ago: see this post (http://forum.doom9.org/showthread.php?p=1444371#post1444371) (MediaFire link is still alive).

Having seen PLENTY of such results, it is hard to imagine that CUDA could ever output something acceptable. (at reasonable bitrates.)

[deadrats]

Some sample would sure be nice! Mind doing a few quick test encodes for us?


i'll let you pick the source, give me a test source and i'll do a couple of quick test encodes.

[Mixer73]

Having seen PLENTY of such results, it is hard to imagine that CUDA could ever output something acceptable. (at reasonable bitrates.)

Yes but I think deadrat's idea of reasonable bitrates is a bit off the planet.

[popper]

deadrats:"i'll let you pick the source"
the 1080P birds sample might be fun , i forget the direct URL to the original though

[CruNcher]

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

they have all the same speed the difference in the EU count is a GPU part not a MFX part "QuckSync" so every of the new Sandy Bridges should have virtually the same QuickSync encoding performance. More EUs are more important for faster Pre Processing stuff (Deinterlacing,Denoising,FRC,SR) and Games not the encoding part per se (the few current comparisons also show that)


Please do! Until then I for one would be utterly shocked if we're on the same page as you with regard to "no perceptible differences between the cuda and the x264 encodes"!

I've evaluated the professional CUDA encoders and they were all rather awful compared to x264 or Mainconcept. I find it EXTREMELY difficult to believe that a consumer CUDA encoder could even hold a candle...

Some sample would sure be nice! Mind doing a few quick test encodes for us?

Derek
Nvidias Encoder is better then Mainconcepts Encoder in it's current state (will most probably change soon though).
The comparison Annandtech did is flawed he didn't actually tested the Quality of Nvidias GPU Encoder but that of Arcsofts X264 GPU Encoder which is awfully buggy, they also have another Encoder which isn't based on X264 @ all though not yet used in any of their Products (very fast Cuda Encoder not up to the Quality of Nvidia though).
Arcsoft are practically the only ones that do not use Nvidias own Encoder (nvcuvenc API) but their own X264 GPU mod inside of MediaConverter7.
We don't know yet how QuickSync was tuned in the Profiles used for Encoding (what settings they call in the Media SDK API (quality level) Cyberlink could have optimized it for Speed rather then Quality in MediaEspresso.
There indications that QuickSync (how it's used in Cyberlinks Encoder) favors to destroy the Grain layer more uniform (keeping over time temporal Grain differences low by "Denoising" more blurry result ) compared to Nvidias Cuda Encoder (coming from a recent compare).

[Blue_MiSfit]

Parkjoy (maybe slowed down to 24p) is always a tough one.

Other than that, I don't know what you have access to. Any DVD or BluRay source is fine.

Cruncher, you're unintelligible as always, which is too bad because I get the feeling you have a unique perspective in all this talk of GPU encoding... or at least have access to lots of these encoders!

[mariush]

Deadrats.... encode this at 1080p 6-8 mbps and 720p 2.5 mbps : http://www.google.com/search?q=SAmsung+Demo+Oceanic+Life Should be a 500 MB h264 file at 40mbps.

Then look at the differences. But do post the encoding settings otherwise any comparison is useless.

[CruNcher]

There will also come support for Sandy Bridges Encoder from a company where i guess many wouldn't have suspected to see it from


Badaboom 2.0 is coming soon!

And with it is coming hardware-accelerated support for both NVIDIA Fermi GPUs and Intel Sandy Bridge hardware! The blazingly fast media converter that formats video files for a variety of devices, such as the iPad or Sony PSP, will also add new features, including the capability to run on any Windows PC! Stay tuned for more information.


We are announcing today that the next version of Badaboom, called version 2.0, is on its way and is bringing with it additional hardware support! As promised, this version will include support for NVIDIA Fermi GPUs. All of the latest NVIDIA graphics cards will be supported. A piece of news that may be a bit more unexpected, however, is that Badaboom 2.0 will also support the new Intel Sandy Bridge chips and their hardware-accelerated video processing capabilities! We are impressed with the performance of Sandy Bridge, and adding support for it means a couple things:

1. Users that have a system with the new Sandy Bridge chip will now be able to utilize Badaboom's transcoding power for the same decode and encode formats as the NVIDIA version.

2. The implemention of the Intel MediaSDK into Badaboom means that when there is no NVIDIA GPU or Sandy Bridge chip detected, Badaboom will still be able to run in software mode. This means you will be able to run Badaboom on any Windows PC!

On the feature side of things, Badaboom 2.0 will add a queuing mechanism (the most requested feature) so that you no longer need to begin each individual transcode manually. More details around this to come. Other added features include audio gain and large .m2ts file support. Combine that with an updated user interface and added output device profiles, and Badaboom 2.0 will be ready to rock.

As we said in the post last week, Badaboom 2.0 will be available for purchase in February. We are excited to be partnering with both NVIDIA and Intel to provide the best transcoding experience possible.


The marked part also states what DS already said its Intels H.264 Software Encoder (see MSU compare) using the Sandy Bridge Hardware tools to accelerate itself when available.
Here is a Video demoing Elementals MediaSDK support http://www.youtube.com/watch?v=BNPf-lMMYLY unfortunately they always take Itunes H.264 Encoder as reference for the Consumer base (and we all know how slow that is)

[popper]

its Not really a surprise as such CruNcher , its another tick in the 'PR Innovators' book.

it's not even a surprise to me that the AMD OpenCL SDK with its so called Open Decode library that uses the DRM/UVD didn't get a mention ether.

as everyone knows that's Tried to work with AMD you cant even get them to provide the Linux Open Decode library to go with the SDK, or even get simple and reported AMD driver bugs fixed in a timely manor.

so no reliable HW decode across the 3 versions of the broken DRM/UVD ASIC from even the one 3rd party Linux dev that did sign the NDA, and he's all but given up on them now, and who could blame him, AMD just dont want to play ball never mind be in the game it seems.

[CruNcher]

its Not really a surprise as such CruNcher , its another tick in the 'PR Innovators' book.

it's not even a surprise to me that the AMD OpenCL SDK with its so called Open Decode library that uses the DRM/UVD didn't get a mention ether.

as everyone knows that's Tried to work with AMD you cant even get them to provide the Linux Open Decode library to go with the SDK, or even get simple and reported AMD driver bugs fixed in a timely manor.

so no reliable HW decode across the 3 versions of the broken DRM/UVD ASIC from even the one 3rd party Linux dev that did sign the NDA, and he's all but given up on them now, and who could blame him, AMD just dont want to play ball never mind be in the game it seems.

It's sad that AMD missed those wide spreading opportunity early on (imho it was a bad mistake) though i remember when i made Donald aware that he could utilize Nvidias DSP back then under Win32/64 utilizing their SDK @ that time Nvidia didn't released the Linux part of it either it came later as the whole concept of VDPAU slowly emerged, though they still haven't open the Encoder part for Linux yet nvcuvenc api which they have done for Win32/64 since some SDKs back now.
The overall response to opening the Encoder (Opening means in that sense setting the API free from NDA barriers, though it seems they where internaly discussions about a entirely Open Source GPU Encoder based on their Research, maybe that idea didn't died fully yet,though you don't have to forget the ISVs making business with their closed Encoders now such a project could hurt in some ways and be helpful in others depending on your customer base) was the same as back then with the Decoder in some weeks a lot of even no name Applications (not always good ones though but do they need really to care about that ?) adopted it in no time (also because their excellent support and documentation) (not only the big ISVs had now access after some short ISV NDA exclusive time) and that's the Power of their Ecosystem (Donald and the Doom9 Community helped a lot Debugging VPx in the same way which helped improving the Quality for every Application and for every user involved in the Ecosystem) though it seems AMD cared more about exclusive stuff and keeping it down to a minimum ISVs @ first (for a very long time) and for Linux it seems even heavier restricted.
I can mostly only speak about Nvidia and they did everything right from the first day strategy wise without hurting the business aspects to much (on the Desktop) and Utilized the Power of the Community as best as possible (with braking down the NDA ISV barriers really fast without hurting anyone else to much and also seeing more the mostly positive things then negative ones that would arise from that "Openness" i can only congratulate the brain behind this decissions @ Nvidia) which in the end made everyone happy and be part of that Software/Hardware Ecosystem :) (ISVs,Consumer,non ISV Developers,Geeks)
AMD reacted a little slow (and the hell its absolute sad seeing that they have the more Powerful Hardware @ Hand also because many Developer made them aware that it would be good to have that support and saw the demand from users for it early on as Nvidia came up with it,on the other side most resources where going @ that time into Fusion and how to integrate ATI efficiently as possible into their future concept), its almost predictable that Fusion would have a much better adoption rate with such a "Open" available Ecosystem to mostly everyone and we can see AMD is trying to speed up their now again at least on the Win32/64 side finally, it's sad for the Linux part though and that Nvidia is still much stronger their in terms of overall Developer support as you explained it.


Btw everyone of the P67 Board buyers forget what reviews are telling you that Intels QuickSync would never work if a discrete GPU is being used that is not true it is either a Bios Restriction or a a Software lock on the OS Driver level but not has anything todo with a Chipset Hardware limitation thing.
Intel is doing since several years now allot on Software Restriction research @ their Hardware level they started this with making several things remotely available last year via a service call on their Motherboards and even the lower price Pentium Chips (upgrade it via a call to a higher series no problem). The same they did this time on the P67 series of Boards see this proof talk by some Intel guy http://www.youtube.com/watch?v=gui_6sNc7Eo
Intel is fully in the concept of DRMing their Hardware for Business purposes now, so yes who knows how its working on the Chip site and if the same Series is restricted the same way by a clever combination of Bios,Key,Motherboard and Operating System the same as they bringing in TPM now to finally make Hollywood being able to provide full 1080p experience On Demand and without any time differences to a Cinema release, as they feel save now with Microsoft and Intels TPM Ecosystem (we will see how long that holds up though) :)
Please also keep in mind i don't say its possible without this Lucid Virtu (Framebuffer copying under Vista/Win7 very efficiently doable as everything is on the GPU already though this most probably highers latency some ms again especial in Windows mode like shown in that Video so Gamers or people who think of Multi GPU data Displaying should be careful, though it is cool and indeed a dream i guess of everyone in the Consumer level to see that) to actually use both Discrete GPU/CPU together @ the same time that obviously isn't possible physically by the Hardware itself it's just the fact that their Software can see the QuickSync that makes it invalid that the P67 turns everything of via the Hardware, but Intels Software layer (Bios/OS Driver) is actually doing that and Lucid got the Permission to disable it to be able todo what you see inside that Video ;) or the other Logic assumption would be the Intel guy is actually mixing up stuff here (mixing up H67 with P67 though several times repeatedly) and all the reviewers like Anandtech are correct if they say P67 doesn't support the Intel QuickSync GPU feature @ all (the information they get from intel and all believe to be true, the motto being better don't think believe everything my partner tells me and put that into public) you decide what is the truth ;)

Now to make it even more Confusing ;)

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

To demonstrate the technology Intel ran an H67 motherboard with a GeForce GTX 480. Lucid’s software was installed which allowed for the GTX 480 to run and its frame buffer output to be copied to main memory and sent out via Intel’s Flexible Display Interface through the DVI port on the back of the motherboard.

So the newest Intel innovation a Auto Switching Chipset Board inside this Machine ;) http://www.youtube.com/watch?v=t81xbq53WIA

[deadrats]

alright everyone, as promised i conducted a test encode and i'm uploading the results for everyone to see. for source i went here:

http://www.demo-world.eu/trailers/high-definition-trailers.php

and downloaded "The Gorgeous Ocean World" demo under the "HDclub" heading. i think this source is a good test because it's a nice 1920x1080p29.97 blu-ray source, it only uses a nominal bit rate of 8.34 mb/s, has lots of good motion, lots of vibrant colors, so it makes a good test for any encoder. it also uses 256 kb/s ac3 audio.

for a target, i chose 1280x720p29.97 mkv, with 128 kb/s audio.

for bit rate i did the following: i calculated a per pixel bit rate for the 1080p source, works out to .134 bits/pixel and derived a nominal bit rate for the target encode of 3.7 mb/s for the video portion, all encodes were done using cbr.

i did test encodes with the default settings for x264 and cuda (remember, i don't speak japanese) and i through in a special treat. tmpg express 5 allows you to use the media sdk encoder in software mode if you don't have a QS enabled processor installed. i did a test encode with this as well, it was slow as hell but it should be indicative of the quality of the encodes QS will offer.

note: it appears that quick sync is little more than a hardware accelerated version of the IPP encoder, the only commercial app that uses IPP, as far as i know, is gom encoder (in addition to the default x264 encoder) and in numerous tests i found there to be no quality difference between the IPP encoder and x264, they pretty much traded punches, under some tests x264 showed slightly better quality under other tests IPP showed slightly better quality.

the big benefit of IPP was that it ran like stink on a monkey with an intel cpu: using a quad core phenom 2 x264 was easily twice as fast as IPP, using a dual core penryn (E7400) IPP smoked x264. this really shouldn't be surprising considering IPP stands for "intel performance primitive".

the source runs 4:05 long, x264 took 13:35 and cuda took 8:17, intel media sdk software encoder brought up the rear with a super slow 44:39.

you can download the finished encodes here:

cuda
http://www.mediafire.com/?0dy2c1n8mjy6rj1

media sdk
http://www.mediafire.com/?6xp933gxj2xtt9e

x264
http://www.mediafire.com/?rcc9yb3elv4ahag

from a quality standpoint, i would put the x264 encode and the cuda encode as overall equal, in certain parts x264 seemed to hold a minor edge in visual quality, in other parts it appeared to me that the cuda encoder produced the better results, overall i would call it a tie.

the sdk encoder was an interesting case: the over all impression i got was that it produced a slightly lower quality than either x264 or cuda but that it produced more vibrant colors.

my guess is if someone wanted to nitpick one could find frames from each encode to support the claim that any of the encoders was better than the other two.

the reality is that 3.7 mb/s for 720 is ridiculously low, people usually capture hdtv at 12-18 mb/s and let's be honest with ourselves and point out that 8.3 mb/s is atrocious for 1080p, if we had the original source, straight from the camera (not a previously compressed source), we could get much higher quality encodes with all 3 encoders, even at 3.7 mb/s for 720p.

quite frankly, most people do not have access to uncompressed or losslessly compressed film transfers, what most people have is blu-rays that they "backup" (i.e. steal, pirate, "fair use" copy) or the have hdtv captures or they have footage shot on consumer grade camcorders.

these people won't be transcoding down to 3.7 mb/s for 720p (unless they are complete imbeciles that have a "bit rate starve" fetish), they'll be using saner bit rates, at 5 mb/s for 720p any differences between the 3 encoders start to vanish and at what i consider the minimum for 720p, 8 mb/s, there is no difference at all.

as a test, i tried the cuda encoder at 720p 8 mb/s, just to see what kind of slow down could be expected, and the test encode finished in an almost identical 8 and a half minutes, while x264 slowed down to 14 and a half minutes.

this is definitely not a conclusive test, nor do i expect anyone to accept these results, i'm sure the criticism will fly from the x264 faithful, but it does seem like software based encoding is destined to go the way of the dodo.

[nurbs]

Why would you use CBR encoding?
And why do you thing 3.7 Mbps is ridiculously low for 720p? I do encodes at CRF 21 (veryslow, film, lvl 3.1, 3 b-frames) at that resolution and most of them come out below 3 Mbps. They look fine on normal viewing.

Edit:
By the way, you certainly didn't encode with x264 using it's defaults. The defaults aren't main profile with both trellis and b-pyramid disabled. They would be slower though.

[Mixer73]

So the newest Intel innovation a Auto Switching Chipset Board inside this Machine ;)

Its not auto switching, its copying the framebuffer back from the Nvidia card to the Intel for display, the limitations make it totally worthless.

[Mug Funky]

i'll chime in and ask why use bits/pixel? there is nothing that bits/pixel can meaningfully say about the actual source. and sources vary enormously.

my tests from HDCAM-SR sources (as near to uncompressed as anyone's likely to get without working straight from the original camera neg or the output of a grading workstation), just using x264 at crf 22 show a massive range of bitrates for different sources.

some (usually shot on RED in daylight, or at least adequate light) features will come in at about 3.5-4mbps for a 1080p24, and some (usually 16mm or a very fast/grainy 35mm) will come in at 20mbps+ at the same res. bits/pixel will not help there. even some HDCAM shot in studio conditions will have huge bitrate requirements due to oversharpening and the everything-in-focus effect of 1/3 inch sensors.

i'll also chime in and say that with these sources, casual viewing reveals little to no difference between x264 encodes at crf22 (which is on the "lower-quality" end) and sonic cinevision at blu-ray bitrates. critical viewing will reveal some grain oddities in x264, but bear in mind we're talking about a 3:1 size difference over the cinevision encodes.

[deadrats]

Why would you use CBR encoding?
And why do you thing 3.7 Mbps is ridiculously low for 720p? I do encodes at CRF 21 (veryslow, film, lvl 3.1, 3 b-frames) at that resolution and most of them come out below 3 Mbps. They look fine on normal viewing.

Edit:
By the way, you certainly didn't encode with x264 using it's defaults. The defaults aren't main profile with both trellis and b-pyramid disabled. They would be slower though.

1) i chose cbr because i wanted the fastest encode possible, i wanted to make sure the b frames would have adequate bit rate and since i don't speak japanese it was the easiest to figure out what was going on.

2) 3.7 mb/s, as i pointed out, works out to just .134 bits per pixel, considering uncompressed a pixel is an 8 bit "entity", using about 1/78th as any bits to represent the same data is stupid beyond belief.

when i said i used the default setting i should have added the defaults tmpg express 5 chooses for the encoders with 2 exceptions: it chooses "high" profile and 4.0 level, i changed that to "main" profile and 4.1 level, don't really know why, it just seemed like a good idea at the time.

as soon as i get an english version of the app i will be able to play around with the settings and really see what each encoder can do.

[deadrats]

i'll chime in and ask why use bits/pixel? there is nothing that bits/pixel can meaningfully say about the actual source.


it seems like the only logical method for choosing a target bit rate when down rezing, if your source of 1080p30 and the calculated per pixel bit rate is .5 bits per pixel, logic would dictate that if you wish to go to 720p30 and keep a comparable quality the target should use the same pixel/bit ratio, if you go higher then you are using too much bit rate as you can't add detail that isn't already there, if you use less bit rate you are bit rate starving the encode and killing the per pixel quality.

it's bad enough that you are losing about 1.1 million pixels per frame when you go from 1080p to 720p, why compound the quality lose by simultaneously reducing the per pixel bit rate?

the people that take a commercially encoded blu-ray, 1080p at 25-35 mb/s and transcode to 720p at < 4 mb/s and actually believe they know what they are doing or that their encodes are high quality productions are retards of the highest caliber, they should bared from using a computer until they squeeze their heads out of their cans.

[poisondeathray]

2) 3.7 mb/s, as i pointed out, works out to just .134 bits per pixel, considering uncompressed a pixel is an 8 bit "entity", using about 1/78th as any bits to represent the same data is stupid beyond belief.


You're disregarding content complexity and inter frame compression. Counting bits per pixel in video compression is next to useless. For example, a black frame will take a lot less to compress than a noisy detailed frame. A series of black frames will take a lot lot less than a detailed scene


You're also using a low quality source (8Mb/s for a 1080p blu-ray ? Come on WTF? ) I suspect using a higher quality source would show bigger differences, and it looks like you're deliberately using poor settings (or maybe it's just the japanese GUI)?


Does anyone else see the hiprocracy here? deadrats is calling dark shikari out for not being objective, and calling software based encoding dead, despite basing his "conclusions" on zero objective evidence


Come on guys, lets see some properly done objective testing.

[CruNcher]

Its not auto switching, its copying the framebuffer back from the Nvidia card to the Intel for display, the limitations make it totally worthless.

Ehh i didn't meant it that way it was sarcastic based on the different Stories (Intel Guy inside is a P67 Chipset) Anandtech (inside is a H67 Chipset) both @ the same time would be the Z68 Chipset ;)

[Mug Funky]

it's bad enough that you are losing about 1.1 million pixels per frame when you go from 1080p to 720p, why compound the quality lose by simultaneously reducing the per pixel bit rate?

the people that take a commercially encoded blu-ray, 1080p at 25-35 mb/s and transcode to 720p at < 4 mb/s and actually believe they know what they are doing or that their encodes are high quality productions are retards of the highest caliber, they should bared from using a computer until they squeeze their heads out of their cans.

i wasn't aware we were resizing in these tests.

as far as scaling quality per pixel dimensions, a simple linear relation may help, but will not tell the whole story (ie, you are using fixed block sizes, which means you'll be proportionally increasing the high-frequency content as well, making compression and lossless-coding of compressed data less efficient in a nonlinear manner).

my approach (which i'll admit is slightly naive, but is more robust than bit/pel) is to simply find a crf i like the look of, and encode everything at that. x264 will decide the bitrate, which scales somewhat linearly with pixel dimension, but not quite (smaller frame sizes need a fair bit more per pixel). i think that TMPGenc has a constant quality setting, though being in japanese could be an issue of course (there wasn't an english translation yet? wow).

one very obvious alternative though - use the freaking vanilla x264 that everyone else uses! why complicate things with TMPGenc at this point? (a) you don't know how to use it by your own admisson, and (b) nobody else has it yet, and so verification is difficult.

use a build from here:

http://x264.nl/

also, an adult BD as a test? those are almost exclusively shot on HDV, with fast motion, and (according to various sources) they often use lenses specifically designed to soften away the ugly truth of what sex looks like close-up. in this situation of loads of blocks, double-compressed source (starting in-camera as mpeg-2), and soft source it's no wonder CUDA and x264 look the same.

[kolak]

i'll also chime in and say that with these sources, casual viewing reveals little to no difference between x264 encodes at crf22 (which is on the "lower-quality" end) and sonic cinevision at blu-ray bitrates. critical viewing will reveal some grain oddities in x264, but bear in mind we're talking about a 3:1 size difference over the cinevision encodes.

Cinevision is not the greatest encoder, but hard to believe that x264 can do the same at 3x smaller file sizes.

Are both encodes BD compliant?

Andrew

[kolak]

also, an adult BD as a test? those are almost exclusively shot on HDV, with fast motion, and (according to various sources) they often use lenses specifically designed to soften away the ugly truth of what sex looks like close-up. in this situation of loads of blocks, double-compressed source (starting in-camera as mpeg-2), and soft source it's no wonder CUDA and x264 look the same.

I was not interested in CUDA encoders at all, because x264 outperforms them massively? Is this has changed?

Andrew

[deadrats]

You're also using a low quality source (8Mb/s for a 1080p blu-ray ? Come on WTF? ) I suspect using a higher quality source would show bigger differences, and it looks like you're deliberately using poor settings (or maybe it's just the japanese GUI)?

i'm with you, i'm the one that's been calling for using enough bit rate for an encode, but i wanted to use a source that could easily be shared with you guys (to see the "control" sample) and if that 8 mb/s 1080p is a first generation encode, then it's really not too bad.

if you have a higher quality source that can easily be shared with everyone here, then post a link.

as for deliberately using poor settings, as i said i don't speak japanese, i can't read japanese, i just was able to figure out how to use the default settings because i recognized the basic layout from previous versions of the software.

Does anyone else see the hiprocracy here? deadrats is calling dark shikari out for not being objective, and calling software based encoding dead, despite basing his "conclusions" on zero objective evidence

DS is hardly objective, nor are his "followers". in any encoding test done where x264 hasn't been shown to be the clear, conclusive winner, DS has spent pages attacking the tester, his methodologies, the chosen source, a look through this forum and his "diary of an x264 developer" will find one diatribe after another complaining about testers that failed to find his "baby" the undisputed champion.

if you really want to see hypocrisy, read through his rants and then read his suggested methodologies for conducting an encoder test and you will see him recommend end users do the exact same thing that he rips other testers for doing.

Come on guys, lets see some properly done objective testing.

i wasn't objective?!?

i uploaded the test encodes and linked to the source so that you guys can see for yourselves, how much more objective could i be?

feel free to conduct your own, better, test and feel free to post the results.

[deadrats]

also, an adult BD as a test? those are almost exclusively shot on HDV, with fast motion, and (according to various sources) they often use lenses specifically designed to soften away the ugly truth of what sex looks like close-up. in this situation of loads of blocks, double-compressed source (starting in-camera as mpeg-2), and soft source it's no wonder CUDA and x264 look the same.

actually adult BD, believe it or not, have some of the highest quality encodes i have ever seen, i have blu-rays that are so crystal clear you can literally see the pores on the chicks face, you can see the tiny, very fine hairs on her ass, hell i have adult BD's that are so clear that i'm sure a doctor could perform a thorough visual examination of the performer.

yes, some studios and directors use a soft lens, but some studios shoot exclusively with sony's RED, i have a 720p encode of "the devil in misses jones, resurrected" that is so clear you would think you are standing there as it's being shot.

feel free to download the japanese version of the software, and if you can figure out how to use it, conduct your own tests:

http://tmpgenc.pegasys-inc.com/ja/product/tvmw5.html

[Mixer73]

yes, some studios and directors use a soft lens, but some studios shoot exclusively with sony's RED, i have a 720p encode of "the devil in misses jones, resurrected" that is so clear you would think you are standing there as it's being shot.

Considering your consumption of said material is it cheeky to question your eyesight?

:devil:

[poisondeathray]

DS is hardly objective, nor are his "followers". in any encoding test done where x264 hasn't been shown to be the clear, conclusive winner, DS has spent pages attacking the tester, his methodologies, the chosen source, a look through this forum and his "diary of an x264 developer" will find one diatribe after another complaining about testers that failed to find his "baby" the undisputed champion.

if you really want to see hypocrisy, read through his rants and then read his suggested methodologies for conducting an encoder test and you will see him recommend end users do the exact same thing that he rips other testers for doing.



Fair enough, but lets stick to FACTS using proper testing methodology. But criticizing the methology used IS valid (You arrive at incorrect conclusions if your methodology isn't sound), criticizing the person (just because) isn't.

And if you don't agree with the guy doesn't mean you have to attack him. Try to be a better person, even though he might not be. Present your evidence in a more scientific objective manner and you will be more convicing than you have been thus far.




i wasn't objective?!?

i uploaded the test encodes and linked to the source so that you guys can see for yourselves, how much more objective could i be?

feel free to conduct your own, better, test and feel free to post the results.

Sorry, perhaps that's stated too strongly. Perhaps you tried to be objective , but the testing methods could be improved.

As mentioned there were problems with

- the settings used (CBR?, main profile? )

- other filters (you're testing ENCODERS, don't complicate matters by testing resizing or audio) . Mug Funky had a good suggestion, just use x264.exe

- source quality. Here people are mentioning blu-ray this , blu-ray that, but a 8Mb/s 1080p source isn't going to test much. Your average retail blu-ray would be ~20-30Mb/s

- ideally, a range of bitrate encodes and different settings would be tested (so you could test max quality, or speed at a given quality etc...) . People have different requirements. Some people want every single bit of compression or top quality at any speed. Some people want speed over quality etc....

At least it's better than Anandtech's single frame resized screenshot. Thanks for sharing the results so far :)

[shon3i]

sorry but @deadrats

http://www.redstate.com/neil_stevens/files/2009/09/doublefacepalm.jpg

[nurbs]

1) i chose cbr because i wanted the fastest encode possible
CBR shouldn't have much influence on speed, if any. While encoding speed depends on the bitrate, with entropy encoding in particular, intuitively there shouldn't be much difference between a CBR and an ABR encode at the same bitrate since it should even out.
considering uncompressed a pixel is an 8 bit "entity"
I might be wrong, but I think that uncompressed 4:2:0 should work out as 12 bits per pixel.
the people that take a commercially encoded blu-ray, 1080p at 25-35 mb/s and transcode to 720p at < 4 mb/s and actually believe they know what they are doing or that their encodes are high quality productions are retards of the highest caliber, they should bared from using a computer until they squeeze their heads out of their cans.
I get the feeling that this is at least partially directed at me.
As I have stated with my preferred settings my 720p encodes from Blu Ray usually come out smaller than 4 Mbps. I arrived at my settings by testing the presets to figure out what speed I'm comfortable with and then selected a CRF that delivers adequate quality with those settings. With my settings details are kept well and I do not notice artifacts at all during normal viewing. You might have a different opinion on what constitutes adequate quality or encoding speed, but have no justification to call other people retards because of their choices on something that essentially comes down to personal preference.

By the way, the source you selected was itself encoded with x264 (r1292). While the encode isn't too bad, there is some blocking which isn't surprising since a high detail underwater shot is a complex source to begin with. If you want a high detail uncompressed source Parkjoy (http://media.xiph.org/video/derf/y4m/1080p/) is always nice.

[nm]

DS is hardly objective, nor are his "followers". in any encoding test done where x264 hasn't been shown to be the clear, conclusive winner, DS has spent pages attacking the tester, his methodologies, the chosen source, a look through this forum and his "diary of an x264 developer" will find one diatribe after another complaining about testers that failed to find his "baby" the undisputed champion.

if you really want to see hypocrisy, read through his rants and then read his suggested methodologies for conducting an encoder test and you will see him recommend end users do the exact same thing that he rips other testers for doing.
You mean this (http://x264dev.multimedia.cx/archives/472)? I thought you were a native English speaker?

[deadrats]

And if you don't agree with the guy doesn't mean you have to attack him. Try to be a better person, even though he might not be. Present your evidence in a more scientific objective manner and you will be more convicing than you have been thus far.

this isn't meant as an "attack" on DS, what annoyed me is his tendency to dismiss technology as "useless" before it's even widely available, what annoys me more is when he dismisses technology as "useless" when the very company that is the first to license his software also offers a product that proves his claims aren't entirely true (hell, if you read carefully what he said he practically ripped pegasys for including "shit" software, when they were the first and only ones that allow him to put some dough in his pocket) and what's most annoying of all is the fact that people with zero programming experience at all, who by their own admission don't even know what QS is or how it works, declare unilaterally that technology x sucks because that's what they heard from DS.

it drives me up the wall, it really does.

as far as this test is concerned, yes, it's by no means conclusive or decisive, but choosing a front end package like tmpg express does allow for uniformity in testing:

1) it allows all 3 encoders to be used with the exact same resize filter, and down rezing is a very common approach when transcoding video, as people try to maximize final quality and/or target a particular device.

2) using the x264 encoder that comes with tmpg express is very valid because it's the first and only commercially licensed application of the encoder, it standardizes results by eliminating any inconsistencies introduced by compilation options, compiler used or modifications to the source or command line parameters introduced by the person building the executable. furthermore, it's the only version that puts a dime in DS pocket, it's the only one you have to pay for and thus it's the standard by which other versions should be compared.

3) it standardizes the decoder used, using a different front end would invariably result in using a different decoder, thus skewing the results.

4) when the english version is released i plan on doing extensive testing and posting the results.

[deadrats]

I get the feeling that this is at least partially directed at me.
As I have stated with my preferred settings my 720p encodes from Blu Ray usually come out smaller than 4 Mbps. I arrived at my settings by testing the presets to figure out what speed I'm comfortable with and then selected a CRF that delivers adequate quality with those settings. With my settings details are kept well and I do not notice artifacts at all during normal viewing. You might have a different opinion on what constitutes adequate quality or encoding speed, but have no justification to call other people retards because of their choices on something that essentially comes down to personal preference.


actually it wasn't directed at any one person, more at the notion that a 720p 4 mb/s encode can possibly be of equal quality to a 30 mb/s 1080p, no matter which encoder you use.

from a mathematical point of view, it's just plain silly.

[poisondeathray]

this isn't meant as an "attack" on DS, what annoyed me is his tendency to dismiss technology as "useless" before it's even widely available, what annoys me more is when he dismisses technology as "useless" when the very company that is the first to license his software also offers a product that proves his claims aren't entirely true (hell, if you read carefully what he said he practically ripped pegasys for including "shit" software, when they were the first and only ones that allow him to put some dough in his pocket) and what's most annoying of all is the fact that people with zero programming experience at all, who by their own admission don't even know what QS is or how it works, declare unilaterally that technology x sucks because that's what they heard from DS.

it drives me up the wall, it really does.



OK. So lets find the truth then.

But what does that dismissing "that technology" have to do with "his software". They are different encoders included in the same GUI.

Also, just because some commercial software decides to include an encoder (of any origin) , indicates nothing. You've stated this a couple times already, and I don't see the point you're trying to make


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.



First of all , what proof?

2nd just because some consumer grade software includes an encoder proves.... what ?

For example , have you seen the "great quality" (I'm being sarcatic for non native english speakers here) of Sony Vegas AVC ?

Just because a commercial software decides to include several encoders, do they all have to be good ? or all have to be bad? I don't see the relationship here?



as far as this test is concerned, yes, it's by no means conclusive or decisive, but choosing a front end package like tmpg express does allow for uniformity in testing:

1) it allows all 3 encoders to be used with the exact same resize filter, and down rezing is a very common approach when transcoding video, as people try to maximize final quality and/or target a particular device.


But be careful how you extend your conclusions. You're no longer testing only the encoder. You're testing a workflow with filters and audio encoding.

This basic science 101. You cannot come to the conclusion that x encoder performs (such and such) when you start to include other variables. For example, there may be bottlenecks introduced.

If you're doing this type of testing, your conclusions are only valid for that specific scenario. Be careful how you phrase you conclusion.


2) using the x264 encoder that comes with tmpg express is very valid because it's the first and only commercially licensed application of the encoder, it standardizes results by eliminating any inconsistencies introduced by compilation options, compiler used or modifications to the source or command line parameters introduced by the person building the executable. furthermore, it's the only version that puts a dime in DS pocket, it's the only one you have to pay for and thus it's the standard by which other versions should be compared.


OK, but again, your testing then is only valid for specific scenarios. You're no longer testing the VIDEO ENCODER only. You're testing multiple variables like audio., It's hard to come to a scientific conclusion when you have all these other variables.

For example, TMPG converts to RGB for all encodes (at least older versions did), this results in slower encoding, lower quality than if you would have stayed in the same colorspace



3) when the english version is released i plan on doing extensive testing and posting the results.

Great, thanks for sharing so far

[Didée]

in this situation of loads of blocks, double-compressed source (starting in-camera as mpeg-2), and soft source it's no wonder CUDA and x264 look the same.
And even in this situation, they don't look the same. Disregarding the fact that CUDA actually used 120kbps more than x264, you can clearly see more than enough artifacts that x264 doesn't have.
(Do I really need to post screens? Look at --just e.g.-- 0:38-0:45, the fish in the background. CUDA is truncating fishs into two halfs, and that sort of things!)

Sidenote, not relevant, but ... the first time I played the first sample, when the first oceanground appeared on the screen, I immediately saw .... YADIF, or s'th with similar edge-interpolation, has been used to deinterlace the original recording. How can people use such deinterlacing and NOT notice the unnatural "vectorization" of textures...? :cry: :cry: :cry:


@ deadrats
Related to speed, may i ask what are the specifications of the PC you did the encodings with? It's a quadcore? Just wondering, you noted it took 13:35 for the x264 encode. I did an encode with Hybrid (which uses standard x264, resizing through mencoder, audio encoding via aften) on my i7-860 (@2.8=stock), with the same x264 settings as used by tmpgenc (derived from stream metadata).

The whole process took 4:30.

It doesn't matter for the relative speeds, from one encoder to the next. But the absolute speeds in your test seem to be somewhat (s)low...

[poisondeathray]

@ deadrats
Related to speed, may i ask what are the specifications of the PC you did the encodings with? It's a quadcore? Just wondering, you noted it took 13:35 for the x264 encode. I did an encode with Hybrid (which uses standard x264, resizing through mencoder, audio encoding via aften) on my i7-860 (@2.8=stock), with the same x264 settings as used by tmpgenc (derived from stream metadata).

The whole process took 4:30.

It doesn't matter for the relative speeds, from one encoder to the next. But the absolute speeds in your test seem to be somewhat (s)low...


He said AMD setup, but didn't say if it was overclocked or stock


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

[deadrats]

just did 2 more test encodes, for source i replicated the very commonly used x264 hd benchmark found here:

http://www.techarp.com/showarticle.aspx?artno=520

i used the included mpeg-2 source, 30 sec duration, 3950 kb/s, 23.97fps, 720p, 384 kb/s audio and transcoded using both the x264 and the cuda encoder (again japanese version of tmpg express 5), ac3 audio 128 kb/s, mkv, 720p, 23.97, main, 4.1, 3950 kb/s (looked through the testing script, same bit rate, level and profile settings), x264 took 1:20 to finish the encode, cuda took 31 seconds, i for one see no difference between the two encodes:

cuda
http://www.mediafire.com/?evnfks434d28wij

x264
http://www.mediafire.com/?n6gd0gqraadw2bn

[Blue_MiSfit]

deadrats,

I wrote this before your latest post, havent even looked at the current test
Thanks for sharing your results. It looks like the defaults in TMPGEnc are quite poorly chosen. They're difficult to compare with because of the advertising it burns into the video while still in trial mode.

I think any comparison at this point involving TMPGEnc is basically invalid because of this factor. Once they release the English version, maybe someone will buy it and we can have an honest look without their logo screwing up our compression tests ;)

By the way, 4mbps average is not "low bitrate" for 720p at all, in my opinion - especially if there are no obnoxious restrictions like short GOPs, tight VBV values / CBR etc. Sure, it may not produce results that are 100% transparent (for sources that actually require keeping 1080p for full details), but it can look QUITE good. 4mbps 1080p is more challenging, and should separate the wheat from the chaff when it comes to encoders!

The source you chose is a bit suboptimal for testing in my opinion. As someone else mentioned, it was actually encoded by x264 originally! :) It also has some compression artifacts, though it's not HORRIBLE quality.

Next time we do some testing with TMPGenc, hopefully some good challenging source will be chosen. Parkjoy has been mentioned several times, though honestly any good true BluRay source would be a good choice. Baraka is a personal favorite of mine, as is Avatar.

Anyway, let's all not read too much into the test. I'd agree all those clips look pretty good.

On a personal note, everyone please watch your tone. We don't tolerate personal attacks here.

Rule 4: Be nice to each other and respect the moderator. Profanity and insults will not be tolerated. If you have a problem with another member turn to the respective moderator and if the moderator can't help you send a private message to Doom9.

Everyone has their bias, but there's no "cult of x264". I'll admit I tend to be biased towards it, but that's only because I've literally never seen anything that can beat it. If something out there does a better job for a certain case, I'm all over it.

Transcoding for sync is a very interesting goal.

1) Here, you don't REALLY care how big an output is, provided it's not TOOOOO big, since you will probably watch it once or twice then throw it away.
2) You DO want it to transcode as quickly as possible, and you DO want it to look good.
3) In x264 to achieve this goal when syncing for my iPhone, I use (for HP@3.1) --preset superfast --tune film --crf 18 --vbv-maxrate 17500 --vbv-bufsize 17500. Maybe ultrafast if I'm feeling masochistic.

It's certainly possible to do this VERY quickly with a CUDA encoder. I'm sure with a 1080p H.264 source, the decode / scaling becomes the bottleneck rather quickly. Presumably x264 properly fed with a threaded decoder and scaler would run very quickly as well, by comparison.

It's hard to say without having access to the proper software. We shall see!

Derek

[weasel_]

Use stupid settings and make excuse like , tmpg express is in japanese ....
If u cant use tmpg in proper way then don`t do test like his becosue they tell nothing

i think this source is a good test because it's a nice 1920x1080p29.97 blu-ray source, it only uses a nominal bit rate of 8.34 mb/s,


:eek:

Yea , big percent of sources is like 8mb/s

x264 vs cuda results where posted over and over again. We want to compare QuickSyncs Quality/Speed here and not CUDA vs X264 again :(
+1

[CruNcher]

deadrats,

I wrote this before your latest post, havent even looked at the current test
Thanks for sharing your results. It looks like the defaults in TMPGEnc are quite poorly chosen. They're difficult to compare with because of the advertising it burns into the video while still in trial mode.

I think any comparison at this point involving TMPGEnc is basically invalid because of this factor. Once they release the English version, maybe someone will buy it and we can have an honest look without their logo screwing up our compression tests ;)

By the way, 4mbps average is not "low bitrate" for 720p at all, in my opinion - especially if there are no obnoxious restrictions like short GOPs, tight VBV values / CBR etc. Sure, it may not produce results that are 100% transparent (for sources that actually require keeping 1080p for full details), but it can look QUITE good. 4mbps 1080p is more challenging, and should separate the wheat from the chaff when it comes to encoders!

The source you chose is a bit suboptimal for testing in my opinion. As someone else mentioned, it was actually encoded by x264 originally! :) It also has some compression artifacts, though it's not HORRIBLE quality.

Next time we do some testing with TMPGenc, hopefully some good challenging source will be chosen. Parkjoy has been mentioned several times, though honestly any good true BluRay source would be a good choice. Baraka is a personal favorite of mine, as is Avatar.

Anyway, let's all not read too much into the test. I'd agree all those clips look pretty good.

On a personal note, everyone please watch your tone. We don't tolerate personal attacks here.

Rule 4: Be nice to each other and respect the moderator. Profanity and insults will not be tolerated. If you have a problem with another member turn to the respective moderator and if the moderator can't help you send a private message to Doom9.

Everyone has their bias, but there's no "cult of x264". I'll admit I tend to be biased towards it, but that's only because I've literally never seen anything that can beat it. If something out there does a better job for a certain case, I'm all over it.

Transcoding for sync is a very interesting goal.

1) Here, you don't REALLY care how big an output is, provided it's not TOOOOO big, since you will probably watch it once or twice then throw it away.
2) You DO want it to transcode as quickly as possible, and you DO want it to look good.
3) In x264 to achieve this goal when syncing for my iPhone, I use (for HP@3.1) --preset superfast --tune film --crf 18 --vbv-maxrate 17500 --vbv-bufsize 17500. Maybe ultrafast if I'm feeling masochistic.

It's certainly possible to do this VERY quickly with a CUDA encoder. I'm sure with a 1080p H.264 source, the decode / scaling becomes the bottleneck rather quickly. Presumably x264 properly fed with a threaded decoder and scaler would run very quickly as well, by comparison.

It's hard to say without having access to the proper software. We shall see!

Derek

What i absolutely don't understand is testing Tmpegencs Cuda (they just implemented the nvcuvenc API) it's nothing else then Nvidias Encoder and that results where posted over and over again in the "Taking submissions thread" also the Encoder is dependent on the Driver and some Drivers can cause Encoding bugs (nvcuvenc.dll is the encoder). And yeah @ high bitrates Nvidias Encoder is ok but with High complex source and @ the resolution edge bitrate it can't cope with x264 @ subme 1 and diamond search (which it uses itself). We want to compare QuickSyncs Quality/Speed here and not Nvidias Encoder vs X264 again :(

[aegisofrime]

Wake me up when TMPGenc v5 English is out. I might indeed be getting a Core i7-2600K and thus can give Quick Sync a whirl for all of you.

EDIT: Oh wait, I'm getting a P67 motherboard. So I can't use Quick Sync. Damn you Intel. What's wrong with you?

[Didée]

We want to compare QuickSyncs Quality/Speed here and not Nvidias Encoder vs X264 again :(
Yes, you're right. There really is
http://img801.imageshack.us/img801/6594/11cuda01308.th.png (http://img801.imageshack.us/i/11cuda01308.png/) http://img828.imageshack.us/img828/8872/12x26401308.th.png (http://img828.imageshack.us/i/12x26401308.png/) (Do the flip-flop!)
no need to compare x264 with CUDA.

However - if someone is concluding "CUDA and x264 look same good", then it makes me wonder ...

[kypec]

Yes, you're right. There really is
http://img801.imageshack.us/img801/6594/11cuda01308.th.png (http://img801.imageshack.us/i/11cuda01308.png/) http://img828.imageshack.us/img828/8872/12x26401308.th.png (http://img828.imageshack.us/i/12x26401308.png/) (Do the flip-flop!)
no need to compare x264 with CUDA.

However - if someone is concluding "CUDA and x264 look same good", then it makes me wonder ...
Shame on you Dideé, how dare you say something like that!
deadrats is obviously right here: CUDA encoder is at least twice as good as x264 because everybody can see that there are twice as many fish in the background as they were in the source!
Case closed, the winner had been picked objectively. :p

[deadrats]

deadrats is obviously right here: CUDA encoder is at least twice as good as x264 because everybody can see that there are twice as many fish in the background as they were in the source!
Case closed, the winner had been picked objectively. :p

i don't believe i ever said the cuda encoder included with tmpg express is twice as good as x264 and in fact i said that if one so desired one could find some screenshots to support the claim that one was slightly better than the other.

what i did say was there was little to no perceptible difference quality wise and that if one was to use a sane bit rate any differences would disappear.

considering SD dvd uses a video bit rate of 9800 kb/s (for professionally encoded dvd), with only 720x480 pixels per frame (yes, they use mpeg-2), using just 3.7 mb/s for 1280x720 pixels is absurd, as is using 8 mb/s for 1920x1080 pixels, i don't care what compression standard or encoder settings are used.

consider this, if you bought a membership to a site that allowed you to download hd tv shows or movies (like an itunes) and you found out that their hd was 720p @ 3.7 mb/s, would you be happy?

how about if you hired someone to professionally record your wedding or other similar event and supply BD to all the guests, and then you found out that the BD's were encoded at 4mb/s 720p or 8 mb/s 1080p and he said "oh, i encoded it with x264, so that's plenty of bit rate", would you pay him or force feed him the BD's?

how about if you want to capture the super bowl, are you going to capture at the highest bit rate your capture card is capable of or are you going to use x264 and stick with 720p @ < 4 mb/s?

as DS pointed out in his guide using too little bit rate and concluding that one encoder is better than another is stupid and counts as cheating.

lastly, i noticed no one commented on the media sdk encode, which is ultimately the topic of this thread and comparison.

[kieranrk]

consider this, if you bought a membership to a site that allowed you to download hd tv shows or movies (like an itunes) and you found out that their hd was 720p @ 3.7 mb/s, would you be happy?

Have a guess what kind of bitrates iTunes uses?

[deadrats]

Have a guess what kind of bitrates iTunes uses?

don't tell me they're 4 mb/s 720p? omg, what a rip off!

[mariush]

deadrats, bitrate is not really a good indication of quality of some material.

It depends on the compression technology, the features the codec has and lots of other things.

For example, I could capture a 1 hour video at 720p or 1080p of me typing something on my desktop or playing a game like Transport Tycoon Deluxe (which has plenty of repetitive textures and is 2D) and then I could get great results encoding lossless this at about 100-200kbps using Camtasia's Screen Codec or anything else designed for this, but I would probably be upset with the quality of h264 at 500 kbps.

I could also film 2 hours of a presentation or a speech, and I could get away with 2mbps at 720p because it's just a person speaking on stage and not much movement, so h264 could really shine.... on the other hand if it's a football match then yes, you would need plenty of bitrate.

You're saying 720x480p MPEG2 was at 9 mbps - this is an old codec, with some features that would bring more quality per bitrate restricted and with other features limited, due to the DVD specification.

I think that you'd agree with me that were you to encode this 720x480 content with plain old MPEG, you'd probably need 15-35 mbps to retain the quality. So if the bitrate went down from 15-35 to about 10 when going from MPEG to MPEG2, why is it so hard to believe you can encode 30% more at 50% less bitrate and get great quality, from the h264 codec?

720p at 4 mbps can give you excellent quality, if those videos are encoded using quality settings and a decent encoder, which isn't hampered by settings to decode fast (cavlc vs cabac), to lower buffering time and so on.

For example, Youtube's quality could be way better at the bitrates they use, but they try to design their encoding presets so that a 720p or an 1080p can be decoded on various game consoles, telephones and low performance pcs.

[Didée]

Continuation of "Beating a Dead Horse" ....

in fact i said that if one so desired one could find some screenshots to support the claim that one was slightly better than the other.
Except for the fact that you don't really need to "search" in order to "cherry pick" a frame that makes CUDA look bad. The truth is much more simple - Cuda IS bad.

Perhaps you're not fully aware of the technicals behind. It is not that encoding per GPU would be inherently fast because GPUs are oh so fast and oh so parallel. Fact is that GPUs can do certain operations at extraordinary speeds .... most of which, alas, do not apply to video encoding.

The *major* reason why GPU encoders are as fast as they are is: usage of very simple algorithms. If you do only very few computations, then you can compute very fast. THAT is what CUDA encoder is doing. And that's what the result is looking like.

Take a 2600K, and let x264 encode some 720p with "--superfast". You'll surely get more than 150fps. Well possible that you might see 200fps.
And it will still look better than a CUDA encode. Yes, it will. And surely it will not look worse than QuickSync. Probably still better.

(Yes, the last paragraph is pure speculation. But you can call me back on this by the time when the real tests will come up. With pleasure.) :)



lastly, i noticed no one commented on the media sdk encode, which is ultimately the topic of this thread and comparison.
Looking from far, it doesn't fall apart in the same obvious way as the CUDA encoding. But still ...

Extension to the above flip-flop:
http://img834.imageshack.us/img834/9914/13intelmediasdk01308.th.png (http://img834.imageshack.us/i/13intelmediasdk01308.png/)

And this took roughly 4 times longer to encode than x264? Interesting!

[aegisofrime]

And this took roughly 4 times longer to encode than x264? Interesting!

I'm guessing that's because deadrats doesn't actually have a Sandy Bridge CPU. I wonder what happens when Intel Media SDK runs on a non-Sandy Bridge CPU, and whether the algorithm is similar to Quick Sync.

[deadrats]

Continuation of "Beating a Dead Horse"

perhaps you're a sadomasochist with a bestiality fetish, i believe they have a cure for that now.

Except for the fact that you don't really need to "search" in order to "cherry pick" a frame that makes CUDA look bad. The truth is much more simple - Cuda IS bad.

that's really a matter of opinion, most people that have responded (both here and the video help forums) seem to be of the opinion that the encodes were close and as i said, once the bit rate is upped to a decent rate, the differences disappear.

Perhaps you're not fully aware of the technicals behind. It is not that encoding per GPU would be inherently fast because GPUs are oh so fast and oh so parallel. Fact is that GPUs can do certain operations at extraordinary speeds .... most of which, alas, do not apply to video encoding.

The *major* reason why GPU encoders are as fast as they are is: usage of very simple algorithms. If you do only very few computations, then you can compute very fast. THAT is what CUDA encoder is doing. And that's what the result is looking like.

there are so many things wrong with what you just said that i could write a book explaining why you don't know what you are talking about.

concentrating on just the gt200 chip, it has 32 double pumped alu's per warp with 2 to 8 warps per chip (i'm doing this from memory, forgive me if i'm slightly off).

each alu is capable of executing one thread at a time and threads are coalesced implicitly within each warp.

any operation that can be executed by a cpu alu can be executed by a gpu alu, including boolean evaluations, such as the ones used in AI.

dx9 gpu's are fully programmable and are used to perform such complex tasks as blast dna sequencing, seti, encryption/decryption, virus scanning, fast fourier transforms, discrete and inverse discrete cosine transform, collision detection, 3d matrices, the list goes on.

the thought that gpu's are incapable of performing complex calculations is laughable to the extreme and easily disproven by looking at all the types of application accelerated by gpu's.

in fact, video encoding requires some of the least mathematically intensive calculations to perform, a fact born out by the reality that x264 uses mostly 8 bit integer operations, and few bigger than 16 bit integer operations (this comes straight from DS, in this very thread).

lastly, the claims you made concerning gpu accelerated encoders is easily disproven by the fact that gpu powered encoders exist in many forms: open cl based (there is an mpeg-2 encoder for the mac), dx9 based mpeg-2 encoders (a modified version of ffmpeg, that violates the gpl by not releasing the source code, that uses the vfw framework) and at least 4 separate cuda based encoders: main concept's cuda encoder (i'm almost positive this is the one tmpg uses), mc also has an open cl encoder, the adobe "mercury" engine (i believe developed by elemental, also licensed by cyberlink), sony's gpu avc (slow as hell, very poorly optimized).

Take a 2600K, and let x264 encode some 720p with "--superfast". You'll surely get more than 150fps. Well possible that you might see 200fps.
And it will still look better than a CUDA encode. Yes, it will. And surely it will not look worse than QuickSync. Probably still better.

at least you're admitting that you are pulling numbers out of thin air.

your claim however is one constantly used by the x264 faithful, but they conveniently ignore 2 things:

1) comparing a top of the line cpu to a midrange gpu is hardly fair, the proper comparison would be to a top of the line gpu.

2) a faster cpu would also benefit the gpu encoding times as it would be able to "push" the gpu harder, it could feed data and instructions to it faster (the cpu has a master/slave relationship with other processors in a system, same thing occurs with 2 or more cpu's, cpu 0 is master and the rest are slaves).

given how much faster cuda was in my tests, i have trouble believing that there is any fair scenario in which x264 could out speed a properly coded cuda powered encoder.

And this took roughly 4 times longer to encode than x264? Interesting!

it took that long because intel purposely disables simd optimizations if a non-intel cpu is detected, try it with an intel cpu then come talk to me about speed.

[deadrats]

I'm guessing that's because deadrats doesn't actually have a Sandy Bridge CPU. I wonder what happens when Intel Media SDK runs on a non-Sandy Bridge CPU, and whether the algorithm is similar to Quick Sync.

as i said, it appears that QS is little more than the IPP encoder being accelerated by dedicated hardware, i expect the algorithms used to be identical.

[weasel_]

this isn't meant as an "attack" on DS, what annoyed me is his tendency to dismiss technology as "useless" before it's even widely available,
and he is always right...
for cuda, for vp8 and now for sb....

i don't believe i ever said the cuda encoder included with tmpg express is twice as good as x264 and in fact i said that if one so desired one could find some screenshots to support the claim that one was slightly better than the other.


:confused:

i alrady told you
Find topic where 10+ people did x264 vs cuda and if u dont see big differencethen u are blind
if u cant find just say i will post picture here for you

And dont complaine about low bitrate...
There is no point comparing 720p@10+mbit like u want

what annoys me more is when he dismisses technology as "useless" when the very company that is the first to license his software also
haahah
what ?
He need to lie and glorifie cuda becouse same comapny who use cuda licence x264 softwre ?...( x264 is not his (DS) like u said ) ...

[SeeManRun]

Wow, I have finally finished reading this entire thread over 2 nights, very impressive discussion.

Couple thoughts regarding deadrats arguments:
1) When compressing content, it seems to me you have to take into account the player. For example, when DVD's first came out, the hardware required to decode them was expensive and complex. As computer technology advanced, and process shrinks took place, the hardware required to decode the same DVD got cheaper and easier to make. Now a cell phone can decode a full bit-rate DVD. Blu-ray is no different, and I think most of these hardware encoders are great for on the fly trans-coding of your media as you are about to leave on a plane to a device that has a small screen and low processing power. You can quickly re-size your 1080p blu-ray to iPad specs at 150 fps and get out the door and gone. You don't care about quality much, you just want the content. Now take something like your wedding film; do you really care if it is 150 fps or 5 fps? I doubt it and you will surely let your computer run overnight if you have to so you get the absolute best quality in a format that might be able to fit on a regular CD or DVD (blu-ray burners are not that popular). You could keep it in the original format, but x264 lets you shrink it down to a smaller size while keeping almost all that quality in place, and certainly more than the 150 fps encoder would do. Back to the beginning of this random thought; the hardware required to view my encodes is much higher than the hardware required to view the trans-coded work (meant for iPhone, iPad, Android...), so it is really not suitable to use it at extreme qualities for those platforms as you have to worry about battery life as well as how long it takes to encode. But if you want to sit down on your sofa and use your HTC to watch a film, you surely don't care about how much power your HTC is using, you only care about quality, and that is what x264 lets you do, and do so in a reasonably small file size that requires much greater hardware to view than to watch that regular blu-ray rip.

2) You mentioned hard drives are cheap so why care about using low bit-rate. This makes no sense. Yes they are cheap, but you will just fill them up that much quicker. I upgraded my machine (more on that below, stay tuned), and it had 8 sata ports available, but my case only has 4 drive bays. Yes I could fill it up with 2 TiB drives for a total of 8, then if i run out because my encodes are so big i can just start daisy chaining devices to the USB and so on... Or, take longer for my encodes and keep the size down so I can fit more movies on my drives. Just because something is cheap doesn't mean it should be wasted.

3) Lastly, what DS and his believers seem to be saying, is that hardware is limited by the hardware used. If quicksync is a hardware encoder that is fixed function, it can do somethings and it can do them very well, but if a new technique is found, or a new algorithm that does something better, that can't be programmed into the hardware. Cuda and openCL have a better shot since they are programmable, but it seems that if you want the quality, the speedup is not worth it, and not to mention what happens when the next batch of cards come out and you have to go ahead and optimize again. The beauty of software is it will run on a pentium 4, AMD Turion, or a Core i7 2600k; same quality same options, just different speeds. And when the next Intel chip comes out, x264 will benefit from whatever architecture improvements they put in to handle more threads, increase IPC or access memory more quickly. If he started from scratch and made a brand new encoder on Cuda to take advantage of a new video card, he will be closing the door on all the people that don't have that brand of card and won't get the benefits of his work. You say software encoding is dead, but software encoding is really the only one that will last and survive. Hardware changes and encoders will have to be re-written each time, but x264 will still continue to run, and improve as people work on it. QS is what it is, and what it does not is all it will do in 2 years on the same chip. x264 in 2 years running on my new CPU will still be better than it is today, but QS will be the same).

My upgraded machine is a Core i7 2600k with lots of RAM on an ASUS P8P67, all at stock but this thing is turboing up to 3.8 ghz all the time. I got this specifically for my encoding with x264. I also have a GeForce 460 and am waiting for Badaboom to enable support for my card with 2.0 so I can try it out. Anyway, I just grabbed a file from the special features of Alice in Wonderland and ran it through with these settings via StaxRip (all 1080p@23.976):

The source file was 194,446,939 (after removing audio and whatever else was in there) bytes

"x264.exe" --preset ultrafast --tune film --crf 22 --output "00588_Output.h264" "00588.avs"

output was 172,483,260
encoded 2085 frames, 75.27 fps, 10649.66 kb/s

Dropping --crf to 23 yielded a file of 157,477,596 bytes, and encoded 2085 frames, 79.09 fps, 9225.78 kb/s

Using these settings gave me around 48 FPS:
"x264.exe" --profile baseline --crf 22 --level 3 --vbv-bufsize 10000 --vbv-maxrate 10000 --output ..."
This is the iPod preset on medium, with size 65,827,267

Now, I will try to get seriously high speed at 720p (all times given are just the encode, not the re-size):
x264.exe" --preset superfast --tune film --crf 22 ...
a disappointing encoded 2085 frames, 57.06 fps, 4843.12 kb/s

It appears resizing is making it slow, as my CPU was only 25% in use during that one.
Something interesting now:
x264.exe" --preset superfast --tune film --crf 18 --output...
encoded 2085 frames, 57.34 fps, 7735.73 kb/s

Seem to have hit the limit on how fast this can go when resizing. To be thorough I was using:
x264>x264 --help
x264 core:105 r1724 b02df7b

Wow, long post, but after reading these posts for hours, I had a lot to say. Wanted to take notes while reading. Hope there isn't a post length limit.
Any other tests anyone would like run on this CPU (I know the above quick tests are hardly conclusive, but 150 FPS seems tough, would love some info on how to maybe achieve that)?

[kypec]

@SeeManRun: thanks for your test results. I think though that for the most optimal results you should upgrade your x264 to latest revision, r1867 that is.
You also didn't specify where the resizing occurs: Avisynth? If yes then which method was used - Spline, Bicubic, Lanczos? Last but not least: which source filter have you used? FFMS2, DGDecNV, DirectShow?
All these conditions may have big influence on overall encoding performance observed...
Please post your full AVS script and Avisynth version used and all above questions will be answered.

[CruNcher]

Continuation of "Beating a Dead Horse" ....


Except for the fact that you don't really need to "search" in order to "cherry pick" a frame that makes CUDA look bad. The truth is much more simple - Cuda IS bad.

Perhaps you're not fully aware of the technicals behind. It is not that encoding per GPU would be inherently fast because GPUs are oh so fast and oh so parallel. Fact is that GPUs can do certain operations at extraordinary speeds .... most of which, alas, do not apply to video encoding.

The *major* reason why GPU encoders are as fast as they are is: usage of very simple algorithms. If you do only very few computations, then you can compute very fast. THAT is what CUDA encoder is doing. And that's what the result is looking like.

Take a 2600K, and let x264 encode some 720p with "--superfast". You'll surely get more than 150fps. Well possible that you might see 200fps.
And it will still look better than a CUDA encode. Yes, it will. And surely it will not look worse than QuickSync. Probably still better.

(Yes, the last paragraph is pure speculation. But you can call me back on this by the time when the real tests will come up. With pleasure.) :)




Looking from far, it doesn't fall apart in the same obvious way as the CUDA encoding. But still ...

Extension to the above flip-flop:
http://img834.imageshack.us/img834/9914/13intelmediasdk01308.th.png (http://img834.imageshack.us/i/13intelmediasdk01308.png/)

And this took roughly 4 times longer to encode than x264? Interesting!

Yep superfast was a evolution :) in terms of Speed/Quality/Power Consumption/Complexity (+ subme 2 you can give it a tad more quality on lower bitrates and create a new profile between superfast and fast) i love it :) and that's why i really would like to know how QuickSync holds up (especialy as it seems to be tuned in most of the Encoding applications for speed and could be more tuned for quality) to from the first looks of Anandtech you can see it heavily blurs on the frames he chose though as always we know nothing about the test and no samples are released so its bogus and we need someone from doom9 doing the visual evaluation of it vs x264 :)
Heck we don't know if it even uses somekind of AQ (Nvidias Encoder uses that) yet with Anandtechs results i would say nope but those could be I-frames vs P-frames or whatnot :(

[kolak]

@SeeManRun: thanks for your test results. I think though that for the most optimal results you should upgrade your x264 to latest revision, r1867 that is.
You also didn't specify where the resizing occurs: Avisynth? If yes then which method was used - Spline, Bicubic, Lanczos? Last but not least: which source filter have you used? FFMS2, DGDecNV, DirectShow?
All these conditions may have big influence on overall encoding performance observed...
Please post your full AVS script and Avisynth version used and all above questions will be answered.

It is very funny when people do speed test, by feeding encoders through big avisynth scripts- juts render script into yv12 file :)

Andrew

[SeeManRun]

@SeeManRun: thanks for your test results. I think though that for the most optimal results you should upgrade your x264 to latest revision, r1867 that is.
You also didn't specify where the resizing occurs: Avisynth? If yes then which method was used - Spline, Bicubic, Lanczos? Last but not least: which source filter have you used? FFMS2, DGDecNV, DirectShow?
All these conditions may have big influence on overall encoding performance observed...
Please post your full AVS script and Avisynth version used and all above questions will be answered.

With an upgraded version (x264 core:112 r1867 22bfd31) I got the following log file. Please take a look and let me know thoughts. Also should note that my CPU is only around 50% used during the test. When I use my own quality settings for blu-ray movies it is 100% on the second pass (yes I use 2 pass encoding).

Let me know what else I can adjust.

[poisondeathray]

attachments have to be approved , if you copy & paste text, or use a 3rd party free hosting site (e.g. mediafire.com, sendspace.com) there is no wait

[SeeManRun]

attachments have to be approved , if you copy & paste text, or use a 3rd party free hosting site (e.g. mediafire.com, sendspace.com) there is no wait

Thanks for the info. Do you prefer 3rd party posting or giant messages opposed to approving attachments by chance?

[easyfab]

Hi, here is a little test ( in french) :x264 VS MediaEspresso et Quick Sync Video with the new SB i5 2300 and i7 2600k

http://www.pcinpact.com/articles/intel-qsv-mediaespresso-x264-video/415-1.htm

[shon3i]

Here's my little contribution

source: park_joy_1080p.y4m
avs script:
RawSource("park_joy_1080p.y4m",1920,1080,"YV12")
AssumeFPS(24000,1001)
Spline36Resize(1280,720)
Encoders: Mainconcept H264 using CUDA, x264 r1834
Settings: Mainconcept
http://img12.imageshack.us/img12/1313/mcsettings1.th.jpg (http://img12.imageshack.us/i/mcsettings1.jpg/)http://img214.imageshack.us/img214/2465/mcsettings2.th.jpg (http://img214.imageshack.us/i/mcsettings2.jpg/)http://img211.imageshack.us/img211/7046/mcsettings3.th.jpg (http://img211.imageshack.us/i/mcsettings3.jpg/)http://img211.imageshack.us/img211/7046/mcsettings3.th.jpg (http://img211.imageshack.us/i/mcsettings3.jpg/)http://img843.imageshack.us/img843/8770/mcsettings4.th.jpg (http://img843.imageshack.us/i/mcsettings4.jpg/)http://img684.imageshack.us/img684/1676/mcsettings5.th.jpg (http://img684.imageshack.us/i/mcsettings5.jpg/)

x264: preset: superfast, tunings: none, ABR
cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x3:0x3 / me=dia / subme=1 / psy=1 / psy_rd=0.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=9 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc=abr / mbtree=0 / bitrate=6000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

Target bitrate: 6mbps
Encoding logs: Mainconcept
Input:
---------------------
Video source: C:/Users/shon3i/Desktop/test.avs (DirectShow Import)
Output settings:
---------------------
Filename: C:/Users/shon3i/Desktop/test_out.264
VIDEO: H.264/AVC CUDA, NTSC, 1280x720pixels, 23.976pfps, VBR, 6000kbps (max N/A)
multiplexing: Elementary
---------------------

H.264 Encoding Done.
--------------------------------------------------------------------------------
Frames: 500 incoming, 500 encoded
Avg. Bitrate: 5999.40 kbits per second
Time elapsed: 12.35 seconds
--------------------------------------------------------------------------------
Transcoding results:
------------------
Done: C:/Users/shon3i/Desktop/test.avs -> C:/Users/shon3i/Desktop/test_out.264 (0h 00m 12.523s, 39.9 FPS)
-------------------

x264:
x264 [info]: frame I:2 Avg QP:25.30 size:178487
x264 [info]: frame P:254 Avg QP:31.24 size: 49476
x264 [info]: frame B:244 Avg QP:34.03 size: 9280
x264 [info]: consecutive B-frames: 2.8% 94.8% 2.4% 0.0%
x264 [info]: mb I I16..4: 6.9% 40.9% 52.2%
x264 [info]: mb P I16..4: 0.7% 1.7% 0.9% P16..4: 76.6% 0.0% 0.0% 0.0% 0.0% skip:20.0%
x264 [info]: mb B I16..4: 0.2% 0.2% 0.0% B16..8: 11.4% 0.0% 0.0% direct:21.9% skip:66.4% L0:24.9% L1:43.2% BI:31.9%
x264 [info]: final ratefactor: 26.27
x264 [info]: 8x8 transform intra:49.0% inter:29.5%
x264 [info]: coded y,uvDC,uvAC intra: 83.7% 71.6% 54.9% inter: 32.0% 12.9% 3.3%
x264 [info]: i16 v,h,dc,p: 32% 14% 42% 12%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 14% 30% 5% 7% 6% 6% 6% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 17% 23% 5% 10% 6% 7% 7% 11%
x264 [info]: i8c dc,h,v,p: 49% 18% 24% 8%
x264 [info]: Weighted P-Frames: Y:2.4% UV:0.8%
x264 [info]: kb/s:5826.40
encoded 500 frames, 41.20 fps, 5826.40 kb/s

Output:
Mainconcept - http://www.mediafire.com/?5c9a4geg809bnyu
x264 - http://www.mediafire.com/?95zzd5338q2rnnx

Enjoy.

[poisondeathray]

Hi, here is a little test ( in french) :x264 VS MediaEspresso et Quick Sync Video with the new SB i5 2300 and i7 2600k

http://www.pcinpact.com/articles/intel-qsv-mediaespresso-x264-video/415-1.htm



Thanks, Maybe something was lost in the Google translation, but it looks on their tests x264 was actually faster on the "ultra fast" preset, and about the same speed on "very fast preset ?" But it was 1/2 the filesize with better quality ?

But - the rollover screenshots aren't of the same frame. They have a zip file, I'll have a look at that

[poisondeathray]

With an upgraded version (x264 core:112 r1867 22bfd31) I got the following log file. Please take a look and let me know thoughts. Also should note that my CPU is only around 50% used during the test. When I use my own quality settings for blu-ray movies it is 100% on the second pass (yes I use 2 pass encoding).

Let me know what else I can adjust.

For some reason it looks like you're deinterlacing a progressive source and doing a crop & resize



FFVideoSource("movies\00588 temp files\00588.mkv", cachefile="movies\00588 temp files\00588.ffindex")
AssumeFPS(23.976)
Crop(0,0, -Width % 8,-Height % 8)
ConvertToYV12()
Yadif()
Crop(0,4,-0,-4)
BicubicResize(1920,1072,0,0.5)

[poisondeathray]

Here's my little contribution

<snip>


Mainconcept - http://www.mediafire.com/?5c9a4geg809bnyu
x264 - http://www.mediafire.com/?95zzd5338q2rnnx


Thanks,

No surprise, not looking too good for the Mainconcept CUDA encoder...

What were your system specs shon3i ? CPU and GPU ?

[mp3dom]

Here's my little contribution
source: park_joy_1080p.y4m

The settings for both encoders are near the same?
Comparing the CUDA settings vs. x264 settings seems that CUDA uses only 1 B-frames (3 on x264), that CUDA can potentially have I frame every frame (x264 at least every 23), CUDA cannot reference B frames and doesn't have pyramid Bframe (both options enabled in x264). Probably doesn't change anything at the end anyway.

[SeeManRun]

For some reason it looks like you're deinterlacing a progressive source and doing a crop & resize

These options seem to be in the default. I will have to take a look if removing them gets me some higher speed. I never resize videos, only crop, so this is interesting.

[poisondeathray]

Those aren't defaults for x264 . You mean the defaults GUI you're using (staxrip ?)

I would say yadif is your main bottleneck. Not only will it be slower, it will be lower quality

If you want to test speed , use x264.exe to remove other bottlenecks

If you're using single threaded ffms , that could be a bottleneck as well (ffms-mt is the multithreaded version , I don't know which one you're using in staxrip)

[LoRd_MuldeR]

I would say yadif is your main bottleneck. Not only will it be slower, it will be lower quality

You will hardly find a (software) deinterlacer that is as fast as Yadif and still gives decent quality.

For an encoder test/comparison I would recommend to do the deinterlacing beforehand and feed all encoders with the identical progressive (deinterlaced) source.

[poisondeathray]

You will hardly find a (software) deinterlacer that is as fast as Yadif and still gives decent quality.


I agree.

But I still wouldn't use it on a 23.976 progressive source. :)

[deadrats]

My upgraded machine is a Core i7 2600k with lots of RAM on an ASUS P8P67, all at stock but this thing is turboing up to 3.8 ghz all the time.


how about you do a QS test with tmpg express 5 for us so we can put this thread to bed.

[shon3i]

Thanks,

No surprise, not looking too good for the Mainconcept CUDA encoder...

What were your system specs shon3i ? CPU and GPU ?
GeForce 9600GT 512MB (stock), Phenom X4 @ 2.2 (stock). Btw to my eyes, Mainconcept is better than any GPU encoder these days. Badaboom (elemental) is even worse

The settings for both encoders are near the same?
Comparing the CUDA settings vs. x264 settings seems that CUDA uses only 1 B-frames (3 on x264), that CUDA can potentially have I frame every frame (x264 at least every 23), CUDA cannot reference B frames and doesn't have pyramid Bframe (both options enabled in x264). Probably doesn't change anything at the end anyway. What i am trying to prove here is what we talking about last 2-3 pages back, that A encoder can be more efficient thatn B encoder and produce significant better quality for same and even faster speed. Nothing else. I off course can match all x264 settings to decrease quality and make same quality as GPU encoder, i will probably get significant more speed with x264 nothing else. I intended to use slowest possible settings in GPU encoder and use same-speed settings in x264, and as i said i can even decrease x264 settings from defaults and i will probably get nothing than more speed.

And about I frames, both encodes have only 2 I frames, you can check streams through Elecard Stream Eye

[SeeManRun]

how about you do a QS test with tmpg express 5 for us so we can put this thread to bed.

Will work on that later, but as others have posted you may need a h67 motherboard for that, which I don't have.

[SeeManRun]

Those aren't defaults for x264 . You mean the defaults GUI you're using (staxrip ?)

I would say yadif is your main bottleneck. Not only will it be slower, it will be lower quality

If you want to test speed , use x264.exe to remove other bottlenecks

If you're using single threaded ffms , that could be a bottleneck as well (ffms-mt is the multithreaded version , I don't know which one you're using in staxrip)

Yes, defaults in the GUI. Removing de-interlacing certainly speeds it up, and I never resize but it seems screwing with it made that happen. Fixing that up and using ultrafast i was able to hit over 135 fps and it looks much better than I would have expected.. Will have to play with this more later.

[SeeManRun]

how about you do a QS test with tmpg express 5 for us so we can put this thread to bed.

I can't seem to find version 5, and since I don't speak Japanese, I don't really want to go through the pain of trying to figure out what to run when it will likely be incorrect.

[frenchfries]

how about you do a QS test with tmpg express 5 for us so we can put this thread to bed.

I too would like to see someone with a SB run a comparison but unfortunately he cannot as he said he has a P67, which does not allow the use of the "QuickSync" bits yet

My encodes taken at a CRF of 18 and using slower settings seem to come out at around 10Mb/s with very little perceivable loss over the original bluray. If the source is grainy, as it so often seems to be these days, I can notice the difference more easily but tuning for film boosts the file size significantly. A trade off I am unwilling to make.

As mentioned by another poster, if you don't care about diskspace why do you transcode at all? I would simply decrypt the content and leave it at that, noty even remux, if that were a viable position for me.

OT - Dark Shikari reminds of Linus Torvalds in forums, comes across as knowing what he is on about but usually very quick to get angry. Neuron2 also fits into this camp. That being said, you also have on several occasions snapped and "argued the person not the topic"

[deadrats]

As mentioned by another poster, if you don't care about diskspace why do you transcode at all? I would simply decrypt the content and leave it at that, noty even remux, if that were a viable position for me.

if you go back and reread what i wrote i routinely advise people not to bother transcoding, the only time i do any re-encoding is if i have a tv capture of a sporting event or tv show and i want to cut out the commercials, otherwise i will only keep the video stream as it is, keep only the highest quality audio stream and remux.

the people that transcode a commercial BD from 30+ mb/s to 10 mb/s are obviously those that intend to pirate the content: they wish to save as much bandwidth as they can sharing it or they intend to return the BD back to the video store and wish to use as little space as possible "backing up" the content.

OT - Dark Shikari reminds of Linus Torvalds in forums, comes across as knowing what he is on about but usually very quick to get angry. Neuron2 also fits into this camp. That being said, you also have on several occasions snapped and "argued the person not the topic"

you hit the nail on the head, the pseudo-religious fervor displayed by the x264 faithful is prevalent within the entire open source community; there was a time i did linux reviews in the old ET forums and said reviews used to be quite popular, they used to regularly get hundred's of views and comments and my email would get flooded.

the funny thing was that if i ripped into that distro or linux in general, the faithful would spend post after post telling me i was wrong, i was incompetent, i didn't know what i was talking about and/or that i was a microsoft employee out to spread FUD in order to destroy linux.

if i liked a particular distro, at times i was accused of being an employee of that company (such as red hat) or at times my positive review got linked on the home page of that distro as a testimonial.

if i have snapped at times it's because DS is single handedly responsible for all the anti-gpu acceleration FUD you're likely to run into: people with no programming experience, that think java is a type of bean, fill forum after forum with some of the most retarded BS you are likely to find and it has DS' signature all over it.

some of the most stupid:

1) gpu's are only good at simple calculations but the calculations performed by x264, and required by video encoding in general, are too complex.

2) gpu's can't do video encoding, that's why cuda sucks.

3) gpu's are only good at tasks that are highly parallel in nature but video encoding is inherently a linear task.

there's a number of others but these are the ones that really annoy me.

[LoRd_MuldeR]

some of the most stupid:

1) gpu's are only good at simple calculations but the calculations performed by x264, and required by video encoding in general, are too complex.

Indeed GPU cores are very simple compared to CPU cores. Initially GPU cores have been designed for 3D rendering and for nothing else. Starting with the GPGPU hype the GPU vendors have integrated more and more "CPU-like" features into their GPU cores. These features actually hurt 3D performance (because they occupy transistors that could have been used for stuff that helps 3D rendering otherwise), but they allow for more efficient/comfortable GPGPU calculations. Still, even with all the GPGPU extensions, GPU cores are lacking many features that you are used from CPU programming. Especially getting the memory management and access patterns right on the GPU is a nightmare! If you claim the opposite, you probably have never implemented a non-trivial algorithm on the GPU (I have, so I know what I'm talking about). The advantage of GPU cores is that they often can "hide" their disadvantages, simply because there are so many cores in a GPU. You can think of the GPU as a highly parallel co-processor. Still only problems that scale to thousands of threads will run on the GPU efficiently. Problems that are inherently sequential will never run efficiently on the GPU, because all those beautiful cores will be idle most of the time...

2) gpu's can't do video encoding, that's why cuda sucks.

CUDA is just an interface for GPGPU programming. There are many problems (mostly scientific ones) that are extremely parallel and thus fit perfectly well onto the GPU. However "video encoding" is a problem which is not that suitable for GPGPU (and thus for CUDA or for OpenCL or for whatever GPGPU interface you use). And that's mainly because of point 3.

3) gpu's are only good at tasks that are highly parallel in nature but video encoding is inherently a linear task.

That's basically true! However video encoding is not inherently sequential in its whole, but there are important parts in the encoding pipeline that are inherently sequential. So if at all, only certain parts of the video encoding pipline will work efficiently on the GPU. Unfortunately moving only parts of the video encoder to the GPU while keeping all the rest on the CPU isn't easy to do either. That's because transferring data between the GPU (device memory) and the CPU (host memory) causes an enormous delay which can easily kill all your nice speed-up (believe me, I know what I'm talking about ^^). The existing "CUDA encoders" workaround that problem by using very simple algorithms for those "problematic" parts of the encoding pipeline. And that's one of the reasons why they suck (quality-wise) that much...

[nm]

My encodes taken at a CRF of 18 and using slower settings seem to come out at around 10Mb/s with very little perceivable loss over the original bluray. If the source is grainy, as it so often seems to be these days, I can notice the difference more easily but tuning for film boosts the file size significantly. A trade off I am unwilling to make.

You should generally always tune for film. Raise CRF until you get the bitrates that you are after.

[mariush]

deadrats, since you think programming in Cuda is so easy, I think you should read this paper from nVidia, which shows just how many things you have to keep in mind if you wish to have efficient and fast code on gpu:

http://developer.download.nvidia.com/compute/cuda/1_1/Website/projects/reduction/doc/reduction.pdf

And this above is a simple reduction, not multihexagon search or something more complex...

What Lord_Mulder says above is correct... if you were to implement the algorithms that are now in x264 that give quality to the encodings on the gpu, it will take so much time to transfer the data back and forth to the GPU and arrange it in a way the algorithms would run in parallel on the video card efficiently... and after you do this the code will run just a bit faster on the GPU... both together would just make the whole encoding slower.

later edit: You can also see this 29 page slideshow, which discusses using Cuda in x264: https://docs.google.com/present/view?id=df3rvqmk_1gsxgzgts&pli=1

The slideshow's project page is this one: https://sites.google.com/site/x264cuda/

[poisondeathray]

I'm a non programmer, but I've seen Lord Mulder explain this before and it seems like very reasonable explanations to me

@deadrats
1) So why do you think - in programming terms - the current GPU encoders "suck" ? Surely the big companies have enough resources to hire good programmers and develop software? It's not in the infancy stage anymore - we're on 3rd and 4th generation GPU encoders now.

2) More importantly, how could you improve them? or how could you integrate a GPU-CPU encoder etc... ie. How can you make something that - me - an end user would want to use?

[dj_tjerk]

if you go back and reread what i wrote i routinely advise people not to bother transcoding, the only time i do any re-encoding is if i have a tv capture of a sporting event or tv show and i want to cut out the commercials, otherwise i will only keep the video stream as it is, keep only the highest quality audio stream and remux.
Blasphemy! Why don't you cut without re-encoding?


the people that transcode a commercial BD from 30+ mb/s to 10 mb/s are obviously those that intend to pirate the content: they wish to save as much bandwidth as they can sharing it or they intend to return the BD back to the video store and wish to use as little space as possible "backing up" the content.

Or those that, well, want to actually play a movie on a device that can't handle such bitrates/resolutions, or can't store that amount of data. Also, nice fallacy there.


you hit the nail on the head, the pseudo-religious fervor displayed by the x264 faithful is prevalent within the entire open source community; there was a time i did linux reviews in the old ET forums and said reviews used to be quite popular, they used to regularly get hundred's of views and comments and my email would get flooded.
So you're saying you used to be an arrogant and allegedly worshipped, though contributing, user? I.e. what you claim DS to be?


the funny thing was that if i ripped into that distro or linux in general, the faithful would spend post after post telling me i was wrong, i was incompetent, i didn't know what i was talking about and/or that i was a microsoft employee out to spread FUD in order to destroy linux.
Can't say you're wrong about the distro stuff, as I haven't seen any of your reviews or the mentioned posts. What I can say however is that you don't know how video compression works, based on your sole argument that "bits per pixel" is always and directly correlated with (perceived) quality.


if i have snapped at times it's because DS is single handedly responsible for all the anti-gpu acceleration FUD you're likely to run into: people with no programming experience, that think java is a type of bean, fill forum after forum with some of the most retarded BS you are likely to find and it has DS' signature all over it. DS has explained over and over how to approach offloading some parts of the encoding process to the GPU to people asking willing to try it. However, every single one of those persons has given up, because it isn't as trivial to implement as they thought. I wouldn't expect anyone to not become a bit curt when the topic of "gpu encoding" surfaces once more, and people are proclaiming it's the next best thing and x264 should use it.


some of the most stupid:

See LoRd_MuldeR's post. The GPU is good at what it's good at (duh), but one often has to resort to highly parallel algorithms that are much worse than a serial algorithm.

[CruNcher]

GeForce 9600GT 512MB (stock), Phenom X4 @ 2.2 (stock). Btw to my eyes, Mainconcept is better than any GPU encoder these days. Badaboom (elemental) is even worse

What i am trying to prove here is what we talking about last 2-3 pages back, that A encoder can be more efficient thatn B encoder and produce significant better quality for same and even faster speed. Nothing else. I off course can match all x264 settings to decrease quality and make same quality as GPU encoder, i will probably get significant more speed with x264 nothing else. I intended to use slowest possible settings in GPU encoder and use same-speed settings in x264, and as i said i can even decrease x264 settings from defaults and i will probably get nothing than more speed.

And about I frames, both encodes have only 2 I frames, you can check streams through Elecard Stream Eye

It's better then Elementals current badaboom encoder no doub't but 2.0 has to bee seen also its not as good as Nvidias Encoder yet but the Q1 version should beat it (also feature wise).
So in your case 8 SMs (G94) are slightly slower as 4 AMD cores @ subme 1 in Mainconcepts Encoder :) i can update this with G92 results @ 14 SMs :) if we can get someone with a Fermi based G100 card and a AMD system it would be perfect :)

Though it would be much easier to create a automated benchmark system based on Nvidias Encoder then on Mainconcepts for easier result gathering in a external thread :) (with x264 as a system reference bench for both 720p/1080p)

[shon3i]

@CruNcher, is there trial of nvidia encoder or in some application? i willing to try. Btw after i do test on older Athlon 4800 @ 2.4GHz i get speed like ~25-30fps with x264, aslo i tryed on friends GTX 460, i didn't get noticeable speed few fps more nothing marginal

[poisondeathray]

Btw after i do test on older Athlon 4800 @ 2.4GHz i get speed like ~25-30fps with x264, aslo i tryed on friends GTX 460, i didn't get noticeable speed few fps more nothing marginal

shon3i - mainconcept's marketing slides show big improvement , but larger improvement with more cores, say GTS250 vs. GTX470 on the GPU encoder, (more on hexcore, but even on dual core setup, speedup is significant). Maybe that older Athlon core was bottleneck ?

http://www.mainconcept.com/fileadmin/user_upload/download/product_sheets/CUDA-Sheets_06-2010.pdf

[deadrats]

...

wow.

1) gpgpu features kill 3d performance? is that why each successive generation of gpu gets faster and faster? gpgpu capabilities have been available since dx8 class cards, when shaders were first introduced, 3d performance has increased many orders of magnitude since the gf3 days, clearly the additional transistors haven't hurt performance all that much.

2) re: memory transfer, a similar claim could be made with regards to general cpu programming - you have to load the data from the hdd to ram and write the results back, if your app doesn't handle memory management internally then the OS does it for you, but either way it takes place. you don't seem to have a problem with the performance implications of that, so why the objection that gpgpu programming has a similar requirement? furthermore, the ram on graphics cards is faster than system ram (gddr3 or 5 vs ddr2 or 3), so the performance penalty is significantly less.

but this approach fails to utilize the full power of modern gpu's: i know that DS tried to get a SAD function coded in cuda (i've seen his posts over at the nvidia developers forum) and i know he was successful in coding it but was disappointed with the performance versus the one used in x264.

what he failed to account for is that cuda functions, unlike c/c++ functions, can be called numerous times, the proper way to use a gpu powered SAD function is to compile the "kernel" and call it repeatedly to perform the SAD calculations in parallel (obviously on different frames). you could code the gpu SAD to store the values in an array that can then be read from the encoder as they are needed.

you don't have to code each individual part of an encoder so that each part runs faster than it's x86 counterpart, all you have to do is code it so all the parts together have a lower running time than all the x86 parts together.

test after test with tmpg express 5 shows that the cuda encoder runs faster than the included x264, using only 20-25% of the 128 cores my gts250 has, and the performance disparity increases as the bit rate increases, at true BD bit rates, x264 just can't keep up.

3) the main reason cuda encoders "suck" is because quite a few of them use the reference nvidia h264 encoder which was meant as a template, a learning tool, it was never meant to be used in a commercial product.

the reality is this: gpgpu programming in not easy, it requires a completely different way of thinking about problems and their solutions, something x86 programmers are not used to. add to that the fact that nvidia hasn't made cuda programming easy for those that cut their teeth doing procedural programming, they have sponsored cuda courses only on the graduate level and it's no wonder cuda encoders suffer a bit.

but that doesn't mean the technology sucks, just that people don't know how to use it yet.

[deadrats]

I'm a non programmer, but I've seen Lord Mulder explain this before and it seems like very reasonable explanations to me

@deadrats
1) So why do you think - in programming terms - the current GPU encoders "suck" ? Surely the big companies have enough resources to hire good programmers and develop software? It's not in the infancy stage anymore - we're on 3rd and 4th generation GPU encoders now.

2) More importantly, how could you improve them? or how could you integrate a GPU-CPU encoder etc... ie. How can you make something that - me - an end user would want to use?

see my response to "mulder".

[LoRd_MuldeR]

1) gpgpu features kill 3d performance? is that why each successive generation of gpu gets faster and faster? gpgpu capabilities have been available since dx8 class cards, when shaders were first introduced, 3d performance has increased many orders of magnitude since the gf3 days, clearly the additional transistors haven't hurt performance all that much.

As a matter of fact, the number of transistors that are available in a GPU is limited. And all transistors that the designers spend for improving GPGPU-specific features cannot be used for 3D Rendering-specific features anymore. Modern GPU's definitely contain various design decisions that have been made in favor of GPGPU performance rather than 3D Rendering performance. Of course the overall 3D performance still has improved in each GPU generation, but it surely could have been improved a lot more of if they did optimize for the "raw" 3D performance only...

2) re: memory transfer, a similar claim could be made with regards to general cpu programming - you have to load the data from the hdd to ram and write the results back, if your app doesn't handle memory management internally then the OS does it for you, but either way it takes place. you don't seem to have a problem with the performance implications of that, so why the objection that gpgpu programming has a similar requirement? furthermore, the ram on graphics cards is faster than system ram (gddr3 or 5 vs ddr2 or 3), so the performance penalty is significantly less.

You obviously don't have the slightest idea what you are talking about. First of all, on the GPU you must "upload" all input data from the host memory (CPU) to the device memory (GPU) first and later you must "download" all the results from device memory back to host memory. This is in addition to loading/saving the data from/to the HDD. Moreover memory access to the GPU memory from a GPU kernel is very different compared to access to the main memory from a CPU program. Access to the "global" GPU memory is very slow and (by default) it's not cached at all! Therefore each group of GPU cores has a fast (but small!) "shared" memory attached to it (some of that "shared" memory can be used as cache in the Fermi generation). Moreover even access to the "shared" memory must be organized very carefully, because it is split into several memory banks. Different GPU cores can access memory located in different banks simultaneously, but access to memory in the same bank must be serialized, which costs a lot of performance. And so on...

but this approach fails to utilize the full power of modern gpu's: i know that DS tried to get a SAD function coded in cuda (i've seen his posts over at the nvidia developers forum) and i know he was successful in coding it but was disappointed with the performance versus the one used in x264.

what he failed to account for is that cuda functions, unlike c/c++ functions, can be called numerous times, the proper way to use a gpu powered SAD function is to compile the "kernel" and call it repeatedly to perform the SAD calculations in parallel (obviously on different frames). you could code the gpu SAD to store the values in an array that can then be read from the encoder as they are needed.

you don't have to code each individual part of an encoder so that each part runs faster than it's x86 counterpart, all you have to do is code it so all the parts together have a lower running time than all the x86 parts together.

Again you have not the slightes idea what you are talking about :rolleyes:

3) the main reason cuda encoders "suck" is because quite a few of them use the reference nvidia h264 encoder which was meant as a template, a learning tool, it was never meant to be used in a commercial product.

the reality is this: gpgpu programming in not easy, it requires a completely different way of thinking about problems and their solutions, something x86 programmers are not used to. add to that the fact that nvidia hasn't made cuda programming easy for those that cut their teeth doing procedural programming, they have sponsored cuda courses only on the graduate level and it's no wonder cuda encoders suffer a bit.

but that doesn't mean the technology sucks, just that people don't know how to use it yet.

CUDA (and GPGPU in general) is available for several years now and various "big" companies, including NVidia, have been pushing GPGPU aggressively since then. Still all the GPGPU encoders that we have seen on the market until now aren't anywhere near the state-of-the-art software encoders. If not all programmers/companies working on GPGPU encoders are completely incompetent, it is time to realize that the currently available GPUGPU platforms are NOT as suitable for video encoding as the GPU vendors and their marketing departments try to make us believe all the time...


Okay, deadrats. I have been watching you trolling this thread for quite some time now. Whenever somebody explains something to you, you respond immediately and claim the opposite, although from your posts it often quite obvious that you don't know the technical background very well. So I kindly ask you stop at this point and focus on the original topic again!

[shon3i]

@CruNcher, is there trial of nvidia encoder or in some application? i willing to try. Btw after i do test on older Athlon 4800 @ 2.4GHz i get speed like ~25-30fps with x264, aslo i tryed on friends GTX 460, i didn't get noticeable speed few fps more nothing marginal
Infact you been right on Athlon machine i can't propretly (without bottleneck) playback avs script. HDD will blow up.

Well that cards will be probably more expensive than an good six or eighth core processor.

[frenchfries]

wow.

1) gpgpu features kill 3d performance? is that why each successive generation of gpu gets faster and faster? gpgpu capabilities have been available since dx8 class cards, when shaders were first introduced, 3d performance has increased many orders of magnitude since the gf3 days, clearly the additional transistors haven't hurt performance all that much.


Have you noticed that GPU's performance increase in each successive generation has been tapering off? At least a small part of this is due to the designers being unable to use all the transistors in the budget for raw 3d work.

I don't appreciate your implication that I am a pirate merely because I don't have unlimited disk space. In fact if I was a pirate I would have considerably more money to spend on disk space and could then simply download BD images and not have to transcode.

I mainly transcode for ease of use, not having to go find the disc is good. If I can make something smaller with no perceivable difference, to me at least, why wouldn't I? It only costs me a little time and my CPU a lot of time :P

Finally, I was quite optimistic when this talk of GPU accelerated transcoding started and it was only after I saw the output that I became jaded. I am so glad the badaboom had a trial or I would have asked for my money back.

[deadrats]

I don't appreciate your implication that I am a pirate merely because I don't have unlimited disk space. In fact if I was a pirate I would have considerably more money to spend on disk space and could then simply download BD images and not have to transcode.

I mainly transcode for ease of use, not having to go find the disc is good. If I can make something smaller with no perceivable difference, to me at least, why wouldn't I? It only costs me a little time and my CPU a lot of time :P

it's not an implication, it's a logical conclusion. first of all who watches a BD on their pc, don't you prefer watching it on a hdtv with a BD player?

second, to me the term "back up" means just that; use a BD burner to make a duplicate disk, not transcode it down to 10 mb/s (or less).

as for being jaded, so long as you use enough bit rate, the quality differences are nill.

furthermore all the companies that buy per seat licenses to main concept's cuda encoder or adobe's "mercury" engine would disagree. another company that would disagree with you is microsoft, seeing how they filed for, and were granted patents for, gpu powered encoding.

the thought that a handful of programmers that give their software away for free knows more about gpgpu than the people making millions of it is laughable.

[aegisofrime]

it's not an implication, it's a logical conclusion. first of all who watches a BD on their pc, don't you prefer watching it on a hdtv with a BD player?

Maybe I just want to watch porn in my own room instead of in the living room with my family.

[poisondeathray]

Maybe I just want to watch porn in my own room instead of in the living room with my family.

Best reply EVER :p

[cacepi]

furthermore all the companies that buy per seat licenses to main concept's cuda encoder or adobe's "mercury" engine would disagree. another company that would disagree with you is microsoft, seeing how they filed for, and were granted patents for, gpu powered encoding.

<sarcasm>Yes, because it's not like Mainconcept wants to charge you $1200 for an encoder, or Adobe $800 for their editor suite ($2600 for Master Collection), or Microsoft patent GPU encoding on their platforms so they can charge Adobe and Mainconcept licensing fees.</sarcasm>

You're certainly not that naïve, are you?

And yes, I understand the point you're trying to make, but what does that really have to do with how superior, or inferior, x264 is to OpenCL/CUDA encoding? And be honest here.

[frenchfries]

it's not an implication, it's a logical conclusion. first of all who watches a BD on their pc, don't you prefer watching it on a hdtv with a BD player?


Its called a HTPC or media centre.
http://en.wikipedia.org/wiki/Home_theater_PC
I prefer being able to easily browse my movies from the couch rather than getting up and having to look at the dvd storage unit and attempt to read the titles from the spine.
http://img504.imageshack.us/img504/3333/previewxf5.png

[deadrats]

And yes, I understand the point you're trying to make, but what does that really have to do with how superior, or inferior, x264 is to OpenCL/CUDA encoding? And be honest here.

what does it have to do with it?

as i have said, people are willing to spend thousands on per seat licenses, or out right pirate the software, rather than use the legally free alternative, i think that speaks volumes as to how x264 is viewed compared to other encoders.

x264 has an unfair competitive advantage by virtue of being free, if they started charging $2500 for a single seat license, how many people do you think would still choose it over main concept gpu powered encoder?

there seems to be this ridiculous mythos that sprouts up around any open source project, linux being a prime example, the thought being that a bunch of hobbyists knows more about OS design than the people making billions off it.

absurd.

in all honesty, i have seen numerous encodes where x264 fell apart, it happens with all encoders once you start bit rate starving an encode.

i think we can all agree that given the same source, if we encoded to 1080p with a very reasonable 15 mb/s or 720p with a reasonable 10 mb/s, more than likely, we wouldn't be able to tell the difference between encodes.

once we apply some professional standards to our encodes x264's advantages quickly disappear.

[Mixer73]

as i have said, people are willing to spend thousands on per seat licenses, or out right pirate the software, rather than use the legally free alternative, i think that speaks volumes as to how x264 is viewed compared to other encoders.

Do not underestimate the impact of nepotism and gladhanding.

[Sharktooth]

@deadrats: compression algos are made to COMPRESS. so the more they compress (retaining image or audio quality for lossy encoders) the better they are. that means, the efficiency of an encoder is the ability to produce the lowest bitrate for an expected image quality. in this case x264 is unbeatable. plus it is very configurable.
your idea about setting a bitrate for a resolution is WRONG. 1st coz bitrate depends on source compressibility and compressibility depends on the encoder. sure you can shoot a super high bitrate and whatever encoder you use the result will look the same. but the principle is you want to COMPRESS that material... otherwise why use a high efficiency compressor? you can just stick to MPEG-2 or MPEG-4 ASP and set, let's say, 25mbps for 1080p.
so, the whole point of this discussion, is not "the bitrate". we care about the COMPRESSION and picture/sound quality. something that oversimplified encoders running on GPUs are not capable to deliver together.

[iwod]

Can we keep things just SB related..... not another GPU Encoding Thread,

[the_corona]

Oh my, I was so excited when I saw how many news posts this thread got, only to discover it turned into a GPU encoder argument :-(

deadrats, it seems you are quite happy with throwing enough bits at a problem so pretty much any encoder will do fine. That's great, so stick with it and stop saying everyone who disagress is a pirate and a mere idiot. What is the point of your posts?

You keep making all this claims, yet have nothing to show for it. You don't seem to understand the first thing about Cuda or OpenCL programming (see your "understanding" of memory).

Regarding SB, DS has said in the past it could potentially be useful, but Intel, who have in the past promised to provide a patch by them for x264, just dissapeared (why? did they find its not helping afterall? Maybe its politics, who knows) and does not adequatly provide documentation for the new low level calls.

I humbly suggest you stop making all these claims and accusations. Or in the very least return to talking about SB and not CUDA because this thread is about the former after all (you do know there is a huge difference don't you?)

[LoRd_MuldeR]

@everybody:
As the discussion in this thread is definitely going into the wrong direction for some time now, I urge everybody to focus on the original topic again.
This means, if you don't have to add anything new to the discussion about Sandy Bridge (QuickSync) please do not post in this thread!

(BTW: I already moved two of deadrats's profanity/no-use replies to moderation. And I will do so with other off-topic posts, in the hope we can resurrect the thread)

[SeeManRun]

@everybody:
As the discussion in this thread is definitely going into the wrong direction for some time now, I urge everybody to focus on the original topic again.
This means, if you don't have to add anything new to the discussion about Sandy Bridge (QuickSync) please do not post in this thread!

Agreed. It seems I am the only one in this thread that I have seen yet with a Sandy Bridge (that I bought specially for x264, not for QS though). I had one private message from someone about running some tests, but so far they are proving too much work for me to do (installing diff versions of avisynth) and I don't really want to corrupt my currently functioning work flow.

How can I help you guys in some way by running some tests? I can offer this: I have a 3.4 ghz SB CPU that will run 8 threads and is fully unlocked. I have a Core 2 Quad 6600 running at 2.4 ghz. By disabling hyperthreading and lowering the speed of my SB, I can compare 4 SB cores at 2.4 ghz to 4 core2duo cores (2+2 of course) running at 2.4 ghz and post the results (unfortunately RAM will be 4 vs 16 gigs, but from what I have seen x264 doesn't usually take more than 1 in my existing work flows).

What I need though is a fairly self contained test so I can more or less just download the package and run it and post the results (I can supply BD or DVD content from my collection).

As for QuickSync, I have a p67 motherboard, so last I heard I cannot tap into the QS functions, though that does seem like an artificial limitation, unless the QS functionality is part of the on board video card which is disabled on p67.

[deadrats]

@SeeManRun

you could download the japanese version of tmpg express and run the media sdk encoder in software mode. if you don't wish to go through that hassle, download gom encoder, make sure to install the IPP encoder, and run some visual quality tests comparing x264 with IPP. you choose which encoder is used in the settings.

as a side note, main concept has jumped on the QS bandwagon:

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

evidently intel has decided to share access to it's low level api with them :rolleyes:

[LoRd_MuldeR]

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

evidently intel has decided to share access to it's low level api with them :rolleyes:

"The MainConcept™ H.264/AVC Encoder SDK for Intel® Quick Sync Video (QSV) acts as wrapper for the Intel Media SDK 2.0."

:rolleyes:

[Sharktooth]

ok, so then it will be crappy as the others...

[aegisofrime]

From what I read on Anandtech, Quick Sync is a special dedicated piece of silicon, separate from the GPU. I'm not an engineer, but to my mind there's no reason why Quick Sync needs Intel FDI to work. I'm hoping one of the more adventurous motherboard manufacturers (I'm looking at you ASRock) will be able to get around this limitation.

As for Mainconcept, they are just jumping onto the bandwagon for marketing purposes. "Hey lookie, we are among the first to support Quick Sync!" I expect as time goes by there will be more refined implementations.

[CruNcher]

Configurable RD optimization (fastest speed, best quality, balanced quality and speed).


If that is usable on QuickSync also :) it would be already much more advanced then any GPU Encoder did someone saw something in the Media SDK 2.0 documentation if the RD modes can be changed also for the Hardware Encoding with QuickSync ?

@aegisofrime
see my post about this restriction matter second part http://forum.doom9.org/showthread.php?p=1470631#post1470631

[frenchfries]

The cards shaders are a key part of the "quicksync" experience. Quote from this (http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i7-2600k-i5-2500k-core-i3-2100-tested/8) Anandtech article for those too lazy to read the article

"Motion search, the most compute intensive part of the transcode process, is done in the EU array. It's the combination of the fast decoder, the EU array, and fixed function hardware that make up Intel's Quick Sync engine."

Therefore, without a way to kick off the onchip video, quicksync wont be happening.

[SeeManRun]

The cards shaders are a key part of the "quicksync" experience. Quote from this (http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i7-2600k-i5-2500k-core-i3-2100-tested/8) Anandtech article for those too lazy to read the article

"Motion search, the most compute intensive part of the transcode process, is done in the EU array. It's the combination of the fast decoder, the EU array, and fixed function hardware that make up Intel's Quick Sync engine."

Therefore, without a way to kick off the onchip video, quicksync wont be happening.

I think this is not correct. The act of transcoding involves multiple steps. First, decode the content, then analyze the content and adjust content (resize or downscale or whatever), and finally encode it to a new format. This discussion is really about encoding and not decoding or transcoding. There is no reason if you were using quicksync that you couldn't use your dedicated video card to decode the video and feed it into the quick sync functionality.

The advantage of the bigger chips with more of the EU's is because the decoding can be done on the video card part of the CPU; the less of these units you have the slower the decoding, and slower overall transcoding would be.

[Mixer73]

There is no reason if you were using quicksync that you couldn't use your dedicated video card to decode the video and feed it into the quick sync functionality.


Yes there is, Quicksync will only be available if you are using the onboard GPU, I find this feature very paradoxical for this reason.

[frenchfries]

@SeeManRun

Unless I am gravely misinformed motion estimation is most definitely a part of the H.264 encoding process. It's supposedly the most strenuous part of the process as well.

[SeeManRun]

Yes there is, Quicksync will only be available if you are using the onboard GPU, I find this feature very paradoxical for this reason.

I am aware of this. I meant no technical reason other than Intel's decision to limit this.

@frenchfries
While that is correct, all the info I have read on QuickSync indicate that it does not use the dedicated graphics functionality to do any part of the encoding. Much like Cuda or openCL, the encoder would have to be written to do that, and if Intel didn't artificially limit the hardware, could be done on your nVidia or ATI card and then sent back to QuickSync.

I could be off on this as I haven't read as much as I should since learning the feature is useless unless you have integrated video and h67, so please forgive me if I am continuing to spew fud.

[CruNcher]

Jesus i never read so much strange things i mean we see opinions here drifting far away what is fixed function and what is not in SB

The advantage of the bigger chips with more of the EU's is because the decoding can be done on the video card part of the CPU; the less of these units you have the slower the decoding, and slower overall transcoding would be.

Surely not it makes absolutely no sense and it wouldn't be possible to get so low CPU utilization the Decoding part is like Nvidias/ATIs fixed function as well most probably its the PowerVR VXD core, Intel also used it on the GMA500 doesn't mean they also use it in their Intel HD GPU but why should they have changed it ? :) anyways we don't know for sure what Intel is doing especially the Encoding part but definitely the EUs play no role for the Decoding part (also watch this (http://www.intel.com/technology/visualtechnology/snb_demo/latin/Module_C.flv) to understand how it works and realize where the problems on discrete GPUs come from this way of Shader based postprocessing and what influences its performance) on Fusion and SB it is much more efficient even with such low shader GPU cores you can gain more of the end performance then you would with a discrete card still Motion Estimation on these wouldn't be as efficient as on the CPU or a specialized part (same amount of shader performance).
They have absolutely no impact on the Decoding Performance of a 6 EU SB (HD2000) or a 12 EU SB (HD3000) you can see the heaviest impact on Games as EUs (Shaders) the more the better in today's heavy Shader based 3D Game World. Also reviews indicate that the EUs have absolutely nothing todo with Motion Estimation (in Intels Quicksync Encoder) as a 6 EU SB is as fast as a 12 EU SB so the EUs aren't doing the Motion Estimation (so in that sense it's not done by the GPU like in a GPU Encoder). Also Francois Piednoel (http://www.linkedin.com/in/francoispiednoel) didn't talked about anything of using EUs for accelerating X264 he talked about something different it didn't sound like a GPU more like a specialized Hardware part. In Intels Release Material its not really visible what that is it just gets a overall term but nothing specific what it is, though most probably no one ever will get low level access to it except Intel or some partner under heavy NDA. So yeah we can see the work its doing in Quicksync but that's all for the moment :)
And it seems Francois was how should i say it to enthusiastic with his idea that he could be able to get his boss to allow x264 to get low level access to it he must have run into some heavy resistance on this idea or was actually never heard by anyone (hello anyone here *echo*) even with his background as a engineer @ Intel only business counts Intel currently demonstrates this in a very heavy way with all the restrictions layer they developed and currently enforcing on consumers.

[Sharktooth]

jeez, it took me almost 6 minutes to parse the text on your post and elaborate it to understand it. please, use punctuation AND short periods.
however, you're right *BUT* it seems QS cant work without GPU. that sounds weird and maybe there are some kind of "relations" that makes it impossible to enable QS without enabling the GPU too.
still, i think that that silicon could have been used to add some more interesting stuff instead of a random black-box that no one knows how it works except intel.

[CruNcher]

Sharktooth currently it's very confusing how and when it works some reviews say you just need to connect a Monitor on 1 of the onboard outs so Dual Monitoring on a H67 Motherboard with a discrete Card to activate it. Would also fit to whats written in some Motherboard Manuals, you can find the information that if you don't explicitly set the shared memory value the VGA output on a H67 Board gets disabled though no word about DVI and if that might be disabling QuickSync also. Though still it holds what i wrote earlier the Intel guy said (http://www.youtube.com/watch?v=gui_6sNc7Eo) hes running a P67 board and their you saw QuickSync working with Lucids Virtu GPU Virtualization and officialy that shouldn't be possible on a P67 Motherboard (especially as a P67 Motherboard has absolutely no onboard outs) so i suspect the disabling of the QuickSync Detection in different scenarios is mainly controlled by the Intel Driver so the chain for this could be Bios->Intel Driver->Media SDK API->3rd Party Application :)
Lucids Virtu copys the Framebuffer to the Onboard out that has absolutely nothing todo with the QuickSync Enable/Disable (can be seen by a 3rd party app/ cant be seen) so something smells iffy here, especialy on a P67 board. All that gets even more confusing if you read Anandtechs article about the same Intel Presentation where suddenly a H67 board is in that machine (that's also why i made the joke, that earlier someone seems to not understood correct about the new intel innovation of a automatically switching chipset ;) ).

[popper]

carriage returns are good CruNcher, please use them more :cool:.
Sharktooth currently it's very confusing how and when it works some reviews say you just need to connect a Monitor on 1 of the onboard outs so Dual Monitoring on a H67 Motherboard with a discrete Card to activate it.

Would also fit to whats written in some Motherboard Manuals, you can find the information that if you don't explicitly set the shared memory value the VGA output on a H67 Board gets disabled though no word about DVI and if that might be disabling QuickSync also.

Though still it holds what i wrote earlier

the Intel guy said (http://www.youtube.com/watch?v=gui_6sNc7Eo) hes running a P67 board and their you saw QuickSync working with Lucids Virtu GPU Virtualization and officialy that shouldn't be possible on a P67 Motherboard (especially as a P67 Motherboard has absolutely no onboard outs)

so i suspect the disabling of the QuickSync Detection in different scenarios is mainly controlled by the Intel Driver

so the chain for this could be
Bios->Intel Driver->Media SDK API->3rd Party Application :)

Lucids Virtu copys the Framebuffer to the Onboard out that has absolutely nothing todo with the QuickSync Enable/Disable (can be seen by a 3rd party app/ cant be seen)
so something smells iffy here, especialy on a P67 board.

All that gets even more confusing if you read Anandtechs article about the same Intel Presentation where suddenly a H67 board is in that machine

(that's also why i made the joke, that earlier someone seems to not understood correct about the new intel innovation of a automatically switching chipset ;) ).

it's clear by now that a BIOS update will perhaps be the quickest fix here, so as to set the required control "bit" for the activation of the ASIC and related circuit's.

it would also seem to me now, that upper Intel board members
(just like AMD and their UVD decode, and as odd as it might seem to doom9 readers and the like),
didn't really consider the Media Engine ASIC as a mass market want/need, but rather just a way to grow their new vertical on-line video protected video markets etc, and the ability to PR match the Encode/Decode ability's as found on all ARM cortex A8/9 SOC today...OC

only now that the mass web presence and bad reviews bringing up the flaws of disabling their Media Engine ASIC if there's no ability to use/plug in an on-board monitor is it becoming clear to them we do want to try and use it as its available on all SB as a generic standard, and gives 3rd party vendors something new to advertise and make profit on.

it seems like good luck rather than good management choices saves Intel in this, as they dont seem to include the DRM parts inside the same ASIC as AMD did with their UVD, and so Intel can release the Encode/Decode info required later for embedded Linux use etc, whereas AMD dont and cant without a signed NDA, even today 3 UVD versions in.

(and AMD still didn't think to separate out that DRM from the decode UVD ASIC to date, never mind put some form of Encode in there for 2011 use to match ARM cortex capabilities etc).

[7oby]

There is no status. Nothing has happened. I haven't talked to him in weeks.
News:
I don't know about Francois, but our team is definitely working on it [bring Intel’s Quick Sync Encode/decode ASIC to general linux use], keep an eye on the mailing list for patches and status updates.
http://phoronix.com/forums/showthread.php?29110-Intel-s-Linux-Sandy-Bridge-Graphics-Still-Troubling&p=167917#post167917

But maybe this just refers to the DEcoding part (boring).

[kolak]

Quite interesting:

Intel provided a technological preview of the Grass Valley EDIUS 6 nonlinear editing (NLE) software, at the Intel Forum 2011 held in Japan, on January 18th 2011. At the Tokyo press conference, Intel highlighted its newly announced 2nd Generation Intel Core processor, embedded with Intel Quick Sync Video technology.
Grass Valley presented a technology preview of a forthcoming update to EDIUS 6, which has been fully optimised for the new Intel processor for hardware encoding support for H.264 videos, allowing for “faster than realtime” encoding of full HD (1920×1080) H.264 videos on a broad range of computers from notebook PCs to desktop PCs, using the new 2nd Generation Core Processor. More than 500 laptop and desktop PC platform designs are expected from all major computer manufacturers worldwide based on this new processor family. The EDIUS 6 update allows users to export to Blu-ray, or to the AVCHD format, faster than real-time directly from the EDIUS timeline.
“With our second generation Core processors, video editors using Grass Valley’s EDIUS 6 will be able to complete their work faster than ever,” said Fumihisa Shimono, Director of Software Marketing of Intel. “We know that in video, editing is all about performance and speed, and the combination of our second generation Core processors and EDIUS 6 deliver just that.”
“Working closely with Intel, we have fine-tuned EDIUS 6 to deliver the best and fastest post-production solutions to the market,” said Jeff Rosica, Executive Vice President of Grass Valley. “With H.264 and AVCHD becoming a key format for distribution, providing a faster solution is exactly what video editors need.”


Andrew

[Mug Funky]

“With H.264 and AVCHD becoming a key format for distribution, providing a faster solution is exactly what video editors need.”

ha!

the LAST thing an editor needs is their client whingeing about poor quality video and demanding more time in the suite!

when i switched to x264encoder on the mac, clients were gobsmacked that their pictures looked so good at email-able sizes. they kept ringing after the fact trying to figure out why their files always came out so much bigger and looked terrible.

a good solution in the long run will be faster than a fast solution that is not as good. editors don't want to be pulled out of sessions to re-do things that were out the door a week ago.

[kolak]

AVCHD became very popular, because of such a big use in cameras and compatibility with BD players, but it's a very bad format for editing.

EDITORS have no clue about quality and codecs. All old school AVID editors understand only one word TAPE. For them something like DNxHD, AVC-I is a black magic:) They just do editing and at the end need export button.
When I said I can export 2h HD timeline in 15min, my AVID friend was confused- 2H in 15min? It's impossible- hehehe :)

Edius users want ok looking AVC as fast as possible. They complain about time, which is needed to export AVC (Edius uses Mainconcept engine) and being told about x264, but for them to use it is also black magic. They still use MPEG2 for BD. They just don't wan't to hear about avisynth, cmd line, scripting etc :) GV knows about it and because they have a good programmers their implementation may be ok and fast. That's all what their customers need.
Why they just don't make x264 plugin- heh, good question, but for different debate :)

I was just quite surprised that they so quickly jumped into new technology. Good for Intel and they made a story of it :)
Grass Valley has quite good reputation for their products.

You would be surprised how many times I received 5Mbit AVC file (encoded with QT) for use on BD- because it's small- buahha :)

Andrew

[Audionut]

@kolak

I hope you spend as much time training these people to not be so spastic as you do voicing your opinions on this forum.

[Lyris]

You would be surprised how many times I received 5Mbit AVC file (encoded with QT) for use on BD- because it's small- buahha :)

I've heard of some smaller studios sending assets on DVD and asking if the compressionists can just re-encode those - quality? Nahhhh!

But 5mbit AVC (especially with Apple's implementation of AVC!), what are they smoking?

[kolak]

Lest wait till end of Q1 and we will see what (or rather how fast) Quick Sync will be able to deliver from Edius timeline.

Andrew

[weasel_]

said Fumihisa Shimono, Director of Software Marketing of Intel. “We know that in video, editing is all about performance and speed, and the combination of our second generation
This is absolutely wrong. Its about quality /efficiency.
I rly cant understand how he can said that.

[Mixer73]

This is absolutely wrong. Its about quality /efficiency. I rly cant understand how he can said that.

Well it depends, if they are accelerating realtime functions while editing and alowing them for rushes/preview I think its OK.

Especially if they just use the decoding side then use the Canopus sw codecs for encoding, this could be a very good boost to the productivity.

[laserfan]

This is absolutely wrong. Its about quality /efficiency. I rly cant understand how he can said that.
Look up his word "performance"--there are numerous definitions which include the word "quality" e.g. this one:

performance [pəˈfɔːməns]
n
1. the act, process, or art of performing
2. an artistic or dramatic production last night's performance was terrible
3. manner or quality of functioning a machine's performance
4. Informal mode of conduct or behaviour, esp when distasteful or irregular what did you mean by that performance at the restaurant?
etc..

When I read the quote from Shimono I did not question that when using "performance" he meant it to include a measure of "quality".

[weasel_]

If hi meant that then ok, my bad.

[Rodger]

Hi guys,

so I got my Sandy Bridge here now ;)
Vcore set @1,3V my 2500K does a rock stable 4.560Mhz.

Boy I can tell this new system makes my old Core2Quad system look ooold :D

If I can do any tests for you just send me a short PM as I may be busy the next days.

x264 HD BENCHMARK 3.0 RESULTS

Please do not compare it with older versions of the benchmark!
Please copy/paste everything below the line to to report your data

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Results for x264.exe r1342
--------------------------
encoded 1442 frames, 125.25 fps, 3900.68 kb/s
encoded 1442 frames, 125.09 fps, 3900.68 kb/s
encoded 1442 frames, 125.59 fps, 3900.68 kb/s
encoded 1442 frames, 125.60 fps, 3900.68 kb/s
encoded 1442 frames, 37.64 fps, 3971.09 kb/s
encoded 1442 frames, 37.27 fps, 3971.60 kb/s
encoded 1442 frames, 37.67 fps, 3971.38 kb/s
encoded 1442 frames, 37.64 fps, 3970.90 kb/s

[kolak]

Hi guys,

so I got my Sandy Bridge here now ;)
Vcore set @1,3V my 2500K does a rock stable 4.560Mhz.

Boy I can tell this new system makes my old Core2Quad system look ooold :D

If I can do any tests for you just send me a short PM as I may be busy the next days.

Try new x264- this one uses old build- much slower (at least on my X5355)

Andrew

[Rodger]

Sorry, I´m afraid I didn´t get you.

You´re talking about the benchmark, or usual encoding?
When encoding I use the current release from komisar (http://komisar.gin.by/).

The benchmark should be the current release too.
Used the only link to be found on that page to download the prog.
You got a link where to download anything newer?

[kolak]

Sorry, I´m afraid I didn´t get you.

You´re talking about the benchmark, or usual encoding?
When encoding I use the current release from komisar (http://komisar.gin.by/).

The benchmark should be the current release too.
Used the only link to be found on that page to download the prog.
You got a link where to download anything newer?

Replace x264.exe with latest one. It's 1.5 faster on my 8 core machine.

Andrew

[CruNcher]

My Sandy Bridge is still stucking @ the Shop the Memory has run out i ordered with so i have to wait before it arrives @ the seller :(
So still some time before im gonna be able to compare Nvidia (the real Nvidia Encoder not what Annandtech compared with) vs Quick Sync

btw this is really amazing on the Desktop (and their seem to be still reserves left to save off,without hurting much other usage scenarios):)

http://img262.imageshack.us/img262/6802/power5.png

that's the same power consumption the boxee box uses (according to a talk with a boxee engineer, CE4100 @ Full HD complete system) for 1080p playback :)

it really looks like the same Video Decoder (1080p) core is working inside Westmere and Sandy Bridge that works inside the GMA500 (CE4100) :)

i cant wait to see where CoreAVC and DiAVC stay (also in feature comparison like x264 lossless support) and how Nvidias VPX compares to that :)

Being able to utilize this for Decoding/Encoding (fully utilizing Media SDK 2.0) instead of Nvidias nvcuvid could show some benefits with the lower overhead being non discrete as well much lower overhead then shuffling data around from the CPU/GPU via PCI-E especially nice for Flash 10.2 :)

No review site so far released any Power Consumption results @ Encoding :(

[kypec]

Benchmarking such ancient revisions of x264 (r1342) on new generation CPUs is especially meaningless!
Please stop posting those benchmark results. They serve no other purpose but confusion.

[nm]

that's the same power consumption the boxee box uses (according to a talk with a boxee engineer, CE4100 @ Full HD complete system) for 1080p playback :)

it really looks like the same Video Decoder (1080p) core is working inside Westmere and Sandy Bridge that works inside the GMA500 (CE4100) :)

You can't draw such conclusions from system power consumption alone when the entire architecture is different. The hardware decoder in Sandy Bridge is much faster than the one in GMA500: according to QuickSync benchmarks, SB MFX can decode 1080i30 video at over 10x realtime speeds. That's about 4x faster than other widely available hardware decoders.

I think this is also a contributing factor to why QuickSync outperformed fast GPUs and software encoders (Ati) used in the reviews -- the competition was bottlenecked by much slower hardware decoders.

[kypec]

The hardware decoder in Sandy Bridge is much faster than the one in GMA500: according to QuickSync benchmarks, SB MFX can decode 1080i30 video at over 10x realtime speeds. That's about 4x faster than other widely available hardware decoders.
Is there any chance that QS video-decoder engine be used in players/source filters (MPC-HC, VLC, ffdshow, ffmpegsource) in near future?

[nm]

Is there any chance that QS video-decoder engine be used in players/source filters (MPC-HC, VLC, ffdshow, ffmpegsource) in near future?

It can be used now through DXVA2 in MPC-HC, VLC and ffdshow-tryouts. To use it more efficiently and to get the decoded video back to AviSynth like DGDecNV does, somebody would need to write a source filter that uses Intel Media SDK.

[Sharktooth]

or OpenCL 1.1, so that will work on nvidia, ati and SB (according (http://news.cnet.com/8301-13924_3-20016302-64.html) to Thomas Piazza - Intel director of graphics architecture)

[Rodger]

Here are the results:

x264 HD BENCHMARK 3.0 RESULTS

Please do not compare it with older versions of the benchmark!
Please copy/paste everything below the line to to report your data

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Results for x264.exe r1342
--------------------------
encoded 1442 frames, 181.25 fps, 3911.51 kb/s
encoded 1442 frames, 181.61 fps, 3911.51 kb/s
encoded 1442 frames, 180.88 fps, 3911.51 kb/s
encoded 1442 frames, 179.82 fps, 3911.51 kb/s
encoded 1442 frames, 34.25 fps, 3962.88 kb/s
encoded 1442 frames, 38.63 fps, 3963.13 kb/s
encoded 1442 frames, 38.72 fps, 3962.83 kb/s
encoded 1442 frames, 38.63 fps, 3962.43 kb/s


System Details
--------------
Name Intel Sandy Bridge
product System Product Name
Codename
Specification Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
Specification PC3-12800
Specification PC3-12800
Core Stepping
Technology 32 nm
Stock frequency 3300 MHz
Core Speed 3343.5 MHz

Northbridge Intel ID0100 rev. 09
Southbridge Intel ID1C46 rev. 04

Command Rate 2T
Command Rate 2T
Memory Type
Memory Size 8192 MBytes

Windows Version Microsoft Windows 7 (6.1) Home Premium Edition (Build 7600)

Number of processors 1
Number of threads 4
Number of threads 4 (max 16)
L2 cache 4 x 256 KBytes, 8-way set associative, 64-byte line size
Instructions sets MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, EM64T, VT-x, AES, AVX
Package (platform ID) (0x1)

Temperature 0 33°C (91°F) [0x21] (SYSTIN)
Temperature 1 60°C (139°F) [0x188] (CPUTIN)
Temperature 2 35°C (94°F) [0x46] (AUXTIN)
Temperature 0 42°C (107°F) [0x38] (Core #0)
Temperature 1 44°C (111°F) [0x36] (Core #1)
Temperature 2 47°C (116°F) [0x33] (Core #2)
Temperature 3 43°C (109°F) [0x37] (Core #3)


For the clever ones of you! I PERSONALLY exchanged the x264 with the current one from komisar.
So it´s NOT r1342 but r1882 from komisar! The release-Version is obiously a FIX VALUE in the result.rtf file!!!
So don´t bug me anymore with wrong sugguestiones!
As there are more things wrong in the log-file.
CPU-Speed is 4560Mhz !!!
(RAM-Speed is 811Mhz)
Command Rate for RAM is 1T !!!

[CruNcher]

So @ 4.5 + 1.1 Ghz (Nominal clock ?) you reach +10 fps more you can say 1 Ghz = 10 so + 500Mhz could be + 5 fps @ what are each core clocks for you when running the benchmark and did you tried how long it sustains stable (turbo boost, at that temperatures i guess it can hold pretty long) ?

The difference isn't that big in the build it stays nicely comparable with the gathered Review results maybe -+1 fps (nothing really to care
about) :)

PS: Sandy Bridge is on its Way :)

You can't draw such conclusions from system power consumption alone when the entire architecture is different. The hardware decoder in Sandy Bridge is much faster than the one in GMA500: according to QuickSync benchmarks, SB MFX can decode 1080i30 video at over 10x realtime speeds. That's about 4x faster than other widely available hardware decoders.

I think this is also a contributing factor to why QuickSync outperformed fast GPUs and software encoders (Ati) used in the reviews -- the competition was bottlenecked by much slower hardware decoders.

True wow which review showed that 10x with deinterlacing on the 6 (HD2000) or 12 (HD3000) EUs ?
and i hope its faster then the CE4100 SGX, it seems really perfect suited for high efficient HTPCs with the Power for other Tasks available on Demand finally we go that direction :)
Lucidlogix just has to release Virtu and we can mix that with discrete 3D performance and then Power switch like on Optimus on the Desktop that will rock not to think about the other possibilities like using both DSPs :D and CUDA while using Quick Sync and mix and match :)
Platform wise it would also rock for a new Game Console it would blast the Xbox 360 into oblivion @ the same power consumption not sure about the PS3 though :)

Combining Nvidias/ATis DSP with CUDA/AAP and Quick Sync, AVX could make some crazy frameworks possible (has to be evaluated, working on their own or combined) :)

[Sharktooth]

+1 fps on the second half of the test.

[Rodger]

Here are some screenshots for the interested:

Idle..............................................................................OC...............................................................................RAM
http://i55.tinypic.com/r074ts.jpghttp://i52.tinypic.com/oardoo.jpghttp://i51.tinypic.com/2zrdr3m.jpg

Overclocking SANDY BRIDGE:
There are some new things that pop up as unclear every now and then.
CPU 2500 without K = NO OVERCLOCKING!
CPU 2500K = Overclockable!
Intel P67 Chipset = Overclocking but NO GRAPHICS ONBOARD! (You need discrete graphics!)
Intel H67 Chipset = NO OVERCLOCKING but you can use integrated HD Graphics
So it´s pretty clear to go like 2500K CPU + Board with P67 Chipset OR 2500 without K + Board with H67 Chipset!
Thanks you Intel you can´t have both !!!
Turbo-Mode on the other side is active with both chipsets and so it seems turbo mode is no overclocking to Intel ?! (crazy guys!)
Overclocking the "K"-CPUs is done via the Turbo-Mode multiplier wich is unlocked here. All other CPUs have a fixed Turbo-Mode multiplier!
So if you want to overclock you CPU, you´d better go with a i7 2600K (TOP MODEL!) or the i5 2500K.
Only the top model 2600K and 2600 without K (;)) do support HT (HyperThreading)!

Additional you can´t or hardly can overclock a CPU via FSB alias BCLK! At the most you should set that value to 106 since you seriously can damage attached Hardware! Intel even WARNS to use anything but clean 100Mhz!
OC Profile on Asus-Motherboards uses 103Mhz! This just as a sidenote.

If I got cruncher right this is the answer:
Turbo-Mode is not limited! It´s only limited if your CPU-temperatures are bad! In that case the CPU reduces or disables the turbo-mode to prevent overheating.
To me - having a watercooled system :D - the Turbo-Mode is never ending ;) So as soon there is enough CPU load the CPU switches to turbo-mode.

[CruNcher]

Here are some screenshots for the interested:

Idle..............................................................................OC...............................................................................RAM
http://i55.tinypic.com/r074ts.jpghttp://i52.tinypic.com/oardoo.jpghttp://i51.tinypic.com/2zrdr3m.jpg

Overclocking SANDY BRIDGE:
There are some new things that pop up as unclear every now and then.
CPU 2500 without K = NO OVERCLOCKING!
CPU 2500K = Overclockable!
Intel P67 Chipset = Overclocking but NO GRAPHICS ONBOARD! (You need discrere graphics!)
Intel H67 Chipset = NO OVERCLOCKING but you can use integrated HD Graphics
So it´s pretty clear to go like 2500K CPU + Board with P67 Chipset OR 2500 without K + Board with H67 Chipset!
Thanks you Intel you can´t have both !!!
Turbo-Mode on the other side is active with both chipsets and so it seems turbo mode is no overclocking to Intel ?! (crazy guys!)
Overclocking the "K"-CPUs is done via the Turbo-Mode multiplier wich is unlocked here. All other CPUs have a fixed Turbo-Mode multiplier!
So if you want to overclock you CPU, you´d better go with a i7 2600K (TOP MODEL!) or the i5 2500K.
Only the top model 2600K and 2600 without K (;)) do support HT (HyperThreading)!

Additional you can´t or hardly can overclock a CPU via FSB alias BCLK! At the most you should set that value to 106 since you seriously can damage attached Hardware! Intel even WARNS to use anything but clean 100Mhz!
OC Profile on Asus-Motherboards uses 103Mhz! This just as a sidenote.

If I got cruncher right this is the answer:
Turbo-Mode is not limited! It´s only limited if your CPU-temperatures are bad! In that case the CPU reduces or disables the turbo-mode to prevent overheating.
To me - having a watercooling system :D - the Turbo-Mode is never ending ;)

Though its not entirely true also the H67 boards allow to change the Turbo multiplier just very calm not in the range of where you are x45 most is x37 for H67 but for me using every resource possible is more important so P67 was no choice and Z67 not available so i set my hopes into Lucids Virtu for H67 and if that should be a wrong guess i gonna switch over to Z67 later.
If im right and didn't missunderstand i can boost the 2400 i took to a max x37 even on the H67, though i wont use that as im not interested in overclocking rather undervolting hehe ;)

[Rodger]

I have never ever heard of changeable turbo-mode multipliers on ANY H67 board!
Which one does support it???

Of course you may set the turbo mode multiplier to fixed value of the certain CPU which will be CPU stock + 4 Steps.
Example Core i5 2500 (without K): 3,3Ghz + 4x100Mhz Turbo = 3,7Ghz

So in your case you are wrong!
Core i5 2400: 3,1Ghz + 3 Steps (3x100Mhz) = 3,4Ghz MAX!!! (Multiplier is LOCKED by Intel!!!)
Only 2500 + 2600 have 4 Steps for Turbo-Mode! All others I think only 3 Steps.

- GERMAN -
In unserer Sprache hier zitiert aus z.B. dem Mindfactory-Board:
Wie ich soeben erfahren habe lassen sich die Multiplikatoren für die frei übertaktbaren K-Prozessoren bei Mainboards mit Intel H67 Chipsatz nicht frei einstellen.
Es macht also keinen Sinn ein H67 Mainboard mit einer ****K CPU zu bestücken.
- GERMAN OFF -

Cooling Advice:
In order to use the turbo-mode as much as possible you should look out for a CPU-cooler capable of coping with the heat from the CPU.
The stock cooler is said to be OKAY for system with a lot air flow. But systems aiming on silence need a better/bigger CPU cooler!
Watch out! Since there is a lot to be read, that coolers collide with parts on mainboard because of their sized. You better read about positive opinions on which cooler is workling fine with the mainboard of your choice.

[CruNcher]

Thats what i meant fixing it on x34 in my case though im confident that someone can brake this restriction anyway in the future ;)
lol just realized they canceled the Motherboard on my order also MF, locally i find only P67 boards geez :(

[nm]

True wow which review showed that 10x with deinterlacing on the 6 (HD2000) or 12 (HD3000) EUs ?

This one with HD3000: http://www.tomshardware.com/reviews/sandy-bridge-core-i7-2600k-core-i5-2500k,2833-5.html

But I doubt the deinterlacing is anything fancy at that speed.

Here's 11x decoding speed for a 12 Mbps 24p source: http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i7-2600k-i5-2500k-core-i3-2100-tested/9 (see the last figure on the page)

[CruNcher]

It depends what quality Intels Deinterlacing is @ :) but yeah Yadiff on the SB should be super fast as well but the more you can push on the DSPs the more you can free up the CPU for x264 encoding, the last HQV test though showed that Intel didn't reached Nvidia nor ATI yet @ Deinterlacing Quality but maybe they can blow it @ speed also, though hard to say with the current reviews :)
Now i have a SB system without Motherboard :p seems the demand is still heavy

[Sharktooth]

Here are some screenshots for the interested:

Idle..............................................................................OC...............................................................................RAM
http://i55.tinypic.com/r074ts.jpghttp://i52.tinypic.com/oardoo.jpghttp://i51.tinypic.com/2zrdr3m.jpg

Overclocking SANDY BRIDGE:
There are some new things that pop up as unclear every now and then.
CPU 2500 without K = NO OVERCLOCKING!
CPU 2500K = Overclockable!
Intel P67 Chipset = Overclocking but NO GRAPHICS ONBOARD! (You need discrete graphics!)
Intel H67 Chipset = NO OVERCLOCKING but you can use integrated HD Graphics
So it´s pretty clear to go like 2500K CPU + Board with P67 Chipset OR 2500 without K + Board with H67 Chipset!
Thanks you Intel you can´t have both !!!
Turbo-Mode on the other side is active with both chipsets and so it seems turbo mode is no overclocking to Intel ?! (crazy guys!)
Overclocking the "K"-CPUs is done via the Turbo-Mode multiplier wich is unlocked here. All other CPUs have a fixed Turbo-Mode multiplier!
So if you want to overclock you CPU, you´d better go with a i7 2600K (TOP MODEL!) or the i5 2500K.
Only the top model 2600K and 2600 without K (;)) do support HT (HyperThreading)!

Additional you can´t or hardly can overclock a CPU via FSB alias BCLK! At the most you should set that value to 106 since you seriously can damage attached Hardware! Intel even WARNS to use anything but clean 100Mhz!
OC Profile on Asus-Motherboards uses 103Mhz! This just as a sidenote.

If I got cruncher right this is the answer:
Turbo-Mode is not limited! It´s only limited if your CPU-temperatures are bad! In that case the CPU reduces or disables the turbo-mode to prevent overheating.
To me - having a watercooled system :D - the Turbo-Mode is never ending ;) So as soon there is enough CPU load the CPU switches to turbo-mode.
you can get more performance from your RAM rising the CAS latency or maybe overvolting the RAM modules.
check this table: http://www.webalice.it/f.corriga/stuff/memlatency.jpg

[Didée]

Just that RAM performance does hardly ever matter. It's mostly important for e-peniz signatures. Overall performance stays almost unaffected. L3 cache is where the party's happening.

[Rodger]

Yeah you´re right and I´m not done with my RAM yet :D
I bought a 8GB Corsair Vengence KIT. Here is a Test of the CL9 Kit if you like http://www.overclockersclub.com/reviews/corsair_vengeance_8gb/
But I chose the CL8 Kit ;) So AT LEAST I´m going to be able to set the 1833er divider. And very important to me...without giving the RAM absurd voltages. 1.65V will definetly be MAX!
Sandy Bridge doesn´t scale so much with the RAM timings but at least a little with the clocks of RAM.
So it´s better to choose clocks over timings.
1300Mhz 8-8-8-21 won´t be as fast as 1600Mhz 9-9-9-24
And even more important in my point of view is the 1T Command Rate. A whole lot of performance is unleashed with that setting.

[woah!]

+1 fps on the second half of the test.

i'm actually not that impressed by it. i get that fps from my 1055T at 3.9ghz. and the cpu is much cheaper than the 2500K is.

and it is the 2nd pass that really matters for most here, as the 1st pass has the fastest settings you can on x264 set.

bulldozer here i come..

[Rodger]

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.

[Sharktooth]

comparing different generations CPU is not so fair. however AMD x6 CPUs are still on track with performance per dollar/euro ratio.
bulldozer is not out yet, but it will be surely an interesting CPU.

[woah!]

what does it matter how many cores it has if its $60 cheaper? it wasnt long ago that intel used 3.2ghz to match a 2.5ghz amd chip, but intel actually sold more because more mhz must means faster right?

basically i want a encoding box for cheap, and well 6 core / 12 core whatever, if its as fast and cheaper how does it matter?

[Rodger]

In THAT CASE wait for the soon released 10core CPUs from Intel based on the new architecture.

But anyway I need a full package to be done by my computer and this is where current AMD CPUs just suck big time. As soon as all cores are used AMD CPUs do become interesting and useful. But that is just not much the case...

[woah!]

i am not trying to come across as amd bias here, i have had intel QX6700 / Q9550 for years. i was looking to upgrade to a SB thats all. yes a westmere might do the trick if amd bulldozer fails.

[Rodger]

Me too...I don´t want to sound like an Intel fan guy or something. I´ve had AMD for so many years myself. I like the idea AMD stands for but they didn´t do very well for quite a while now and insider reports really don´t sound nice when it comes to bulldozer.
It´s said bulldozer won´t even catch the performance of the first generation Core i series, which would be devastating. AMD can´t possibly be able to stand that price dumping of their CPUs for much longer. Be honest...the 6 Core CPUs would have to be much more expensive if AMD would have to make money with selling them.

No! No need to upgrade for you, if you really do have your total preferences on encoding.
I based my decision on a huge test from a site here in germany. So it´s in german language but the numbers speak volumes. http://www.computerbase.de/artikel/prozessoren/2011/test-intel-sandy-bridge/28/#abschnitt_x264_hd_benchmark_319
In this article the AMDs don´t stand a chance. At stock speed the AMD1075T and the Intel 2500K are this one time at same speed when going for the second pass. But just this once.

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

[kieranrk]

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.

I contacted the Head of Developer Relations at AMD through a contact last year, and our request was rebuffed in spite of describing our contact with Intel...

[burfadel]

I think part of the reason why it hasn't been so is if they help out one developer (for x264), then other developers would scream foul that they didn't have a chance too. The end result is a lot of consultation hours, risk of corporate espionage (yes that is a real thing! and way too common for it not to be a threat), and the risk of companies (not in x264's case) doing a poor implementation then saying it was done with assistance - which doesn't help Intel or AMD's case, it hinders it!

So at best you can really only deal with what they provide to everyone. Of course then there's the assistance to games developers by (mostly) Nvidia, which gets them a nice 'the way its meant to be played' video at the beginning of the games and joy that although games aren't specifically designed to run poorly on the competitors cards (AMD GPU's), they certainly aren't tweaked in their favour either. Its pretty much the reason why even after Directx 10.1 was released games only supported Direct 10, even though ATI (now part of AMD) cards supported Directx 10.1 - Nvidia did not recognise Directx 10.1 for a long time, even with 'newer generation' cards, as it would have required some redesigning. Some games like Bioshock were originally Directx 10.1, but were stripped down to Directx 10. The rumour behind this is because Directx 10.1 fixed one of the major flaws with Directx 10, slowness in antialiasing (I think it was that from memory!). The originall Bioshock heavily favoured ATI cards because of this, as the Nvidia cards only ran in Directx 10, and as a result it was pulled. The given reason was shown to be complete bull! Despite this, at the end of the day almost all games these days are console ports and either have poor engine support or very low quality ported textures that rely on the GPU power to make them look better.

Anyways, the reason why this applies to this argument is because providing support can be risky, even if it is seemingly in your favour. Something that favours Intel or AMD more would be signficantly more scrutinised than something that favours Nvidia or AMD in terms of graphics, but in both cases it can be risky, especially if say, the quality of the output derived from Intels help doesn't meet quality expectations etc...

[Dark Shikari]

I think part of the reason why it hasn't been so is if they help out one developer (for x264), then other developers would scream foul that they didn't have a chance too.Except that they do work with other developers. All the time. Especially developers of programs used to benchmark their CPUs.

[cyberbeing]

Especially developers of programs used to benchmark their CPUs.

Then why not create an 'official' x264 benchmark and field it to the tech sites.

Effort
+
GUI
+
benchmarks for easily identifiable operations (SAD, motion search, etc) in x264
+
checkasm --bench for advanced results
+
x264 1080p encode test with --preset superfast , --preset medium , and --preset veryslow
+
Pretty graphs of results which compares results to reference systems from each CPU platform x264 supports
+
Weight results and generate an arbitrary score 1000-10000 (bigger numbers are better ;)) and ranking system similar to other benchmarks
+
(Optional) Video ABX test to assess video quality in motion between presets and non-x264 encodes
+
(Optional) Image ABX test to assess per-frame quality PNG captures between presets and non-x264 encodes
+
(Optional) Source decoding speed (bottleneck) benchmark



I'm half-joking, but if you truly think it could cause CPU vendors to care more about x264, how hard would it be for someone on the dev team to create and maintain such a thing. Give CPU vendors something to point to and brag about if/when they introduce architectural changes that benefit x264 and give them a performance advantage vs competitors. It could also serve the additional purpose of dispelling the myth that x264 is unable to match GPU/Quicksync encoders for speed at similar or better quality. I'm sure you are unsurprised that the common user on an internet forum uses a GPU/Quicksync encoder because they honestly believe marketing hype that it has a speed advantage vs CPU encoding, not because it uses less CPU resources.

[Dark Shikari]

Then why not create an 'official' x264 benchmark and field it to the tech sites.There already is one. :p

[cyberbeing]

Well you could always replace the quasi-official Tech ARP x264 benchmark with something that suits your needs better for x264 vs GPU/Quicksync comparisons and exposes checkasm results to the world. The current x264 bench is obviously not doing enough to make CPU vendors care about x264. CPU/GPU vendors love synthetic benchmarks, and have marketing departments which care more about non-subjective speed claims than quality. Show them you can beat them at the speed game with stock quality-focused x264, identify to the user slow operations taking the majority of x264's CPU time, while having big-name tech websites inform users that x264 is faster/higher-quality than XXX GPU/Quicksync encoder, and maybe they'll start to care. ;)

[Ghitulescu]

I think Dark Shikari is right. No developer wants to trade speed for incertitude. Once one relies on 3rd party implementations, their bugs will be silently incorporated into the product. Nobody would care whether it's the CPU or the software, bottom line the encoding is faulty. It may be even more work, to patch for CPU errors. Plus the DRM issue that might be implemented deep in the core.

[burfadel]

Except that they do work with other developers. All the time. Especially developers of programs used to benchmark their CPUs.

Quite true! I wasn't even thinking about benchmarks when I said that :)

I probably should have said developers of everyday actual useful programs :), benchmark apps aren't really 'everyday' apps. I guess the difference is they see most apps as too insignificant benefit wise to be bothered considering!

Maybe get more hardware review sites to consider using the x264 benchmark and things may change!

[hajj_3]

new quicksync info for Intel Ivy Bridge platform: http://www.anandtech.com/show/4830/intels-ivy-bridge-architecture-exposed/5

"The increase in EUs and improvements to their throughput both contribute to increases in Quick Sync transcoding performance. Presumably Intel has also done some work on the decode side as well, which is actually one of the reasons Sandy Bridge was so fast at transcoding video. The combination of all of this results in up to 2x the video transcoding performance of Sandy Bridge. There's also the option of seeing less of a performance increase but delivering better image quality."

Lets cross our fingers that there is x264 support, i can't see that happening though.

[CruNcher]

Imho Quicksync does a nice job already and putting this performance improvement of Ivy Bridge in actual Quality so that we continue to climb up in comparison to Software implementations like x264 is the right way to go instead of making it even faster it is already very fast and a very nice user experience :)
Though you should still find a right balance for this the balance of Quality/Power Consumption/Encoding Performance and Easy achievable fast workflows this always remain key factors in User Experience. Microsoft especially is becoming very aggressive currently in this user Experience of "Fast and Fluid" vs Google Androids Ecosystem, there a whole lot of changes on those areas including the decimation of Dshow completely from this Top Part of the UI Experience. Especially Intels Quicksync Transcoding Engine plays a major role here and is by standard one of the Encoders Million of Users are gonna use in the Future (for 8 Bit Personal content Encoding).
User don't care what is running behind the curtain they care about the End Result and having a fluid experience while (transcoding,editing,playing.streaming) they care more about how long will my systems battery hold and rather accept a lose in quality that in most user cases isn't really visible @ all. Though there is a chance for bringing the X264 experience over to it but im not sure if it can survive in such a environment anymore http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-783T :(

[hajj_3]

you can do either, you can choose the current video quality and have it upto 2x faster or choose the better quality setting and it will be slightly faster than quicksync is currently with sandybridge. Its a very nice improvement. Intel is already way faster than CUDA/Stream so the speed improvement may hopefully mean microsoft may build support in windows 8 for encoding using h264 or something as it would be extremely fast.

[CruNcher]

you can do either, you can choose the current video quality and have it upto 2x faster or choose the better quality setting and it will be slightly faster than quicksync is currently with sandybridge. Its a very nice improvement. Intel is already way faster than CUDA/Stream so the speed improvement may hopefully mean microsoft may build support in windows 8 for encoding using h264 or something as it would be extremely fast.

That's by default the case if the hardware supports in anyway Transcoding it will be utilized if not most probably the CPU is going to be used but im not sure if Microsoft is going to allow this didn't saw the Certification part yet that might indeed say "You need to provide a DSP for Encoding" it would though fit in their "Fast and Fluid" Agenda.
Windows 8 is combining Android and Chrome OS or Mac OS and IOS under 1 Hood it runs aside (though it is a integral part in terms of Performance) and for some tasks it's more efficient with the right combination of Input Devices or Formfactor then the old Windows Shell :).
That's also why you can Decide what you want to use and when which gives great flexibility also on the Desktop (you not forced to change wouldn't be possible anyways in the early days of this ;) ).
The changes can be compared when Microsoft integrated IE back then as Core component into Windows (which caused the Windows vs State trial) as a integral part now they even do it on a much broader scale deep down to the core functions (abstracted by the WinRT API to multiple programming languages) exactly what HTML5 promised Direct Hardware usage of all Devices melting OS and the Internet (services) together also on the Desktop. When you found .NET scary then you will find this ultimately scary ;)

PS: AMD released their first Bulldozer benchmarks (aside of IDF running some blocks down @ a Press conference called Fussion Zone http://nl.hardware.info/nieuws/24619/eerste-officiele-benchmarks-amd-fx-processor) and surprise surprise they used X264 in form of Handbrake for Benchmark winning it by 19% with 4 modules vs 4 cores ;), and surprise surprise Anandtech was not reporting about this but kept straight focused onto IDF and Ivy Bridge ;).
Though you can most probably guess that this win is bought @ almost the full 125W scale (though nothing really was revealed about the benchmark itself just the result) which everyone knows is not hard to win vs Intels more efficient 95W output driving your max Power to the EDGE.
At least it seems they reach almost Intels Efficiency now and don't hang 2 Generations behind anymore which already is a good sign they are back in a fully recovered state (after all the Fusion investment including ATI) :)

[JoeH]

This study was recently published comparing X264, QuickSync, CUDA and AMD's solution. Incredible article. Final conclusion is that X264 is still the way to go, and that even when QuickSync approaches X264 in SSIM and PSNR scores, visually X264 is noticeably better.

http://www.behardware.com/articles/828-1/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-stream-intel-mediasdk-and-x264.html

[smok3]

JoeH: I can't even imagine the purpose of this test? Is it about power consumption, is it about plastic looking GUI designs or something entirely else? Will i become a one-day hero if i actually encode something with mikisoft GPU accelerated media converter 7? :rolleyes:

[nm]

JoeH: I can't even imagine the purpose of this test?

Huh? It's an encoder comparison, and at a quick glance, much more thorough and correct than they usually are. There are speed, quality and power consumption figures among other things.

[smok3]

27 pages with illustrations to tell, quote: "By offering rapid encoding solutions, but with quality that leaves too much to be desired, H.264 encoding via GPGPU solutions remains, as yet, a poor solution to what is a real problem." ? (but nevermind, i guess i just don't get it :))

[JoeH]

Well, it's actually the first serious comparison I've seen of X264 and QuickSync quality/speed, using objective metrics. If you have seen better studies please share! It is far more thorough even than MSU's last annual study.

Before this there were lots of random comments of people that X264's quality was superior, but very few if any objective metrics to show exactly how much better or worse. This study offers the objective metrics.. finally. But it also offers the subjective side as well, for anyone to see, as you can click on the images and actually change which encoder output you see. Seems pretty valuable to me... just my opinion.

As far as the software included in the study, they are of interest precisely because they use QuickSync. And of course, whether you're using QuickSync with a cheap consumer application or with something more serious like Adobe Premiere, since it's always QuickSync at least in theory you should get the same quality.

[CruNcher]

As far as the software included in the study, they are of interest precisely because they use QuickSync. And of course, whether you're using QuickSync with a cheap consumer application or with something more serious like Adobe Premiere, since it's always QuickSync at least in theory you should get the same quality.

It's unfortunately not that easy as the frameworks itself and the implementation also can differ you need to make your own to compare efficiently and without any hidden quirks, especially Arcsofts Media Converter you need to know whats going on (in the background).
I have my framework almost finished for 3 General Platforms Intel,Nvidia and X264 and by now im used to all 3 Encoder :)
Though im currently working alongside on my Dekstop Realtime Recording Framework on these 3 and i make great process their also, this is also something which in the end will be compared :)

glimps (Quicksync)

http://img148.imageshack.us/img148/7202/thisiscool.png

Also 27 pages for something you could do in much less seems overbloated you get totally lost and don't know after some time what actually is compared :P (and for me it seems they compare actually Encoder Software Frameworks and not individual Cores)

But yeah even with those quirks it is currently the nicest compare in those regards something i wished MSU would have done early on (obviously not in that form though ;) ), i see already a lot of things which are wrong in that compare and let some encoder look more bad then they are based on the test framework it's not fair. :(

The Arcsoft CUDA encoder is quite simply not up to the task. Our other encoders show differences in sharpness.

They actually have 3 different Cuda Encoder :D

Also the compare system they use (this funny half tiled compare with 1000 of options) geez why making such easy things with a common goal extra complex that is completely bogus it looks nice and maybe professional to some but it's bogus and just melts your brain.
Though the Graph Compare system is nicely done and also efficient http://www.behardware.com/marc/h264/graph.htm?all_avatar1080ps1 :)

GeForce 8800s offered decoding of accelerated H.264 streams, though this was partial. There was no GPU support for CABAC decoding at the time (this was added to the following generations).

Also incorrect G92, VP2 fully supports Cabac so they cant write any 8800s series Card doesn't support VLD Decoding.

[JoeTF]

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?

(...)

Considering how much hdds cost nowday due to, well, a few too many rainy days in Malaysia, I would say that was prophetic:D

PS. Don't ban me for this little necro.