Hacker News Reader

Comment by ampdepolymerase | Hacker News Reader

You underestimate the amount of time needed to do video conversion client side. It is a very compute intensive process and is not feasible for videos of any significant length unless you are willing to let you computer's fan spin up to maximum for an extended period of time. There has been a dozen WebAssembly ffmpeg ports. The issue is absolutely not with the technology.

View on HN

Just to put this into perspective: my i7 4790k takes around 2 minutes to render about 1 minute of 1080p 60 fps footage at x264 medium.

If you wanted to run a YouTube competitor you would likely require better compression, which would take even longer. Now think about it running in the browser, which likely slows it down even more.

You upload a 10 minute clip and then your browser eats 100% of the CPU for the next hour.

And all of that is just for one quality setting.

Can it be done faster on a GPU?

Not if you want to keep quality. GPU encoding blocks are pretty poor in comparison to SW encoders.

That depends on the encoder and the settings you use. My own playing around with CUVID and NVENC support in ffmpeg a couple of years ago worked out quite well. I found that I could take 1080p H.264 footage, decode it, overlay a text display, and re-encode it back to H.264 much faster than real time without perceptible-to-me quality loss.

I saw no problems with the video quality if I used -profile:v high -preset:v slow and set the output bitrate equal to the input's average bitrate. With those settings, I was able to reencode at about 130 fps - handy when the raw footage was 9+ hours at 25 fps. Yes, that's "slow" on the GPU. :)

Yes, but it comes at the cost of quality/bandwidth. When it comes to videos you can trade image quality for file size. High end nvidia GPUs are better in bit rate constrained situations for streaming, but they're not as good at reducing file size as the slower encoders.

When it comes to video hosting it's largely about bandwidth. Imagine you had a video that got 1 million views. 110 MB vs 100 MB file size. That's 110 TB vs 100 TB bandwidth - a difference of 10 TB. At a cent per GB that's $100 difference. Now imagine a video with 10 million views or 100 million views.

And the real difference in file size is likely to be larger.

You're not going to pay anywhere near a cent per GB if you're running a major video hosting site.

Those kinds of fees would only happen if you were a tiny site and using an overpriced option like AWS.

Not only that, but are you gonna transcode to multiple resolutions on the users computer and upload all of those? Not only wasting a ton of time, but also bandwidth? What if they're uploading from their phone, also wasting their battery.

Does it also add other concerns, such as the user uploading different content at different resolutions?

And its not just different resolution but also different codec. You have x264 as baseline. Then you want HEVC, and for some people AV1 as well.

It may be trivial for Youtube or Netflix, certainly not from a consumer's perspective.

Reply on news.ycombinator.com