问题描述：

       两台大禹的rk3568设备进行 wifi display投屏。在sink端看到界面非常卡顿。

实际体验感受：

      每次在rk3568的source端操作界面的时候就会卡顿验证，几秒甚至达到将近10s画面不会切换。

分析思路：是否是底层wifi p2p链路质量差，导致丢包严重。

分析步骤1:tcpdump抓取报文进行分析

       双端设备进行时间同步，然后同时抓取tcpdump报文。分析是否有严重丢包。视频数据采用的传输协议是UDP。

分享sink端的tcpdump日志：

证据1：丢包率低还卡顿！

       分析-->启用协议-->搜索mpeg，所有选项都选上。

       分析-->启用协议--->搜索rtp，   把rtp_rtsp,rtp_udp都勾上
       然后选中一条mpeg数据。电话-->rtp-->rtp流分析

结论：rk3568卡顿。跟丢包率没有关系！

证据2：通过tcpdump导出视频观看是否卡顿

这样可以导出Payload。直接用VLC播放器是否卡顿即可证明问题

步骤二：iperf打流分析。

在source端和sink端之间进行 iperf的udp打流。 source端做iperf的client端。sink端做iperf的服务端。

针对iperf打流做进一步分析：

            对照组：   在Source端不做任何操作，仅安静投屏，同时运行iperf。此时iperf带宽稳定在15M。

            实验组：   在Source端做切换界面的操作，同时运行iperf，可以看到iperf带宽剧烈波动。频繁地域15Mbps

附录：投屏需要的带宽：