Closed Gorgull closed 9 years ago
Actually the way it is set up is that in texture mode it uses an FBO that is only updated when a new frame is complete (it used to have far worse tearing)
If you want to email me a link to your movies (jvcleave on gmail) I could try them out and maybe see if there are any OMX tweaks that help
Thanks for your answer Jason. I'm now sending you some test movies of mine. I've been through your ofxOMXPlayer code and figured out about the fbo. Using a fbo kind of helps but I assume OMXPlayer code updates the EGLImage (therefor the texture) asynchronously, am I correct? Do you have more information about the way OMXPlayer actually updates the EGLImage, and if there's a way to lock or even better triple-buffer the component, in order to avoid any tearing? I was actually wondering if using a double-fbo would be a acceptable temporary solution?
Hi there,
Sorry to come back with this problem again, but even though the tearing problem I've been describing diminishes together with the fill-rate (thus the resolution), it still happens randomly, and the project I'm working on won't tolerate any glitch.
In addition to this tearing problem, I've also experienced stutter right after looping, which I could temporarily avoid by checking out an old revision (7e0e8f5b).
Besides the slow performances, none of these problems happens when using the standard ofVideoPlayer, which eliminates the possibility of my movie files being the cause of those problems.
I've tried to double-buffer the fbo that's in ofxOMXPlayer but since update() happens in the same thread as getTextureReference(), it doesn't make any difference.
My guess is that ofxOMXPlayer's internal texture (that seems to be linked to an EGLImage) is somehow updated while being rendered in the fbo, lacking proper synchronisation.
Any thought about that?
I am getting glitches too....any updates/ideas? Will try different compressions to see if that makes a difference.
I’m experiencing visual glitches by displaying textures coming from ofxOMXPlayer.
The problem is clearly visible when using my highly contrasted testing videos.
(the red line is cut while it's always straight in the video)
(multiple glitches in this one, clearly coming from the texture since all three quads are affected)
At first I thought it might be a vertical-sync display problem. I made sure I switched vertical-sync on in my application, then I drew a vertical white line scrolling from left to right to be perfectly sure it wasn’t.
The problem doesn’t always show up, depending on the video file, the usage of a fbo or not, the resolution of the display and the amount of pixels I draw on top of the video, etc.
I actually spent a lot of time figuring out what could be wrong in my code, until I realise I could reproduce the problem by running the basic example using texture mode, with one of my torture-sync-test movies.
Did anyone experience a similar problem?
My guess is that ofxOMXPlayer asynchronously writes texture data while it’s been used for drawing, couldn't it?