DGMVCSource

[slavanap]

I even don't know to what thread I should respond :)

Well, the way how to dump MPEGSplitter_mod.ax output is:
Install GraphStudioNext (you may already have one with "K-Lite Codec Pack Full" installed).
Insert splitter from file: Graph->Insert filter from file... menu.
Choose the .ax file, and use this GUIDs:
MPC MPEG Splitter {DC257063-045F-4BE2-BD5B-E12279C464F0}
or
MPC MPEG Source Splitter {1365BE7A-C86A-473C-9A41-C0A6E82C9FA3}

After inserting the filter into the graph you can insert the source filter, and dump the output pins output (right click -> dump). Output pins will appear after connecting input pin or opening the source.

Also you can use next version of ssifSource4, set stop_after = SA_DEMUXER, and specify avc264 & mvc264 for dest files.
http://rghost.ru/52455885
http://forum.doom9.org/showthread.php?p=1668501#post1668501

P.S. @allanlee Nothing special about sample_decode.exe. I just got one from here:
"c:\Program Files (x86)\Intel\Media SDK 2013\samples\_bin\x64\sample_decode.exe"

[allanlee]

Thank you so much, slavanap!

Managed to write the output of MPCHC filter to files:
(1) if the ssif is generated by tsMuxer3D (using elementary streams), the demuxed avc & mvc streams have the same md5 & sha1 compared to the original ones. Therefore, feeding MPCHC filter demuxed streams into DGMVCSource of course still have bad frames. :-(
(2) if the ssif is from original BluRay - eac3to demuxed ones and MPCHC filter demuxed ones are slightly different. (Tried with some sample clips) Since I don't have the Pacific Rim 3D BluRay here, currently I'm not able to run through the whole stream.
But personally I suppose that the demuxing step - use eac3to/tsmuxer3D/MPCHC/whatever-else should NOT be the source of problem.
Even the same combined avc+mvc stream will have different decode results - ssifSource4.x return good frames while DGMVC/Frim/MVCSource have problem. There must be some hidden bugs (or at least different algorithm compared to ssifSource4.x) after the "combined stream" step with DGMVCS/Frim/MVCSource.

[Thalyn]

Ran through the whole stream as demuxed from the source disc using a Graph to create the elementary streams. Same problem in the same place. Granted there's two different GUIDs I could choose from and I haven't tried both (I picked the Source Splitter), I'm still reasonably sure now that it's not the way the streams are demuxed that's causing the problem.

With that said, it appears Pistacho may have found a work-around. Not a fix, but still something usable in the short term for people who just want to get the movie done. All going well he'll share this info with Neuron2, or at least point him in the right direction (it sounds like it's something to do with using SW mode instead).

*ed: So this is interesting. ssifSource4 (first release) with its default settings works, aside from an issue I'm certain is the combiner which could be as a result of the cropped streams (testing with Pac1 - the extra issue occurs just after the one we've been troubleshooting and can be ignored). Changing the "intel_params" value, however, can make it trigger the problem:
The default "-d3d" is fine.
Changing to "-d3d -hw" is not fine, plus it runs slower, still uses SW and reverts from SDK v1.8 to v1.7.
Changing to "-d3d11 -hw" is not fine, reverts the SDK but does use HW.
Changing to "-hw" is not fine, reverts the SDK, still uses SW but runs better.
Changing to "-d3d11" caused VirtualDub to crash, probably because of whatever dismissed the Intel Media debug screen.
Changing to "" is fine (just uses System surfaces).

I'm gonna do another test with FRIM (since it gives identical results to DGMVC at the moment) and set it to software w/D3D surfaces. There's only one common element I can see here: everything which causes it to revert from v1.8 to v1.7 is problematic. According to the information I can find it should only revert when using hardware, pending a new driver (and possibly Broadwell's iGPU), which makes it weird it would do it while still claiming software mode. *end ed*

*2nd ed: 3:30 later and the results are inconclusive. Unfortunately the same issue presented but I have no way to determine whether setting "platform" to "sw" and "memory" to "d3d" results in FRIM using 1.8 instead of 1.7. *end*

*3rd ed: Nevermind. It was my fault the log wasn't being produced. Now that I have it logging I can see that it's still using 1.7 when set with those options, which explains why the issue persisted. *end*

*4th ed: Managed to get FRIM to use 1.8. Seems it just wanted a restart, as tends to be the fix for so many things. Will run Pacific Rim again tonight and report back. *end*

Also, has there been any word from Intel yet, Neuron2? When I got in touch with them over some driver issues they got back to me pretty quickly so I'm hoping they've at least acknowledged the issue. Seems they're the only ones who can really fix this by back-porting whatever they changed in 1.8 to 1.7.

[Guest]

Also, has there been any word from Intel yet, Neuron2? When I got in touch with them over some driver issues they got back to me pretty quickly so I'm hoping they've at least acknowledged the issue. Seems they're the only ones who can really fix this by back-porting whatever they changed in 1.8 to 1.7. I haven't posted about it yet at their forum, as I am currently focused on getting DGDecIM born. As I mentioned, anybody can post about it, and in any case, you have done more research about it than I have. I will be collecting all broken samples and posting about them but not for a while. Go ahead and post about it if you need immediate attention for it.

[Thalyn]

Gah! Got FRIM running again, the logs claim API v1.8, and it still has the errors. Even managed to get it running with the smaller fragments for quicker testing (apparently it wanted to use DLLs from at least 3 different locations) and they're glitching in FRIM where they don't in ssifSource4.

I... am at a loss.

[Guest]

Pistacho explains it in his thread:

http://forum.doom9.org/showthread.php?p=1669072#post1669072

He also tantalizes us with claims of 700fps decoding.

[pistacho]

Some had already realized this fact:
http://forum.doom9.org/showthread.php?p=1664548#post1664548

But it's also a fact that in this forum if you speak good of me or of my applications you become a loser... :D

[Thalyn]

Huh... interesting. I wonder if that means the issue continues into the 2014 SDK?

[jdobbs]

Some had already realized this fact:
http://forum.doom9.org/showthread.php?p=1664548#post1664548

But it's also a fact that in this forum if you speak good of me or of my applications you become a loser... :DWow. I hope you didn't mean that like it sounds...:confused:

[sef]

...you become a loser...

??? Do not understand..

..wants to talk about an older "discussion" between me & others members and him..

I remember, the "discussion" .. ;)

[Stereodude]

Wow. I hope you didn't mean that like it sounds...:confused:Well, he didn't exactly get a warm welcome (http://forum.doom9.org/showthread.php?t=170004).

[Nico8583]

I think pistacho wants to talk about an older "discussion" between me & others members and him, but it's past ;)

[jdobbs]

There's never a good excuse for bad behavior...

[Guest]

Guys, let's please stay on topic.

@pistacho

Don't tar everyone with the same brush. I have publicly praised and defended you and I'm sure many others also appreciate your work.

[Nico8583]

@neuron2 : Do you plan to release a version with "workaround" gives by pistacho ?

[Guest]

No, I won't back off to an older Intel Media SDK. Anyway, it is still broken for HW decoding. Better to get a proper fix from Intel. When I finish the DGDecIM basic functionality I will address problem streams.

[Nico8583]

Ok thanks :) DGDecIM will be released on another topic or here ?

[Guest]

You haven't noticed this thread?

http://forum.doom9.org/showthread.php?t=170237

[Nico8583]

Shame on me, I have not browsed this section... Thanks !
Edit : Does MVC will be included in DGDecIM or DGMVCSource will stay only decoder for MVC ?

[jdobbs]

You haven't noticed this thread?

http://forum.doom9.org/showthread.php?t=170237I'm glad you posted this link... I somehow missed that thread entirely.

[Guest]

It's weird. Doesn't everybody just hit Quick Links/Today's Posts every day?

Think of all the other things you're missing! :scared:

[Guest]

Does MVC will be included in DGDecIM or DGMVCSource will stay only decoder for MVC? At some point it will be added to DGDecIM.

[Nico8583]

Ok thanks :-) I'm following DGDecIM topic ;-)

[Nico8583]

I'm testing b22 but I had a problem : Unable to load dgmvcdecode.dll
So I've followed 3D topic and I've seen sef said it is necessary to install VC++ 2012 in order to dgmvcdecode works. And yes it works after install vcredist_x86.exe.
My question : is it possible to include dll with dgmvcdecode ? Or it's a particularity of VC++ 2012 ?
Thanks !

[Guest]

I'll look into that. Thanks for pointing it out. Does it apply to DGDecodeIM also?

[sef]

..Does it apply to DGDecodeIM also?

HI neuron2. No unnecessary. Although, I conclude only dgdecodeim_b2..

[Guest]

Hi sef! Thanks, it's probably just my linking options then. Ciao.

[qupfer]

Hi, what is the fasted (easiest) way to get the number of frames of a h264-video?

mediainfo doen't show it (yes, i switched to expert-mode).
At the moment, i create a avs-file for the "left.264" file (created by eac3to) and open it in virtualDub, skip to the last frame and note the number. But I think, this way is a little bit awkward :D

[Guest]

Things are different for elementary streams versus transport streams versus containerized streams. Specifically, what is the type of your video file? Also, is this for programmatic use by another application? What do you do with the number of frames?

If this is for counting frames to have the correct parameter to pass to one of the available MVC source filters, then any ad hoc method, such as yours, will suffice. I believe you can also use eac3to for counting frames. This will be mitigated when MVC support is added to DGDecIM.

[Sharc]

Workarounds which have been suggested to obtain the number of frames:
- open the files in MPC-HC, go to the end and press CTRL+G
- open a script in AvsPmod, start the internal player ad see the number of frames in the status bar
- get the duration from the playlist (e.g. with BdEdit or similar) and calculate the number of frames based on the framerate

[KreuzBlick]

@qupfer
You can open the h264-video with DirectshowSource() and use the property framecount().

[r0lZ]

I have received this PM from a user of BD3D2MK3D:
BTW, I noticed that you have a couple of libraries compiled with visual studio 2012 and starting _ENCODE.cmd it displays an error that avisynth cannot load dgmvcdecode.dll and breaks, but it doesn't display that popup message that it is missing msvcr110.dll. I've checked dgmvcdecode.dll with dependency walker and then saw that it is missing msvcr110.dll. Instaling VS 2012 redistributable fixed the problem.
I did not know that DGMVCSource requires a redistributable package, and it's obviously a bad thing (due to M$, not you).
Can you compile a static, standalone version of DGMVCSource ? If it's not possible, can you check if the dependencies are present, and if it's not the case, issue a meaningful error message ?
Or is it sufficient to copy msvcr110.dll in the same directory than DGMVCSource.dll ?

Thanks!

[Groucho2004]

I did not know that DGMVCSource requires a redistributable package, and it's obviously a bad thing
I just checked the latest DGMVCDecode.dll and it does not require the runtime.
Also, it's certainly not a bad thing to use dynamic linking with up to date runtime libraries. It's just annoying (IMO).

[Guest]

Earlier versions had the dependency. As Groucho2004 says, the latest one does not.

[r0lZ]

Oh, yes, sorry. For whatever reason, the version included with the beta of BD3D2MK3D was not the latest. I've downloaded the latest one, and now it's perfect.

[Sharc]

I re-downloaded DGMVCsource100b22 (dated 12.03.14) and found that the size of DGMVCdecode.dll is 402k. The version which I had on my HD is also 100b22 (dated 03.02.14) and has a much lower filesize of 62k only. Just wondering why there is such a difference.

[Groucho2004]

I re-downloaded DGMVCsource100b22 (dated 12.03.14) and found that the size of DGMVCdecode.dll is 402k. The version which I had on my HD is also 100b22 (dated 03.02.14) and has a much lower filesize of 62k only. Just wondering why there is such a difference.
Probably one of neuron2's silent slipstream updates where he changed from dynamic to static linking. Static linking requires all necessary code that usually resides in the runtime libraries to be linked into the binary.

[Sharc]

Probably one of neuron2's silent slipstream updates where he changed from dynamic to static linking. Static linking requires all necessary code that usually resides in the runtime libraries to be linked into the binary.
Oh I see. Yes, this possibly explains it.

[CaBleman]

'lo there,

sorry if this counts as a crosspost; and I don't know if it is directly related to DGMVCsource, but maybe it's of interest:
Please see a description of symptoms and error messages here in this entry (http://forum.doom9.org/showthread.php?p=1697429#post1697429) (and others) in the BD3D2MK3D thread...

In short: with hw=0 or hw=2 in the function call, it seems that blank/black frames are being decoded & served. With hw=1 it works fine.
Could this be due to the relatively new Haswell Refresh processor I5 4590S that I operate under Win 8.1?

Any hint is appreciated!

thx & bye,

CaBleman

BTW, I'm a happy "customer" for DGDecNV which I use on another system (Laptop with nVidia GFX)... ;)

[Selur]

If you want to contact Donald Graft you should post in his forum (http://rationalqm.us/board/index.php), which is afaik atm. the only official source for DG* support from Donald himself.

[tebasuna51]

Please guys, peace.

I removed 2 post because forum rule "4) Be nice to each other..."

I can't understand for what we need reopen this thread after 5 years.

And I removed 3 post because rule "8) No cross posting. Post your message once..." https://forum.doom9.org/showthread.php?p=1890366#post1890366

[tebasuna51]

I let the link to BD3D2MK3D thread to be know for BD3D2MK3D users.

If you want I can undelete the post here and delete the BD3D2MK3D posts, but the rule 8 is clear.

[Atak_Snajpera]

Because r0lZ is violating my licensing and using my software without permission and I want people to know that.

I object to your censorship.

Sue him ! :)