@teenight #1 试过，有用，然后又没用了，应该是和 dota2 有关
用系统自带的输入法比如微软拼音，然后打开 dota2 ，然后又开始跳了，原因分两边
系统自带输入法这边，比如微软拼音，它会导致状态提示栏里多显示一格，一共两格，左边一格是“中”，右边一格时“拼”，而纯英文状态下只有一格 ENG ，总的占据的宽度不一样，在这两个状态间切换，就还是会跳动
至于为什么会和 ENG 切换，因为 dota2 启动后会给系统安装一个“隐藏”的纯英文键盘，可能是为了防止游戏中的输入被输入法程序拦截吧，结果就是不开 dota2 一切安好，开了之后就乱了
https://steamcommunity.com/app/570/discussions/0/46476691633035335/
https://steamcommunity.com/groups/SteamClientBeta/discussions/1/864976115478357063/

所以干脆不用自带的微软拼音了，然后在第三方输入法里面选了一圈，发现还不如老古董谷歌拼音

我自己组装的，没在乎外观体积，用了老家不用的旧机箱，买了一块翔升的 N3150 集成主板，然后其他零部件也都是通用件，在保内我就不怕，而且说实话快 7 年了，没有哪个重要部件出故障或损坏的，我还都是买的便宜货甚至二手，而且真要坏了我也不怕再买一个直接换上去就好了

@ea3ba5c0 #6 电影，剧集，分开放，分开设置源

@lscho #1 不是哦，看轴承类型的哦，至于风量，看尺寸大小，我们还是先说说轴承的事情。
滚珠的是非常吵的，其实它里面润滑是很充分的，但是滚珠声音振动不可避免，转速一快非常吵。那么滚珠有啥好的呢，滚珠的耐用，非常耐用，价格相对便宜，风量更大一点。
磁悬浮是非常非常安静的，耳朵凑近了闻都不一定能听到明显的声音，搭配上减震垫圈，真的是安安静静。说是磁悬浮其实是吸铁石磁力排斥，并不是啥高大上，贵不到哪里。而且并不是完全靠磁悬浮，其实里面还是加了油的，也许是液压式，也许是含油式，磁悬浮只是一种辅助。
在乎噪声的就买磁浮的，磁浮+含油、磁浮+液压，很安静，价格贵一点点，风量稍微小点。

@uiosun 什么抽屉原理

结合各种房产相关的新闻，不得不感慨国内房地产行业的程序啦监管啦都跟演小品似的

买了 E900V22C ，用着很开心

@flyz #9 ocr

你改了之后，你这一次方便了，换个设备换个系统，换个用户，呵呵

@1054850490 #29
我没有用 yt-dlp ，我用的 youtube-dl ，我其实有点想用 dlp 的，但是我已经在原版的基础上魔改了几个提取器的 class ，比如 iwara 的，我又严重依赖这些改动，用着又没啥毛病，我又懒，所以我就没换 dlp 。

我的 youtube-dl 的配置文件：
--cookies ~/.config/youtube-dl/cookies.youtube.txt
-o "%(title)s [%(extractor)s %(id)s][%(uploader)s].%(ext)s"
--yes-playlist
--fragment-retries infinite
-icw
--external-downloader aria2c
--external-downloader-args "-x10 -s10 -k 1M"
-f (299/137)[height<=?1080][fps<=60]+(m4a/aac)/bestvideo+bestaudio/best
#--socket-timeout 30
#-R infinite

我用自己写的 tg bot 辅助下载，把 url 往 bot 聊天里面一扔就不管了，所以那一大堆下载的视频我并没有挨个仔细检查过。但就我确实打开观看过的那些视频来说，我没有发现肉眼可见的损坏，也许也少了几帧，那这种我肯定是不在乎的。
然后我从油管下载的时候，从来没走过 hls 协议，没看到 m3u8 相关的信息，基本全是 dash mp4 流，一个视频流一个音频流，全是 aria2c 下载的，可能跟我限定了媒体格式有关，就是这行配置`-f (299/137)[height<=?1080][fps<=60]+(m4a/aac)/bestvideo+bestaudio/best`。
从 p 站下的视频倒是经常走 hls ，然后偏偏 aria2 不支持 hls 嘛，然后它就分段下载，哎哟我去那个龟速我就日了，前几天我刚刚研究了这个事情，给 p 站 url 开了一个处理分支加了一点参数，`-f [format_id!*=hls]`，把带 hls 标记的媒体流给排除掉了，终于又可以通过 aria2c 秒速下载了。
hls 真的是坏东西，对下载而言，我个人觉得。

@pinkbook #10 我明白了，你说的是各个地区、尤其是小的区域的营业厅推出的优惠活动套餐的卡，这些活动和套餐在官网上不出意外是找不到的，因为这不属于省级的管辖范围内。
我说的是那种纯流量的物联网卡。

@pinkbook #5 流量卡嘛，N 道贩子，随时可能跑路，运气不差用个一两年也是可能的，但是给的流量虚高。
总结，还不如运营商官方推出的大流量套餐。

它缺的那几帧如果不是连续的二十分散再各处的话，人眼很难看出来的

@1054850490 #24 我只想知道，计算对比帧数的方法，能不能广泛用于各种视频损坏。

BTW 没人应得什么，没什么东西是谁应得的，任何人，所有人，无一例外。

1. 这玩意确实有运气成分在里面
2. 店大欺客不是说着玩的
3. 图便宜还不如上 pdd ，兴许还更靠谱点

https://www.v2ex.com/t/835357

我怀疑自己会不会要你的悬赏，我甚至怀疑另一个人是不是冲着你的悬赏才来分享方法的。
但在此之前，我更在意的是，他的那个方法，能不能适用于所有损坏的视频。

@yogogo #164 离线硬盘也用，NAS 也用
存 储 多 样 化 ！

@anytk #10 谢谢告知，原来 refind 用处这么大，以后多系统启动不用愁了。
你的建议我都做到了，也顺便补充一点，开启了 bitlocker 的 windows ，需要在 bitlocker 的管理里先暂停保护，不然的话……bitlocker 的恢复密钥一定要保存好

@1054850490 #10 细节处理肯定不会通用的，但正确的思路、模式是能够泛用的。我实践了一下，发现还是卓有成效的，但并不是每个有问题的视频都会输出类似的错误日志、都会输出相同的关键词，需要针对不同类型的损坏添加特征集，一遍一遍地筛查。但毫无疑问，这个过程肯定是自动化的，是比人工快得多的。

首先作为演示，我们需要一个视频作为对照组，为表诚意，当然得选择“同类型”的视频啦，好在我的收藏里是有这类视频的，虽然只有唯一一个：
[직캠_Fancam] 150520 밤비노(BAMBINO) (은솔) 댄스공연 Intro @ 건양대 [nljhfXCcXlE][pharkil 2015].mp4
https://anonfiles.com/D262Hc6dy4/_Fancam_150520_BAMBINO_Intro_nljhfXCcXlE_pharkil_2015_mp4

那么，先用`ffplay -i filename`来播放它，好的，播放正常，播放过程中可以左右 seek 跳转快进快退，都没问题。不过在播放到结尾的时候，画面并没有消失，ffplay 程序也没有退出，底部状态那一行还在飞速变化，我们看看它显示的什么：
91.23 A-V: -7.910 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0
91.23 是当前播放位置，其实已经是视频结束了，这个视频就这么长，所以这个数值尽管在跳动，但其实不变了。
A-V 这个数值，看字面意思，莫非是音频轨和视频轨之间的差值？好像是这样的，播放过程中，这个值是一个在 0 附近跳动的微小数值，体现了音画之间的同步差值。但等到播放结束之后，音频肯定停了，但画面还在跑（虽然只有黑屏），于是这个值开始在负轴上一路狂奔，朝着负无穷勇往直前。
这个时候，如果再按右键进行快进，那么自然是“异常”的，虽然程序不会退出，但是会打印红色的错误信息“error while seeking”，嘛，说得通，毕竟后面已经没了，播放结束了。
那么，如果是加速播放呢，用命令`ffplay -i filename -vf "setpts=0.1*PTS"`，跟刚才差不多。唯一不同是，播放过程之中，A-V 就开始往负轴跑，毕竟音画不同步了，这个命令只调快了画面。顺便，setpts=0.1*PTS 按理来说应该是 10 倍速播放，但结果显然不是，只有 2 倍多一点，我不知道为什么，先不管。
那么，如果换用 ffmpeg 转码呢，自然也是没问题的，因为这个视频本身没问题嘛，所以转码过程没任何不良消息。顺便一提，我这台笔记本显卡是 RTX 3050 Ti ，30 系显卡的硬件转码真的是又好又快啊，我用 ffmpeg 自带的 nvenc 编码器，转码倍速能到 20x ，即使不缩小输出画面尺寸也能有 18x 。

好了，对照组完毕，现在来看看实验组样品。

220708 #뮤직뱅크 퇴근길 #비비지 #VIVIZ (#은하 #신비 #엄지) Fancam-宽度 1920-码率 4445.735-编码 avc1.640028-频道名(전람회)-网页地址 olOzlESoEh0.[origin].mkv
出门口的这个视频。
这个视频问题明显，所以输出日志中的错误消息也很明显，一大串的类似下面截取的消息：
[NULL @ 000002e318718d40] missing picture in access unit with size 276
[h264 @ 000002e318771000] Invalid NAL unit size (0 > 5688).
[h264 @ 000002e318771000] Error splitting the input into NAL units.
[NULL @ 000002e318718d40] Invalid NAL unit size (0 > 36089).
[NULL @ 000002e318718d40] missing picture in access unit with size 36093
[h264 @ 000002e3187aec00] Invalid NAL unit size (0 > 7954).
[h264 @ 000002e3187aec00] Error splitting the input into NAL units.
[NULL @ 000002e318718d40] Invalid NAL unit size (0 > 5930).
[NULL @ 000002e318718d40] missing picture in access unit with size 5934
[h264 @ 000002e3187af0c0] Invalid NAL unit size (0 > 21100).
[h264 @ 000002e3187af0c0] Error splitting the input into NAL units.
[NULL @ 000002e318718d40] Invalid NAL unit size (0 > 19469).
[NULL @ 000002e318718d40] missing picture in access unit with size 19473
真的是一大串，不停地刷屏。你看，这种特征明显，关键字固定的错误最好找了对不对？ ffplay 和 ffmpeg 跑都是这样的错误，好了，这个类型的损坏视频算是搞定了。

우주소녀 루다 부탁해-宽度 720-码率 897.992-编码 vp9-频道名(지구젤리)-网页地址 flh-q3MpgVg.[origin].mkv
舞台上白色短裙的这个视频。
这个视频特征不明显。ffmpeg 转码（目标容器格式维持原格式，mkv ）的时候，一共蹦出来三行警告：
[matroska @ 000001745e3eae40] Invalid DTS: 15100 PTS: 10133 in output stream 0:0, replacing by guess
[matroska @ 000001745e3eae40] Invalid DTS: 25233 PTS: 17700 in output stream 0:0, replacing by guess
[matroska @ 000001745e3eae40] Invalid DTS: 45500 PTS: 35267 in output stream 0:0, replacing by guess
但如果转成 mp4 的话，则完全没提示任何错误警告，仿佛没事一样。
那么如果用 ffplay 来播放呢，也没输出错误警告。
好吧，这种缺帧的视频我们就认怂换个思路，老老实实比对实际帧数和理论帧数吧。