预期android设备上的实时流滞后

Question

当android设备的摄像头实时直播时，预计会有多大的延迟？我检查了Miracast，它的延迟大约在150到300毫秒左右(通常在160到190毫秒左右)。我有一个蓝牙和一个wifi直接应用，两者都落后约400-550毫秒。我想知道是否可以复制或者更接近Miracast的表演。我在H.264中对摄像机帧进行编码，并使用我自己的自定义协议在WiFi连接上传输编码的帧(如果是TCP )。

Answer 1

视频编码是计算密集型的，所以从硬件中获得的任何帮助通常都会加快速度。这是值得确保您使用的编解码器，利用硬件-即避免您的H.264编码全部在软件中。

这里有一个视频讨论了如何访问HW加速视频编解码器，虽然它有点老，但将适用于较旧的设备：

• https://www.youtube.com/watch?v=tLH-oGfiGaA

我相信MediaCodec现在为硬件编解码器提供了Java (我自己还没有尝试或看过速度比较测试)，这使事情变得更容易：

• http://developer.android.com/about/versions/android-4.1.html#Multimedia

请参见此处关于使用摄像机的表面预览作为速度辅助工具的说明：

• https://stackoverflow.com/a/17243244/334402

顺便说一句，500毫秒似乎并没有那么糟糕，而且你可能会陷入收益递减的境地，因此，如果你能忍受当前的滞后，减少的努力可能会很大。

另外，我假设您正在测量服务器端的延迟(或延迟)？如果是这样的话，你需要看看服务器是如何解码和呈现的，特别是当你将自己的玩家和第三方玩家进行比较的时候。

值得在接收端查看您的抖动缓冲区，而不考虑流等延迟--简单地说，在开始回放之前等待更多的数据包可能会导致更多的启动延迟，但也可能提供更好的总体用户体验。这是因为在进入用户通常不喜欢的“缓冲”模式之前，大型缓冲区将更能容忍延迟的数据包。

这是一种平衡，你的需求可能决定一种偏见或另一种方式。例如，如果你计划一个像应用程序这样的视频聊天，那么延迟是非常重要的，因为它开始对200-300 ms以上的用户变得烦人。如果你提供一个体育活动的反馈，那么延迟可能就不那么重要了，避免缓冲停顿可能会给用户提供更好的感知质量。