DGDecIM: Frame-accurate Avisynth source filter for QuickSync

[DarkSpace]

@DarkSpace
AviSynth+ is compatible. I use it with x64 version of DGDecNV and also I have tested it with DGDecIM 32bit.
I'm aware of compatibility, but thanks (it was perhaps misleading, I'll edit my original post). What I meant was whether avs+ will be actively supported, e.g. by setting the MT mode in the plugin itself (http://forum.doom9.org/showthread.php?p=1667360#post1667360).

[Guest]

I am little disapointed about the speed. I made real encoding test and results are follows. I encoded to 720p x264:
DGDecNV (x64) - encoded 75747 frames, 15.40 fps
DGDecIM (x32) - encoded 75747 frames, 12.35 fps

I know it is not fair compare x32 vs. x64 encoding process. But from previous tests I know x64 version is about 2-3fps faster than x32 encoding process. I can make conclusion that DGDecNV and DGDecIM have very similar speed. Any mistakes? DGDecIM is a decoder. I care about and can control only the decode frame rate. In the current beta DGDecIM is 25-50% faster than DGDecNV. In my private beta about to be released I have a decode rate of 500fps+, which is 300-400% faster. No reason for disappointment here. :)

[Guest]

It looks to me like a butchered hybrid stream, i.e. interlaced for the interview segment and pulldown for the movie segment. Separate the fields and look for example field 179 (the hand), 383, 403, 485, 495 (all with blueish ghosts) to name but a few. It's the same for fieldop=2. Then it's not an issue for me, right?

[Guest]

I'm aware of compatibility, but thanks (it was perhaps misleading, I'll edit my original post). What I meant was whether avs+ will be actively supported, e.g. by setting the MT mode in the plugin itself (http://forum.doom9.org/showthread.php?p=1667360#post1667360). If someone tells me clearly what to do and how to do it, and it does not break 2.5.8 support, I will certainly try to help. I'm not sure MTing a source filter that already delivers 500fps (upcoming beta) would benefit much from the effort, but you tell me, I'm an MT dilettante.

[Groucho2004]

I know it is not fair compare x32 vs. x64 encoding process.
Exactly.

Any mistakes?
See above.

But from previous tests I know x64 version is about 2-3fps faster than x32 encoding process. I can make conclusion that DGDecNV and DGDecIM have very similar speed.
You're measuring encoding speed, not decoding speed. In your scenario the encoder determines how many frames/second it needs, the decoders are almost idle and very bored.

[Guest]

Thanks for the answer. Just for the record, I believe that Unicode support is nice to have.
Noted, thank you.

[Guest]

In your scenario the encoder determines how many frames/second it needs, the decoders are almost idle and very bored. Yes, very well put. :goodpost:

[Sharc]

Then it's not an issue for me, right?
Looks like, yes.
I got alert because it looked better (no ghosts, but partly jerky) when decoding it with DGDecodeNV / Nvidia.
Anyway, it finally looks ok when I append telecide():
The interview section becomes progressive and the movie section shows a regular 3:2 pulldown pattern.
Finally, appending telecide().tdecimate() does the trick.
So we can put this clip aside.....

[Groucho2004]

I'm not sure MTing a source filter that already delivers 500fps (upcoming beta) would benefit much from the effort
That's your polite way of saying what I think - It makes no sense. :D

[Guest]

Here is beta 10, with performance improvement. I am reaching 500fps+ with AVC 1920x1080.

http://neuron2.net/misc/dgdecim_b10.zip

For those interested in the changes that so dramatically improve the decode rate, there were two (no secrets here):

1. The asynchronous pipeline was being synced after every frame decode. It's done that way in the Intel sample, but it is not necessary. Empirically and theoretically, it suffices to sync the pipeline only once after each decoder reset and then omit the sync call on linear-access subsequent frames. Sync is performed after every seek and then linear decode proceeds without sync'ing.

2. The NV12->YV12 conversion is very expensive. I optimized the conversion and frame copy to the Avisynth buffer. I am wondering if the SDK can give me YV12 directly. I will look into that. Also possible, do the conversion on the iGPU.

[Guest]

I hope you will add Intel HW deinterlacing in the next build. My current priority list, assuming the 500fps build holds up, is:

* check VC1 HW decode with recently released Intel driver
* address any problem streams (I have only one right now: test_bad_decode.mkv)
* HW postprocessing (crop, resize, deinterlace, ivtc)
* MVC support

And at some point I have to make nice documentation and then formally make the whole thing available at my web site.

[Guest]

That's your polite way of saying what I think - It makes no sense. :D I think if you can find a way to respond to things in a polite and helpful way then you achieve a win-win interaction. An interaction that requires asserting that the other has no sense is not win-win. And it's debatable anyway; what's wrong with trying to squeeze as much as one can out of a process?

Still, I enjoy the humor. :p

[DarkSpace]

Noted, thank you.
Okay.

If someone tells me clearly what to do and how to do it, and it does not break 2.5.8 support, I will certainly try to help. I'm not sure MTing a source filter that already delivers 500fps (upcoming beta) would benefit much from the effort, but you tell me, I'm an MT dilettante.
From that, I suppose you want Mode 3 (serialized) for your filter. In that case, the header should contain something like

int __stdcall SetCacheHints(int cachehints,int frame_range) {
if (cachehints == 509) /* CACHE_GET_MTMODE */
return 3; /* MT_SERIALIZED */
else
return 0;
}

to register the filter as such.

EDIT:
That's your polite way of saying what I think - It makes no sense. :D
I took no offense, I realize that source filter typically have no MT, anyway. MT modes in the plugin was mainly an example, but neuron2's answer gave me the information I wanted, so thanks!

EDIT2:
I guess I'll have to find my old HDD, I should have some streams there that I might be able to use to test, also with MT modes...

[Groucho2004]

what's wrong with trying to squeeze as much as one can out of a process?
Nothing.
However, you might be opening a can of worms going that route. Multi-threading always has some overhead, synchronization issues, etc.
Just look at FFMS2. More often than not, users have to specify "Threads=1" in order to get a filter chain working properly.

[Guest]

Nothing.
However, you might be opening a can of worms going that route. Multi-threading always has some overhead, synchronization issues, etc.
Just look at FFMS2. More often than not, users have to specify "Threads=1" in order to get a filter chain working properly. I wasn't committing to support MT usage and I've always been dubious about its reliability in practice, at least as currently implemented, but I still see it as a valid and potentially useful technology and wouldn't want to discourage interested people from exploring it and applying it where possible.

[lansing]

benchmark on beta10 @30% iGPU

Number of frames: 116220
Length (hhh:mm:ss.ms): 001:04:37.874
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (30000/1001)
Interlaced: No
Colorspace: YV12

Frames processed: 39050 (0 - 39049)
FPS (min | max | average): 199.1 | 669.6 | 601.3
CPU usage (average): 18%
Thread count: 39
Physical Memory usage (peak): 176 MB
Virtual Memory usage (peak): 338 MB
Time (elapsed): 000:01:04.948


Reached a whopping 600fps :eek:, kind of weird that the benchmarks vary though. Sometime it stayed at 600fps, sometime 575fps.

[Guest]

I noticed that too. Strange.

[lansing]

problem found, random seeking in beta 10 will cause chroma ghosting, happen to both avc and mpeg2 streams. And after seek, frame accuracy will be off, I compared side by side with beta 9 in avspmod, the same number frame didn't match up.

[asteri]

DGDecIM is a decoder. I care about and can control only the decode frame rate. In the current beta DGDecIM is 25-50% faster than DGDecNV. In my private beta about to be released I have a decode rate of 500fps+, which is 300-400% faster. No reason for disappointment here. :)

I wrote it in wrong way ;)

Maybe the DGDecIM is 30% faster then DGDecNV in decoding but impact on speed of the whole encoding process is minimal to nothing.

I think this is the important measurement for those of us with nvidia cuda capable card.

Still I think the whole encoding process (decoding+encoding) it must be slower because you will use CPU for decoding and encoding. But with cuda card could be decoding part done by another hw (nvidia cuda graphics) and almost whole power of CPU could be used for encoding. Am I right?

Of course I have to say big thank you for this DGDecIM version even if it will be slower. It is very important to have some alternative for people without cuda graphics. Current DGAVCDecDI isnt good choice.

EDIT: My measurement was done with beta9, I will try b10 later ;)

[lansing]

it must be slower because you will use CPU for decoding and encoding

You are missing the whole point of this tool then. This decoder was created to take the loads off the cpu by utilizing it's internal gpu, to let the internal gpu do the decoding job. Yes, just like what you're talking about with the nvidia card.

Maybe the DGDecIM is 30% faster then DGDecNV in decoding but impact on speed of the whole encoding process is minimal to nothing.
You need to compare apple to apple here. We are talking about decoding speed, not anything else. The overall encoding speed can be affected by many other stuffs, the most obvious bottleneck is the speed of the cpu itself. No matter how fast the decoding speed is, if cpu can only run at N frame per second for encoding, then your whole process will be as fast as your weakest link.

[asteri]

You are right, but If there will be no speedup of the whole process then speedup in decoding phase only is not important for me ;)

It was my fault expected speed up of the whole process.

Thanks guys for clarification

[Sharc]

Do I have to remove dgdecodeNV.dll from the avisynth plugins folder for testing dgdecodeIM.dll (which I load explicitly from a local folder) to make sure that DGSource uses dgdecodeIM?

[yup]

neuron2!

Thanks now work!
I am testing short clip from camera and see a lot off block in Virtualdub (1440x1088 interlaced source 25 fps).
When I read the same dgi (created by IM indexer) file by NV decoder all was O'k.

yup.

[Guest]

Do I have to remove dgdecodeNV.dll from the avisynth plugins folder for testing dgdecodeIM.dll (which I load explicitly from a local folder) to make sure that DGSource uses dgdecodeIM? I'll have to look into that. For now it's probably best to do that. You can use the debug=true parameter to see which one is actually being used.

[Guest]

problem found, random seeking in beta 10 will cause chroma ghosting, happen to both avc and mpeg2 streams. And after seek, frame accuracy will be off, I compared side by side with beta 9 in avspmod, the same number frame didn't match up. It is very important for us to be sure that the performance improvement has not broken things. Can you please provide a stream and instructions for duplicating what you report here? Thank you.

[Guest]

neuron2!

Thanks now work!
I am testing short clip from camera and see a lot off block in Virtualdub (1440x1088 interlaced source 25 fps).
When I read the same dgi (created by IM indexer) file by NV decoder all was O'k.

yup. Please advise if it happens also with beta 11. We are testing the effect of the performance improvements.

[Guest]

In view of lansing's reports I have backed off the pipeline change in beta 11:

http://neuron2.net/misc/dgdecim_b11.zip

I'll follow up with Intel to see if there is any way to reliably use this finesse. Even without it the color conversion changes are giving me about 400fps.

For those interested in testing we have:

b9 no performance changes
b10 pipeline and color conversion changes, likely broken
b11 color conversion changes only

[Guest]

You are right, but If there will be no speedup of the whole process then speedup in decoding phase only is not important for me ;)

It was my fault expected speed up of the whole process.
The point of this development is to provide non-Nvidia users with a frame-accurate source filter. I have never claimed that it will speed up transcoding, although in some scenarios it may give a modest improvement.

[Guest]

I'll have to look into that. For now it's probably best to do that. You can use the debug=true parameter to see which one is actually being used. I did some testing and it appears that the loadplugin in the script overrules the plugin directory.

Probably Gavino could confirm or disconfirm this; I haven't looked at Avisynth code for a long long time.

[Sharc]

problem found, random seeking in beta 10 will cause chroma ghosting, happen to both avc and mpeg2 streams. And after seek, frame accuracy will be off, I compared side by side with beta 9 in avspmod, the same number frame didn't match up.
Hmm.... I don't want to overcomplicate things, but I noticed ugly chroma ghosting in my "problematic" clip 'vc-1_hulk' as well and concluded that the clip is probably butchered. Surprisingly the chroma ghosting also exists when I decode with DGDecodeNV. In my case the ghosting shows typically up as blueish ghosts in some frames/fields.

[Sharc]

I did some testing and it appears that the loadplugin in the script overrules the plugin directory.
Yep, I came to the same conclusion (thanks to the debug=true).
A problem may only arise when both .dll are in the avisynth plugins folder and no specific LoadPlugin(...) is in the script. In my tests the DGDecodeNV gets preference in this case.

[Guest]

Hmm.... I don't want to overcomplicate things, but I noticed ugly chroma ghosting in my "problematic" clip 'vc-1_hulk' as well and concluded that the clip is probably butchered. Surprisingly the chroma ghosting also exists when I decode with DGDecodeNV. In my case the ghosting shows typically up as blueish ghosts in some frames/fields. The two are unrelated. Your source clip is bad. The ghosting is in the source.

[Sharc]

The two are unrelated. Your source clip is bad. The ghosting is in the source.
Thanks for double checking. I'll bury this clip now definitely :D

[Guest]

Yep, I came to the same conclusion (thanks to the debug=true).
A problem may only arise when both .dll are in the avisynth plugins folder and no specific LoadPlugin(...) is in the script. In my tests the DGDecodeNV gets preference in this case. Do you folks out there want me to have separate filter names:

dgsourceim()
dgsourcenv()

This affects only people who want to be able run both of them.

[Sharc]

Short term it would probably prevent ambiguities or doubts.
Long term only one decoder may be good for all cases, making anything else obsolete?

[lansing]

Tested beta 11, no more chroma ghostng, frame matched up with beta 9 in preview. Speed well above 400fps.

Another thing I notice, it feels like the gpu has its own cache remembering the last activity or something? I ran three consecutive benchmarks on the same file. On the first run, speed steadied at 475fps for about 13k frames before it dropped to 42x fps at 15k frames, where I exited. On the second run, the speed stayed at 475fps until the 15k frames mark before it began to drop again, this time I let it run until the 40k frames mark before i exited it. And on the third run, it ran at 470fps for the first 40k frames with the same behavior.

[CarlPig]

Do you folks out there want me to have separate filter names:

dgsourceim()
dgsourcenv()

This affects only people who want to be able run both of them.

Yes that is a good idea.

[lansing]

Do you folks out there want me to have separate filter names:

dgsourceim()
dgsourcenv()

This affects only people who want to be able run both of them.

+1 for that. It's always better for users to know what it is by its name. Btw, what is "IM" stand for anyway?

[Guest]

Tested beta 11, no more chroma ghostng, frame matched up with beta 9 in preview. Speed well above 400fps. Sweet. Thanks for your test results.:thanks:

Another thing I notice, it feels like the gpu has its own cache remembering the last activity or something? I ran three consecutive benchmarks on the same file. On the first run, speed steadied at 475fps for about 13k frames before it dropped to 42x fps at 15k frames, where I exited. On the second run, the speed stayed at 475fps until the 15k frames mark before it began to drop again, this time I let it run until the 40k frames mark before i exited it. And on the third run, it ran at 470fps for the first 40k frames with the same behavior. There is lots of caching to take into consideration, especially the HW disk cache and the OS file caching. There is also Avisynth frame caching but it wouldn't come into play for linear decode. There is no iGPU frame caching.

IM = Intel Media

[tormento]

Do you folks out there want me to have separate filter names
If you plan to join DGDecNV with DGDecIM, IMHO, a single filter name is better, with option to select the decoder.

As the indexing software is able to create avs file automatically, you should put a voice in menus to select the hw decoder to use, greyed if not available.

[yup]

Please advise if it happens also with beta 11. We are testing the effect of the performance improvements.

neuron2!

I am testing beta9 and beta11 and see also block but in other place comparing to beta 10.
yup.

[Guest]

I am testing beta9 and beta11 and see also block but in other place comparing to beta 10.
yup. If you want any attention to your problem, you'll need to provide a test stream, your script, and an explanation of how to duplicate the issue. Thank you.

[yup]

If you want any attention to your problem, you'll need to provide a test stream, your script, and an explanation of how to duplicate the issue. Thank you.

I find progressive source and one work fine.
Problem only with camera source mts file, which I convert using MeGUI Extractor for h264.
This source work fine with NV tools.
After weekend I try upload source.
yup.

[Guest]

Here is beta 12. It changes the source filter name to dgsourceim() and it fixes tormento's "bad" MKV stream handling.

http://neuron2.net/misc/dgdecim_b12.zip

At this point I have only yup's issue to fix; nothing else has been reported. It would sure be nice if yup could upload the stream now so I could work on it this weekend. ;)

[Sharc]

beta12 works ok here, but I can only test it in SW mode.
Looking forward to the integration of MVC :)

[Guest]

Looking forward to the integration of MVC :) More than HW deinterlace, ivtc, and crop/resize?

[CarlPig]

HW deinterlace yes sir.

[lansing]

I have a tv recorded stream that will cause avsmeter to hang when it ends. No such problem with virtualdub analysis pass, avspmod preview, or mpc playback.

bad (http://www.mediafire.com/download/9o934akzqiqv1f9/hangs.mkv)

[Nico8583]

I'm agree with MVC integration before HW filter :D

[Groucho2004]

I have a tv recorded stream that will cause avsmeter to hang when it ends. No such problem with virtualdub analysis pass, avspmod preview, or mpc playback.

bad (http://www.mediafire.com/download/9o934akzqiqv1f9/hangs.mkv)
Have you tried different decoders? I tried DGDecodeNV and LWLibavVideoSource. No problem.
I can't use DGDecIM, don't have the required hardware.