3 ms·
> measuring the performance of a blocking playlist fetch along with a segment load doesn’t give you an accurate measurement, and you can’t use your playlist dow
by ec109685 7y ago
> measuring the performance of a blocking playlist fetch along with a segment load doesn’t give you an accurate measurement, and you can’t use your playlist download performance as a proxy.
I don’t see why this would be the case. If you measure from the time the last bit of the playlist is returned to the last bit of the video segment is pushed to the client, you’ll be able to estimate bandwidth accurately.
- Fripplebubby 7y ago> from the time the last bit of the playlist is returned to the last bit of the video segment Based on my loose understanding of HTTP/2 server push and ALHLS, the sequence of events will be: 1. Client requests playlist for future media segment/"Part" 2. Server blocks (does not send response) until the segment is available 3. Server sends the playlist ("manifest") as the response body along with a push promise for the segment itself The push then begins with the segment. The push stream can presumably occur concurrently with the response body stream. So I don't think you can wait until every bit of the playlist comes in. Likewise, you can't use the playlist bits itself to gauge bandwidth because the server imposes latency by blocking.
- ec109685 7y agoIt’s still over the same TCP connection, so there is no way for the push to beat the playlist.