External players and the application handoff

External-player playback hands a media resource from one application to a separate player whose access, track choices and reporting form a distinct playback path.

An external player is a separate application that receives a media resource from the library app. It then performs playback using its own engine and output configuration.

This changes the playback path. It can also change which application owns controls, track selection and progress reporting.

A handoff transfers a defined resource

A caller can supply a file path, a media URL or another supported handoff representation. The external player must be able to use what it receives.

Resource supplied Access requirement
Local file path The file exists in the external player's filesystem context
Network path The receiving process can reach and access that share
HTTP media resource The player can obtain the resource using the relevant access context
Session-specific output The resource remains valid for the intended playback lifecycle

A path meaningful on Emby Server's machine is not automatically meaningful on a different client. The same printed directory name can refer to different storage, or no storage, on the receiver.

A media URL also has its own lifetime and access requirements. Handoff needs to preserve the usable context, not just a title or catalogue identifier.

Player options become part of the session

This original mpv illustration asks a player to open a fictional file at a start position:

mpv --start=120 "example.mkv"

The command was not executed. It demonstrates that resource identity and a starting position are separate inputs.

The external player can have its own audio, subtitle, decoding and output preferences. If the caller does not convey a selected track through a supported mechanism, the player may choose according to its own defaults.

Consequently, comparing integrated and external playback requires the same source and intended tracks. A successful external run with a different subtitle selection does not exercise the same processing requirements.

Playback progress needs a return path

Starting a process proves that a launch occurred. Its exit proves that it ended. Neither observation reports which programme intervals were presented.

For a library app to update resume state accurately, an integration needs suitable progress or final-position feedback and a mapping to the correct item/source timeline.

A prepared version with different opening material can have a different local time for the same scene. Merely copying its final counter into the original source's resume position can therefore misplace the next start.

See Also

References