video_replay如何捕获和回放WebRTC视频流

最新推荐文章于 2024-09-26 09:15:00 发布

LiveVideoStack_

最新推荐文章于 2024-09-26 09:15:00 发布

阅读量1.9k

点赞数

本文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/79543578

版权

video_replay是WebRTC的一个工具，用于复现和分析视频解码问题，尤其在数据包丢失导致的显示异常时。通过wireshark捕获RTP流，结合chrome://webrtc-internals的信息，可以使用video_replay离线解码并重现问题，便于调试。文章介绍了如何捕获未加密的RTP数据、提取必要的信息以及如何使用video_replay进行回放。

摘要由CSDN通过智能技术生成

视频编码问题常常是最难解决的问题之一，video_replay工具可以帮助分析定位故障。视频协作平台pixip的工程师Stian Selnes撰文，详解了如何通过video_replay来捕获、分析视频的。LiveVideoStack对本文进行了摘译。

文 / Stian Selnes

译 / 刘庆超

在数据包有丢失的环境下进行视频解码不是一件容易的事。Chrome 58中引入了一种新的视频抖动缓冲区，这导致最新版的Chrome在视频显示时一直有问题。由于该问题只在某些数据包丢失时才会出现，因此调试难度很大。为此，webrtc.org提供了一个名为video_replay的工具来复现和分析这些棘手问题。

当看到Stian Selnes提交的一个版本中视频显示仍然有问题时，我将这个工具告诉了他。将视频流轻松重现后，谷歌的WebRTC视频团队很快就解决了这个bug。不过，这一过程的记录做得不是很好，所以我们请Stian重现了抓取必要数据和使用该工具进行操作的过程。Stian目前在pexip工作，他有超过10年的实时通信处理经验。他在媒体协议栈领域有非常丰富的经验，特别是在视频编解码以及其他类型的信号处理、网络协议和错误恢复能力等方面。

WebRTC包含了一个非常好用但鲜为人知的工具——video_replay。事实证明，在调试视频解码问题时，这个工具非常好用。它的目的是什么呢？为了在发现异常行为之后能容易地重复捕获WebRTC呼叫，video_replay将捕获的RTP流视频作为输入文件，然后离线使用WebRTC框架来解码数据，最后在屏幕上显示输出的结果。

例如，最近我正在研究一个问题，有一个版本的Chrome显示输入的视频时突然出了上面这样的问题。最终，使用video_replay调试后，WebRTC的团队发现，Chrome中实现抖动缓冲区的部分出现了一个错误，这导致视频流在某些情况下显示会有异常。这种看似随机数据导致的错误其实是VP8解码器的内部状态引起的。

视频编码问题常常是最难解决的问题之一。最初，我自己写了一个测试方法，每20次调用中大约复现1次这样的问题。使用这种方法重现问题是非常耗时的，效果通常也不好，最终也没有给WebRTC团队解决该问题起到什么作用。

为了可以多次重现这个问题，我设法使用wireshark捕获到一个失败的呼叫，然后使用video_replay工具来分析。这样我就有了一个每次都能重现这个罕见的问题测试用例。当一个问题具有重复性的时候，解决问题和打补丁就非常轻松啦！这是典型的双赢局面。

在这篇文章中，我将通过一个例子来演示如何使用video_replay，包括如何来捕捉一个WebRTC呼叫的RTP通信数据，识别和提取接收到的视频流，最后如何导入到video_replay中来实现在屏幕上显示捕获的视频。

捕获未加密的RTP数据

video_replay将输入的文件导入到RTP协议栈、协议包解析设备和解码器中，不过目前还没有能力解密加密呼叫使用的SRTP包。Chrome和Firefox都支持加密呼叫，但是解密WebRTC呼叫却不是一个简单的过程。尤其是SRTP进行秘钥分发时使用DTLS来保密共享，因此该秘钥难以获得。为此，最好用Chromium或Chrome Canary，因为它们有一个可以禁用SRTP加密的选项。启动浏览器时添加命令行标志–disable-webrtc-encryption即可，如果在窗口的顶部看到警告信息，说明你使用的浏览器不支持命令行标志。注意，这要求双方在通话都不能加密，否则会话将无法连接。

首先，使用Wireshark捕获数据包。在会话开始发送媒体数据之前就要打开捕获功能，这一点很重要，因为这可以将整个流都能记录下来。如果捕获的数据中丢失了流的开头，视频解码器将无法解码。

第二，打开一个选项卡，进入chrome://webrtc-internals (或者Fippo最新的webrtc-externals).。呼叫之前首先做这个，以获取所有需要的信息，特别是SDP协商信息（如果想深入分析该问题，请见webrtchacks SDP分析指导）。

最后，就是呼叫了。我们以appr.tc为例，但适用于任何使用WebRTC的呼叫。打开第二标签进入https://appr.tc/？IPv6 = false。由于目前video_replay尚没有IPv6相关的解决方案，因此在这个例子中，我将其禁用，希望该问题能很快解决。

现在，加入一个直播室。当第二个参与者加入同一个房间时，RTP将开始流动。不管谁先加入，除非chrome://webrtc-internals看起来有异常。下面的截图是在拨号进入现有房间时拍摄的。

收集信息

为了从接收到的流中成功获得RTP包，并能顺利使用video_replay播放，我们需要收集一些关于RTP流的细节信息。有几种方法可以做到这一点，我坚信最重要的是下面这几个：