公开/公告号CN106604055A
专利类型发明专利
公开/公告日2017-04-26
原文格式PDF
申请/专利权人 广州四三九九信息科技有限公司;
申请/专利号CN201710011238.8
发明设计人 卫铁旦;
申请日2017-01-06
分类号H04N21/2187(20110101);H04N21/262(20110101);H04N21/2662(20110101);H04N21/643(20110101);
代理机构11337 北京市盛峰律师事务所;
代理人梁艳
地址 510630 广东省广州市天河区建中路8号四楼B2房
入库时间 2023-06-19 02:03:52
法律状态公告日
法律状态信息
法律状态
2019-08-09
授权
授权
2017-05-24
实质审查的生效 IPC(主分类):H04N21/2187 申请日:20170106
实质审查的生效
2017-04-26
公开
公开
技术领域
本发明涉及移动应用技术领域,尤其涉及一种基于复杂弱移动网络环境的视频平滑发送直播上行方法。
背景技术
直播已经是目前网络生活中很常见的娱乐项目之一。目前主流的移动直播基本都是通过rtmp协议将移动端的音视频压缩数据直接发送到cdn源机上来实现的。但是,我们知道,用户的移动网络相当的复杂,移动网络的特点是信号强度不稳定,随地理位置变化而变化,丢包率变化复杂,而经常引起网络抖动厉害,因为直播主流采用的是rtmp协议上传,rtmp协议属于tcp协议的范畴,最终会产生延迟累积的弊端,最终造成“弱网络”的体现。
发明内容
本发明的目的在于提供一种基于复杂弱移动网络环境的视频平滑发送直播上行方法,从而解决现有技术中存在的前述问题。
为了实现上述目的,本发明采用的技术方案如下:
一种基于复杂弱移动网络环境的视频平滑发送直播上行方法,包括如下步骤:
S1,获取视频码流变量bitrate;
S2,根据所述视频码流变量bitrate,计算每秒发送的字节大小sendSizePerSec;
S3,根据S2计算得到的sendSizePerSec,计算视频包发包间隔timeGap和发包间隔内一次发包大小sendSizeOneTime;
S4,设置发包间隔内初始化实际发包大小realSendSize=0;
S5,设置视频缓存发送队列大小videoWaitSenderQueue,每次有新包进入队列时,周期遍历缓存发送队列,设置遍历循环当次的视频包大小rawDataSize;
S6,判断所述缓存发送队列视频数据总大小allVideoDataSizeInQueue,当所述缓存发送队列视频数据总大小小于设定阈值的发送数据量时,即:allVideoDataSizeInQueue<=(sendSizePerSec_>>2)时,执行S7,当所述缓存发送队列视频数据总大小大于所述设定阈值的发送数据量时,即:allVideoDataSizeInQueue_>(sendSizePerSec_>>2)时,执行S8-S11;
S7,判断realSendSize+rawDataSize>=sendSizeOneTime_,如果是,则停止发送,退出遍历,否则,发送视频数据到视频服务器;
S8,根据allVideoDataSizeInQueue和sendSizeOneTime,计算所述缓存发送队列中,剩余包大小leftSize;
S9,根据leftSize和timeGap,计算所述缓存发送队列中剩余的还需要发送的包大小moreSendSize;
S10,根据sendSizeOneTime、moreSendSize、realSendSize和rawDataSize,计算实际少发一个包造成的预估发送大小与实际发送大小的差值gap1,以及,实际多发送一个包造成的实际发送大小与预估发送大小的差值gap2;
S11,判断是否满足gap1>0,且gap2>0,如果是,判断是否满足gap1<=gap2,如果是,则停止发送,退出遍历,否则,发送视频数据到视频服务器。
优选地,S2中,采用如下公式计算每秒发送的字节大小sendSizePerSec:sendSizePerSec_=bitrate*1024/8。
优选地,S3中,采用如下公式计算视频包发包间隔timeGap:
timeGap=Epoll::msecEpoch_-lastCheckSendVideoMSec_;
式中,
Epoll::msecEpoch_:表示本次获取的本地时钟值。
lastCheckSendVideoMSec_:表示上一次程序循环记录的检查获取的本地时钟值;
采用如下公式计算发包间隔内一次发包大小sendSizeOneTime:
sendSizeOneTime_=timeGap*sendSizePerSec_/1000。
优选地,S5中,所述视频缓存发送队列大小videoWaitSenderQueue设置为小于等于1000,所述遍历循环当次的视频包大小rawDataSize设置为1300字节,S6中,所述设定阈值为250ms。
优选地,S8中,所述剩余包大小leftSize,按照如下公式进行计算:
leftSize=allVideoDataSizeInQueue_-sendSizeOneTime_。
优选地,S9中,所述剩余的还需要发送的包大小moreSendSize,按照如下公式进行计算:moreSendSize=leftSize*timeGap/5000。
优选地,S10中,所述gap1和gap2分别采用如下公式进行计算:
gap1=(sendSizeOneTime_+moreSendSize)-realSendSize;
gap2=(realSendSize+rawDataSize)-(sendSizeOneTime_+moreSendSize)。
本发明的有益效果是:本发明实施例提供的基于复杂弱移动网络环境的视频平滑发送直播上行方法,通过对音视频帧的重新拆包,使用udp协议,并合理设计音视频包大小,开发重传算法和平滑发送算法,可以实现在复杂多变的弱网络环境下,达到移动直播音视频上传码率稳定、低延迟和符合应用场景较高可靠性的目的。
附图说明
图1是本发明实施例提供的方法流程示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施方式仅仅用以解释本发明,并不用于限定本发明。
如图1所示,本发明实施例提供了一种基于复杂弱移动网络环境的视频平滑发送直播上行方法,包括如下步骤:
S1,获取视频码流变量bitrate;
S2,根据所述视频码流变量bitrate,计算每秒发送的字节大小sendSizePerSec;
S3,根据S2计算得到的sendSizePerSec,计算视频包发包间隔timeGap和发包间隔内一次发包大小sendSizeOneTime;
S4,设置发包间隔内初始化实际发包大小realSendSize=0;
S5,设置视频缓存发送队列大小videoWaitSenderQueue,每次有新包进入队列时,周期遍历缓存发送队列,设置遍历循环当次的视频包大小rawDataSize;
S6,判断所述缓存发送队列视频数据总大小allVideoDataSizeInQueue,当所述缓存发送队列视频数据总大小小于设定阈值的发送数据量时,即:allVideoDataSizeInQueue<=(sendSizePerSec_>>2)时,执行S7,当所述缓存发送队列视频数据总大小大于所述设定阈值的发送数据量时,即:allVideoDataSizeInQueue_>(sendSizePerSec_>>2)时,执行S8-S11;
S7,判断realSendSize+rawDataSize>=sendSizeOneTime_,如果是,则停止发送,退出遍历,否则,发送视频数据到视频服务器;
S8,根据allVideoDataSizeInQueue和sendSizeOneTime,计算所述缓存发送队列中,剩余包大小leftSize;
S9,根据leftSize和timeGap,计算所述缓存发送队列中剩余的还需要发送的包大小moreSendSize;
S10,根据sendSizeOneTime、moreSendSize、realSendSize和rawDataSize,计算实际少发一个包造成的预估发送大小与实际发送大小的差值gap1,以及,实际多发送一个包造成的实际发送大小与预估发送大小的差值gap2;
S11,判断是否满足gap1>0,且gap2>0,如果是,判断是否满足gap1<=gap2,如果是,则停止发送,退出遍历,否则,发送视频数据到视频服务器。
其中,S2中,采用如下公式计算每秒发送的字节大小sendSizePerSec:sendSizePerSec_=bitrate*1024/8。
S3中,采用如下公式计算视频包发包间隔timeGap:
timeGap=Epoll::msecEpoch_-lastCheckSendVideoMSec_;
式中,
Epoll::msecEpoch_:表示本次获取的本地时钟值。
lastCheckSendVideoMSec_:表示上一次程序循环记录的检查获取的本地时钟值;
采用如下公式计算发包间隔内一次发包大小sendSizeOneTime:
sendSizeOneTime_=timeGap*sendSizePerSec_/1000。
S5中,所述视频缓存发送队列大小videoWaitSenderQueue设置为小于等于1000,所述遍历循环当次的视频包大小rawDataSize设置为1300字节,S6中,所述设定阈值为250ms。
S8中,所述剩余包大小leftSize,按照如下公式进行计算:
leftSize=allVideoDataSizeInQueue_-sendSizeOneTime_。
S9中,所述剩余的还需要发送的包大小moreSendSize,按照如下公式进行计算:moreSendSize=leftSize*timeGap/5000。
S10中,所述gap1和gap2分别采用如下公式进行计算:
gap1=(sendSizeOneTime_+moreSendSize)-realSendSize;
gap2=(realSendSize+rawDataSize)-(sendSizeOneTime_+moreSendSize)。
通过采用本发明公开的上述技术方案,得到了如下有益的效果:本发明实施例提供的基于复杂弱移动网络环境的视频平滑发送直播上行方法,通过对音视频帧的重新拆包,使用udp协议,并合理设计音视频包大小,开发重传算法和平滑发送算法,可以实现在复杂多变的弱网络环境下,达到移动直播音视频上传码率稳定、低延迟和符合应用场景较高可靠性的目的。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
本领域人员应该理解的是,上述实施例提供的方法步骤的时序可根据实际情况进行适应性调整,也可根据实际情况并发进行。
上述实施例涉及的方法中的全部或部分步骤可以通过程序来指令相关的硬件来完成,所述的程序可以存储于计算机设备可读取的存储介质中,用于执行上述各实施例方法所述的全部或部分步骤。所述计算机设备,例如:个人计算机、服务器、网络设备、智能移动终端、智能家居设备、穿戴式智能设备、车载智能设备等;所述的存储介质,例如:RAM、ROM、磁碟、磁带、光盘、闪存、U盘、移动硬盘、存储卡、记忆棒、网络服务器存储、网络云存储等。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视本发明的保护范围。
机译: 一种用于发送基于面积的360度视频的方法,一种用于接收基于面积的360度视频的方法,一种用于发送基于区域的360度视频的设备,一种用于基于区域接收360度视频的设备
机译: 胁迫安全电话/手表/ MDT设备应用程序。启用Duress后,它将直播/录制视频,使用GPS当前位置,并将所有信息发送到A1认证的中心,该中心可以向有需要的人的位置请求警察。 Duress还可以将实时视频和位置信息发送到警察设备或手机。
机译: 用于从移动电话进行直播电视广播的系统,使用视频呼叫通过移动电话分离并传输音频信号和视频信号,并将音频和视频包转换为Internet协议流