logoalt Hacker News

jon_dahltoday at 5:45 PM1 replyview on HN

Mux founder here :wave:

Two answers.

First, it does save money. A meaningful percentage of videos on the internet are never watched in the first place, and an even larger percentage are watched soon after upload and never watched again. We're able to prune unwatched renditions, and if they happen to be requested years later, they're still playable. Transcoding on the fly lets us save both CPU and storage.

Second, it is ridiculously fast. Our median time-to-publish for a 5-20 minute video is 9 seconds. We had a customer (God bless them) complaining a few months ago that it took us something like 40 seconds to transcode a 40 minute video, which actually was slower than normal for us. If you do an async transcode up front, you're looking at 20 minutes, not <1 minute.

Blog post on this: https://www.mux.com/blog/how-to-transcode-video-100x-faster-...


Replies

steve_adams_86today at 7:35 PM

> A meaningful percentage of videos on the internet are never watched in the first place [...] We're able to prune unwatched renditions, and if they happen to be requested years later, they're still playable.

I worked on something similar a while back, and the data that helped me make a call on whether or not we should transcode on the fly or store renditions was looking at analytics for how often the files are accessed.

I figured out that a large file being transcoded and stored would use more compute resources in ~15 minutes than it was likely to use over the span of _several years_ if it was transcoded on the fly. In a situation where you don't know if the company will exist in several years... You opt for the choice which allows you to stack on the storage later if it's necessary.

That's probably one of very few times I've ever applied YAGNI properly. That was ripe for over engineering