全国服务热线:0551-64931480

04
18-12

直播视频秒开背后的技术与优化经验

李雨来 758426 0

  使用常见的视频直播服务器,比如Nginx-RTMP做一个简单的Demo环境。我们用OBS往Nginx-RTMP上推流,随便找一个播放器播放。一般情况下,我们会看到一个黑屏,然后过一会之后,它才会出现图像。我们对比一下,如果我们看手机直播,像陌陌直播,映客,我们点一下播放按纽之后,一秒钟之内视频直接就出来了。今天我们要讲的内容就是这个差别是怎么形成的,背后的原理是什么。出现黑屏的原因很简单,就是解码器没有得到能解码出视频图像的数据,那么导致这个问题的原因就很容易定位了:

  比较搞笑一点的说法就是你家的网络比较慢;

  视频直播服务器没有打开关键帧缓冲。

  那么就这些了吗?我想对于这个问题来说确实是这样。为了探究其中的原委,接下来我们需要往下去挖掘一下视频到底是怎么播放的。

  视频是如何播放的

  视频要播放它肯定是有视频数据,把视频数据放到编码器,然后编码器把这个视频数据解码出来,解成图片,然后播放到显示器上,这是一个基本的播放流程。一般来讲,大家现在主流的用H.264编码。对于H.264编码来说,我们会有三个不同的帧,所谓帧是什么呢?就是你看到的每一个图像。我们看到动态的视频,大家知道电影最开始用胶片拍的时候,每秒是25帧,是每秒25个图片在切换。对于H.264来讲,我们常见的有I帧,P帧,和B帧。

  1.I帧,I-Frame也有人会叫Inter Frame,那么它的意义是什么?

  (1)它是一个自描述帧,你可以理解为它就类似一个jpg图片,它里头所有的数据,你解出来之后,它就是一整张图片。

  (2)无其他帧引用,它不需要去做前置和后置的引用。

  (3)它压缩比是最小的,因为它要包括整个图片所有的数据在里头。

  2.P帧,P-Frame也就是说预测帧,它的预测帧是怎么回事呢?大家有没有用过版本管理软件,比如git或SVN,这样可能大家会比较好理解,P帧就是保留变的部分,不变的部分你去上一个或者几个帧里面找就行。P帧只是负责向前引用,也就是任何一个P帧,它只看它往前的这些帧的数据。P帧的好处是什么呢?因为它只存一些变化信息,所以它大概的压缩比是I帧的50%。这个数据哪来的?大家可以去翻一下维基百科,那里会有一些介绍。

  3.B帧,B-Frame,前后双向引用预测。

  B帧比较特别,它要引用前面P帧某一部分的图像数据同时B帧后面的数据也会引用,这个是B帧的特点,它要引用前面的数据,也要引用后面的数据。那么它的优势就是压缩比比P帧还大,大概是I帧的25%,也就是我们B帧用的特别多的话,它会把视频的大小降的比较低,因为它的压缩比更大一些。

  I帧,B帧,P帧它是怎么组成一个视频流呢?我们管这个东西叫Group Of Picture,简称叫GoP。

  视频解码器,看到GoP它是怎么放呢?那很简单,编码器会有一个缓冲,然后它会保留从I帧开始,当然现在说是I帧,其实这个I帧还有个特殊的类型。从I帧开始,他会把数据缓存到解码器的Buffer里,当他遇到下一个P帧,或者再下一个B帧的时候,它会从它Buffer里找到它之前引用的那个帧,然后把这个数据解出来,最终播放到显示器上。那么缓冲区开始的第一个帧肯定是I帧,这个毋庸置疑。另外还有一个比较特别的点,B帧和P帧并不会只引用当前GoP里的帧,他可能会往前去引用上一个GoP中的帧。既然它有这么一个特性的话,我们什么时候去清空这个缓冲区呢?这里就要介绍一个新的概念,叫IDR帧。

  IDR帧

  IDR帧是I帧,但I帧并不一定是IDR帧,所谓IDR帧是什么?它就是拿到这个帧之后,播放器可以直接从这个帧开始往后播放,它保证后面的P帧和B帧的引用不会跨越这个IDR帧,那么看到IDR帧,编码器就可以把当前的Buffer清空,从当前这IDR帧开始解码往Buffer里边放,后续帧就可以从Buffer里的数据引用,然后解码,也就是说编码器可以从任何一个IDR帧开始解码。大家可以联想到,当我播放一个视频文件的时候,我可以拖动,但是我拖动的任何一个点,它肯定是一个IDR帧,当然它也是I帧,但是并不一定说每一个I帧我都能让它作为一个拖动的点。

  IDR帧有时也有它不太学术的叫法:关键帧。在做编解码程序的时候,我们可能会看到FFmpeg的数据结构里会标着PTS和DTS,那么PTS和DTS是什么呢?

  PTS和DTS是什么

 

  PTS,Presentation Time Stamp也就说这个帧什么时候会放在显示器上;DTS就是Decode Time Stamp,就是说这个帧什么时候被放在编码器去解。那么如果全是I帧和P帧,PTS和DTS都是单调递增的,那么如果我们有B帧,会出现什么情况?因为大家都知道,对于B帧来讲,它会引用前面的帧和后面的帧。

  我们看这个例子,就是当B帧进来的时候,因为它要引用后面的P帧,也要引用前面的I帧,可以看到DTS的顺序,一三四二,然后PTS顺序,一二三四。B帧它会根据它编码时候的特性,它会自动的把它的DTS时间戳往后挪,把它引用的帧先放到前面去,等它引用的帧解完了,数据解完了之后,才会把B帧去解,否则的话,我先把B帧放进去,它引用后面的P帧,P帧的数据还没有,B帧解不出来。所以说这点上给大家讲一下,B帧,P帧,I帧它们整个放在一个视频流里面,它的解码顺序和编码顺序,当然后续的话,我们可能会根据这个有一些开放性的思考。

  为什么直播会等待

  对于直播来讲,它是一个流,它不像点播,大家都从0秒开始,任何一个视频文件,0秒第一个帧肯定都是关键帧。那么对于直播来讲,我是一个随机的时间点接到这个视频流进行播放,那么我接入的这个时间点的帧有可能拿到的第一个帧的数据是I帧,也有可能是B帧,也有可能是P帧。这是一个随机的。在这种情况下,我们大概率会出现一个黑屏的状态。因为我拿到的是个P帧,对于P帧来讲,解码器面那个Buffer是空的,它不知道这个P帧如何进行解码,所以它只能丢弃这个帧。

  对于直播来讲,我一秒钟的帧数是固定的,只能等到我下一个关键帧到来的时候,我才能开始去播放。当然正好赶巧了的话,接入那瞬间得到的数据正好是个I帧。就可以达到秒开的效果。

  关键帧缓冲如何工作

  其实是在cache服务器上,它会去预先解一下这个帧,然后去看它到底是个I帧,还是个B帧,还是个P帧,当它发现是I帧的时候,它会放在它的程序的内存里头,当你每一次打开这个视频流的时候,cache服务器会把内存中的I帧发送给客户端比如当前播放到了P帧,那我把P帧前面的I帧和P帧全波放到cache的内存里,然后当客户端接入之后先把内存里的数据发送给客户端解码器,然后再从这个B帧往后给。对于这个解码器来讲,它很舒服,它接到第一个数据流的第一个包肯定是I帧,那么它就可以直接播放了。

  如何去做到秒开?

  没有什么好的方法,任何人做这种事时候都是一个笨的方法,就是去看文档,没有什么捷径。大家可以翻阅FLV视频文件格式文档,它会告诉你package里头,它任何一个Video里的package有一个Video TagHeader,对它是有一个Frame Type,Frame Type如果把它解出来,它是1的时候,它管这个叫key Frame,咱们看后面这个AVC,a seekable Frame你可以理解为它是个IDR帧,它并不一定就是I帧。

  几个问题

  1.开放性的解决问题,GoP Cache是从当前的这个GoP帧开还是从上一个GoP开始

  这个问题比较有意思的是我从上一个GoP放的话,我拿过来的肯定是直接可以放了。因为有时我也预见过一些比较特殊的编码,会导致我从当前这个GoP的第一个I帧拿播放器放出来,我这样可能会提高编码器的兼容性,但是它会有一个问题,就是如果GoP开的特别大的话,那么我的延时自然而然就会上去。因为我上一个GoP如果是十秒,等于说我拿的是十秒之前的数据,也就是你看到的是10秒之前他说的话,他做得表情,他做的动作。那么我从当前这个GoP开始,它肯定是有一定的延迟,但是不会大到超过你整个GoP。对于视频直播来讲,我们GoP size多少合适,换一句话讲如果GoP size设成0,所有都是I帧,不存在任何GoP cache问题,但是码率来讲会很高,因为所有的都是I帧,我们知道它压缩比会比较低,那么反过来,就是我需要设一个GoP的Size是多少呢?

  2.视频直播的GoP Size设置成多少合适

  一般来讲,对于手机直播,一到两秒可能是比较合适的,因为它本身的GoP时间也不会很长,我这边缓冲,一旦出现问题大概一到两秒这个视频也能出来。有一个不太好的地方就是它码率会稍微高一些,也就说同样的东西,如果我把GoP改成十秒,我可能是500K,但是我改成一秒,有可能变成一个六七百K的样子,这个还是跟编码有关系,具体的比例是多少,可能跟实际相关。

  另外如果是点播的话,不关心首屏打开时间,只要是客户端下来速度快,CDN给力,那么我可能要求更小的范围。告诉大家一个实践过程中得出的结果,大家用过OBS?比如说做主播的话,大家用OBS会比较多,OBS它有一个问题就是它默认的话,如果你不调它的特性,GoP就是10秒,10秒的意思就是说GoP size。如果比较点背的话,看的是10秒之前的,如果是比较大的话,它的码率,码流的大小会小点,但是延迟会稍微高一些,CDN开了几个cache,有些情况下,我们也可以做些转码,强行把它的GoP size压小,整个CDN层面上加一个转码的话,它可能会增高这个延迟,这块一个开放性问题,大家可以根据自己的场景去思考,这个GoP Size配成多大比较合适。

  3.你在视频直播中到底用不用B帧

  我有时候在搜相关的资料,也有做直播的不用B帧,所以这一块我并没有什么结论,就是说给大家一个点,让大家去想一想。鉴于B帧之前看的DTS和PTS的PPT,也知道B帧在解码的时候,它是要打乱每一个帧传入解码器的顺序,如果丢包或者一些特殊情况,它可能会影响解码器的运行的特点。

  一个数学故事

  我不知道有多少人听说过这个事,就是1943年以前,二战的时候,因为英国被德国打的都已经找不着北了,他希望美国在后面支持英国,然后去做一些物资上的支持,那么就会有很多的商船,运输船把它的物资源源不断的从美国送到英国,德国人反制方式是什么?它的狼群潜艇在大西洋里逛。对于军事学家来讲,他们可能想不出来一些什么好的办法,他们就请来一些数学家问我这个商船怎么开比较合适,能保证一个是我的损失最小,另外一个我物资运送最大,碰到狼群的次数越低。这些数学家根据概率统计的概率论,然后得出一个结论,就是一定数量的船队编队规模越小,编次流越多与敌人相遇的概率就越大,换句话来讲,就是我这个船队肯定是攒足了,比如说我原来有一百艘船的货运量,那么我每一次发一艘船过去,那么我可能遇到狼群的概率会大一些,但是我把这一百艘船变成一个编队,然后我把我的护航编队做到足够好,我把我这一群送过去,我碰到的狼群概率很低的情况下,我可能效率更高一些。

  数据包与网络抖动之间的斗争

  我们从这个数学故事发散去考虑一个问题,我们把视频的数据保管好,运维的数据保管好,当成我们的运输舰,把网络走动,丢包,我们想成是一个狼群,就是德国的潜艇在整个大西洋上跑。我们就可以根据这个数学结论去考虑一个特殊的点,我们的发包节奏是什么样的。

  因为我发一个包,比如说我发出一个数据包过去,你可以理解为,我从美国发了一批货运船,带了一行护行舰队去往英国,那么我们到底是有数据就往外发,还是我们攒一波数据之后往外发?这个就我刚才说的,你发包频率应该是有讲究的,看怎么去发比较合适。

  另外,可不可以换一种思路,使用类似TCP慢起动这样的算法,我最开始为了保证首屏时间,我以最快的发包速率往上发,等我发到一定的程度的时候,换成慢包率发送,把时间拉长一点,拉倒一个可以接受的范围,然后逐渐的去调整这个东西,当然这可能是比较传统的,朴素的方式。最终的效果呢大家还得自己去根据这个特性自己想,这也是一个开放性的问题。

评论列表(0)
暂无评论