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

From: "Vajjhula, Venkatram" <[email-masked]>
Date: Wed, 14 Feb 2018 03:17:56 +0000

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

---

From: Craig Pratt <[email-masked]>
Date: Fri, 16 Feb 2018 02:05:17 -0800

Thanks for the feedback Venki.

Reply in-line.

cp

On 2/13/18 7:17 PM, Vajjhula, Venkatram wrote:

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.

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.

I'm actually going to remove the "Shift Buffer Representations"
section from the draft - due to an issue with non-Range requests.
But the idea is that if/when a client requests a range that precedes
the 3-hour mark, e.g. "Range: bytes=0-999999999999" the server would
return whatever byte position represents the 3-hour mark as the
start of the Content-Range and the large end value to indicate
indeterminate length. e.g. if the 3-hour mark started at byte
position 102030405, the server would respond with "Content-Range:
bytes 102030405-999999999999/*

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.

The draft only deals with continuity of data/representation - not
continuity of time. If a single representation is used to express
content containing time gaps/discontinuities, the format of the
content needs to be able to express them. e.g. PTS/DTS gaps in MPEG2
transport stream representations.

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.

Similar to discontinuities, the format of the representation needs
to have a way to identify random access points. e.g. ISO BMFF (used
for MP4 files) can express random access points in a number of ways.

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.

There isn't a limit specified in the draft. 999999999999 is just an example. Section
4 of the draft discusses the choice of a large end value.

Please let
me know if you have more questions

-Venki

I hope this answers at least some of your questions. Please let me
know if you have any follow-up questions or if you think I've missed
something.

cp

--

craig pratt

Caspia Consulting

[email-masked]

503.746.8008