产品经理应该懂的直播业务发展（二）

直播的场景越来越丰富，娱乐直播，商务直播，视频会议等，特别在疫情期间，每个人都成为了直播会议的使用者。但这不代表人人都是直播产品经理。 从早期的直播推流到服务器，直接拉流，到现在互动直播的不断进化，各种直播玩法也层出不穷。 我写的这个《产品经理应该懂的直播业务》系列，主要是从直播底层入手，让产品经理更好的理解直播的能力。

每个阶段会遇到很多问题，不论是业务上的，还是技术上的。

当观看端网络速度不足怎么办？

一般主播端推流上行速度是可以保证。观看端用户群情况不同，下行速度，影响的因素比较多，比如弱网，4G，信号覆盖位置等。

比如直播推了一个2M的视频流，那观众就会收看这个2M的视频流。但观众端，下行的网速不够怎么办？

这时候就在源站服务，加直播多清晰度转码集群，多码率的策略（上行端），和播放器监控卡顿切线的策略（下行端）

比如主播推了一个2M的1080P的源流，那么通过源站服务，向下转成480p、360p等低清晰度、低码率的视频流，作为直播流的选择效率让CDN去分发。观众端，播放器根据自身情况，去选择清晰度。

直播想要更多观看终端观看怎么办？

在2014年开始，移动互联网开始迅速发展，并且chrome 和 其他浏览器支持的插件有差异，都促使直播技术需要支持不同的终端，当然像pc客户端，app等，可以定制开发去支持播放。但在不同浏览器（桌面 ，移动）终端，如何适配播放。

这是就需要，最优的协议选择，和终端适配，在《产品经理...直播业务发展（一）》里提到过，把源流的RTMP通过CDN可以封装不同协议，RTMP 、HTTP-FLV、HLS等，都是对源流的封装，视频内容是一样的。但这里需要注意的是HTTP-FLV协议需要浏览器MSE支持。

这里RTMP ,HLS, HTTP-FLV协议的优缺点，网上有很多比较，这里就不重复介绍，值得一提的是chrome在2020年底终止对flash的支持，虽然RTMP很成熟，但需要依赖flash插件。在移动端app，客户端等还会继续使用，但在浏览器H5将不会有容身之地。

hls并不是一个真正的流，实际是HTTP短链接，对切片下载播放，优点适配性最好。缺点就是延时太高，ts碎片多。

http-flv，在封装上和RTMP很类似，用的的HTTP长链接方式。延时和RTMP差不多，缺点就是兼容性，有些浏览器不支持MSE；产品经理需要注意的是，是否有支持这三种协议，播放器SDK的开发。策略是检测兼容性，根据业务要求，选择播放协议。长期来看HTTP-FLV会是H5的主流。

如何看直播内容回放？

很多教育客户，有直播回放的需求，产品经理会根据这部分业务做深挖（直播生成回放业务，和回放剪切业务等），这里简单的说一下流程，之后会针对点播系统，另写一篇。

这里也是对服务源站增加一个直播录制服务系统，点播系统。策略是直播录制+点播系统，对源流进行HLS切片存储，然后对接到点播系统。

综合以上业务迭代，形成了一套比较完整的，直播服务。

这套方案，可以理解为普通的直播方案，区别于互动直播。像娱乐直播平台，公开课等采用。

这些主播会很熟练的使用第三方工具，如OBS、VLC等推流工具。但作为直播产品经理，需要去了解一些网络检查手段，去研究竞品（当然你也可以直接和RD小伙伴说，我要这个功能...），排查问题。我是有这Geek信仰的PM所以喜欢研究这些，不光是功能的前因后果，还有实现的目的，及边界。

检查手段：F12 、 wireshark 、charles等。

- F12如何操作，对于直播，知道用到什么协议。F12 - > network 我们可以看到 Request URL 的地址。

- RTMP协议F12搞不定，需要用到wireshark，等工具抓包；移动端等可以用charles 等工具抓包。

大概在2017年的时候，直播整个行业变化，很多企业转向了互动连麦的方向。因为以上的解决方案，只适合一个人推流，其他人观看，延时高。但面向互动连麦的方向，产品也遇到了很多挑战，将在下一篇讲解。

---

原创声明：本文由顽童LOCK原创，转摘请注明出处和作者。

---

发现telegram上几乎没有产品经理的存在，抱着试试看的态度，如果有产品经理使用tg，加入telegram的产品经理群https://t.me/WeArePM

tg：wangtong73

twitter：@wangtong_73

wx:pmideas