const Node *pNode
to typename const List<T*>::Node *pNode
as well as changing the headers from glload/wgl_all.h to glad/glad_wgl.h for the interops. This allows the code to compile and the VideoTexture sample runs, but the VideoPlayback sample crashes with an exception every time I run it.
The exception seems to be related to calls to ->AddRef(), which is a part of the Win32 COM API:
HRESULT GetItem(typename const List<T*>::Node *pNode, Ptr* ppItem)
{
Ptr pItem = NULL;
// The base class gives us the pointer without AddRef'ing it.
// If we return the pointer to the caller, we must AddRef().
HRESULT hr = List<Ptr>::GetItem(pNode, &pItem);
if (SUCCEEDED(hr))
{
assert(pItem || NULLABLE);
if (pItem)
{
*ppItem = pItem;
(*ppItem)->AddRef();
}
}
return hr;
}
Visual Studio gives me an error output:
'SimplePlayBack.exe' (Win32): Loaded 'C:\Windows\System32\mfmp4srcsnk.dll'.
Exception thrown at 0x00007FFD83C94B59 in SimplePlayBack.exe: Microsoft C++ exception: bad_hresult at memory location 0x000000000014DD50.
Exception thrown at 0x00007FFD83C94B59 in SimplePlayBack.exe: Microsoft C++ exception: bad_hresult at memory location 0x000000000014DD28.
Exception thrown at 0x00007FFD83C94B59 in SimplePlayBack.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
Exception thrown at 0x00007FFD83C94B59 in SimplePlayBack.exe: Microsoft C++ exception: bad_hresult at memory location 0x000000000014DD28.
After a few times stepping through the code, the issue is at AddRef() in GetItem().
This is getting a little bit further into the weeds of how Windows works than I’m comfortable with, so I’ve gotten stuck and thought I’d throw up a bat signal for some assistance… does anyone know exactly how this Windows API works, and why this call would be causing exceptions in the player?
My latest working version of Cinder-WMFVideo is available on github.
This may be a silly question, but does ignoring the exception still allow for the playback to occur? I find that Cinder-WMFVideo will also often Exceptions in my own codebase, but ignoring them doesn’t seem to impact execution.
For the record, I’m sure it’s not healthy to just outright ignore them, but they’re thrown in areas that I have little understanding of, and not found the time to further investigate.
If I ignore these exceptions, I’ll eventually get a read access violation exception… so it seems like I need to figure out what’s going on here, unfortunately
It might be worthwhile giving other forks of the WMFVideo code a shot. @paul.houx has done a fair amount of work iirc, and his branch would be the first I’d give a shot just to see if anything changes.
I also recall @paul.houx taking a break from having anything to do with the apparent nightmare that is working with accelerated video decoding in Windows if the goal is to eventually get the output to an OpenGL texture. So if nothing seems to budge with WMFVideo there are other possible options to explore:
aaaaaand I just noticed you’ve commented on that thread, so you’re well aware of it
The error seems to happen in EVRCustomPresenter::SetMediaType when the handler is fetching the Video Samples; I haven’t dug deeper down the rabbithole yet. I bailed and tried to get VLC or FFMPEG working as a video player, but both of those have also resulted in deep rabbitholes…
Many of the helper functions are lifted directly from the Windows Media Foundation examples from 2016, so it seems most likely to me that something changed in the Windows API or COM Interface, though that’s really just a hunch.
I may take a deeper look this week at it; if you find another video player that’s working out-of-the-box with the latest VS2019/C++17, I’d love to take a look…
Ok mate, I think I’ve figured it out. I had decided to revert to an older version of cinder and visual studio that didn’t have these issues for the project I’m just starting and everything was chugging along fine until I accidentally updated the ciWMFVideoPlayer and suddenly I started seeing the access violation again in the same location.
I had a quick look at at what was different between the two versions and all I could see were the aforementioned changes to linklist.h that updated some of the typedefs used. Not sure how I didn’t see it originally but it was one of those classic C++ vtable-y footguns where the Node typedef was not correctly specified to use the correct T, which would explain why the error was in such a strange place. Honestly I’d have expected the compiler to catch it but it didn’t so here we are.
Long story short, there’s a working fork on my github here. I submitted an issue to the Potion guys erroneously yesterday so I’ll go and clear that up with them, and if they want to merge my changes into their vs2019 branch that’s up to them.
I just pulled it and it’s working great for me as well. Surprised that the compiler didn’t catch it, but totally jazzed that we have working video again!
