[haikuginger]

Hardware implementations of codecs can be made that perform encode at low power if a certain level of quality/efficiency can be given up.

This is already the case for AVC/HEVC on mobile devices where storage and power considerations overwhelm the possible quality and coding efficiency advances that could be available from a highly-intensive, highly-tunable CPU-based encode.

In comparison, if you look at digital cinema, video is dumped as raw, unencoded pixels onto high-speed, high-power SSDs without any compression; this way, the original image can be manipulated losslessly before going through an intensive encode process for an optimal quality/space balance for end-user media delivery.

[tatersolid]

The very popular RED digital cinema cameras have always shot in compressed form using a low-latency wavelet-based codec (presumably with some ASIC or GPU acceleration on board).

http://www.red.com/learn/red-101/redcode-file-format

http://www.theblackandblue.com/2012/05/02/shooting-red-epic-...

What cameras shoot uncompressed 8K HDR video? That doesn’t even seem possible given current SSD bus speeds. Note that many high-quality lossless formats are actually still compressed (they subtract current frame data from the previous frame and then apply LZ4 for example).

[vardump]

> What cameras shoot uncompressed 8K HDR video? That doesn’t even seem possible given current SSD bus speeds.

12-bit bayer RGB matrix 8k @24 fps: 7680 * 4320 * 12bit * 24/s = 1.2 GB/s uncompressed. Currently SSDs go up to 3 GB/s. And you could have a RAID 0 array made out of multiple SSDs.

So it is possible. Entirely another matter whether it makes sense.

One hour of video at this bitrate requires 4.3 TB.

[fandango]

Did you forget that there are multiple color channels? 12 bit should be 36 bit so even more is needed.

[vardump]

No. That's how practically all of the cameras work. Google RGB bayer matrix.

There's just one color component per pixel, thus 12-16 bits per pixel is enough.

[rayiner]

Right, but designing a codec that is scalable in complexity to accommodate real-time hardware encoding on one end, and 100x Netflix encoding on the other end probably isn't easy.

[Twirrim]

Why does it have to be the same codec?

Use the right tool for the job.

[Slartie]

The encoding part may well differ, but having the same bitstream format and thus being able to use the same decoders for a very wide range of efficiency/time trade-offs has huge advantages. The necessity of using hardware implementations of video decoders in many scenarios requires a big initial investment into a new codecs' decoding part before even the first frame of video may be displayed by it.

This is why pretty much anyone has standardized on h264, and now on h265, as the video codec of choice, despite using very different encoder software or hardware to realize hugely differing trade-offs on the encoding side of things.