成本优化之使用P2P的方案的需要了解的本地SDK的背后的原理

一. 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

猜你喜欢

转载自blog.csdn.net/weixin_45581597/article/details/127865969
P2P
今日推荐