4 ms·

Out of curiosity, what is the problem with the user experience? I genuinely want to know, since I haven't tested embedding videos for a long time. Is a CDN abso

Out of curiosity, what is the problem with the user experience? I genuinely want to know, since I haven't tested embedding videos for a long time. Is a CDN absolutely needed for streaming content?

eropple 4y ago
Seeking into a large video file is awful and having to buffer the entire thing is a bad user experience unless you're starting at the very beginning. In addition to that, there's a quality-vs.-download-time tradeoff and the right answer to that can vary depending on circumstances. Modern systems use HLS or DASH to enable adaptive streaming. Adaptive streaming chunks up your video into segments of 2-10 seconds and renders it out at different quality levels; a sufficiently smart player can then switch between different renditions on the fly based on system and network performance.
- teddyh 4y ago
  > Seeking into a large video file is awful and having to buffer the entire thing is a bad user experience It would be, if not for HTTP having "Range" support since HTTP 1.1 in 1999.
  - eropple 4y ago
    Have you ever tried to range into a file with variable-length encoding? It doesn't go so well. This is one of the reasons (a little stale IMO, but historically reasonable) that the received wisdom for podcast formats is to use CBR audio, so as to make the naive seek algorithms used when streaming more reliable. Video's bigger and the human tolerances are smaller. There are very, very smart people working on making video readily consumable over the internet. If "just use HTTP range requests" was a viable answer, I tend to think they'd have done it.
    - teddyh 4y ago
      Then, clearly, what we need is a seek-friendly video encoder.
      - eropple 4y ago
        Okay, I'm stumped. Why do we need a "seek-friendly video encoder", which will compromise video quality and file size, when DASH and HLS define seeking in a more flexible and effective way that also allows for adaptive streaming and content steering than "range requests for a multi-gigabyte file" ever will be?
        teddyh 4y ago
        Sure, if the indexing can be handled out-of-band to enable more efficient video encoding, then do that. But this means that the media is no longer a single stream of bytes, which complicates things. It’s always simpler, and therefore better, to have media self-contained in a single file of bytes.

Out of curiosity, what is the problem with the user experience? I genuinely want to know, since I haven't tested embedding videos for a long time. Is a CDN absolutely needed for streaming content?

eropple 4y ago

Seeking into a large video file is awful and having to buffer the entire thing is a bad user experience unless you're starting at the very beginning. In addition to that, there's a quality-vs.-download-time tradeoff and the right answer to that can vary depending on circumstances. Modern systems use HLS or DASH to enable adaptive streaming. Adaptive streaming chunks up your video into segments of 2-10 seconds and renders it out at different quality levels; a sufficiently smart player can then switch between different renditions on the fly based on system and network performance.

teddyh 4y ago
> Seeking into a large video file is awful and having to buffer the entire thing is a bad user experience It would be, if not for HTTP having "Range" support since HTTP 1.1 in 1999.
- eropple 4y ago
  Have you ever tried to range into a file with variable-length encoding? It doesn't go so well. This is one of the reasons (a little stale IMO, but historically reasonable) that the received wisdom for podcast formats is to use CBR audio, so as to make the naive seek algorithms used when streaming more reliable. Video's bigger and the human tolerances are smaller. There are very, very smart people working on making video readily consumable over the internet. If "just use HTTP range requests" was a viable answer, I tend to think they'd have done it.
  - teddyh 4y ago
    Then, clearly, what we need is a seek-friendly video encoder.
    - eropple 4y ago
      Okay, I'm stumped. Why do we need a "seek-friendly video encoder", which will compromise video quality and file size, when DASH and HLS define seeking in a more flexible and effective way that also allows for adaptive streaming and content steering than "range requests for a multi-gigabyte file" ever will be?
      - teddyh 4y ago
        Sure, if the indexing can be handled out-of-band to enable more efficient video encoding, then do that. But this means that the media is no longer a single stream of bytes, which complicates things. It’s always simpler, and therefore better, to have media self-contained in a single file of bytes.