chutsetien 最近的时间轴更新 chutsetien 最近的时间轴更新 |
chutsetienV2EX 第 22966 号会员，加入于 2012-07-03 13:34:59 +08:00今日活跃度排名 4424 |
chutsetien 最近回复了
21 小时 34 分钟前 回复了 markyun02 创建的主题 › 生活 › 大家生日是过阳历时间，还是农历的？ |
不过生日 + 1
甚至已经到了如果一下子被人问及年龄我都得现算一下的地步。
如果感到讶异，说明诸位还年轻，早晚也会有这一天（指年龄需要靠算~）
甚至已经到了如果一下子被人问及年龄我都得现算一下的地步。
如果感到讶异，说明诸位还年轻，早晚也会有这一天（指年龄需要靠算~）
1 天前 回复了 NianBroken 创建的主题 › 编辑器 › Windows 求推荐能秒开的纯文本编辑器 |
OP 遇到的问题实际上是字型档的问题，不知道为什么，Notepad++ 对部分字型档的彩现很慢，换一个系统自带的经典字型（比如新细明体、微软正黑之类）开起来就会快很多。
5 天前 回复了 dcsuibian 创建的主题 › 视频技术 › AV1 和 H265 需要多大码率才能达到 90Mbps 的 H264 水平？可以简单换算吗？ |
@Valyrian
是的，你说到的这条非常重要，YouTube 刻意打压 1080p 的画质（大概跟 COVID 初期的大降质有关），往下的 720p 也好，或者任何 1080p 以上的解析度也好，画质都没有 1080p 那么烂。YouTube 的 1080p 简直是烂到了不能看的地步，因此不得不在去年还是前年来着，又出了个「高码率 1080p 」，然后给弄成了 Premium 专享……
是的，你说到的这条非常重要，YouTube 刻意打压 1080p 的画质（大概跟 COVID 初期的大降质有关），往下的 720p 也好，或者任何 1080p 以上的解析度也好，画质都没有 1080p 那么烂。YouTube 的 1080p 简直是烂到了不能看的地步，因此不得不在去年还是前年来着，又出了个「高码率 1080p 」，然后给弄成了 Premium 专享……
5 天前 回复了 dcsuibian 创建的主题 › 视频技术 › AV1 和 H265 需要多大码率才能达到 90Mbps 的 H264 水平？可以简单换算吗？ |
不能简单换算。不过，如果 YouTube 的 4K 影片的画质对你来说可以接受，你可以把要转换的视频都传到 YouTube 上去，然后等 YouTube 给你转完了再自己下载下来（使用 yt-dlp 当然是，不然 YouTube 自带的只允许你下 720p ）。
AV1 和 H265 既不是一个世代也不是一个派系的——AV1 是 VP9 的后代，世系大体上是 VP8 → VP9 (webp 在这里) → AV1 (avif 在这里); H265 是 H261 → H262 → H263 (很多人可能不知道，当年火爆全网的 rm/rmvb 也是一种 h263) → H264 → H265 → H266 这样连贯下来的。论代来说，AV1 和 H266 算是一代的。
如果一定要自己压的话，这里有一篇
https://kokomins.wordpress.com/2019/10/10/anime-encoding-guide-for-x265-and-why-to-never-use-flac/
建议参考一下。尽管它这里说的是压 anime, 但它借着讲 anime 把很多概念都讲清楚了，你可以根据从这里学到的概念来考虑自己该如何选择。
我自己几年之前也总结过一篇，写在了这里——
https://www.reddit.com/r/2000committee/comments/12s5llm/some_personal_libx265_notes/
当然就不如人家写的好，就是一些自己用的时候的经验（当时花了整整 2 个月的时间去做压码测试），而且也没有后续的更新，比如后来我终于搞懂了 ffmpeg 的 scaler (也不算是完全搞懂吧，但是已经能够写出像 crop='floor(if(gte(iw,ih),min(iw,ih*(28657/17711)),min(iw,ih*(17711/28657)))/2)*2:floor(if(gte(iw,ih),min(ih,iw*(17711/28657)),min(ih,iw*(28657/17711)))/2)*2' 的表达式了——这个式子表示找到长边，然后以长边作为裁切后的长边，裁切为长边比短边为黄金分割), 但是也没有去更新它。
很多人都吹 AV1 如何如何好，但很遗憾，或许是我太过粗鄙愚笨，我无论如何都压不好 AV1, 以我上面的描述，可以看出我是愿意拿出很长的时间去学习编码的参数以及进行自己测试的，但无论我如何测试，我总是发现 AV1 总是需要比压 H265 长得多得多得多的时间以及以比 H265 多出好多的码率，才能达到近乎 H265 的画质水准——甚至还是不行，如果进行截取单一影格放大，进行精细到像素的对比的话。我不知道他们那些研究是如何做出来 AV1 优于 H265 的，反正在愚笨的我这里完全无法复现。我可以忍受更久的压码时间，但是码率更高、质量反而更糟就……同理还有 VP9, 用 libwebp 压出来的图片，最终的画面质量无论如何就是比不过 JPEG (我一般用 cwebp -mt -q 95 -m 6 -sharp_yuv -af -alpha_filter best -sns 0 作为基准参数，但有时生气了就算把 q 调到 100, 放到 Ps 里去放大摁着像素去比会发现 webp 就是会有一些「掉色」的感觉，一些颜色压完就不「鲜艳」了).
因此我个人从来不信 VP8/VP9/AV1 这一套，目前还是摁着 H265 用，H266 虽然现在也有了而且 ffmpeg 也支援了，但我想还是再等个 3 年等它完全稳定、成熟后再说。（但是第一段仍旧成立，我自己也经常这么做，因为经过 YouTube 压制后的画质虽然不是那么能让人接受，但是毕竟体积小，然后浏览器都支持直接播放，因此有很多场景下很好用。）
AV1 和 H265 既不是一个世代也不是一个派系的——AV1 是 VP9 的后代，世系大体上是 VP8 → VP9 (webp 在这里) → AV1 (avif 在这里); H265 是 H261 → H262 → H263 (很多人可能不知道，当年火爆全网的 rm/rmvb 也是一种 h263) → H264 → H265 → H266 这样连贯下来的。论代来说，AV1 和 H266 算是一代的。
如果一定要自己压的话，这里有一篇
https://kokomins.wordpress.com/2019/10/10/anime-encoding-guide-for-x265-and-why-to-never-use-flac/
建议参考一下。尽管它这里说的是压 anime, 但它借着讲 anime 把很多概念都讲清楚了，你可以根据从这里学到的概念来考虑自己该如何选择。
我自己几年之前也总结过一篇，写在了这里——
https://www.reddit.com/r/2000committee/comments/12s5llm/some_personal_libx265_notes/
当然就不如人家写的好，就是一些自己用的时候的经验（当时花了整整 2 个月的时间去做压码测试），而且也没有后续的更新，比如后来我终于搞懂了 ffmpeg 的 scaler (也不算是完全搞懂吧，但是已经能够写出像 crop='floor(if(gte(iw,ih),min(iw,ih*(28657/17711)),min(iw,ih*(17711/28657)))/2)*2:floor(if(gte(iw,ih),min(ih,iw*(17711/28657)),min(ih,iw*(28657/17711)))/2)*2' 的表达式了——这个式子表示找到长边，然后以长边作为裁切后的长边，裁切为长边比短边为黄金分割), 但是也没有去更新它。
很多人都吹 AV1 如何如何好，但很遗憾，或许是我太过粗鄙愚笨，我无论如何都压不好 AV1, 以我上面的描述，可以看出我是愿意拿出很长的时间去学习编码的参数以及进行自己测试的，但无论我如何测试，我总是发现 AV1 总是需要比压 H265 长得多得多得多的时间以及以比 H265 多出好多的码率，才能达到近乎 H265 的画质水准——甚至还是不行，如果进行截取单一影格放大，进行精细到像素的对比的话。我不知道他们那些研究是如何做出来 AV1 优于 H265 的，反正在愚笨的我这里完全无法复现。我可以忍受更久的压码时间，但是码率更高、质量反而更糟就……同理还有 VP9, 用 libwebp 压出来的图片，最终的画面质量无论如何就是比不过 JPEG (我一般用 cwebp -mt -q 95 -m 6 -sharp_yuv -af -alpha_filter best -sns 0 作为基准参数，但有时生气了就算把 q 调到 100, 放到 Ps 里去放大摁着像素去比会发现 webp 就是会有一些「掉色」的感觉，一些颜色压完就不「鲜艳」了).
因此我个人从来不信 VP8/VP9/AV1 这一套，目前还是摁着 H265 用，H266 虽然现在也有了而且 ffmpeg 也支援了，但我想还是再等个 3 年等它完全稳定、成熟后再说。（但是第一段仍旧成立，我自己也经常这么做，因为经过 YouTube 压制后的画质虽然不是那么能让人接受，但是毕竟体积小，然后浏览器都支持直接播放，因此有很多场景下很好用。）
8 天前 回复了 givemeMcNuggets 创建的主题 › 问与答 › 有什么资源网站可以分享吗 主要是想看双语字幕的剧、电影吗 或者下载资源的地方 |
11 天前 回复了 NianBroken 创建的主题 › macOS › 求一个拥有完整的历史编辑记录的笔记写作软件 |
每到问笔记软体的时候我都要推——MediaWiki.
13 天前 回复了 jkfadsljlasdgs 创建的主题 › 问与答 › 寻一个多时区时间展示工具 |
[GadgetPack]( https://gadgetpack.net/) 里面好像带一个叫 Digital Clock 的工具，可以手动设定时区然后摆放在桌面上。我大概在 2017 到 2020 年左右用过 4 年左右，后来就没再用了，不知道现在是否还被支援。当时的实现效果如下图所示（抱歉纷乱的 taskbar……），有很多小细节可以调整，比如透明度、字型之类的。
注：好像 daytime saving 要自行手动修改，这个……没办法。这个小组件毕竟是 2010 年的东西了。
另外如楼上某位所说，Windows 可以添加 2 个副时钟，这个是自动帮你调 DST 的。
其实还有一个小诀窍就是，将系统的时区设为没有 DST 的恒定的 GMT+0, 这样算任何地方的时间就好办很多（直接加减）。我从 2007 年到 2021 年都是这么做的，习惯之后你就知道 22:00 是早上 6 点，00:00 是早上 8 点，04:00 是中午 12 点，09:00 是下午 5 点……然后最主要的是算别的地方的时间非常容易。（后来不这么做是因为真的来到了 GMT+0 的地方，然后从三月底到 10 月底要 +1, 再坚持 +0 反而会觉得超级难受……很奇怪是不是？在 +8 区用 +0 可以适应，但是在 +1 时用 +0 却觉得很难受……）
注：好像 daytime saving 要自行手动修改，这个……没办法。这个小组件毕竟是 2010 年的东西了。
另外如楼上某位所说，Windows 可以添加 2 个副时钟，这个是自动帮你调 DST 的。
其实还有一个小诀窍就是，将系统的时区设为没有 DST 的恒定的 GMT+0, 这样算任何地方的时间就好办很多（直接加减）。我从 2007 年到 2021 年都是这么做的，习惯之后你就知道 22:00 是早上 6 点，00:00 是早上 8 点，04:00 是中午 12 点，09:00 是下午 5 点……然后最主要的是算别的地方的时间非常容易。（后来不这么做是因为真的来到了 GMT+0 的地方，然后从三月底到 10 月底要 +1, 再坚持 +0 反而会觉得超级难受……很奇怪是不是？在 +8 区用 +0 可以适应，但是在 +1 时用 +0 却觉得很难受……）
Select Language