Response to:Working Group Last Call for HTTP Random Access and Live Content

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


Received on Wednesday, 14 February 2018 03:18:31 UTC