平均码率*（播放时间+缓冲时间）≈总下载数据量
码率看单帧看不出来的。单帧图像的总和比视频流码率算出来的结果要高一大截……

@iyg429 抱团了那还叫 Linux 么，你看上头这帮人自己都快打起来了

有线鼠标带 usb 转接头？或者带 docker ？

@Chingim Dolby Vision 大概率不能，HDR10+大概率不能，非 x264 或部分其他格式大概率不能。
电视盒子不能解的东西多了去了……

你调过 Linux 底层的 bug 的话就不会问出用啥系统这个问题了，家用高性能 NAS 肯定 WinServer 方便啊……Linux 不说别的，调个 iSCSI Target 坑比 Win 还多……

然后再跑一趟 MIPS 的看看交叉编译多久

跑一趟 OpenWRT armv7/v8 版编译，带 LuCI 就行，看看要多久……

我印象里这四个最后都是调的 trunc，所以没区别（？），你可以自己创建几个文件 strace 下……

誰にだって訳がある
Born to be free

别买 R7 1700，不省电性能也不行，尤其是跑 Chromium 编译这种事。而且一代 ryzen 有概率编译时 core dump （ Linux 高负载编译限定 bug ）
Ryzen 上二代及以上稳定得多，而且省电，单线程效率也好。
电源就别省这么多了……正常电源带低功耗模式根本不会启动风扇。
散热可能有问题，but 你可以选择换个机箱解决。

交叉编译了拷过去啊……

归根结底不是什么 INT3 的问题（说这个的你用过 od/IDA 么），是 release 模式有优化，编译器会打乱代码行序并且清除大量的编译相关信息以提升运行性能。这样你最多能看到调用了啥函数（某些 stripped 了的程序你连调用栈信息都看不到，里面只剩各种指针了），内部有什么指令偏移多少的信息没了，调试器看到你的源文件的时候不知道去哪里找对应的指令下断点。
为啥 vs 的 release 模式就支持下断点呢，人家有 pdb 文件啊！
debug 模式下编译器会在程序中插入调试用的符号表，以及使用未优化的代码（确保每行源代码都能对应上特定的二进制指令），所以下断点容易得多。

不知道 clion 有没有
-跨任意平台远程 debug，前后来回上下跳甚至直接右键执行特定行
-支持 qt 到 mfc 的所有 C++标准的 intellisense，上到 app 下到单片机的 C 都能写，前提是你配好远程编译器和调试器，以及头文件依赖。
-不卡，不死机
-自动生成图形化的头文件调用树
-ClaudiaIDE （大雾
-文件过滤器
-查看函数之类的调用树很清晰
缺点：CMAKE 支持差，安装体积也不小。

用不了，商店本身 bug 。打开就报错而且始终修复不了，Windows 支持找了几遍了也没用。

换个 1T 的 C 盘就够了。

罗技就行，雷蛇质量太差了

Windows 进程挂了弹的那个窗口可以通过注册表或者组策略禁用 WER 解决。
https://www.hotbak.net/key/%E5%A6%82%E4%BD%95%E5%8F%96%E6%B6%88windows%E4%B8%8B%E5%BA%94%E7%94%A8%E5%B4%A9%E6%BA%83%E5%90%8E%E5%BC%B9%E5%87%BA%E7%9A%84%E9%94%99%E8%AF%AF%E5%AF%B9%E8%AF%9D%E6%A1%86%E8%BF%90%E7%BB%B4wiCSDN%E5%8D%9A%E5%AE%A2.html

@132hong 这东西哪有计算标准，都是看 CPU 性能的