x264 and Intel's Media Engine / Sandy Bridge

[deadrats]

Originally Posted by Mug Funky

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]

Originally Posted by deadrats

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?

[poisondeathray]

Originally Posted by deadrats

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

[nurbs]

Originally Posted by deadrats

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.

Originally Posted by deadrats

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.

Originally Posted by deadrats

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 is always nice.

[nm]

Originally Posted by deadrats

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? I thought you were a native English speaker?

[deadrats]

Originally Posted by poisondeathray

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]

Originally Posted by nurbs

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]

Originally Posted by deadrats

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]

Originally Posted by Mug Funky

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]

Originally Posted by Didée

@ 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,

[edit] I wrote this before your latest post, havent even looked at the current test [/edit]
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

Originally Posted by deadrats

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,

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

Originally Posted by CruNcher

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]

Originally Posted by Blue_MiSfit

deadrats,

[edit] I wrote this before your latest post, havent even looked at the current test [/edit]
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]

Originally Posted by CruNcher

We want to compare QuickSyncs Quality/Speed here and not Nvidias Encoder vs X264 again

Yes, you're right. There really is
(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]

Originally Posted by Didée

Yes, you're right. There really is
(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.

[deadrats]

Originally Posted by kypec

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.

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]

Originally Posted by deadrats

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?