MediaStreamAPI: Difference between revisions

Jump to navigation Jump to search
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.
1,295

edits

Navigation menu