hi. i'm ollie from the android team. i want to tell you aboutexoplayer, an application level media player for android. built on top of android'slow-level media apis,
Android api levels, exoplayer deliversa number of benefits over android'sbuilt-in media player. you'll be glad tohear it supports both dash and smoothstreaming adaptive play backs.
at google, we'realready using exoplayer in youtube and to play movies. and now we're opensourcing it so that you can useit in your own app. i'm going to show you the lowerlevel apis in which exoplayer is built, outline some of thebenefits of application level media players, and show youhow you can integrate exoplayer into your own applications. before we take alook at exoplayer,
let's first take a lookat android's media apis. prior to jelly bean, android'shigh-level media player api was the de factoway for developers to videos to their applications. it's really easy to use. this example startsplaying a video with just two lines of code. one to create the player and thesecond to start the playback. these two lines ofcode hide nearly all
of the complexities of videoplayback from the developer. however, under the hood, themedia player implementation is doing a lot of work in orderfor the video to be played. for streaming, the first thingthat the player needs to do is to load the videodata over the network. the data then needs tobe buffered according to some policy, whichspecifies when more data needs to be loaded and how much. before the videocan be rendered,
the individual audioand video samples need to be extractedfrom the container format in whichthey're delivered. these samples thenneed to be decoded. and finally, thedecoder samples need to be rendered to thescreen and to the speaker. at a slightly higherlevel, the player needs to track its overallstate, such as the playback position and whether theplayback is currently
advancing. the media player api issimple and easy to use because it hides allof this complexity. however, the onedrawback of this approach is that more advanceddevelopers are then unable to modify or extendthe underlying behaviors to better suit their needs. for example, a developer isunable to tweak the buffering policy or to add a persistentcache for buffered media data.
to better supportthese use cases, we added low-levelmedia apis to android. from jelly bean onwardsthe medial extractor api provides networking,buffering, and media extraction functionality. we also added themediacodec api, which provides access todecoders, including hardware accelerated video decoders. the mediacodec api supportsrendering of video frames
directly. and playing decoded audio canbe done using the audio track api, which has beenaround since cupcake. these low-level apis providedevelopers with an alternative to android's high-levelmedia player. they make it possible to buildapplication level media players written in javawhile they player logic is implementedin application code. this code will typicallycall into the provided apis
in order to load andextract the media samples, decode them, and render them. a developer mayoptionally choose to implement more ofthis functionality at the application level. for example, implementingnetworking, buffering, and sample extractionallows the developer to more easily customizethese components. within google, we've developedour own application level media
player called exoplayer. it supports both dash andsmoothstreaming adaptive playbacks, drmprotected content, and has beendesigned specifically to be easy to modifyand to extend. google's youtube andplay movies applications are already using exoplayer onsome of the more recent android devices. and we're seeingsome great results.
for example, in play movies,dash playbacks using exoplayer have been shown to reducestartup playback latency by 65%. a 40% less likely to rebufferand deliver video at 11% higher resolution on averagethan when using media player. since exoplayer is anapplication level medial player, we're able to tweak itand to add new functionality through play store updates. and we hope that this willallow us to further improve
these numbers going forward. we're really pleasedwith the improvements that exoplayer has broughtto our own applications. but we recognize thatfor many developers, the barrier to entry foradopting a similar approach is quite high. exoplayer is itself around16,000 lines of code. and using android's low-levelmedia apis can be a challenge. so creating such aplayer from scratch
requires a considerable effort. for this reason, we've decidedto open source exoplayer. we hope that this will lowerthe barrier to entry allowing third party developers toobtain similar improvements without having to incurthe cost of developing their own application levelmedia players from scratch. let's take a look at howexoplayer is designed and how it can be usedin your own application. rather than being asingle java objects,
an exoplayer is composed froma range of modular components, each of which contributesa desired behavior or piece of functionality to the player. at the top level, wehave the exoplayer object itself, whichdoes little beyond maintain the overallplayer states. this object callsinto components called trackrenderers whose job it is to render themedia during playback.
the exoplayer libraryprovides a track renderer for playing video,which uses a mediacodec api to decode the videosamples and to render them onto the surface. it supports any videoformat for which there exists anunderlying decoder. h.264 is commonly used. the exoplayer library alsoprovides the track renderer for playing audio, which usesa mediacodec api to decode
the audio samples and theaudio track api to play them. both the audio and videotrack renderer implementations need to be provided witha sample source component from which samplescan be obtained. for a developer whodoesn't require control over the networking, buffering,and sample extraction behaviors, the exoplayerlibrary provides an implementation calledframeworksamplesource, which hooks into android'smedia extractor api.
by doing this, it providessupport for all container formats supported by theversion of android on which it's running. let's take a look atthe corresponding code. first, we buildthe sample source passing the uri wherethe video is located. we then build our audioand video renderers passing the sample source. and finally, we buildan instance of exoplayer
passing the two renderersand start the playback. this is the simplest exampleof how exoplayer can be used. let's now take a look at amore complicated use case, specifically, howexoplayer supports dash and smoothstreamingadaptive playbacks. for dash and smoothstreaming,the exoplayer library contains componentsthat completely replace android'smedia extractor api. individual instancesof a component
called chunksamplesourceare used to supply audio and videosamples to the renderers. each chunksamplesource requiresa chunk source component from which chunksof media, typically between 2 and 10 seconds induration, can be obtained. in this example, we'llfocus on dash paybacks for which dash mp4 chunksourcecomponents should be used. finally, each chunksourcerequires a data source. as the name suggests,data source components
are responsible foractually loading the media. in this case we usehttp datasource, which moves dataover the network. note that for dash playbacksaudio and video are normally streamed separately, whichis why there are two http datasource componentsrather than just one. going back tolooking at code, you can see how eachcomponent is injected with the componenton which it depends.
the video renderer is injectedwith a sample source, which is injected with thechunksource, which is injected with the datasource. this approach, where theplayer is constructed from much of the componentsusing dependency injection, makes it easy for anapplication developer to replace any or allof these components with their own customimplementations. what i've shown so far is aslightly simplified object
model. and in a full example, a fewmore components are required. firstly, somethingcalled a loadcontrol is required to manage thebuffering of the media chunks. secondly, and most importantlyfor adaptive playbacks, each chunksourcerequires something called a format evaluator. format evaluators selectfrom the available formats before each chunk ofmedia is requested.
here we're using afixed implementation for audio, which willstick to a single format. for video, we're using anadaptive implementation, which will selecta format suitable for the current networkconditions aiming to provide the userwith the highest quality possible withoutcausing any buffering. we now know how tobuild an exoplayer for adaptive playbacks usingthe standard components provided
by the exoplayer library. i also touched on how easy itis for an application developer to customize such aplayer to better suit their particular use case. let us now take alook at some examples. suppose that the developerwants to add a persistent cache for buffered media data sothat if the user watches the same video twice,the second time around it would be played from the cache.
in the exoplayermodel, this is easy. the developer can simply insertcache data source components when building the player. a cache datasourcecomponent is provided but equally, a developeris free to write their own implementationfrom scratch. similarly, adeveloper may choose to replace the defaultloadcontrol implementation in order to achievedifferent buffering behavior
or implement an entirelycustom track renderer, for example, to render anoverlay on top of the video. of most use foradaptive playbacks is the ability to injectcustom format evaluators. this allows thedeveloper to experiment with their ownadaptive algorithms. there are many otherways in which exoplayer can be extended and customized. and we're lookingforward to seeing
what developers can do with it. in summary, we've seen howandroid's low-level media apis allow the developmentof powerful application level media players, which canbe more easily updated, modified, andextended by developers than is possible with androidstandard media player. google is usingexoplayer to deliver some great benefits forour own applications. and we hope that byopen sourcing exoplayer,
we will allow other developersto achieve similar results.
so if you're curiousand want to learn more, then visit the developer guide. you're going to find aton of useful information as well as some great examplesto help get you started.
