Build a player
Design a resilient Vyla playback experience around your own product and infrastructure.
Your player, your rules
Vyla supplies the integration layer; your application owns the player experience. That includes design, authentication, title discovery, parental controls, analytics, playback policy, and fallback behavior.
For a local managed experience, Vyla Home starts its bundled player service. For a custom product, choose one of two boundaries:
| Integration | Best for |
|---|---|
| SDK directly | Node.js products that already have a backend and want complete control |
| Stream API | browser or mobile clients that need an HTTP/SSE source feed |
Build for changing conditions
Provider results vary by title and network. A dependable player should:
- Begin playback as soon as it has a usable candidate.
- Keep later candidates as fallbacks.
- Keep subtitles independent from first playback.
- Report a helpful unavailable state when no candidates resolve.
- Destroy playback and abort in-flight work when the viewer changes titles.
The SDK returns provider results directly; Stream API emits meta, source, and
done events. Both models benefit from the same fallback strategy.
Playback formats
Candidates may be HLS manifests or direct media files. Let the result metadata and your player capabilities guide how a candidate is loaded; do not assume every URL has the same format or availability. HLS-capable web players normally use HLS.js where native HLS is unavailable, while direct media can be assigned to a video element.
Continue building
- Embed provider resolution with SDK quickstart.
- Learn the optional HTTP event contract in Paths and playback events.
- Use the client integration guide for a browser-oriented example.
- Review error handling before shipping a player.