Skip to content

ecompress 2.3.0

Choose a tag to compare

@priyadip priyadip released this 17 Aug 21:13
· 4 commits to main since this release
pip install --upgrade ecompress

Fixed

A bitrate proven to work is no longer thrown away when the resolution changes.

Every rung of the ladder restarted its search from the original opening estimate. Having learned that 3.13 Mbps worked at 1440p, the search dropped back to 965 kbps on moving to 2160p - so the higher resolution produced a smaller file than the rung below it:

Attempt 2: 21.0 MB [3.13 Mbps @ 2560x1440]   learned 3.13 Mbps works
Attempt 3: 16.2 MB [965 kbps  @ 3840x2160]   threw it away

The learned rate now carries forward, so each climb makes the file larger, monotonically, and the size floor is reached in fewer attempts.

Also: the climb decision now looks at what the current frame size achieved rather than a global best from another rung, and saturation is judged within a rung.

Changed

Long sources are searched on a 30-second sample. Each search pass had to encode the whole file. Benchmarked: 4K -> 4K runs at 19 fps against 65 fps for 4K -> 1080p, so a five-pass run on a six-minute 4K source could exceed an hour. Above 90 seconds the search now runs on a slice taken a quarter of the way in, and only the winning settings get a full-length encode.

The prediction is never the result - the full encode is measured and validated exactly as before, and corrected if the sample misjudged the file. Quality is unaffected.

Two measurements worth recording, both negative: -hwaccel auto made 4K decoding three times slower, not faster, because every frame is copied back from the GPU; and the scaler choice (lanczos, bicubic, fast_bilinear) makes no measurable difference. Neither is worth doing.

427 tests, 84% coverage, verified on Linux, macOS and Windows across Python 3.10-3.13.