- From: David LaPalomento via GitHub <sysbot+gh@w3.org>
- Date: Thu, 29 Oct 2015 21:03:53 +0000
- To: public-html-media@w3.org
dmlap has just created a new issue for https://github.com/w3c/media-source: == Report buffer changes in update events == Currently it is difficult, and in some cases impossible, for application developers to determine the time ranges that were added or removed as result of operations on SourceBuffers. Some video formats (HLS, for example) do not provide timestamp information in their manifest files and require the application to synchronize manually during quality changes. With video-on-demand content the application is normally able to accurately calculate the correct content to fill the buffer without gaps because the start and end time are known. Live videos with multiple quality levels are more complicated, however. Different renditions may not be synchronized due to delays encoding or pushing content to edge servers. If the application is unlucky with its decision about what content to download, it may waste a lot of bandwidth trying to find the edge of the current buffered time range. For example, image a live stream with two quality renditions which present some window of available content but are not exactly in sync: ``` A |--a0--|--a1--|--a2--|--a3--| B |--b0--|--b1--|--b2--| 0 5 10 15 20 ``` Assume the application has buffered `b0` and `b1` and decides to switch to `a1`. Appending `a1` into a SourceBuffer in that state would have no effect on the buffered ranges and so the application would be forced to make another blind guess for the next segment to download. If the video has a large amount of buffered content, the application could be required to make multiple requests to find a segment that allowed it to determine the time shift between the two streams. If `update` events included `added` and `removed` TimeRanges with the results from the coded frame processing algorithm, the app could synchronize across quality levels much more quickly and save viewers and publishers significant bandwidth costs. See https://github.com/w3c/media-source/issues/35
Received on Thursday, 29 October 2015 21:03:54 UTC