x264 and Intel's Media Engine / Sandy Bridge [Archive] - Page 5

CruNcher

12th January 2011, 04:59

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

12th January 2011, 04:59

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

12th January 2011, 05:20

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

12th January 2011, 05:56

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

12th January 2011, 08:21

CruNcher

12th January 2011, 14:10

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

13th January 2011, 00:05

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

13th January 2011, 00:14

Mixer73

13th January 2011, 00:24

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

13th January 2011, 00:29

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

13th January 2011, 00:41

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

13th January 2011, 00:49

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

13th January 2011, 00:54

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

13th January 2011, 01:00

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

13th January 2011, 01:19

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

13th January 2011, 01:23

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

13th January 2011, 01:26

deadrats

13th January 2011, 01:26

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

13th January 2011, 01:36

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

13th January 2011, 01:39

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

13th January 2011, 01:46

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

13th January 2011, 01:47

sorry but @deadrats

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

nurbs

13th January 2011, 01:51

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.

13th January 2011, 01:57

deadrats

13th January 2011, 02:28

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

13th January 2011, 02:32

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

13th January 2011, 02:50

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

13th January 2011, 02:59

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

13th January 2011, 03:05

@ 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

13th January 2011, 03:22

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

13th January 2011, 03:32

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_

13th January 2011, 03:44

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

13th January 2011, 03:47

aegisofrime

13th January 2011, 03:59

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

13th January 2011, 04:11

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

13th January 2011, 10:56

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

14th January 2011, 00:48

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

14th January 2011, 01:57

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

14th January 2011, 02:23

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

14th January 2011, 02:39

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

14th January 2011, 02:54

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

14th January 2011, 03:27

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

14th January 2011, 04:15

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

14th January 2011, 04:18

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_

14th January 2011, 04:42

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

14th January 2011, 08:12

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

14th January 2011, 10:06

@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

14th January 2011, 12:36

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