[RESOLVED] DGMVCSource b22 and VC++2012
Re: [RESOLVED] DGMVCSource b22 and VC++2012
Yes, I think so too. And anyway, I suppose that using the last version is always better. I'll ask him to do it, when I will be sure that the Dragon Gate bug is fixed.
Thanks anyway for your hard work. Will you release a new version, non-beta, or should I consider that the third beta is the official release (if the DG bug is fixed of course)? I will need to update it in the BD3D2MK3D distribution package...
Thanks anyway for your hard work. Will you release a new version, non-beta, or should I consider that the third beta is the official release (if the DG bug is fixed of course)? I will need to update it in the BD3D2MK3D distribution package...
Re: [RESOLVED] DGMVCSource b22 and VC++2012
I made an official release. The only difference from what you have is the version number in the DLL properties.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
OK, the Dragon Gate test is finished and it's OK. ![Smile :-)](./images/smilies/icon_e_smile.gif)
Unfortunately, I have no news from Frank. We should test the decoder on his Dell too, but anyway, I think that this version is certainly better than the previous official release. I hope that frank will confirm that it works on his Dell tonight or tomorrow.
Thanks again!
![Smile :-)](./images/smilies/icon_e_smile.gif)
Unfortunately, I have no news from Frank. We should test the decoder on his Dell too, but anyway, I think that this version is certainly better than the previous official release. I hope that frank will confirm that it works on his Dell tonight or tomorrow.
Thanks again!
Re: [RESOLVED] DGMVCSource b22 and VC++2012
Good news guys, and thanks a lot to Donald !
I'm away from my home and I could see results thursday only...
Donald, could you also update DGDecIM if all is OK ?
I'm away from my home and I could see results thursday only...
Donald, could you also update DGDecIM if all is OK ?
Re: [RESOLVED] DGMVCSource b22 and VC++2012
@r0lZ
You're welcome, sir.
You're welcome, sir.
I will. Also, it would be nice to find that double-rate deinterlacing works properly with the new MSDK and driver. We shall see. Who knows, I may get some energy and add MVC support, so we will have proper random access for MVC.Nico83500 wrote: Donald, could you also update DGDecIM if all is OK ?
Re: [RESOLVED] DGMVCSource b22 and VC++2012
I have received a PM from Frank, that confirms that your latest beta works perfectly on (almost) all his PCs. Here is his PM:
![Wink ;-)](./images/smilies/icon_e_wink.gif)
I will now try to convince videofan3d to recompile his FRIMSource, and I'll release an update of BD3D2MK3D with the latest MVC decoders. BTW, have you already released the final version of DGMVCDecode? If yes, where is it? I've found only the third beta.
P.S.: Random access for MVC would be nice!
Everything is fine now! What a beautiful world!dgMVCsource b23 works properly. He got it!
I tested Pacific Rim, that is the hardest test. OK.
Exception: Intel 7, 2nd gen, igfx3000, Sandy Bridge (Dell XPS): same glitches with hardware decoding. But the rest is ok.
That is because hardware decoding depends on Intel drivers. And for this 2nd generation there are no updates.
So software decoding is OK on all my PC.
Hardware decoding too with one exception because of outdated drivers.
[...]
____
frank
![Wink ;-)](./images/smilies/icon_e_wink.gif)
I will now try to convince videofan3d to recompile his FRIMSource, and I'll release an update of BD3D2MK3D with the latest MVC decoders. BTW, have you already released the final version of DGMVCDecode? If yes, where is it? I've found only the third beta.
P.S.: Random access for MVC would be nice!
Re: [RESOLVED] DGMVCSource b22 and VC++2012
Good news, thank you.
http://rationalqm.us/mine.html
You may need to refresh the page.
Links on this page have been updated:r0lZ wrote:BTW, have you already released the final version of DGMVCDecode? If yes, where is it? I've found only the third beta.
http://rationalqm.us/mine.html
You may need to refresh the page.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
OK, I got it. Thanks.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
Thanks for DGDecIM, I'll try it when you will release it ![Wink ;)](./images/smilies/icon_e_wink.gif)
And thanks for official release, no changes between b23 and official release (except versionning) ?
![Wink ;)](./images/smilies/icon_e_wink.gif)
And thanks for official release, no changes between b23 and official release (except versionning) ?
Re: [RESOLVED] DGMVCSource b22 and VC++2012
b23 *is* the official release. There is no change other than versioning compared to the informal betas I had given you.Nico83500 wrote: no changes between b23 and official release (except versioning) ?
Re: [RESOLVED] DGMVCSource b22 and VC++2012
Ok thanks ![Wink ;-)](./images/smilies/icon_e_wink.gif)
I can confirm movies are bug free with the b23 on my system.
![Wink ;-)](./images/smilies/icon_e_wink.gif)
I can confirm movies are bug free with the b23 on my system.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
Hi Donald. Sorry to revive this old thread, but I've tried to update libmfxsw32.dll to the latest version, and DGMVCSource seems to produce only black frames with some BDs. It takes a long time before decoding the first frame, and then all frames are black (and the "decoding" is extremely fast!)
The version of libmfxsw32 I've tried is v6.15.6.2, dated 23 sep 2015 and taken from INDE 2015 update 2.1 (NOT update 2 RTM) "w_inde_2015.2.048.exe". The last version that worked fine with your plugin (and FRIMSource) was v6.14.11.28. Since I don't have the right CPU, I can't test the library in hardware mode. Personally, I'm happy with v6.14.11.28, but I suppose that the latest version may be better, or even necessary for correct operation in hardware mode with new CPUs, and therefore I would like to update it in the distribution of BD3D2MK3D.
Strangely v6.15.6.2 works fine with FRIMSource (without update). Therefore, I guess that there is probably only a little thing to do to make DGMVCSource compatible with the latest version. Perhaps just a new compilation? Note also that the latest version works fine with many BD3Ds, so there might be an incompatibility occurring only with some BDs.
Here is a sample: http://download.videohelp.com/r0lZ/tmp/ ... .15.6.2.7z
Any chance to have an update?
Thanks in advance!
[EDIT]
Just tried your plugin with libmfxsw32 v6.15.3.12 (from INDE update 2 RTM, 22 apr 2015) and it works fine. So perhaps the black frames are caused by a bug in the latest Intel library. Anyway, I will use v6.15.3.12 for BD3D2MK3D, at least while there is no new version of your plugin or of the libmfxsw32 DLL. Therefore, a fix is less urgent, but you may want to consider it anyway.
The version of libmfxsw32 I've tried is v6.15.6.2, dated 23 sep 2015 and taken from INDE 2015 update 2.1 (NOT update 2 RTM) "w_inde_2015.2.048.exe". The last version that worked fine with your plugin (and FRIMSource) was v6.14.11.28. Since I don't have the right CPU, I can't test the library in hardware mode. Personally, I'm happy with v6.14.11.28, but I suppose that the latest version may be better, or even necessary for correct operation in hardware mode with new CPUs, and therefore I would like to update it in the distribution of BD3D2MK3D.
Strangely v6.15.6.2 works fine with FRIMSource (without update). Therefore, I guess that there is probably only a little thing to do to make DGMVCSource compatible with the latest version. Perhaps just a new compilation? Note also that the latest version works fine with many BD3Ds, so there might be an incompatibility occurring only with some BDs.
Here is a sample: http://download.videohelp.com/r0lZ/tmp/ ... .15.6.2.7z
Any chance to have an update?
Thanks in advance!
[EDIT]
Just tried your plugin with libmfxsw32 v6.15.3.12 (from INDE update 2 RTM, 22 apr 2015) and it works fine. So perhaps the black frames are caused by a bug in the latest Intel library. Anyway, I will use v6.15.3.12 for BD3D2MK3D, at least while there is no new version of your plugin or of the libmfxsw32 DLL. Therefore, a fix is less urgent, but you may want to consider it anyway.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
I'll look into it.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
I installed update 2.1 and find that DGDecIM still works fine. But I duplicated your issue with DGMVCDec and your stream.
Can you please give me a sample set that works with 2.1? Then I can compare what happens with the two in the debugger. Thanks.
Can you please give me a sample set that works with 2.1? Then I can compare what happens with the two in the debugger. Thanks.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
The library appears to be under-reporting the number of surfaces required for decoding. If I allocate the suggested amount plus 4, then the software decode works. But this workaround does not fix HW decoding. Does FRIM do only software decode? If not, I wonder if it too is failing in HW mode.
I'll tinker some more with HW decoding. If I can't get a workaround for that would you still want the SW workaround?
I'll tinker some more with HW decoding. If I can't get a workaround for that would you still want the SW workaround?
Re: [RESOLVED] DGMVCSource b22 and VC++2012
Well, I don't know. If you're sure it's a bug in the Intel lib, I suppose it will be fixed soon, and I can skip this version. However, if the fix is simple to implement and has no consequence with the previous correct and forthcoming versions, maybe it is worth doing it, even if the fix works only in SW mode. But I suppose that I will have to distribute the last version that works in both modes anyway. So, I don't need the fix, and it's up to you.
BTW, I wonder why DGDecIM has no problem. Do you allocate anyway more surfaces than theoretically required? If it's the case, why don't you do the same thing with DGMVCDecode?
FRIM does hw decoding too, but I don't know if it fails with v6.15.6.2 in hw mode. AFAIK, nobody has reported problems with that version, in sw or hw mode, with FRIM, DGMVCDecode or DGDecIM. I suppose that the 3DBD that has caused the problem is a rare case and/or most peoples use an older Intel library.
Can you please notify the bug to the guys at Intel? You will be able to explain the problem much better than me. (Of course, you can give them the link to the sample if you wish.)
Thanks anyway for your investigation.
BTW, I wonder why DGDecIM has no problem. Do you allocate anyway more surfaces than theoretically required? If it's the case, why don't you do the same thing with DGMVCDecode?
FRIM does hw decoding too, but I don't know if it fails with v6.15.6.2 in hw mode. AFAIK, nobody has reported problems with that version, in sw or hw mode, with FRIM, DGMVCDecode or DGDecIM. I suppose that the 3DBD that has caused the problem is a rare case and/or most peoples use an older Intel library.
Can you please notify the bug to the guys at Intel? You will be able to explain the problem much better than me. (Of course, you can give them the link to the sample if you wish.)
Thanks anyway for your investigation.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
It happens only for MVC decoding.r0lZ wrote: BTW, I wonder why DGDecIM has no problem. Do you allocate anyway more surfaces than theoretically required? If it's the case, why don't you do the same thing with DGMVCDecode?
Based on my past experience with Intel, it would just be a waste of my time.Can you please notify the bug to the guys at Intel? You will be able to explain the problem much better than me. (Of course, you can give them the link to the sample if you wish.)
Re: [RESOLVED] DGMVCSource b22 and VC++2012
OK, thanks anyway.
Will you do an update or should I still distribute the current version of DGMVCDecode with BD3D2MK3D ?
Will you do an update or should I still distribute the current version of DGMVCDecode with BD3D2MK3D ?
Re: [RESOLVED] DGMVCSource b22 and VC++2012
Let's stick with the current version for now. If you want to include the v6.15.3.12 DLL that should be OK.
I'm not aware of anything important for 3D stuff being fixed in the latest INDE.
I'm not aware of anything important for 3D stuff being fixed in the latest INDE.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
OK. I hope that the next version of the Intel lib will be bug free. I prefer to be up to date anyway. But you're right. It's not urgent, and the MVC decoder works perfectly with older versions.
Thanks again.
Thanks again.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
Just to let you know, I've just tested the new libmfxsw32 v7.15.10.28 (from the intel_media_sdk_2016.msi) and it produces still the black frames with DGMVCSource.
Pity.
Pity.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
Hi Donald.
Statula (an user of BD3D2MK3D) has reported the problem of the black frames with GDMVCSource and a recent version of the Intel decoder installed with the driver for his hardware. This time, the BD causing problem is Jurassic World. So, it appears that indeed, the hw lib has the same bug than the sw lib, and that the problem originally noticed with Creature from the Black Lagoon happens also with other 3DBDs. However, Statula has also tested FRIMSource, and FRIMSource has no problem, even in hw mode. Also, Pistacho has replied to the thread that his MVCSource has no black frames problems. (I haven't tested it.) Therefore, it seems that there is a way to fix the bug, even when the latest hardware libs are used.
So, I come back with this. Can you try to fix the bug or implement a workaround? Perhaps it is sufficient to increase the number of surfaces? You wrote previously that that will not be sufficient in hw mode, but there must be a way to use the new libmfxhw32.dll without problem, since two decoders can do it. I can't help you, but I'm sure the author of FRIMSource will accept to help, if you need some additional info.
Anyway, thanks for considering my request.
Statula (an user of BD3D2MK3D) has reported the problem of the black frames with GDMVCSource and a recent version of the Intel decoder installed with the driver for his hardware. This time, the BD causing problem is Jurassic World. So, it appears that indeed, the hw lib has the same bug than the sw lib, and that the problem originally noticed with Creature from the Black Lagoon happens also with other 3DBDs. However, Statula has also tested FRIMSource, and FRIMSource has no problem, even in hw mode. Also, Pistacho has replied to the thread that his MVCSource has no black frames problems. (I haven't tested it.) Therefore, it seems that there is a way to fix the bug, even when the latest hardware libs are used.
So, I come back with this. Can you try to fix the bug or implement a workaround? Perhaps it is sufficient to increase the number of surfaces? You wrote previously that that will not be sufficient in hw mode, but there must be a way to use the new libmfxhw32.dll without problem, since two decoders can do it. I can't help you, but I'm sure the author of FRIMSource will accept to help, if you need some additional info.
Anyway, thanks for considering my request.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
You could be right, of course. Resolving it would be a nontrivial project for me and the other authors do not in fact share their methods (I have tried in the past). But the main thing for me is I have no motivation about it. I'm mostly doing physics research these days, and Intel support is essentially non-existent. So let me ask you, before I devote any time to it, why is it so important to have DGMVCSource, when you have FRIMSource and MVCSource? It seems to me that it would be easier to just incorporate anything useful I have done feature-wise in DGMVCSource into FRIMSource or MVCSource.
Re: [RESOLVED] DGMVCSource b22 and VC++2012
Well, as you know, Pistacho's MVCSource cannot be distributed with BD3D2MK3D (or any other software) and doesn't work without installing his BDtoAVCHD. I don't want to force the users to install that ad supported program to use mine. Therefore, MVCSource is not and will never be an option.
FRIMSource is free and already distributed with BD3D2MK3D, but several peoples have reported problems in the past. I have never been able to verify them, but your program has always worked correctly for everybody, and I have used yours almost exclusively. It is still the default MVC decoder for BD3D2MK3D, because I know and trust it. It's a pity that the recent Intel libs do not work as expected.
Of course, I can remove your plugin from the BD3D2MK3D distribution and use only FRIM, but since it is possible that FRIM has other bugs that your plugin doesn't have, it would be a pity. Keeping both is a good safeguard in case of new problems (for example due to a new bug in a forthcoming version of the intel libs.)
I think also that it is better for you if your plugin works well in all circumstances, regardless of its usage in my program. But that's up to you. BTW, you wrote previously "I installed update 2.1 and find that DGDecIM still works fine. But I duplicated your issue with DGMVCDec and your stream." So, I suppose that the solution is already in the code of DGDecIM and that it should not be so difficult to implement it in DGMVCDecode (although I understand that finding what subtle difference is the cause of the bug can take a long time).
I know that Pistacho will probably refuse to share his code or even explain his method. He has always taken the programs and knowledge of the other programmers and never shared his sources or knowledge. But I think that videofan3d will accept if he has some time to spend on this. I can't be sure however. I can ask him if you wish.
Anyway, I don't want to force you to do it if you have other things to do or if you're not interested in that plugin any more. I will accept your decision, but I hope you'll devote some time to try anyway.
Thanks anyway for what you did, and what you will do!![Wink ;-)](./images/smilies/icon_e_wink.gif)
FRIMSource is free and already distributed with BD3D2MK3D, but several peoples have reported problems in the past. I have never been able to verify them, but your program has always worked correctly for everybody, and I have used yours almost exclusively. It is still the default MVC decoder for BD3D2MK3D, because I know and trust it. It's a pity that the recent Intel libs do not work as expected.
Of course, I can remove your plugin from the BD3D2MK3D distribution and use only FRIM, but since it is possible that FRIM has other bugs that your plugin doesn't have, it would be a pity. Keeping both is a good safeguard in case of new problems (for example due to a new bug in a forthcoming version of the intel libs.)
I think also that it is better for you if your plugin works well in all circumstances, regardless of its usage in my program. But that's up to you. BTW, you wrote previously "I installed update 2.1 and find that DGDecIM still works fine. But I duplicated your issue with DGMVCDec and your stream." So, I suppose that the solution is already in the code of DGDecIM and that it should not be so difficult to implement it in DGMVCDecode (although I understand that finding what subtle difference is the cause of the bug can take a long time).
I know that Pistacho will probably refuse to share his code or even explain his method. He has always taken the programs and knowledge of the other programmers and never shared his sources or knowledge. But I think that videofan3d will accept if he has some time to spend on this. I can't be sure however. I can ask him if you wish.
Anyway, I don't want to force you to do it if you have other things to do or if you're not interested in that plugin any more. I will accept your decision, but I hope you'll devote some time to try anyway.
Thanks anyway for what you did, and what you will do!
![Wink ;-)](./images/smilies/icon_e_wink.gif)