5G虎牙直播推流视频卡顿问题分析

点击上方蓝字关注「前景理论

  

一、问题描述

国内某个5G首发演示保障,与虎牙直播合作,在保障开始前开始的业务联调,存在推流卡顿的问题,具体表现:推流软件(obs)设置码率50M、分辨率4K、30帧,监控到丢帧率较高,速率达不到50Mbps,且深圳观看有明显卡顿。

  • 网络拓扑:

推流链路:推流PC->CPE->基站->核心网->承载网->视频服务器

拉流链路:拉流PC 使用potplayer播放器主动从服务器进行拉流观看

  • 站点分布:

二、分析过程

空口环境测试:UDP灌包和FTP上传可以达到70m以上,说明空口能力达标。

CPE镜像抓包可见,报文平均RTT时延在17ms左右,无丢包乱序问题,TCP流有少量重传0.27%

在基站使用IFTS 3201跟踪抓包可见:报文平均RTT时延12.8ms,无丢包乱序重传引入。

CPE镜像抓包和基站抓包说明基站以下时延低,没有引入丢包乱序问题,需要进一步隔离基站以上到核心网问题。

  • 安排测试人员到电信机房,直连设备进行推流无卡顿,非核心网以上的问题。

  • 基站S1-U会增加36字节GTPU报文头,如果TCP按照MTU 1500协商,发送报文最终会超过1500,基站出端口报文会分片为一个1500左右大包和一个小包,如果链路上某节点组包性能受限,容易引入乱序导致重传,从而限制TCP速率引起卡顿。如果修改终端侧设备MTU 1400TCP流会按照整条链路上的最小MTU(即pMTU)发送报文,基站发出报文不会超过1500,可以避免报文分片。

  • 若出现分片,可能会导致:

a) 增加了网络接收端处理报文的复杂程度,接收端需将分片报文重组。对链路中的设备能力要求较高。

b) 分片后,任何一片丢失,均须重新发送,增加了网络开销。分片后每片都含一个IP头,导致传输效率降低。

三、解决措施

修改终端设备的MTU(CPE)。从1500修改到1400,验证推流无卡顿,可以稳定推流码率50M、60M视频。

推流/拉流电脑进行TCP窗口优化。

a)关闭heuristics功能。netsh int tcp set heuristics disabled

b)优化TCP auto tuning。netsh int tcp set global autotuninglevel=normal

c)修改完之后可以用netsh int tcp show global查看是否修改成功。

四、经验总结

成功经验:

  • 4K推流对电脑性能要求较高,推流电脑应选用高性能游戏PC或游戏电脑,保证编解码效率和TCP流的稳定性。

  • 可以通过修改终端设备的MTU,修改为较低值,使得测试终端设备的MTU比链路MTU小,规避链路上增加报头之后,TCP报文需要分片、重传,导致的速率下降等情况。

不足之处:

  • 问题处理过程中仅定位出空口时延和丢包率指标正常,未能定位出基站以上丢包情况。后续类似问题需要总结方法,提升效率,与其他部门联合定位。

推广:

  • 高清视频回传/直播等业务对链路要求较高,从推流电脑到光路带宽、服务器等都需要提前按照高规格提供,避免更换设备造成不必要的时间浪费。

发表评论

您的电子邮箱地址不会被公开。