DGAVCDecNV 1.0.13: GPU decoding on Nvidia

[Guest]

@Snake91

We're testing encoding using x264 via DGAVCDecodeNV. What is your point?

Anyway, there is no decoding done when saving a project.

[Snake91]

Ok, I will try very soon a CRF encode to try the improvement

[Guest]

Thank you for your testing.

[Guest]

I ran a quick test with a CRF encode of 1280x720 material.

E8500 @ 3.8 GHz

NV GPU: 27.9 fps

CoreAVC via DSS: 28.4

Apparently CoreAVC is so good that its CPU utilization is comparable to the overhead of managing decoding on the GPU (memory transfers host<->device, etc.). It's hard to believe, so I'll look to see if I've missed something.

I'm beginning to think this is a dead end, since things can only get better on the CPU versus the GPUs, which are "cast in silicon".

Maybe I'll update the regular versions with the latest libavcodec code while we wait for a CoreAVC API/SDK.

[Sagekilla]

I do have some good news in regards to the deinterlacing of vp2.

The following image was deinterlaced using a simple TempGaussMC():
http://img522.imageshack.us/img522/7932/tempgaussmcdeintym5.jpg

The following with the VP2 Deint:
http://img143.imageshack.us/img143/214/vp2deintkg1.jpg


I used very naive settings of the default, just to play the role of a new user who doesn't know better. The deinterlacer is very very sharp.

[Guest]

Maybe that's the saving grace! :)

Nice shots, thanks for posting.

BTW, I noticed with CoreAVC via DSS(), it blend deinterlaced, even though I have deinterlacing turned off in its control panel. It also included my clip 4 times in the output! I haven't used CoreAVC much but I was somewhat surprised. Any idea what is going on?

[Turtleggjp]

To be honest, I think that the decoding on the GPU is a neat idea, but in the end should be an option for those with the right hardware who want to try squeezing a little more speed out of their encodes. I'm concerned though that eventually the limitations of DXVA on these cards may begin to hinder this great program's ability to work. I agree that the PAFF accuracy is nice (haven't gotten to try it myself yet though) but I know how difficult it can be sometimes to make hardware based tasks like this work consistently. The thought of only one instance at a time is scarry too, as I sometimes do more than one encode at once, or may in the future be reading from more than one source at once (doing a fade between two of my camera's clips comes to mind).

Bottom Line: I feel that hardware acceleration is better for realtime critical applications (playback). However for applications like transcoding, a pure software solution is better, since speed is nice, but not critical, and it can grow as needed without being as you say "cast it silicon."

edit: That de-interlaced footage does look nice! Does it change the fps to 60 like DGbob does? (assuming of course the source was 30i).

[Guest]

I already said several times that I'm not dropping the pure SW solution.

And nobody said the single instance version is anything more than a test version for encoding speeds.

Why are you raising these bogeymen???

[Sagekilla]

Yes, indeed.. I'll need to test on a longer interlaced source to see how well a "good" deinterlacer will fare vs AVCSource(deinterlace=true) speed wise. By "good" I mean to say one that would produce very similar results without being horribly slow At the very least, we have quite possibly a fast and high quality decoder + deinterlacer for those annoying 30i sources.


Edit: I forget where I got the source now, but it was thanks to some searching on the doom9 forums for an interlaced H.264 m2ts source did I find it.
Edit 2: neuron2, is it safe to assume you used DSS() using graphedit to connect CoreAVC as the decoder?

[Turtleggjp]

I already said several times that I'm not dropping the pure SW solution.

And nobody said the single instance version is anything more than a test version for encoding speeds.

Why are you raising these bogeymen???

Sorry, I was just trying to give my opinions. I wasn't trying to beg you to keep the pure SW solutions.

[squid_80]

I ran a quick test with a CRF encode of 1280x720 material.

E8500 @ 3.8 GHz

NV GPU: 27.9 fps

CoreAVC via DSS: 28.4
You could try it with a single core - you might be pleasantly surprised. (Windows can be limited to a specific number of cores by using the /numproc=X switch in c:\boot.ini.)
BTW, I noticed with CoreAVC via DSS(), it blend deinterlaced, even though I have deinterlacing turned off in its control panel. It also included my clip 4 times in the output! I haven't used CoreAVC much but I was somewhat surprised. Any idea what is going on? The clip looping 4 times I would dismiss as a directshowsource side-effect, but the deinterlacing is a mystery - coreavc can't do blending (the "Blend" option shows one field and discards the other, which is why it was renamed "Single Field" in 1.8.0).

[Guest]

Edit 2: neuron2, is it safe to assume you used DSS() using graphedit to connect CoreAVC as the decoder? I just made a script with DirectShowSource("file.264"). Is that wrong?

[Sagekilla]

@squid_80: For the single core users who happen to have a very fast GPU, this is indeed very useful.

On another note, while this is an extremely unusual case, I'm curious how much speed up I can afford on two machine setup with TCPServer --> TCPSource.

@neuron2: I'm not completely sure. My normal routine is Directshowsource("graph.grf") with graph.grf being a filter graph of source file --> CoreAVC. I don't know if doing it your way could produce different results.

[Audionut]

I just ran a quick test on my e6750 @ 3.6Ghz and 8800gt 512m.

BD source croped and resized to 1280,528

In virtualdubmod encoding to huffyuv with software = 21fps
same with hardware = 34-42fps

encoding to x264 ("turbo" settings) with software decoder = 21 fps
same with hardware = 29 fps.

And i've seen the purevideo de-interlacer at work, I like it alot.

Sorry, it's not alot more detailed, but it's been a big day and I should be sleeping.

edit: neuron, did i read correctly, you are using 8600 gpu?
I'd like to see some tests from someone with a 9800gtx*2 or 280 core even in sli.

[CruNcher]

Nice Deinterlacing results though i wouldn't have suspected that it beats something as advanced as TempgaussMC last time my visual subjective impression was it was on the same level then yadif, definitely more tests with different sources need to be done :)
Im gonna test DgdecodeNV as fast as i can though currently PC resources are not available :(

@Audionut
As Donald already said it's equal for every Nvidia card they are all clocked with 400 mhz (VP1/2 core) <- (No Software yet can change that no Software even knows that this Clock is existing, it was revealed here almost as a Worlds First exclusive, not really that suprising its a own Hardware core though nobody knew how high it's clocked) so the only difference is the Memory Bandwith and most probably stuff like the Deinterlaceing could be a big amount faster as here the Shader Clock i think plays a role :) else for Progressive it should be really steady for us all and the results posted here show that it indeed is :)

[Turtleggjp]

Yeah, the graph option is better, since you can build the graph yourself and guarantee what decoder is being used. I always use either a .m2ts file or .mkv file as my source, and then run that to the desired decoder (CoreAVC for AVC, WMV Decoder DMO for VC-1). Seeking can be unstable with this method though, which is why your DGAVCIndex/DGAVCDecode program is so valuable. :)

[Inventive Software]

A direct comparison between this (DGAVCDecodeNV) and the software DGAVCDecode (currently Alpha 35 IIRC) would be most welcome, as I don't have an NVIDIA-capable GPU to test this with (ATI Xpress 1150 or NVIDIA GeForce FX5200 :(). Same settings, same encoder, please. :)

[Comatose]

neuron2: If you get the latest CoreAVC, then it has a tray icon when it's loaded like ffdshow.

And wow, the deinterlacer is really nice. I might have to trade cards with my brother so I get a 9600GT (got a 8800GTS 320MB now).

[rack04]

A direct comparison between this (DGAVCDecodeNV) and the software DGAVCDecode (currently Alpha 35 IIRC) would be most welcome, as I don't have an NVIDIA-capable GPU to test this with (ATI Xpress 1150 or NVIDIA GeForce FX5200 :(). Same settings, same encoder, please. :)

As soon as I get off work I'll compare these using the following settings.

DGAVCDecode

LoadPlugin("[PATH\]DGAVCDecode.dll")
AVCSource("[PATH\]Transporter_DGAVCDecode.dga")
Spline36Resize(1280,544)

"[PATH\]x264.exe" --crf 18 --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --b-pyramid --b-rdo --bime --weightb --filter -1:-1 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "[PATH\]Transporter_DGAVCDecode.mp4" "[PATH\]Transporter_DGAVCDecode.avs"

DGAVCDecodeNV

LoadPlugin("[PATH\]DGAVCDecodeNV.dll")
AVCSource("[PATH\]Transporter_DGAVCDecodeNV.dga")
Spline36Resize(1280,544)

"[PATH\]x264.exe" --crf 18 --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --b-pyramid --b-rdo --bime --weightb --filter -1:-1 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "[PATH\]Transporter_DGAVCDecodeNV.mp4" "[PATH\]Transporter_DGAVCDecodeNV.avs"

Directshow

DirectShowSource("[PATH\]Transporter.mp4",fps=25,audio=false)
Spline36Resize(1280,544)

"[PATH\]x264.exe" --crf 18 --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --b-pyramid --b-rdo --bime --weightb --filter -1:-1 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "[PATH\]Transporter_Directshow.mp4" "[PATH\]Transporter_Directshow.avs"

[crypto]

Ok, here are my results dgavcdecode vs. dgavcdecodeNV:

First good news: Using x264 cli two pass encodings are no problem.
Second good news: Acceleration is massive especially on the first pass.
Third good news: The quality of the final encode seems to be higher. I don't know why and have to do more tests.

Source: 1080p30 Apple music clip downscaled to 720p30
CPU: Q6600 2.4GHz
GPU: GF 8600 GTS 1.450 GHz

dgavcdecode:
pass #1: encoded 6580 frames, 32.68 fps, 4811.95 kb/s
pass #2: encoded 6580 frames, 21.48 fps, 5005.68 kb/s
x264 [info]: SSIM Mean Y:0.9689052
x264 [info]: PSNR Mean Y:41.892 U:48.994 V:48.284 Avg:43.078 Global:42.345 kb/s:5005.53


dgavcdecodeNV:
pass #1: encoded 6580 frames, 57.11 fps, 4811.95 kb/s
pass #2: encoded 6580 frames, 24.45 fps, 5005.42 kb/s
x264 [info]: SSIM Mean Y:0.9691189
x264 [info]: PSNR Mean Y:41.931 U:49.607 V:49.447 Avg:43.258 Global:42.404 kb/s:5005.27

[nm]

Third good news: The quality of the final encode seems to be higher. I don't know why and have to do more tests.
Perhaps there is some hardware postprocessing going on even when the video is not deinterlaced. Denoising might cause such a difference, for example. You could do some lossless encodes with both hardware and software decoding and compare the output frame-by-frame.

[CruNcher]

Ahh right crypto you should make sure your settings in the Control Panel dont include Nvidias Denoiseing or Sharpening Post Pro (Shaders) crazy maybe it can applied this way too :D

[Diodato]

A quick test of the Nvidia deinterlacing capabilities. I'm impressed.

The source is a crapy Main@L4.0 ~7.5Mb/s 25fps
(Beijing Olimpics 2008 Opening Ceremony 1080i CCTV.ts)

http://rapidshare.com/files/146436434/NVdeinterlace.zip.html

All Nvidia processings are turned off (edge=off, noise=off).

[blubberbirne]

I don't get the decoder to work :(

Using Vista SP1 64bit here.

LoadPlugin: unable to load "DGAVCDecodeNV.dll"

The DLL is in the same directory with the avs script.

[Guest]

Do you have CUDA drivers installed? Do you have an Nvidia card? Which one? Did you put nvcuvid.dll in System32?

[Guest]

Ahh right crypto you should make sure your settings in the Control Panel dont include Nvidias Denoiseing or Sharpening Post Pro (Shaders) crazy maybe it can applied this way too :D Umm, what is this control panel you're all talking about?

[Ranguvar]

NVIDIA driver control panel.

[rack04]

Don't really know how to translate the results but here goes:

Q6600
8800GT

DGAVCDecode
http://i11.photobucket.com/albums/a199/rack04/CRF_DGAVCDecode.jpg

DGAVCDecodeNV
http://i11.photobucket.com/albums/a199/rack04/CRF_DGAVCDecodeNV.jpg

Directshow
http://i11.photobucket.com/albums/a199/rack04/CRF_Directshow.jpg

[JK1974]

Sorry for getting off-topic in-between the lines - between all this discussion on deinterlacing - I will come back to this point later on. ;)

I also checked DGAVCIndexNV on two XP SP3 machines with GeForce 8600 GT, and it is really fantastic. No more artifacts on my AVCHD recordings of my Canon HF100 (which I had with DGAVCIndex before).

When trying to install it on the second machine, the plug-in did not load. I installed the latest drivers 177.92 (which seems to be beta; from the "the force within" promotion section of the site), tried it with the "special" cuda drivers, installed the toolkit, nothing worked until I checked again with Sysinternals Processmon. It was finally the nvcuvid.dll which was missing in the system32 directory - after installing this I could even remove the cuda toolkit and reinstall the latest (beta) drivers.

I still have some remarks on the tool itself:
- When doing a SeparateFields(), BFF seems to be used although even DGAVCIndexNV itself says that it is TFF. Currently, I would have to set an AssumeTFF() before in any script handling with the fields.
- I think it has not really clearly been said: TempGaussMC is a bobber which makes an 1080i50 being a 1080p50 while the NVIDIA deinterlacer just outputs 1080p25. This might be interesting for Blu-ray ripping but when it is about scaling while preserving the fields e.g. for an AVCHD-to-DVD conversion, this deinterlacing is useless IMHO - or did I miss something?
- One little request: Could you please add the extension "mts" to the list of ts-streams in DGAVCIndexNV? It´s the extension used by Canon AVCHD-Cams. ;)

[Guest]

I also checked DGAVCIndexNV on two XP SP3 machines with GeForce 8600 GT, and it is really fantastic. No more artifacts on my AVCHD recordings of my Canon HF100 (which I had with DGAVCIndex before). Yes, it solves the problem of broken libavcodec.dll.

When trying to install it on the second machine, the plug-in did not load. I installed the latest drivers 177.92 (which seems to be beta; from the "the force within" promotion section of the site), tried it with the "special" cuda drivers, installed the toolkit, nothing worked until I checked again with Sysinternals Processmon. It was finally the nvcuvid.dll which was missing in the system32 directory - after installing this I could even remove the cuda toolkit and reinstall the latest (beta) drivers. Good to know. Thanks for reporting your experiences.

I still have some remarks on the tool itself:
- When doing a SeparateFields(), BFF seems to be used although even DGAVCIndexNV itself says that it is TFF. Currently, I would have to set an AssumeTFF() before in any script handling with the fields. SeparateFields() separates based on the parity of the clip. DGAVCDecode and DGAVCDecodeNV currently blindly set parity to BFF, because I haven't done the code to determine it and set it yet; it's been on my to-do list for a long time. Since most h264 streams are TFF, I will change it to set TFF, atleast until I get time to do it properly. It involves some parsing of PIC timing SEIs when field or frame repeats are present and other things.

- I think it has not really clearly been said: TempGaussMC is a bobber which makes an 1080i50 being a 1080p50 while the NVIDIA deinterlacer just outputs 1080p25. This might be interesting for Blu-ray ripping but when it is about scaling while preserving the fields e.g. for an AVCHD-to-DVD conversion, this deinterlacing is useless IMHO - or did I miss something? You can't make a DVD at double rate, it has to be 29.97 for NTSC, so your point is kind of moot. But anyway, there are a lot of applications of single-rate deinterlacing. Why do you think single-rate deinterlacers exist? :)

- One little request: Could you please add the extension "mts" to the list of ts-streams in DGAVCIndexNV? It´s the extension used by Canon AVCHD-Cams. I think I can probably manage that.

[Sagekilla]

As a note to everything, please remember that my deinterlacer comparison was very naive, I never changed the TempGaussMC settings so it could theoretically do better.

[lexor]

Don't really know how to translate the results but here goes:

Q6600
8800GT


to me it says one of two things:

1) If AVS is something more than "open file", then avs is a bottleneck negating advantages of hardware decoding

2) If AVS just contains an "open file" statement, then CPU cycles freed up by hardware decoding of source are inconsequential

Either way, at least we get greater stream compatibility (with paff and such). Still too bad we don't get encoding speed boost.

[rack04]

to me it says one of two things:

1) If AVS is something more than "open file", then avs is a bottleneck negating advantages of hardware decoding

2) If AVS just contains an "open file" statement, then CPU cycles freed up by hardware decoding of source are inconsequential

Either way, at least we get greater stream compatibility (with paff and such). Still too bad we don't get encoding speed boost.

So are you saying that they results are skewed because I resized in the avs?

[Sagekilla]

I suppose when it comes to using faster settings, the GPU decoding definitely comes out on top. I'm curious how this would benefit a Core 2 Quad overclocked to 3.2 GHz :) Those would be -really- starved for data between my decoding Blu-ray, filtering, and encoding.

[Sulik]

Unless decode is the bottleneck (ie encode runs at 50+fps) and/or CPU is pegged at 100%, the speed boost for having even infinitely fast decoding would be small. As the numbers from rack04 show, a ~10fps encode gets a 2-5% speed boost.

[Sagekilla]

As I said, I'm curious what the results would be on a workhorse like I just described :) I plan on upgrading to such a system in the near future so this will be helpful having one thing offloaded from my chain.

Also, the encode doesn't need to run at "50+ fps" for it to be a bottleneck. The decode eats up a significant portion of my cpu time on my desktop computer, where I have a lowly Opteron 170.

[JK1974]

You can't make a DVD at double rate, it has to be 29.97 for NTSC, so your point is kind of moot. But anyway, there are a lot of applications of single-rate deinterlacing. Why do you think single-rate deinterlacers exist? :)


:)
I thought that the deinterlacers are just for all those TV-to-DivX encoders that don´t care about fluid movements.
Concerning the DVD at double rate:
For creating high-quality downconversions of the HD material to SD material, the HD material has first to be bobbed to 1080p50 at best quality (this takes huge time with TempGaussMC). Just then, you can scale it down at high quality. The resulting 576p50 has then to be weaved to 576i50.
Any possibility to bob it to 1080p50 at a comparable quality like the deinterlacer would also be a great improvement for a lot of users - at least at PAL land ;)

[Sagekilla]

@JK1974: There was a thread on this before. Yes, bobbing with a very high quality bobber like TGMC would produce the best results in both 1080p and 576p, but the reality was that there was VERY little difference between a dumb bob and smart bob when downsizing to 576p.

[JK1974]

@JK1974: There was a thread on this before. Yes, bobbing with a very high quality bobber like TGMC would produce the best results in both 1080p and 576p, but the reality was that there was VERY little difference between a dumb bob and smart bob when downsizing to 576p.

Thanks a lot for your clarification - don´t have the time to check the forum daily, so I must have missed it. With dumb bob you mean a simple SeparateFields()? Going to check if I find this thread...

[blubberbirne]

Do you have CUDA drivers installed? Do you have an Nvidia card? Which one? Did you put nvcuvid.dll in System32?

Yes, i have 177.84 installed, and also the Cuda SDK. My Card is a GTX260. And i also put the nvcuvid.dll in the System32 Folder.

[qyqgpower]

@blubberbirne
you are running vista 64bit, so may be the nvcuvid.dll(is it a 32bit runtime?) should be in the SysWoW64 folder

[roozhou]

Great work!
Will there finally be a standalone dshow filter that can be used for real-time playback? That will be an alternative way to DXVA.

[squid_80]

Great work!
Will there finally be a standalone dshow filter that can be used for real-time playback? That will be an alternative way to DXVA.
What would be the point? If your card supports this, it already supports DXVA.

[Quark.Fusion]

DXVA don't support post-processing. BTW resizing and sharpening also can be done at GPU :)

Best benefit will be if someone combine decoding, lanczos/blackman/spline resizing and FFT3DGPU in one package to avoid transfer of image back and forth. (Like this (http://avisynth.org/oldwiki/index.php?page=GPU_001))

[NanoBot]

Hi,

since Sagekilla asked for a comparision between DGAVCIndex and DGAVCIndexNV on a quadcore CPU, a ran a few tests.

My PC is a Q6600 @ 3,4GHz with 2GBytes DDR2-800 RAM running at 756MHz. The graphics card is a 9600GT with forceware 177.83 drivers, and the OS is Windows XP Pro 32bit. To get DGAVCIndexNV to run, I only had to unpack it and to copy the nvcuvid.dll into my system32 directory, like instructed. Both the denoising and the sharpening sliders in the Nvidia control panel where set to 0% during this tests.


The first clip I used for my tests is a DVB recording from "Anixe HD", which is about 2 minutes long. It is 1080i50, the footage seems to be shot with a video camera, since it really is interlaced, it has an AR of 1,78:1 and looks very clear ( no noise or grain )

1.) Decoded with DGAVCDecode and encoded as interlaced:


LoadPlugin("D:\MPEG\AVISYNTH\PLUGINS\DGAVCDecode.DLL")
AVCsource("anixe.dga")

D:\MPEG\megui\tools\x264>x264.exe --crf 22.0 --level 4.1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-rdo --bime --weightb -
-trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --interla
ced --output "H:\anixe.mkv" "G:\Aufnahmen\anixe.avs"

avis [info]: 1920x1080 @ 25.00 fps (3023 frames)
x264 [warning]: NAL HRD parameters require VBV max bitrate and buffer size to be specified
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: slice I:14 Avg QP:21.34 size:229347
x264 [info]: slice P:1330 Avg QP:23.36 size: 65230
x264 [info]: slice B:1679 Avg QP:25.90 size: 20724
x264 [info]: consecutive B-frames: 9.8% 41.6% 17.0% 31.5%
x264 [info]: mb I I16..4: 13.0% 50.0% 37.0%
x264 [info]: mb P I16..4: 1.4% 6.9% 3.2% P16..4: 44.7% 15.1% 10.9% 0.0% 0.0% skip:17.8%
x264 [info]: mb B I16..4: 0.1% 0.3% 0.3% B16..8: 39.7% 1.1% 2.0% direct: 6.7% skip:49.8% L0:36.9% L1:54.5% BI: 8.6%
x264 [info]: 8x8 transform intra:58.1% inter:55.6%
x264 [info]: ref P L0 52.5% 20.0% 12.9% 4.0% 3.7% 2.1% 3.6% 1.2%
x264 [info]: ref B L0 65.5% 20.6% 7.2% 2.4% 3.0% 1.3%
x264 [info]: ref B L1 70.9% 29.1%
x264 [info]: SSIM Mean Y:0.9713192
x264 [info]: kb/s:8254.2

encoded 3023 frames, 5.64 fps, 8254.32 kb/s

2.) Decoded with DGAVCDecodeNV with "deinterlace=false" and encoded as interlaced:


LoadPlugin("D:\MPEG\AVISYNTH\PLUGINS\DGAVCDecodeNV.DLL")
AVCsource("anixe_nv.dga", deinterlace=false)

D:\MPEG\megui\tools\x264>x264.exe --crf 22.0 --level 4.1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-rdo --bime --weightb -
-trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --interla
ced --output "H:\anixe_nv.mkv" "G:\Aufnahmen\anixe_nv.avs"
avis [info]: 1920x1080 @ 25.00 fps (3026 frames)
x264 [warning]: NAL HRD parameters require VBV max bitrate and buffer size to be specified
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: slice I:14 Avg QP:21.01 size:228003
x264 [info]: slice P:1162 Avg QP:22.76 size: 66468
x264 [info]: slice B:1850 Avg QP:24.86 size: 16716
x264 [info]: consecutive B-frames: 9.0% 18.8% 25.3% 46.9%
x264 [info]: mb I I16..4: 12.9% 47.7% 39.4%
x264 [info]: mb P I16..4: 1.3% 7.5% 3.3% P16..4: 40.3% 15.9% 11.0% 0.0% 0.0% skip:20.9%
x264 [info]: mb B I16..4: 0.1% 0.2% 0.3% B16..8: 37.4% 0.9% 1.5% direct: 5.2% skip:54.5% L0:33.0% L1:58.9% BI: 8.1%
x264 [info]: 8x8 transform intra:59.7% inter:55.5%
x264 [info]: ref P L0 56.6% 22.8% 8.5% 3.8% 2.7% 2.1% 2.3% 1.2%
x264 [info]: ref B L0 71.8% 20.6% 3.7% 2.0% 1.0% 0.9%
x264 [info]: ref B L1 76.9% 23.1%
x264 [info]: SSIM Mean Y:0.9719650
x264 [info]: kb/s:7359.7

encoded 3026 frames, 5.99 fps, 7359.81 kb/s

3.) Decoded with DGAVCDecodeNV with "deinterlace=true" and encoded as progressive:


LoadPlugin("D:\MPEG\AVISYNTH\PLUGINS\DGAVCDecodeNV.DLL")
AVCsource("anixe_nv.dga", deinterlace=true)

D:\MPEG\megui\tools\x264>x264.exe --crf 22.0 --level 4.1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-rdo --bime --weightb -
-trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --output
"H:\anixe_nv_deint.mkv" "G:\Aufnahmen\anixe_nv_deint.avs"
avis [info]: 1920x1080 @ 25.00 fps (3026 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: slice I:14 Avg QP:19.71 size:161555
x264 [info]: slice P:1117 Avg QP:21.46 size: 54310
x264 [info]: slice B:1895 Avg QP:23.47 size: 14413
x264 [info]: consecutive B-frames: 8.6% 15.1% 22.5% 53.8%
x264 [info]: mb I I16..4: 10.8% 70.6% 18.7%
x264 [info]: mb P I16..4: 1.8% 14.8% 1.6% P16..4: 41.4% 11.9% 7.8% 0.0% 0.0% skip:20.7%
x264 [info]: mb B I16..4: 0.2% 0.7% 0.1% B16..8: 32.7% 0.7% 1.1% direct: 6.1% skip:58.3% L0:34.0% L1:58.0% BI: 7.9%
x264 [info]: 8x8 transform intra:80.1% inter:68.1%
x264 [info]: ref P L0 74.8% 13.3% 7.6% 4.2%
x264 [info]: ref B L0 89.6% 7.0% 3.4%
x264 [info]: SSIM Mean Y:0.9820854
x264 [info]: kb/s:5964.2

encoded 3026 frames, 9.01 fps, 5964.27 kb/s


The second clip I used is also a DVB recording, this time from "Premiere HD", which also is about 2 minutes long. It is 1080i50 and seems to be shot on celluloid since the footage is progressive. This clip has an AR of 1,85:1 and looks quite noisy to be, might be film grain.


4.) Decoded by DGAVCDecode and encoded as progressive:


LoadPlugin("D:\MPEG\AVISYNTH\PLUGINS\DGAVCDecode.DLL")
AVCsource("Premiere.dga")

D:\MPEG\megui\tools\x264>x264.exe --crf 22.0 --level 4.1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-rdo --bime --weightb -
-trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --output
"H:\Premiere.mkv" "G:\Aufnahmen\Premiere.avs"
avis [info]: 1920x1080 @ 25.00 fps (2977 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: slice I:42 Avg QP:14.42 size:171198
x264 [info]: slice P:2020 Avg QP:16.96 size: 84495
x264 [info]: slice B:915 Avg QP:19.28 size: 27135
x264 [info]: consecutive B-frames: 39.6% 55.8% 2.1% 2.5%
x264 [info]: mb I I16..4: 14.2% 77.5% 8.4%
x264 [info]: mb P I16..4: 2.4% 11.8% 0.7% P16..4: 45.1% 20.9% 10.1% 0.0% 0.0% skip: 8.9%
x264 [info]: mb B I16..4: 0.3% 0.8% 0.0% B16..8: 35.5% 0.8% 1.3% direct:16.4% skip:44.8% L0:43.3% L1:50.3% BI: 6.3%
x264 [info]: 8x8 transform intra:78.7% inter:60.6%
x264 [info]: ref P L0 57.8% 20.9% 11.3% 9.9%
x264 [info]: ref B L0 80.5% 10.5% 9.0%
x264 [info]: SSIM Mean Y:0.9782869
x264 [info]: kb/s:13617.7

encoded 2977 frames, 5.89 fps, 13617.88 kb/s

5.) Decoded by DGAVCDecodeNV with "deinterlace=false" and encoded as progressive:


LoadPlugin("D:\MPEG\AVISYNTH\PLUGINS\DGAVCDecodeNV.DLL")
AVCsource("Premiere_nv.dga",deinterlace=false)

D:\MPEG\megui\tools\x264>x264.exe --crf 22.0 --level 4.1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-rdo --bime --weightb -
-trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --output
"H:\Premiere_nv.mkv" "G:\Aufnahmen\Premiere_nv.avs"
avis [info]: 1920x1080 @ 25.00 fps (2980 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: slice I:37 Avg QP:14.35 size:149138
x264 [info]: slice P:1752 Avg QP:16.64 size: 78769
x264 [info]: slice B:1191 Avg QP:19.28 size: 25838
x264 [info]: consecutive B-frames: 24.9% 59.9% 10.1% 5.0%
x264 [info]: mb I I16..4: 14.3% 77.9% 7.8%
x264 [info]: mb P I16..4: 2.4% 12.1% 0.5% P16..4: 44.7% 20.5% 10.0% 0.0% 0.0% skip: 9.9%
x264 [info]: mb B I16..4: 0.2% 0.7% 0.0% B16..8: 39.4% 0.6% 1.2% direct:14.4% skip:43.4% L0:39.8% L1:54.4% BI: 5.8%
x264 [info]: 8x8 transform intra:80.1% inter:60.0%
x264 [info]: ref P L0 63.5% 18.4% 12.5% 5.6%
x264 [info]: ref B L0 81.5% 11.8% 6.7%
x264 [info]: SSIM Mean Y:0.9784119
x264 [info]: kb/s:11697.7

encoded 2980 frames, 6.41 fps, 11697.84 kb/s


Since the second clip is noisy, I ran two more tests on this one while adjusting the denoiser slider in the Nvidia control panel to 25% and 51%. Nevertheless this has no impact on the result, both the performance and the file size are not influenced in anyway by the adjustment of the denoise slider. This makes me think that might it be necessary do explicitely activate the denoise postprocessing through the cuda api.


My preliminary conclusions are:

When using a quadcore CPU, offloading the decoding process to the GPU without deinterlacing at least atm speeds up things about 5% - 10%. This is a good step into the right direction, but it's such a big one as somebody might have hoped for. Nevertheless I suppose that the performance gain by GPU decoding might be much higher when using a single ore a dual core CPU.

On the other hand, the GPU decoding has a huge impact when used together with the GPU deinterlacing feature. Here I could observe a performace gain over 50%.

I also observed that decoding the video through the GPU seems to have an notable impact on the picture quality resulting in a significantly higher compressibility of the video during the encoding process.

And at last, the libavcodec.dll seems to have a bug which makes it loosing 3 frames compared to GPU decoding.

Subsuming the results of my tests it's my opinion that, even at this early stage of development, the usage of the GPU decoding through DGAVCDecodeNV is absolutely recommendable, if you own a suitable graphics card. Even if you might "only" get a speedup of 5% - 10% in the worst case, the better compressibility, the better picture quality and the very good deinterlacing feature are making DGAVCDecodeNV superior over DGAVCDecode.


C.U. NanoBot

[lucassp]

DXVA don't support post-processing. BTW resizing and sharpening also can be done at GPU :)

Best benefit will be if someone combine decoding, lanczos/blackman/spline resizing and FFT3DGPU in one package to avoid transfer of image back and forth. (Like this (http://avisynth.org/oldwiki/index.php?page=GPU_001))

All the HQV tests have shown that DXVA capable cards can do sharpening, noise reduction and other post-processing.

Firstly you need FFT3DGPU ported to CUDA because right now it uses the Direct3D backend.

So we need a good CUDA programmer to do all this :)

[Daodan]

Better picture quality? That, I think, shouldn't happen. Do you have maybe comparison pics? Or did you mean only when deinterlacer is used, compared to software ones?

[NanoBot]

Hi Daodan,

perhabs I used a misleading verbalization:

Decoding through libavcodec.dll gives me macroblock errors, which results in a loss of compression. Those errors are gone if I use GPU decoding.
So "better picture quality" was the wrong term in that context, I should have used "better decoding result".

C.U. NanoBot

[Quark.Fusion]

AFAIK DXVA can't do FFT-NR, high-quality resize and limited sharpening — so you get medium quality NR, bilinear or at most bicubic resize and don't-know-what sharpening.
And if you want to encode that to view later on your not-so-powerful notebook or HTPC — you out of luck with DXVA.

[blubberbirne]

@blubberbirne
you are running vista 64bit, so may be the nvcuvid.dll(is it a 32bit runtime?) should be in the SysWoW64 folder

Great tip, i will test it, when i'm at home