Alliance for Open Media codecs

[NikosD]

https://www.youtube.com/watch?v=UhIgBdrKyNM - Dav1d: a fast new AV1 decoderThis is a very fast decoder.

Using just C with almost no ASM and no SIMD at all, they managed to be 60% faster than libaom v1.0.0.0 and capable of 1080p decoding of a 4Mbps clip at 50fps using 4 cores.

In the presentation they said that they are expecting the SIMD version to hit a 4x decoding acceleration, meaning 200 fps for 1080p using 4 cores.

That would be probably the biggest step up in software decoding SIMD acceleration.

[NikosD]

If someone could build and provide latest libaom and dav1d decoders in DirectShow filter form, I'm interested in opening a new thread for AV1 decoder's evaluation.

I have various CPUs from Core 2 Duo to Haswell, so I can follow the improvements in ASM, MultiThreading and SIMD acceleration for both AV1 decoders.

BTW, are there any other AV1 decoders ?

But I need them to be registered as DirectShow filters.

[foxyshadis]

I have seen 50% reduction at very low bitrates and UHD resolutions. But for moderately grainy SD/HD content, x264 versus x265 is more like 30%.

Grain/noise parameterization and reconstruction is probably the single biggest next step in encoding performance, since random noise is intrinsically uncompressible.


I have a feeling that video standards are eventually going to have a similar come-to-jesus moment that graphic card makers faced when they were finally called out for totally ignoring minimum FPS. That led to some pretty big driver changes within a year, but video standards have a much longer lead time....

[NikosD]

...I did however notice that, out of the three cores being utilized on my Xeon x3470, one of them is pretty much fully pegged and the other two are about half utilization - this would then equal the ~25% utilization I'm seeing.

Now normally I would let this all go as simply a case of "not having fast enough single-threaded performance" and be done with it, but the fact that you and others were seeing over 60% utilization on your own 4c/8t CPUs (which implies it was balancing the load across more than 4 threads) makes me thing something still isn't quite right here - I mean, weaker single-threaded performance shouldn't result in fewer threads being utilized, and if anything you'd want it to be the opposite, no?

My preliminary results for LAV x64 0.72.0-15 and MPC-HC v1.8.2 using libaom v1.0.0-552 show me only ~75% CPU utilization of a 2C/4T Haswell Core i3-4170@3.7GHz, meaning that the current status of libaom decoder is an up to 3 threads SMT implementation.

The above situation leads to a ceiling in performance of course, meaning that a lot of 1080p AV1 samples out there, are simply not real-time decoded by libaom.

Probably even the no SIMD version of dav1d as it is right now, due to the 4 threads implementation IIRC, could do it better.

But generally speaking, "we need a bigger boat"

[clsid]

The number of threads for libaom depends on the number of tiles in the video.

Newer libaom build is already 10-15% faster. You should wait with tests until dav1d gets into FFmpeg/LAV. Then libaom as decoder will become obsolete.

[NikosD]

The number of threads for libaom depends on the number of tiles in the video.
The number of tiles is a property of the video created by the encoder or is it something that is been created by the decoder ?

[LigH]

The encoder decides that, usually based on the resolution of the video, especially the height, if it was not specified expliticly as parameter.

[NikosD]

By watching the presentation of dav1d, he gave me the impression that a tile-based decoder decides the number, the scheme, the orientation etc of the tiles, but without saying too many details in the presentation.

Wrong impression obviously.

[Beelzebubu]

Sorry if that created confusion; tiles (and thus the amount of tile threads a decoder can use) are set by encoder; frame threads is selectable by decoder without requiring special encoder settings.

[user1085]

Sorry if that created confusion; tiles (and thus the amount of tile threads a decoder can use) are set by encoder; frame threads is selectable by decoder without requiring special encoder settings.For comparison with other decoders for H.265, H.264, do we know how many threads they use?

[Beelzebubu]

Depends on the implementation. FFmpeg's decoders for H264/HEVC typically use only frame threads in the default configuration, the exact number depends on the number of cores on your system. OpenHEVC allows you to combine frame and wave-front threading (similar to x265). Frame+Tile - like Frame+WFP - allows better scaling at ultra-high resolutions or very low-end systems, but is not typically necessary for real-time playback on normal systems.

[olduser217]

Sorry if that created confusion; tiles (and thus the amount of tile threads a decoder can use) are set by encoder; frame threads is selectable by decoder without requiring special encoder settings.

For AV1, decoder frame threading is related to encoder (bitstream encoded) too.
CDF tables can be updated (or not updated) at the end of decoding for a frame, depending on a frame header syntax element in the bitstream.

If the CDF tables need to be updated at the end of the decoding for a frame, then frame threading should be impossible.

[jonatans]

- https://www.fsf.org/blogs/licensing/googles-updated-webm-license : "Unfortunately, the interaction between the copyright license and the patent license made the result GPL-incompatible. Based on the concerns of developers writing GPL-covered software, Google publicly stated that they would take some time to review the WebM license and try to address the community's concerns. Today, they released a revised license, and it is GPL-compatible."
"The most important part of the change is that Google has separated the patent license from the copyright license. Now the copyright license on the software is a totally standard three-clause BSD license, which is clearly compatible with the GPL. The patent license, in turn, provides distributors with permission to exercise all the rights, and meet all the conditions, in the GPL, as required by GPLv2 section 7; and those permissions are consistent with the ones provided by the patent grant in GPLv3 section 11. All this means that developers distributing GPL-covered software can take advantage of the patent license without running afoul of the GPL's conditions, whether they're using GPLv2 or GPLv3."

Does it still apply to AV1?

Yes, it does.

Well.. the problem still applies to AV1. But the solution does not ;)

In WebM, the software license and patent license are clearly separated https://www.webmproject.org/license/ "The WebM codec source code and specification are licensed differently."

In AOM, the software license and patent license are clearly combined https://aomedia.org/license/ "Software released by the Alliance for Open Media is made available under a combination of the following licenses"

[Nintendo Maniac 64]

How do you turn on motion interpolation?
I'm using third party software for that - it is not part of MPC-HC, LAVfilters, nor AV1.

I was just making a point about how much CPU headroom I still had is all.

[NikosD]

Sorry if that created confusion; tiles (and thus the amount of tile threads a decoder can use) are set by encoder; frame threads is selectable by decoder without requiring special encoder settings.
For AV1, decoder frame threading is related to encoder (bitstream encoded) tooThank you for your comments.

Then it must be a great coincidence that all three AV1 clips I tried to decode had 75% CPU utilization on a four threaded CPU.

Is it some kind of default settings of the encoder to produce such clips ?

Can you post a sample that libaom decoder can use 4 threads or more during decoding ?

Thank you.

[Beelzebubu]

If the CDF tables need to be updated at the end of the decoding for a frame, then frame threading should be impossible.

The VDD presentation explains how we still accomplish frame threading in this scenario. Efficient frame threading is possible, even with CDF table dependencies. We did this in ffvp9 also, there is nothing new about this approach.

[olduser217]

The VDD presentation explains how we still accomplish frame threading in this scenario. Efficient frame threading is possible, even with CDF table dependencies. We did this in ffvp9 also, there is nothing new about this approach.

Thanks for the information.
Do you mind to point out the link to the presentation if it is available?

[Beelzebubu]

Thanks for the information.
Do you mind to point out the link to the presentation if it is available?

https://www.youtube.com/watch?v=UhIgBdrKyNM

[Adonisds]

I'm using third party software for that - it is not part of MPC-HC, LAVfilters, nor AV1.

I was just making a point about how much CPU headroom I still had is all.

I understood your point. But I'd like to start using motion interpolation for all my videos. What software do you use?

[Adonisds]

Would a modern 8 core/16 threads processor be able to software decode av1 4k60 hdr video once the decoder is more optimized?

[Blue_MiSfit]

I'd better hope so! If not, AV1 is going to have a hard time.

[mzso]

Honestly, finding real-world scenarios where libvpx can deliver better quality @ bitrate @ perf than x264 is a challenge, although I suspect that's primarily due to x264's massively greater psychovisual tuning and perf optimization efforts, not differences in the bitstream standards.

When was the last time a now format's encoder could beat the predecessor in bitrate and performance at the same time? Those days are gone it seems to me.

[alex1399]

The HEVC have tried very hard to not let its decode complexity overwhelm the decode complexity of AVC too much. In modern days, AV1 could try something better with the cost of decode complexity.

[Nintendo Maniac 64]

What software do you use?

SVP (http://svp-team.com/).

Note that there are several variants of it:
the old SVP 3.1.7 is free but only works on Windows and with programs like MPC-HC; also it might only work with 32bit media players.
the full-featured version of SVP 4 is only free on Linux and works with VLC and mpv.
the basic yet free version of SVP 4 which only works on Windows and with programs like MPC-HC much like v3.1.7, but has considerably reduced configuration options compared to both the full-featured version and the old 3.1.7 version.
the paid full-featured "Pro" version on Windows and Mac is largely identical to the free version of SVP 4 on Linux, though on Windows it also works with MPC-HC as well as VLC and/or mpv.

One thing to keep in mind is that interpolating to refresh rates that are exact multiples of the source framerate will provide a smoother result with fewer artifacts - e.g. 30fps interpolated to 120Hz (4x) is better than 30fps interpolated to 144Hz (4.8x) - this is most easily accomplished with something like like MPC-HC's or madVR's built-in automatic resolution changer which can be used to change your refresh rate depending on a given video frame rate (though you may need to create a custom resolution in order to access certain refresh rates on your display).

[Blue_MiSfit]

Yikes, no thanks. Looks like the motion interpolation on every TV these days :(

[Nintendo Maniac 64]

Yikes, no thanks. Looks like the motion interpolation on every TV these days :(

...what were you expecting? That's simply what motion interpolation is.


If you don't like high framerate video, then no amount of motion interpolation is going to look good - that's the goal of motion interpolation after all.

If you simply don't like interpolation artifacts, then certainly a piece of software designed to run at fullspeed with cranked settings on even a 10-year old quad core CPU isn't going to deliver a cleaner image than dedication interpolation hardware in modern TVs.


It is worth mentioning however that the Linux version, Pro versions, and the old v3.1.7 do have "2m (min artifacts)" and "1.5m (less artifacts)" settings as well as a "32 px. Large 0" setting that are particularly ideal for people that dislike high motion interpolation but still want improved motion resolution.

Additionally, it can make a big difference how your source content was originally recorded - my main use is for motorsports that are actually natively recorded and broadcast at 50fps but are then downsampled to 25fps for internet streaming (I'm looking at you Formula E). These sorts of 50fps --to-> 25fps content retains the faster camera shutter speed of the original 50fps recording which means that applying motion interpolation will make it look much more akin to native HFR content than what you'd get if you interpolated 24fps movie content recorded with a slow camera shutter speed (as is typically used in cinema).

And in my opinion, applying motion interpolation with cranked settings for native 50fps motorsports on a 100Hz CRT is glorious - the sense of speed you get from the cars that way is just unmatched!



________EDIT________

I just don't care for motion interpolation at all.
But you didn't say what aspect it is that you don't like, so I felt it necessary to try to answer every angle I knew of.


Now I know a lot of people don't like the artifacts, but that would practically require something like a Threadripper 2990WX + 64GB RAM + a GPU with Nvidia's A.I. Tensor cores in order to have truly artifactless interpolation that looks like real native HFR.

Keep in mind however that the higher the native frame rate of the video, the less artifacts there are: 50fps --to-> 100Hz has quite a bit fewer artifacts than 25fps --to-> 100Hz, and since 50fps is natively HFR anyway the overall "feeling" isn't exactly Earth-shatteringly different either when using interpolation.

Also interpolation in general can be a god-send for low framerate content like 15fps (which is what my father's smartphone camera uses for videos recorded in low-light situations) that can otherwise look really choppy (such as a recently recorded fireworks video he took).


Let's get back to AV1 :)
Hey now, you were the one that decided to not ignore the subject and "let my post be". :p It was even at the end of a page which would have allowed it to have easily been ignored.

[Blue_MiSfit]

So we're getting OT here, but if you like this stuff - great!

I just don't care for motion interpolation at all.

Let's get back to AV1 :)

[Nintendo Maniac 64]

It seems that LAVfilters v0.73 / MPC-HC v1.8.3 improves AV1 performance a tad (~20% faster), but it's multi-threaded utilization is still poor (only ~26% utilization with 4c/8t Nehalem).

The biggest benefit I found is that only using dual core no longer completely tanks performance.


Utilizing a Nehalem Xeon x3470, I had the following performance when trying to decode the 1080p AV1 video-only stream from Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview (https://www.youtube.com/watch?v=_fAOe8oz8qM) in MPC-HC v1.8.3 64bit:
4c/8t @ 2.93GHz: ~20fps
4c/8t @ 3.20GHz: ~22fps
3c/3t @ 3.20GHz: ~22fps
2c/4t @ 3.46GHz: ~20fps
2c/2t @ 3.46GHz: ~20fps

Anything above 3c/3t still sees no benefit, and SMT still sees no utilization (though Nehalem's implementation of SMT is certainly going to be weaker than more modern implementations e.g. Ryzen).

[benwaggoner]

Would a modern 8 core/16 threads processor be able to software decode av1 4k60 hdr video once the decoder is more optimized?
Can a modern system do that for HEVC? HEVC decode is going to be more inherently parallelizable due to WPP. And I'm not aware of any software decoders that can do a realtime 2160p60 HEVC on any hardware I've looked at.

That kind of pixel fill rate is normally the domain of hardware decoders, or at least hybrid CPU-GPU implementations (like the Xbox 360 H.264 decoder).

For commercial content, the DRM hardware requirements to play UHD on a PC has always come on systems that have a 2160p60 HW decoder anyway. Since there is already a large installed base with has the DRM support bu not HW AV1, I would expect HEVC to remain the dominant codec for delivering premium UHD content for years to come.

But I believe Profile @ Level for AV1 requires some degree of tiling for UHD resolutions. Even if not required, I imagine some de facto guidelines about tiling to improve decode perf would become standard.

Parallelizing decode of Golden/IDR, I, P, B, and b frames can also be a useful technique if plenty of memory is available. You'd just do a lookahead to encode and buffer the referenced frames in tier order. That was nigh impossible with VP9, but I think is feasible for AV1.

[LigH]

New uploads: (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)

AOM v1.0.0-735-g9b21428c8 (https://www.mediafire.com/file/y9981oqyft1987f/aom_v1.0.0-735-g9b21428c8.7z)

rav1e 0.1.0 (4d185f7 / 2018-10-04) (https://www.mediafire.com/file/r05hl811nnlm15n/rav1e_0.1.0_2018-10-04_4d185f7.7z)

dav1d 0.0.1 (c6788ed / 2018-10-04) (https://www.mediafire.com/file/6j3ip3u28u9n1ab/dav1d_0.0.1_2018-10-04_c6788ed.7z)

[Nintendo Maniac 64]

Can a modern system do that for HEVC? HEVC decode is going to be more inherently parallelizable due to WPP. And I'm not aware of any software decoders that can do a realtime 2160p60 HEVC on any hardware I've looked at.

I just did some tests with my trusty 4c/8t Nehalem Xeon x3470 @ 2.93GHz, and I was able to play back a particularly intensive 40fps (not a typo) 3840x2160 20Mbps HEVC video clip without issue, though it seems just barely as even 41fps resulted in stuttering.

So at least for 60fps 4k HEVC at the same 20Mbps bitrate, you would only need at most 50% more CPU horsepower, though if it was 60fps 30Mbps then you might need 100% more CPU horsepower.

...however, even 100% more performance should be relatively easy to achieve when you consider the following:
Modern CPU architectures (Haswell and Zen1) are ~50% faster clock-for-clock than Nehalem (and Sky/Kaby/Coffee Lake has even faster IPC as will Zen2)
Having 50% more CPU threads (6c/12t) is quite common nowadays and can now even be had in high-end laptops (not to mention that 8c/16t is also a thing)
50% higher clockspeed (4.4GHz) is right around the max turbo speed for modern higher-end desktop CPUs on both Intel and AMD (and ~5GHz overclocks are not at all uncommon anymore)

Combine all three aspects and you should not only be able to play 4k HEVC @ 60fps without issue, but you could probably even do it at 90fps if not 120fps.

[nevcairiel]

Consumer bitrate HEVC content can definitely software decode through ffmpeg/avcodec on a high-end'ish machine at 4K 10-bit 60 FPS (ie. like those 60 FPS UHD Blu-rays). WPP isn't really needed for that either, since its a bitstream feature thats not mandatory. Frame-based threading is fine.

[benwaggoner]

I just did some tests with my trusty 4c/8t Nehalem Xeon x3470 @ 2.93GHz, and I was able to play back a particularly intensive 40fps (not a typo) 3840x2160 20Mbps HEVC video clip without issue, though it seems just barely as even 41fps resulted in stuttering.

So at least for 60fps 4k HEVC at the same 20Mbps bitrate, you would only need at most 50% more CPU horsepower, though if it was 60fps 30Mbps then you might need 100% more CPU horsepower.

...however, even 100% more performance should be relatively easy to achieve when you consider the following:
Modern CPU architectures (Haswell and Zen1) are ~50% faster clock-for-clock than Nehalem (and Sky/Kaby/Coffee Lake has even faster IPC as will Zen2)
Having 50% more CPU threads (6c/12t) is quite common nowadays and can now even be had in high-end laptops (not to mention that 8c/16t is also a thing)
50% higher clockspeed (4.4GHz) is right around the max turbo speed for modern higher-end desktop CPUs on both Intel and AMD (and ~5GHz overclocks are not at all uncommon anymore)

Combine all three aspects and you should not only be able to play 4k HEVC @ 60fps without issue, but you could probably even do it at 90fps if not 120fps.
Good analysis. Thanks!

This suggests that common consumer system isn’t likely to be able to do SW 2160p60 decode for some time to come. It seems likely to me that the installed base of computers that can decode 2160p60 HEVC in HW is many times higher than that can do it in SW.

Also, 60p isn’t THAT common in professional content; it’s mainly seen with sports. Entertainment seems stubbornly stuck at 24p, which is a lot easier to decode.

Most PCs don’t have UHD displays, of course, and many of the devices that do have a pixel size so small that delivering UHD resolutions is kind of pointless (on a 15.4” 3840x2160 display, a well-encoded 1080p 24-60p isn’t going to be obviously degraded compared to a 2160p on the same screen).

But for cases where UHD playback, particularly at high frame rates, matters, HEVC is going to have a much bigger installed base beyond 2020.

[dapperdan]

Mozilla Research grants available to work on AV1 related projects:

https://mozilla-research.forms.fm/mozilla-research-grants-2018h2/forms/5348

Core Web Technologies: Mozilla has been deeply involved in creating and releasing AV1, an open, royalty-free video encoding format. We are looking for someone to port the rate control model from Theora/Daala to AV1, and to explore how best to use novel AV1 features like alt-refs and frame super-resolution to optimize the result.

[MoSal]

i7-7700K is capable of software-decoding HEVC 4K@60fps (10bit, >50mb/s) in real time using ffhevc. But a faster CPU (or a faster decoder) is probably required for smooth day-to-day usage.

The better optimized ffvp9 decoder is way way faster than ffhevc. I know the theoretical complexity of HEVC and VP9 decoders is not the same. But the gap here is really largely attributed to better optimizations.

Assuming dav1d will reach a sufficiently-optimized state in months, I think we can conservatively predict that above mid-range devices sold in 2019 should be capable of software-decoding AV1 4K@60 fps just fine.

[Blue_MiSfit]

My 6700k at work struggles to decode 4kp24 VP9 in software (in latest Chrome playing 4k YouTube content). Switch on hardware decoding, however, and my little GTX 960 does it without breaking out a sweat (windows reports approx 30% decode utilization).

Software playback of 4kp60 AV1 on 8 modern cores seems like a reasonable target to me, but it's kind of a moot point. Your average consumer watching 4k videos on YouTube probably doesn't have an 8 core CPU. I certainly don't, and I'm a hardcore tech / video nerd :)

I think YouTube will be using VP9 for 4kp60 VOD for quite some time, since there's lots of hardware decoders out there by now, and Google takes a very dogmatic position against HEVC

[Nintendo Maniac 64]

My 6700k at work struggles to decode 4kp24 VP9 in software
That's strange as I can play a 2160p30 VP9 YouTube video at 47fps (therefore has an effective bitrate of 28Mbps) in MPC-HC v1.8.3 x64 on my Xeon x3470 which is basically just a 1st gen i7, so surely a 6th gen i7 should have no issue with 60fps 4k VP9 let alone 24fps.

in latest Chrome
...oh, that might be the problem.

If you play the exact same VP9 video stream in MPC-HC then it should be a total cakewalk for your 6700k; I believe this is because Chrome uses the libvpx decoder while MPC-HC and LAVfilters uses ffvp9.

It's my impression that Firefox also utilizes ffvp9, so you may be able to alternatively use that instead of Chrome in order to get performance similar to what is seen with MPC-HC/LAVfilters.

[Clare]

If you want to patch ffmpeg to use libdav1d, I have this patch: https://gist.github.com/WyohKnott/09e84e4fc9f67fc1b8190a9855119ba9

To test with mpv, use mpv --vd=libdav1d

Some Rav1e data: https://wyohknott.github.io/video-formats-comparison/rav1e.html

Speed is there but the quality is way way below x264 for now.

[NikosD]

Would a modern 8 core/16 threads processor be able to software decode av1 4k60 hdr video once the decoder is more optimized?I'd better hope so! If not, AV1 is going to have a hard time.It seems that LAVfilters v0.73 / MPC-HC v1.8.3 improves AV1 performance a tad (~20% faster), but it's multi-threaded utilization is still poor (only ~26% utilization with 4c/8t Nehalem).
Anything above 3c/3t still sees no benefit, and SMT still sees no utilization (though Nehalem's implementation of SMT is certainly going to be weaker than more modern implementations e.g. Ryzen).Can a modern system do that for HEVC? HEVC decode is going to be more inherently parallelizable due to WPP. And I'm not aware of any software decoders that can do a realtime 2160p60 HEVC on any hardware I've looked at.Consumer bitrate HEVC content can definitely software decode through ffmpeg/avcodec on a high-end'ish machine at 4K 10-bit 60 FPS (ie. like those 60 FPS UHD Blu-rays). WPP isn't really needed for that either, since its a bitstream feature thats not mandatory. Frame-based threading is fine.i7-7700K is capable of software-decoding HEVC 4K@60fps (10bit, >50mb/s) in real time using ffhevc.If you want to patch ffmpeg to use libdav1d, I have this patch.
In your analysis following the initial question, you missed the single most important parameter regarding SW decoding speed which is not resolution (4K), frame rate speed (60fps) or quality (10bit).

It's bitrate/ bandwidth.
The UHD Blu-rays mentioned above, are 4K60fps HDR10 at 140Mbps HEVC video stream.

Please, find me a non HEDT CPU that could decode such stream in real-time.

I mean I doubt if Ryzen 2700X could do it or the Core i9 9900K that announced yesterday.

So, regarding decoding of 4K60fps AV1 at similar bitrates of 140Mbps is surely out of question.

Now, regarding AV1 decoding progress, latest LAV 0.73 using libaom is around 13% faster than previous libaom version of LAV 0.72.x which is really impressive and this is something I mentioned at LAV filters thread, the progress of libaom.

Still, it seems to me as a 3 threaded decoder.

Eventually, it looks like dav1d is not the only AV1 decoder progressing and the battle for the fastest AV1 decoder is still alive.

[clsid]

If you want to patch ffmpeg to use libdav1d, I have this patch: https://gist.github.com/WyohKnott/09e84e4fc9f67fc1b8190a9855119ba9Is this compatible with latest dav1d git head? I can successfully build dav1d and the ffmpeg libs (for LAV Filters) but it crashes at playback start.

dav1d.exe is working ok, but annoying that it requires outputting to a (huge) file.

[Clare]

Is this compatible with latest dav1d git head? I can successfully build dav1d and the ffmpeg libs (for LAV Filters) but it crashes at playback start.

dav1d.exe is working ok, but annoying that it requires outputting to a (huge) file.

Yeah you need a recent GIT, I used da97ba3f from Oct, the 4th.

[Mr_Khyron]

https://www.youtube.com/watch?v=rMgUk002JrU

[Nintendo Maniac 64]

It's bitrate/ bandwidth.
The UHD Blu-rays mentioned above, are 4K60fps HDR10 at 140Mbps HEVC video stream.

To my credit, I've started mentioning bitrate in my more recent posts talking about HEVC and VP9 decoding performance for this very reason. I also linked to the AV1-encoded YouTube video clip that I was testing with, so one could always find out the bitrate themselves if they absolutely needed to know what it was.


Nevertheless, I personally think that 4k AV1 encoded at anything higher than 50Mbps will be extremely unlikely to exist in the wild even at 120fps. The major reason for this is because it's my impression that current video streaming services already only use ~20Mbps for their 4k 24fps content with codecs that are less efficient than AV1, and higher framerate do not require a linear increase in bitrate (last I checked, YouTube used only 33% to 50% more bits for 60fps compared to 30fps, yet the 60fps encode always looked better).

Now while that only covers internet streaming and not the likes of disc media, I see it even more unlikely for AV1 to be adopted for such a thing due to a case of "not invented here" syndrome with the MPEG-LA and the various companies more interested in traditional broadcast media and the like. The one exception to this might be game consoles, but they require relatively modern and/or high-end GPUs anyway and therefore are extremely likely to have AV1 hardware decoding...and even then, as graphics become better and better, there becomes less and less of a need to utilize any sort of pre-recorded video (which takes up more storage capacity) rather than just rendering the scene in real-time.

[mzso]

In your analysis following the initial question, you missed the single most important parameter regarding SW decoding speed which is not resolution (4K), frame rate speed (60fps) or quality (10bit).

It's bitrate/ bandwidth.
The UHD Blu-rays mentioned above, are 4K60fps HDR10 at 140Mbps HEVC video stream.

Please, find me a non HEDT CPU that could decode such stream in real-time.

I mean I doubt if Ryzen 2700X could do it or the Core i9 9900K that announced yesterday.

So, regarding decoding of 4K60fps AV1 at similar bitrates of 140Mbps is surely out of question.


Why bother using a more efficient format if you're hellbent on wasting bandwidth anyway? Use 50Mbps max or stick with HEVC/AVC. (Blu-rays throw bandwidth at the problem instead of using efficient encoders to begin with.) Typical FullHD movies are (or can be if encoded efficiently) essentially perfect as far as human perception is concerned, so even with AVC you would only need at most 100mbps to match it at UHD@60p. And HEVC is supposed to be more efficient than AVC.

[Mr_Khyron]

There are some 4K AV1 samples to download here
https://www.elecard.com/videos :cool:
I can play them with MPC-HC 1.8.3 and LAV Filters 0.73.0-1

[NikosD]

I can play them with MPC-HC 1.8.3 and LAV Filters 0.73.0-1
And your CPU is ?

[benwaggoner]

There are some 4K AV1 samples to download here
https://www.elecard.com/videos :cool:
I can play them with MPC-HC 1.8.3 and LAV Filters 0.73.0-1
Including the UHD clips?

Also, does anyone know if the sources for those clips are available? This would be a great chance to do some apples-to-apples comparisons!

[Mr_Khyron]

And your CPU is ?

Including the UHD clips?

Also, does anyone know if the sources for those clips are available? This would be a great chance to do some apples-to-apples comparisons!
My Cpu is a Ryzen 1700 and when i play the UHD clips all cores are at %40 and i get between 8-16 fps

[benwaggoner]

My Cpu is a Ryzen 1700 and when i play the UHD clips all cores are at %40 and i get between 8-16 fps
Ah! Not at real-time then.

[nevcairiel]

For the record my i9-7900X@4.5G can play those Elecard UHD clips in realtime with libaom through LAV Filters (achieves ~33 fps on the 22mbit clip, the clip is 25 fps). Considering the state of the multi-threading in libaom, the 10 cores aren't really doing me any good, so it must be the relatively high clock I have it running at, and full AVX2.

Judging by these results, and the limited number of threads it uses now, with proper threading and more optimizations, I have no doubt that such clips would run fine on 2018/19 mainstream CPUs (ie. decently clocked quadcores with AVX2 and above), once the decoders are fully done. Of course the highest clip they had was 22mbit only, but considering AV1 is more likely to become a web format then a optical disc format, extremely high bitrates are probably going to remain very rare.