测阻值，测压降，多简单的事情
至于怎么暂停，现在哪还有连上线就充电的，整个充电流程都有专门的芯片负责管理的

还不如组个 ITX

@jedihy #10
@Heiban #11
这不是种族歧视，而是膈应微软印度帮的做事风格，他们手里确实糟蹋了不少好东西

v2ray 套 https 再套 cf

病理性的老年痴呆没法靠日常生活习惯来规避的呀，这个取决于基因和环境诱因
非病理性的痴呆来源于用脑过度休息不足、接触的信息量不足

不知道，但你不妨试试 QT （ pyqt5，pyside2 ），搜搜看 QT 框架内有没有现成的 API 能实现你的需求
毕竟 QT 早已不是单纯的 GUI 框架，而已是跨平台的操作系统接口封装集

还可以直接贴收款码接受捐赠，随缘

请善用各类“要饭”平台，比如：
爱发电
patreon

@paoqi2048 #59 本世纪中叶搞不好会来一场，看五大流氓的运营能力和战略克制力
毕竟二战后已经过了三代人了，痛苦的记忆早已随风飘逝，但这其实不是最要命的，最要命的是，当代人以及可预期的未来的后代们，缺乏克制欲望和跨群体关怀的意识与能力，这个意识与能力，才是真正能帮助人类避免纷争、解决矛盾的核心力量
然而，瞅瞅眼下的社会主流价值观语境中的峰值坐标在哪个象限吧：崇尚物质消耗、关注个体幸福、信仰尊卑贵贱、制造地区冲突
“克制欲望和跨群体关怀的意识与能力？笑死个人了！”
不教、不学、不会

@black11black 屏蔽完还特意告诉我别回了难道就能显得你大度机智吗？难道就能掩盖你的理亏愚钝吗？难道就能让你的观点自动变成正确的吗？

我要懂什么才能用 hevc 和 avc 这两个词？这俩词都指代压缩标准，你不懂的话可以去看 wiki 。而现实语境中，hevc 经常拿来指代 h265 编码或者编码器本身，avc 倒是在语境中用的不多，但是只要有人讲大家就能听懂是什么。

当初测试 x265 编码器的不只是国内动画压制圈，全世界压制组有闲的都多多少少参与了，因为当初大家不知道什么样的参数能达到什么样的结果。

压制组压片讲究具体片源具体调参。片源质量好的话可以省不少精力，否则就要加滤镜、跑 avs，分片段分场景调整参数，因为一套参数不适合全片。

压制组付出这么多，是因为他们最后发布的成品必须是高品质的，因为不乏高清收藏党们对画质音质有着颇高的要求。

但也不乏就听个响、看个故事的人，这样的人实际上非常多，所以压制组也不是每个都追求质量、花大功夫去调参，那些 0day 组、为了让看客尽快看上片的速发型字幕组，都是用简单参数快速压一遍，力求尽快发布。当然这些组的作品质量是入不了高清收藏者的法眼的，但它们自有受众。

那么，像我这种找个编码器简单设置几个参数的到底逗在哪里呢？逗在不会装逼？逗在践踏了你心目中复杂参数模式的优越性？还是因为你自己心虚理亏又不知道如何反驳又不敢撕毁自己伪君子的面具对我恶言相向，所以不得已用了“逗”这个字，来指望我会因为这个字就被你吓住，然后妄自菲薄自惭形愧？

难怪你还要结尾来个拉黑通知勿回的无脑三连，原来你是真的心中憋了气但拳头无处挥。

然后最为可笑的一点是，本文意图实验在相似画质时这几个编码器输出的文件大小和所需时间的差异关系。你自以为是自行脑补的“圭臬”是从哪里看出来的？

写到这里我好像有点明白你一直念叨的这么测没意义是什么意思了，合着你以为编码器默认参数压根发挥不出它的效能？

假如你真的这么认为的话，那真的是要让人笑掉大牙了。因为默认参数固然是不能达到最期望的输出，要想输出符合自己需求是必然要调参的。但是你无论怎么调参，你都逃不了必须在画质、体积、速度里面取舍，这在我前面回复你的时候就重点讲了。

同一个编码器，你可以通过细调参数来获得更精致的画面，但是压制所需的时间就会变长，文件体积也会变大，因为需要更多的运算来分析图像，描述图像中的细节也需要更多的数据量。

此外，同画质 hevc 编码所需要的时间是 avc 的几倍，文件体积则可以下降 30 ％左右最多可以减一半，这不需要我做这个实验，业界早已有了大量的实验数据来支持这个结论。

那么请问你能通过调参，让 avc 的码率利用率反超 hevc 吗？不能。
你能通过调参让 hevc 的压制速度超过 avc 吗，不能。
你能通过调参让 avc 变得像 hevc 一样适合超高清分辨率但同时对像素块的涂抹现象更严重吗？不能。

所以将变量控制为只有 crf 一个参数，才能使这样的实验变得有意义，因为只有一个参数变化，所以实验结果反应的是各个编码器的平均表现随着这个参数变化而发生的变化。

连这点都看不出来，说明你是缺乏实操经验的人。也难怪你不停地拿我跟压制组比，合着你是想借压制组的模式来打压我的方法，因为你自己没有能拿得出手的经验。这一招贼喊捉贼用得也太显眼了。

最后，总有人辩不过别人就嘲笑别人“写这么多累不累”，以此来妄图给自己挽回点颜面。殊不知这一招纯属自损，在原有的理亏愚钝的短板上，又加了两块：人懒、笔弱。不然也不至于会灰溜溜拉黑逃跑，是不是？

@locoz #25 你指的是总算力，不是单“器件”算力，这里的“器件”可以理解成单芯片
计算芯片的架构、工艺已经挤了十几年牙膏了，intel 狡猾固然是一方面，但平心而论这管牙膏已经剩的不多了，它要不慢慢挤这么多年怎么恰饭，怎么维持股价
硅芯片制程早已到天花板，10nm 以下的工艺用的定义方法全是等效值，而不是真实微观尺度
而即使是这种带水分的工艺，什么 7nm 、5nm，也都是天花板下的哀嚎了
这还没算上能效提不上去导致的高发热所带来的的致命问题，工艺越高，单位面积内晶体管越多，散热面积却越来越小，散热难度指数级上升
整个微电子行业的基石已经撞墙了

@ISSSSSSS #21 炒豆子应该是 APM 功能导致的吧？你把它禁用不就行了

@shunconf #29 所以这种时候就要反过来质问他们究竟想要什么样的，要他们把特定的需求描述出来，我不管你们需要用多少篇幅来讲反正要给我讲清楚。
这既是在气势上反客为主，也是很务实地在沟通需求，你们光说这个不行那个不行，那是不行的，你们得说什么样的你们觉得行，这才行。

@locoz #14
非常赞同你关于“微服务”和“边缘服务”的观点，这才是既以务实之态度整合当前技术而成经济实惠的方案，又不会在某一条道上过于极致而误入歧途
至于云需要算力这一点上，云当然需要算力，但云所需要的算力提升远远小于端，因为端对算力的需求是有峰谷的，而云则可以将各端错开的峰谷在一定程度上抵消。此外，云可以更容易实现供能、散热、传输，这些都是云的成本优势，所以云会蓬勃发展起来
但是者不代表云的需求能够促进技术革新，尤其是击穿天花板的革新
实际上端的算力需求也不能促进革新
实际上需求对技术发展的促进作用是极为有限的
原因前一帖说过，技术受限而需求急迫的情况下，几乎总是会导致技术的发展在迷宫中找到一个“最经济”局部最优解
然后这个局部最优解将持续十几年甚至几十年地疯狂吸钱、人、产能
这样的局面会长久持续、不断嵌套迭代，从宏观上看到的现象就是技术么是一直在发展的，但是曾经那个让大家头痛的问题并没有被解决，而社会中残留的问题则在不断积累乱象和矛盾
最后这些乱象和矛盾突破阈值，迎来总爆发，大萧条，或者世界大战，或者其他什么，反正也没得选，因为这些麻烦总是要来就一起来
然后重新洗牌，而在这个过程中原先的利益规则无以为继，人们为了生存解放了拷在自己身上的陈旧的商业逐利枷锁，不计成本甚至忘却生死地去探寻更多的可能性，去尝试去探索，这个过程的结果就是基础科学的跃进
然后和平降临，这波基础科学的红利可以供几代人吃喝糟蹋
我们现在所处的这波“战后经济”正面临基础科学红利消耗殆尽的窘境

我的理想是每个人都能利用自己的智慧和身边的环境做出自己需要的工具和产品，而不是受限于某些“大家都在用的产品”

我写的东西少，我开源的动机就很简单了，我需要这个工具，没有现成的，只能自己做
不是为了别人，当然也不对别人负责
熬夜写代码调试仅仅是因为我自己急着要用
所以就没有这些烦恼了

@murmur #10
@ElegantOfKing #7
我认同 murmur 关于“对云服务需要谨慎提防”的观点
这个观点背后的逻辑其实与技术并没有关系
很多人就是看到新鲜事物、看到技术发展就非常开心，就忘乎所以，就尽情拥抱
平心而论这跟某些人看到巨款就张开双腿放松括约肌的条件反射如出一辙
技术本身是双刃剑，永远都是
商人逐利且只逐利，再好的技术到他们手里都不能得到充分的发展，而只会窝在某个盈利最大化的局部极值点
然后这个坑一蹲就是按十年计的漫长光阴，将人类社会大量的人力、物力、以及最最宝贵的时间原地消耗
这十几年来，围绕云的技术实践和商业布局愈演愈烈，这个行业本身是对旧技术的改良
对企业而言，云端化可以将服务和数据管道化，以最少的成本得到最大的市场普及率，并提高利润率
而消费者对此的放纵与默许，将使信息技术的商业实践在“租赁化”这条不归路上继续狂奔二三十年
而人类在微电子和信息技术方面其实早就摸到天花板了
接下来单芯片算力的提升和微型化，需要基础科学的革命性突破才能击穿这个天花板
虽然这个天花板也是促使“云”诞生的压力，但是，对“云”的过分投入，将吸走大量的资本、人才、产能
而这些被吸走的要素，恰恰是击穿这个天花板所需要的，而且是不可替代的

现在资本和消费者对“云”的拥抱、狂欢、憧憬，这种在“云租赁”这条道路上一条道走到黑的态势，会阻滞接下来至少半个世纪的技术升级
因为人、时间、生产力、思想观念都被疯狂所占据了

@Nostalgiaaaa #3
@oneisall8955 #4
随机排序的另一种实现（笑

不是，你（他们）光说不要什么，可是却没说要什么，这怎么找？