FFmpeg 7.0 Released With Native VVC Decoding & Multi-Threaded CLI

[caligula]

You are neglecting a few things here. 8 years ago, Intel was not claiming they could encode 12 real-time 4K streams, it was 12 720p streams, and a lesser number of 1080p streams*. Intel is talking about 5 4K streams today.

1280x720 = 921,600 x 12 videos = 11,059,200 pixels x 30 fps** = 331,776,000 x 8bit color*** = 2,654,208,000

1920x1080 = 2,073,600 x 6 videos = 12,441,600 x 30 fps** = 373,248,000 x 8bit color*** = 2,985,984,000

3840×2160 = 8,294,400 x 5 videos = 41,472,000 x60 fps = 2,488,320,000 x 10 bit color = 24,883,200,000

The cards of today are pumping almost 10 times the pixels through every second compared to then. This doesn't even bring into the picture the quality of the image, which has drastically improved over that period, which means the cards are doing significantly more work per pixel.

Then we need to mention HDR, not just 10 bit, but the new lighting information that is needed on top of that for todays videos.

I was originally referring to 1080p 30 fps non-HDR 8bit H.264 original / H.264 output. I observe around 5x real-time encoding performance. This is with 5950X (16 cores), RX 7900 XTX, 2 x 32 GB DDR4-3600 CL14, Samsung 980 Pro 2 TB (up to 5100 MB/s). The final video was around 800 MB and 100 minutes in size. So it took 20 minutes to render the video (around 670 kB/s). A 1,2 MB floppy RAID-0 system (8bit Intel 8271 Floppy disk controller, Intel 8257 DMA controller from the year 1977) can write around 250 kB/s. That was 47 years ago.

[caligula]

x264 has been patent free for 20 years. What more do you ask for?

H264 patents will expire in 2028 https://meta.wikimedia.org/wiki/Have...expired_yet%3F

[OneTimeShot]

H264 patents will expire in 2028 https://meta.wikimedia.org/wiki/Have...expired_yet%3F

I'm interested in the first version of h264. I am aware that there were subsequent features added, but if I don't use them then it shouldn't issue. As that page says:

"Version 1 of H.264 (containing Baseline, Main, and Extended profiles) may have all patents already expired in some country (for example in Europe), you could consider using it."

If I only want to encode video that plays, I should be fine as long as I use the original encoder. I don't care about SVC or 3D video.

[Artim]

I was originally referring to 1080p 30 fps non-HDR 8bit H.264 original / H.264 output. I observe around 5x real-time encoding performance. This is with 5950X (16 cores), RX 7900 XTX, 2 x 32 GB DDR4-3600 CL14, Samsung 980 Pro 2 TB (up to 5100 MB/s). The final video was around 800 MB and 100 minutes in size. So it took 20 minutes to render the video (around 670 kB/s). A 1,2 MB floppy RAID-0 system (8bit Intel 8271 Floppy disk controller, Intel 8257 DMA controller from the year 1977) can write around 250 kB/s. That was 47 years ago.

Yes, h264/x264 is dirt slow. But nobody cares enough about it anymore to change that. If you want speed, use something made for that.

[Artim]

H264 patents will expire in 2028 https://meta.wikimedia.org/wiki/Have...expired_yet%3F

Doesn't mean there are any patents on x264.

[joepadmiraal]

I think people here vastly oversimplify the work that an h264 encoder has to do.
By the way, a lot of people deliberately choose a software encoder like x264 instead of a hardware encoder because the software encoders still outperform the hardware encoders in terms of picture quality and settings you can tune.

The speed of h264 compression heavily depends on a lot of factors like content, bitrate, quality settings, etc.
For example I was doing x264 for a livestream and it was running fine, until we turned the camera to a scene with a lot of water, the cpu completely overloaded because of all the tiny non repetitive details it had to encode.
Also all encoders (both hardware and software) I have worked with have at least a simple quality setting which heavily impacts frames/second they can push.

[brad0]

Doesn't mean there are any patents on x264.

Except that is exactly what it means.

[pWe00Iri3e7Z9lHOX2Qx]

Doesn't mean there are any patents on x264.

x264 is a free and open source encoder and there are no patents to worry about on its code. Doesn't mean that there still aren't H.264 patents to deal with. The x264 FAQ used to include this...

Does the x264 license include AVC patent royalties?

No, it does not. You will need to get a separate patent license from MPEGLA, see: http://www.mpegla.com for more info .

[Artim]

Except that is exactly what it means.

Nonsense. x264 created a bitstream that can be decoded by the same means for h264, yet circumventing the patents on h264. That was the whole point of x264 and x265. Or with the words of the videolan team:

x264 is a free software library and application for encoding video streams into the H.264/MPEG-4 AVC compression format, and is released under the terms of the GNU GPL.

Or how do you think it would be possible to publish an encoder under GPL that's violating existing patents? Maybe the MPEG LA even tried to sue them, yet obviously never had any success, otherwise it wouldn't have been part of ffmpeg for so many years.

[caligula]

I'm interested in the first version of h264. I am aware that there were subsequent features added, but if I don't use them then it shouldn't issue. As that page says:

"Version 1 of H.264 (containing Baseline, Main, and Extended profiles) may have all patents already expired in some country (for example in Europe), you could consider using it."

If I only want to encode video that plays, I should be fine as long as I use the original encoder. I don't care about SVC or 3D video.

Well, in case you missed the previous mp3 fiasco, mp3 codecs became kosher for 100% libre distros only after the very last patent in the pool expired. Decoding of CBR (non join) stereo 128 kbps was free long before. I think all the technology was already invented by 1993 or 1994. So it still took something like 5 years longer for distros (maybe even longer for server and LTS distros) to accept the fact and start shipping the libraries.