VVdeC is a software VVC decoder that tells you which platforms it works on

The Fraunhofer reference decoder for VVC

VVdeC is the Fraunhofer Versatile Video Decoder, and the README describes it as a fast software H.266/VVC decoder implementation supporting all features of the VVC Main10 profile.

That word all is doing work, and it is the right thing to check first. A decoder that implements a subset of a profile will decode conforming streams only in the subset it covers, so a conformance suite run against a partial decoder produces failures that look like bitstream bugs and are not. The claim here is full Main10 coverage, and the build has a conformance bitstream download option, which is how you would check that claim yourself rather than take it on trust.

The project is C++, and the licence is BSD-3-Clause-Clear, which is the variant with a patent grant, appropriate for a codec implementation that must interoperate with others. The homepage is the Fraunhofer HHI page for the VVC technology, and the releases are frequent: v3.2.1 on 2026-10-07, v3.2.0 on 2026-07-28 and v3.1.0 on 2025-11-18, with the last push on 2026-10-20.

The repository is a conventional C++ tree, with `source/`, `include/`, `tests/`, `thirdparty/`, `cmake/`, a `pkgconfig/` directory, a top level `CMakeLists.txt` and `Makefile`, plus `AUTHORS.md`, `SECURITY.md`, `LICENSE.txt` and CI configuration for GitLab and GitHub.

The platform table marks what is untested

The supported architectures table is the most unusual thing in the README, and the reason to read it carefully.

On Windows, Win32 and x64 are marked as tested and working, while armv7 is marked as not working. On Linux, x86, x86_64, armv7 and aarch64 are all tested, and the README says other architectures and platforms might work, with a pointer to the wiki.

On macOS X, x64 is tested and arm64 is marked as needing testing, which the legend explains as might already work. On Android, armv7 and aarch64 are tested, with arm64 needing testing. On iOS, armv7 is tested and arm64 needs testing.

The browser build is the one place with a full column of results. Edge, Firefox and Chrome are all tested, and Safari is marked as not working.

The legend explains the three marks: tested and works, needs testing which might already work, and does not work.

So the honest summary is that the decoder is verified on Windows x86 and x64, on four Linux architectures, on armv7 for Android and iOS, and in three of the four listed browsers, with the Apple silicon targets present but unverified. A project that publishes that much detail about its own gaps is easier to plan around than one that claims universal support.

Building with CMake is three commands

VVdeC uses CMake to describe and manage the build process, and a working CMake installation is required.

You create a `build` directory and generate the project:

mkdir build
cd build
cmake .. <build options>

and then you build it:

cmake --build .

For multi-configuration projects, such as Visual Studio or Xcode, you specify `--config Release` to build the release configuration, which is the detail that trips people up on the generators that hold several configurations in one tree.

The README points at the wiki for the full list of build options, and that is the right place to go, because the number of options is large enough that the summary in the README is only a starting point. The build system in the repository is the CMake one, with the `cmake/` directory holding the modules, and a top level `CMakeLists.txt` that pulls in `thirdparty/` for the third-party components the decoder depends on.

The Makefile is a wrapper over the same options

On top of the CMake build, a convenience Makefile is provided to simplify the build process, and its targets are terse. The header comment explains the convention: `make <project>-r` builds variant=release, `-d` builds debug, and `-p` builds relwithdebinfo, while the `c` prefixed variants clean and build in one step, so `make <project>-cr` is clean plus release.

The interesting target is the install one, which is the command the README gives:

make install-release <options>

The options are single names mapped onto CMake cache variables. The one that matters for testing is `enable-bitstream-download=1`, which downloads the VVC conformance bitstreams for testing, and it is implemented as a thin translation:

ifneq ($(enable-bitstream-download),)
CONFIG_OPTIONS += -DVVDEC_ENABLE_BITSTREAM_DOWNLOAD=$(enable-bitstream-download)
endif

The same pattern carries the rest: `enable-local-bitstream-download` for a local copy of the bitstreams, `enable-build-type-postfix`, `install-prefix`, `install-vvdecapp`, `opt-target-arch`, `enable-lto` for link time optimisation, `enable-werror`, and `enable-unstable-api`. The generator can also be chosen with `g=umake`, `g=ninja` or `g=xcode`, and `verbose` turns on verbose make output.

The other supported build targets are `configure`, `release`, `debug`, `relwithdebinfo`, `test` and `clean`, and the Makefile builds two binaries, `vvdec` and `vvdecapp`.

Citing VVdeC is part of using it

The Citing section asks for a specific reference, and the BibTeX entry is provided:

@InProceedings{VVdeC,
  author    = {Wieckowski, Adam and Hege, Gabriel and Bartnik, Christian and Lehmann, Christian and Stoffers, Christian and Bross, Benjamin and Marpe, Detlev},
  booktitle = {Proc. IEEE International Conference on Image Processing (ICIP)},
  date      = {2020},
  title     = {Towards A Live Software Decoder Implementation For The Upcoming Versatile Video Coding (VVC) Codec},
  doi       = {10.1109/ICIP40778.2020.9191199},
  pages     = {3124-3128},
}

The contribution rules are equally specific. You fork the current most state of the master branch, apply the desired changes, and for non-trivial contributions you add your name to `AUTHORS.md`, then create a pull request to the upstream repository.

The legal section is short but has a wrinkle. You are pointed to `LICENSE.txt` for the terms of use of the contents of the repository, with a contact address at [email protected], and the copyright line reads Copyright (c) 2018-2026 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. & The VVdeC Authors, with all rights reserved. The final line is the one to notice: VVdeC is a registered trademark of the Fraunhofer-Gesellschaft, so the licence grants you use of the code while the name itself is protected. This is not legal advice, but it is a different arrangement from a plain BSD licence and the trademark line is the part that matters if you are naming the tool in a product.

Where a software VVC decoder earns its keep

The case for a software decoder is straightforward and does not require a special framework. Where no hardware VVC decoder is available, and where you need to inspect, test or transcode VVC content rather than simply play it, a full software implementation is the only way to get there. The conformance bitstream option exists for exactly the teams who need to know whether the decoder is behaving.

There are also reasons to look elsewhere. This is a decoder, and nothing in the repository suggests an encoder, so a pipeline that needs to produce VVC is out of scope. The platform matrix is the other check: an Apple silicon Mac or an iOS target is marked as needing testing, and a Safari build does not work at all, so a deployment that must run on every browser of your users is not a fit.

The alternative approach, when the goal is playback rather than processing, is to let the platform's own media stack handle the file. That trades control and the ability to inspect frames for a much smaller operational surface and better hardware use, and it is the right call whenever the platform already has a VVC decoder. The difference in approach is exactly that: VVdeC gives you the decode under your control, with a conformance test path, at the cost of owning the build, the platform coverage and the licence obligations that come with a Fraunhofer trademark attached.

For research and conformance work, that trade is clearly worth it, and the wiki's build information, usage documentation, licence notes, publications and version history are where the details live.

Editorial conclusion

Adopt VVdeC when you need to decode VVC streams in software, for conformance work, research or a platform without a hardware VVC decoder, and when you are willing to build from source and read the platform matrix before you rely on a target. Do not adopt it for encoding, for general media playback, or on a target the README marks as untested. Verify first that your architecture and operating system appear in the matrix with the mark you expect, that the release you build is the one you tested, that the licence terms in `LICENSE.txt` match your use given the registered VVdeC trademark, and that the build options you enable, especially the bitstream download and the unstable API, are the ones you intend to ship.

Frequently asked questions

Official sources

1. fraunhoferhhi/vvdec on GitHub
2. License: BSD-3-Clause-Clear
3. Project website
4. README
5. Releases