I am trying to get ofxHapPlayer to work with liquidzym’s 64bit openframeworks (https://github.com/liquidzym/openframeworks_X64/tree/VS2013_X64).
Unfortunately, the HapSupport.h complains about not being able to find QTML.h and Movies.h
Has anyone been able to do this?
EDIT: Sorry, should confirm - I am on windows using visual studio
Quick update - I’ve also tried to do this using the 0.9 release candidate but it looks like video in windows has been changed to directshow and quicktime does not play nicely.
So I am guessing this is a quicktime/windows 64bit issue?
The problem is quicktime is not 64 bit compatible, on any platform. Is there a reason you need to build it for 64 bit? We did move over 0.9.0 to support 64 bit pretty much across the board but as for compatibility of addons that’s more the maintainers responsibility than ours (imagine the legacy issues if every addon that hasnt been updated in years still had to work…)
Have you tried ofxWMFPlayer? If you are just trying to playback HD videos people have had pretty decent success but certain functionality does not work (like playing a video backwards)
I have the most up to date branch - https://github.com/DomAmato/ofxWMFVideoPlayer
Thanks for the reply. I thought that was the case with QT. I am just thinking that 64bit would give me better performance.
I am trying the play back a 5760 x 1080 video (or 3 full HD videos in a row, in sync) and be able to change the speed of playback.
The hap player is almost there but I can see a slight judder when changing the speed, especially when the video has been looping for a while.
The videos are very large (hap versions are 50GB each for full HD).
I will take a look into ofxWMFVideoPlayer and let you know what I find.
doing a brief investigation it appears there is a directshow version of Hap so it should be possible to enable 64 bit if the addon is updated. There is also an AVFoundation one so 64 bit on mac should also be doable. The google code is archived so I’m migrating it to github
Thanks for the help. ofxWMFVideoPlayer running 3 x full HD mjpeg files is doing the job nicely.
Quick update on this.
Unfortunately, ofxWMFViodePlayer doesn’t seem to be stable enough for me. I left it running the videos overnight a few times and came back to crashes. I also noticed that the setSpeed control can take a very long time for the speed to actually change (sometimes I’d change the speed by .1 and would have to wait for 30 seconds for it to take effect). Maybe mjpeg is not the best format for this?
So, I switched back to ofxHapPlayer but this time converted my videos to HAPQ at 30fps (they were 60fps before). This seems to be working nicely again.
Another thing I noticed is ofDirectShowPlayer from the nightly build is allowing me to scrub through the videos (using setPosition) at different speeds quite nicely.
For WMFVideoPlayer it supports more formats but there are known issues with it, like playing in reverse. Which fork were you using and can you describe the errors?
The direct show player is nice and less of a headache than using WMF (from a programmers standpoint) though there are similar limitations like its more limited codec support, if using a mov, mp4, avi you will need to install codecs to support them. There is hardware acceleration that is available to both but neither take advantage of that unfortunately, not currently at least
I’ve been using ofxWMFVideoplayer with MP4/WMV quite successfully and I’d be curious to hear what issue you got.
DomAmato> Actually ofxWMFVideoplayer uses hardware acceleration, that’s the whole point of the player (wmf renders directly to a d3d texture that is hw accelerated, and then the texture is shared between d3d and opengl to avoid costly transfer GPU->RAM->GPU)
I thought ofxWMFVideoPlayer doesnt fully utilize DXVA 2 and instead uses a variation of the D3D presentation engine from the microsoft samples. I actually never dug very deep into the presentation engine tbh so i could very well be wrong on that. I thought you stopped working on the video player as well since I have an open pull request on the github that adds in some features like playback rate control and async video loading that the clouds documentary people added in.
I will certainly dig into it a little more and post my findings but at the moment I need to press on with the project.
Worth noting that I was using mjpeg so I could manipulate the speed easier. I never really tried mp4 or wmv.
Dom > So what happened was I cleaned up my working version of the addon, made a bunch of test and published it on github. I don’t have much time to maintain the public facing one and integrating other people pull request would require me to make sure everything still works (as the code is endorsed by my employer it just gives me a bit of a case of cold feet).
Regarding DXVA2, you may be right actually, and it may only be doing DXVA1 (I assumed everything was working magically) I’m no DX expert; but I’m going to investigate that matter more! I don’t want to invade this topic any longer but feel free to reach me over PM if you want to continue the discussion!
Edit: I ran DXVA Checker on my laptop, and it seems like both windows media player and my empty_example.exe playing an mp4 run the same DXVA calls/events
Feel free to continue the conversation here guys, if it’s helpful to people.
I had another look at the WMF player again today and switched my method of working. I have now split the videos into smaller pieces (I was playing 3x12 minute videos but now I have around 18x1-3 minute clips - 3 of which are played simultaneously) and I am using the method mentioned by obviousjim here to play them back seamlessly. It seems so far to be a lot more stable.
This method works fine when playing back at a rate of 1 but when I speed up to 3 I get a very clear pause when the new videos starts to playback. Any ideas on removing that pause?
Since you are changing the playback rate I am assuming you are using my fork. Are you loading the files asynchronously or not because I pulled in the CLOUDS guys changes to my fork but you can flag it to load asynchronously or not , it doesn’t by default.
ObviousJim’s approach is actually a pretty good way but since you only have 18 short videos you might just want to buffer them all into memory by having 18 video player instances. That way you never have to reallocate memory and the player instances persist between playbacks. You can just load them into a vector/array and however you choose to playback the videos just draw the currently playing ones. Other than that you can start playing the background movie a little before the switch and then set its position to 0 right as the new video is drawn. Essentially priming the decoding buffer.
Careful with setting the playback rate too as there are actual limits to the playback speed, if you are’t getting a warning you are fine but Media Foundation does a check for supported playback rates during the rate transition and if its not supported without thinning will log an error and fail to change speeds. I would also generally recommend against thinning as it essentially drops a bunch of frames in order play at the requested rate, seems to be the only way to get it to play in reverse though which kinda sucks
That’s right, I’m using your fork.
I am loading files asynchronously halfway though the previous video and starting playback (and setting speed) once the video ends. It seems the delay is when the next video starts to play.
I’ll look into loading all into ram and see how that goes.
I am using thinning with the speed changes because I was getting the error message and the speed was not changing without it. I’ve not experienced any dropped frames though.
Thats good to hear about the thinning, I think it might depend on the format for how many frames get dropped and I really only tested it a few times in forward playback. Mostly I was trying to get reverse to play nicely. Certainly open to feedback on how things go
Ok here is something weird - when I load all 18 videos at the start and use a variable to signify which one to update() and draw() - I get very strange speed results whereby every speed from 1 - 1.9 looks fine, 2 drops to be a lot slower, then 2.1 goes fast again.
It seems to be that just by creating more instances of ofxWMFVideoPlayer (and only loading 3 of them with videos) is enough to cause this.
Any ideas why that would happen?
I wonder if 2 is the cusp of thinning and non thinning playback. Is there any warnings or errors that pop up in the log? There should be a general catch for error logging and should output the full HRESULT error if there is one. its strange that it would only occur at one speed and not be consistent after that threshold.
Like my hunch would be a stream or buffer problem but I can’t really say without testing things myself
How did you solve your initial problem with the QTML and Movies headers?
Hmm, I don’t remember now. I think I ended up using the 32bit version of oF (0.8.4 or something IIRC).