4 ms·

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 resolut

by akerro 6y ago

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.

kevincox 6y ago
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.
- akerro 6y ago
  I meant webm as an example, anything else works as long as the file will be encoded once and then directly streamed without reencoding
  - kevincox 6y ago
    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.
mekkkkkk 6y ago
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).
- mekkkkkk 6y ago
  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.

by akerro 6y ago

kevincox 6y ago

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.

akerro 6y ago
I meant webm as an example, anything else works as long as the file will be encoded once and then directly streamed without reencoding
- kevincox 6y ago
  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.

mekkkkkk 6y ago

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).

mekkkkkk 6y ago
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.