QOYV — Quite OK YCbCr Video

The video codec OpenJVID ships — built on QOY, a YCbCr-based format derived from QOI.

If you’ve looked at OpenJVID, you’ve already seen QOYV in the component list — ingest, egress, and the peripheral streaming path. This post covers what the codec actually is and how it relates to QOI and QOY.

QOYV is the streaming and file wrapper jVid uses for video. Each frame is compressed with QOY. QOY is not QOI; it’s a related format that encodes YCbCr 4:2:0 instead of RGBA.

From QOI to QOY to QOYV

QOI (Quite OK Image) is Dominic Szablewski’s still-image format: fast encode/decode, modest compression, MIT licensed, magic bytes qoif. It works on RGBA using a small set of operations — a 64-slot color index, small diffs, runs, and full pixel values when needed.

QOY (Quite OK YCbCr420A) builds on that approach with a different colorspace. It’s by Dominic Szablewski with Jorrit “Chainfire” Jongma. From the vendored qoy.h in jVid:

QOY encodes and decodes images in a lossless format, as QOI does. But where QOI encodes RGBA, QOY encodes YCbCr 4:2:0 A (YCbCrA 4:2:0:4).

So QOY is sourced from QOI — same goals of staying small, simple, and fast — but it’s a sibling format aimed at chroma-subsampled video-style pixels, not a renamed .qoi file. Magic bytes are qoyf, not qoif. Encoding is lossless relative to the YCbCrA representation. If you pass RGBA in, the library converts with a JPEG-style integer approximation; that conversion (and the 4:2:0 subsampling) is lossy.

QOYV is jVid/OpenJVID’s layer on top: QOY-compressed frames packaged as a video stream or file — TCP, .qov files, keyframe intervals, and related tooling.

QOI  (RGBA stills)     →  inspiration / ancestor
 └─ QOY (YCbCr 4:2:0)  →  per-frame compressor in jVid
     └─ QOYV           →  video stream + file container around QOY frames

Why YCbCr instead of QOI frames?

Chroma subsampling is a common tradeoff in video: luma matters more to perception than full-resolution chroma. QOY uses that:

Pixels are handled in 2×2 blocks
Y (and alpha) are stored per pixel
Cb / Cr are averaged for the block (4:2:0)
Encoded size is roughly half of QOI, with decoded RGBA described in the QOY docs as virtually indistinguishable
Native YCbCrA paths are also faster (~1.5× encode / ~2× decode vs going through RGBA)

That’s the reason QOY exists alongside QOI in this stack: better fit for frame sequences where size and speed matter more than bit-identical RGB.

What QOYV does in jVid

jVid includes native encode/decode (QOYEncoder_V2_Native, QOYDecoder_Native) wrapping qoy.h, plus Java egress/ingest (QOYStreamEgressor_V2, QOYStreamIngestor_V2).

Useful details if you’re inspecting the wire format or a .qov file:

Per-frame payload is a QOY bitstream (qoy_encode / qoy_decode)
TCP egress prefixes each frame with a 4-byte big-endian length, then the QOY bytes
File convert (FFMPEGIngestToQOYVFile) writes a small header (frame rate, width, height, segment hint), then the same length-prefixed frames into a .qov file
Keyframes (often around every 60 frames in the stream egressor) force a full encode; intervening frames can zero unchanged pixels before QOY so runs compress better
OpenJVID’s Peripheral path uses a subset of the QOYV streaming protocol over multicast for discovery and inter-node video

OpenJVID exposes this as QOYV Ingest and QOYV Egress components. jVid is the library underneath.

Notes and limits

QOYV is not aimed at competing with H.264/HEVC/AV1 on bitrate. It’s meant to be fast and simple enough for LAN and tool pipelines — closer to QOI’s design goals than to a broadcast encoder.
jVid also has a QOI path, and there was a QOIV experiment whose efficiency didn’t hold up well enough for OpenJVID. QOYV is what stayed in the graph.
For lossless relative to what QOY stored, stay in YCbCr. Round-tripping through RGBA includes the colorspace conversion and chroma subsampling cost.

QOYV — Quite OK YCbCr Video

From QOI to QOY to QOYV

Why YCbCr instead of QOI frames?

What QOYV does in jVid

Notes and limits

Further reading