Memory / CPU issue with AV1 decoding

[jurisbu]

OS: Linux Arch RAM: 32GB

YUView Version v.2.12

I experience frequent oom kills of YUView due to memory full:

kernel: Out of memory: Killed process 65648 (YUView) total-vm:29111464kB, anon-rss:25797984kB, file-rss:0kB, shmem-rss:15904kB, UID:1000 pgtables:52828kB oom_score_adj:0

My workflow is comparing 2 different video encodes (one being AVC the other AV1) in Comparison split view. Video clips are ~2min long usually. I frequently see that playback from start to end in such case will result in all RAM consumed be YUView and short system lockup until oom kill happens.

I checked that comparing in split view two AVC encodes will not trigger the issue. Looks like AV1 decode is the culprit.

[jurisbu]

Did a bit more testing and I think indeed the culprit might be AV1. I observe rapid memory use increase during AV1 video playback.

Another thing I noticed that reaching end of playback YUView will be "stuck" using 100% CPU time. But application itself is responsive, meaning I can load another video and do playback at which point CPU usage will normalise.

[ChristianFeldmann]

Hi! Thanks for the report. Yes this all sounds like the AV1 decoder (we use Dav1d) implementation has a problem. The CPU utilization at the end of the sequence could also be an indication to this (maybe a problem with flushing the decoder) and the memory issue may be related to proper release of memory. Thank you for the report. I will try to reproduce this.

[ChristianFeldmann]

Hi! So I did some quick debugging session and could not reproduce the issue. Could you let me know which version of the decoder you are using? Also could you somehow provide me with one of the bitstreams that you use? I tried with a small bitstream that I just created using ffmpeg but as I said I could not observe the problem there.

[jurisbu]

@ChristianFeldmann Unfortunately I cannot share production bitstreams. I will look into if I can reproduce issue with some other source clip (BBB maybe). Will let you know about my findings this week.

ON a related note, what information would you like me to gather? Since I install YUView from Arch AUR there may be differences in libraries used. I can try and gather versions if that makes sense.

[jurisbu]

Adding more information.

• I am running YUView built via Arch AUR, but patched to use commit 586bec283a549de91362573688e7ac0bd5a85738 with AV1 bitrate plot fix.
• dav1d 0.9.2-1

I tested with this clip: http://www.caminandes.com/download/03_caminandes_llamigos_1080p.mp4 which was encoded to AV1 with SVT-AV1 with following command:

INPUT=03_caminandes_llamigos_1080p.mp4
ffmpeg -i $INPUT -f yuv4mpegpipe - |  \
        SvtAv1EncApp -i stdin -b stdout -w 1920 -h 1080 --fps 24 --preset 8 \
        --crf 37 --keyint 23 \
        | ffmpeg -i - -an -c:v copy -y 03_caminandes_llamigos_1080p_AV1.mp4

The resulting encode is ~40MB I can share it directly ... somehow ... if you are interested.

Just for demonstration purposes also a screenshot how situation looks on my side by the end of playback (see stats from htop)

[ChristianFeldmann]

I have tried a longer file and encoded it in SVAT. On windows I can not see the stalling thread issue so far. The one thing that I noticed is that the memory consumption calculation from YUView and the actual used memory definitely differs. So this may be a bug. I will try an enven bigger file as your file seems to be even longer. How long is you video?

Also ffmpeg has an integration for the SVT AV1 encoder:

ffmpeg.exe -i Sintel.2010.1080p.mkv -map 0:0 -map 0:1 -c:v libsvtav1 -af "channelmap=channel_layout=5.1" Sintel.2010.1080p.av1.webm

[ChristianFeldmann]

So what I can see already is that there is a bug with the reporting of the memory utilization. What memory threshold did you setup in the settings?

[jurisbu]

Regarding memory thresholds. I definitely changed those settings to lower, since I recall thinking it might be culprit. Currently I have set to 2230 MB (no rational behind it).

The videos I have are usually 1m30sec-2m30sec long. The one I mentioned above is 00:02:30.

Also ffmpeg has an integration for the SVT AV1 encoder:

Yep, I am just currently poking with few AV1 encoder implementations and I have this universal workflow not using ffmpeg integration since some of them simply are not integrated into ffmpeg. But I believe this should not be an issue.

[Nagorak]

Sorry, I thought this was an FFmpeg bug report. I had Googled FFmpeg/Dav1d high memory usage and ended up here.

I will leave this info here in case it is of use to you. There is some bug with FFmpeg's decoding of AV1 video that results in a massive memory leak.

It happens when inputting a file into FFmpeg in the following situation:

1. Using -r before the AV1 input to change the input frame rate.
2. With filter complex to perform SSIM or VMAF calculation, with a null output.
3. With .mp4 or .mkv file format for the AV1 input file.

If you don't use -r before the input it works fine. If you output to a file instead of running through the filter complex to a null output it works fine. If you use .ivf file format for the AV1 input file it works fine.