Hacker News new | past | comments | ask | show | jobs | submit login

Then you could just skip the ad in the video, unless the player has some meta-data around when the ad is; in which case youtube-dl can chop it out.



Not if you tightly control the streaming rate to not get far ahead of a realtime playback, just mete out the video stream at a rate appropriate for watching, not as fast as the pipe can suck it down.


I'm kinda surprised Google doesn't do this... They would need to keep track of user seeks and stuff, but it still seems do-able. One simple model is for the server to know when ad-breaks should happen, and prevent any more downloading for the duration of the ad.

Sure, it would break people who want to watch at 2x realtime, but they seem small-fry compared to those with adblockers.


The issue there is scale, MPEG-DASH/HLS let the edge servers for video to be simple. The servers don't need to do much more than serve up bytes via HTTP. This ends up being better for clients, especially mobile clients, since they can choose streams based on their local conditions the server couldn't know about like downgrading from LTE to UMTS.

Google would end up having to maintain a lot of extra client state on their edge servers if they wanted to do that all in-band. Right now it's done out of band with their JavaScript player. Chasing down youtube-dl users isn't likely worth that extra cost.


The edge server could implement this without much extra complexity.

For example each chunk URL could be signed with a "donotdeliverbefore" timestamp.

Now the edge server has zero state.

Similar things are done to prevent signed in URL's being shared with other users.


There's no shared wall clock between the server and client with HTTP-based streaming. There's also no guarantee the client's stream will play continuously or even hit the same edge server for two individual segments. That's state an edge server needs to maintain and even share between nodes. It would be different for every client and every stream served from that node.

For streaming you actually want the client to have a buffer past the play head. If the client can buffer the whole stream it makes sense to let them in many cases. The client buffers the whole stream and then leaves your infrastructure alone even if they skip around or pause the content for a long time. The only limits that really make sense are individual connection bandwidth limits and overall connection limits.

The whole point of HTTP-based streaming is to minimize the amount of work required on the server and push more capability to the client. It's meant to allow servers to be dumb and stateless. The more state you add, even if it's negligible per client, ends up being a lot of state in aggregate. If a system meant edge servers could handle 1% less traffic that means server costs increase by 1%. Unless those ones of ad impressions skipped by youtube-dl users come anywhere close to 1% of ad revenue it's pointless for Google to bother.


> skipped by youtube-dl users

It's also ublock and adblock plus users. Estimated at about 25% of youtube viewership.

Also, the shared clock only needs to be between edge servers and application servers. And only to an accuracy of a couple of seconds. I bet they have that in place already.




Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: