3 ms·

Yes. An uncompressed 1080p, 60fps video with 24-bit color depth would need around 3Gbps to be streamed. And even if you don't need to stream it, that would sti

Yes. An uncompressed 1080p, 60fps video with 24-bit color depth would need around 3Gbps to be streamed. And even if you don't need to stream it, that would still consume a sizeable portion of the write throughput of the fastest SSDs currently available; if you go up to 4K, you'd actually exceed that by a lot (not to mention, 1tb of storage would last for about 10 minutes of video).

Ecco 4mo ago
Using raw uncompressed bitrate is a bit disingenuous. How about comparing an older, widely supported codec like H.264 as a baseline?
- overfeed 4mo ago
  > Using raw uncompressed bitrate is a bit disingenuous It is not disingenuous given the context. Gp was responding to ggp's hypothetical: >> Is there a compelling reason encoding needs to be done locally?
- gblargg 4mo ago
  If you compressed it with H.264, it wouldn't make much sense to send it remotely to be encoded with a better codec.
  - Dylan16807 4mo ago
    Why not? If h.264 is the best you can do with minimal resources, you can give it 5x the final bitrate and send it to a specialized/beefy encoding system to become something better.
Forgeties79 4mo ago
Who is regularly watching uncompressed videos outside of production environments? That’s got to be a very small population.
- gblargg 4mo ago
  The context was remotely encoding the video, which would require sending the uncompressed stream.
  - zamadatix 4mo ago
    I think the context was intended to be "encoded in some fashion on the upload, just it not as AV2 until after the remote end does all of the transcoded variations". I.e. upload as 2x target bitrate AV1 once and distribute as 1x target bitrate AV2 1,000 times and you'll get the same quality without having to encode AV2 locally. I've actually done a version this for some multi-system live AV at an event before. Between the main software mixer workstations at various fields in the event it was a dumb but simple encoding they could do in hardware at a high bitrate and then in the machine compositing for the livestream out it did AV1 software encoding to upload to the streaming site to minimize bandwidth requirement from the venue and maximize quality on the streaming site. We've since upgraded to hardware with AV1 encode though. The practical downside is AV2 is only providing a 30% advantage over AV1. For the streaming providers their bandwidth costs are pretty cheap compared to revamping the transcoding infrastructure, so it'd probably only make financial sense once the remove end can do the most complex and quality encoding used and the rest are all simpler.

Ecco 4mo ago

Using raw uncompressed bitrate is a bit disingenuous. How about comparing an older, widely supported codec like H.264 as a baseline?

overfeed 4mo ago
> Using raw uncompressed bitrate is a bit disingenuous It is not disingenuous given the context. Gp was responding to ggp's hypothetical: >> Is there a compelling reason encoding needs to be done locally?
gblargg 4mo ago
If you compressed it with H.264, it wouldn't make much sense to send it remotely to be encoded with a better codec.
- Dylan16807 4mo ago
  Why not? If h.264 is the best you can do with minimal resources, you can give it 5x the final bitrate and send it to a specialized/beefy encoding system to become something better.

Forgeties79 4mo ago

Who is regularly watching uncompressed videos outside of production environments? That’s got to be a very small population.

gblargg 4mo ago
The context was remotely encoding the video, which would require sending the uncompressed stream.
- zamadatix 4mo ago
  I think the context was intended to be "encoded in some fashion on the upload, just it not as AV2 until after the remote end does all of the transcoded variations". I.e. upload as 2x target bitrate AV1 once and distribute as 1x target bitrate AV2 1,000 times and you'll get the same quality without having to encode AV2 locally. I've actually done a version this for some multi-system live AV at an event before. Between the main software mixer workstations at various fields in the event it was a dumb but simple encoding they could do in hardware at a high bitrate and then in the machine compositing for the livestream out it did AV1 software encoding to upload to the streaming site to minimize bandwidth requirement from the venue and maximize quality on the streaming site. We've since upgraded to hardware with AV1 encode though. The practical downside is AV2 is only providing a 30% advantage over AV1. For the streaming providers their bandwidth costs are pretty cheap compared to revamping the transcoding infrastructure, so it'd probably only make financial sense once the remove end can do the most complex and quality encoding used and the rest are all simpler.