CN105072508A - 一种无线网络多媒体播放补包系统及方法 - Google Patents
一种无线网络多媒体播放补包系统及方法 Download PDFInfo
- Publication number
- CN105072508A CN105072508A CN201510491648.8A CN201510491648A CN105072508A CN 105072508 A CN105072508 A CN 105072508A CN 201510491648 A CN201510491648 A CN 201510491648A CN 105072508 A CN105072508 A CN 105072508A
- Authority
- CN
- China
- Prior art keywords
- tcp
- bag
- packet
- module
- udp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
- H04N21/64746—Control signals issued by the network directed to the server or the client
- H04N21/64761—Control signals issued by the network directed to the server or the client directed to the server
- H04N21/64776—Control signals issued by the network directed to the server or the client directed to the server for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
- H04N21/41422—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance located in transportation means, e.g. personal vehicle
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/64—Addressing
- H04N21/6405—Multicasting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明是一种无线网络多媒体播放补包系统及方法,该系统包括地面数据服务器、udp组播接收模块、tcp补包模块、缓存模块、本地数据模块和直播终端,所述地面数据服务器通过udp协议向udp组播接收模块无线传输多媒体数据包构成无线传输udp组播数据包主通道,所述udp组播接收模块分别连接缓存模块和tcp补包模块,udp组播接收模块将多媒体数据包存入缓存模块中并检测是否有丢包,有丢包时向tcp补包模块发送丢包信息并建立tcp补包通路,tcp补包模块通过tcp协议无线连接地面数据服务器构成请求补包子通路,地面数据服务器通过tcp协议无线连接udp组播接收模块构成补包子通路,实现在网络状况不佳而产生丢包后能够及时补包,避免了因网络丢包产生视频马赛克的问题。
Description
技术领域
本发明涉及无线网络音视频播放技术领域,具体涉及一种无线网络多媒体播放补包系统及方法。
背景技术
目前地铁列车上的网络直播视频的现状大致如下:
第一,车厢中没有LCD显示屏,没有视频播放功能,只有简单的语音报站;
第二,车厢中有LCD视频播放,但是没有车地无线网络,只能播放车厢服务器中预先录制好的录播视频;
第三,有车地无线网络直播视频,但是经常会出现马赛克。
网络视频直播效果的首要因素是车地无线网络,而其中有一种LTE无线网络,LTE无线网络的LTE(LongTermEvolution,长期演进)技术是3G的演进,始于2004年3GPP的多伦多会议。LTE是3G与4G技术之间的一个过渡,3.9G的全球标准,改进并增强了3G的空中接入技术。与3G相比,LTE更具多方面的技术优势,包括高数据速率、分组传送、延迟降低、广域覆盖和向下兼容等。LTE技术在20MHz频谱带宽能够提供下行100Mbps、上行50Mbps的峰值速率。LTE网络的发射频率和覆盖范围参考数据,本发明在地铁沿线上每隔300米会安装一个LTE无线网络终端,站点切换过程中断网时间<2秒。
由于地铁列车一直在高速运行并频繁切换站点,网络不稳定因素必然存在,几秒断网间隔会反复存在,断网的间隔内,产生数据丢失,体现在LCD屏上就是出现播放马赛克,声音断断续续或杂音,本发明提出一种直播软件的处理机制,在断网期间丢失的数据进行重新补充,再利用缓存机制消除播放马赛克和杂音的问题。
发明内容
本发明的目的在于克服现有技术存在的问题,提供一种无线网络多媒体播放补包系统及方法,实现在网络状况不佳而产生丢包后能够及时补包,避免了因网络丢包产生视频马赛克等问题。
为实现上述技术目的,达到上述技术效果,本发明通过以下技术方案实现:
一种无线网络多媒体播放补包系统,该系统包括地面数据服务器、udp组播接收模块、tcp补包模块、缓存模块、本地数据模块和直播终端,所述地面数据服务器通过udp协议向udp组播接收模块无线传输多媒体数据包构成无线传输udp组播数据包主通道,所述udp组播接收模块分别连接缓存模块和tcp补包模块,udp组播接收模块将多媒体数据包存入缓存模块中并检测是否有丢包,有丢包时向tcp补包模块发送丢包信息并建立tcp补包通路,所述tcp补包通路为:udp组播接收模块->tcp补包模块->地面数据服务器->udp组播接收模块,其中tcp补包模块通过tcp协议无线连接地面数据服务器构成请求补包子通路,地面数据服务器通过tcp协议无线连接udp组播接收模块构成补包子通路,udp组播接收模块将补包子通路传输过来的多媒体数据包存入缓存模块中对应的预留位置中,所述缓存模块连接直播终端,并且所述直播终端同时连接本地数据模块,用于在缓存模块和本地数据模块之间来回切换。
一种无线网络多媒体播放补包方法,该方法包括以下步骤:
步骤1.1)建立udp和tcp网络连接,设定最大缓存时间T,启动本地录播;
步骤1.2)udp组播接收模块通过车底无线网络接收地面数据服务器发出的多媒体数据包并存入缓存模块recv_buffer中;
步骤1.3)所述udp组播接收模块根据数据包号的连续性进行是否丢包判断,若是,则进入下一步骤,若否,则跳转至步骤1.5);
步骤1.4)启动tcp补包通路进行补包,补充的数据包存入缓存模块recv_buffer中;
步骤1.5)判断存入缓存模块recv_buffer中数据包的时间是否大于设定的最大缓存时间T,若是,则进入下一步骤,若否,则跳转至步骤1.7);
步骤1.6)停止本地录播,开始网络直播,并跳转至步骤1.2)缓存模块recv_buffer继续接收地面数据服务器发出的多媒体数据包;
步骤1.7)停止网络直播,播放本地录播,并跳转至步骤1.2)缓存模块recv_buffer继续尝试接收地面数据服务器发出的多媒体数据包。
进一步的,所述步骤1.1)中建立udp和tcp网络连接的同时创建并行的udp接收线程、tcp连接线程、请求补包线程、tcp接收补包线程、网络直播线程和本地录播线程。
进一步的,所述步骤1.2)中当udp组播接收模块接收到一个正确的数据包后,首先取出包头里面的包序号order,若此次收到的order=0或第一次启动udp组播接收标志first_recv_flag=1,则记录下udp组播接收模块收到的第一个数据包序号udp_recv_first_order=order,上次接收的包号last_order=order,再将此包存储于缓存模块的recv_buffer[0]的位置处。
进一步的,所述步骤1.3)中udp组播接收模块检测判断否丢包的方法为:
若本次接收的数据包号this_order–上次接收到的数据包号last_order>1,
则表明存在丢包,丢失的包数量Num为:
Num=this_order–last_order–1。
进一步的,所述多媒体数据包在缓存模块中的实际存储位置的计算方法为:
接收的数据包号偏移量recv_order_offset=当前接收的包号packet.order-udp组播接收模块第一次接收到的包号udp_recv_first_order,
实际存储位置save_array=(recv_order_offset)%MAX_PCK_NUM,其中,MAX_PCK_NUM为接收缓存能存储的最大数据包数量,
最终存储位置即为save_array,则:
接收缓存recv_buffer[save_array]=接收到的数据包中的实际数据packet.data,
存储成功后,将全局接收缓存数据包个数计数器值recv_buffer_count累加1,同时将未接收到多媒体数据包的存储位置空置,直至接收到补充的对应标号的多媒体数据包,将其存入对应的空置位。
进一步的,所述udp接收线程包括以下步骤:
步骤2.1)建立udp连接通路;
步骤2.2)循环接收多媒体数据包,如果udp连接通路接收错误,则重新执行步骤2.1),否则,判断是否有丢包,如有丢包,则将所有丢失包号存入丢包队列中,并启动请求补包线程;如果包号连续即无丢包,则经过校验后将多媒体数据包存入缓存模块recv_buffer中;
步骤2.3)如果接收缓存值>最大缓存时间T,则启动网络直播线程;否则返回继续执行步骤2.2),不断接收,直到接收缓存大于预设的最大缓存时间T。
进一步的,所述tcp连接线程包括以下步骤:
步骤3.1)首先判断tcp连接标志是否tcp_connect=1,如果tcp处于断开状态,则等待循环检测,直到tcp_connect=1时进行下一步;
步骤3.2)从补包队列中取出丢失的数据包号order,如果取出为空,则休眠等待sleep一下重新执行步骤3.1);否则将丢失的包号以tcp发送请求,如果发送成功,继续执行步骤3.1)循环取下一个;否则置位tcp_connect=0表明当前tcp连接异常,重新执行步骤3.1)。
进一步的,所述请求补包线程包括以下步骤:
步骤4.1)首先判断tcp连接标志是否tcp_connect=1,如果tcp处于断开状态,则等待循环检测,直到tcp_connect=1;
步骤4.2)从补包队列中取出丢失的数据包号order,如果取出为空,则休眠等待sleep一下重新执行步骤4.1);否则将丢失的包号以tcp发送请求,如果发送成功,继续执行步骤4.1)循环取下一个;否则置位tcp_connect=0表明当前tcp连接异常,重新执行步骤4.1)。
进一步的,所述tcp接收补包线程包括以下步骤:
步骤5.1)先判断tcp连接状况,若tcp_connect=1,则表明连接正常,开始循环接收地面数据服务器发送来的tcp补包;
步骤5.2)如果tcp接收错误,则置位tcp_connect=0表明tcp此时处于异常情况,需要重连,重新执行步骤5.1);否则经过协议校验,也将数据包存入与udp组播数据包主通道同样的接收缓存中;
步骤5.3)判断是否接收缓存值>最大缓存时间T,若是,则启动网络直播;否则重新执行步骤5.1)。
本发明的有益效果是:
1.本发明不需要特制的高带宽网络设备支持,在通用无线网络条件下,依然可以缓冲实现网络多媒体直播;
2.在网络状况不佳的情况下,只要断网时间小于设定的缓存时间,即能持续进行补包动作,依然能够保证音视频的顺畅播放,无马赛克或杂音现象出现。
3.系统结构比较简单,搭建成本低,可靠性高。
附图说明
图1为本发明的系统模块结构框图;
图2为本发明的无线网络多媒体播放补包方法主流程图;
图3为本发明的所有并行子线程结构框图;
图4为本发明的udp接收线程流程图;
图5为本发明的tcp连接线程流程图;
图6为本发明的请求补包线程流程图;
图7为本发明的tcp接收补包线程流程图;
图8为本发明的udp和tcp接收数据包存储结构示意图。
具体实施方式
下面将参考附图并结合实施例,来详细说明本发明。
参照图1所示,一种无线网络多媒体播放补包系统,该系统包括地面数据服务器、udp组播接收模块、tcp补包模块、缓存模块、本地数据模块和直播终端,所述地面数据服务器通过udp协议向udp组播接收模块无线传输多媒体数据包构成无线传输udp组播数据包主通道,所述udp组播接收模块分别连接缓存模块和tcp补包模块,udp组播接收模块将多媒体数据包存入缓存模块中并检测是否有丢包,有丢包时向tcp补包模块发送丢包信息并建立tcp补包通路,所述tcp补包通路为:udp组播接收模块->tcp补包模块->地面数据服务器->udp组播接收模块,其中tcp补包模块通过tcp协议无线连接地面数据服务器构成请求补包子通路,地面数据服务器通过tcp协议无线连接udp组播接收模块构成补包子通路,udp组播接收模块将补包子通路传输过来的多媒体数据包存入缓存模块中对应的预留位置中,所述缓存模块连接直播终端,并且所述直播终端同时连接本地数据模块,用于在缓存模块和本地数据模块之间来回切换。
参照图2所示,一种无线网络多媒体播放补包方法,该方法包括以下步骤:
步骤1.1)建立udp和tcp网络连接,设定最大缓存时间T,启动本地录播;
步骤1.2)udp组播接收模块通过车底无线网络接收地面数据服务器发出的多媒体数据包并存入缓存模块recv_buffer中;
步骤1.3)所述udp组播接收模块根据数据包号的连续性进行是否丢包判断,若是,则进入下一步骤,若否,则跳转至步骤1.5);
步骤1.4)启动tcp补包通路进行补包,补充的数据包存入缓存模块recv_buffer中;
步骤1.5)判断存入缓存模块recv_buffer中数据包的时间是否大于设定的最大缓存时间T,若是,则进入下一步骤,若否,则跳转至步骤1.7);
步骤1.6)停止本地录播,开始网络直播,并跳转至步骤1.2)缓存模块recv_buffer继续接收地面数据服务器发出的多媒体数据包;
步骤1.7)停止网络直播,播放本地录播,并跳转至步骤1.2)缓存模块recv_buffer继续尝试接收地面数据服务器发出的多媒体数据包。
参照图3所示,所述步骤1.1)中建立udp和tcp网络连接的同时创建并行的udp接收线程、tcp连接线程、请求补包线程、tcp接收补包线程、网络直播线程和本地录播线程。在本实施例中直播软件随时等待接收udp组播数据包,每次收到数据,先做数据正确性检查校验check_sum,再与收到的包头信息中的check_sum值比较,如果不相等则丢弃此数据包,并断开udp连接,反复重新初始化udp组播连接,直到初始化成功,继续接收udp组播数据包。如果校验正确,则将udp组播收到的数据包放入接收缓存recv_buffer中,recv_buffer是一个全局性的packet*recv_buffer[MAX_PAK_NUM],在数据结构上来说是一个指针数组,即线性指针链表,每一个成员都是一个数据包pakcet结构,最大存储包的个数MAX_PAK_NUM可从文本型配置文件sysconfig.ini中读取,每次上电运行启动时读取一次,此值大小依赖于本机内存大小,一般设为500000。
所述步骤1.2)中当udp组播接收模块接收到一个正确的数据包后,首先取出包头里面的包序号order,若此次收到的order=0或第一次启动udp组播接收标志first_recv_flag=1,则记录下udp组播接收模块收到的第一个数据包序号udp_recv_first_order=order,上次接收的包号last_order=order,再将此包存储于缓存模块的recv_buffer[0]的位置处。
所述步骤1.3)中udp组播接收模块检测判断否丢包的方法为:
若本次接收的数据包号this_order–上次接收到的数据包号last_order>1,
则表明存在丢包,丢失的包数量Num为:
Num=this_order–last_order–1,
在本实施例中,检测到丢包,立即启动tcp补包模块进行补包,同时udp组播接收模块的接收并列进行,一旦接收缓存值>用户预设值(即最大缓存时间T,本实施例中设定T=10分钟)后,启动网络直播;此处的用户预设值10分钟只是本实施例选取的一个例子,此时间值可设范围为0-整个视频片源的全部时长;如果设为整个片源播放时长,即相当于将整个视频下载到了本地播放一样,这是一种极限,一般来说,除非网络出现故障,否则无线网络不可能出现连续10分钟以上断网的情况,所以此处以10分钟缓存为例,足以满足当前无线网络出现偶尔抖动和信号不佳的情形下网络视频的播放质量。
所述多媒体数据包在缓存模块中的实际存储位置的计算方法为:
接收的数据包号偏移量recv_order_offset=当前接收的包号packet.order-udp组播接收模块第一次接收到的包号udp_recv_first_order,
实际存储位置save_array=(recv_order_offset)%MAX_PCK_NUM,其中,MAX_PCK_NUM为接收缓存能存储的最大数据包数量,
最终存储位置即为save_array,则:
接收缓存recv_buffer[save_array]=接收到的数据包中,在本实施例中以这个存储顺序,来保证音视频数据是顺序来播放的;
存储成功后,将全局接收缓存数据包个数计数器值recv_buffer_count累加1。同时将未接收到多媒体数据包的存储位置空置,直至接收到补充的对应标号的多媒体数据包,将其存入对应的空置位,在本实施例中,参照图8所示,假定order=0的包是第一个收到的存储在recv_buffer[0],如果接连收到order=0,order=3的包,即存储到recv_buffer[0]和recv_buffer[3]的位置,而没有收到order=1和order=2的包(即为丢包),则order=1和order=2包号处的存储位置一直就将会是空的NULL,直到下次收到TCP补包的order=2,则将其存储在此NULL位置,当然,或者是循环一个来回,使(recv_order_offset)%MAX_PCK_NUM=2,也将存储于order=2的位置,order=1即为循环一个来回后存入到recv_buffer[1]处的。
参照图4所示,所述udp接收线程包括以下步骤:
步骤2.1)建立udp连接通路;
步骤2.2)循环接收多媒体数据包,如果udp连接通路接收错误,则重新执行步骤2.1),否则,判断是否有丢包,如有丢包,则将所有丢失包号存入丢包队列中,并启动请求补包线程;如果包号连续即无丢包,则经过校验后将多媒体数据包存入缓存模块recv_buffer中;
步骤2.3)如果接收缓存值>最大缓存时间T,则启动网络直播线程;否则返回继续执行步骤2.2),不断接收,直到接收缓存大于预设的最大缓存时间T。
参照图5所示,所述tcp连接线程包括以下步骤:
步骤3.1)首先判断tcp连接标志是否tcp_connect=1,如果tcp处于断开状态,则等待循环检测,直到tcp_connect=1时进行下一步;
步骤3.2)从补包队列中取出丢失的数据包号order,如果取出为空,则休眠等待sleep一下重新执行步骤3.1);否则将丢失的包号以tcp发送请求,如果发送成功,继续执行步骤3.1)循环取下一个;否则置位tcp_connect=0表明当前tcp连接异常,重新执行步骤3.1)。
参照图6所示,所述请求补包线程包括以下步骤:
步骤4.1)首先判断tcp连接标志是否tcp_connect=1,如果tcp处于断开状态,则等待循环检测,直到tcp_connect=1;
步骤4.2)从补包队列中取出丢失的数据包号order,如果取出为空,则休眠等待sleep一下重新执行步骤4.1);否则将丢失的包号以tcp发送请求,如果发送成功,继续执行步骤4.1)循环取下一个;否则置位tcp_connect=0表明当前tcp连接异常,重新执行步骤4.1)。
参照图7所示,所述tcp接收补包线程包括以下步骤:
步骤5.1)先判断tcp连接状况,若tcp_connect=1,则表明连接正常,开始循环接收地面数据服务器发送来的tcp补包;
步骤5.2)如果tcp接收错误,则置位tcp_connect=0表明tcp此时处于异常情况,需要重连,重新执行步骤5.1);否则经过协议校验,也将数据包存入与udp组播数据包主通道同样的接收缓存中;
步骤5.3)判断是否接收缓存值>最大缓存时间T,若是,则启动网络直播;否则重新执行步骤5.1)。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种无线网络多媒体播放补包系统,其特征在于,该系统包括地面数据服务器、udp组播接收模块、tcp补包模块、缓存模块、本地数据模块和直播终端,所述地面数据服务器通过udp协议向udp组播接收模块无线传输多媒体数据包构成无线传输udp组播数据包主通道,所述udp组播接收模块分别连接缓存模块和tcp补包模块,udp组播接收模块将多媒体数据包存入缓存模块中并检测是否有丢包,有丢包时向tcp补包模块发送丢包信息并建立tcp补包通路,所述tcp补包通路为:udp组播接收模块->tcp补包模块->地面数据服务器->udp组播接收模块,其中tcp补包模块通过tcp协议无线连接地面数据服务器构成请求补包子通路,地面数据服务器通过tcp协议无线连接udp组播接收模块构成补包子通路,udp组播接收模块将补包子通路传输过来的多媒体数据包存入缓存模块中对应的预留位置中,所述缓存模块连接直播终端,并且所述直播终端同时连接本地数据模块,用于在缓存模块和本地数据模块之间来回切换。
2.一种无线网络多媒体播放补包方法,其特征在于,该方法包括以下步骤:
步骤1.1)建立udp和tcp网络连接,设定最大缓存时间T,启动本地录播;
步骤1.2)udp组播接收模块通过车地无线网络接收地面数据服务器发出的多媒体数据包并存入缓存模块recv_buffer中;
步骤1.3)所述udp组播接收模块根据数据包号的连续性进行是否丢包判断,若是,则进入下一步骤,若否,则跳转至步骤1.5);
步骤1.4)启动tcp补包通路进行补包,补充的数据包存入缓存模块recv_buffer中;
步骤1.5)判断存入缓存模块recv_buffer中数据包的时间是否大于设定的最大缓存时间T,若是,则进入下一步骤,若否,则跳转至步骤1.7);
步骤1.6)停止本地录播,开始网络直播,并跳转至步骤1.2)缓存模块recv_buffer继续接收地面数据服务器发出的多媒体数据包;
步骤1.7)停止网络直播,播放本地录播,并跳转至步骤1.2)缓存模块recv_buffer继续尝试接收地面数据服务器发出的多媒体数据包。
3.根据权利要求2所述的无线网络多媒体播放补包方法,其特征在于,所述步骤1.1)中建立udp和tcp网络连接的同时创建并行的udp接收线程、tcp连接线程、请求补包线程、tcp接收补包线程、网络直播线程和本地录播线程。
4.根据权利要求2所述的无线网络多媒体播放补包方法,其特征在于,所述步骤1.2)中当udp组播接收模块接收到一个正确的数据包后,首先取出包头里面的包序号order,若此次收到的order=0或第一次启动udp组播接收标志first_recv_flag=1,则记录下udp组播接收模块收到的第一个数据包序号udp_recv_first_order=order,上次接收的包号last_order=order,再将此包存储于缓存模块的recv_buffer[0]的位置处。
5.根据权利要求2或4所述的无线网络多媒体播放补包方法,其特征在于,所述步骤1.3)中udp组播接收模块检测判断否丢包的方法为:
若本次接收的数据包号this_order–上次接收到的数据包号last_order>1,
则表明存在丢包,丢失的包数量Num为:
Num=this_order–last_order–1。
6.根据权利要求2或4所述的无线网络多媒体播放补包方法,其特征在于,所述多媒体数据包在缓存模块中的实际存储位置的计算方法为:
接收的数据包号偏移量recv_order_offset=当前接收的包号packet.order-udp组播接收模块第一次接收到的包号udp_recv_first_order,
实际存储位置save_array=(recv_order_offset)%MAX_PCK_NUM,其中,MAX_PCK_NUM为接收缓存能存储的最大数据包数量,
最终存储位置即为save_array,则:
接收缓存recv_buffer[save_array]=接收到的数据包中的实际数据packet.data,
存储成功后,将全局接收缓存数据包个数计数器值recv_buffer_count累加1,同时将未接收到多媒体数据包的存储位置空置,直至接收到补充的对应标号的多媒体数据包,将其存入对应的空置位。
7.根据权利要求3所述的无线网络多媒体播放补包方法,其特征在于,所述udp接收线程包括以下步骤:
步骤2.1)建立udp连接通路;
步骤2.2)循环接收多媒体数据包,如果udp连接通路接收错误,则重新执行步骤2.1),否则,判断是否有丢包,如有丢包,则将所有丢失包号存入丢包队列中,并启动请求补包线程;如果包号连续即无丢包,则经过校验后将多媒体数据包存入缓存模块recv_buffer中;
步骤2.3)如果接收缓存值>最大缓存时间T,则启动网络直播线程;否则返回继续执行步骤2.2),不断接收,直到接收缓存大于预设的最大缓存时间T。
8.根据权利要求3所述的无线网络多媒体播放补包方法,其特征在于,所述tcp连接线程包括以下步骤:
步骤3.1)首先判断tcp连接标志是否tcp_connect=1,如果tcp_connect=0,表明tcp处于断开状态,则等待循环检测,直到tcp_connect=1时进行下一步;
步骤3.2)从补包队列中取出丢失的数据包号order,如果取出为空,则休眠等待sleep一下重新执行步骤3.1);否则将丢失的包号以tcp发送请求,如果发送成功,继续执行步骤3.1)循环取下一个;否则置位tcp_connect=0表明当前tcp连接异常,重新执行步骤3.1)。
9.根据权利要求3所述的无线网络多媒体播放补包方法,其特征在于,所述请求补包线程包括以下步骤:
步骤4.1)首先判断tcp连接标志是否tcp_connect=1,如果tcp_connect=0,表明tcp处于断开状态,则等待循环检测,直到tcp_connect=1;
步骤4.2)从补包队列中取出丢失的数据包号order,如果取出为空,则休眠等待sleep一下重新执行步骤4.1);否则将丢失的包号以tcp发送请求,如果发送成功,继续执行步骤4.1)循环取下一个;否则置位tcp_connect=0表明当前tcp连接异常,重新执行步骤4.1)。
10.根据权利要求3所述的无线网络多媒体播放补包方法,其特征在于,所述tcp接收补包线程包括以下步骤:
步骤5.1)先判断tcp连接状况,若tcp_connect=1,则表明连接正常,开始循环接收地面数据服务器发送来的tcp补包;
步骤5.2)如果tcp接收错误,则置位tcp_connect=0表明tcp此时处于异常情况,需要重连,重新执行步骤5.1);否则经过协议校验,也将数据包存入与udp组播数据包主通道同样的接收缓存中;
步骤5.3)判断是否接收缓存值>最大缓存时间T,若是,则启动网络直播;否则重新执行步骤5.1)。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510491648.8A CN105072508A (zh) | 2015-08-12 | 2015-08-12 | 一种无线网络多媒体播放补包系统及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510491648.8A CN105072508A (zh) | 2015-08-12 | 2015-08-12 | 一种无线网络多媒体播放补包系统及方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN105072508A true CN105072508A (zh) | 2015-11-18 |
Family
ID=54501768
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510491648.8A Pending CN105072508A (zh) | 2015-08-12 | 2015-08-12 | 一种无线网络多媒体播放补包系统及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105072508A (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108111531A (zh) * | 2018-01-02 | 2018-06-01 | 青岛海信网络科技股份有限公司 | 一种增强视频直播质量的方法及装置 |
CN108155999A (zh) * | 2017-12-27 | 2018-06-12 | 罗建平 | 带tcp补包机制的智能udp组播文件分发系统及方法 |
CN111385241A (zh) * | 2018-12-27 | 2020-07-07 | 北京紫荆视通科技有限公司 | 多媒体数据的丢包修复方法、装置、系统和可读存储介质 |
CN111935490A (zh) * | 2019-05-13 | 2020-11-13 | 深圳市茁壮网络股份有限公司 | 一种直播录流容灾处理方法及系统 |
CN112565430A (zh) * | 2020-12-08 | 2021-03-26 | 上证所信息网络有限公司 | 一种多市场行情数据在广域网的低时延可靠传输方法 |
CN112969075A (zh) * | 2021-01-29 | 2021-06-15 | 北京字节跳动网络技术有限公司 | 直播过程中的补帧方法、装置及计算设备 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1980377A (zh) * | 2005-12-01 | 2007-06-13 | 北京北大方正电子有限公司 | 一种智能插播素材的方法 |
CN101018110A (zh) * | 2006-02-10 | 2007-08-15 | 中兴通讯股份有限公司 | 一种基于重传次数的harq协议的重传调度方法 |
CN101277175A (zh) * | 2007-03-30 | 2008-10-01 | 国际商业机器公司 | 改进会话启动协议服务器性能的方法和装置 |
CN101826937A (zh) * | 2010-03-18 | 2010-09-08 | 常熟理工学院 | 适用于下一代移动互联网的链路层差错控制系统及其方法 |
CN101945129A (zh) * | 2010-09-10 | 2011-01-12 | 北京易视腾科技有限公司 | P2p流媒体直播的低延时传输方法及系统 |
CN102970615A (zh) * | 2012-11-21 | 2013-03-13 | 联想中望系统服务有限公司 | 高清视频的高效传送及编解码的系统 |
CN104468061A (zh) * | 2014-11-25 | 2015-03-25 | 厦门雅迅网络股份有限公司 | 一种低速网络环境下的实时可靠数据传输的方法及系统 |
-
2015
- 2015-08-12 CN CN201510491648.8A patent/CN105072508A/zh active Pending
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1980377A (zh) * | 2005-12-01 | 2007-06-13 | 北京北大方正电子有限公司 | 一种智能插播素材的方法 |
CN101018110A (zh) * | 2006-02-10 | 2007-08-15 | 中兴通讯股份有限公司 | 一种基于重传次数的harq协议的重传调度方法 |
CN101277175A (zh) * | 2007-03-30 | 2008-10-01 | 国际商业机器公司 | 改进会话启动协议服务器性能的方法和装置 |
CN101826937A (zh) * | 2010-03-18 | 2010-09-08 | 常熟理工学院 | 适用于下一代移动互联网的链路层差错控制系统及其方法 |
CN101945129A (zh) * | 2010-09-10 | 2011-01-12 | 北京易视腾科技有限公司 | P2p流媒体直播的低延时传输方法及系统 |
CN102970615A (zh) * | 2012-11-21 | 2013-03-13 | 联想中望系统服务有限公司 | 高清视频的高效传送及编解码的系统 |
CN104468061A (zh) * | 2014-11-25 | 2015-03-25 | 厦门雅迅网络股份有限公司 | 一种低速网络环境下的实时可靠数据传输的方法及系统 |
Non-Patent Citations (3)
Title |
---|
曹欣等: "一种改进的不限重传次数的HARQ重传方案", 《电讯技术》 * |
王练: "基于网络编码的无线网络重传方案综述", 《重庆邮电大学学报(自然科学版)》 * |
郑侃等: "3G长期演进系统中的混合自动重传请求技术", 《中兴通讯技术》 * |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108155999A (zh) * | 2017-12-27 | 2018-06-12 | 罗建平 | 带tcp补包机制的智能udp组播文件分发系统及方法 |
CN108155999B (zh) * | 2017-12-27 | 2020-08-07 | 乐自科技(南京)有限公司 | 带tcp补包机制的智能udp组播文件分发系统及方法 |
CN108111531A (zh) * | 2018-01-02 | 2018-06-01 | 青岛海信网络科技股份有限公司 | 一种增强视频直播质量的方法及装置 |
CN108111531B (zh) * | 2018-01-02 | 2020-12-08 | 青岛海信网络科技股份有限公司 | 一种增强视频直播质量的方法及装置 |
CN111385241A (zh) * | 2018-12-27 | 2020-07-07 | 北京紫荆视通科技有限公司 | 多媒体数据的丢包修复方法、装置、系统和可读存储介质 |
CN111385241B (zh) * | 2018-12-27 | 2022-02-18 | 北京紫荆视通科技有限公司 | 多媒体数据的丢包修复方法、装置、系统和可读存储介质 |
CN111935490A (zh) * | 2019-05-13 | 2020-11-13 | 深圳市茁壮网络股份有限公司 | 一种直播录流容灾处理方法及系统 |
CN111935490B (zh) * | 2019-05-13 | 2023-12-05 | 深圳市茁壮网络股份有限公司 | 一种直播录流容灾处理方法及系统 |
CN112565430A (zh) * | 2020-12-08 | 2021-03-26 | 上证所信息网络有限公司 | 一种多市场行情数据在广域网的低时延可靠传输方法 |
CN112969075A (zh) * | 2021-01-29 | 2021-06-15 | 北京字节跳动网络技术有限公司 | 直播过程中的补帧方法、装置及计算设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105072508A (zh) | 一种无线网络多媒体播放补包系统及方法 | |
US11095701B2 (en) | Method and apparatus for providing adaptive streaming service | |
US8300709B2 (en) | Method of processing video data and wireless communication apparatus | |
CN111052754B (zh) | 将空间元素的帧流传输到客户端装置 | |
CN103888818B (zh) | 一种电视节目播放方法、设备和系统 | |
CN102932676B (zh) | 基于音视频同步的自适应带宽传输和播放方法 | |
US8488509B2 (en) | Method of minimizing an unnecessary scheduling information reception in a wireless communication system | |
CN102710969B (zh) | 通过无线网络传输直播数据的方法及其系统 | |
US9226266B2 (en) | Method for determining delay parameters for user data flow synchronization for eMBMS | |
CN106604064A (zh) | 一种快速开播方法及装置 | |
CN105072014A (zh) | 一种多媒体数据传输方法及车载设备、监控服务器 | |
KR101613857B1 (ko) | 무선 방송 통신 시스템 및 그의 방송 서비스 방법 | |
WO2021254335A1 (zh) | 一种切换控制方法及通信装置 | |
US20230345581A1 (en) | Method and Apparatus for Releasing RRC Connection | |
CN102196042A (zh) | 面向物联网应用的多媒体采集传输终端及其实现方法 | |
WO2014144641A1 (en) | System and method for replicating a media stream | |
CN112684992A (zh) | 一种投屏播放同步的实现方法、装置及计算机主设备 | |
WO2016197759A1 (zh) | 信息展示方法、终端设备、服务器和系统 | |
JP2002171257A (ja) | 無線伝送装置及び無線伝送方法 | |
CN102651849B (zh) | 实现mbms业务连续性的上报方法和用户设备 | |
KR101129192B1 (ko) | 이동 통신 시스템 및 방송시스템에서 모바일 아이피 텔레비젼 서비스 제공 장치 및 방법 | |
KR101346984B1 (ko) | 무선 디지털 통신 방법 및 시스템 | |
CN103813205B (zh) | 在多个媒体播放设备间实现媒体同步播放控制的方法和装置 | |
CN105406955A (zh) | 数据输出的控制方法和系统 | |
US20110151911A1 (en) | Multimedia broadcast/multicast service system, and data transmission and reception method thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20151118 |