You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a few things that would simplify the time related fields in remote-playback-state.
Currently they all use media-time which is the internal clock used by the media renderer to synchronize audio/video frames. However HTML uses float values in the API to control media playback.
epoch should be milliseconds since the epoch (positive or negative). It could be a float64 or an int64.
duration and currentTime could be a float64 to align with HTML. It depends on whether it's the responsibility of the remote playback controller or the remote playback renderer to convert between media-time and seconds on the media timeline.
Similar case for the media time ranges - they should follow whatever is done for currentTime.
I think we should use null to represent an unknown value instead of having a separate type field. We can't just omit the field because that means "no change from previous state update."
As part of this PR the spec should propose how time values should be converted to/from media-time for use in the protocol.
The text was updated successfully, but these errors were encountered:
There are a few things that would simplify the time related fields in
remote-playback-state
.Currently they all use
media-time
which is the internal clock used by the media renderer to synchronize audio/video frames. However HTML uses float values in the API to control media playback.epoch
should be milliseconds since the epoch (positive or negative). It could be a float64 or an int64.duration
andcurrentTime
could be a float64 to align with HTML. It depends on whether it's the responsibility of the remote playback controller or the remote playback renderer to convert betweenmedia-time
and seconds on the media timeline.currentTime
.null
to represent an unknown value instead of having a separate type field. We can't just omit the field because that means "no change from previous state update."As part of this PR the spec should propose how time values should be converted to/from
media-time
for use in the protocol.The text was updated successfully, but these errors were encountered: