Online video publishers that decide to launch a mobile app are faced with a decision between reusing their HTML5 player by embedding it in a native app, building a completely native playback experience, or a combination of both approaches. Initially, it may seem easiest to re-use your HTML5 player, but that is not always the best option from evidence we’ve seen in our comprehensive testing. This post will evaluate the pros and cons of each approach. It will give some guidance for this important decision, and highlight why investing in a native video player gives your customers the best performance, feature set, and user experience.
Pure HTML5 Approach
On iOS and Android devices you can use a web-view component to embed web content into a native application. The web-view enables the multimedia playback capabilities of the underlying browser engine in your native app.
A simple implementation loads a website containing a HTML5 video player (usually reused from your web implementation as shown below) that references the video content you wish to playback. The web-view presents a standard, non-customizable video player user interface that is dependent on the operating system. This approach limits you to the media formats and codecs that the underlying web-view supports. You are required to write a lot of custom code that differs from your web implementation to support advertisements, DRM, casting, air-play, and the rich-user experience that your customers expect. Running all this code inside a mobile devices web-view ends up consuming a lot more resources than necessary
- Time to Market: Reusing your existing HTML5 video player inside a mobile app requires much less initial development. An organization does not need to invest in engineers with the specific mobile development skill sets required to build a native video player.
- Single code base: Changes to your HTML5 video player will automatically update your mobile app as well. It is even possible to update the video player over-the-air without updating the whole native app using the app store.
- Low performance: Running the whole HTML5 player inside a web-view component needs more processing power than using a full native player. This also negatively impacts the battery life of your device. Also the video startup time is negatively affected as we will show later.
- Reduced Interaction with native app: If you want to show supplementary content based on the HTML5 player, you will need to update the app’s UI with the current video player state. Implementing a communication channel between the web player and native application is tedious and difficult to maintain.
- Reduced feature set: The HTML5 player is unable support all the features your customers expect (and have with other native video players). Examples of those features are
- Offline playback and offline DRM
- Picture in picture
- Reduced access to device sensors
Pure Native Approach
Build a native video player and a native user interface. All of the components in this solution are built on top of core operating system APIs and functionality. The most common native video players today are AVPlayer (iOS) and ExoPlayer (Android). Both video players have API’s that allow you to add functionality around playback, DRM, advertisements, casting/airplay, and analytics. These native video players also have access to all other system and device APIs.
- Offline playback and DRM: With a native video player, you are able to support download and offline playback of protected and unprotected content. We find this use case very important to users who are traveling or are in locations with limit network bandwidth. They are able to download content directly to their device and then playback that content anywhere.
- Picture in Picture: Picture in Picture is a feature that allows the user to browse other apps, answer emails, and respond to texts all while the video continues to play. The video is minimized into a smaller window that can be resized and moved around the screen.
- Performance: Native video players will have a much more responsive user interface. They will also have better startup-time and lower resource consumption as seen in our detailed performance analysis below.
- Updating: No over-the-air updating of the player without updating the application itself
A hybrid approach is typically composed of a native video player with an HTML5 user interface overplayed on top of it. All user interactions are captured by the HTML5 user interface and sent to the underlying native video player.
- Reuse of User Interface: Enables easy JS/CSS based skinning of the player. Changing the color, background and size of UI elements is a matter of minutes and applies to all supported platforms at once. It guarantees a unified user experiences across all platforms and devices. There is no need to implement the same UI which is already used for the web-based player multiple times to support additional platforms like iOS and Android
- Performance & Functionality: With the hybrid approach, you are still able to get benefits of Native Video Player. You can support features like offline playback, DRM playback, and picture in picture.
- Performance: Although the performance is much better with the hybrid approach than with the pure HTML5 based approach, it lacks a bit behind compared to the full native strategy. Nevertheless, for many use cases this performance overhead is more than compensated by the benefits explained above.
CPU Usage and Battery Life
As our evaluation below shows, a pure native approach results in a much less CPU utilization than the HTML5-only solution. Less CPU usage allows for smoother and more fluid user experience and also has a positive impact on battery life. It also shows that a HTML5-only approach almost doubles the CPU utilization during playback compared to the full native or hybrid approach. The test data shows the CPU usage during the first two minutes of a 4.8 mbps, 1080p steam on an iPad Mini 4. It is averaged over multiple test runs and we see similar results on Android.
We also evaluated the start-up time of the different approaches. We measured the time it takes from creating the player object until the first frame is rendered and playback starts. This involves setting up the player itself, initializing the UI, downloading and parsing the manifest and retrieving first video segment. The values were obtained as mean values of several experiments which were executed on different mobile devices. As the chart below shows, the pure HTML5 approach performs worse, with a increase in start-up time of 50% to 100% over the hybrid approach depending on the network conditions. The pure native approach still performs best here and should be chosen to get the most optimal start-up performance for your video enabled application.
Amongst the different approaches explained above, the pure native and the hybrid approach are the best options when you want to the deliver the user experience. The pure HTML5 approach may offer a quick start for developing a video enabled application but its performance and functionality lacks behind the other two approaches. The CPU utilization can double, which will have an impact on the perceived system performance and battery life. Additionally the start-up time until video playback starts is significantly higher as shown before. The pure HTML approach also reduces the feature set and the possibilities you could provide to your users with a native or hybrid approach.
With Bitmovin’s native SDKs for iOS, Android, tvOS and Fire OS we allow our customers to choose between the pure native and the hybrid approach. As discussed, the pure native approach delivers the best performance and allows to use all the features which are offered and supported by the underlying operating system. Also the hybrid approach still delivers a pretty good performance and offers a very easy and flexible way to adapt the UI and deliver a unified user experience across multiple platforms and devices.
Resources and Next Steps
Below we’ve compiled some of our best resources and suggestions for followup reading to learn more about your options for implementing a native, hybrid or HTML5 player.
Read and Learn:
- Announcing Bitmovin’s Android and iOS SDKs [Blog Post]
- Android Bitmovin Player Code Samples [GitHub Repo]
- iOS Bitmovin Player Code Samples [GitHub Repo]
Start Building Now: