CUDA H.264 vs x264 Speed and Image Quality Benchmarks, discussion

[St Devious]

Hardware


Intel Q9450 @ 3.2 Ghz
4GB RAM @ 800 MHz 5-4-4-12 2T
GTS 250 512 MB @ 738/1836/1100 MHz (Core/Shader/Memory)


http://i27.tinypic.com/20z7l21.jpg

Software

Nvidia GeForce 186.18 WHQL Drivers
MeGUI 0.3.1.1047
x264 r1178 Jeeb's Build
Mediacoder 0.7.1.4475 for CUDA GPU encoding



Source Videos
VforVendetta 2000Kbps 1280x720 Clip (http://mirror05.x264.nl/Dark/force.php?file=./x264clips/VForVendetta.mkv)

Mediainfo on Source
Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Container profile=Unknown@4.0
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 52s
Nominal bit rate : 2 000 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 2.35
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.091
Writing library : x264 core 65 r999+1 eb3ef1b
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=tesa / subme=9 / psy_rd=1.0:0.0 /
mixed_ref=1 / me_range=32 / chroma_me=1 /trellis=0 / 8x8dct=1 / cqm=0 / deadzone=4,4 / chroma_qp_offset=-2 / threads=3 /
nr=0 / decimate=0 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 /
scenecut=40(pre) / rc=2pass / bitrate=2000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40
/ pb_ratio=1.30 / aq=1:1.00


Encoding Settings
CUDA GPU

http://i31.tinypic.com/2hxr3nd.jpg

MeGUI x264
Preset ultrafast used here
program --bitrate 800 --no-mixed-refs --bframes 1 --no-weightb --direct temporal --nf --no-cabac --subme 1 --partitions none --scenecut 0 --me dia
--threads auto --thread-input --aq-mode 0 --output "output" "input" --subme 0 --preset ultrafast

Speed Results


CUDA GPU H.264 - 23.5s 114.4 FPS
x264 preset ultrafast - 30s 90.8 FPS


Image comparison

Source
http://i29.tinypic.com/1e8dc1.jpg

x264 @ 800 Kbps
http://i27.tinypic.com/dnhl4g.png

CUDA GPU @ 800 Kbps
http://i28.tinypic.com/dfanhf.png

Output File Mediainfo

x264 @ 800 Kbps
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.1
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1mn 52s
Bit rate mode : Variable
Bit rate : 900 Kbps
Nominal bit rate : 800 Kbps
Maximum bit rate : 2 229 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16/9
Frame rate mode : Constant
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.041
Stream size : 12.1 MiB (100%)
Writing library : x264 core 68 r1179M 96e2229
Encoding settings : cabac=0 / ref=1 / deblock=0:0:0 / analyse=0:0 / me=dia / subme=0 / psy_rd=0.0:0.0 / mixed_ref=0 /
me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=6 / nr=0 / decimate=1 / mbaff=0 /
bframes=1 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / wpredb=0 / keyint=250 / keyint_min=25 / scenecut=0 / rc=abr / bitrate=800 /
ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=0



CUDA GPU @ 800 Kbps

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1mn 52s
Bit rate mode : Variable
Bit rate : 869 Kbps
Maximum bit rate : 1 776 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16/9
Frame rate mode : Constant
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.039
Stream size : 11.6 MiB (100%)


http://i32.tinypic.com/beggah.jpg

Shows that GPU temperature rose by 6 C when encoding. CPU Usage was almost 95% on all 4 cores during the encode.


More soon...

Suggest settings and comparisons you would like to see.

EDIT: Thank you for you suggestion guys.

As I said in my OP, that there is more to come with different sources at different resolutions.

I'm not trying to advertise anyone here. Just feeding my curiosity to see what kind of encoding does the free CUDA encoder do and probably helping others feeling the same way in the process.

The settings in this encode were used to test the pure speed of x264, to see if it could be as fast as GPU encode at similar or better quality. Since that didn't happen, I will try to match the quality and see what is the difference in performance.

As to the hardware used, this is the best thing I have access to right now. Also as others said GTS 250 is a last generation GPU based on the G92 chip used in 8800GTS 512 MB, 9800GTX, 9800 GTX+.

Also I may use Badaboom and MediaShow Espresso in future if time permits.

Also I plan on using this video

1080p VBR Video Quality Test Streams
Sony HDW-F900 footage, 1080p@25, 18 Mbps average, 30 Mbps peak in a 35 Mbps Transport Stream (259,534,064 bytes)

on this page http://www.w6rz.net/ as one of the sources. Please let me know if there is another uncompressed source you would like me to try.

I'm not too sure about the questions regarding the decoder, I only have ffdshow+haali media splitter installed on my system.
I would really appreciate if you let me know If i need to change something with the decoders.

[roozhou]

MeGUI uses avisynth to frameserve but mediacoder uses mencoder to decode and pipes raw data to encoders.
With "ultrafast" settings decoding may become a bottleneck for x264.

[kumi]

I wonder what settings MediaCoder used to arrive at these benchmarks (http://blog.mediacoderhq.com/benchmarks-cuda-h-264-vs-x264/)?

[stanleyhuang]

Absolutely. Though the decoding is done in the separate process and there is a large ring-buffer to connect decoder and encoder, the decoding is still a bottleneck on a fast multi-core processor. Fortunately mplayer-mt/ffmpeg-mt has multi-threaded H.264 decoding.

MeGUI uses avisynth to frameserve but mediacoder uses mencoder to decode and pipes raw data to encoders.
With "ultrafast" settings decoding may become a bottleneck for x264.

[Dark Shikari]

Why did you use such retardedly low quality settings with x264?

At a minimum your goal should be to match the quality of the two; it makes no sense to test two encoders against each other in terms of speed at vastly different compression settings.

Also, if you're going to compare two encoders, use raw video input, not a highly compressed H.264 stream whose decoding method differs between the two encoders.

[stanleyhuang]

I think Q9450 and GTS250 is not the hardware of the same level, at least not the same price. ;-)

[Dark Shikari]

I think Q9450 and GTS250 is not the hardware of the same level, at least not the same price. ;-)This as well. It's rather disingenuous to pick a last-generation CPU and compare to a current GPU (and then question why the former is slower).

[stanleyhuang]

Actually x264 do generate better quality when it is configured for maximum quality, but that will also make the transcoding extremely slow.

[Fr4nz]

This is a totally borked comparison...

[Dark Shikari]

Actually x264 do generate better quality when it is configured for maximum quality, but that will also make the transcoding extremely slow.You hardly need "maximum quality"; even the (reasonable) faster settings beat the crappy CUDA encoder easily quality-wise, as has been tested dozens of time before with exactly this encoder.

Of course, it doesn't help that he even turned off subpixel motion vectors though... his settings are completely ridiculous.This is a totally b0rked comparison...Yes, and he posted it in a very official-looking fashion despite the entire thing being done in a completely idiotic and haphazard manner.

I mean seriously:

1. Pick a GPU that's more costly and faster than the CPU.
2. Go out of the way to pick the worst possible settings for x264 (literally!)
3. Use two different decoders to feed the different encoders.
4. Show how the GPU encoder looks so much better than x264.

I'm not going to bother with this anymore as it's clear that this guy is here solely to try to advertise crappy encoders by performing intentionally bad tests.

[stanleyhuang]

I've published the x264 options in my benchmark (http://blog.mediacoderhq.com/benchmarks-cuda-h-264-vs-x264/). Under this configuration, both encoders have near (x264 is slightly better) output quality. The CPU I used costs about US$ 195, the GPU (display adapter with 896MB onboard GDDR3) I used costs about US$ 235.

PS1: For serious encoding, I myself use x264.
PS2: I don't know and have no relationship with St Devious and I don't think he can benefit anything by advertising the crappy encoder. I just saw this post by a back-link to my blog.

[Fr4nz]

2. Go out of the way to pick the worst possible settings for x264 (literally!)

I think this is the most important point that invalidates the comparison: you have to use *possibily* the same settings in both encoders in order to make a credible comparison.

[stanleyhuang]

He might just want x264 to work as fast as it can.

[roozhou]

He might just want x264 to work as fast as it can.

I wonder why x264 ran so slowly with --preset ultrafast on a Quad-core.

[slavickas]

This as well. It's rather disingenuous to pick a last-generation CPU and compare to a current GPU (and then question why the former is slower).

err no GTS 250 = 9800GTX+ ~= 8800 GTS

[Reimar]

I wonder why x264 ran so slowly with --preset ultrafast on a Quad-core.

Probably due to decoding speed. Unfortunately it is unclear which decoders were used. If either the source was uncompressed or at least DXVA+readback was used for x264 or the source used some format that the GPU can't accelerate it might make some sense as an encoder comparison so far the main conclusions is: A fast GPU can decode H.264 a lot faster than a slow CPU with some random (probably single-threaded) decoder. Not exactly news. And not in any way related to x264.

[roozhou]

Probably due to decoding speed. Unfortunately it is unclear which decoders were used. If either the source was uncompressed or at least DXVA+readback was used for x264 or the source used some format that the GPU can't accelerate it might make some sense as an encoder comparison so far the main conclusions is: A fast GPU can decode H.264 a lot faster than a slow CPU with some random (probably single-threaded) decoder. Not exactly news. And not in any way related to x264.

How can one perform DXVA+readback? Is there any opensource implementation available?

[ajp_anton]

This as well. It's rather disingenuous to pick a last-generation CPU and compare to a current GPU (and then question why the former is slower).He DID pick a last-generation GPU.

And about picking the "worst possible settings", he's trying to match the speeds, not the quality.

However, it doesn't say if x264 was able to use all cores. It says "95% on all 4 cores", was this during the x264 encode? And why only show a picture of the last core? There's a nice picture of the task manager with all 4, separately or combined.
Not to mention what decoder was used (use uncompressed), and why not use the source of the source?

[Reimar]

How can one perform DXVA+readback? Is there any opensource implementation available?

I actually didn't mean to imply it is possibly, I don't know (I know it is possible on Linux with VDPAU), but given that IDirectXVideoDecoderService::CreateVideoDecoder takes IDirect3DSurface9 as render target I'd expect you should be able to read back from those surfaces.
That is DXVA2 only though...

[tph]

Any video encoder comparison needs to use raw video as input, otherwise you're benchmarking decoder performance.

[LoRd_MuldeR]

Any video encoder comparison needs to use raw video as input, otherwise you're benchmarking decoder performance.

Usually the decoder should be orders of magnitude faster than the encoder. So the time for decoding should be negligible.

Reading "raw" data from the HDD may actually become a bottleneck, especially for HD content...

[CruNcher]

as the others already said a lot here is flawed settings wise comparing main vs high then the subme is totally off 0 for x264 is laughable keyint 250 vs 15 is also a good joke ;) also would have been nice if you could add Elemental Technologies Badaboom to the test (Main Profile) :)

@Lord_Mulder
not entirely true especially when you decode more complex streams +higher resolution (Full HD) on Nvidias Hardware Decoder (VP2/VP3) it can be more beneficial speed wise in a encoding chain (especially if you add other GPU effects additionaly as denoising or deinterlacing to it) it heavily depends on your usage scenario Badaboom for example does this quiet good by decoding all the inputs it supports on the VP2 same scenario can be simulated for x264 with Donald Graft his Nvidia API Decoder :)

And it depends on a lot more for example you have a older CPU and want to encode faster now buying a complete new system maybe means to make a complete architecture change (you calculate the costs your budget explodes) now you have a old GFX card inside and decide to buy say a 8800 GT you only need to change the GFX card get future OS gimick support , 3D Games support, Video Encoding and Enhancing including a very powerful Hardware HD Decoder all in one (that is a pretty good deal) not to say all the other CUDA/OpenCL able applications that are still to come :)

you can say what you want but the ION platform shows here what is possible in a very small form factor with this combination putting a i7 quadcore in that case would melt it and every efficiency be wasted ;)

And the extremest case what energy usage is worth you which encoding quality ? (though this one mostly doesn't apply for end consumers as most of the times they don't care about this question)

[LoRd_MuldeR]

If I get you right, you are saying that we can speed-up the decoding part even more by using GPU-accelerated decoders.

So this supports my point that using "raw" (uncompressed) input may not be the best idea.

I'd rather use a fast lossless compressor, such as HuffYUV, for the source instead of uncompressed YUV/RGB data...

[CruNcher]

ah sorry misunderstood you meant decoder in general not CPU Decoding here :) yep you right then of course raw is problematic in terms of IO and the test should be done on separate harddrives (in/out) and best with separate hardware controllers (to lower CPU utilization on a consumer system) or directly from RAM :)

Elemental Technologies developed based on all these requirements their own GPU powered Encoder rack :) http://www.elementaltechnologies.com/products/server
combining all the features of the GPU with the Power of the CPU in a Energy Efficient way (sure not yielding the best quality but for the bitrate target of it a very efficient quality HVS wise with a very good energy output).

[St Devious]

Thank you for you suggestion guys.

As I said in my OP, that there is more to come with different sources at different resolutions.

I'm not trying to advertise anyone here. Just feeding my curiosity to see what kind of encoding does the free CUDA encoder do and probably helping others feeling the same way in the process.

The settings in this encode were used to test the pure speed of x264, to see if it could be as fast as GPU encode at similar or better quality. Since that didn't happen, I will try to match the quality and see what is the difference in performance.

As to the hardware used, this is the best thing I have access to right now. Also as others said GTS 250 is a last generation GPU based on the G92 chip used in 8800GTS 512 MB, 9800GTX, 9800 GTX+.

Also I may use Badaboom and MediaShow Espresso in future if time permits.

Also I plan on using this video

1080p VBR Video Quality Test Streams
Sony HDW-F900 footage, 1080p@25, 18 Mbps average, 30 Mbps peak in a 35 Mbps Transport Stream (259,534,064 bytes)

on this page http://www.w6rz.net/ as one of the sources. Please let me know if there is another uncompressed source you would like me to try.

I'm not too sure about the questions regarding the decoder, I only have ffdshow+haali media splitter installed on my system.
I would really appreciate if you let me know If i need to change something with the decoders.

@ ajp_anton - thanks for pointing that out. I'll put the x264 CPU Usage in the next encode. The image that I put up and 95% on all 4 cores is actually the CPU Usage during the GPU encode. And the image shows the usage of all 4 cores. If you look closely, each one of them is color coded and all of them are in there. It just so happens that they are hidden behind the last one as the usage is about the same on all.

[CruNcher]

you can leave MediaShow Espresso away it will only let Nvidias Encoder look worse as they don't have any idea of what they doing with Nvidias API in their GUI over there @ Cyberlink i have the feeling ;)
Stans Cli Encoder Interface to cuvidenc.dll is currently the most purest way to make usage of Nvidias Encoder API via cuvidenc.dll :) the other do to much insane stuff in their input Logic (most of them are optimized for Mobile Encoding and buggy as hell) for advanced usage ;)
You only need to use GPU Decoding in a x264 chain if you compare vs Badaboom and only if the input is VP2 Decodable in your case Stans encoder is only a interface to Nvidias API so no Decoding going on there :)

Just to make it clear there are only 2 Nvidia Capable Cuda Encoder Cores currently (Nvidia,Elemental Technologies)

Nvidia = cuvidenc.dll coming with Nvidias driver (used by almost all 3rd party Cuda advertised products Mediashow Espresso, Nero MoveIt, Loiloscape, PowerDirector 7, Vreveal HD, Stans Cli Encoder (Mediacoder))

Elemental Technologies = Badaboom (Consumer Main Profile only),Elemental Accelerator (Professional High Profile),Elemental Server (Professional High Profile)

[St Devious]

you can leave MediaShow Espresso away it will only let Nvidias Encoder look worse as they don't have any idea of what they doing with Nvidias API in their GUI over there @ Cyberlink i have the feeling ;)
Stans Encoder is currently the most purest way to make usage of Nvidias Encoder API via cuvidenc.dll :) the other do to much insane stuff in their input Logic (most of them are optimized for Mobile Encoding and buggy as hell) for advanced usage ;)
You only need to use GPU Decoding in a x264 chain if you compare vs Badaboom and only if the input is VP2 Decodable in your case Stans encoder is only a interface to Nvidias API so no Decoding going on there :)

ok, mediashow espresso is out for this round.

So If I use the video I suggested in my previous post, do i need to worry about decoding holding back the encoding ? Do I need to change anything around with the decoders ?

[CruNcher]

Only if you compare vs Badaboom as it will decode the Mpeg-2 on your GPU :) best to avoid any IO differences would be decoding from a Ramdisk and additionally as output for the speed estimation into NUL.

[St Devious]

Only if you compare vs Badaboom as it will decode the Mpeg-2 on your GPU :)

what about x264 vs stan's CUDA H.264 encoder with that mpeg-2 sample ? do i need to change anything ?

[CruNcher]

CABAC on
Subme 3
partitions default
scenecut 1
bframes 2
8x8dct 1

Stans Cli Encoder
-idrp 250

not quiet sure about the partitioning though but none is definitely not reflecting Nvidias Encoder


PS: I practically have the same card as you 8800 GT (G92) but another CPU also Dual Core Athlon XP 64 Toledo :)

i would also add my results here your Core 2 Quad should be a lot more efficient at least in the CPU Encoding part :)

[LoRd_MuldeR]

Just to make this clear:

It's not Stan's H.264 encoder. It's just Stan's interface to NVIDIA's H.264 encoder. The very same encoder we have seen producing crap quality in other applications ;)

Also that "encoder" was removed from the MediaCoder package due to licensing issues. At least that was the case when I last checked...

[CruNcher]

Yes and it's clear that Nvidia didn't like that ;) especialy the 3rd parties hehe ;D

@Lord_Mulder
anyway it was problematic with those 3rd party apps to get on the spot target results either they where crippled or buggy :P

[St Devious]

Just to make this clear:

It's not Stan's H.264 encoder. It's just Stan's interface to NVIDIA's H.264 encoder. The very same encoder we have seen producing crap quality in other applications ;)

Also that "encoder" was removed from the MediaCoder package due to licensing issues. At least that was the case when I last checked...

Alright, let's call it Mediacoder CUDA encoder ?

And it is back in the latest release.

Yes and it's clear that Nvidia didn't like that ;) especialy the 3rd parties hehe ;D

@Lord_Mulder
anyway it was problematic with those 3rd party apps to get on the spot target results either they where crippled or buggy :P

I think Mediacoder has more options to configure the encoder than Badaboom, unless I'm wrong. Don't recall seeing High profile in Badaboom

@CruNcher - sure, I'll add your results too

[CruNcher]

But Badaboom is bad to compare it's a unique core compared to the 3rd party apps and yes the consumer version has yet no High Profile support but there are sightings in the last version of High Profile and AQ support which could come soon :)

Oh its back :) so Stan payed his royalities ;)

[dj_tjerk]

First of all I have to say it's quite useless testing at your decoding/reading/(bitstream writing?) maximum (In your case, 114fps, in my case it was 118 fps). But I can't make nvidia's encoder go any slower too (as in.. give better quality) so it can't be helped.
Secondly, you're probably showing like one of the first frames for the output files, which is nice but doesn't really work for single pass --bitrate encodes. NVidia's encoder is apparantly better at that though.

If you wanna have x264 encode at the max speed too (as was the case on my system here), you might wanna go for sth like --bframes 0 --subme 5 and remove the --no-cabac. That caused no slowdown for me whatsoever in comparison to ultrafast's defaults.

Also, I looked at the output of the file encoded with mediacoder/cuda, and leaving aside that the colors are totally off, it looks a lot like abusing ttempsmooth(). Surfaces are moving nice and steady, but every couple frames almost the entire frame changes.

[stanleyhuang]

I'm not trying to advertise anyone here. Just feeding my curiosity to see what kind of encoding does the free CUDA encoder do and probably helping others feeling the same way in the process.
Hoping some people can free themselves from prejudices.

As to the hardware used, this is the best thing I have access to right now. Also as others said GTS 250 is a last generation GPU based on the G92 chip used in 8800GTS 512 MB, 9800GTX, 9800 GTX+.
What I was thinking is that you are using a more advanced CPU and a less advanced GPU.

BTW: I think you can use MediaCoder to do benchmark for both x264 and CUDA H.264 encoder. This will eliminate the difference in decoding.

[stanleyhuang]

Also that "encoder" was removed from the MediaCoder package due to licensing issues. At least that was the case when I last checked...

The encoder is re-added (since 0.7.1.4470) now after we signed a formal license with nvidia. We are currently working on our own cuda-based video filtering features including down-scaling, de-interlacing, 3D-denoising and pull-up.

[CruNcher]

Stanley does Nvidia provide the API for their Cuda Encoder for free in the CUda 2.2 SDK does the usage of it needs to be licensed (payed) i guess so i mean you virtualy a competitor now to all those 3rd party applications (Cyberlink,Nero,Loilo) that make money from selling this :D

[stanleyhuang]

I am sorry I don't think I can disclose this due to the NDA we signed.

[CruNcher]

Hehe Cyberlink and Co will be pissed if that goes around (though they have the nicer GUI) ;) but anyway Nvidia sells their cards and is happy :D
How you 3rd parties fight against each other is not their thing :D
Yeah sure understand that confidential stuff highly business critical lol ;)

[Manao]

If you wanna have x264 encode at the max speed too (as was the case on my system here), you might wanna go for sth like --bframes 0 --subme 5 and remove the --no-cabac. That caused no slowdown for me whatsoever in comparison to ultrafast's defaults.You'd better keep bframes too. They usually reduce bitrate by 20% at the same quality (cabac is "only" 10%, deblocking is 10% also).

[St Devious]

Hoping some people can free themselves from prejudices.

not sure what you mean. But I know that CPU encoding is where its at, and GPU encoding is still in its infancy and can't compete with x264 in its current form. When I see slides from Nvidia and ATI and review sites that GPU encoding is 5 times faster than CPU encoding and there is no mention of image quality, that makes me kinda angry.

So I'm just trying to provide proof.

What I was thinking is that you are using a more advanced CPU and a less advanced GPU.

Not sure how you would measure that.

BTW: I think you can use MediaCoder to do benchmark for both x264 and CUDA H.264 encoder. This will eliminate the difference in decoding.

That's a good idea but as in business they say, you can't make everyone happy, I fear I would get flamed for that too for trying to advertise mediacoder

[dj_tjerk]

You'd better keep bframes too. They usually reduce bitrate by 20% at the same quality (cabac is "only" 10%, deblocking is 10% also).
Maybe so, but in my case --bframes 1 with --no-cabac and --subme 0 caused it to slow down to about 108 fps (whereas setting --bframes 0 and --subme 5 and removing --no-cabac caused no slowdown whatsoever from my maximum). So I got subme and cabac for "free".

St Devious however chose to set bframes 1 before changing anything else, eventhough with his goal of comparing quality at the same speed (i.e. maximum possible speed), he should've enabled cabac and subpixel refinements, since those would've most likely caused x264 to encode at the same speed as cuda (assuming his system behaves the same as mine does).

[St Devious]

St Devious however chose to set bframes 1 before changing anything else, eventhough with his goal of comparing quality at the same speed (i.e. maximum possible speed), he should've enabled cabac and subpixel refinements, since those would've most likely caused x264 to encode at the same speed as cuda (assuming his system behaves the same as mine does).

I am under the impression that presets override any settings. is that the case ?

[LoRd_MuldeR]

I am under the impression that presets override any settings. is that the case ?

Nope. Presets don't overwrite anything! If a preset is selected, it is applied first. Then all explicit options are applied (and may overwrite what the preset has set).

In other words: Instead of starting from the defaults, we start from the selected preset. But that's all.

Maybe you are thinking of the new "--profile" option (which is applied after the explicit options). That option does overwrite your settings, as it enforces a certain level!

[St Devious]

Presets don't overwrite anything! If a preset is selected, it is applied first. Then all explicit options are applied (and may overwrite what the preset has set).

ok then I will try to set the same option as the preset ultrafast in the MeGUI x264 settings GUI

[stanleyhuang]

not sure what you mean.
I mean the people claiming that you intend to make these benchmarks to advertise something. I hope they can be a bit open-minded.

That's a good idea but as in business they say, you can't make everyone happy, I fear I would get flamed for that too for trying to advertise mediacoder
That's likely. ;-)
So every word should be neutral here.

[St Devious]

I'm comparing now with best quality that each encoder can provide at a certain bitrate.

Using this video

1080p VBR Video Quality Test Streams
Sony HDW-F900 footage, 1080p@25, 18 Mbps average, 30 Mbps peak in a 35 Mbps Transport Stream (259,534,064 bytes)

on this page http://www.w6rz.net/

Encoding both encoders to 4Mbps and 6 Mbps.

Using 2 pass unrestricted HQ profile in Megui, would extra quality provide some better quality ?

And here are the settings for CUDA encoder in Mediacoder. Please let me know what to set to compare to match x264

http://i26.tinypic.com/2gv1vsl.jpg

[stanleyhuang]

The CUDA H.264 encoder in current release doesn't support 2-pass mode yet.

[St Devious]

The CUDA H.264 encoder in current release doesn't support 2-pass mode yet.

i meant used 2 pass unrestricted HQ for x264.

But How can i configure the CUDA encoder to provide maximum quality ?

Here is an update, click on the images to get full size 1920x1080 image

x264 @ 6 Mbps
http://www4.picturepush.com/photo/a/1958117/220/1958117.png (http://www.picturepush.com/public/1958117)

CUDA @ 6 Mbps
http://www4.picturepush.com/photo/a/1958117/220/1958117.png (http://www.picturepush.com/public/1958118)


Source
http://www1.picturepush.com/photo/a/1958119/220/1958119.png (http://www.picturepush.com/public/1958119)

Mediainfo

Source
Video
ID : 49 (0x31)
Menu ID : 1 (0x1)
Format : MPEG Video
Format version : Version 2
Format profile : Main@High
Format settings, Matrix : Default
Duration : 2mn 7s
Bit rate mode : Variable
Bit rate : 32.5 Mbps
Nominal bit rate : 30.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16/9
Frame rate : 25.000 fps
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.628
Stream size : 493 MiB (92%)


x264
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2mn 7s
Bit rate mode : Variable
Bit rate : 6 000 Kbps
Maximum bit rate : 16.6 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16/9
Frame rate mode : Constant
Frame rate : 25.000 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.116
Stream size : 90.9 MiB (100%)
Writing library : x264 core 68 r1179M 96e2229
Encoding settings : cabac=1 / ref=5 / deblock=0:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 /
chroma_qp_offset=-2 / threads=6 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=6000 / ratetol=1.0 /
qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00


CUDA
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2mn 7s
Bit rate mode : Variable
Bit rate : 6 035 Kbps
Maximum bit rate : 42.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 4/3
Frame rate mode : Constant
Frame rate : 25.000 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.116
Stream size : 91.4 MiB (100%)