Why bother transcoding on the fly? Storage is cheaper than CPU and the work it takes to determine what needs encoding is excessive.
It implies that you guys are generating the playlists on the fly, tracking the client requests, then feeding that over to your transcoder - which then needs to get the original, seek, and transcode. Why bother?
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.
> 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
But can you still seek on a video that's being instantly transcoded? To be honest I don't know if anyone does that except YouTube, and it jumps to the time so theoretically you have about a second or two when the request comes into pull the file and start encoding. It sounds like the mezzanine file is chunked, so the time to pull it down is pretty fast.
Since it's your own player you can hint to the backend.
Do you dynamically generate the manifests too? Or do things get transcoded on request?
Oh, never mind - yeah, by using the access logs of segments you can effectively anticipate and pre-encode when you need to. And once the hls or cmaf stabilizes you can just encode one resolution. And the player will tell you it wants to move up or down, so you can trigger the encode it wants.
It's interesting your customers want the video immediately; ours don't care about that. But you guys can really build your manifest files and encode immediately, since you're making those mezzanine files.
Then the encoded files are basically a cache that you can evict whenever.
How long did it take you guys to prove that design out?
They already hit 3 ships. They don't need to mine the strait, just making it impassable due to insurance cost because you can end up with a hole in a tanker is enough.
When I was in finance there was a question whether US debt would crowd out other debt instruments. The answer, obviously, is "no." There seems to be an unlimited appetite for zero-risk debt, which makes no sense.
>The right of the people to be secure in their persons, houses, papers, and effects,[a] against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
Also:
>No person shall ... be deprived of life, liberty, or property, without due process of law.
There’s a difference between happening to be captured on camera if there’s a camera in a public place and having a government agency identify and track you and your vehicle across hundreds of miles of travel.
It's actually no different from how real software is made. Requirements come from the business side, and through an odd game of telephone get down to developers.
The team that has developers closest to the customer usually makes the better product...or has the better product/market fit.
It implies that you guys are generating the playlists on the fly, tracking the client requests, then feeding that over to your transcoder - which then needs to get the original, seek, and transcode. Why bother?
reply