How we rewrote Reddit's video player on Android
Written by Alexey Bykov, Staff Software Engineer at Reddit & Google Developer Expert for Android technology
Reddit serves approximately hundred of millions playbacks a day on Android.
In our last two posts: Improving video playback with ExoPlayer and Taking ExoPlayer Further: Reddit's performance techniques we covered ExoPlayer performance and what you can do to improve startup latency, rebuffering, video quality & stability. (Check them out if you haven't yet, they also show how your production metrics may improve after every optimisation)
But bundling those performance practices into a reusable component with a safe and clear API turned out to be a different challenge. Over time, every new video integration became harder, and we kept finding edge cases that were difficult to support without breaking existing behaviour.
In this article, we'll share how we rewrote our abstraction on top of ExoPlayer from scratch: a better API for teams building video features, and even better performance and stability.
Goal: One obvious way to play video
Our main requirement for the API was simple: engineers integrating video shouldn't need to be video or performance experts. They shouldn't have to think about prefetching, player creation, prewarming, or lifecycle. Video should be fast by default and take a few lines of declarative code to integrate.
ExoPlayer is considered one of the best open-source video players among all platforms. It gives you a dozen valid ways to get to the same playable video, and at our scale, that freedom stops being a feature and starts being a challenge.
Tim Peters put it best in the Zen of Python: "There should be one, and preferably only one, obvious way to do it."
Architecture
Playback engine: ExoKit
To bundle all of the optimisations together, we built an agnostic playback engine called ExoKit.
It abstracts away ExoPlayer, makes the API stricter, owns all player communication, and keeps every playback in a central place with a single app-wide video state and effects handling.
It supports all of the performance features we covered earlier, such as:
- Player pooling and prewarming the pool on the app start, since creating a player can still take up to ~200ms according to our production traces
- Decoder reuse for identical videos, which saves up to ~80ms more
- Warming up videos during first composition (not to be confused with prefetching), so the first keyframes are decoded and rendered before the user scrolls to the video.
You can read more about these optimisations and their impact on our metrics here.
On top of that, it offers two APIs: a declarative one for rendering and an imperative one for managing playback state.
u/Composable
fun PostVideo(
mediaId: String,
url: String,
modifier: Modifier = Modifier,
) {
val key = remember { PlaybackKey(mediaId, "feed") }
// Imperative API: express playback intent.
val actions = rememberPlaybackActions()
PlayButton {
actions.action(key, PlaybackAction.Play)
}
// Declarative API: render from playback truth.
val state = rememberVideoPlaybackState(mediaId)
if (state.isBuffering()) {
LoadingIndicator()
}
// Declarative API: describe the video surface.
Video(
modifier = modifier,
props = VideoProps(
url = url,
playbackKey = key,
),
surfaceLifecycle = rememberLifecycle(),
)
}
But even though it looks minimalistic enough, it still leaves a lot of responsibility on engineers. They have to decide where to play the video (which gets tricky with autoplay on), manage the player lifecycle, fire telemetry and coordinate between the declarative and imperative APIs.
To make it easier, we landed on a much more opinionated API.
Self-hosted UI Components
Our first step was to abstract the imperative API from the feature layer: one less decision means one less way to get it wrong. But that logic had to live somewhere.
Rather than building reusable abstractions and inject them into every screen's ViewModel, we went the opposite way: every UI component became fully independent and self-hosted.
To ensure every composable can access product-related context, such as analytics, every block implements the following contract:
interface Component<Props : Any> {
u/Composable
fun Content(props: Props, modifier: Modifier)
fun key(props: Props): Any = props
}
Implementations live in an impl module and can also access product-related context.
Here is a simplified example of what a lower-level composable might look like inside a component implementation:
u/Composable
// Very simplified version of the code for mute button
fun MuteButton(
playbackKey: PlaybackKey,
modifier: Modifier = Modifier,
) {
// Imperative API
val playbackActions = rememberPlaybackActions() // manage playback
val globalActions = rememberGlobalActions() // global state, e.g. settings
// Declarative API
val audioSettings by rememberAudioSettings()
val playbackState by rememberPlaybackState(playbackKey)
// no sound -> hide, loading -> settings fallback, has sound -> real state
val muted = when (playbackState.audio) {
AudioTrackState.HAS_NO_SOUND -> return
AudioTrackState.UNKNOWN -> !audioSettings.isEnabled(playbackKey.surfaceId)
AudioTrackState.HAS_SOUND -> playbackState.isMuted
}
IconButton(
modifier = modifier,
onClick = {
globalActions.action(
GlobalAction.SetSurfaceAudioSetting(
playbackKey.surfaceId,
audioEnabled = muted,
),
)
playbackActions.action(
playbackKey,
PlaybackAction.Mute(!muted),
)
// More things, like handling product-related telemetry
},
) {
Icon(if (muted) Icons.VolumeOff else Icons.VolumeUp)
}
}
The same pattern applies to every clickable or interactive media component. Every UI component also usually has its own ViewModel.
At the screen level, media becomes a set of declarative components that can be arranged like any other UI:
u/Composable
fun SimpleVideoScreen(
screenState: SimpleVideoScreenState,
videoComponent: Component<VideoProps>,
playComponent: Component<PlayProps>,
muteComponent: Component<MuteProps>,
seekbarComponent: Component<SeekbarProps>,
modifier: Modifier = Modifier,
) {
val key = screenState.playbackKey
Box(modifier.fillMaxSize()) {
// 1. Video
videoComponent.Content(props = screenState.toMediaProps())
// 2. Play
playComponent.Content(props = key.toPlayProps())
// 3. Mute
muteComponent.Content(props = key.toMuteProps())
// 4. Seekbar
seekbarComponent.Content(props = key.toSeekbarProps())
}
}
Usually, the Media Foundation team, which focuses full time on media performance and developer experience, implements the components whose internals use both declarative and imperative APIs, whereas feature teams interact with the player through the declarative API.
This new setup gave us three big benefits:
- Product screens stay simple. They only need to arrange the media components and pass in a few props. Nothing more.
- Playback works the same way across the whole app. Every component shares the same playback state wired by playback key, actions, settings and telemetry pipeline under the hood, so users get one consistent experience no matter where they are.
- Performance. Screen-level state does not need to update for every media-related event. Only the affected media component recomposes.
Since introducing a component-based model in our app, AndroidX has made a new addition to their Media3 UI. This new model might serve as a good starting point if you’re thinking of solving similar problems today. One key difference remains: our media components are tied to global playback state, while Media3 UI’s are tied to one Player. So the challenges still remain the same: player creation and the rest of the lifecycle ownership.
Experimentation Setbacks
Choreographer-based Seekbar
I personally found the seekbar a challenging component to implement smoothly, and there are a few interesting decisions we made.
So what does “smooth” mean in practice?
Basically, don't do more work than the screen can render. A 60Hz display takes roughly 16.7ms per frame; at 120Hz (which is not a rare thing anymore), that reduces to ~8.3ms to render a frame. And if it goes beyond this limit, the user sees a jank.
This is where Choreographer can help. It runs right before Android draws the next frame, using the display’s real refresh rate. If the previous frame takes too long to draw, it waits for the next frame instead of firing again. That means we do not stack seekbar updates on top of an already-janky UI.
Estimated position or player position?
In our custom seekbar we predict the position by extrapolating from the last update, and only update it if the video is playing.
If your application's use cases are limited to video, ExoPlayer.getCurrentPosition() is a cheap operation, and it already uses an estimated position under the hood.
long elapsedTimeMs = SystemClock.elapsedRealtime() - positionUpdateTimeMs;
long estimatedPositionMs =
Util.usToMs(positionUs) + (long) (elapsedTimeMs * playbackParameters.speed);
Polling this function will give you a smooth, speed-aware position for free. My recommendation is to still drive the updates using Choreographer and not use an arbitrary delay within a Coroutine or an Handler.
Reddit's production experience
Moving seekbar updates out of screen-level state and driving them with Choreographer made the full-screen video experience measurably smoother.
On our full video screen, the slow-frame rate dropped by 7.3%.
https://reddit.com/link/1urq7f6/video/ifte8fv9g7ch1/player
Playback error 1004 & MediaSource reuse
While experimenting with our newly written ExoKit in production, there was a noticeable jump in playback error 1004 with "Unknown error" message. It affected a small share of devices and was challenging to reproduce locally. Our initial hypothesis was that it was a device-specific playback issue.
The root cause was our MediaSource cache. In some cases, the same cached MediaSource was reused across different player instances. This is something that I wouldn't recommend doing, as every media source is bound to the playback handler of the player it was originally attached to. Otherwise, you risk hitting an error which is thrown here.
Reddit's production experience
We fixed this by keying cached media sources by player id, so a MediaSource can only be reused by the same player instance.
Another possible fix was to move all playbacks onto a single playback thread. That also avoids the handler mismatch, but our production data showed that it made overall startup performance worse:
- % Video started in less than 250 ms: −0.199%
- % Video started in less than 500 ms: −0.132%
- % Video started in more than 1 sec: +1.165%
- % Video started in more than 2 sec: +0.634%
Rebuffering problems
If your app saves and restores playback position, be careful. In our old player we found that at least 36% of plays had a very short stall, under one second.
The main reason came from old choices made years ago. The old player restored the saved position as a check on every play and every move between screens. But the saved position did not match the position the player held at run time. Here is why: if you call player.pause() and then save player.position, and later call player.seek(savedPosition), the two numbers may differ by a few milliseconds. player.pause() does not finish right away. If you want the true position, wait for a playback state change first.
Reddit's production experience
We stopped saving positions this way. Instead we lean on the run time cache kept in the media source, and we reuse the player for videos the user watched before. This removed all of these tiny stalls.
Saving position on your own is still useful when the system kills the process of your app and you need to restore it for a long video.
If you cover this case, watch the order of your calls. Always call seek() first and prepare() after. If you do it the other way, the player loads key frames and chunks you don't plan to play.
Trade-off: Only one playable video at a time
Simultaneous playback is possible on Android, but hardware decoders are finite and shared across the whole device. A high-end phone might decode two or three videos at once, a low-end one just a single video, and an app sitting in Picture-in-Picture can quietly hold a decoder you were counting on. When you run out, you either fall back to software decoding (higher CPU usage, dropped frames) or fail playback with errors like 4001 or 4003.
Reddit's production experience
We could have partly mitigated this by checking the device performance class (a challenge in itself, since not all devices support it), but the development and testing cost wasn't worth the benefit. Instead, ExoKit runs a state machine that picks one active playback by priority (at Reddit it's based on how much of the video unit is visible, but it could also be based on how much of the screen's playable zone it fills).
We expected every surface to start faster after the rewrite. But surfaces that went from playing several videos to playing one improved their startup latency even more than the ones that already played a single video in the control group.
Conclusion
Besides an improved developer experience, the rewrite reduced perceived start latency by 65% at P50 and by 20% at P90. (An additional factor which helped here was the removal of a lot of unnecessary IO work from the startup path. In production traces, a single Main → IO dispatch before playback could add up to 11ms at the P99.)
Kudos to Merve Karaman, Ahmed Nawara, Irene Yeh and Vikram Aravamudhan for making this rewrite possible. We used to talk about this as a dream 2-3 years ago, and now it's our new reality.
Thanks to the following folks for helping me review this article: Iaroslav Khramov, Nicholas Ngorok
