Modernising the video player of a subscription yoga platform: HLS playback and viewer-controlled quality on the existing streaming infrastructure
Executive summary
For a subscription yoga business, the video player is not a component of the product: it is the product. When some newly published lessons started to reach members at a maximum of 480p, complaints followed, and a planned player upgrade became a priority for the growth of the web app.
Babini Mazzari replaced the legacy web player with a modern HLS player, kept the streaming infrastructure that already worked, and gave members direct control over video quality. The new player shipped in two milestones, each tested across six desktop and mobile browsers and released with a documented rollback plan.
- Client
- an international online yoga brand that sells its classes and courses by subscription
- Industry
- Telecom & Media
- Platform and technologies
- web platform, JavaScript video player, HLS, adaptive bitrate streaming, picture-in-picture, cross-browser testing
- Services
- Application modernization, Web Development
At a glance
| Before | After |
|---|---|
| Members had no say in video quality, and some lessons played at 480p at most | Members choose Auto, High or Low quality, with automatic adaptation as the default |
| A legacy player with inconsistent controls across pages | One player with the same controls everywhere it is embedded: speed, volume, fullscreen, picture-in-picture |
| Every change to playback was a risk for paying members | Releases in two milestones, each with cross-browser regression tests and a rollback plan |
Business context
Babini Mazzari already knew the platform ecosystem and the operational weight of its video experience. The client's revenue depends on members coming back to practise, so poor picture quality during a class is not a minor defect: it undermines the value members pay for.
Doing nothing was not an option. Part of the catalogue had degraded because the external video service no longer generated the higher-quality versions of some files. Changing streaming provider would have meant migrating the whole video library while members kept practising. The business needed a fix on the infrastructure it already had.
Challenges
- Feature parity with no room for regression. Members relied on existing behaviour such as playback speed and video watermarking. Losing any of it would read as a downgrade, not a modernisation.
- A video pipeline outside our control. Quality depended partly on how the external service encoded each upload, so a better player alone could not solve everything.
- Many browsers, one experience. Members watch on desktop and mobile browsers with different HLS support, so every control had to behave the same everywhere.
- Change on a live, paying platform. Each release had to be reversible, because playback problems reach members immediately.
Key decisions and trade-offs
Modernise the critical layer, keep the infrastructure that worked. We replaced the player and left the streaming service in place. That kept the scope controlled and avoided a costly migration. The trade-off was accepting the service's constraints and working around them.
Give members control, not just a better default. Adaptive streaming picks quality automatically, but members needed a manual choice when automatic selection did not match their expectations. A simple Auto, High and Low selector addressed a real complaint at a low cost.
Fix the source, not only the symptom. Part of the quality problem came from how videos were prepared before upload. We documented the encoding settings and constraints that decide which quality versions get generated, instead of compensating for them in the player.
Approach
Analysis and player selection
We compared HLS-compatible players on extensibility and on how well they integrated with the existing video service. The output was a technical memo with the chosen player, the reasons, the integration approach and the known limits, approved as the first milestone deliverable.
Implementation and feature parity
The new player was built in staging first. It reproduced the existing features, including the watermark and a simplified set of playback speeds, and added standard controls for volume, fullscreen and picture-in-picture.
Quality control and adaptive streaming
The quality selector was mapped to the HLS renditions the service produces, with the same interface on every page that embeds the player. Casting to smart TVs was assessed, and its limits were documented where the browser did not support it.
Source video quality
In parallel, we worked with the client's team on the files themselves. The streaming service's output depended on the bitrate and encoding profile of each upload, so we documented the settings and constraints that affected whether higher-quality HLS renditions were generated. That gave the client a repeatable reference for preparing future lessons instead of treating each low-quality video as a separate player issue.
Release and risk management
Each milestone went through regression tests on representative videos and pages, performance checks, and keyboard and screen-reader checks where supported. Both were released with a documented rollback plan.
Outcomes
A modern player on the existing infrastructure
The platform moved to an HLS player without changing streaming provider, keeping the existing video library in place.
Members control their picture quality
Three quality options, with adaptive streaming as the default, put the viewing experience back in the members' hands.
One consistent experience
The same controls now work across six desktop and mobile browsers and on every page that embeds a lesson.
A clear path for the video pipeline
Documentation of the integration, its limits, and the encoding settings that shape upload quality gives the client's team a repeatable way to keep quality high as the catalogue grows.
Who this is relevant for
This approach suits subscription and e-learning businesses whose video experience is the product, and that need to modernise playback quickly without migrating their streaming infrastructure or putting paying members at risk.
FAQ
Can you replace a video player without changing streaming provider?
Yes. If the provider delivers standard HLS, the player can be replaced on its own, keeping the existing library and contract. The work is mapping the new player to the provider's renditions and testing it across browsers.
Should members be able to choose video quality if adaptive streaming exists?
Usually yes. Adaptive streaming is the right default, but a simple manual choice resolves complaints when automatic selection does not match what members expect.
How do you reduce the risk of a player change on a live subscription platform?
Release in milestones, run regression tests on representative videos and browsers, and keep a documented rollback plan for each release.
Why do some videos play at low resolution even with a modern player?
The player can only show the versions the video service generated. Encoding issues upstream need a fix at the source, such as consistent encoding settings for uploads.
Related services
- Application modernization: replaced the legacy player while keeping the infrastructure that worked.
- Web Development: built, tested and released the new player across the web platform.
Next steps
If video is at the heart of your subscription product and playback has become a risk, talk to Babini Mazzari about a focused modernisation plan that protects your members and your existing infrastructure.