Manipulate A Custom Glsurfaceview In Android

I have a Custom GLSurfaceView created by D.J.I. The video rendering is done by their own compiled class and it allows only one GLSurfaceView to receive their encoded video. I would

Solution 1:

I'm not familiar with the library, but my guess is that it works by using the current EGL context and surface, probably decoding the video in software and uploading it as a GLES texture.

If that's the case, you can configure EGL with a different surface, and when you call into native_GLDrawFrame() it will draw onto that instead. If the current surface is an FBO, it will use that instead of the SurfaceView. You can then use GLES to render the attached texture as often as you want. (I assume you're trying for some sort of stereo effect.)

One example of this sort of thing can be found in Grafika's "record GL app" activity. The doFrame() method, when in RECMETHOD_FBO mode, will render to an FBO, then blit from it twice (once to the screen, once to a video encoder). Something like this should work for you.

You will need to lift the EGL/GLES code from Grafika if you don't have an equivalent.

(You can't read pixels back from a SurfaceView, so you need to render them twice. I assume that, if the library did that for you, you wouldn't be asking this, so capturing the rendering and blitting it is necessary.)

It's also entirely possible that my guess at the library's workings is wrong, so some experimentation may be necessary.

Edit: I should note that, while you can't get pixels back from a SurfaceView, you can read them before the frame is submitted. So if the library works the way I think it does, it's rendering to GLES without calling eglSwapBuffers() (which is invoked by GLSurfaceView when onDrawFrame() returns). So in onDrawFrame() you could read the pixels back with glReadPixels(), upload them to a texture in a second GLSurfaceView context with glTexImage2D(), and draw them on a different surface. This is slower than the FBO approach because the pixels have to be copied out to the CPU and back in, but it might work.

I should also point out that, whatever solution you arrive at, you are much better off having both sides of the video on a single Surface, rather than two separate SurfaceViews. If you use two Surfaces, you can't guarantee that both of them will be updated on the same display refresh, so you might have frames where one side is slightly behind the other. It would be much better to capture the output and then render it twice to a single SurfaceView. (GLSurfaceView is just a SurfaceView with some additional code to handle the EGL setup and thread management.)