documentation/products/player.md

# Build a player

<p class="page-description">Design a resilient Vyla playback experience around your own product and infrastructure.</p>

## 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:

1. Begin playback as soon as it has a usable candidate.
2. Keep later candidates as fallbacks.
3. Keep subtitles independent from first playback.
4. Report a helpful unavailable state when no candidates resolve.
5. 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](/sdk/vyla-sdk/quickstart).
- Learn the optional HTTP event contract in [Paths and playback events](/stream-api/reference/paths).
- Use the [client integration guide](/guides/integrations) for a browser-oriented example.
- Review [error handling](/guides/error-handling) before shipping a player.