Currently Active Users: 30857 (56 members and 30801 guests)

[suzzer99]

Originally Posted by Gary Cooper

How does Pornhub never crash with like 4 billion daily users?

https://www.reddit.com/r/webdev/comm...hub/?rdt=33967

There are a few misconceptions in the answers, so I'll post my experience. I work for the most visited adult live streaming site (you can figure out which one from this) and we too serve static content (think Instagram stories) as well as regular video content on top of our actual live streaming experience.

For regular video content, we convert to a format that's accessible for most browsers and deliver it as a regular video. This feature is not too widely used and it isn't a requirement for these to start playing instantly so the key factor in delivering these very quickly to the browser is a very strong infrastructure for content delivery (in-house CDN) with edge node caching.

For expiring content (stories) we went this route originally too, however due to a limitation in video length some of our content creators started uploading videos split into shorter chunks. In the story player this caused a delay when starting a new chunk as you'd expect. This caused the videos uploaded in sequence to be unenjoyable. To solve this we came up with different solutions, the most interesting of which was to convert all types of stories into a single HLS source (images would be converted into chunks of 6 second videos for example). This improved continuous playing experience drastically, however starting from a non-zero index could cause more loading time than the original video sources. The current solution is to convert each video into HLS and pre-play the next video in line in order for it to start buffering enough for the transition between two stories to happen instantly. The reason for going with HLS had a lot to do with the developers' vast experience working with the format (due to background in live streaming) as well as an already existing infrastructure for converting all sorts of sources to HLS in an efficient way. We don't make much use of the variable bitrate that could be achieved when network conditions change (which can also be implemented with regular videos, but is massive pain as MP4 and other formats weren't intended to be used this way). The main advantage with this solution is that you can very easily control buffering and can preload chunks with ease as they are just regular TS files. As a side note: I saw people mentioning that you need a library to play HLS and this isn't true. Since the format was developed by Apple, it is natively supported by Apple devices. As a fallback solution for non-Apple devices you can use MediaSourceExtension API to implement HLS playback for video elements. There are libraries that do this, one example is HLS.js.

Finally, when it comes to live streaming we use a plethora of sources and fallback services to ensure that the streaming experience is uninterrupted regardless of network conditions, location and possible server outages, but this has little to do with your original question.

Now comes my opinion as to what you should do. I don't think it's reasonable to try to implement the setup we have. It took multiple teams of developers years of dedicated hard work to pull this off and it's an overkill for almost all use-cases. For most projects it's better to go with a cloud solution where you can "cross that bridge when you get there" when it comes to scaling. You should try to maintain as little as possible of your video storing / converting / caching / playback services as you can. Going with a cloud service also means that when advancements land in browsers, you'll be able to take advantage of them within days, rather than having to learn and implement the changes yourself, costing you hundreds of hours.