# VVenC is Fraunhofer's H.266 encoder, and its bit-exactness is a build option

> VVenC is a C++ implementation of the H.266/VVC video encoder from Fraunhofer HHI, with five quality and speed presets, perceptual optimisation based on the XPSNR visual model, frame-level and task-based parallelism, and single-pass and two-pass rate control. It fits researchers and pipeline engineers producing VVC bitstreams, and it does not fit a team that needs an encoder that is bit-exact across compilers by default.

**fraunhoferhhi/vvenc** — VVenC, the Fraunhofer Versatile Video Encoder

- Repository: https://github.com/fraunhoferhhi/vvenc
- Website: https://www.hhi.fraunhofer.de/en/departments/vca/technologies-and-solutions/h266-vvc.html
- Stars: 1,219 · Forks: 236
- Language: C++
- License: BSD-3-Clause-Clear
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/fraunhoferhhi-vvenc

## The four headline features are presets, perceptual quality, parallelism and rate control

VVenC is the Fraunhofer Versatile Video Encoder, a software implementation of the H.266/VVC encoder. The README lists four main features and they are the right four to evaluate it on.

The first is ease of use with five predefined quality and speed presets. For an encoder this is a meaningful design decision rather than a convenience, because VVC exposes a very large coding tool set, and the difference between a hand-tuned parameter set and a sensible default is the difference between an encoder people use and one they avoid. Presets give you a starting point that is not arbitrary.

The second is perceptual optimisation to improve subjective video quality, based on the XPSNR visual model. This is the feature that distinguishes a research encoder from a conformance-oriented one. Rather than optimising only for bitrate against a distortion metric, the encoder consults a visual model so that what it spends bits on corresponds to what a viewer notices. The trade-off is that perceptual optimisation is not the same objective as rate-distortion optimality, and results are harder to compare against a bitstream optimised purely for PSNR.

The third is extensive frame-level and task-based parallelisation with what the README calls very good scaling. Task-based parallelisation is the more interesting of the two, because frame-level parallelism alone limits you to the number of frames, while task parallelism can keep cores busy on a single frame. The fourth is frame-level single-pass and two-pass rate control supporting variable bit-rate encoding, and the two-pass mode is what you want for a fixed target bitrate on a file of known duration.

## The build is CMake, and the Makefile is a convenience wrapper

VVenC uses CMake to describe and manage the build, and a working CMake installation is required. The basic sequence is to create a build directory, generate the project, and then build it:

```sh
mkdir build
cd build
cmake .. <build options>
```

```sh
cmake --build .
```

For multi-configuration generators such as Visual Studio or Xcode, you specify --config Release to get the release configuration, since those generators do not pick the build type at configure time.

On top of CMake there is a convenience Makefile, and its main target is:

```sh
make install-release <options>
```

The other supported targets are configure, release, debug, relwithdebinfo, test and clean, with the Wiki holding the full list.

The Makefile is not just a thin alias, though. It accepts a set of options that map onto CMake variables, and reading them is a good way to see what the project exposes. The g option sets the CMake generator, with umake, ninja and xcode handled specially and anything else passed through. verbose turns on CMake verbose makefiles. enable-tracing, address-sanitizer and thread-sanitizer each map to a corresponding VVenC CMake option, which is a useful sign of the project's engineering practice, since address and thread sanitizers are available as first-class build switches rather than something you have to bolt on.

Other options include enable-arch for the target architecture, disable-lto to turn off link-time optimisation, enable-json for the third-party JSON support, install-prefix, osx-arch, toolchainfile and install-ffapp for the functional application.

## Floating-point contraction is why the same source can give different bitstreams

This is the most consequential technical detail in the README, and it is a section of its own for a reason.

By default, VVenC allows the compiler to apply floating-point contraction, which the README explains as fusing multiply and add operations into fused multiply-add instructions. That is a legitimate compiler optimisation, and on AArch64 in particular it improves performance. The problem is that it makes the output depend on the compiler and the target.

The README states plainly that this improves performance but may result in output mismatches between platforms or compiler versions, and that to guarantee fully bit-exact output across builds, VVenC must be built with floating-point contraction disabled.

There are two ways to do it. With CMake directly:

```sh
mkdir build
cd build
cmake .. -DVVENC_FFP_CONTRACT_OFF=On <other build options>
```

Or through the Makefile wrapper:

```sh
make install-release ffp-contract-off=On <other options>
```

The section is titled for AArch64 specifically, which is where the discrepancy bites hardest in practice, because arm64 servers are common in cloud encode farms and the fused instruction is available there while the identical build on x86 might contract differently or not at all.

If you are producing bitstreams that must be reproducible across a build fleet, this is a build option you have to set explicitly, and the fact that it is documented rather than buried is a good sign about the project. The flip side is that the default is performance, not reproducibility, so a pipeline that assumes reproducible output without turning the option on will get surprises.

## The repository layout separates the encoder, its config, its tests and its third-party code

The top level of the repository is a conventional C++ project with the parts you would expect. source/ holds the encoder implementation, include/ the public headers, cmake/ the CMake modules, cfg/ configuration files, test/ the test suite, thirdparty/ the bundled third-party code, and pkgconfig/ the package configuration files consumed by pkg-config.

The presence of a pkgconfig directory and a top-level CMakeLists.txt means VVenC is intended to be installable and linkable, not only runnable from a build tree. The Makefile's install-release target and the install-prefix option reinforce that, and there is a separate install-ffapp option for the functional application.

The Makefile header also documents the single-target shortcuts, which are a convenience for iterating on one binary: make vvenc-r for a release build of the vvenc target, vvenc-d for debug and vvenc-p for relwithdebinfo, with the cr, cd and cp variants cleaning first. The three targets are vvenc, vvencapp and vvencFFapp.

A changelog.txt at the root and a CHANGELOG wiki page sit alongside AUTHORS.md, and the contributing section asks that non-trivial contributions add the contributor's name to AUTHORS.md before opening a pull request against master. The project also points to a Publications wiki page and gives a specific citation to use when referring to VVenC in literature, the ICMEW 2021 paper describing the open and optimised VVC encoder implementation.

## VVenC is an encoder only, and that is the structural limit

The repository contains an encoder and nothing else. There is no decoder, no container handling, no transcoding pipeline and no player. The output is an H.266 elementary stream, and everything around it, demuxing, muxing into MP4 or MPEG-TS, feeding the bitstream to a player, is the caller's job.

That is a normal shape for a codec research implementation, and it is a deliberate one. A codec encoder has a specification to conform to and a quality objective to optimise, and a repository that also did playback and packaging would be doing three jobs. Fraunhofer's VVenC is the reference encoder that the standard's own evaluation used, and the citation in the README points at a paper about an open and optimised VVC encoder implementation, which is the framing.

The consequence for a user is that you have to plan the rest of the pipeline yourself. If you need H.266 in an MP4 with a proper edit list and a playable moov atom, that work is outside this project.

There is also a licensing nuance to check rather than assume. The repository licence field records BSD-3-Clause-Clear, and the README says to see LICENSE.txt for the terms of use of the contents of the repository, with a separate License page in the wiki and a contact address, vvc@hhi.fraunhofer.de, for questions. The copyright line covers 2019 to 2026 for Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. and the VVenC Authors, with all rights reserved, and it states that VVenC is a registered trademark of Fraunhofer. A BSD-derived licence with a trademark reservation is not unusual for a research institute, but the precise terms are in LICENSE.txt, and anything beyond the source code itself, such as patent licensing, sits outside what this repository can tell you.

## Conclusion

VVenC fits a team that needs to produce H.266 bitstreams for research, standards evaluation or encoding pipelines and wants a source encoder with documented presets and a wiki rather than a black-box binary, and it does not fit a pipeline that needs identical output from every build machine without extra configuration. Before adopting it, decide whether you need bit-exact reproducibility, and if so build with floating-point contraction disabled via -DVVENC_FFP_CONTRACT_OFF=On, because the default allows the compiler to fuse multiply-add operations and the README warns that this can produce output mismatches between platforms or compiler versions.

## FAQ

### How do I build VVenC from source?

VVenC uses CMake. Create a build directory, run cmake .. with your build options, then cmake --build ., adding --config Release for multi-configuration generators like Visual Studio or Xcode. A convenience Makefile is also provided, with make install-release as its main target and configure, release, debug, relwithdebinfo, test and clean among the others.

### What are VVenC's main features?

The README lists an easy to use implementation with five predefined quality and speed presets, perceptual optimisation to improve subjective video quality based on the XPSNR visual model, extensive frame-level and task-based parallelisation, and frame-level single-pass and two-pass rate control supporting variable bit-rate encoding.

### How do I get bit-exact output across builds?

VVenC must be built with floating-point contraction disabled. By default the compiler may fuse multiply and add operations, which improves performance but may produce output mismatches between platforms or compiler versions. Configure with -DVVENC_FFP_CONTRACT_OFF=On under CMake, or build with make install-release ffp-contract-off=On.

### What licence does VVenC use?

The repository records BSD-3-Clause-Clear, and the README directs you to LICENSE.txt for the terms of use of the repository contents, with a License page in the project wiki. The copyright covers 2019 to 2026 for Fraunhofer-Gesellschaft and the VVenC Authors, and VVenC is a registered trademark of Fraunhofer.

## Sources

- [fraunhoferhhi/vvenc on GitHub](https://github.com/fraunhoferhhi/vvenc)
- [License: BSD-3-Clause-Clear](https://github.com/fraunhoferhhi/vvenc/blob/master/LICENSE)
- [Project website](https://www.hhi.fraunhofer.de/en/departments/vca/technologies-and-solutions/h266-vvc.html)
- [README](https://github.com/fraunhoferhhi/vvenc/blob/master/README.md)
- [Releases](https://github.com/fraunhoferhhi/vvenc/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fraunhoferhhi-vvenc