4 ms·

Why would the browser send byte range requests for video tags if it expects to play the file back linearly from beginning to end anyway? Wouldn't that be additi

Why would the browser send byte range requests for video tags if it expects to play the file back linearly from beginning to end anyway? Wouldn't that be additional overhead/round-trips?

koakuma-chan 2y ago
> Why would the browser send byte range requests for video tags if it expects to play the file back linearly from beginning to end anyway? Probably because byte range is required for seeking, and playing from the beginning is equivalent to seeking at 0. > Wouldn't that be additional overhead/round-trips? No because the range of the initial byte range request is the whole file (`bytes=0-`).
- EE84M3i 2y ago
  My original comment was about the commenter I replied to saying: > To my knowledge, video stream requests chunks by range and is largely client controlled. It isn't a single, long lived http connection. Wouldn't a byte range request for the whole file fall under the "single, long lived http connection"? Sure it could be terminated early and another request made for seeking, but regardless the video can start before the whole file is downloaded, assuming it's encoded correctly?
  - tedunangst 2y ago
    The client doesn't want to eat the whole file, so it uses a range request for just the beginning of the file, and then the next part as needed.
    - koakuma-chan 2y ago
      The client would actually request the whole file and then terminate the request if the file is no longer needed. This is what browsers do at least.
      - lxgr 2y ago
        Both are possible, and in fact I could imagine not all servers being too happy with having to trickle data over a persistent HTTP connection through the entire length of the video, with an almost always full TCP send buffer at the OS level.
        koakuma-chan 2y ago
        > Both are possible It is possible if you are in control of the client, but no browser would stream an mp4 file request by request. > with an almost always full TCP send buffer at the OS level This shouldn't be a problem because there is flow control. Also the data would probably be sent to the kernel in small chunks, not the whole file at once.
        lxgr 2y ago
        > It is possible if you are in control of the client, but no browser would stream an mp4 file request by request. I believe most browsers do it like that, these days: https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Audio_and_video_delivery/buffering_seeking_time_ranges https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Au... > This shouldn't be a problem because there is flow control. It's leveraging flow control, but as I mentioned this might be less efficient (in terms of server memory usage and concurrent open connections, depending on client buffer size and other variables) than downloading larger chunks and closing the HTTP connection in between them. Many wireless protocols also prefer large, infrequent bursts of transmissions over a constant trickle.
        koakuma-chan 2y ago
        > I believe most browsers do it like that, these days Nope. Browsers send a byte range request for the whole file (`0-`), and the correspoding time range grows as the file is being downloaded. If the user decided to seek to a different part of the file, say at byte offset 10_000, the browser would send a second byte range request, this time `10000-` and a second time range would be created (if this part of the file has not already been downloaded). So there is no evidence there that any browser would stream files in small chunks, request by request. > in terms of server memory usage It's not less efficient in terms of memory usage because the server wouldn't read more data from the filesystem than it can send with respect to the flow control. > concurrent open connections Maybe if you're on HTTP/1, but we live in the age of HTTP/2-3. > Many wireless protocols also prefer large, infrequent bursts of transmissions over a constant trickle. AFAIK browsers don't throttle download speed, if that's what you mean.
  - koakuma-chan 2y ago
    > Wouldn't a byte range request for the whole file fall under the "single, long lived http connection"? Yes, it would (though a better description would be "a single, long lived http request" because this doesn't have anything to do with connections), and wewewedxfgdf also replied Yes. > Sure it could be terminated early and another request made for seeking, but regardless the video can start before the whole file is downloaded, assuming it's encoded correctly? Yes.

Why would the browser send byte range requests for video tags if it expects to play the file back linearly from beginning to end anyway? Wouldn't that be additional overhead/round-trips?

koakuma-chan 2y ago

> Why would the browser send byte range requests for video tags if it expects to play the file back linearly from beginning to end anyway? Probably because byte range is required for seeking, and playing from the beginning is equivalent to seeking at 0. > Wouldn't that be additional overhead/round-trips? No because the range of the initial byte range request is the whole file (`bytes=0-`).

EE84M3i 2y ago
My original comment was about the commenter I replied to saying: > To my knowledge, video stream requests chunks by range and is largely client controlled. It isn't a single, long lived http connection. Wouldn't a byte range request for the whole file fall under the "single, long lived http connection"? Sure it could be terminated early and another request made for seeking, but regardless the video can start before the whole file is downloaded, assuming it's encoded correctly?
- tedunangst 2y ago
  The client doesn't want to eat the whole file, so it uses a range request for just the beginning of the file, and then the next part as needed.
  - koakuma-chan 2y ago
    The client would actually request the whole file and then terminate the request if the file is no longer needed. This is what browsers do at least.
    - lxgr 2y ago
      Both are possible, and in fact I could imagine not all servers being too happy with having to trickle data over a persistent HTTP connection through the entire length of the video, with an almost always full TCP send buffer at the OS level.
      - koakuma-chan 2y ago
        > Both are possible It is possible if you are in control of the client, but no browser would stream an mp4 file request by request. > with an almost always full TCP send buffer at the OS level This shouldn't be a problem because there is flow control. Also the data would probably be sent to the kernel in small chunks, not the whole file at once.
        lxgr 2y ago
        > It is possible if you are in control of the client, but no browser would stream an mp4 file request by request. I believe most browsers do it like that, these days: https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Audio_and_video_delivery/buffering_seeking_time_ranges https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Au... > This shouldn't be a problem because there is flow control. It's leveraging flow control, but as I mentioned this might be less efficient (in terms of server memory usage and concurrent open connections, depending on client buffer size and other variables) than downloading larger chunks and closing the HTTP connection in between them. Many wireless protocols also prefer large, infrequent bursts of transmissions over a constant trickle.
        koakuma-chan 2y ago
        > I believe most browsers do it like that, these days Nope. Browsers send a byte range request for the whole file (`0-`), and the correspoding time range grows as the file is being downloaded. If the user decided to seek to a different part of the file, say at byte offset 10_000, the browser would send a second byte range request, this time `10000-` and a second time range would be created (if this part of the file has not already been downloaded). So there is no evidence there that any browser would stream files in small chunks, request by request. > in terms of server memory usage It's not less efficient in terms of memory usage because the server wouldn't read more data from the filesystem than it can send with respect to the flow control. > concurrent open connections Maybe if you're on HTTP/1, but we live in the age of HTTP/2-3. > Many wireless protocols also prefer large, infrequent bursts of transmissions over a constant trickle. AFAIK browsers don't throttle download speed, if that's what you mean.
- koakuma-chan 2y ago
  > Wouldn't a byte range request for the whole file fall under the "single, long lived http connection"? Yes, it would (though a better description would be "a single, long lived http request" because this doesn't have anything to do with connections), and wewewedxfgdf also replied Yes. > Sure it could be terminated early and another request made for seeking, but regardless the video can start before the whole file is downloaded, assuming it's encoded correctly? Yes.