Client playback capabilities

Client playback capabilities describe the media configurations a particular player path can accept and present rather than a universal list attached to a device name.

A client capability describes a playback configuration: a container/delivery path, codec parameters, picture dimensions and cadence, selected audio presentation, and any relevant subtitle handling. It is more precise than “this model of television plays video.”

The app, operating system, decoder and connected output path participate in that configuration. Two apps on one device need not expose the same capabilities.

Different kinds of evidence

Evidence What it supplies
Hardware support specification What a media engine is designed to process
App/profile declaration What the application tells a planner it can handle
Configuration query A response about a particular described media configuration
Successful observed playback Evidence that this tested session worked
Smooth observed presentation Evidence about timing and load during that session

A hardware specification cannot guarantee that a browser uses that engine. A successful short sample does not test every format variation. A capability report is still useful: it narrows which media plan is sensible before the full programme is attempted.

Emby's DeviceProfile model represents several distinct kinds of media constraints. A planner can use such information alongside the selected source and session request.

A query needs actual parameters

The W3C Media Capabilities draft takes configuration information such as type, codec/content type, dimensions, bitrate and frame rate. Its result distinguishes supported, smooth and power-efficient expectations.

For example, asking about one 1080p configuration supplies different evidence from asking about a 4K, higher-frame-rate configuration. Changing only the display label while leaving the query parameters unchanged would not test the second case.

These are predictions or declarations about a configuration, not a live network-speed measurement. The working-draft interface also does not imply that every Emby client uses it for every decision.

Output paths matter

A surround codec that can be passed to an external receiver may need another presentation when listening through stereo headphones. A display change can alter HDR output behavior. A selected subtitle can require a renderer that another app lacks.

The source's stream facts remain the same; the usable client path has changed. That is why a capability result should retain context such as app/player, relevant output route and chosen media parameters.

Unknown is not the same as unsupported

A missing field or an untested configuration supplies incomplete evidence. Software can respond conservatively, try a fallback, or obtain more information. Those policies differ from a proven decoding limitation.

A fallback after a playback failure supplies another kind of evidence. Emby's public conversion-reason vocabulary includes direct-play errors as well as format/property mismatches. The named reason identifies what the planner observed or decided; it is not a complete diagnosis of the underlying failure.

Playback compatibility combines these capability observations with the actual source, selected tracks and delivery limits.

See Also

References