Bad performance after the threading model change

Hi EveryOne,

At the first commit of v0.93 (after the release of v0.92), there is a "Merge the 3 threading models into a single one". 753eef83

Has anybody made before/after performance tests at this change?

Because the memory usage seems to be ~50% more (850 Mb vs. 1250 Mb at 4K/10-bit content) and sometimes the CPU load is also higher with ~10% (55% vs 60% at 4K/8-bit content), comparing the libdav1d 0.92 final and the 0.93 first commit with the new threading model.

I use libdav1d and FFmpeg 4.4.1 static x64 builds with my video player application, on Windows 10, with a Core i7 CPU, probably AVX2 compatible.

The programatic difference can be that the FFmpeg lib uses unique thread number calculation/configuration at the older libdav1d (in libavcodec/libdav1d.c), which seems to be better than the new libdav1d internal code.

Performance has been tested extensively and generally shown to be equal or better while requiring less active threads.

If you are using a new dav1d, you should stop using the old framethreads and tilethreads options, and just specify a thread count you want using -threads.

Note that there is no "0.9.3", and you should always compare the very latest version, not the first version, as additional improvements have been made to the threading implementation.

Could you share the clip you experienced this issue with? I think it's worthwhile testing and making sure there's nothing bad lurking in the shadows.

I use YT videos, downloading them with 3D Youtube Downloader, playing locally.

This video has a 4K, 10-bit HDR AV1 stream too (MP4 2160p 3840x2160 30fps 918.85 MB): https://youtu.be/5LxsViMm25o

Another 4K/8-bit video with AV1 stream (MP4 2160p 3840x2160 30fps 524.67 MB): https://youtu.be/U-6wqFE79Gc

(my CPU is not enough strong to decode 8K AV1 content, so I do testing with the 4k AV1 streams)

Btw. there is a small bug in FFmpeg too: there is a 1.5 multiplier at the thread count. Removing it, I get a little less memory footprint (now it's only 50% more, not double). I still see higher CPU load at 8-bit content (the 2. video), but I have no proper tool to measure the real decoding speed.

Maybe the FFmpeg's thread config is still wrong, but I don't know how could it be better. The 'n_threads' is set to the number of logical cores (it seems).

I've tested/compiled a newer (01 Nov, 2021) libdav1d version too, but I don't see significant difference relative to the "threading model change" commit.

changed the description

Could you also share what system this was on? Particularly, how many cores, what CPU, how much memory do you have?

Btw. there is a small bug in FFmpeg too: there is a 1.5 multiplier at the thread count. Removing it, I get a little less memory footprint (now it's only 50% more, not double). I still see higher CPU load at 8-bit content (the 2. video), but I have no proper tool to measure the real decoding speed.

It's not a bug. It was done on purpose back in the day for the old threading model, but for the new one it's no longer needed. I'll backport the commit that removed that to the 4.4 branch.

Regarding the memory footprint, there isn't really an issue in the model, just in defaults. In the old system, FFmpeg would use n_threads = 1.5 * n_cores, and then use n_tilethreads == n_framethreads and n_tilethreads * n_framethreads == n_threads. Frame threads account for the large majority of memory usage, and n_framethreads = sqrt(1.5 * n_cores), and therefore memory is proportional to sqrt(1.5 * n_cores).

In the new system, we use (by default) max_framedelay = n_threads, and n_threads = n_cores. This means memory usage is now proportional to that (n_cores), which is higher than before for n_cores > 1 integer values.

This can easily be addressed by using a default max_framedelay = ceil(sqrt(n_threads)), but that introduces a libm dependency which I'm not sure we want to add. But that would perform roughly equally well on most content and use less memory.

I'm downloading one of the videos now to look further into this, it's slow & will take a while (~2hrs ETA).

I've prepared FFmpeg executables with different versions of LibdAV1d: "v0.92 release", "Sept 3. 2021." (threading model change) and "Nov 5. 2021."

At pure/native decoding, the new threading model seems to be faster, the only remaining disadvantage is the bigger memory footprint: ~350 Mb vs ~570 Mb at the 2nd (4k/8-bit) test file.

Speed test results of FFmpeg.exe with 3 different libdav1d versions on Intel Core i7 8650U / 16G RAM / Win10:

(command line is: ffmpeg441_[libdav1d_version].exe -i 4K_NEW_ZEALAND_ASCENDING.mp4 -f null -)

libdav1d v0.92 : frame=12063 fps= 76 q=-0.0 Lsize=N/A time=00:06:42.54 bitrate=N/A speed=2.55x

libdav1d Sept 3.: frame=12063 fps= 82 q=-0.0 Lsize=N/A time=00:06:42.54 bitrate=N/A speed=2.74x

libdav1d Nov 5. : frame=12063 fps= 80 q=-0.0 Lsize=N/A time=00:06:42.54 bitrate=N/A speed=2.68x

I don't know why does the task manager show +5-10% CPU usage in a "videoplayer environment".

(I've got this at several 4k/8-bit files, not only at the given YT example)

If you have further ideas for the FFmpeg thread config, please let me know.

You can download the executables, the modified (FFmpeg's) libdav1d.c and the test_log.txt from here: FFmpegLibdAV1dSpeedTest

the only remaining disadvantage is the bigger memory footprint

That is because of config changes. Try reducing maxframedelay to reduce memory usage.

mentioned in merge request !1339 (merged)

closed with merge request !1339 (merged)

closed with commit b562b7f6

changed milestone to %1.0.0

added feature performance labels