5 ms·

Yes it is true. Browsers talking to static web servers use HTTP byte ranges requests to get chunks of videos and can use the same mechanism to seek to any poin

Yes it is true. Browsers talking to static web servers use HTTP byte ranges requests to get chunks of videos and can use the same mechanism to seek to any point in the file. Streaming that way is fast and simple. No fancy technology required. For MP4 to work that we you need to render it as fragmented MP4.

jofla_net 2y ago
Seconded, ive done a userland 'content-range' implementation myself. of course there were a few ffmpeg specific parameters the mp4 needed to work right still
EE84M3i 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? 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.
wordofx 2y ago
It’s not true because throwing a video file as a source on video tag has no information about the file being requested until the headers are pushed down. Hell back in 2005 Akamai didn’t even support byte range headers for partial content delivery, which made resuming videos impossible, I believe they pushed out the update across their network in 06 or 07.
- jonathanlydall 2y ago
  If your HTTP server provides and supports the appropriate headers and you’re serving supported file types, then it absolutely is true. Just putting a url in my Chromium based browser’s address bar to an mp4 file we have hosted on CloudFlare R2 “just works” (I expect a video tag would be the same), supporting skipping ahead in the video without having to download the whole thing. Initially skipping ahead didn’t work until I disabled caching on CloudFlare CDN as that breaks the “accept-range” capability on videos. For now we have negligible amount of viewership of these mp4s, but if it becomes an issue we’ll use CloudFlare’s video serving product.
  - wordofx 2y ago
    > If your HTTP server provides and supports the appropriate headers and you’re serving supported file types, then it absolutely is true. No. When you play a file in the browser with a video tag. It requests the file. It doesn’t ask for a range. It does use the range if you seek it, or you write the JavaScript to fetch based on a range. That’s why if you press play and pause it buffers the whole video. Only if you write the code yourself can you partially buffer a while like YouTube does.
    - bmacho 2y ago
      Nah, it uses complex video specific logic and http range requests as protocol. (At least the normal browsers and servers. You can roll your own dumb client/server of course.) > That’s why if you press play and pause it buffers the whole video. Browsers don't do that.
    - jonathanlydall 2y ago

jofla_net 2y ago

Seconded, ive done a userland 'content-range' implementation myself. of course there were a few ffmpeg specific parameters the mp4 needed to work right still

EE84M3i 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? 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.

wordofx 2y ago

It’s not true because throwing a video file as a source on video tag has no information about the file being requested until the headers are pushed down. Hell back in 2005 Akamai didn’t even support byte range headers for partial content delivery, which made resuming videos impossible, I believe they pushed out the update across their network in 06 or 07.

jonathanlydall 2y ago
If your HTTP server provides and supports the appropriate headers and you’re serving supported file types, then it absolutely is true. Just putting a url in my Chromium based browser’s address bar to an mp4 file we have hosted on CloudFlare R2 “just works” (I expect a video tag would be the same), supporting skipping ahead in the video without having to download the whole thing. Initially skipping ahead didn’t work until I disabled caching on CloudFlare CDN as that breaks the “accept-range” capability on videos. For now we have negligible amount of viewership of these mp4s, but if it becomes an issue we’ll use CloudFlare’s video serving product.
- wordofx 2y ago
  > If your HTTP server provides and supports the appropriate headers and you’re serving supported file types, then it absolutely is true. No. When you play a file in the browser with a video tag. It requests the file. It doesn’t ask for a range. It does use the range if you seek it, or you write the JavaScript to fetch based on a range. That’s why if you press play and pause it buffers the whole video. Only if you write the code yourself can you partially buffer a while like YouTube does.
  - bmacho 2y ago
    Nah, it uses complex video specific logic and http range requests as protocol. (At least the normal browsers and servers. You can roll your own dumb client/server of course.) > That’s why if you press play and pause it buffers the whole video. Browsers don't do that.
  - jonathanlydall 2y ago