Initializing... drag & drop files here
Supports: CAVS
A .cavs file is a raw AVS1-P2 elementary video stream — the Chinese national video coding standard, published as GB/T 20090.2-2006 and enacted on 1 March 2006, with a single profile named Jizhun. HEIF is the ISO container that Apple popularised for photographs, holding HEVC-coded still images.
This conversion takes one frame out of a Chinese AVS stream and writes it as a modern still image. This page covers what a .cavs file actually is, what survives the trip, and how the quality control on the page maps to real numbers.
| Property | Value |
|---|---|
| Full name | Advanced Audio Video Coding, Part 2: Video (AVS1-P2) |
| Standard | GB/T 20090.2-2006, Standardization Administration of China |
| Enacted | 1 March 2006 |
| Profile | Jizhun (the only profile in AVS1-P2) |
| Design goal | H.264-class efficiency at lower decoder complexity, for SD and HD broadcast |
Structure of a .cavs file |
raw elementary stream — no container, no audio, no timestamps |
| Encoder availability | none in the open-source toolchain; decode only |
| Successor | AVS2 (.avs2, IEEE 1857.4) — a separate, incompatible standard |
That last row is the one that surprises people, so we checked it rather than assuming: an AVS2 elementary stream fed to the AVS1 demuxer and decoder is rejected outright, no frames produced. AVS2 is not a newer version of the same bitstream, it is a different standard that happens to share a family name.
The "decode only" row is why .cavs is an input format on xconvert and never an output one. There is a working AVS1 decoder; there is no AVS1 encoder anywhere in the pipeline, so there is nothing that could write a .cavs file for you.
.cavs onto the drop zone or click "Add Files". The page accepts .cavs only.The conversion runs in two stages. First the requested frame is pulled out of the AVS stream and written as a lossless PNG — nothing is thrown away at this point, and no quality setting applies yet. Then that PNG is encoded to HEIF with whatever preset you chose. Everything you can control on the page acts on the second stage.
One consequence of that split matters for broadcast material. AVS1 was designed for standard- and high-definition television, and a great deal of television is interlaced. There is no deinterlacing anywhere in this pipeline — no yadif, no bwdif, nothing. A frame lifted from an interlaced stream contains two fields captured at different instants, woven together, and that comb pattern is baked into the still.
We proved that rather than asserting it: a test stream whose two fields were solid blue and solid red produced a still whose scan lines alternate blue, blue, red, red, blue, blue down the frame. If your source is interlaced television and the picture has motion in it, expect horizontal tearing on moving edges. Grabbing a frame from a static shot avoids the problem entirely.
The preset names map to fixed quality values, and those values map to real file sizes. Measured on a 1920 × 1080 frame whose lossless PNG intermediate was 288,106 bytes:
| Quality Preset | Quality value | HEIF output |
|---|---|---|
| Highest | 100 | 172,300 bytes |
| Very High (Recommended) | 95 | 172,300 bytes |
| High | 90 | 158,736 bytes |
| Medium | 80 | 128,060 bytes |
| Low | 70 | 100,530 bytes |
| Very Low | 60 | 78,058 bytes |
| Lowest | 50 | 57,427 bytes |
Highest and Very High landed on the same byte count on both test frames we tried, so the top of the range has very little headroom left — Very High is the sensible ceiling. Everything below Medium starts costing visible detail on broadcast-sourced frames, which are already carrying compression artefacts from the AVS encode.
The output itself is HEVC-coded at 4:2:0 chroma subsampling, confirmed by probing the finished file. That means colour resolution is half the luma resolution in both directions — fine for photographic content, less kind to hard-edged graphics such as broadcast tickers and station logos.
Because a decoder exists and an encoder does not. The toolchain can read AVS1-P2 Jizhun profile streams, but there is no AVS1 encoder in it, so nothing could produce a .cavs file even if the option were offered. Every .cavs route on xconvert is one-way by necessity, not by choice.
No, and they are not interchangeable. AVS2 is IEEE 1857.4, a separate standard with a different bitstream. We fed an AVS2 stream to the AVS1 demuxer and decoder and it produced no frames at all. A file that will not open may simply be the wrong AVS generation.
Nothing went wrong — that is interlacing. Your AVS stream stores two half-height fields per frame captured milliseconds apart, and there is no deinterlacing step in this pipeline to blend them. Use Frame Selection to pick a moment with little motion, or deinterlace the source in a video editor before uploading.
Set Frame Selection to Specific Frame and put the time in seconds into the Time field. If you would rather review several candidates, choose Multiple Screenshots and a capture rate — one frame every second, every five seconds and so on — and you get a set of stills to choose from in one pass.
Not entirely. The HEIF we write is HEVC at 4:2:0 chroma subsampling, so colour detail is stored at half resolution horizontally and vertically. For photographic content that is imperceptible; for a frame full of small coloured text or a sharp graphic overlay you may see colour fringing. CAVS to PNG avoids the issue by writing full-resolution colour.
Modern Windows can open HEIF once the HEIF Image Extensions are installed, and macOS, iOS and recent Android open it natively. If you need something that opens absolutely everywhere with no extension to install, CAVS to JPG is the safe answer at the cost of a larger file for the same visual quality.
No — a raw .cavs elementary stream is video only. There is no audio track, no timestamps and no container metadata in it at all, so nothing audio-related is being discarded. If your recording had sound, it was in a separate file or a separate stream inside a container such as a transport stream.
Because HEIF's rate control is a single quality number, not a bit depth or a zlib level. The Quality Preset dropdown is the whole control surface, plus Specific file size if you need to hit a byte target. Bit depth controls appear on uncompressed targets such as PPM, where they change the file layout.
Specific file size is a ceiling, not an exact target. The server reduces resolution first if it has to, then binary-searches the quality scale for the highest setting whose output still fits under your budget. Landing under the number is the intended outcome; overshooting is what it is designed to prevent. For a batch of frames that should all look alike, the fixed Quality Preset gives more consistent results than a size target.