H.266 / VVC Video
H.266, also called VVC, is a video coding standard that requires its own compatible decoder and playback integration.
H.266, also called Versatile Video Coding (VVC), extends block-based picture coding with additional ways to divide, predict, and reconstruct regions. Its aim is to give encoders useful choices for different scenes and delivery uses.
The “versatile” part becomes concrete when looking at a region's shape.
Fit the coding regions to the picture
A VVC picture can use a 128 × 128 coding-tree footprint and subdivide it into smaller coding regions. Alongside a four-way square split, its multi-type tree can use binary and ternary splits.
For an illustrative 64 × 64 region:
| Split | Resulting regions |
|---|---|
| Quad | Four 32 × 32 squares |
| Vertical binary | Two 32 × 64 rectangles |
| Vertical ternary | 16 × 64, 32 × 64, and 16 × 64 rectangles |
The ternary regions cover the same area:
16 × 64 + 32 × 64 + 16 × 64 = 4,096 = 64².
The middle region can receive one coding description while narrower regions around it use others. A tall moving subject, a sharp vertical boundary, and broad flat surroundings can benefit from different region shapes.
These are coding possibilities, not a compulsory layout. The stream's tree-size, depth, and split restrictions determine which choice is permitted at a particular point. The decoder reads the selected structure and reconstructs its leaves.
Describe more than a uniform shift
A basic motion vector translates a reference region by one displacement. Real camera movement can also rotate or zoom a region, making the displacement vary across it.
VVC includes motion tools that can describe such varying relationships, including affine prediction. Rather than assuming every point in a region moves identically, a motion model can determine related displacements at different locations. Other prediction choices and coded residuals still provide the information needed to reconstruct the target.
The benefit is a potentially better predictor for that region. A better predictor leaves less correction to describe. A poor model still needs larger corrections or another coding choice.
The encoder explores; the decoder follows
More region shapes and prediction tools give an encoder a larger set of candidates to evaluate. Its search must balance reconstructed-picture error against the bits needed for tree decisions, motion information, and corrections.
The decoder does not repeat that entire search. It follows the signaled candidates, but it must implement their syntax, interpolation, transforms, filtering, and reference rules. This is why a HEVC decoder cannot simply treat VVC as another HEVC profile.
Compression efficiency comes from the selected representation and settings. To measure a particular saving, compare encodes of the same source under an appropriate picture-quality evaluation; the standard's name does not supply a fixed percentage.
Put the format into a playback path
For direct playback, a receiving app needs a usable VVC decoder and compatible extraction/presentation of that stream. For conversion into another codec, the server needs the VVC input decoder first:
VVC source → VVC reconstruction → processing → target encoder → target playback decoder.
The target encoder cannot bypass the source reconstruction. The source's profile, workload, and packaging determine that input job, while the output format determines the client's job.
For a VVC file in an Emby library, inspect the actual server and app implementations at those boundaries. The format explanation describes the work that needs to exist; it does not declare a particular Emby version or device to implement it.