Draft seems to address well the use case of live file applications like Block chain files Draft does not specifically address the following live video applications. 1. A live video server that serves only a window of bits including current but not always from the beginning. E.g: A video server that serves in window of [3hrs , current]. In this case what would be the byte range request. 2. A video event has gaps. i.e Runs from 9am-10am and then resumes from 10:30-11:30. In this case how will the byte range semantics reflect the live stream gaps . I would like to see a semantics of Range: bytes=0-1000/1000 2800-5000/5000 6000-1000000/* . Even that may have a problem in addressing future but yet unknown gaps. 3. In the initial request when a live video application is seeking the first range request, it is most likely that the application is also looking for a point where it can start decoding the video. How can an application indicate that in the byte range request a key frame start offset ? And what kind of response will the server indicate. 4. The current draft indicates in 999999999999 as the very very large value. But with 4K/8K video live streaming around the corner, this can be reached within 56hrs of the live stream start. So this will run into issues in a 24x7 scenario. Given that most applications will be 64bit, why did we limit this. Having a couple more digits in place can make it more future proof. Please let me know if you have more questions -Venki
Received on Wednesday, 14 February 2018 03:18:31 UTC