The problem
Recompressing a video library is easy to start and expensive to get wrong. A smaller file is useful only if the application preserves the required streams, makes failures recoverable, and leaves the original alone.
My contribution
I scoped the fidelity and safety requirements, directed the agent-assisted implementation, compared codec tradeoffs, and validated the queue and recovery behavior. FFmpeg, NVIDIA codecs, and their underlying algorithms are upstream work.
Architecture
The Qt interface manages immutable job settings. A pipeline module coordinates cancellable subprocesses, a durable manifest, media validation, and no-clobber publication. A small C bridge preserves AAC priming; a separately pinned FFmpeg verifier checks decoded audio.
Read the architecture flow
- 1Source identity + settings
- 2Encode video
- 3Checksum checkpoint
- 4Copy auxiliary streams
- 5Validate
- 6Publish separate output
Make verification part of the job
The application separates video encoding from the final mux and validation. A completed encode becomes a checksum-bound checkpoint. If finalization fails, retry can reuse that video instead of spending the encoding time again. An interrupted partial encode restarts; it does not pretend to resume a codec stream.
The tradeoff
Full decode and preservation checks cost time. Encoding FPS alone would hide that cost. The interface therefore reports verification as a separate phase, and the final filename appears only after acceptance.
Read demonstration transcript
A synthetic test file is added to a separate Compressor queue. The source is inspected, then the queue starts. The application reports encoding, validation, and completion. Original media remains separate from the output. This short fixture demonstrates the workflow, not representative throughput or perceptual quality.
74.3% smaller in one retained HDR test
A recorded 4K HDR HEVC test reduced 5,472,536,698 bytes to 1,404,958,321 bytes. That is a 74.327% reduction in final-file size. This was a lossy re-encode of one source, not a promise of invisible differences or typical savings.
| Input size | 5.473 GB |
|---|---|
| Final output | 1.405 GB |
| Encoding throughput | 97.48 FPS |
| Measured successful stages | 30.75 FPS |
Method and scope
Retained release-acceptance records, September 2026. Intel i3-12100, 32 GB RAM, RTX 4060, driver 580.173.02; FFmpeg 6.1.1. HEVC NVENC CQ20/p4. Successful-stage timing includes the recorded scan, encode, packet work, mux, and successful validation. It excludes failed development attempts and unmeasured overhead. Some runs overlapped other GPU work. This audit checked the retained records; it did not repeat the full episode.
Verification and limits
38 existing regression cases passed on a private source copy on October 21, 2026. The suite includes synthetic stream-preservation, recovery, no-clobber, timing, color, audio, and Qt queue checks.
- Savings depend strongly on the source. Two other documented HEVC user runs saved only 3.5% and 4.6%.
- Structural validation does not establish perceptual transparency, calibrated HDR display quality, or compatibility with every player.
- Unsupported media fails explicitly. Publication depends on a filesystem supporting the required no-clobber hard-link operation.
These results describe the inspected project and stated test conditions. They are not a guarantee for every input or machine.