@Valyrian

是的，你说到的这条非常重要，YouTube 刻意打压 1080p 的画质（大概跟 COVID 初期的大降质有关），往下的 720p 也好，或者任何 1080p 以上的解析度也好，画质都没有 1080p 那么烂。YouTube 的 1080p 简直是烂到了不能看的地步，因此不得不在去年还是前年来着，又出了个「高码率 1080p 」，然后给弄成了 Premium 专享……

不能简单换算。不过，如果 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 压制后的画质虽然不是那么能让人接受，但是毕竟体积小，然后浏览器都支持直接播放，因此有很多场景下很好用。）

About V2EX 第一条：

> 这里绝对不讨论任何有关盗版软件、音乐、电影如何获得的问题

—https://v2ex.com/about

每到问笔记软体的时候我都要推——MediaWiki.

[GadgetPack]( https://gadgetpack.net/) 里面好像带一个叫 Digital Clock 的工具，可以手动设定时区然后摆放在桌面上。我大概在 2017 到 2020 年左右用过 4 年左右，后来就没再用了，不知道现在是否还被支援。当时的实现效果如下图所示（抱歉纷乱的 taskbar……），有很多小细节可以调整，比如透明度、字型之类的。
https://i.imgur.com/MCNdVy5.jpeg
注：好像 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 却觉得很难受……）

@luoma 你忘了 Nokia 808 :)

https://zh.wikipedia.org/wiki/%E4%B8%AD%E5%8D%8E%E4%BA%BA%E6%B0%91%E5%85%B1%E5%92%8C%E5%9B%BD%E8%A1%8C%E6%94%BF%E5%8C%BA%E5%88%92%E4%BB%A3%E7%A0%81

點開右側的資訊方塊裡的每一個連結，你甚至能找到已被廢止的一些行政區劃的代碼。

你要看日历表的话那就是从立春开始是春天、立夏开始是夏天、立秋开始是秋天、立冬开始是冬天，也即差不多是 2, 3, 4 月是春； 5, 6, 7 月是夏； 8, 9, 10 月是秋； 11, 12, 1 月是冬。

但感觉上很明显 8 月份不可能是「秋」，因此大部分中国大陆人，尤其是北方人，应该都会认同楼上诸位的提法，也即 3, 4, 5 月份是春； 6, 7, 8 月份是夏； 9, 10, 11 月份是秋；然后 12, 1, 2 月份是冬。

如果更具体一些来说的话，很多时候可能我们会感觉 3 月底还比较凉，但到了 5 月就很热了，因此春天可能往往也就 4 月还比较算得上；然后夏天其实基本上是从 5 月到 9 月——即使是中北方地区。

一个比较有趣的是，一些海洋上的国家，因为受气候的影响，会更晚地迎接四季的到来，比如英国就以四分日 (‘quarter days’) 为进入该季节的开始，也即春分才是英国春天的开始、夏至是夏天的开始、秋分是秋天的开始、冬至是冬天的开始（甚至真实来说还要再晚几天，因为英国的四分日并不严格的和四至点重合，第一个四分日在 3 月 25 日、第二个在 6 月 24 日、第三个在 9 月 29 日、第四个在 12 月 25 日）。英国的旧历（‘Old Style’, 基于儒略历）甚至以第一个四分日为一年的起点，因此一年的第一天就是 3 月 25 日（而前一天是去年的 3 月 24 日），后来改用新历 (‘New Style’) 后对税年的开始日期仍旧从旧且继续沿用儒略历，因此现在英国的税年的开始日期已经挪到了 4 月 5 日了。

所以，在不同的地方，对四季的感受也是不同的。而位于南北回归线以内的就不要再强凹说自己那里也有四季了——任何学过中学地理的都知道，南北回归线以内的地区没有四季，全年都是夏季。

@yukino 2029 年以后，直到 2050 年，估计都再也看不到工党政府了，甚至它还能不能守住国王陛下最忠实的反对党的地位都难说，最近一些地方 councillor 的补选有的时候它甚至都跌到第 5 位去了，只剩个位数的支持度~

@chutsetien 正面典型还忘了一个非常重要的：gov.uk

以及，由于 Google 把他家的设计语言也用到了网页上，因此也勉强可以说说：原生代 Material Design (约 2013 成熟至 2018 年中) 是设计精良的； Material Design 2 是噁心的，Material Design 3 是邪恶且恐怖的（现在 Google 几乎所有的网页都让人看了想吐，即使装了 Unround Everything 也他妈的想吐，干！）。对应的微软家的原生代 Metro Design (Zune to WinPhone 8.1, 约 2006 到 2015) 是设计精良的，后来 2015 到 2020 年左右尚可接受，现在的 Fluent UI 则是纯粹的噁心 + 邪恶。

正面典型：
豆瓣, Google Reader, Amazon, MediaWiki (但需要非 Vector 2022 布景主题为前提，Vector 2022 是邪恶！邪恶！), SS64

反面典型：
Gmail New Compose 2013 (Old Compose 可以透过 add-on 找回，直到 2016 年 1 月) 以及如今的整个 Gmail, 妈的噁心死了;
Netflix;
YouTube 2020 及后续的 Redesign (YouTube 的设计巅峰在 2014 到 2019, 2020 和 2021 勉强还能接受，但 2022 以后简直就是邪恶！邪恶！现在没有 YouTube Redux 再加几个其他的 add-ons 基本没法用);
IMDb;
reddit 2023 (2024 年 12 月故意撤下 ‘new.’ 系 layout 后正好帮我戒掉 reddit 了);
MediaWiki Vector 2022 (坚决抵制 Vector 2022!);
Twitter (自强制将 mobile.twitter.com 扶正之后，大概是 2019 年的事儿了吧，不过至今仍有无数 add-ons 或 userscripts 回到过去);
Github 以及其他的微软系网站，如今不知道在背后捣鼓些啥，表面上看着没什么变化，但是一开它们就特别吃资源，响应缓慢，甚至会影响到连关闭这个标签页都得等一会儿，所有微软系网站的页面如今越来越多地都有这个毛病。

@wuruxu 我觉得可能跟持续受力有关系？硅胶套一般都和手机贴合得很紧，然后加上天气的变化、室内、室外、手机自身发热等可能会导致的硅胶套的热胀冷缩，或许会让手机一直受到一些不均衡的力？搞不好哪天就裂了。反正我们的实践结果就是如此，我的每一个手机都摔了很多次，都没事，她的反而有次真的就亲眼看着它裂开了，观赏了自我开裂的全过程……

> 一直装在硅胶套中使用 …… 左下角竟然裂开

问题就出在这里。

我和家人自 2018 年以来一直是按着索尼买，然后我什么都不用，不贴膜不上壳，就完全裸着用；对方则是又贴膜又带硅胶套。结果我的每一支索尼手机都完好无损（ XZ2 → Mark 3 ），然后她的则是每一支都会出问题（ XZ2 → Mark 2 → Mark 5; 其中 Mark 2 那代甚至换了两次荧幕……），而且也是像 OP 描述的那样，就是谁都没招惹它，自己就裂了。关键是我还手抖，手会经常抽一下，所以经常会掉东西，因此手机都不知道掉过多少次，XZ2 到后期边上都磕出小坑来了，荧幕也没裂。

多次劝过说别用那个套，就是不听，然后就接着裂。

所以劝 OP 下个手机试试别带套，别贴膜，看看能不能用得久一点。

遇到这种问题是不是因为没有把 Advanced keyboard settings 中的 ‘Let me set a different input method for each app window’ 开开，以至于输入法的切换是全局的，因此需要不停地来回切换？

这一设定的位置如下：
https://i.imgur.com/m6DznYQ.png
Windows 8 / 8.1; Server 2012 / 2012 R2

https://i.imgur.com/PUNvQTk.png
Windows 10; Server 2016/19/22

https://i.imgur.com/LR5F9mc.png
Windows 11; Server 2025

再之前的 Windows 版本预设的输入法切换就不是全局而是单视窗的，因此无需设定。

Firefox, 长期使用逾 20 年；
MediaWiki, 长期使用逾 15 年。