birdie
23rd September 2026, 09:41
I recently compared FFmpeg 8.x's built-in VVC decoder against Fraunhofer's external vvdec decoder using the same 1080p VVC bitstream, NovosobornayaSquare_1920x1080.vvc.
The setup was deliberately constrained to four LP E-cores using taskset, because my CPU is heavily power-limited at the moment and I wanted to reduce the effect of boost behavior and heterogeneous-core scheduling.
Test clip
1920x1080
600 frames
VVC Main 10
decoded to null
FFmpeg 8.x
vvdec 3.2.0
Basic FFmpeg benchmark
Native FFmpeg VVC:
159 fps
3.772 s wall time
14.223 s total CPU time
libvvdec:
185 fps
3.235 s wall time
12.734 s total CPU time
So vvdec was about 16% faster in throughput and used roughly 10% less aggregate CPU time in that run.
I then ran each decoder 10 times under perf stat.
Average results
FFmpeg VVC libvvdec
Task-clock 14.695 s 13.909 s
Cycles 44.29 B 41.28 B
Instructions 104.74 B 82.99 B
Branches 9.62 B 7.90 B
Branch misses 178.34 M 144.99 M
Cache references 1.99 B 2.80 B
Cache misses 586.85 M 1.24 B
Wall time 3.982 s 3.767 s
The most interesting result is not actually the modest ~5% wall-clock advantage in the repeated perf test.
It is the instruction count.
libvvdec retired about 83 billion instructions versus roughly 105 billion for FFmpeg's native decoder — around 21% fewer instructions for decoding exactly the same stream.
Interestingly, FFmpeg's decoder achieved higher IPC:
FFmpeg VVC: ~2.37 instructions/cycle
libvvdec: ~2.01 instructions/cycle
So vvdec does not appear to win because it executes its instruction stream more efficiently. It wins despite lower IPC because it has substantially less instruction-level work to perform in the first place.
The cache behavior goes in the opposite direction. vvdec generated roughly 41% more cache references and more than twice as many reported cache misses. I would not read too much into generic cache events on a modern hybrid Intel CPU, but it does suggest that vvdec may be trading memory locality for reduced computation.
In other words, on this particular stream:
FFmpeg native VVC
higher IPC
substantially more instructions
more CPU cycles
vvdec
~21% fewer instructions
~7% fewer cycles
lower IPC
noticeably higher cache traffic
still finishes faster
That is quite an interesting implementation trade-off.
One caution: VVC decoder performance is highly content-dependent. Different bitstreams exercise very different combinations of prediction modes, transforms, filters and other coding tools, so this is not enough to declare either decoder universally faster.
I'd like to repeat the comparison with several 4K streams and different encoders/settings.
Still, considering FFmpeg's native VVC decoder is relatively young while vvdec has been heavily optimized specifically for VVC decoding, the results seem pretty plausible — and the ~21% instruction-count difference is larger than I expected.
The setup was deliberately constrained to four LP E-cores using taskset, because my CPU is heavily power-limited at the moment and I wanted to reduce the effect of boost behavior and heterogeneous-core scheduling.
Test clip
1920x1080
600 frames
VVC Main 10
decoded to null
FFmpeg 8.x
vvdec 3.2.0
Basic FFmpeg benchmark
Native FFmpeg VVC:
159 fps
3.772 s wall time
14.223 s total CPU time
libvvdec:
185 fps
3.235 s wall time
12.734 s total CPU time
So vvdec was about 16% faster in throughput and used roughly 10% less aggregate CPU time in that run.
I then ran each decoder 10 times under perf stat.
Average results
FFmpeg VVC libvvdec
Task-clock 14.695 s 13.909 s
Cycles 44.29 B 41.28 B
Instructions 104.74 B 82.99 B
Branches 9.62 B 7.90 B
Branch misses 178.34 M 144.99 M
Cache references 1.99 B 2.80 B
Cache misses 586.85 M 1.24 B
Wall time 3.982 s 3.767 s
The most interesting result is not actually the modest ~5% wall-clock advantage in the repeated perf test.
It is the instruction count.
libvvdec retired about 83 billion instructions versus roughly 105 billion for FFmpeg's native decoder — around 21% fewer instructions for decoding exactly the same stream.
Interestingly, FFmpeg's decoder achieved higher IPC:
FFmpeg VVC: ~2.37 instructions/cycle
libvvdec: ~2.01 instructions/cycle
So vvdec does not appear to win because it executes its instruction stream more efficiently. It wins despite lower IPC because it has substantially less instruction-level work to perform in the first place.
The cache behavior goes in the opposite direction. vvdec generated roughly 41% more cache references and more than twice as many reported cache misses. I would not read too much into generic cache events on a modern hybrid Intel CPU, but it does suggest that vvdec may be trading memory locality for reduced computation.
In other words, on this particular stream:
FFmpeg native VVC
higher IPC
substantially more instructions
more CPU cycles
vvdec
~21% fewer instructions
~7% fewer cycles
lower IPC
noticeably higher cache traffic
still finishes faster
That is quite an interesting implementation trade-off.
One caution: VVC decoder performance is highly content-dependent. Different bitstreams exercise very different combinations of prediction modes, transforms, filters and other coding tools, so this is not enough to declare either decoder universally faster.
I'd like to repeat the comparison with several 4K streams and different encoders/settings.
Still, considering FFmpeg's native VVC decoder is relatively young while vvdec has been heavily optimized specifically for VVC decoding, the results seem pretty plausible — and the ~21% instruction-count difference is larger than I expected.