UDP直播中VBR视频快速平滑发送方法与装置
技术领域
本发明属于视频直播技术领域，更具体地，涉及一种UDP直播中VBR视频快速平滑发送方法、装置及电子设备。
背景技术
CDN(Content Delivery Network，内容分发网络)是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN本身并不对视频内容进行修改。原有的CDN视频提供直播服务时，组播UDP(User DatagramProtocol，用户数据报协议)发送是最常见的形式之一，广泛适应机顶盒、PC等各类型终端。
GOP(Group of Picture，图像组)关键帧的周期，是两个关键帧之间的距离，同时也是一个帧组的最大帧数。一般而言，每一秒视频至少需要使用1个关键帧。增加关键帧个数可改善质量，但是同时会增加带宽和网络负载。
CBR(Constant Bit Rate，固定比特率)视频，是以恒定比特率方式进行编码生成的视频。当有运动发生时，由于码率恒定，只能通过增大量化参数来减少码字大小，此时图像质量变差；当场景静止时，量化参数还原，图像质量又变好，因此图像质量不稳定。这种算法优先考虑码率(带宽)，此类视频也是原CDN分发视频内容中绝大部分视频的类型，同时在CDN组播直播传输中均采用此类视频。
VBR(Variable Bit Rate，可变比特率)视频，也称动态比特率视频，其码率可以随着图像的复杂程度的不同而变化，因此其编码效率比较高，运动发生时马赛克很少。码率控制算法根据图像内容确定使用的比特率，图像内容比较简单则分配较少的码率，图像内容复杂则分配较多的码字，这样既保证了质量，又兼顾带宽限制。这种算法优先考虑图像质量。
随着视频业务需求的不断增长，视频业务对画质的不断追求，VBR视频尤其是高码率VBR视频也出现在CDN中。当CDN组播直播发送遇上VBR视频时，由于视频码率不断变化，不论是使用原CBR方式按平均码率发送，还是按最高码率发送，亦或者按照帧率发送帧大小数据，都无法满足终端的实际需求。发送过程吞吐速率要么固定无法适应VBR变化，要么变化过于剧烈，终端会因缓冲的下溢出或上溢出导致播放卡顿，花屏等不良观感。
发明内容
针对现有技术中存在的缺陷，本发明的目的在于提供一种UDP直播中VBR视频快速平滑发送的方法，在终端网络缓冲大小可容纳待传输VBR视频最大帧大小下，VBR视频可以不做任何变更，也能够利用UDP平滑发送到终端。
为实现上述目的，按照本发明的一个方面，提供了一种UDP直播中VBR视频快速平滑发送方法，包括：
S1、帧数据处理层平滑步骤：负责视频数据的高IO输入、缓冲并分段解析、求解媒体分段的发送路径，并根据发送路径进行一级平滑；
S2、帧数据发送层平滑步骤：接收帧数据处理层一级平滑后的视频数据和发送路径进行二级平滑发送；
其中，所述帧数据处理层平滑步骤和帧数据发送层平滑步骤在每段数据处理中是异步的，仅在一个媒体分段处理起始时，同步上一个媒体分段实际发送数据量。
本发明的一个实施例中，所述帧数据处理层平滑步骤包括：
S01、高IO输入原始媒体视频数据；
S02、原始媒体视频数据缓冲，将原始媒体视频数据进行分段解析，确认媒体分段内每个视频帧的大小及对应的时刻；
S03、依据媒体分段内每个视频帧的大小及对应的时刻，以及数据发送层上一个媒体分段实际发送数据量，求解媒体分段的发送路径，所述发送路径包含发送速率、时间起点、时间终点；
S04、依照发送路径中的时间起点、时间终点结合媒体分段，确认待推送数据量，一次性推送这些数据到数据发送层，然后等待，其中等待时间为推送数据量除以发送速率。
本发明的一个实施例中，所述步骤S03中依据媒体分段内每个视频帧的大小及对应的时刻，以及数据发送层上一个媒体分段实际发送数据量，求解媒体分段的发送路径，包括：
S041、确认推送数据量的初始起点O和初始终点P；
S042、计算当前起点到当前终点的斜率tg；
S043、根据S042得到的斜率tg与传输上下限比较查找是否有交点；若查找到交点位于时刻i，则进入步骤S044；若未查找到交点，则进入步骤S045；
S044、保留当前起点，将当前终点变更为S(i)，进入S042，其中所述S(i)表示时刻i处的传输上限；
S045、确认下一媒体分段的发送路径的起点和终点。
本发明的一个实施例中，所述步骤S043中查找是否有交点，具体为：
判断依据是若tg*(T(终点)-T(起点))+起点对应数据量>＝U(i)且S(i)>＝tg*(T(终点)-T(起点))+起点对应数据量则不相交，反之则相交，其中记终端侧网络缓冲大小为b，待输出视频帧大小为fi，每帧的时长记作ti，媒体分段内总帧数记为n，则
本发明的一个实施例中，所述S045中确认下一媒体分段的发送路径的起点和终点，具体为：
若当前终点非初始终点P，则输出当前发送路径，并将当前终点变更为当前起点，同时当前终点设为P，进入S042；
若当前终点为初始终点P，则输出当前发送路径，然后进入S041；
其中所述当前发送路径包括当前斜率tg，时间起点，时间终点。
本发明的一个实施例中，所述帧数据发送层平滑步骤包括以下步骤：
S11、从数据缓冲中弹出数据；
S12、判断数据缓冲的上溢门限，当超过门限，则设置发送长度为1个满包，然后直接跳到S1X立即触发一次发送，同时对外告警；
S13、根据数据段的位置，确认发送速率，设定预约时刻；
S14、设定此次发送数据包大小；
S15、判断预约时刻与target_tick的关系，当预约时刻小于等于target_tick时，进入步骤S16，否则进入步骤S17；其中，target_tick是指下一次执行网络发包的时刻；
S16、预估发送数据量，反馈实际发送数据量给帧数据处理层；
S17、比较当前时刻和target_tick，若当前时刻更早，进入步骤S18；若当前时刻等于target_tick进入步骤S1X，若target_tick更早，进入步骤S19；
S18、等待，其中等待时间长度为target_tick-当前时刻；
S19、更新时间起点，调整预约时刻；
S1X、发送设定发送大小的数据，偏移缓冲读指针，计算下一次target_tick的时刻。
本发明的一个实施例中，所述步骤S13中根据数据段的位置，确认发送速率，设定预约时刻，具体为：
按帧数据处理层发来的数据段起止位置和发送速率，设定本轮发送速率为对应的发送速率，当数据处于一个媒体数据段的起始位置时，设定本数据段预约时刻＝预约时刻起点+数据段总大小/发送速率，target_tick为当前时刻，若预约时刻起点未设置时，默认为当前时刻。
本发明的一个实施例中，所述步骤S16中预估发送数据量，反馈实际发送数据量给帧数据处理层，具体为：
若当前媒体数据段是媒体分段的最后一个数据段时，获取当前数据段已发送的数据量，当预约时刻与target_tick相等时，已发送数据量加上此次发送数据包大小，否则保持不变，然后将已发送数据量作为实际发送数据量反馈给帧数据处理层。
本发明的一个实施例中，所述步骤S19中更新时间起点，调整预约时刻，具体为：
若预约时刻是本轮确定的，则变更预约时刻＝target_tick+数据段总大小/发送速率，同时将计算下一次target_tick的时间起点变更为当前时刻。
按照本发明的另一方面，还提供了一种UDP直播中VBR视频快速平滑发送装置，包括帧数据处理层平滑模块和帧数据发送层平滑模块，其中：
所述帧数据处理层平滑模块，用于负责视频数据的高IO输入、缓冲并分段解析、求解媒体分段的发送路径，并根据发送路径进行一级平滑；
所述帧数据发送层平滑模块，用于接收帧数据处理层一级平滑后的视频数据和发送路径进行二级平滑发送；
其中，所述帧数据处理层平滑步骤和帧数据发送层平滑步骤在每段数据处理中是异步的，仅在一个媒体分段处理起始时，同步上一个媒体分段实际发送数据量。
总体而言，通过本发明所构思的以上技术方案与现有技术相比，具有如下有益效果：
首先本发明方法分两级平滑处理的方式，使当前大多数外部媒体处理模块都可以较容易的兼容使用，通过一级平滑方式既约束系统的性能，也使媒体处理模块不需要过多关注平滑发送需求；
其次，本发明方法不依赖对视频的整体分析，可以随视频的播放分段分析，且计算复杂度较低，能够适应直播场景的需求，实用性高；
再次，本发明方法在数据发送层的平滑还有效降低了大码率VBR视频中单帧数据发送中的峰值，降低网络抖动，改善传输效率；
最后，本发明方法对原始视频的处理方式摆脱了现有已知方案对编码器的依赖，可以适用于CDN等纯媒体转发设备使用，可有效的降低原工程整体解决方案中的硬件成本。
附图说明
图1为本发明实施例中UDP直播中VBR视频快速平滑发送方法的流程示意图；
图2为本发明实施例中帧数据处理层步骤的流程图；
图3为本发明实施例中求解媒体分段的发送路径的流程图；
图4为本发明实施例中数据发送层平滑步骤的流程图；
图5为本发明实施例中一种数据发送层的工作过程示意图；
图6为本发明中数据发送层平滑的效果示意图；
图7为本发明实施例中UDP直播中VBR视频快速平滑发送装置的结构示意图；
图8为本发明实施例中一种电子设备的结构示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
实施例1
本发明提供了一种UDP直播中VBR视频快速平滑发送的方法，在一定前提下，VBR视频可以不做任何变更，也能够利用UDP平滑发送到终端。这里的一定前提是指：终端网络缓冲大小可容纳待传输VBR视频最大帧大小。
如图1所示，本发明实施例提供了一种UDP直播中VBR视频快速平滑发送的方法，包括：
S1、帧数据处理层平滑步骤：负责视频数据的高IO输入、缓冲并分段解析、求解媒体分段的发送路径，并根据发送路径进行一级平滑；
S2、帧数据发送层平滑步骤：接收帧数据处理层一级平滑后的视频数据和发送路径进行二级平滑发送；
其中，所述帧数据处理层步骤和帧数据发送层平滑步骤两者在每段数据处理中是异步的，仅在一个媒体分段处理起始时，同步上一个媒体分段实际发送数据量。
实施例2
如图2所示，帧数据处理层步骤，包括以下子步骤：
S01、高IO输入原始媒体视频数据；
该媒体可以是本地文件，也可以是摄像机或专线输入的媒体。
S02、原始媒体视频数据缓冲，将原始媒体视频数据进行分段解析，确认媒体分段内每个视频帧的大小及对应的时刻；
将媒体数据解复用，分离出视频。确认视频GOP的起始位置和结束位置，按连续m个GOP为一个媒体分段(这里m是预设的值，通常m个GOP的总时长不超过10秒，m最小为1)。
确认媒体分段内每个视频帧的大小及对应的时刻。
若帧数据处理层没有媒体处理，则使用原始媒体中每个视频帧的大小及对应的时刻；
若帧数据处理层包含媒体处理，且媒体处理输出的封装大小与分析的封装大小有差别，此时每个视频桢的大小及对应的时刻则按媒体处理的自有算法换算得出。例如媒体处理是将原始PES流封装为ts流，则每184字节需添加4字节ts头部，则按每184字节变为188字节换算。再比如媒体处理是视频降码率，要求新视频图像大小压缩为原有视频的70％，那么每帧的大小需按原有视频每帧大小的70％换算。
S03、依据S02解析得到的媒体分段内每个视频帧的大小及对应的时刻，以及数据发送层上一个媒体分段实际发送数据量，求解媒体分段的发送路径。求解出的发送路径以下称为PATH信息，包含发送速率(S042中的斜率)、时间起点、时间终点。
计算的本质是在单调增的阶梯形区域[U(i),S(i)]中快速求解出一条斜率变化较少的有效路径。其中为方便描述计算步骤，记终端侧网络缓冲大小为b，待输出视频帧大小为fi，每帧的时长记作ti，S03中媒体分段内总帧数记为n，则
S04、一级平滑。依照S04输出的PATH信息的时间起点、时间终点结合媒体分段，确认待推送数据量，一次性推送这些数据(媒体分段及所有对应的PATH信息)到数据发送层，然后等待。
等待时间＝推送数据量/PATH信息中发送速率。通过此步骤操作从而使高IO输入的速率可以有保障的初步降低，避免数据发送层缓冲区因推送过快导致上溢出。
实施例3
如图3所示，本发明实施例中步骤S04具体包括以下子步骤：
S041、确认推送数据量的初始起点O和初始终点P。
其中初始起点O在从未向数据发送层推送媒体分段的数据内容时，最初为0点，当向数据发送层推送过媒体分段后，则初始起点O的准确位置为上一个媒体分段起始位置加上数据发送层中上一个媒体分段实际发送数据量。
S042、计算当前起点到当前终点的斜率tg。tg是当前终点与当前起点数据量差值与时间长度的比值，即为当前起点到当前终点的发送速率。计算出斜率tg后进入S043。
初始时，当前终点为P，若后续进入S044则会出现当前终点变更。
S043、根据S042得到的斜率tg与传输上下限比较查找是否有交点。判断依据是若“tg*(T(终点)-T(起点))+起点对应数据量>＝U(i)且S(i)>＝tg*(T(终点)-T(起点))+起点对应数据量”则不相交，反之则相交。若查找到交点，则进入步骤S044；若未查找到交点位于时刻i，则进入步骤S045。
S044、保留当前起点，将当前终点变更为S(i)，进入S042，其中所述S(i)表示时刻i处的传输上限。
S045、确认下一媒体分段的发送路径的起点和终点。
若当前终点非初始终点P，则输出当前PATH信息(当前tg，时间起点，时间终点)，然后将当前终点变更为当前起点，同时当前终点设为P，进入S042。若当前终点为初始终点P，则输出当前PATH信息(当前tg，时间起点，时间终点)，然后进入S041。
需要说明的是，本发明实施例中的媒体分段是按GOP或m个GOP切割的，如此切割最符合视频编码和解码的实际需要，按任意数据位置切割或按帧边界切割，都可能打破视频图像序列，不利于数据提供给其他系统处理时的完整性和时效性。
实施例4
如图4所示，数据发送层二级平滑步骤，包括以下子步骤：
S11、从数据缓冲中弹出数据。
S12、判断数据缓冲的上溢门限。
上溢门限是数据缓冲的上溢保护，例如通常可以设置为数据缓冲大小的90％，当超过门限，则设置发送长度为1个满包(满包的大小与MTU以及视频封装规格有关，由小于MTU的最大封装填充大小确认，例如纯UDP TS数据满包数据大小为188*7＝1316字节)，然后直接跳到S1X立即触发一次发送，同时对外告警。
S13、根据数据段的位置，确认发送速率，设定预约时刻。
数据段是在一个媒体分段内计算中遇到了交点，计算出了PATH信息，该PATH信息对应的数据范围。
按帧数据处理层发来的数据段起止位置和发送速率，设定本轮发送速率为对应的发送速率(发送速率是PATH中的速率，因为一个媒体分段中可能出现一个或多个PATH，也就对应多个数据段，数据段依次按轮次发送)。当数据处于一个媒体数据段的起始位置时，设定本数据段预约时刻＝预约时刻起点+数据段总大小/发送速率，target_tick为当前时刻。预约时刻起点未设置时，默认为当前时刻。
S14、设定此次发送数据包大小。
若S11弹出数据量大于满包大小，设定发送大小为满包大小，否则设为S11中弹出数据大小。
S15、判断预约时刻与target_tick的关系。
target_tick是指下一次执行网络发包的时刻，比较设定的预约时刻与target_tick的关系，当预约时刻小于等于target_tick时，进入S16步骤，否则进入S17步骤。
预约时间的目的是在准确时间矫正数据发送层实际发送数据量，若出现些微误差，需在下一个媒体分段中纠偏。
S16、预估发送数据量，反馈实际发送数据量给帧数据处理层。
具体是若当前媒体数据段是媒体分段的最后一个数据段时，获取当前数据段已发送的数据量，当预约时刻与target_tick相等时，已发送数据量加上此次发送数据包大小，否则保持不变。然后将已发送数据量作为实际发送数据量反馈给帧数据处理层。
若当前媒体数据段不是最后一个数据段，则将当前预约时刻作为下次设置预约时刻的起点。
S17、判断当前时刻与target_tick的关系。比较当前时刻和target_tick，若当前时刻更早，进入步骤S18；若当前时刻等于target_tick进入步骤S1X，若target_tick更早，进入步骤S19。
S18、等待，等待时间长度为target_tick-当前时刻。
S19、更新时间起点，调整预约时刻。
若预约时刻是本轮确定的，则变更预约时刻＝target_tick+数据段总大小/发送速率，同时将计算下一次target_tick的时间起点变更为当前时刻。
S1X、发送设定发送大小的数据，偏移缓冲读取位置，计算下一次target_tick的时刻。
立即按设定发送大小发送数据，发送成功后偏移数据缓冲中的读指针，当读指针到本数据段末尾时，跳转到下一数据段开始位置。计算下一次target_tick的时刻，target_tick＝时间起点+此次发送数据包大小/发送速率。若时间起点未修改，则默认是本次的target_tick。
实施例5
如图5所示，下面以数据发送层处理到媒体分段末尾时可能出现的情形，说明本方案数据发送层的工作过程。
(1)数据发送层已发送完上个满包，且记录了上次发送时刻。根据步骤S1X，计算得到了target tick 1。
(2)在target tick 1之前数据发送层弹出数据，且大于一个满包。那么需要根据当前时刻与target tick 1的差距计算等待时长，并进入等待。
(3)数据发送层退出等待，在target tick 1发送一个满包。然后根据步骤S1X计算得到target tick2。
(4)在target tick 2时刻数据发送层弹出数据，此时正好满足发送条件，但数据不足一个满包，立即发送弹出的数据，然后根据S1X计算得到target tick3。
(5)时间超过了target tick3，数据发送层才有数据弹出，数据大于一个满包，此时需进行发送滞后处理。具体是立即发送数据，然后根据步骤S1X和当前时刻计算得到target tick4。发送之后处理整体会延后后续的target tick，但不会影响预约时刻。
(6)target tick 4时刻，数据发送层继续发送一个满包，同时计算得到targettick 5
(7)在target tick 5之前时间来到预约时刻，则统计上报媒体分段实际发送数据量给帧数据处理层，用于计算下一个媒体分段的发送路径。
(8)因为预约时刻在target tick 5之前已经统计反馈了实际发送数据量给帧数据处理层，在target tick 5时刻将作为下一个媒体分段数据发送的初始target tick。
实施例6
下面以HLS直播转TS over RTP通过UDP组播发送为例，说明本方案的工作过程。
首先直播源不断生成最近直播点的TS分片文件，TS分片标准时长为10秒。此过程为标准HLS直播，不涉及本技术方案。
具体执行过程如下：
(1)帧数据处理层从直播源，通过HTTP以高IO拉取最近的直播点TS分片文件。实验中输入速率约1Gbps，分片输入耗时40毫秒。
(2)收取的数据缓冲到内存。
(3)分析缓冲视频数据。分析内容包括：得到10s内完整GOP长度的最大数据，数据时长9秒620毫秒，数据总大小约5.09MB，帧率30帧，总帧数288以及每帧数据的大小(帧大小统计中复用后两帧间的音频大小统一归入前一视频桢)，每帧数据的时间起止时刻。
(4)上面解析的结果求解媒体分段的发送路径。假设此分段帧大小实际分布如图6，从起始点O，计算到目标点P的斜率记作tg(O,P)，按GOP内时间顺序判断与U(i)或S(i)是否相交。若出现与U的交点，例如图中U1，则找到U1对应的S1，得到路径PATH(O,S1)＝<tg(O,S1),T(1)-T(0)>。更新起点为S1；若出现与S的交点，例如图中S3，为更新起点为S1后tg(S1,P)的交点，得到路径PATH(S1,S2)＝<tg(S1,S3),T(3)-T(1)>。每当获得一段路径PATH，就提供给一级平滑。实例中设定计算中网络缓冲大小为200KB，此值为估算值，可根据实际对接终端和网络情况调整，一般不超过终端网络缓冲上限的70％。
(5)一级平滑结合上面得到的PATH，从媒体处理输出获取数据。按时间段对应的待推送数据量除以速率对应的时间为节奏，将数据段和匹配的速率发送给数据发送层。
(6)数据发送层接收到一个完整的数据段后，将数据缓冲起来。实验中数据发送层数据缓冲使用的是内存池的链表结构，数据段和速率配对存储。
(7)数据发送层二级平滑发送部分，为循环读取发送。其不断尝试从数据发送层数据缓冲中弹出数据，若无数据则弹出数据量为0。同时判断数据发送层数据缓冲情况，若已缓冲数据量超过总量的90％，则直接立即发送1个满包封装的UDP包。
(8)数据发送层二级平滑若没有触发超限保护，则按周期性平滑发送。具体方法是先确定数据段发送反馈的时刻，以及数据段的发送速率。然后规划本轮发包的数据量，最大为1个满包封装的UDP包。若数据不足满包，则发送全部本轮弹出的数据。
(9)确定完发送数据量大小和速率，进入二级平滑的发送阶段。其重点在于判断当前时刻、预约时刻、target_tick(平滑发送包的时刻)之间的关系。首先是预约时刻和target_tick的关系，预约时刻早于target_tick或两者重合但减去本轮待发送数据后仍有剩余，表明数据发送有延迟，需同步给帧数据处理层，校准下一个完整数据分段的发送速率。其次是当前时刻和target_tick的关系，当前时刻早于target_tick时，需要等待到target_tick时刻才能发送；当前时刻晚于target_tick时，表明帧数据处理层一级平滑出现了抖动，数据处理层二级平滑需要做异常处理，具体是重新设置target_tick的时间起点，如有必要也调整预约时刻，确保预约时刻的连贯性，这样在本轮末尾数据反馈时间发送量时，可以包含此误差，后续数据段能校准修正。
(10)在target_tick数据发送层，将待发送的数据发送到网络上，同时依照本轮速率和target_tick的时间起点计算下一次循环中使用的target_tick的时刻。然后返回第7步尝试弹出数据，继续循环。
根据实验验证，直播约50分钟片长视频内容，存储原始片源发现码率波动范围732Kbps～11Mbps平均4.74MBps，最大帧数据大小114KB，实际传输中码率分布范围1.37Mbps～8.2Mbps，平滑网络传输峰值约25％(具体地，计算峰值减小幅度(11-8.2)/11＝25％)，整体直播过程终端播放稳定，效果达到设计预期。
实施例7
如图7所示，本发明提供了一种UDP直播中VBR视频快速平滑发送装置，包括帧数据处理层平滑模块和帧数据发送层平滑模块，其中：
所述帧数据处理层平滑模块，用于负责视频数据的高IO输入、缓冲并分段解析、求解媒体分段的发送路径，并根据发送路径进行一级平滑；
所述帧数据发送层平滑模块，用于接收帧数据处理层一级平滑后的视频数据和发送路径进行二级平滑发送；
其中，所述帧数据处理层平滑步骤和帧数据发送层平滑步骤在每段数据处理中是异步的，仅在一个媒体分段处理起始时，同步上一个媒体分段实际发送数据量。
实施例8
本发明实施例提供了一种电子设备，包括：
至少一个处理器；以及，
与所述至少一个处理器通信连接的存储器；其中，
所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述UDP直播中VBR视频快速平滑发送方法。
进一步地，本发明还提供了一种计算机可读存储介质，其上存储有计算机程序(指令)，该计算机程序(指令)被处理器执行时实现上述UDP直播中VBR视频快速平滑发送方法的步骤。
本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。
