@happinessnch #81 你回不回的，又如何，at 你的楼层是为了明确上下文，写了又不是只给你一个人看的。就算你不特意说明接下来不回，难不成我还催着你回复吗？我要真那么做了，屏蔽是干嘛用的？虽然我自己坚决不拉黑别人，但并不认为这个功能的存在有何不妥。

为什么总有人要把视频编解码这么复杂的体系看成一个单独的算法？哪怕是这个体系中的每一个环节，也都是由多个不同算法构成的，并且有些算法还不是强制的、固定的，是可增减的、根据条件选择的。选择的根据不仅仅是用户指定的参数，还取决于各个软件、硬件的具体实现，即使严格遵照标准依然有巨大的灵活发挥空间。
再说用户只能指定更改哪些参数，剩下大量参数既然没有被用户指定，那就保持默认值，而这个默认值不同的软硬件实现也可以不一样。至于参数本身，标准体系内的参数也不是非得全部暴露出来，标准之外的参数也不是不可以加进来。
说到底，还是前述的那样，标准体系之下有着巨大的灵活发挥空间，软硬件编码器怎么实现、怎么设计、怎么在标准的基础上取舍、乃至魔改，八仙过海各凭本事。

你心心念念的所谓“一样的算法”“一样的参数”这些前提，从一开始就不存在。除非我们是在讨论同一个软硬件实体的同一个版本，而不是现在这样在讨论众多不同的软硬件实现。

运动预测这方面，标准只规定要按照怎样的“语法”来描述运动，至于这些运动偏移是怎么估算出来的，标准才不管那么多。其他方面也是，标准的存在是为了统一用来描述静态和动态画面的方式及相关的数据结构，只要能保证这方面的统一性，就能保证统一的可解码性，并能保证解码结果的统一性，至于是怎么编码出来的，根本不在乎，反正编码结果数据的语义和数据结构符合标准就行了。

所以编码器在对画面作运动预测时，是以一整个画面为范围，还是划分成 4 个、16 个、64 个小块来提高并行度，这是编码器的自由，也不会违反编码标准，反正不管用何种方式进行预测，只要预测的结果能被其他解码器读懂就行。给 CPU 用的软件编码器有着充足的内存空间和强大的运算单元，不需要再考虑把单帧画面进一步切割。GPU 上的运算单元都是些功能孱弱的弱单元，显存也不够一众核心分，所以在给核心分配任务的同时限定各自的搜索范围，这都是在客观因素制约下的因地制宜的手段。

所以你结尾总算说了一句事实，（同一视频编码标准下的，各种不同的软件编码器实现，和各种硬件编码器）压根就不是一个算法。所以也别拿自己参与过的项目来类比这个项目之外的、更广阔的的、你所不熟悉的领域了。

@happinessnch #40
你的发言佐证了我一直以来的一种观点：专业人士很容易把自己的知识技能经验外扩到自己的专业之外，而现如今是一个“专业割裂”严重的时代，同领域同场景下看似同专业实则不然的情况太常见了，很反直觉是吧。
我们看看视频编码本质上是个什么运算，在如今仍然主流的基于像素块的编码思路下，无非是在二维矩阵上搜索、跟踪大量的像素群是如何随着时间移动、变化的，并将这些运动用尽量少的数据描述出来。这部分工作就是运动预测、运动补偿，除此之外的工作，诸如量化、采样、宏块切割、滤波、频域转换、熵编码（无损压缩）等等基础计算虽然同样重要但并不是影响最终编码效率的关键因素、或者虽然也是关键因素但影响比重明显小于运动预测。
那么，如何高效、准确地进行运动预测？最理想的情况是，在整个画面上进行搜索跟踪。但这就带来一个“负担”，这么大的矩阵是要占用不小的运行内存空间的。
如果是 CPU 跑编码算法无所谓，大把的内存条，空间管够，反正就一个计算单元，整个图像范围由它承包。一个运算单元负责一整个图像，而且现代 CPU 性能强劲，在强力的分支预测加持下，视频编码算法中大量的分支条件判断压根不算个事。
GPU 就惨了，一堆运算单元，却个个都是残废，光是一个 if-else 就够这些单元跑半天了，这些单元也就只能胜任某几种模式的数值计算罢了，让它们进行复杂逻辑判断真是要了亲命。那么单核心这么弱，是不是得把工作分一分啊，那肯定啊。那咋分呢，每个 GPU 运算单元该复杂多大范围呢？负责的范围太小的话不行，这个单元上一帧还能看到画面上那只手呢，下一帧这手直接移动到它负责的范围外面了，它直接懵逼，顺带它隔壁的单元也跟着懵逼，咋我的工作区里多出来一只手，我之前跟踪着的那只眼镜呢？那么范围大一点行不，要不干脆直接大到一整个画面范围得了，反正一帧画面是大家共用的嘛，又不用多占空间？不行，画面数据是公用的，但每个单元负责的任务数据是独有的，每个单元负责的范围越大，它要分辨的数据量就越大，它能识别并跟踪的目标就越大，目标运动范围、运动模式就更复杂，记录这些数据需要的空间就更更更大，字面意义上的几何式增长。显存一共才多大啊，就算它 8 个 G ？几百几千个核心等着分呢，笑死，根本不够分。
那取个折中行不，也不整个画面范围了，也不弄得范围太小，取个过得去的中间值吧。行，事实上也是这么做的，然而即使如此，一旦跑起来，依然是内存直接拉满，但核心却依然有大量空闲。真没办法了，每个核心负责的单元不能太小，不然动不动丢失跟踪目标，没法玩。就这样，整个画面依然被划分成了不少的范围，一旦动起来，依然频繁出现目标从一个区块跑到另一个的情况，引起巨大的编码浪费，它们要真是直接瞬移过去的还好，关键是一帧一帧慢慢过去，中间的每一帧上，这些区块的边界上充斥了各种不完整的目标碎片，严重的能造成几倍的编码浪费。
所以大家都懂，都会玩，说是 GPU 硬件加速编码，其实负责编码运算的根本不是 GPU 核心，而是另外单独的专用视频编解码电路，核心撑死了帮忙做一些外围辅助工作，视频编码的大头工作全交给专用电路，intel qsv ，nvenc ，诸如此类，概莫如是。

所以，你当初参与的那个项目的那个算法，大概率是一个本来就针对并行计算特性所设计的模式，压根就不能发挥出 CPU 这种能胜任复杂任务的强力运算单元的优势，而更偏向于照顾 GPU 单元这种多而弱的运算架构，而且既然已经是针对并行运算所设计的视频编码算法，毫无疑问逃不开上面所述的“分割画面范围导致跟踪对象丢失引起大量冗余编码”的弱点，那自然是就算用了 CPU 来跑也不会得到更好的画面或者编码效率。

@yongboy #8 感觉跟原来那块差不多，我是放在减震架上的，两边和底下都有橡胶柱，所以哪怕是有大的动静也不会传导到机箱，所以基本啥都听不到。

@liuzh365 #46 并不是让你换，只是作为对照情况测试一下。对照的数据越多，越容易发现端倪。
单进程只能跑到 50%，说明瓶颈很可能在其他地方，既然网络被排除了。
除了 potplayer ，也可以考虑其他播放器作为对比，或者，不是播放，而是直接 4K 视频文件，看看速度如何。

上面有人建议你先试试 FTP 的传输速度，你确定不试试看吗

@Zys2017 #6 菁百数码，现在价格 930

@liuzh365 #41 这就不在我的经验覆盖范围了，但是感觉瓶颈在别处

@ailuoliai #4 那我用到猴年马月也不一定装得满哦

@liuzh365 #39
J1900 单核性能和我用的 N3150 差不多，而且还略强于后者。但 N3150 单核性能不足以支撑 smbd 的负载子进程跑满千兆，我家里差不多跑到 70M 左右的时候，负载进程就单核占用 100%了，J1900 应该大差不差也是差不多的成绩。
但你说 60%，这就有点。这 60%是整体 CPU 占用，还是单线程占用？如果是整体只能到 60%，那有理由怀疑是过热降频。如果是单个 smbd 的子进程占用单核 60%然后上不去，那果然还有其他瓶颈（话说这种情况我觉得挺怪异的）

@caryqy #2
还可以哦，以我的标准来说的话。
而且因为是家人，所以整场团战我的输出基本等于零哦，是值得赞扬的呢

对了，这块 8T 盘花了 850 元

我就没这么多烦恼，我多年前直接选择 ubuntu server ，一步到位，满意至今

@ungrown #37 算了无视我的回复吧，我没看完你的帖子描述就胡乱提建议了

@liuzh365 #29
排查：
- iperf3 跑一遍，看看“跑满”是什么样子
- nas 上 htop 看看 cpu 负载，smbd 的子进程很吃 cpu 的

我正在用的 MiWiFi R1C ，如果你对性能要求不是很高的话，这个型号应该凑合够用，而且很便宜，闲鱼上二三十吧
https://openwrt.org/toh/hwdata/xiaomi/xiaomi_mini_v1

@sjzjams #25
也许你 at 错人了，反正我没觉得他说的使用习惯有啥大毛病，也许确实增加了一些工作量。
我个人是用原地升级的，毕竟便利性放在那不用白不用，但我同样不相信它，我的数据确实也是要么在其他分区，要么另有备份，要么在坚果云端。

@wazon #113
文叔叔我也不用，抱歉拿它当了例子。
wetransfer 我这儿直连速度能到 MB/s ，用 transfer 命令行工具可以多开上传任务，所以并行速度能成倍提升。

@zy0829 #34 就在本地移动营业厅网点（得是分店，不是那种外包出去的小服务点）直接问，优惠活动一年四季都有，正好赶上没活动的空窗期的概率很小。
后续快到期时一般 10086 会主动联系推荐新优惠活动，比如我家原来的 100M 今年就被推荐直接上 15 元的 300M 。

@wazon #107
我还是要再啰嗦一次。

还不行的话那就还是回到 wetransfer 、文叔叔之类的文件中转服务上，反正都支持匿名，找几个国内速度够快的就行。（奶牛快传现在必须得注册才能用了，不够方便，所以略过）。
虽然单词中转分享的数据量只有 1 、2GB ，但是可以分卷啊，一个脚本的事情。上传下载也不用手动点网页，GitHub 上有个叫 transfer 的项目，命令行工具，支持多个这类服务的上传下载，wetransfer 、文叔叔也在支持列表上。
写个脚本，这头把 40GB 分卷，然后上传到中转服务，把获取的链接保存到一个文本文件，然后把它发给对方，对方用另一个脚本把这些链接的分卷全部下载，然后本地拼接、解压缩。完事。

这个方法不是挺好的么，我自己就在用类似的流程，只不过我的数据少还没必要分卷。
你选这个方案，只要写两个稍微有一点点复杂的脚本就行，也不一定是脚本，反正拿你熟悉的语言写个小工具，撑死了 100 行左右的代码，然后就能愉快地使用了，根本不需要什么对象存储、CDN 、开设服务器之类的多余操作。