4 ms·

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 sig

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.

ehsankia 6y ago
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.
- ghayes 6y ago
  Does it also add other concerns, such as the user uploading different content at different resolutions?
- ksec 6y ago
  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.
Aerroon 6y ago
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.
- prox 6y ago
  Can it be done faster on a GPU?
  - izacus 6y ago
    Not if you want to keep quality. GPU encoding blocks are pretty poor in comparison to SW encoders.
    - flyinghamster 6y ago
      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. :)
  - Aerroon 6y ago
    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.
    - AlchemistCamp 6y ago
      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.

ehsankia 6y ago

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.

ghayes 6y ago
Does it also add other concerns, such as the user uploading different content at different resolutions?
ksec 6y ago
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.

Aerroon 6y ago

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.

prox 6y ago
Can it be done faster on a GPU?
- izacus 6y ago
  Not if you want to keep quality. GPU encoding blocks are pretty poor in comparison to SW encoders.
  - flyinghamster 6y ago
    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. :)
- Aerroon 6y ago
  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.
  - AlchemistCamp 6y ago
    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.