Re: [whatwg/streams] Stream Reader: event to detect first byte of each chunk added to internal buffer (#1126)

As far as I know, this is indeed impossible.

I work for a company that builds online video player solutions. In recent years, there's a huge interest in the industry for low-latency live streaming. In such streams, the origin server announces the availability of the next audio/video segment *before that segment is fully complete*. A low-latency player can already send the request for that segment and start downloading it *while it is still being generated*.

However, this makes it difficult to do accurate network bandwidth estimations (for adaptive bitrate switching). The player is no longer continuously downloading at the full "line speed" of its network, instead it will receive "bursts" of data as the segment is being generated. A naive implementation that does not take these "bursts" into account would conclude that the bandwidth estimate is always less than or equal to the segment's bitrate. That is: if the player is downloading a 2 Mbps video segment over a 10 Mbps link, it would incorrectly estimate that the network bandwidth is 2 Mbps, and never attempt to switch up to a higher video quality (with a higher bitrate). This makes for a poor viewer experience.

The state-of-the-art is to try to detect which chunks were received without any delay between them (i.e. are part of the same "burst"), and *only* estimate the bandwidth across those chunks. For example, [ACTE](http://streaming.university/ACTE/) does this. From their paper:
> At each chunk downloading step _i_, the average bandwidth is calculated as follows: [...] (1) where _Q_ is the chunk size, and _b_ and _e_ are the beginning and end times of the chunk download, respectively, as illustrated in Figure 4. (1) requires us to know the values for _Q_, _b_ and _e_. _Q_ is inferred from the HTTP header and the HTTP Fetch API provides us the value for _e_. However, with the standard HTTP protocol we have no means to determine the value for _b_. If there is a non-negligible idle period after a chunk is downloaded (i.e., when _b<sup>n+1</sup>_ - _e<sup>n</sup>_ ≫ 0), that chunk must be disregarded in computing (1). Since we do not know the _b_ values, we have to determine such chunks in a different way.

I don't know what your specific use case is, but perhaps it's close enough so that you can borrow some ideas from low-latency video streaming and ACTE? 🙂

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1126#issuecomment-839225952