DGMVCSource

[Guest]

I did make one small change. :)

Your trace of any timeout that might still occur will be really helpful.

I plan to simplify my interface to the Intel SDK code (eliminating one thread entirely), but what I have should work fine so I'd like to get to the bottom of it.

[Sharc]

OK, good.
I let the cmd batch now loop for a while and save the debug log.

Added:
With another 26 rounds in succession without issues I am very positive that the problem is now solved ...... :cool:

[Guest]

With another 26 rounds in succession without issues I am very positive that the problem is now solved Great to hear! Thank you for your testing.

Onward to interface simplification followed by hardware acceleration...

Anybody need an immediate source code drop or should I wait for the above?

[Nico8583]

Great to hear! Thank you for your testing.

Onward to interface simplification followed by hardware acceleration...

Anybody need an immediate source code drop or should I wait for the above?
Thanks for your work !
No need for source code now for me ;)

[Guest]

Sorry guys, single stream output got broke in b12. So here is b14 (yes I am superstitious) to fix that.

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

[Sharc]

Resuming my favourite test with beta 14 ...... :D

[Guest]

Just in time for beta 15!

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

I added the capability to decode a normal AVC stream (not a combined MVC stream). You just specify like this in the same way as if it was MVC combined:

dgmvcsource("normal_avc.264", "", view=0, frames=1000)

The specified file is examined and the decoder is opened in the correct mode depending on whether the file has MVC startcodes or not. So again, we avoid needing an additional parameter. If a normal AVC file is detected, the view parameter is ignored.

Obviously, DGDecIM is going to need to work on normal AVC files also (and normal VC-1, MPEG2, HEVC). ;)

[Nico8583]

Just in time for beta 15!

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

I added the capability to decode a normal AVC stream (not a combined MVC stream). You just specify like this in the same way as if it was MVC combined:

dgmvcsource("normal_avc.264", "", view=0, frames=1000)

The specified file is examined and the decoder is opened in the correct mode depending on whether the file has MVC startcodes or not. So again, we avoid needing an additional parameter. If a normal AVC file is detected, the view parameter is ignored.

Obviously, DGDecIM is going to need to work on normal AVC files also (and normal VC-1, MPEG2, HEVC). ;)
Very good news for multi codec support :D but why "IM" in DGDecIM ? Input Multiple ?

[Guest]

Intel Media

[Nico8583]

Of course, it was evident ;)

[Guest]

I'm trying to turn on HW acceleration but no Intel graphics HW is detected. Hmm, I have an NVidia card installed and so I suppose the integrated Intel graphics is turned off in the BIOS. I have to turn it back on and hope I can use it as a secondary, etc. Anybody have this working?

[r0lZ]

As far as I know, the HW acceleration requires a specific Intel CPU, not a nVidia graphics card. It's not CUDA.
Unfortunately, I don't have the right hardware, and I can't help you much on that subject. IIRC, Nico8583 has the right CPU and he should be able to test your builds.

[Guest]

I have the right CPU and I well know the difference between the Intel stuff and CUDA. I am just looking to enable it alongside the NVidia adapter. If I can't do that I lose DGDecNV and that's not something I can accept.

EDIT: I found a post by Eric Gur at the Intel forum explaining how to do this and it is working for me now. :)

[r0lZ]

Ah, OK, I have not understood your request. Sorry.

[Guest]

No problem, r0lZ! I always appreciate your feedback and testing!

Here is beta 16 with HW acceleration. It will be used automatically if available, otherwise SW will be used.

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

So, in case you didn't figure it out, this little project for me is a warmup for DGDecIM, sort of a test to see if I can use the Intel Media SDK in the way that will be needed. It's apparent that I can. So I propose to wait a bit for feedback on this last version of DGMVCSource. If no problems arise I'll release the source code and then move on to the fully frame-accurate DGDecIM (with MVC support, of course).

EDIT: To see how fast the HW acceleration can be, add AssumeFPS(1000) to your script and then play it in VirtualDub.

[Guest]

@r0lZ

Could you please verify that b16 is still working in SW mode? Thanks!

[r0lZ]

Yes, it works. Slowly for me, but it works. ;-)

[Zathor]

Thank you very much for this filter!

I just tried it the first time and of course also within MeGUI. Sadly it does crash MeGUI. I expected that when using the preview when MeGUI tries to jump into the preview but it also crashes simply opening and closing the avs script environment. frimsource does not have this behaviour. I am currently debugging MeGUI to get the step where it crashes. Likely the problem is within MeGUI or the related avs wrapper.

Also in VirtualDub (it does not crash there) I noticed that I cannot reopen the video while in the middle of the video - it will start from the beginning. Once again with frimsource and this pseudo caching set to >1 it is possible to do this.

[Guest]

Can you please give me the script you opened in MEGUI?

I will try it here too with some scripts.

The re-open stuff will be automatically fixed by correct random access, and I'm not that interested in pseudo seeking. As an interim expedient, sure go for it, but I don't think it's a good long-term solution.

[Nico8583]

Thanks a lot for HW acceleration, I'll try to test tomorrow ;)

[Guest]

OK, it's obvious what is happening. MEGUI is asking for multiple instantiations of dgmvcsource(). It's on my to-do list and I suppose I'll have to support that right now. Standby...

[Zathor]

My current script is quite simple:
LoadPlugin("D:\MVC\DGMVCDecode.dll")
vid=dgmvcsource("D:\MVC\combined.264","",view=0,frames=2000)

I am not sure if multiple instances are the problem. Based on the MeGUI debug the crash happens after the third opening of the script but the other two are already closed. Or do you see on your side that these other two instances are not correctly closed? In that case the wrapper may have a problem as the dispose is called in the managed code and executed in the unmanaged wrapper code.

[MeteorRain]

Honestly I'm quite exciting when hearing about QuickSync for DG series. (DGQuick?)

[Guest]

My current script is quite simple:
LoadPlugin("D:\MVC\DGMVCDecode.dll")
vid=dgmvcsource("D:\MVC\combined.264","",view=0,frames=2000)

I am not sure if multiple instances are the problem. Based on the MeGUI debug the crash happens after the third opening of the script but the other two are already closed. Or do you see on your side that these other two instances are not correctly closed? In that case the wrapper may have a problem as the dispose is called in the managed code and executed in the unmanaged wrapper code. I'll check. I had a trace only on the instantiation and not the destruction so I wouldn't have noticed what you say. Assuming you are correct can you continue please to find the cause of MEGUI crashing? Thanks.

Meanwhile I am removing all global data anyway as it needs to be done.

EDIT: You're right, I see the destructor called as you say.

[osgZach]

Thread's a bit big to read through... But is this basically for decoding 3D stuff? i.e useless for non 3D ?

And about the Quicksync. I have had trouble finding any reliable answer on exactly what needs to happen to enable it. Does it require a CPU with a GPU or something? I can't get Quicksync to enable in LAV filters for instance.. Its just a decoder right?
I have an i5 3570K Ivybridge. Which supposedly supports it, but then people say you need an onboard GPU....? Is this a motherboard specific thing and not the IGPU's in newer CPUs ?

If so that is pretty retarded on Intel's part.. why even include the technology if you're going to gimp it with the requirement of an inferior GPU on the chip or motherboard

[Stereodude]

And about the Quicksync. I have had trouble finding any reliable answer on exactly what needs to happen to enable it. Does it require a CPU with a GPU or something? I can't get Quicksync to enable in LAV filters for instance.. Its just a decoder right?
I have an i5 3570K Ivybridge. Which supposedly supports it, but then people say you need an onboard GPU....? Is this a motherboard specific thing and not the IGPU's in newer CPUs ?

If so that is pretty retarded on Intel's part.. why even include the technology if you're going to gimp it with the requirement of an inferior GPU on the chip or motherboardAre you using the integrated graphics on your Ivybridge to drive a display? Ivybridge supports QuickSync. I believe you need to run some additional software for Ivybridge processors to enable the iGPU if you're using a PCIe display adapter to drive your display so you can still use QuickSync if you don't have a monitor attached to it.

[Thalyn]

Most motherboards have the option to have the iGPU enabled with a discrete GPU. It's an option in BIOS. Both my Sandy Bridge and Haswell have the option, at least on Z68 and Z87 boards respectively. I believe only certain H and P boards can do it, though.

However, unless the implementation is Windows 8 aware (thus supporting "headless" mode) you need to have a monitor attached - either real or fake. If you don't do this than DirectX won't enumerate the device, thus it won't be available to use for acceleration. This page here (http://mirillis.com/en/products/tutorials/action-tutorial-intel-quick-sync-setup_for_desktops.html) outlines how you can create a fake monitor and it seems to work with the latest drivers from Intel (but not with the latest Windows Update ones). If you're using a fake screen you can reposition it up to the very corner of the real one to stop your cursor getting "lost".

[Zathor]

I'll check. I had a trace only on the instantiation and not the destruction so I wouldn't have noticed what you say. Assuming you are correct can you continue please to find the cause of MEGUI crashing? Thanks.

Meanwhile I am removing all global data anyway as it needs to be done.

EDIT: You're right, I see the destructor called as you say.
Sorry, I did not had the time to dig deeper. For me it is quiete complicated to find the root cause of the crash as it is happening somewhere in unmanaged external code. Regarding the log it crashes in the module DGMVCDecode.dll_unloaded

[Guest]

Sorry, I did not had the time to dig deeper. For me it is quiete complicated to find the root cause of the crash as it is happening somewhere in unmanaged external code. Regarding the log it crashes in the module DGMVCDecode.dll_unloaded Thanks, Zathor. I found and fixed the problem. I wasn't properly deallocating the decode pipeline when the filter was deinstantiated. I'll make a new beta after some more testing.

[Guest]

Here is the fix for running in MEGUI:

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

[Guest]

Thread's a bit big to read through... But is this basically for decoding 3D stuff? i.e useless for non 3D ? It can decode normal AVC as well.

Think of it as a trial run for a version of DGDecNV that will use the Intel Media SDK rather than NVidia's CUVID. The Intel Media SDK supports both SW decoding and HW acceleration via QuickSync, and therefore DGDecIM will be able to run in SW or HW, depending on the machine capabilities.

[Guest]

Please re-download beta 17. The first upload was, umm, suboptimal. ;)

[Video Dude]

Thanks for working on another great program!


The Intel Media SDK supports both SW decoding and HW acceleration via QuickSync, and therefore DGDecIM will be able to run in SW or HW, depending on the machine capabilities.
Is there any difference in decode quality between software and hardware mode?

[Guest]

Is there any difference in decode quality between software and hardware mode? I haven't tested anything like that but theoretically the outputs should be identical.

[Guest]

Release candidate:

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

This supports multiple instantiation in a script.

[Nico8583]

Doom9 is up :D
I'll try to make an other test today to compare SW and HW speed with AVSMeter and x264 :)

[Guest]

Here is a version that allows you to force SW or HW decoding. Use the hw parameter as needed.

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

[Nico8583]

Thanks for this version, I'm going to test :)

[rack04]

It can decode normal AVC as well.

Think of it as a trial run for a version of DGDecNV that will use the Intel Media SDK rather than NVidia's CUVID. The Intel Media SDK supports both SW decoding and HW acceleration via QuickSync, and therefore DGDecIM will be able to run in SW or HW, depending on the machine capabilities.

Would an NVidia user with an ivy bridge processor be able to use DGDecIM without having intel's video drivers installed? This may be useful if there are streams that don't work with NVidia, which I have yet to encounter.

[Guest]

Would an NVidia user with an ivy bridge processor be able to use DGDecIM without having intel's video drivers installed? This may be useful if there are streams that don't work with NVidia, which I have yet to encounter. You will be able to use the SW decoding mode if no Intel drivers are installed, or if the Intel GPU is not enabled in the BIOS. My current thinking is to have one application, DGDec, that can use any available decoding engine, SW or HW. So even if you don't enable the Intel GPU, you could still use the Intel Media SDK decoder in SW mode. Or CUDA/CUVID, all in one application.

If you want QuickSync, however, you have to install the Intel driver. I have done this as a secondary. My i7-4770 machine came with an nVidia 620 installed. I had to enable the Intel GPU in the BIOS and then install the Intel driver. The nVidia 620 remains the primary video so I get both CUDA/CUVID and QuickSync available.

QuickSync appears to be somewhat faster than CUDA/CUVID, so that could be a reason to prefer it. CUDA/CUVID always has to pass decoded pictures back to the CPU over the video bus. The Intel GPU is presumably closer to CPU memory and that accounts for some of the speedup.

[MeteorRain]

For DGDecIM, would it be usable under remote desktop connection?

If I have 3 monitors, 2 of them plug on nVidia while 1 on IGP, will it still be able to use QS?

[Nico8583]

So I have made 4 tests with DGMVCSource and FRIMSource. Here are results with my i5-3570, 8GB RAM and latest Intel drivers.

DGMVCSource SW :
Frames processed: 2800 (0 - 2799)
FPS (min | max | average): 16.01 | 30.97 | 20.52
CPU usage (average): 19%
Thread count: 9
Physical Memory usage (peak): 592 MB
Virtual Memory usage (peak): 594 MB
Time (elapsed): 000:02:16.473

DGMVCSource HW :
Frames processed: 2800 (0 - 2799)
FPS (min | max | average): 33.32 | 65.83 | 54.57
CPU usage (average): 7%
Thread count: 17
Physical Memory usage (peak): 650 MB
Virtual Memory usage (peak): 737 MB
Time (elapsed): 000:00:51.310

FRIMSource SW :
Frames processed: 2800 (0 - 2799)
FPS (min | max | average): 17.33 | 35.12 | 21.69
CPU usage (average): 41%
Thread count: 12
Physical Memory usage (peak): 730 MB
Virtual Memory usage (peak): 778 MB
Time (elapsed): 000:02:09.120

FRIMSource HW :
Frames processed: 2800 (0 - 2799)
FPS (min | max | average): 55.87 | 74.81 | 63.93
CPU usage (average): 25%
Thread count: 20
Physical Memory usage (peak): 771 MB
Virtual Memory usage (peak): 973 MB
Time (elapsed): 000:00:43.797

For both tests, FRIMSource is faster than DGMVCSource but it uses more CPU (about 2x or 3x) than DG plugin. Both are based on Intel Media SDK so how could we interpret that :confused:

[Sharc]

I did similar tests which I posted in neuron2's Forum.
I can't HW decode, however for SW decoding I also found that FRIM seems to be faster than DGMVC for pure decoding, HOWEVER:
When I transcode half-SBS with x264, DGMVCsource produced faster overall results for my 3D testclip:
DGMVCsource_SW_decoding + x264_encoding time = 180 sec.
FRIMsource_SW_decoding + x264_encoding time = 195 sec

[Nico8583]

I did similar tests which I posted in neuron2's Forum.
I can't HW decode, however for SW decoding I also found that FRIM seems to be faster than DGMVC for pure decoding, HOWEVER:
When I transcode half-SBS with x264, DGMVCsource produced faster overall results for my 3D testclip:
DGMVCsource_SW_decoding + x264_encoding time = 180 sec.
FRIMsource_SW_decoding + x264_encoding time = 195 sec
Could you post here or PM your AVS scripts and x264 cmdline ? I'll try to make tests like you with my CPU (and HW support)

[Groucho2004]

HOWEVER:
When I transcode half-SBS with x264, DGMVCsource produced faster overall results for my 3D testclip:
DGMVCsource_SW_decoding + x264_encoding time = 180 sec.
FRIMsource_SW_decoding + x264_encoding time = 195 sec
That makes sense considering the larger CPU overhead of FRIMSource().

[Sharc]

That makes sense considering the larger CPU overhead of FRIMSource().
Exactly my thoughts......

[sef]

Nico8583: So I have made 4 tests with DGMVCSource and FRIMSource. Here are results with my i5-3570, 8GB RAM and latest Intel drivers.

I Agree..

[Sharc]

Could you post here or PM your AVS scripts and x264 cmdline ? I'll try to make tests like you with my CPU (and HW support)
Here we go:

FRIM script:
LoadPlugin("c:\Program Files Video\AviSynth 2.5\plugins\FRIMSource.dll")
FRIMsource(codec="mvc", filename="base.264", filename_dep="dep.mvc", layout="SBS", cache=24, num_frames=1650)
horizontalreduceby2()

x264-FRIM cmd:
x264.exe "FRIMSource_.avs" --bluray-compat --crf 22 --vbv-bufsize 15000 --vbv-maxrate 15000 --sar 1:1 --fps 23.976 --output "out_FRIMSource-to-x264.h264"


DGMVC script:
LoadPlugin("c:\Program Files Video\AviSynth 2.5\plugins\DGMVCDecode.dll")
Video=DGMVCsource("base.264","dep.mvc",frames=1650,view=0,hw=0)
V1 = SelectEven(video)
V2 = SelectOdd(video)
return StackHorizontal(horizontalreduceby2(V1),horizontalreduceby2(V2))


x264-DGMVC cmd:
x264.exe "DGMVCSource_.avs" --bluray-compat --crf 22 --vbv-bufsize 15000 --vbv-maxrate 15000 --sar 1:1 --fps 23.976 --output "out_DGMVCSource-to-x264.h264"

[sef]

Very good neuron2! Thank you for the work done, you become the favorite ..:)

[Nico8583]

Thanks Sharc, I'm going to try in few hours and I'll tell you results :)