Skip to content

Playback and Proxy Model

Playback issues often sit between the client, SyncTV, Provider, and upstream media server. Providers explicitly return playback information and upstream headers, clients follow that result, and the proxy does not guess client headers.

  1. The client requests the current room playback or a playback for a media item.
  2. SyncTV uses room state, media, user, Provider credentials, and client profile to build Playback.
  3. The Provider returns one or more PlaybackInfo entries with URL, format, headers, subtitles, expiry, and metadata.
  4. The client chooses direct URL, proxy URL, transcode variant, HLS, FLV, or subtitle URL.
  5. When URL expiry, media switch, credential change, or client capability changes, the client requests fresh playback info.
ModeBest forRisk
DirectClient can access upstream and set headersBrowser header limits, CORS, upstream exposure
SyncTV proxyUpstream is server-only or requires server-controlled headersSyncTV carries bandwidth and latency
Provider variantsMultiple qualities, codecs, subtitles, or transcodingClient must choose by capability
HLS/FLV liveRTMP publish to playbackMulti-replica deployments need HLS backend or publisher proxy
Client conditionHandling
Browser cannot set Referer or custom headersPrefer proxy URL
Native client can set headers and access upstreamDirect URL can be used
Mobile client lacks codec/container supportDeclare capabilities in PlaybackClientProfile
URL has expires_atRequest fresh playback info before expiry
Subtitle has separate headersUse subtitle-specific headers or proxy subtitle URL

Seeking usually depends on HTTP Range:

Range: bytes=1048576-2097151

Proxy slice cache boundaries:

  • Caches only Range slices.
  • Does not cache full response bodies.
  • Bypasses upstreams that do not support Range.
  • File backend can survive process restarts, but has no cross-process index or distributed lock.
  • Shared storage in multi-replica mode is possible, but this is not a strongly consistent distributed cache.

See Proxy Slice Cache.

New clients observe playback resources over Realtime:

  • playbackState: current position, state, and version.
  • playback: playback URLs, headers, subtitles, and expiry.

On reconnect, fetch playbackState and observe playback with the current playbackClientProfile. Playback info is player-ready data for the current source and expires with its URLs.

See Realtime API.

CapabilityBoundary
WebRTCRoom realtime audio/video or signaling; depends on ICE/STUN/TURN and use_webrtc
RTMP publishPublisher entry, usually used by streamer or room admin
HTTP-FLVLow-latency live playback, sensitive to long connections and slow clients
HLSPlaylist/segment files; multi-replica requires local proxy, shared file, or OSS backend

WebRTC configuration is in WebRTC Configuration. Livestreaming is in Livestream Configuration.

SymptomLikely layerCheck
Player gets 403 immediatelyProvider credential or headerProvider headers and upstream status
Seek failsRange or slice cacheAccept-Ranges, Content-Range, proxy logs
Browser only failsCORS or header restrictionsUse proxy and inspect browser Network
Proxy only failsServer-to-upstream network or headersDNS, server network, proxy headers
Multi-replica live randomly failsHLS storage modelPublisher node, shared storage, OSS, gRPC proxy
URL stops working laterexpires_atObserve or fetch a new playback