Hacker News Reader

Comment by chime | Hacker News Reader

The major criticism the author has is the requirement for HTTP2 push for ALHLS, which many CDNs don't support. While I agree it is a valid criticism, I am glad Apple is forcing the CDNs to support push. Without the 800lb gorilla pushing everyone to upgrade, we would still be using pens on touchscreens.

I am not a fan when Apple obsoletes features that people love and use. But I always support when Apple forces everyone to upgrade because friction from existing providers is what keeps things slow and old. Once Apple requires X, everyone just sighs and updates their code, and 12mo later, we are better off for it.

That being said, I agree with author's disappointment that Apple mostly ignored LHLS instead of building upon it. Chunked encoding does sound better.

View on HN

There are good reasons CDNs don't support http/2 push. It’s hard to load balance and hard to operate, since it requires a persistent TCP connection with the client for the entire duration of the stream, which can be hours. It has consequences that echo almost everywhere in the architecture.

I agree. But now there is motivation for the CDNs to solve these problems in a clever way so that users can get better performance and lower latency.

They are likely to “solve” them by charging more. Serving low-latency HLS to Apple devices will cost more, continuing consolidation into the few tech giants big enough to pay what it takes to get inside the iOS walls. Hardly progress.

I believe Cloudflare supports it and it's free.

What exactly is the benefit of HTTP2 for HLS CDN use, particularly?

The obvious benefit of not using it is that you don't need your CDN to do TLS, likely to be utterly superfluous if video chunks are validated through the secure side-channel of the playlist already.

TLS provides privacy, not merely validity. Some folks don't want others knowing what they watch after connecting to, er, Disney+.

(I have no idea why video streaming might be better over HTTP/2 either.)

TLS specifically does not prevent a passive eavesdropper from telling what compressed video you’re watching. If they can drop a few packets and force you to rebuffer, they can tell very quickly—plausibly faster than you can tell watching the video start!

That’s interesting. Do you have a reference to a working example?

How does that work?

Dropping packets is not passive...

Okay so ignore that part. It's a tangent to the actual point.

Can you point us to some documentation? I’m having trouble seeing how this would work absent a huge vulnerability in TLS.

https://pdfs.semanticscholar.org/2015/26efeb7206e2704b8db469...

http://cs.jhu.edu/~cwright/oakland08.pdf

https://www.blackhat.com/docs/us-14/materials/us-14-Niemczyk...

There's variation in the segment-to-segment sizes of video. Watching the stream of data, you can pretty easily find many of the segment sizes, and from there you just need a lookup table.

Figuring out spoken language or which web pages are in packets is fuzzier but still viable.

Ah, thanks. That makes sense.

The main redeeming feature of traditional HLS is that it can use ordinary HTTP CDN infrastructure. If you're going to require video-streaming-specific functionality in CDNs anyway there is absolutely no justification for designing your protocol in this horrendously convoluted, inefficient, poorly-performing way.

Reply on news.ycombinator.com