Three issues on this board already stand on this surface and none of them
builds it, and the record in #112 has already placed the far side of the
handover outside the core. #63 measures the interval from a play call to a
playable handover. #35 talks about the stream in flight while a token is
renewed. #98 says the core hands over something playable and the platform plays
it. So the number in M7 is measured against code nobody planned, which is how a
budget ends up instrumented over a gap.
It is one request, one rule and one handover, and it stops well short of a
player.
What this produces
The negotiation with the server. What the device can actually decode arrives
through the capability description in #36, and the server answers with the
sources it is willing to serve for that item.
A rule that picks one source when the server offers several, written here rather
than decided by whichever caller asks first. Playing the file as it stands where
the device can decode it, and asking the server to convert where it cannot, with
the reason each direction is taken and what each costs a person on a slow
connection.
The handover itself. An address the platform's own player opens, the position to
start from as decided in #58, and which audio and subtitle streams were chosen,
so that two clients given the same item start it the same way.
A stated answer for a server that will serve nothing this device can play. That
is a named kind from the vocabulary in #4 rather than an empty result, because an
empty result is the shape a client forgets to handle.
The boundary, restated because this is the issue most likely to erode it. The
core opens no player, decodes no media, draws nothing, and holds no opinion about
what the client does with the address it was given.
Done when
A test against the fake server produces a handover from a play call. A test
covers a source the device cannot decode and proves the conversion path is the
one requested. A test covers a server that offers nothing playable and proves the
named error rather than an empty answer. The source-selection rule sits in
docs/decisions/ with its reason. Nothing in the handover crosses the line #112
draws. Blocked on #4, #36, #39 and #112.
Three issues on this board already stand on this surface and none of them
builds it, and the record in #112 has already placed the far side of the
handover outside the core. #63 measures the interval from a play call to a
playable handover. #35 talks about the stream in flight while a token is
renewed. #98 says the core hands over something playable and the platform plays
it. So the number in M7 is measured against code nobody planned, which is how a
budget ends up instrumented over a gap.
It is one request, one rule and one handover, and it stops well short of a
player.
What this produces
The negotiation with the server. What the device can actually decode arrives
through the capability description in #36, and the server answers with the
sources it is willing to serve for that item.
A rule that picks one source when the server offers several, written here rather
than decided by whichever caller asks first. Playing the file as it stands where
the device can decode it, and asking the server to convert where it cannot, with
the reason each direction is taken and what each costs a person on a slow
connection.
The handover itself. An address the platform's own player opens, the position to
start from as decided in #58, and which audio and subtitle streams were chosen,
so that two clients given the same item start it the same way.
A stated answer for a server that will serve nothing this device can play. That
is a named kind from the vocabulary in #4 rather than an empty result, because an
empty result is the shape a client forgets to handle.
The boundary, restated because this is the issue most likely to erode it. The
core opens no player, decodes no media, draws nothing, and holds no opinion about
what the client does with the address it was given.
Done when
A test against the fake server produces a handover from a play call. A test
covers a source the device cannot decode and proves the conversion path is the
one requested. A test covers a server that offers nothing playable and proves the
named error rather than an empty answer. The source-selection rule sits in
docs/decisions/with its reason. Nothing in the handover crosses the line #112draws. Blocked on #4, #36, #39 and #112.