建议：像甲壳虫一样增加“不渲染过期帧”功能选项

[arkhubs]

建议：像甲壳虫一样增加“不渲染过期帧”功能选项。这样在低码率但是网络本身延迟高的情况下，延迟会小很多。最明显的b站界面、文件管理器界面等进行的滑动操作

[qian9008]

现在的代码配合 Android 底层机制，已经是“最完美、性能最好的丢帧策略”了。

很多不太懂底层架构的开发者，在遇到网络卡顿时，会试图自己在客户端写代码把过期的视频帧扔掉。但在我们这个项目目前的架构下，完全不需要画蛇添足，因为 Android 系统在两端都在自动帮你做这件极其复杂的事情，而且做得比任何手动写的代码都要好：

1. 服务端（被控手机）：最顶级的“源头丢帧” (Backpressure 机制)
   如果你的网络非常卡，导致 1MB 的 TCP 窗口和底层发送队列被塞满，代码里的 Os.write() 就会被阻塞（排队等待）。 由于写不进去数据，负责压码的 MediaCodec 就会停工。 当 MediaCodec 停工时，负责截取屏幕的 VirtualDisplay (虚拟显示器) 发现没人接数据了，它会直接把最新的屏幕画面丢进垃圾桶，连编码都不去编！

效果：不仅节省了网络带宽，还省下了大量的 CPU/GPU 算力和电量。只有等网络缓过来了，它才会抓取当下“最新的一帧”去编码。这就是传说中的背压（Backpressure）自适应网络，是最好的丢帧方案。
2. 客户端（控制端）：SurfaceFlinger 的“视觉丢帧”
假设网络突然顺畅，服务端之前积压的一小波数据（比如 10 帧画面）瞬间打包发到了控制端。 控制端在几毫秒内解出了这 10 帧，并疯狂执行我们改过的 mediaCodec.releaseOutputBuffer(outIndex, true); (立刻渲染)。 这时 Android 底层的屏幕管线（SurfaceFlinger）会介入：因为手机屏幕刷新一次需要 16 毫秒（60Hz），在这 16 毫秒内如果你强行塞给了它 10 帧画面，它会自动把前 9 帧“过期”的画面全部抛弃掉，只把最后一帧也就是最新的一帧渲染在屏幕上。

为什么千万不要手动去丢数据包？
视频编码（比如 H.264/H.265）是有严密的前后文依赖的（P 帧依赖前面的画面）。 如果我们在传输或解码前，强行把“过期”的数据包从代码里扔掉，会导致解码器立刻崩溃或者满屏马赛克、花屏（因为失去了参考画面）。想要恢复正常，只能苦苦等待下一个关键帧（I 帧）的到来。

总结： 我们这一路的修改（去掉冗余帧、解开帧内刷新限制、放大 1MB 通道、关闭时间戳同步改成直接渲染），其实已经把这套架构调整成了极低延迟的最佳状态，完美利用了系统自带的双重丢帧机制。你不需要再写一行代码去处理过期帧了，目前的方案就是最优雅、最流畅的。