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
Platform and technologies
web platform, JavaScript video player, HLS, adaptive bitrate streaming, picture-in-picture, cross-browser testing

At a glance

BeforeAfter
Members had no say in video quality, and some lessons played at 480p at mostMembers choose Auto, High or Low quality, with automatic adaptation as the default
A legacy player with inconsistent controls across pagesOne player with the same controls everywhere it is embedded: speed, volume, fullscreen, picture-in-picture
Every change to playback was a risk for paying membersReleases 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

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.

Let’s discuss your project

Request a consultation to explore your next step with Babini Mazzari.

Request a consultation