Video compression

On compression, encoding trade-offs, and examples

I’m working on a context-oriented, low-latency video compression scheme. I haven’t fully formalized how the codec works yet, so to avoid confusion I’ll only share a few snippets for now. The best way to get a feel for it is through numbers—so check out the videos below, which include some bitrate plots.

At some point, I plan to do more sophisticated research and compare the results with state-of-the-art methods to provide a more scientific overview. But that’s a lot of work. So this subpage might feel a bit underwhelming—but hey, at least I can tease some results.

If you have some background: the image quality can be compared to baseline JPEG at 75% quality—because that’s essentially what I’m using. Same quantization tables for luminance and chrominance. The key difference is I’m not using Huffman coding, but a form of differential encoding. In some cases, it's worse than (M)JPEG, in others it's better.

Theoretically, it would even be possible to run MJPEG and my custom encoder in parallel and dynamically choose the better frame. Since their compression behavior is close, most of the pipeline can be shared.

I also discovered I can apply Huffman coding *after* my custom compression. In some cases, this reduces size by another 5%; in others, up to 20%. But I’m postponing that for now—I don’t want to implement it in FPGA. It’s just something to explore later when I feel like fooling around.

Video Demos and Results

The videos in this playlist show the actual compressed stream output from the device, captured in real time. Compression quality is comparable to baseline JPEG at 75%. YouTube may have further compressed, but with HD enabled, the visuals are nearly identical to what the display renders.