h264 encoding challenge

[deadrats]

finally we can end this discussion with a conclusion: GPU encoding sux b@ll$.
oh, wait, wasnt it already known? whatever... seriously, let's stick the tests so no more CUDA/GPU fanboys will make ppl waste their time...

2 things:

1) no one is twisting your arm to participate and i am certainly not a "fan boy", more like an A/C man.

2) i fail to see any evidence to support the claim of "gpu encoding sucking balls", i think most of the tests show comparable visual quality across the board.

3) some of the encoding speeds for x264 seem way to high and then i realized a couple of things: a) it seems those participants use intel cpu's and 2) they are all using cli versions of x264.

i'm wondering if this is skewing the results, if either intel cpu's have a superior SSE engine or if the x264cli versions they're using have performance patches and/or very aggressive compilation parameters.

i'd like that info from those that participated and used a cli version: what build is it, where did you get it, how was it compiled (compiler version, options, etc).

if they're using custom builds that certainly skews the results.

[Sharktooth]

1) clogging the forums or even hijaking discussions with your CUDA/GPU encoding very questionable theories is a way to piss me off (if you havent already noticed it, today im not in a good mood...)
2) no evidence? are you still talking? 5 times faster encoding with a 1.8GHz CPU and x264 has still BETTER quality... watch your mounth, coz you're trolling here...
3) there is no other official versions other than CLI and libx264. also x264 is well optimized for AMD cpus.
there are no compilation parameters that influence x264 speed so much since most (if not all) of the relevant code is written in assembly and compiler optimizations will result in less than 2% difference.
now, just accept the fact that you werent able to set up x264 correctly (also, as i said, CLI is the "official" encoding frontend) and GPU encoding sux.

[Didée]

There are no "magic speed tweaks". Most of the speed relevant parts are inline ASM anyway.

Perhaps you're posing the wrong question. Instead of asking "why is CLI encoding with x264 so fast", perhaps you should rather ask "why is x264 encoding so slow in TMpegEnc" ...


2) i fail to see any evidence to support the claim of "gpu encoding sucking balls", i think most of the tests show comparable visual quality across the board.
Might be related to the testing material. I've seen 4mbps rips that look better after encoding, than your source material before encoding ...

Or, perhaps it's just a matter of personal perception. Know this from my wife ... as long as you can tell apart George Clooney from Brad Pitt, the quality is good.

[Motenai Yoda]

only for replying..
with
mencoder.exe %1 -noskip -nosub -lavdopts threads=2:idct=3 -o %1_.mkv -of lavf
-lavfopts format=matroska -forceidx -ovc x264 -oac lavc -lavcopts acodec=ac3:abitrate=192
-vf scale=1280:720 -sws 0 -x264encopts frameref=1:bframes=0:deblock=false:cabac=false:weight_b=false:partitions=none
:8x8dct=false:me=dia:me_range=4:subq=0:trellis=0:aq_mode=0:chroma_me=false
:mixed_refs=false:direct_pred=none:b_adapt=false:b_pyramid=0 -channels 6 -af pan=2:1:0:0:1:-0.866:0.5:-0.5:0.866:0.707:0.707:0:0
1m07s
while with default (mencoder's)
mencoder.exe %1 -lavdopts threads=2:idct=3 -o %1_.mkv
-of lavf -lavfopts format=matroska -ovc x264 -oac lavc
-lavcopts acodec=ac3:abitrate=192 -vf scale=1280:720
1m52s
spec i7-920@stock, 6gb ddr3@1333, hd4650 1gb ddr2

some times ago I've tested mediaexpresso.. it's faster than x264 but with a low quality results... both software and GPU encoding. (ME Gpu 2m55s@24.6drf vs x264 3m50s@20.8drf)

[mariush]

He always fails to see any evidence the love of his life (cuda) sucks. I wouldn't be suprised by now to hear that he's actually color blind.
In addition, in ALL his tests we found much later that he actually used custom settings, different on Cuda and the x264, so it makes his tests pointless. The source material is also trash, a poor benchmarking one.

I could provide you with a test file that would stress both x264 and especially cuda if you want but to be honest, I don't see the point if he's not going to admit that cuda has lower quality for just a bit, if any, speed improvement.

[Sharktooth]

are you kidding too? x264 was able to outperform CUDA encoder speed by 5 times and still produced a better quality... on a 1.8Ghz CPU.

[nm]

only for replying..
with
mencoder.exe %1 -noskip -nosub -lavdopts threads=2:idct=3 -o %1_.mkv -of lavf
-lavfopts format=matroska -forceidx -ovc x264 -oac lavc -lavcopts acodec=ac3:abitrate=192
-vf scale=1280:720 -sws 0 -x264encopts frameref=1:bframes=0:deblock=false:cabac=false:weight_b=false:partitions=none
:8x8dct=false:me=dia:me_range=4:subq=0:trellis=0:aq_mode=0:chroma_me=false
:mixed_refs=false:direct_pred=none:b_adapt=false:b_pyramid=0 -channels 6 -af pan=2:1:0:0:1:-0.866:0.5:-0.5:0.866:0.707:0.707:0:0
1m07s

Decoding speed is a bottleneck here. Try -lavdopts threads=8 and make sure your MEncoder is linked against ffmpeg-mt.

Why are you setting idct=3? Doesn't sound like a good idea to me.

And how about using presets instead of custom settings? MEncoder supports this now: -x264encopts preset=superfast
I wouldn't use ultrafast because it's sometimes worse than nvcuenc.

[Motenai Yoda]

Decoding speed is a bottleneck here. Try -lavdopts threads=8 and make sure your MEncoder is linked against ffmpeg-mt.

Why are you setting idct=3? Doesn't sound like a good idea to me.

my hd is a bottleneck, with high bitrate source, increase decoding threads don't increase speed...
edit:- it's increased a lot (~10fps)
also idct=3 is still IEEE-1180 compliant, which should I use?
(I use this batch for reencode avc fansubs to sap compatible avi, I do not care reach the highest quality)

And how about using presets instead of custom settings? MEncoder supports this now
on the man page isn't reported.

[nm]

my hd is a bottleneck, with high bitrate source, increase decoding threads don't increase speed...

HDD might become a bottleneck for 25 Mbps video at 20x realtime decoding speeds, not 4x.
Are you sure the decoder is ffmpeg-mt? Which MEncoder build are you using?

also idct=3 is still IEEE-1180 compliant, which should I use?

I don't think the idct parameter is even used in the H.264 decoder; only MPEG-4 ASP. Just don't set it at all.

[Sharktooth]

leave the idct alone and use presets. even if it is not documented they're in. also, check if your mencoder is linked against ffmpeg-mt as nm suggested coz i really doubt your HDD is the bottleneck...

[Didée]

are you kidding too? x264 was able to outperform CUDA encoder speed by 5 times and still produced a better quality...
Better don't get hooked to that 5 times number. I cannot imagine THAT, something must've been mixed up. Back when I did some 720p comparisons with Nvidia's vanilla CUDA SDK encoder, I've had x264 (veryfast/superfast, not sure ATM) slightly faster than CUDA: CUDA was 94fps, x264 was 102 fps. That was on an i7-860 with an GT240, read: strong CPU, weak GPU. I'd rather rate them as ~roughly~ the same speed.

[Sharktooth]

probably TMpegEnc uses a different encoder.

[poisondeathray]

Yes, something is weird here.... it should be closer in speed (not 5x faster)

Kolak mentioned something about TMPG's x264 implementation, maybe it's buggered or needs a patch, maybe it's other encoders need fixing too

Thanks for the test results Blue_Misfit, I would like to see your results on TMPG as well - this would provide more information if it's an AMD/Intel issue or if TMPG screwed up that release

Did you use TMPEG 5?

Some quick tests, which I've done show that it's few times slower (for some reason) than x264 in CLI mode (same settings).

[Motenai Yoda]

it's the sherpya's p4-mt build
- audio=copy +ultrafast : decoding threads=8 => 86.18 | decoding threads=4 => 80.26 | decoding threads=2 => 54.93
- audio=copy +medium : decoding threads=8 => 34.99 | decoding threads=4 => 34.82 | decoding threads=2 => 33.99

my hdd's speed on long time sequenzial read/write is ~30MBps
it's a 24.1Mbps = 3MBps so it's shoud go at 10x ≈ 300fps (ignoring fragmentation and access&seek time)

[Blue_MiSfit]

I'll give TMPGEnc more work tonight.

With its CUDA encoder on my GTX 460, at both 2mbps and 4mbps for the second source file, I had total encode times of 1m22s, including the audio, mux etc. That's just piss poor.

I'll try its x264 mode tonight. As for the incredibad performance in this department within TMPGEnc, maybe their libx264 wasn't compiled with asm? :devil:That's one thing that I'd think could cause such a massive slowdown versus plain CLI.

The 5x faster number is pretty damning. Remember though, as I stated on my previous post - this was on my desktop, a 2.4 GHz Intel Core 2 Quad Q6600. Its performance in encoding has been shown to be quite similar to my 1.8 GHz i7 laptop though. The CUDA decode really helps a lot in cases like these.

Derek

[InsulinJunkie]

Is there a working source link (the ones he linked earlier are dead)?

Grabbed the MediaConverter 7 demo (although it had to download several auto-updates to get to the version that had QuickSync enabled), and I'll probably grab the TMPGEnc demo. I don't believe the version of DVRMSToolbox with QuickSync has been released for public consumption yet.

[Blue_MiSfit]

I'll push one up later tonight.

[InsulinJunkie]

I'll push one up later tonight.

Sounds good.

Tried a 5 minute snippet of a 720p OTA recording with MediaConverter to try and get a feel for the settings (and it's sort of limited for Intel QuickSync, which is no surprise given the intended audience).

[aegisofrime]

While everyone is comparing x264,and CUDA, I did a comparison of CUDA and Intel Media SDK.

Quick first impressions was that Intel Media SDK looked much better than CUDA at the same bitrate, however it was much slower. However that is mostly probably because I don't have a Sandy Bridge CPU. Does anyone know if the output would be the same, if it was done with a AMD CPU and a Sandy Bridge CPU?

Also, I was pleasantly surprised that TMPGEnc Mastering Works supports avisynth input. If I were to get a Sandy Bridge CPU that might replace some of my current workflows :)

[InsulinJunkie]

While everyone is comparing x264,and CUDA, I did a comparison of CUDA and Intel Media SDK.

Quick first impressions was that Intel Media SDK looked much better than CUDA at the same bitrate, however it was much slower.

I haven't gotten around to putting my GT 240 back in (using the IGP of the 2500K at the moment), but I was impressed with my quick test of QuickSync, considering my low expectations.

Took the first five minutes of DETROIT 1-8-7 (OTA recording, 720p60, MPEG2 video bitrate of ~16.3), saved it as an MPEG, and threw it at Media Converter. Not a lot of customising is possible (can't set a bitrate, just a constant quant, but it doesn't seem to matter what you enter anyways) - it spit out a file with a video bitrate of ~5 in 1:45, which works out to about 172fps.

Will do more thorough testing later (tomorrow or later in the week), but did feed the MPEG straight to r1884 x64 with --preset fast --tune film --crf 20, since I usually encode HD with CRF 20 or 21 and wanted to get a rough ballpark idea of the bitrate for comparison with QuickSync, and got a bitrate of 5785 and 46.87fps. --preset medium, bitrate of 5025 and 40.03 fps.

For watch-once transcodes (with really low power consumption), QuickSync doesn't seem so bad.

[woah!]

for me using my weapons of choice, i get a muxed mkv file after 1min 44secs using the x264 profile of medium. i would like to see the cuda result in the first post to compare but its not there any more.
i can post the file if needed, heres a screen shot of the encode window with stopwatch.

http://i.imgur.com/pqkOe.jpg

[Blue_MiSfit]

Here's the second porn source that deadrats provided:

http://www.mediafire.com/?cp36l1x51varm24

Disclaimer: there's some upper frontal female nudity here, so if you're offended by that sort of thing... well... don't download it :)

Now, on to comparison between TMPGEnc 5's built in x264, and x264 cli.

A few things
1) The TMPGenc version doesn't support one pass VBR, which is probably just as well. It does support one pass CBR, so that's what we'll test here

2) It's tough to know which options in the TMPGEnc GUI map to the x264 cli arcuments. Since we're going for max possible speed here, I tried my best to match x264 cli's --preset ultrafast

1280x720p29.97, BP@L4, 1:1 PAR, single pass CBR, 4mbps avg/max bitrate, automatic buffer size, CAVLC, "fastest" performance preset", GOP limited to 30 frames, 1 ref, 0 b-frames (auto-set by baseline profile), no scene change detection

These settings made an output in 1m 23s.

TMPGEnc reports that the CPU was used for 72.6% of the work, and CUDA was used for 27.4% of the work, likely for decode and scaling, IMO. During the encode, I saw about 60% CPU utilization.Disabling CUDA brought CPU usage up to an average of maybe 70%, but total encode time increased to 1m27s.

For reference, x264 cli set to CBR mode and ultrafast settings was able to push 111fps with roughly the same CPU utilization.

So then, TMPGEnc spent (let's subtract 23 seconds for the audio transcode and mux) about one minute on the encode. That means it ran at about 25fps.

25fps vs 111fps..... same CPU usage.....I think somebody either totally broke something, or compiled libx264 without ASM... yikes.

Derek

[woah!]

i'll suffer tho it... i do this for the good of this forum...

[InsulinJunkie]

I figured out MediaConverter a bit more - if you choose a resolution it allows you to set the bitrate.

Resizing to 1280x720, bitrate of 4 (actually came out ~3715), converting to MP3 (it doesn't seem to let you keep the audio as-is), and spitting out a MKV took 9 seconds. 1496 frames, so ~166 fps using QuickSync on a 2500K.

QuickSync test: http://www.mediafire.com/?nln6tb4dxcdt52r

[woah!]

ok with new source:

DG ultrafast = 110.56 fps
DG superfast = 110.43 fps
DG veryfast = 93.78 fps
DG faster = 71.13 fps
DG fast = 44.41 fps
DG medium = 42.80 fps

heres the Screens.

http://i.imgur.com/T5kro.jpg

http://i.imgur.com/JJ3p7.jpg

[woah!]

I figured out MediaConverter a bit more - if you choose a resolution it allows you to set the bitrate.

Resizing to 1280x720, bitrate of 4 (actually came out ~3715), converting to MP3 (it doesn't seem to let you keep the audio as-is), and spitting out a MKV took 9 seconds. 1496 frames, so ~166 fps using QuickSync on a 2500K.

QuickSync test: http://www.mediafire.com/?nln6tb4dxcdt52r

interesting, now i want to see what it can output with good film source from a bluray. that result isnt terrible for the speed.

[GodofaGap]

@Blue_Misfit:

Without wanting to go into details, deadrats is indeed suspended?

[7ekno]

2) i fail to see any evidence to support the claim of "gpu encoding sucking balls", i think most of the tests show comparable visual quality across the board.


Seriously?!? You can't see "the blocks dancing" in the fades?!? You can't see the "blocks dancing" on flat backgrounds?!?

Yikes,
7ek

[kolak]

So then, TMPGEnc spent (let's subtract 23 seconds for the audio transcode and mux) about one minute on the encode. That means it ran at about 25fps.

25fps vs 111fps..... same CPU usage.....I think somebody either totally broke something, or compiled libx264 without ASM... yikes.

Derek

Yes- about 4x slower. Something is wrong with TMPEG 5.


Andrew

[InsulinJunkie]

Yes- about 4x slower. Something is wrong with TMPEG 5.

When I tried TMPGEnc after running MediaConverter 7, it was much slower than MediaConverter 7 even using hardware (Intel QuickSync) - about 35 seconds to MediaConverter's 9 seconds.

[aegisofrime]

Hmmm if everything is slower on TMPGEnc 5, could it be a trialware limitation perhaps? Just guessing.

Interestingly, when I encode with Intel Media SDK on my Phenom rig it says that it's using CUDA, despite me not having any filters on. Hmmm...

[nm]

Interestingly, when I encode with Intel Media SDK on my Phenom rig it says that it's using CUDA, despite me not having any filters on. Hmmm...

Maybe it's using nvcuvid for hardware decoding.

[LoRd_MuldeR]

Hmmm if everything is slower on TMPGEnc 5, could it be a trialware limitation perhaps? Just guessing.

With a trial version you usually want to convince your potential customers to buy the full version. You don't want to scare them away :p

[aegisofrime]

With a trial version you usually want to convince your potential customers to buy the full version. You don't want to scare them away :p

Sometimes companies do the darnest things. It's one explanation I can think of for both TMPGEnc Quick Sync and x264 being slower than other implementations though.

Maybe it's using nvcuvid for hardware decoding.

I think I will give it a shot with a format that I know Purevideo doesn't support...

[Blue_MiSfit]

Could be the scaling. Anyone try feeding TMPGEnc an AviSynth script, pre-scaled?

Derek

[kolak]

My test was pure encode- no processing at all.
There is something wrong with TMPEG 5.

Andrew

[InsulinJunkie]

Just feeding both the 5-minute MPEG snippet of a 720p60 OTA recording, using QuickSync hardware transcoding to CBR 5000, it was much closer for the video transcode/audio encode/mux.

1:42 for Media Converter 7 trial
2:40 for TMPEG 5 trial.

[CruNcher]

Hi its not the best evaluation but its the only one that has samples available for all the top tier ISV Encoding applications (Cyberlink,Arcsoft,Elemental) and modes (including originals), please be aware that all the Applications use different Frameworks and for some GPU stuff own Encoder are used (especially you have to look out for Arcsoft GPU results they use their own Encoder Core (APP/CUDA) like Badaboom does for CUDA as well and their APP Encoder is currently totally borked (also their CUDA Encoder is not really working perfect they use a modified X264 with GPU support though it fails fast on high quantizers creating strange effects), so the ATI results inside MediaConverter 7 are currently the worst quality wise, seems to be a very early in Dev APP Encoder, that they always release such Alpha stuff out of their Labs into their Applications that get sold really surprises me).
QuickSync results are consistent throughout all ISV Applications (no surprise here).
Cyberlink uses the Default supplied Nvidia Encoder (inside the driver) but not the best tweaking for the profiles, and a at least stable APP Encoder compared to Arcsofts.
Elementals Badaboom 2.0 Alpha uses their own Cuda Encoder as well like Arcsoft and Mainconcept do it, its a more recent code version from their Professional Elemental Encoder line (Blue_MiSfit has some insights on it out of real life experience), so much better results then the old consumer Core we have plenty results of here on Doom9 from it.

http://www.tomshardware.com/reviews/video-transcoding-amd-app-nvidia-cuda-intel-quicksync,2839.html

Quick Sync shows that it has a much more efficient Motion Search where Nvidias Diamond search is often failing in more complex scenes Intels Quick Sync survives it but also Badaboom 2.0 Alpha has a better Motion Search for CUDA then Nvidias own Nvcuvenc now, but stability wise it's not up to Quick Sync, it comes close though imho :)

This is no scientific compare in any way, but we can surely say that at least Quick Sync has better Quality then Nvidias Nvcuvenc @ faster speeds, my own compare also with a well Enhanced Cuda Framework is still in the making :)

Also be careful not every sample from the THG test is usable or comparable as the ISV application use sometimes very strange profile settings for Devices and some samples are Baseline some are Main different levels it's a total mess to interpret ;)

Though comparing the samples between each ISV application is not really a good way either as the Frameworks (especially scaling in this case) can be completely different so the THG test is more a comparison between Frameworks and final results (of the individual ISV applications) then a Encoder Compare :)

So just from looking @ this even with all quirks i would say that

1st place = Quick Sync (not important in which Application all are Media SDK 2.0 based, though restricted to Vista/7 DXVA2, also output restrictions and currently chipset restrictions apply not very nice the whole environment it operates in currently)
2nd place = Badabom 2.0 Alpha CUDA/Nvidia CUDA (WinXP,Vista/7)
3rd place = Arcsoft CUDA (WinXP,Vista/7) (x264 core based, with some bugs @ high quantizers)
4th place = Cyberlink APP (WinXP,Vista/7) (quality is visually worse, needs quality improvements)
5th place = Arcsoft APP (WinXP,Vista/7) (a visual mess that needs heavy work, lots of bugs)

though a well tweaked x264 will beat all of them quality and most probably speed wise on Sandy Bridge especially using GPU Decoding via Intels IGP, so we just need DGMXFdec now, though would be Vista/7 only then ;)

This also shows that AMDs APP Encoder are not up yet to compete with either Intel, Nvidia, Elemental or Mainconcept (Quality comparable to Nvidias Encoder) all available AMD APP implementations tested are weak in comparison (Visual Quality lacks, have severe bugs, no surprising result either (except Arcsofts own APP Encoder results) seeing all the Doom9 tests done with AMDs GPU Encoder in the past and those results, also AMDs own H.264 Software Research isn't very advanced see MSU tests compared to Intel).

Also i would like to quote and comment something from the THG test


Another person concurred, saying, "give them time and they will get quality down." Both individuals have a fair point. Indeed, Sam Blackman, Elemental's CEO, is insistent that hardware-accelerated encoders will be just as good as their CPU counterparts given time. He further stated, "if you look at where we were with Badaboom two years ago versus where we are now, the amount of progress is so significant that its pretty clear that the trajectory of GPGPU encoders is one that is going to surpass CPU only in the very near future, if it hasn't already."

We will see improvements though till GPGPU Encoders reach X264 quality we most probably will be deep into X265/VP9 already ;)
And @ that time we gonna see if all the done research can be easily applied and taken on to the same level for GPGPU (or if H.265/VP9 will be even designed partly for it) if that happens we can say it makes no sense anymore to continue the CPU Software part if consumers could have this quality then available @ roughly the same timeframe in GPU Hardware inside the CPU :)
And yes it's exciting to see how that Develops in the Future :)

[dansus]

Are there any interesting projects that use Quick Sync yet? (apart from the usual big name brands which are typically useless)

Oh and Badaboom is now at 2.0 and Quick Sync enabled.

[aegisofrime]

Yes I just downloaded Badaboom 2.0.

My main beef with Badaboom 1.x, which I see they have not fixed in 2.0, is the lack of a "as source" resolution setting. I mean, in the immortal words of Jeremy Clarkson, how hard can it be?

In any case, stupidity aside I will be grabbing a few lossless clips and giving it a whirl.

However, so far I'm really giving the edge to TMPGEnc Mastering Works 5, because it supports Avisynth input and it's not "idiot-proofed" like Badaboom, trying to hold my hand by restricting the options that I have.

[dansus]

If someone with Quick Sync like to do a comparison of available tools, that would be useful.

[pascalwil]

What is --no-interlaced for?
Is it for Progressive?
If so is --interlaced correct for Interlaced?

Thanks

[sneaker_ger]

"--no-interlaced" is indeed for forcing progressive in case x264 misidentifies the content.
Use "--tff" or "--bff" for interlaced. (top field first/bottom field first)

[pwnsweet]

However, so far I'm really giving the edge to TMPGEnc Mastering Works 5, because it supports Avisynth input and it's not "idiot-proofed" like Badaboom, trying to hold my hand by restricting the options that I have.

Have you by any chance managed to get b-pyramids working in TMPGEnc Video Mastering Works 5? All the encoding tests I've performed in TMPGEnc have b-pyramid=0...

[ilovejedd]

Do we have PQ comparisons or even screenshots of 1080p videos encoded with Quick Sync and with x264? My search-fu is failing me...

[benwaggoner]

1st place = Quick Sync (not important in which Application all are Media SDK 2.0 based, though restricted to Vista/7 DXVA2, also output restrictions and currently chipset restrictions apply not very nice the whole environment it operates in currently)
2nd place = Badabom 2.0 Alpha CUDA/Nvidia CUDA (WinXP,Vista/7)
3rd place = Arcsoft CUDA (WinXP,Vista/7) (x264 core based, with some bugs @ high quantizers)
4th place = Cyberlink APP (WinXP,Vista/7) (quality is visually worse, needs quality improvements)
5th place = Arcsoft APP (WinXP,Vista/7) (a visual mess that needs heavy work, lots of bugs)
Have you looked at Main Concept's CUDA implementation yet? Any idea where it would rank? It's implemented in Expression Encoder 4 SP1. That drop was fast but definitely had lower compression efficiency compared to a dialed-up pure software encode. Main Concept CUDA doesn't do adaptive or reference B-frames, among other limitations. But they're working hard to improve it.

I'm personally still agnostic as to how useful a GPU codec implementation would be. The low-hanging fruit for GPU acceleration of compression is definitely in source decode and preprocessing. A TDeint+EDI implementation on GPU would probably be easier than doing a full codec, show a bigger performance gain, and not have any quality regressions. GPU is great for "embarassingly parallel" but an actual video encoder has a whole lot of dependiences on what's happening in past frames and other parts of the current frame.

There's been some interesting talk about using the GPU for an initial coarse motion estimation, and then using the CPU to do the actual refinement. This would be particularly useful in multibitrate encoding where 10 different encoder instances may be running at once, and so only doing motion estimation between areas already flagged as having matching could save a lot in CPU time and by loading fewer pixels into the memory cache per instance.

In the VC-1 Smooth Streaming encoder, we saved a bunch of encoding time by only needing a single encoder instance for the first pass, which could be used by an arbitrary number of second passe bitstreams at different bitrates and frame sizes. That's something that could probably be done entirely in GPU.

[CruNcher]

Yes i have and it's not up to Nvidias own reference yet (not in the rank would be between 1-2) which really shouldn't be a surprise @ all, though inside their labs they should have by now a much better version according to their last released roadmap ;)

[aegisofrime]

though inside their labs they should have by now a much better version according to their last released roadmap ;)

Sounds interesting. I haven't read anything like that, will it be implemented in Avisynth?