diff --git a/CHANGELOG.md b/CHANGELOG.md index c669294..aac1426 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,21 @@ # Changelog +## 0.1.9 + +- HDR sources (iPhone HLG, HDR10/PQ) are converted to SDR BT.709 inside the same + encode. Before, the output kept HDR tags on 8-bit pixels, so iPhone videos + looked washed out after compression +- Quality checks tone-map the reference frame too, so VMAF and SSIM measure + compression loss instead of the HDR-to-SDR transfer curve +- A target below the minimum bitrate for the video's duration now fails before + encoding and reports the smallest achievable size, instead of spending an + encode that cannot fit. `--force` still runs it +- When a two-pass encode lands more than 0.5% over target, halfsize re-encodes + once with a corrected bitrate instead of handing back an oversized file +- `--for email` now targets 18 MB, because base64 makes a 20 MB attachment a + 26.7 MB message that bounces at Gmail's 25 MB limit. New `--for outlook` + targets 15 MB for the 20 MB message cap + ## 0.1.8 Failure modes, mostly. The kind that leave you with a file you think is fine. diff --git a/README.md b/README.md index f4b576f..8a43880 100644 --- a/README.md +++ b/README.md @@ -26,9 +26,10 @@
- New in 0.1.8: compare the original and the compressed video in the web app, - cancel a running encode, and no more half-written output files. - Release notes + New in 0.1.9: HDR clips (iPhone HLG, HDR10) are tone-mapped to SDR instead of + looking washed out, a target that cannot fit now fails before the encode with the real + minimum, and the email presets account for the base64 attachment tax. + Release notes
--- @@ -47,7 +48,7 @@ It computes the bitrate, picks the resolution that actually fits, encodes twice, the result with **SSIM** and **VMAF** so you know whether it still looks the same. ``` - halfsize 0.1.8 + halfsize 0.1.9 source.mp4 23.2 MB 8s 1920x1080 30.00 fps h264 @@ -171,7 +172,8 @@ compression plus a measured quality report, instead of guessing a bitrate. the encoder gets to spend its bits on fewer pixels. 4. **Encode twice.** Two-pass ABR with `libx264` or `libx265`. Pass one learns where the bits are needed; pass two spends them. Output is `yuv420p`, AAC audio, `+faststart`, and tagged - `hvc1` for H.265 so it plays on Apple devices. + `hvc1` for H.265 so it plays on Apple devices. HLG/PQ sources are tone-mapped to SDR BT.709 + in the same pass; without that, 8-bit pixels keep their HDR tags and look grey. 5. **Prove it.** Sample three points in the video, compute SSIM at each, and VMAF at the midpoint. Compare against thresholds and print a verdict in plain language. @@ -211,7 +213,7 @@ more quality at the same size if your player supports it. halfsize- 0.1.8 新功能:网页版可直接对比原片和压缩后、随时取消编码,失败时不再留下半截文件。 - 更新说明 + 0.1.9 新功能:iPhone 拍的 HDR 视频会自动转成 SDR,压完不再发灰;压不到的目标在编码前就报出真实最小值;邮件预设按 base64 后的实际上限来算。 + 更新说明
--- @@ -45,7 +45,7 @@ npx halfsize 婚礼.mp4 --to 25mb 画质到底还在不在。 ``` - halfsize 0.1.8 + halfsize 0.1.9 source.mp4 23.2 MB 8s 1920x1080 30.00 fps h264 @@ -161,6 +161,7 @@ npx skills add YKLovePython/halfsize 让编码器把有限的比特花在更少的像素上,而不是硬撑 4K。 4. **压两遍。** `libx264` 或 `libx265` 两遍 ABR。第一遍找出哪里需要比特,第二遍把比特花在那里。 输出 `yuv420p`、AAC 音频、`+faststart`,H.265 额外打 `hvc1` 标签,保证苹果设备能播。 + HLG/PQ 片源会在同一次编码里转成 SDR BT.709;不转的话,8-bit 像素还带着 HDR 标签,播出来就发灰。 5. **证明。** 在视频里取三个采样点算 SSIM,在中间点算 VMAF,对照阈值给一句人话结论。 ``` @@ -197,7 +198,7 @@ SSIM 取三个采样点。实际数字会随内容变化:新闻口播会好很 halfsize$ npx halfsize video.mp4 --to 20mb
- halfsize 0.1.8
+ halfsize 0.1.9
video.mp4
136 MB 60s 1920x1080 30.00 fps h264
diff --git a/site/discord/index.html b/site/discord/index.html
index 0b1bd06..961d028 100644
--- a/site/discord/index.html
+++ b/site/discord/index.html
@@ -71,7 +71,7 @@ Step by step
$ npx halfsize clip.mp4 --for discord
- halfsize 0.1.8
+ halfsize 0.1.9
clip.mp4
136 MB 60s 1920x1080 30.00 fps h264
diff --git a/site/email/index.html b/site/email/index.html
index 50983c3..6461571 100644
--- a/site/email/index.html
+++ b/site/email/index.html
@@ -81,7 +81,7 @@ One command
214 MB → 17.62 MB 12x smaller 2.1% under target
VMAF 87.4 SSIM 0.968 slight softening
- The --for email shortcut targets 20 MB, which is right for Outlook-class servers. For Gmail, --to 18mb is the safer number because of the base64 tax.
+ The --for email shortcut targets 18 MB, the Gmail-safe number after the base64 tax. --for outlook targets 15 MB for the 20 MB message cap. --to overrides either one.
What it does to the picture
Eighteen megabytes for a one-minute clip is about 2.2 Mbps. That is comfortable for 720p and cramped for 1080p, so the tool downscales instead of starving the larger frame. Measured on a 60-second 1080p30 source at 18 Mbps:
diff --git a/site/ffmpeg-compress-to-size/index.html b/site/ffmpeg-compress-to-size/index.html
index e30671a..76cc8b2 100644
--- a/site/ffmpeg-compress-to-size/index.html
+++ b/site/ffmpeg-compress-to-size/index.html
@@ -104,7 +104,7 @@ What halfsize automates
Computes the budget, then picks the largest resolution that stays above a bits-per-pixel floor — 1080p when it fits, 720p or 540p when 1080p would look starved.
Runs both passes, writes to a temporary file, and only renames it when the encode succeeds.
Measures VMAF and SSIM, then prints a plain-language verdict instead of a number you have to interpret.
- Adds --for discord, --for wechat, --for whatsapp, --for email and --for twitter so you do not have to look the cap up.
+ Adds --for discord, --for wechat, --for whatsapp, --for email, --for outlook and --for twitter so you do not have to look the cap up.
$ npx halfsize input.mp4 --to 20mb
diff --git a/site/index.html b/site/index.html
index e3a6367..e09cd6a 100644
--- a/site/index.html
+++ b/site/index.html
@@ -35,7 +35,7 @@
"codeRepository": "https://github.com/YKLovePython/halfsize",
"license": "https://github.com/YKLovePython/halfsize/blob/main/LICENSE",
"offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" },
- "softwareVersion": "0.1.8"
+ "softwareVersion": "0.1.9"
}