Red5 Pro Android Mobile SDK Migration Guide

This documentation serves as a guide in migrating client-side code where a breaking change to the API has been made in a distribution.

Migrating from 5.7.0 to 6.0.0

The 6.0.0 release of the Red5 Pro Android Mobile SDK includes perfomance upgrades for decoding streams for live playback, as well as the modification of R5Connection to allow for decoupled SharedObjects (no longer requiring a pre-established stream in order to use SharedObjects for communication).

6.0.0 Playback Improvements

With regards to the improvements to decoding performance, prior to 6.0.0, decoding of frames for playback were converted from YUV to RGB on the software-side. With the 6.0.0 release, the frames are accepted and stored in YUV (420p) and offloading the YUV to RGB conversion to the GPU during the rendering stage.

This greatly improves the playback performance and is now the default decode procedure used.

Developers utilizing the Subscriber APIs do not have to update their code to take advantage of this default implementation, however they can utilize an additional API method (playWithForcedRGBDecode( String streamName )) if they prefer to use the older implementation of YUV to RGB conversion on the software-side (as detailed below).


The following documents the updates and additions to the R5Stream class.

void play( String streamName )

This method has been updated to be backward compatible and default to store the incoming frames for playback in YUV (420p) to be converted to RGB using the GPU during the rendering stage.

void playWithForcedRGBDecode( String streamName )

This API addition allows developers to choose the pre-6.0.0 decoding implementation which converts incoming YUV frames to RGB o the software-side prior to the rendering stage.


void onFrameReceived( Object data, int format, int width, int height)

Used in assignment of a frame listener through the R5Stream:setFrameListener method.

The interface method of onFrameReceived has been updated to provide a format argument that relates to the R5StreamFormat type of the data being passed into the listener instance.

  • 1 : RGB
  • 2 : YUV 420p (tri-planar)


void setRenderer(R5VideoViewRenderer)

The rendering operations within the R5VideoView have been offloaded to an R5VideoViewRenderer instance in the 6.0.0 version of the Android SDK. There is a default R5VideoViewRenderer instance used within the SDK.

R5VideoViewRenderer getRenderer()

This API addition returns the current R5VideoViewRenderer instance being used by the R5VideoViewController.


Described in the previous section, this class addition to the 6.0.0 release of the Android SDK now handles the interaction with the underlying GLKView as the default rendering routine.

6.0.0 Decoupled Shared Objects

View the Decoupled Shared Objects example from the publicly available Red5 Pro Android Testbed.


When using Shared Objects from an previously established R5Stream instance, the underlying R5Connection is used as the communication channel. In a decoupled Shared Object scenario, a R5Connection is used to start a "data-only" connection. The following methods have been added to the R5Connection API, to achieve a data-only connection:

void startDataOnlyStream()

This method attempts to open a connection to be used for messaging through Shared Objects. Events are provided to assigned R5ConnectionDelegate receivers.

This method cannot be used in conjunction with a R5Connection already established from an R5Stream.

void stopDataOnlyStream()

This method attempts to close the previously established "data-only" connection.

This method cannot be used in conjunction with a R5Connection already established from an R5Stream.

Event Delegation Note

Events from a data-only R5Connection are handled the same as stream-based connections in Android: using the R5ConnectionListener interface.