都用上 RTMP 了，还怎么降低延迟。TCP 方案是没办法降低延迟的，只会增加延迟。
选 WebRTC 靠谱一点。编码和解码环节其实都会引入一帧以上的延迟，200ms 还是一个过于理想的值，屏到屏只有网络好的情况下才能达到。GOP 值太小，建议设为 2S 或 3S，1S 会造成传送的速率过高。
8000kbps 有点过高，你这个测试是不经过 CDN 的，如果是订阅的人多于一台机器带宽的承载量，必然要引入 CDN 分发，也会加入延迟。
图形传送基于分组域的解决方案，除非传送的数据量特别少，或者只走局域网，否则基本上没啥办法做到百毫秒级别的延迟。

在 AVC 时代，x264 在很长一段时间内被公认为画质最好的编码器。但是 HEVC 时代 x265 并没有压倒性的优势。同样压缩率的情况下，先编几个场景用肉眼评估一下，如果区别不大就选那个快的。

@FutherAll 惭愧，没认真审题。我以为方法 1 和 2 在内存分配上有区别

我并不觉得这两种方式存在本质的区别， 好奇心让我试了一下，发现上面答案提的并不是最主要的因素，是代码写的有问题，只需要把方法 2 中的`matrix2[j][i]`中的 i 和 j 对换一下，能跑到比方法一更快。

没改之前：
go run test.go
2.103482788s
8.669886344s

改之后：
1.69951775s
1.543304649s

尝试把方法 1 中的 i 和 j 位置也换一下:
go run test.go
9.274899793s
1.484341903s

结论：变化快的数字应该做低维下标，如果 i 是外层循环变量，应该把 i 放在前面。

好像很有些道理

大部分的项目都不是一开始设计出来的，都是无数的 Feature Request 讨论出来的。
你关注一个开源项目时间长一点，仔细的看一下 changelog，尤其是 PR
写一个文档可能没多久就会过时，很多人就不会愿意写这些内容

交流电是一个等效电压，实际有一个高压和低压不是这个值。懂的人说说

去年 10 月初取消以后到现在还没见到有人报告新办的有 CN2 。如果楼主办了以后发现有麻烦通知一声

@imherer postman 好像会自己解压 gz 的东西，方便你查看

FPGA 视频编码方向有没有兴趣

赶紧换电池

你说的这个可以参考一下 buffered chan 。申请 chan 的时候指定长度即可。
ch := make(chan []struct{}, 1000)
监控容量情况更是简单，len(ch)就是当前队列中未处理容量。

交钱加入安全联盟，很快就解封了。要是在意的话
不在意的话就挂着，挂个一年两年的，也就解封了

@ODD10 我只是怀疑这两个 SSID 的处理在同一个板子上的逻辑有干扰。我见过路由器可以开 4 个 SSID 的，看上去是隔离的， 但是出了问题后会有相互的影响