文章目录

• 一. P2P的SDK到底做了什么
• 二. P2P原理
• • 1. 同流分享思路
  • 2. 目前方案
• 三. 使用P2P后产生的问题
• • 1. 有概率出现loading转菊花
  • 2. 首次打开速度明显慢于正常的通道1-2秒
• 参考文章

一. P2P的SDK到底做了什么

P2P的SDK在我们App启动后其实是开启了一个服务，固定端口去监听。这样又个好处，防止频繁开关HTTP服务，节省频繁开关时间。
播放的时候将链接换成http://127.0.0.1/xxxx.flv,实际上这只是一个实时的换链操作，这个新版SDK顺利解决了我们的几个痛点

1. 可以单独做成一条线路
2. 支持我们秒开操作

二. P2P原理

1. 同流分享思路

目前P2P的4个节点，从用户去拉数据。用户往上推的时候是在每个视频帧前面都插入SEI帧，SEI帧里面有编号。比如现在我看了一些视频，上传了编号是 0 1 2 3 4 5 6 7 8的视频帧，那么播放端会氛围4份 ，每个id都%4.然后按上图一次进行播放。如果某个节点数据有异常的时候，会提前从cdn拉取。这里有点类似我们之前做的直播的AI流控的逻辑，可能会出现双路流同时拉取的情况，虽然p2p的sdk做了缓冲机制，但是这里的临界点是难以完全把握好的，就可能出现偶尔的播放过程中的loading的情形。这个点和P2P团队沟通了我们当时做直播的AI流控的的思路，这里确实难以解决，目前经验是看大数据来分析。
P2P的SDK每次请求会去自己的后台拉取一份配置列表，相当于我们的灰度配置。做一些策略。

2. 目前方案

分四路子流0/1/2/3

1.刚开始是请求完整流
2.运行一段时间会请求子流，0/1/2/3
3.子流运行比较平稳的时候切P2P流

三. 使用P2P后产生的问题

1. 有概率出现loading转菊花

了解方案这个问题目前确实难以彻底解决，但是出现概率不大。

2. 首次打开速度明显慢于正常的通道1-2秒

非直播车的节点难以命中，需要回源，会增加回源率。所以目前已经和p2p团队沟通后进行了改造。白天都tdns，晚上走直通车。这样既然可以减少回源率，也可以减少首次打开的时间。

参考文章

1. 腾讯云X-P2P