It doesn't matter if I use the prebuilt library or rebuild it against various .net versions and/or cpu targets. This happens in the DxPlay and PlayWnd samples too, so it's not just my app. If I target 3.5 with the samples, it works fine. So whether it's the library or the sample, I'm not sure.
I also get an SEHException frequently when my app or the samples close if I've played a video. I'm guessing when I can figure out how to solve the video distortion problem, this will go away too.
I'm on Win7 x64 FWIW, and I'm testing with a .mov file.
Has anyone gotten these samples to work with .net 4, and if so, how did you do it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Our lib is a really thin layer over the unmanaged DirectShow API. The .NET version shouldn't make any differences except perhaps if you wrote managed code called by unmanaged components like Sample Grabber's callbacks, for exemple.
I suggest you to test your code on a different computer (or a virtual machine). Possibles causes of your problems can be rooted to a DirectShow stack imbalance due to a codec pack (never use them) or a bitness problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't even think about it being codec related. Of course, I don't have any problem playing the video in other apps but perhaps directshow is less tolerant than the other apps I've used. Good idea.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Weird stuff. It looks like it only happens when running in the debugger! I'm using VS 2010. If I run my app, or either sample, outside of the debugger they work fine. If I run any of them in the debugger, messed up video and SEHException on shutdown.
Certainly that shouldn't happen. Any clues as to why it would have trouble when run in the debugger, and by extension how to fix it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some of the samples DO contain DsROTEntry, which is why I asked. Also, the DsROTEntry in these samples is sometimes inside an "#if DEBUG", which also seems to match your description.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, yeah I see what you're talking about now. I have the directshow library built in release mode and the dsrot stuff is commented out of my app, and it still happens. So that's not it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It doesn't matter if I use the prebuilt library or rebuild it against various .net versions and/or cpu targets. This happens in the DxPlay and PlayWnd samples too, so it's not just my app. If I target 3.5 with the samples, it works fine. So whether it's the library or the sample, I'm not sure.
I also get an SEHException frequently when my app or the samples close if I've played a video. I'm guessing when I can figure out how to solve the video distortion problem, this will go away too.
I'm on Win7 x64 FWIW, and I'm testing with a .mov file.
Has anyone gotten these samples to work with .net 4, and if so, how did you do it?
Our lib is a really thin layer over the unmanaged DirectShow API. The .NET version shouldn't make any differences except perhaps if you wrote managed code called by unmanaged components like Sample Grabber's callbacks, for exemple.
I suggest you to test your code on a different computer (or a virtual machine). Possibles causes of your problems can be rooted to a DirectShow stack imbalance due to a codec pack (never use them) or a bitness problem.
I didn't even think about it being codec related. Of course, I don't have any problem playing the video in other apps but perhaps directshow is less tolerant than the other apps I've used. Good idea.
Weird stuff. It looks like it only happens when running in the debugger! I'm using VS 2010. If I run my app, or either sample, outside of the debugger they work fine. If I run any of them in the debugger, messed up video and SEHException on shutdown.
Certainly that shouldn't happen. Any clues as to why it would have trouble when run in the debugger, and by extension how to fix it?
Is your code using DsROT? While useful for debugging, it can have unfortunate side effects.
No. Remember, this problem happens with the samples too.
Some of the samples DO contain DsROTEntry, which is why I asked. Also, the DsROTEntry in these samples is sometimes inside an "#if DEBUG", which also seems to match your description.
Sorry, yeah I see what you're talking about now. I have the directshow library built in release mode and the dsrot stuff is commented out of my app, and it still happens. So that's not it.