Comment by simias | Hacker News Reader

Comment by simias | Hacker News Reader

Parent Full thread

Streaming video is hard and expensive, I think that's why there's very little serious competition to Youtube.

You not only have the network effects of social media ("everybody is on Youtube") but you also have to host and stream petabytes of data and still manage to turn a profit.

Now if on top of all of that you want to do it with decentralized technologies it become even harder to reach the same level of quality. Anybody who's attempted to download some niche torrent from a few years ago knows that the success rate tends to be very low. Meanwhile you can still watch the holiday video of some Polish family in Italy in 2011 on Youtube, even if it only has like 20 views.

I want a decentralized, peer-to-peer internet but when you face the technical and financial realities you realize that it really doesn't add up, IMO. You need huge economies of scale to make it work.

Or alternatively you need to convince people that things like web search, video streaming and email hosting are actually worth paying for. Good luck.

Interestingly, part of the problem is that people have switched to smaller and portable devices like laptop, tablets and phones, and away from desktop computers. Desktop computers are not constrained as much by energy consumption problems, can usually have more storage at the same price point, and can persistently connect to reliable internet.

In other words, and ironically, the physical deanchoring of compute devices has made it harder for virtually decentralized video sharing to take off.

On the other hand, wifi routers could do this. Plug in a USB external hard drive, fiddle with some software, boom. (Asus includes a remote accessible file storage; other options are possible with 3rd party firmware, etc)

True, and also IPv4 and mass-NATing everything by default was an other factor IMO. If you've been coding some network application over the past 3 decades you basically have to assume that most of your users are going to run it behind a NAT. That creates a world of issues for anything p2p.

I wonder if the situation would've been different had something like IPv6 been adopted much earlier. Then even end users might have integrated the idea that their devices would remain accessible remotely once connected to the internet. That would have made it harder for ISPs to sell these connections where basically nothing but HTTP(S) makes it through.

Is YouTube even profitable? Google/Alphabet have never disclosed this.

Can I encode video to one format, like webm, and only serve this format without reendocing specifically for a client? Force all clients to watch only in resolutions in which the file is available on disk? It would deduct CPU/GPU time and only need to get storage and network, which isn't that expensive. I have a few dedicated kimsufi servers that are under-utilized.

You can. But now most of your clients will burn battery because they don't have hardware VP8, VP9 or AV1 decoding (yet). IIUC these are the only video codecs supported by WebM and they have very little hardware support. Of course this problem exists for any particular codec that you chose it is either nonfree, inefficient or not universally supported.

And after that some of your clients will have terrible buffering because your video file is too large. Other clients will have a 4k TV and your file will be too small. Unless your bandwidth is very cheap you will also spend more money sending your 1080 video to phones with a 720p screen.

So yes you can. But there is a reason that every serious video service has multiple codecs, every client has a different ideal video file and by getting close to that you will provide a better experience.

I meant webm as an example, anything else works as long as the file will be encoded once and then directly streamed without reencoding

My point is that any one encode won't be sufficient. WebM is actually probably one of the better options for a single encoding. But any single choice of codec and parameters will be insufficient to provide a top-tier user experience.

Not sure what you mean with reencoding for each client? AFAIK no major streaming does this realtime. They reencode the content once from source into a number of bitrates and formats, put the result on a CDN and then use DASH/HLS/Smooth so clients can dynamically fetch and switch between them based on a manifest.

If you do not do DRM you can probably get away with only using HLS or DASH and three or so bitrates/qualities. 480p, 720p and source perhaps?

That might double your storage req and the one time encode effort, but running costs are the same (if not less because people will consume less bandwidth).

Can't edit my comment for some reason, but I just wanted to correct myself in that just-in-time encoding is a thing that exists and is being used. Only lately has it been in significant use for non-live content though. The standard practice is still what I outlined above.

Reply on news.ycombinator.com