Access violation with ofxWMFVideoPlayer

hi friends,
my app needs to decode and display a few video files (nothing too fancy, I suppose) but this is turning out to be harder than expected. The OSX version runs perfectly fine, but with Windows (10) I can’t get it to work.

I tried the supplied ofVideoPlayer but it hits quite heavily on the CPU, so I had to switch to an addon, ofxWMFVideoPlayer. The behavior is… strange. It runs, most of the times, but when the application closes it crashes (sometimes this happens even when stopping a video and loading a different file).

The access violation happens in PresentEngine.cpp, D3DPresentEngine::releaseSharedTexture(), but I suspect the real cause is something weird happening at setup, in createSharedTexture. There a call to wglDXXOpenDeviceNV returns 1.

Not NULL, that would mean a failure, but neither a valid pointer… what’s a “1” supposed to mean? Then the videos seem to work, but when the resources have to be released of course that 1 leads to an access violation.

I tried to understand what that call does but I found a whole world that’s way to complex for me at the moment :frowning:

Did somebody encounter the same problem before, and may be find a solution? Thank you!


I should probably update the addon and ill look into the issues your having.

Do you know which fork of ofxWMFVideoPlayer you used?

That would be great. I first tried the “official” branch (from secondstory, the one listed in ofxAddons), then your branch but unfortunately the errors persisted.

I’ll be glad to help if you want to investigate a little, a reliable video player for Windows is very much needed.


The return value is valid at least according to this old opengl thread:

I think I ran into this problem before and iirc it was because the handle was already closed or something along those lines, granted its been a few years since I last looked at it. I thought I fixed it but maybe I never updated the repo…

Try the new update to my branch, I actually just merged in something others worked on but it has to do with the texture locking and unlocking. Since you can create the crash its more of an experiment to see if it works or possibly rule out the texture handle.

I am going to look closely at this branch as well: