addJavascriptInterface()<\/a> method. This method allows us to inject Java objects into the JavaScript context of the WebView and gives the WebView access to the ProviderRouter object\u2019s public methods.<\/p>\nJW Player for Android SDK Native Layer<\/h2>\n The ProviderRouter routes calls to provider functions between our native providers. Similar to jwplayer.js, our native SDK also has support for multiple providers. We currently have a provider for playback on the device (ExoPlayerProvider) and a provider for playback on external devices such as Chromecast (CastProvider).<\/p>\n
When starting playback, the ProviderRouter routes a call to play() to our ExoPlayerProvider. The ExoPlayerProvider is our abstraction layer on top of ExoPlayer. Within our SDK we use ExoPlayer to perform the actual playback of media files.<\/p>\n
ExoPlayer supports Dynamic Adaptive Streaming over HTTP (DASH) which is not supported by Android\u2019s built-in MediaPlayer.<\/p>\n
ExoPlayer has support for advanced HLS features, such as correct handling of stream discontinuities and 608 captions.<\/p>\n
ExoPlayer gives us the ability to update the player along with our SDK, since ExoPlayer is a library that is included in our SDK, whereas Android\u2019s Default MediaPlayer is only updated with every new Android release.<\/p>\n
ExoPlayer has fewer device-specific issues than the Android MediaPlayer.<\/p>\n
<\/p>\n
Object model for MP4 playback using ExoPlayer<\/p>\n
ExoPlayer – TrackRenderers<\/h2>\n To play a specific type of media, such as video, audio, or text, ExoPlayer makes use of TrackRenderers. ExoPlayer provides a default TrackRenderer for video, audio, and text playback (e.g. closed captions). ExoPlayer\u2019s default TrackRenderers for video and audio playback make use of Android\u2019s MediaCodec class to decode individual media samples. These TrackRenderers can handle all audio and video formats supported by a given Android device.<\/p>\n
ExoPlayer – SampleSources<\/h2>\n In order to instantiate a TrackRenderer, you need to pass in a SampleSource to their constructor.<\/p>\n
A SampleSource produces a source of media samples from a given datasource using Extractors, Extractors facilitate extraction of data from a container format. ExoPlayer ships with Extractor implementations for a wide array of media container formats such as MP3, MP4, WebM, etc.<\/p>\n
Android Media Framework – MediaCodec<\/h2>\n In order to decode the media samples provided by the SampleSources, ExoPlayer\u2019s default TrackRenderers make use of Android\u2019s MediaCodec class. The MediaCodec class is part of Android\u2019s low-level multimedia support infrastructure, which has been added to Android in version 4.1 (API 16). This is also the reason that version 2.0 of our SDK requires at least Android 4.1.<\/p>\n
<\/p>\n
A codec processes encoded media input data to generate output data that can be rendered by your device\u2019s audio and video components.<\/p>\n
The basic usage flow of a codec is as follows (when using synchronous processing):<\/p>\n
Create and configure a codec.<\/p>\n
While there is input:<\/p>\n
Request an input buffer.<\/p>\n
When the input buffer is ready, fill it with data.<\/p>\n
Queue the input buffer on the codec.<\/p>\n
Wait until the codec has processed the input buffer, when the input buffer has been processed, let the codec output to the Surface. When this is done, release the buffer back to the codec.<\/p>\n
When there is no more input, stop the codec and release it.<\/p>\n
Starting with Android Lollipop, the MediaCodec class also supports asynchronous processing using buffers.<\/p>\n
In ExoPlayer, these media codecs output their data to a Surface<\/a>. A Surface is a raw buffer that holds pixels that are being composited to the screen.<\/p>\nThe Surface that the Android media codecs output to is displayed on the screen using Android\u2019s SurfaceView class. A SurfaceView provides a dedicated drawing surface embedded inside a view hierarchy. The SurfaceView on which ExoPlayer displays its output is placed below our WebView that contains jwplayer.js in JWPlayerView\u2019s view hierarchy.<\/p>\n
<\/p>\n
Flow chart of \u201cwhat happens when you press play\u201d.<\/p>\n
Conclusion<\/h2>\n I hope this post gave you some insight into our SDK\u2019s architecture, and what our SDK actually does when you hit the play button. We think that the architecture of our new JW Player for Android SDK 2.0 is a big leap forward; the transition to ExoPlayer gave us great flexibility in supporting a wide array of media formats, whereas it also greatly reduced device-specific issues. The hybrid software model also made it easier for us to keep feature parity with the HTML5 player. Stay tuned for more updates from the JW Mobile Team.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Have you ever thought about what happens when you press play on an Android device? There is a lot of hidden complexity to playing video on your mobile phone that you may not be aware of. In this post I\u2019ll give you a quick tour through the architecture of our JW Player SDK for Android […]<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2937","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"acf":[],"yoast_head":"\n
What happens when you press play? An overview of the JW Player SDK for Android stack. - JW Player<\/title>\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\t \n\t \n\t \n