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.
There are a few things that would simplify the time related fields in
remote-playback-state.Currently they all use
media-timewhich 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.epochshould be milliseconds since the epoch (positive or negative). It could be a float64 or an int64.durationandcurrentTimecould 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-timeand seconds on the media timeline.currentTime.nullto 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-timefor use in the protocol.