News for hackers. Stuff that matters.
Re:H.266/Versatile Video Coding (VVC) by ajross on Monday July 06, 2020 @09:56AM (#23747867)
If one trusted numbers like this, and followed a chain of en vogue codecs back through history, you'd expect that a modern codec would produce files sizes like 3% of MPEG-2 on the same input data. It's all spin.

I'm sure it does better, but I'm equally sure it'll turn out to be an incremental benefit in practice.

> I wonder how many more CPU instructions are required per second of decoded video compared to HEVC.

CPU cycles are cheap. The real cost is the addition of yet another ?!@$!!#@ video codec block on every consumer SoC shipped over the coming decade.

Opinionated bile: video encoding is a Solved Problem in the modern world, no matter how much the experts want it to be exciting. The low hanging fruit has been picked, and we should just pick something and move on. JPEG-2000 and WebP failed too, but at least there it was only some extra forgotten software. Continuing to bang on the video problem is wasting an absolutely obscene amount of silicon.

Re:H.266/Versatile Video Coding (VVC) by sp332 on Monday July 06, 2020 @10:23AM (#23748193)
MPEG-2 doesn't support video larger than 1920x1152, so it's hard to compare on 4k video, let alone 8k. But according to https://www.researchgate.net/publication/321412719_Subjectiv... H.265 can achieve similar visual quality with 10% of the bit rate of MPEG-2 even on SD video (832*480). [Edit: not 720p]
Re:H.266/Versatile Video Coding (VVC) by entropicdrifter on Monday July 06, 2020 @10:43AM (#23748409)
832x480 is ~480p video (720x480 is standard widescreen dvd) 720p is 1280x720
Re:H.266/Versatile Video Coding (VVC) by gibolt on Monday July 06, 2020 @10:10AM (#23748016)
Video sizes are not shrinking. 8K is coming, with even bigger sizes on the way. That matters at scale.

As long as someone sees the benefit, people will keep pursuing it. Compression (as like all tech) is a moving target with the platforms regularly improving on many axes.

Re:H.266/Versatile Video Coding (VVC) by syshum on Monday July 06, 2020 @10:10AM (#23748011)
The video codec battle is not about file size, it is about streaming bandwidth.
Re:H.266/Versatile Video Coding (VVC) by yjftsjthsd-h on Monday July 06, 2020 @10:59AM (#23748614)
Are those different? If I chop up a video file into chunks, I'm streaming it, and if I save a stream I have a file. With a buffer, I would expect the sizes involved to be identical. (Although without a buffer I'd expect streaming to be worse)
Re:H.266/Versatile Video Coding (VVC) by Sebb767 on Monday July 06, 2020 @12:00PM (#23749249)
Yes. For the most part, you need to be able to encode to a low and constant bandwidth at 30/60/+ fps, possibly even with limited latency. Then there are also some lesser, but also important aspects, such as the need to be able to start in the middle of a stream, handle lost packages etc.
Re:H.266/Versatile Video Coding (VVC) by occamrazor on Monday July 06, 2020 @04:02PM (#23752099)
Latency will become more important with video conferencing (already now) and AR/VR.
Re:H.266/Versatile Video Coding (VVC) by gsich on Monday July 06, 2020 @11:17AM (#23748813)
>Are those different?

No. In the end you transmitted a file that has a certain size. It doesn't really matter if you save that file or just use a volatile buffer.