Surface Layers and the Live Streaming Android SDK

With great power comes great responsibility. OpenGL (while not a superpower per se) is still a mighty library capable of great things. However, like a Hulk temper tantrum, a lack of control can have bad results.

With this in mind, we would like to share some tips about working with OpenGL and surface layers so you can harness that power. We want to help you build successful applications and don’t like it when you’re angry.

Notes about Android and Surface Layers:

• Surfaces, and related GLSurfaces, allow images to be drawn directly to the Android window. These surfaces are used by the Red5 Pro Android SDK to draw the camera preview. The R5VideoView draws the camera preview with a SurfaceView and an incoming stream’s video with a GLSurfaceView.
• These SurfaceView objects are drawn separately from the Android UI.
• They have multiple layers, specifying that only one surface ‘should’ be on each at any one time. From Top to Bottom they are:
• “OnTop” (Surface Layer)
• UI (Everything in layouts and non-surface views added programatically)
• “MediaOverlay” (Surface Layer)
• Default Surface Layer
• Having multiple Surfaces on one layer technically leads to undefined behavior. This effectively means that it’s up to the OEM’s discretion to decide how surface layering is handled. Most will have taken care of any issues that might arise from z-fighting.

Tips:

• Point of confusion:
• SurfaceViews added in layouts (ie – not added to view hierarchy by addView()) are drawn as normal parts of the UI layer only when they have a background.
• Important note – This means if your app uses a background on any of its views or layouts in the same window as an R5VideoView. The DebugView will draw on the correct UI layer, but the stream view will be behind the background.
• The stream will always be drawn under any alert or dialog views.
• Troubleshooting – if your stream isn’t displaying correctly, make sure there aren’t any backgrounds sharing its draw space.