Fixed
- Encoding stalls on files with many unwanted subtitle streams (Breathless 2024, Brotherhood, etc — releases that ship 30+ subrip tracks). Previous attempts (v0.3.37 muxer flags, reverted in v0.3.38) didn't address the actual cause. Live diagnostics on a stuck job showed ffmpeg's
frame=andfps=advancing whiletime=froze, which means the encoder was producing output but the output-side commit position was lagging — interleave drift across the 35 input streams was wedging the muxer's per-stream queues. Single-process ffmpeg test on the same file confirmed: 5.15× speed with-an -sn(no streams), but the production cmd with 4 mapped + 30 dropped subs only made it through 2 minutes before drift made it diverge from steady throughput. Fix: when a job needs to drop ≥6 subtitle streams, do a fast-c copyremux pass first that strips them, then run the main encode on the cleaned 5–7 stream file. The main pass then has nothing to demux that it isn't using, no interleave drift, and runs at the same speed as the streamless test. Pre-strip is I/O-bound (~30s for a 2 GB file), runs once per qualifying job, and is automatically skipped for files with fewer drops. Falls back gracefully to single-pass on errors / timeouts.
Docker images
Pinned to this release:
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.39 # portable (amd64 + arm64, CPU)
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.39-nvenc # x86_64 + NVIDIA GPU (NVENC)
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.39-edge # as above but ffmpeg master
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.39-edge-nvencFloating tags (:latest, :edge, :nvenc, :edge-nvenc) track the most recent release of each lineage.