W3C home > Mailing lists > Public > public-html-media@w3.org > October 2015

[media-source] Report buffer changes in update events

From: David LaPalomento via GitHub <sysbot+gh@w3.org>
Date: Thu, 29 Oct 2015 21:03:53 +0000
To: public-html-media@w3.org
Message-ID: <issues.opened-114146684-1446152631-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:06 UTC