在局域网视频传输链路中，卡顿问题的根源通常藏在各个环节的协作里。下面从视频图像采集，颜色空间转换，图像编码，网络发送，客户端接收，图像解码，图像渲染全链路进行分析。
- 图像采集
图像采集阶段本身不会很耗时，不会直接产生卡顿结果。选择合适的截图方法，即使4K@30fps，CPU占用也不高，也不耗时，不是最终接收端渲染卡顿的瓶颈。后续处理(颜色空间转换，编码等)得当，可以以稳定帧率输出。
不过这里要注意：分辨率高，帧率高，编码后的码率就高，要考虑网络性能(尤其无线)是否能达到，超出网络收发能力，一样会有卡顿现象。
- 颜色空间转换
如果使用CPU转换，这里的性能损耗甚至比编码还要高，这是容易忽视的点。
图像采集得到的图像格式一般是RGB格式，一般会将其转换为YUV420P格式再进行编码，这样更加节省网络带宽，并且兼容性更好。颜色空间转换设计大量计算，一张4K图像RGB转YUV420p 大概需要60-80毫秒，且CPU占用也很高。因此，若想保证4k@30fps的分辨率和帧率，必须处理好颜色空间转换，否则要么帧率达不到，要不卡顿严重。
当然这里最好能用GPU转换，但GPU转换容易遇到驱动，系统等兼容性问题，不得不fallback 到CPU转换。
在实际工业生产环境中，颜色空间转换必须处理fallback 的情况，否则一旦不支持GPU转换，视频渲染必卡。
- 编码
如果使用GPU编码，这里性能和耗时一般是完全满足的，和颜色空间转换一样，这里容易遇到兼容性问题，同样不得不fallback 到CPU编码。
下面讨论CPU编码的情况。这是性能和画质权衡的关键点，常见的坑如下：
(1) 软编 CPU 打满：1080P 60帧的软件编码（如libx264）会瞬间占满多核 CPU。系统表现出严重卡顿，其他应用都用不了了。CPU编码的情况下，1080P 最好调整到30帧以下。
(2) 码率与关键帧：VBR（动态码率）在复杂画面下码率会飙升，造成瞬间网络阻塞。对局域网应用，强制使用 CBR（固定码率）更可靠。同时，将 GOP（关键帧间隔）设为 1-2 秒，能让接收端花屏后快速恢复。
(3) 延迟参数：很多编码器有"低延迟"预设，必须开启。还要禁用 B 帧（设为0），因为编解码 B 帧需要等待前后帧，会引入显著延迟。
- 网络发送
TCP 的确认和重传机制在有干扰的无线环境下会造成数据堆积，导致视频周期性卡顿。实时视频传输通常首选 UDP， 网络丢包问题一般通过 FEC 机制解决。
数据包分片：编码后的关键帧（I帧）可能很大（几百KB），必须控制MTU（最大传输单元）。若不处理，网络层分片后，任何一个分片丢失，整个帧就废了。
Wi-Fi 干扰与缓冲：Wi-Fi 受同频干扰、信号衰减影响大。AP 和驱动层有缓冲区，缓冲区过大反而增加延迟。有条件尽量使用有线。用无线时，可在应用层做小容量的抖动缓冲（Jitter Buffer，单位是毫秒级）。
- 网络接收
缓冲区与排序：UDP 会乱序。接收端需要排序缓冲区，按帧序号重新排列，超时的直接丢弃，绝不能死等。
组包机制：接收端收到分片包后需重组。要设置超时清理机制，防止一个分片丢失导致所有分片占用内存。
- 解码
解码：解码一般不是造成卡顿的原因，除非是高分辨率，高帧率同时叠加CPU软解码，例如4K@60fps。解码和渲染最好的选择是硬解+零拷贝渲染。
- 渲染
必须将硬件渲染使用起来。软件渲染必卡。
发送端和接收端在实际的实现当中，做好多线程，异步处理，各个阶段不要相互阻塞，实际当中也是造成卡顿的重要原因。