2026-06-01 and newer builds have some kind of runaway memory allocation issue when doing VMAF tests. I have seen it allocating and eventually freeing well over 200 GB of memory. It has to have been attempting to allocate quite a bit more than that, as my C: drive has ~240 GB free at the moment, which is where the pagefile resides, and while trying to figure out what was going on I was occasionally having it fail with messages like this:
[fc#0 @ 00000211ca6e3400] Task finished with error code: -12 (Cannot allocate memory)0:09:16.60
[fc#0 @ 00000211ca6e3400] Terminating thread with return code -12 (Cannot allocate memory)
The VMAF job was launched with a command such as this, built automatically by a script that had previously determined the various features of the source file, which is a 1080p 50 fps PAL source which is roughly 92 minutes in duration:
ffmpeg -y -fflags +genpts -i distorted.mkv -fflags +genpts -i reference.mp4 -filter_complex "[0:v]setpts=N/FRAME_RATE/TB,fps=50,format=yuv420p,setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709[d];[1:v]setpts=N/FRAME_RATE/TB,fps=50,format=yuv420p,setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709[r];[d][r]libvmaf=model=version=vmaf_v0.6.1:n_threads=8:log_fmt=xml:log_path=distorted.VMAF.txt[v]" -map "[v]" -an -sn -dn -f null NUL
I don't update religiously, but I updated yesterday and that was when the issue cropped up. Prior to updating to ffmpeg-2026-06-15-git-44d082edc8-full_build I had been using ffmpeg-2026-05-18-git-b4d11dffbf-full_build without issue. When I saw this happening I started stepping backwards through the releases until I reached my previously used version. The issue went away when I stepped back to ffmpeg-2026-05-28-git-7b46c6a2a3-full_build and begins with ffmpeg-2026-06-01-git-bf608f16fd-full_build and every subsequent build up to and including ffmpeg-2026-06-15-git-44d082edc8-full_build.
I'm not sure if all files are doing the same thing, and this one in particular just happened to be large enough to trigger the weird memory allocation behaviour, or if it is always doing the same thing and this file just happened to be large enough to run me out of disk space. I'll do a bit more investigation today. I'll keep an eye on memory allocation during shorter file runs and see if it is still eating memory like crazy, but just not enough to run me out of space. Maybe it is, and maybe it isn't. I'll report back, but thought I'd open the issue while this was fresh in my mind.
2026-06-01 and newer builds have some kind of runaway memory allocation issue when doing VMAF tests. I have seen it allocating and eventually freeing well over 200 GB of memory. It has to have been attempting to allocate quite a bit more than that, as my C: drive has ~240 GB free at the moment, which is where the pagefile resides, and while trying to figure out what was going on I was occasionally having it fail with messages like this:
[fc#0 @ 00000211ca6e3400] Task finished with error code: -12 (Cannot allocate memory)0:09:16.60
[fc#0 @ 00000211ca6e3400] Terminating thread with return code -12 (Cannot allocate memory)
The VMAF job was launched with a command such as this, built automatically by a script that had previously determined the various features of the source file, which is a 1080p 50 fps PAL source which is roughly 92 minutes in duration:
ffmpeg -y -fflags +genpts -i distorted.mkv -fflags +genpts -i reference.mp4 -filter_complex "[0:v]setpts=N/FRAME_RATE/TB,fps=50,format=yuv420p,setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709[d];[1:v]setpts=N/FRAME_RATE/TB,fps=50,format=yuv420p,setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709[r];[d][r]libvmaf=model=version=vmaf_v0.6.1:n_threads=8:log_fmt=xml:log_path=distorted.VMAF.txt[v]" -map "[v]" -an -sn -dn -f null NUL
I don't update religiously, but I updated yesterday and that was when the issue cropped up. Prior to updating to ffmpeg-2026-06-15-git-44d082edc8-full_build I had been using ffmpeg-2026-05-18-git-b4d11dffbf-full_build without issue. When I saw this happening I started stepping backwards through the releases until I reached my previously used version. The issue went away when I stepped back to ffmpeg-2026-05-28-git-7b46c6a2a3-full_build and begins with ffmpeg-2026-06-01-git-bf608f16fd-full_build and every subsequent build up to and including ffmpeg-2026-06-15-git-44d082edc8-full_build.
I'm not sure if all files are doing the same thing, and this one in particular just happened to be large enough to trigger the weird memory allocation behaviour, or if it is always doing the same thing and this file just happened to be large enough to run me out of disk space. I'll do a bit more investigation today. I'll keep an eye on memory allocation during shorter file runs and see if it is still eating memory like crazy, but just not enough to run me out of space. Maybe it is, and maybe it isn't. I'll report back, but thought I'd open the issue while this was fresh in my mind.