You’re in need of a video player, but where do you start?

Matthijs Langendijk
8 min readApr 28, 2021

The heart of OTT apps will always remain the video player. Whether you’re dealing with VOD or Live video content, this is the one part you need to have nailed down. Users will judge you harshly if video starts slow, buffers a lot or has a terrible quality. And then we haven’t even touched upon the user interface or some of the things that happen under the hood. So where do you start and what should you consider when looking to develop or use a video player?

My player should do A and B and C

Step one in your search for a video player (or multiple video players), is understanding what kind of features you want. With different types of features come different costs, development times and technical dependancies. We can split up the feature-set in roughly four areas: Video on Demand (VOD), Live content, Advertisement and User Interface.

Video player example (

User Interface

Let’s start with the last in the list, User Interface. You might ask yourself why I’ve put this as a separate area, while the user interface is different for each other listed area. The reason for that is because you will have a lot of shared components across your types of players. You will always need a progress bar, video controls and for example recommended content. Getting this list of features UI clarified will help you in determining a question we’ll ask ourselves later: do I want a custom player, or buy/license from a third party?

Video on Demand

Easiest in the bunch is definitely Video on Demand. In technical terms, VOD content always has a starting point (0), and an ending point (the duration of the video). There are no difficult calculations required with timeframes in order to do the regular control options like fast forwarding, rewinding and showing progress on a progress bar. Other topics you should cover here are for example whether you need DRM, what resolutions you want to support (do you need 4K/UHD video?), if you need multiple audio languages or subtitles.

Live Content

I’ll admit, a player for Live Content is similar to one for VOD in many ways. There will still be a progress bar, you will still want to allow your users to fast forward and rewind (do you? Not every player or video type supports it!), and the typical video aspects (resolution, DRM, audio and subtitle languages) are topics to cover for Live as well. So what is the difference here? Mainly the time. What is the starting point of a live stream? What is the ending time, if there even is any? These are technical questions that might make it very difficult to implement such features yourself. And don’t forget the user interface. Instead of recommendations maybe you’ll want a mini-EPG displayed on top of the player.


You need to make some money too, if you have opted for using an AVOD supported streaming service (as opposed to TVOD or SVOD). Typical aspect to cover in this area are preventing users from fast forwarding through the ads, managing clicks on the advertisement, to something as important as attempting to still make the advertisements shown even though users have an ad-block tool installed (do you?).

Where do I want those features?

Okay, you now have a rough idea of the features you want in your players. But, did you already determine where it is you want those features? I can imagine you have a rough idea in the form of: Web, Mobile, Tablet, TV (and attachable dongles like Roku, Apple TV or Fire TV). So, devices determined, let’s move on… right? If it was that easy I don’t know if I would be writing this blog at this point, because sadly it’s not that plain and simple. It largely depends on the road you take (third party versus custom development), so I’ll quickly explain the reasoning behind your choice of devices and move on.

When you’re thinking of all of those devices, you have to keep one important thing in mind. They generally don’t follow any technical standard (or they claim to, but don’t do so entirely). While you might have an awesome player that works great in the Google Chrome browser, that doesn’t automatically mean it works great on the Safari browser. This principle applies to the majority of the devices. Especially when you’re doing custom development, you can quickly get lost in the amount of devices and types of technology you actually have to support. So how do you make sense of it all?

The hard question to answer

Wait, so all questions we’ve previously asked (and tried to answer), were easy? It’s obviously not that black and white. There are a lot of options to consider before you can get to the point we are about to discuss. Whether you need Live and VOD is easy, but supporting DRM, 4K/UHD content and fast forwarding and rewinding in Live is already a big step above the easiest questions. You might ask yourself now, what is the hard question to answer then? Well, we’ve touched upon it before: should I develop a custom player, or buy/license one from a third party?

Custom development

I can imagine you might wonder why you should even consider doing custom development on a player. And you’re not wrong to ask yourself that. There are a lot of topics you have to cover when developing your own player. You’ll have to develop a player in multiple technologies, to support many devices, and you need to develop each feature that you want as well. You need to test the implementation on all those devices, and make sure that it continues to work as expected. So why still do this? Simply put: you can do with it whatever you want.

That’s really all it boils down to: control. A third party player might sound amazing, but you are also limiting yourself in a certain way. Do you have a custom feature that the player doesn’t support? You’re either going to have to ask the third party to develop it for you, or you have to somehow build it on top of the third party player. That of course can result into compatibility issues and you’re still going to have to test it every where. Building the player yourself gives you full control over the features you do and don’t need. You’re only building exactly what it is you need, there is no additional overhead and you can tailor the players exactly how you want it.

An example of the different technologies you could be working with

The cherry on top here is that the open source community has made it infinitely easier to build your own players. For the majority of platforms out there, an API interface, or even a complete and instantly useable player, is readily available for you. In technical terms, you can think about the likes of Exoplayer (Android/Android TV), AVPlayer (iPhone/Apple TV) and DashJS and Shakaplayer (Web and TVs). So you’re definitely not starting out from scratch either, and it makes developing your own player a lot faster.

Buying or licensing a third party

You don’t have the time, budget, or technical teams to build your own players? Then buying or licensing a third party player might just be the way to go for you. The big benefit of leveraging a third party is really that all the hard work has already been done for you. The majority (if not all) of the features have already been developed for you, and you can almost immediately start using them. No need to wait for your own developers to implement features from scratch, just configure and go.

An added benefit of this is that you’re often not alone in using the third party. The features that you are using are also being used by other parties at the same time, so you can almost guarantee that they will work properly. And you can also reap the benefits from any new developments being done for other customers of the third party.

So what are some of the aspects you should take into consideration here? I can imagine that cost is a factor, but that factor is also important for custom development, and largely depends on what features you need and on which devices. The other big costs topic that scales for third party players is usage. You’ll often end up paying based on the user count, or amount playback starts, that you get from within your apps. On the one hand it means you can start with a low budget, and only need to scale up in costs when you get more users. It also means that, maybe a custom development team ends up being cheaper, in the long run. Next to that, there is the previously mentioned aspect of a third party player not having all the features you need. It can certainly be a costly and time-consuming process to getting up all the features that you want, if you deviate from the standard set of features that a player offers.

Image from

Where you can find such a third party player? Google is your friend of course, but I wouldn’t write this blog if I didn’t have some suggestions for you. In the industry there are a few players that are commonly found, namely some of the following: Bitmovin, THEOplayer, JWPlayer and Flowplayer (apologies if you’re reading this and I missed you, feel free to DM me for suggestions!). Whether any of the players support your feature-set, is something that you’ll have to clarify on your own (I’d be happy to share some insights if you have answered the more easy questions). You can find more information on commercial video players here:

Key takeaways

Finding a video player of your choice, or building your own, can be a daunting job to take on. There are a lot of things to consider before you can make a decision, and you might even come back from your decision several times. When factoring in costs, the features that you need, and the devices that you would like to be on; there is no clear-cut answer for this question. I do however hope that you have gained some insights in the things you should be asking yourself when you’re starting out with your video player or streaming apps.

Did we touch on every topic there is to cover for video players? No, definitely not. You can go a lot deeper on the technology side of things, what types of DRM there are, what types of streaming content, statistics and analytics, you name it. But with the base topics covered in this blog, you should be in a decent place to get started with your journey into streaming.