1,295
edits
| Line 44: | Line 44: | ||
*A stream can be "blocked". While it's blocked, its timeline and data window does not advance. | *A stream can be "blocked". While it's blocked, its timeline and data window does not advance. | ||
Blocked state should be reflected in a new readyState value "BLOCKED". We should have a callback when the stream blocks and unblocks, too. | Blocked state should be reflected in a new readyState value "BLOCKED". We should have a callback when the stream blocks and unblocks, too. | ||
We do not allow streams to have independent timelines (e.g. no adjustable playback rate or seeking within an arbitrary Stream), because that leads to a single Stream being consumed at multiple different offsets at the same time, which requires either unbounded buffering or multiple internal decoders and streams for a single Stream. It seems simpler and more predictable in performance to require authors to create multiple streams (if necessary) and change the playback rate in the original stream sources. | |||
*Streams can end. The end state is reflected in the Stream readyState. A stream can never resume after it has ended. | *Streams can end. The end state is reflected in the Stream readyState. A stream can never resume after it has ended. | ||
edits