近期对流媒体技术的思考

Posted 2021-09-09 LiveVideoStack_

点击上方“LiveVideoStack”关注我们

作者 | 刘歧

很久没有更新公众号内容了，主要是想分享一些具体技术之外的内容，但是想到这是个流媒体技术号，分享其他东西也不太合适，直到 Joe Li 兄台提醒我很久没有分享内容了，我突然意识到自己应该是怠惰了，应该勤奋一些，为大伙多分享一些技术内容，不过今天我还是没忍住，破例在技术号灌个水吧。

从年初到现在跟各领域的朋友们交流后对几个大伙频繁聊起的方向做了一些思考，主要分享的信息内容如下：

1. 音视频流媒体技术对计算机技术新人不友好？

2. 开源技术商业化前景如何？

3. 音视频流媒体技术的开源商业化前景如何？

在开始分享之前，我先多说几句。

近几年观察国内的音视频流媒体技术群体，其实依然还是小众群体。跟成立，连响，包老板，赵委员，杜老师我们常在一起分析音视频技术与其他技术的差别。其实如果仔细想想，技术群体比较发达的主要是这么几个方向，我看到的比较火热的部分：

1. 云计算、K8S、云存储等，以前还有OpenStack，CloudStack等，也许还有区块链技术

2. 大数据ELK（可能我已经Out，但是大体上可以理解是大数据那个群体）

3. 数据库，关系型数据库，非关系型数据库，GraphSQL等

以上是听到的比较火热比较多的热词，但是了解并不是特别多，也并不是我重点关注的方向，所以理解难免会有片面，那就片面的归纳一下特点。

这些群体有几个共同的特点：

1. 有最终受惠用户（比如我们作为网银用户、看剧用户）

2. 有一定专业操作但是不会用代码修改内部实现的维护者（可能叫运维、也可能叫DBA）

3. 有一定代码能力并且能够修改、优化、设计内部实现的开发者（不论是原创还是参与代码级别贡献）

这样的群体用漏斗型来形容可能也算是比较贴切，人员数量从最终受惠用户到开发者收口，最后代码级别维护者就是漏斗最下面那部分的人群，这样的状态看上去比较健康，有开发者，有非开发的维护者，有最终受惠用户，而且群体比较大，所以天花板看上去会高一些。开发者也可以根据自己的想法做各种调整然后优化，所以可玩性比较多。

1.音视频流媒体技术对计算机技术新人不友好？

    

音视频流媒体技术对新人并不是不友好，其实是门槛可见，只不过这个门槛对于很多新人来说不喜欢，甚至避之而不及，并不是说这么做是错的，只是这是一个筛选音视频开发技术人员的最好的自然门槛，如果大胆尝试跨这个门槛的话，他就相当于毫无门槛，但是如果真的回避了或者绕行了，那就真的是个门槛了，而且门槛还很高。举个最简单的例子，nginx大家都用，大家很多人或多或少的看过Nginx的代码，但是又有几个人照着Nginx的代码重头到尾实现过一遍呢？哪怕是早期的Nginx版本，这就没那么多人了，所以从头到尾实现过一遍的那些人，在实现的过程中遇到了问题，去学习解决问题，去思考为什么这么做等问题，自然就学习到了很多东西。音视频也是一样，只不过大多数情况下是对照着参考标准去实现，为什么呢？因为音视频这个领域有很多参考标准，而这些参考标准如果你不去对照着参考标准去解析的话，将不会成功的把音视频数据从封装中读取出去，这个封装可以理解就像是Linux系统下面的打包工具tar一样，tar我们打包的时候只要这么操作就可以了:

打包 tar cf package.tar dir解包 tar xf package.tar

注意，这是打包和解包，并不压缩。只不过音视频领域的打包姿势各有不同，有微软的姿势，有real公司的姿势，有Apple的姿势，有ITU的姿势，有RFC的姿势，有Adobe的姿势，还有……怎么样?是不是突然觉得姿势挺多的？没错，就是姿势多。新人不需要全做一遍，但是至少自己生活的土壤中还是要将常用的打包和解包的姿势学会，否则很难有入门的感觉，遇到问题也无法解决。

而压缩呢？还是用tar来举例：

打包并压缩 tar cjf package.tar.bz2 dir解包并解压缩 tar xjf package.tar.bz2

用过tar的人都知道，这么做可以压缩成bzip2的包，如果这么解包与解压缩的话肯定是会报错的：

tar xzf package.tar.bz2

因为这个是解压缩gunzip的压缩包，用来解压缩bzip2的话算法是对不上的。没错，压缩与解压缩的姿势也需要对得上，音视频也一样，只不过这个压缩与解压缩的姿势比较多而已，而且也涉及到新旧交替的周期比较长。例如H.264压缩到H.265(HEVC)，现在还有H.266(VVC)，除了H.2xx的姿势，还有VP6、VP8、VP9、AV1、AV2等姿势。如果打包与解包的姿势对了，还想继续深入一些的话，这些姿势能自己实现一遍也需要对着参考标准实现一遍，才能够理解得比较透彻，否则真的比较难跨过编解码的门槛了。

除了封装与解封装、编码与解码之外，还有传输协议的理解，如果不亲自对着参考标准实现一遍的话，理解起来也会有一定的偏差，例如HTTP、例如RTSP/RTP/RTCP、例如RTMP、例如QUIC、例如SRT等等。这些都理解得差不多的时候，恭喜你，已经很完美的骑在这个门槛上了，至于另一条腿是否能够进入到这个门槛里面，真的就需要多在工作中实践，踩坑了。

所以请注意：

/如果你身边有一个从事音视频技术开发的朋友、同事，请珍惜和他的友谊，因为他对音视频技术确实是真爱，而且是深爱的那种，经历过这种门槛的程序员并不多，因为这种门槛如果只是为了挣钱并非爱好的话，他真的在看不到未来的时候就放弃了。/

2.开源技术商业化前景如何？

    

我不是个商人，只是个开源技术爱好者，也并不是一个成功将技术商业化的创业者。本经阴符七术养志法中也有说过“欲多则心散，心散则志衰，志衰则思不达也”，诸葛武侯的诫子书也说过“非淡泊无以明志，非宁静无以致远”。如果作为开源技术开发者，主要精力其实更应该集中于如果将开源社区运营好，因为要应对伸手党、白嫖党、Review贡献者的代码、跟开发者们交流功能的可行性、性能优化的姿势等，还要推广自己的开源程序，这就相当于做市场，任何一个开源软件其实都需要做市场宣传，酒香也怕巷子深，因为人家不一定去巷子口，人家去的是豪华大酒店。Linux开源软件也在不断地宣传和推广，FFmpeg也在推广（例如NTTW这种，主要是面向图书馆，博物馆的数字化群体），开源软件很多时候不一定必须面向程序员，不一定非要面向计算机技术从业者，跨界也是需要的，思路还是要打开的。

但是做了这么多，主要还是在花钱，既然要商业化主要目标还是应该是在挣钱方面，可是开源社区做的事大多数情况下确实是在利他，想法其实也没有那么多的。如果非要加入到收入方面的考虑，市场占有率方面的考虑的话，是不是社区就会被金钱所污染？会不会就不那么纯粹了呢？目前从事开源的大多数是因为爱好，如果加入了金钱的元素后，如何判断是为了赚钱多一些还是为了利他多一些呢？如果资金链断了或者没有金钱继续注入的话，这个开源社区是否还能够继续进行下去吗？我理解的是没有标准答案，因为不同的个人站在的位置不同，给的结论应该也不一样，但是确实这对我来说是一个疑问。因为现在从事计算机这个行当的好多人我确实已经无法确认他们到底是为了挣钱还是真的是爱好了，只是流媒体开发者这个群体中真正的爱好者目前看还是能筛选出来的，因为投入产出不成正比，学习投入成本比较高，收益又不一定有多少，不像是前端开发那样大多数情况下可以速成，所以大多数还是真爱。

3.音视频流媒体技术的开源商业化前景如何？

正如前面提到的背景中，音视频这个行当的门槛若有若无，导致了从业者的群体并不是特别多，所以各大公司招聘人才的时候会明显的发现音视频流媒体专业的人就那么点，而且主要是开发者，也就是漏斗下面那一部分。音视频领域没有DBA这样的角色，没有IT运维工程师这样的角色，最终受惠用户遇到问题的时候，问题第一个落脚点就是开发者身上，很显然缺少了DBA，运维工程师这样的群体。加之本来群体也不大，所以这部分还需要继续深度发展一段时间，主要是需要有一个像数据库，云计算，大数据等这样的健康一点的生态，门槛稍微降低一些，让更多的人参与进来才更适合谈商业化前景。

写在最后

总结，当前音视频流媒体技术建设方面，由于前面讲述的各种断层、群体差异性、若隐若现的门槛的存在。团队的稳定性是重中之重，大多数决策层并不是很在意这样的稳定性，因为在潜意识中存在的理念是没有人是无法替代的，但是容易忽略一个事实，那就是音视频技术在不同的应用场景会存在位置不同的坑，没有谁是绝对正确的，也没有谁是绝对错误的，只不过踩过的坑的位置存在不同，前人踩过的坑，新来一个人有很大的可能性也会再踩一次，经验特别充足的人又不一定会亲自去踩某些坑，这样就需要为不稳定的团队结构而买单了。比如某拥抱变化的公司，时不时调整一下，这样其实不太利于音视频技术的沉淀的，所以某些时候服务并不像某司那么稳定，再比如某司的视频云团队就比较稳定，并且还不断有经验充足的人加入进行能力补充，服务也是眼看着越做越稳定，差别还是可见的。

本文来源：

---

扫描图中二维码或点击阅读原文

了解大会更多信息

喜欢我们的内容就点个“在看”吧！