CN101656597B - 数据接收和发送方法、装置及数据传输系统 - Google Patents
数据接收和发送方法、装置及数据传输系统 Download PDFInfo
- Publication number
- CN101656597B CN101656597B CN 200910176422 CN200910176422A CN101656597B CN 101656597 B CN101656597 B CN 101656597B CN 200910176422 CN200910176422 CN 200910176422 CN 200910176422 A CN200910176422 A CN 200910176422A CN 101656597 B CN101656597 B CN 101656597B
- Authority
- CN
- China
- Prior art keywords
- medium bag
- data packet
- media data
- bag
- packet
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种数据接收和发送方法、装置及数据传输系统。涉及通信领域；解决了无法在合理占用网络资源的同时实现对数据包丢失的可靠处理的问题。该数据接收方法包括：在接收完一个媒体数据分组后，判断是否能够恢复丢失的媒体包；如果能够恢复丢失的媒体包，则恢复丢失的媒体包；或，如果不能恢复丢失的媒体包，则向流媒体服务器发送丢包信息，请求流媒体服务器重新发送丢失的媒体包。本发明提供的技术方案适用于IPTV业务。
Description
技术领域
本发明涉及通信领域，尤其涉及一种数据接收和发送方法、装置及数据传输系统。
背景技术
在IPTV业务中，媒体数据由流媒体服务器到机顶盒的传输质量，直接影响着用户的视频观看效果。如果媒体数据传输过程中出现了丢失，视频画面就会出现停顿或者马赛克花屏的情况。如何保证媒体传输的质量，给用户提供高质量的视频观看体验，是IPTV领域面临的关键技术问题。
在IPTV系统中，对于丢包，一般采用重传或者FEC(前向纠错)技术进行处理。重传技术是在客户端反馈回丢包消息后，根据客户端反馈的丢包消息，重新发送丢失的数据包；FEC技术则是由客户端重建丢失的数据包。
在上述解决丢包问题的过程中，存在如下问题：
采用重传技术，带来的相关联的延迟会可能会比较大，由于实时的要求，不可能进行多次的重传，如果重传包也丢失，无法对重传包再进行重传，可靠性低；采用FEC技术，客户端能够重建丢失的包，但在丢包数量较多时，很难重建出丢失的数据包，适用范围较小。使用上述两种方法，均无法在合理占用网络资源的同时实现对数据包丢失的可靠处理。
发明内容
本发明提供了一种数据接收和发送方法、装置及数据传输系统，解决了无法在合理占用网络资源的同时实现对数据包丢失的可靠处理的问题。
一种数据接收方法，包括：
在接收完一个媒体数据分组后，判断是否能够恢复丢失的媒体包；
如果能够恢复丢失的媒体包，则恢复丢失的媒体包；或，
如果不能恢复丢失的媒体包，则向流媒体服务器发送丢包信息，请求流媒体服务器重新发送丢失的媒体包。
进一步的，所述在接收完一个媒体数据分组后，判断是否能够恢复丢失的媒体包的步骤之前，还包括：
设置判定门限，具体为设定丢包门限及重传门限。
进一步的，所述在接收完一个媒体数据分组后，判断是否能够恢复丢失的媒体包具体为：
获取所述媒体数据分组的丢包率；
如果所述媒体数据分组的丢包率大于丢包门限且小于重传门限，则确定能够恢复丢失的媒体包；
如果所述媒体数据分组的丢包率不小于重传门限，则确定不能够恢复丢失的媒体包。
进一步的，所述媒体数据分组包括媒体包和前向纠错(FEC)包，该方法还包括：
设置FEC包的冗余度，具体为将FEC包的冗余度设置为不大于5％。
一种数据发送方法，包括：
发送媒体数据分组，并在发送媒体数据分组的同时，对所述媒体数据分组进行媒体缓存；
根据接收端反馈的重新发送丢失的媒体包的请求，从媒体缓存的媒体数据分组中查找对应的媒体包，并在新的媒体数据分组发送所述对应的媒体包和FEC包。
进一步的，所述数据发送方法还包括：
为所述对应的媒体包产生FEC包，在所述新的媒体数据分组中发送所述FEC包。
一种客户端，包括：
丢包检测模块，用于在接收完一个媒体数据分组后，判断是否能够恢复丢失的媒体包；
数据恢复模块，用于在所述丢包检测模块判定能够恢复丢失的媒体包时，恢复丢失的媒体包；
丢包信息上报模块，用于在所述丢包检测模块判定不能恢复丢失的媒体包时，向流媒体服务器发送丢包信息，请求流媒体服务器重新发送丢失的媒体包。
进一步的，所述客户端还包括：
门限设置模块，用于设置判定门限，具体为设定丢包门限及重传门限；
FEC设置模块，用于设置FEC包的冗余度，具体为将FEC包的冗余度设置为不大于5％。
一种流媒体服务器，包括：
媒体数据媒体缓存模块，用于在发送媒体数据分组的同时，对所述媒体数据分组进行媒体缓存；
丢包补偿模块，用于根据接收端反馈的重新发送丢失的媒体包的请求，从媒体缓存的媒体数据分组中查找对应的媒体包，并在新的媒体数据分组发送所述对应的媒体包和该媒体包的FEC包。
一种数据传输系统，其特征在于，包括客户端和流媒体服务器；
所述客户端，用于在接收完一个媒体数据分组后，判断是否能够恢复丢失的媒体包，在所述丢包检测模块判定能够恢复丢失的媒体包时，恢复丢失的媒体包，或在所述丢包检测模块判定不能恢复丢失的媒体包时，向流媒体服务器发送丢包信息，请求流媒体服务器重新发送丢失的媒体包；
所述流媒体服务器，用于在发送媒体数据分组的同时，对所述媒体数据分组进行媒体缓存，根据接收端反馈的重新发送丢失的媒体包的请求，从媒体缓存的媒体数据分组中查找对应的媒体包，并在新的媒体数据分组发送所述对应的媒体包和该媒体包的FEC包。
本发明的实施例提供了一种数据接收和发送方法、装置及系统，在接收完一个媒体数据分组后，判断该媒体数据分组是否存在媒体包丢失，并根据丢包率确定采用恢复媒体包或重传的方法解决媒体包丢失的问题；且在发送时媒体缓存媒体包，根据客户端反馈的重传信息重传，解决了无法在合理占用网络资源的同时实现对数据包丢失的可靠处理的问题，提高了系统效率。
附图说明
图1为本发明的实施例提供的一种数据接收和发送方法的流程图；
图2为图1中步骤105的具体流程图；
图3为本发明的实施例提供的一种客户端的结构示意图；
图4为本发明的又一实施例提供的一种客户端的结构示意图；
图5为本发明的实施例提供的一种流媒体服务器的结构示意图；
图6为本发明的实施例提供的一种数据传输系统的结构示意图。
具体实施方式
为了解决无法在合理占用网络资源的同时实现对数据包丢失的可靠处理的问题，本发明的实施例提供了一种数据接收和发送方法，该方法基于UDP传输模式，使用该方法在流媒体服务器和客户端之间完成数据传输的过程如图1所示，包括：
步骤101、流媒体服务器向客户端发送媒体数据分组，并在发送媒体数据分组的同时，对所述媒体数据分组进行媒体缓存；
本步骤中，流媒体服务器发送媒体数据分组，既包括媒体包，又包括媒体包的FEC包。流媒体服务器在发送媒体数据分组时，为该媒体数据分组中的媒体包产生相应的FEC包。。
本发明实施例中，FEC技术采取比较低的冗余度，减少对带宽的依赖程度。对于IPTV业务来说，冗余度低于5％时对带宽影响相对较小。假设一个媒体数据分组中的J个媒体包，经过FEC算法计算处理后，产生了新的K个FEC包，则K需要小于J。
步骤102、客户端在接收完一个媒体数据分组后，判断是否能够恢复丢失的媒体包；
媒体包一般用RTP(Real-time Transport Protocol，实时传输协议)格式封装，常用的流媒体的丢包检测方法就是根据RTP的序号来判断的。RTP包的序号是顺序逐渐递增的，一旦出现跳变，就表示丢包，并且可以根据序号差来统计丢包的个数。
本步骤中，客户端检测到媒体包有丢包，则启动丢包检测定时器，在丢包检测定时器超时，或者未超时，但是丢包所在媒体数据分组最后一个包已经接收完毕时，检测该分组媒体包丢包情况，判断是否能够恢复丢失的媒体包。由于使用UDP传输模式，估在传输过程中有可能发生乱序的情况，客户端会暂时性的误认为丢失了媒体数据包，故在接收一个媒体数据分组完成后再判定是否丢包及能否恢复丢失的媒体包更为准确。
本发明实施例中，会在客户端上设置判定门限，具体为设定恢复门限及重传门限。恢复门限与采用的FEC算法有关，重传门限与当前的网络状况有关。
在判断是否能够恢复丢失的媒体包时，首先获取所述媒体数据分组的丢包率，如果所述媒体数据分组存在丢包，且丢包率小于等于丢包门限，则确定能够恢复丢失的媒体包，进行恢复；如果所述媒体数据分组的丢包率大于丢包门限且小于等于重传门限，则对丢失的媒体包采取重传；如果丢包率大于重传门限，说明当前网络质量较差，且大量的媒体包重传会进一步恶化网络状况，故不采取任何动作。
此外，由于本发明实施例中，流媒体服务器发送的媒体包可能是重传媒体包，所以，当客户端接收到媒体包是重传媒体包时，如果发生重传媒体包丢失，则不启动丢包检测定时器，这样就避免了一个媒体包被多次重传，有效控制了资源浪费。
步骤103、如果能够恢复丢失的媒体包，则恢复丢失的媒体包；
如果步骤102的判断结果为能够恢复丢失的媒体包，则本步骤中，客户端直接恢复出丢失的媒体包。
步骤104、如果能够重传丢失的媒体包，则客户端向流媒体服务器发送丢包信息，请求流媒体服务器重新发送丢失的媒体包；
本步骤中，客户端将接收到的媒体数据分组的丢包信息反馈给流媒体服务器，消息以NACK(Negative Acknowledgement)形式反馈，NACK消息反馈整组数据的丢包情况，具体为丢失的媒体包的序号。
步骤105、流媒体服务器根据接收端反馈的重新发送丢失的媒体包的请求，从媒体缓存的媒体数据分组中查找对应的媒体包，并在新的媒体数据分组发送所述对应的媒体包和FEC包；
本步骤中，流媒体服务器收到步骤104中客户端发送的NACK消息后，如果还处于上一个数据分组的丢包重传流程，则等待上一次丢包重传流程结束后，启动重传媒体包的流程，具体如图2所示，包括：
步骤1051、流媒体服务器在媒体缓存中查找需要重传的媒体包；
流媒体服务器将数据分组缓存时，是以分组为单位对整个媒体数据分组进行缓存。即一个媒体数据分组的全部数据包，都存储在缓存中。
需要说明的是，如果在媒体缓存中不存在需要重传的媒体包，说明这个媒体包已经发出很长时间了，不再进行重传。
步骤1052、流媒体服务器为重传的的媒体包产生相应的FEC包；
步骤1053、将重传的媒体包及相应的FEC包加入新的媒体数据分组进行发送；
为了描述方便，现将媒体数据分组中丢包个数设为L，媒体数据分组中媒体包个数设为J，本步骤中，流媒体服务器将重传的媒体包加入新的媒体数据分组时，有以下三种情况：
1、如果流媒体服务器刚发送了一个媒体数据分组的N个媒体包，而且N+L小于等于J(N可以为0)，则流媒体服务器将另一个媒体数据分组(该分组)的N个媒体包，L个重传的媒体包，J-L-N个媒体包(哪一个分组的？该分组)以及这L个重传的媒体包对应的K个FEC包构成一个新分组，并继续发送这一新分组中剩下的媒体包。其中，L个重传的媒体包放在该新分组中优先发送的位置。
例如，媒体数据分组G3，G3中包括媒体包A1，A2，…，Aj以及冗余包R1，R2，…，Rk；在G3前发送媒体数据分组G1。
在已经发送了A1，A2，…，An时，流媒体服务器接收到客户端请求，要求重传分组G1中的B1，B2，…，B1等媒体包。这时，流媒体服务器重新构成分组G4，G4包括A1，A2，…An，B1，B2，…，B1，An+1，An+2，……Aj-1.，以及相应的FEC包R’1，R’2…R’k，即在发送完A1到An后，接着发送B1到B1。
2、如果流媒体服务器刚发送了另一个媒体数据分组的N个媒体包，N小于J但是N+L大于J，则将这N个另一个媒体数据分组中的媒体包和J-N个重传媒体包归于一个新分组，剩下的L-(J-N)个重传媒体包归入到与该新分组紧邻的下一个分组。在该新分组及该新分组的下一个分组中，重传的媒体包都处于该分组优先发送的位置；
3、如果流媒体服务器当前正准备发送或者正在发送另一个媒体数据分组的FEC包，则继续发送完该分组的FEC包，将L个重传的媒体包做为下一个分组的前L个媒体包。
本发明的实施例提供了一种数据接收和发送方法，在接收完一个媒体数据分组后，判断该媒体数据分组是否存在媒体包丢失，并根据丢包率确定采用恢复媒体包或重传的方法解决媒体包丢失的问题；且在发送时媒体缓存媒体包，根据客户端反馈的重传信息重传，解决了无法在合理占用网络资源的同时实现对数据包丢失的可靠处理的问题，提高了系统效率。在丢包率比较小的情况下，通过FEC方法，能够顺序的恢复出丢失的媒体包；在丢包率比较大的情况下，通过重传机制来获取丢失的媒体包，根据实际情况决定资源战胜，有效的复用了资源；且在网络比较恶劣的情况下，如果重传包再次丢失的情况下，也可能会通过重传包的FEC计算方法恢复出丢失的重传包，进一步增加了系统的可靠性。
本发明的实施例还提供了一种客户端，如图3所示，包括：
丢包检测模块301，用于在接收完一个媒体数据分组后，判断是否能够恢复丢失的媒体包；
数据恢复模块302，用于在所述丢包检测模块301判定能够恢复丢失的媒体包时，恢复丢失的媒体包；
丢包信息上报模块303，用于在所述丢包检测模块301判定能够重传丢失的媒体包时，向流媒体服务器发送丢包信息，请求流媒体服务器重新发送丢失的媒体包。
进一步的，该客户端如图4所示，还包括：
门限设置模块304，用于设置判定门限，具体为设定丢包门限及重传门限；
FEC设置模块305，用于设置FEC包的冗余度，具体为将FEC包的冗余度设置为不大于5％。
本发明的实施例还提供了一种流媒体服务器，如图5所示，包括；
媒体数据媒体缓存模块501，用于在发送媒体数据分组的同时，对所述媒体数据分组进行媒体缓存；
丢包补偿模块502，用于根据接收端反馈的重新发送丢失的媒体包的请求，从媒体缓存的媒体数据分组中查找对应的媒体包，并在新的媒体数据分组发送所述对应的媒体包和该媒体包的FEC包。
本发明的实施例还提供了一种数据传输系统，如图6所示，包括客户端601和流媒体服务器602；
所述客户端601，用于在接收完一个媒体数据分组后，判断是否能够恢复丢失的媒体包，在所述丢包检测模块判定能够恢复丢失的媒体包时，恢复丢失的媒体包，或在所述丢包检测模块判定能够重传丢失的媒体包时，向流媒体服务器602发送丢包信息，请求流媒体服务器602重新发送丢失的媒体包；
所述流媒体服务器602，用于在发送媒体数据分组的同时，对所述媒体数据分组进行媒体缓存，根据客户端601反馈的重新发送丢失的媒体包的请求，从媒体缓存的媒体数据分组中查找对应的媒体包，并在新的媒体数据分组发送所述对应的媒体包和该媒体包的FEC包。
上述客户端、流媒体服务器和数据传输系统，可以与本发明的实施例提供的一种数据接收和发送方法相结合，在接收完一个媒体数据分组后，判断该媒体数据分组是否存在媒体包丢失，并根据丢包率确定采用恢复媒体包或重传的方法解决媒体包丢失的问题；且在发送时媒体缓存媒体包，根据客户端反馈的重传信息重传，解决了无法在合理占用网络资源的同时实现对数据包丢失的可靠处理的问题，提高了系统效率。
本领域普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
另外，在本发明各个实施例中的各功能单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。
上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求所述的保护范围为准。
Claims (7)
1.一种数据接收方法，其特征在于，包括：
设定丢包门限及重传门限；
在接收完一个媒体数据分组后，判断是否能够恢复丢失的媒体包，包括：获取所述媒体数据分组的丢包率；如果所述媒体数据分组的丢包率不大于丢包门限，则确定能够恢复丢失的媒体包；如果所述媒体数据分组的丢包率大于丢包门限且不大于重传门限，则确定能够重传丢失的媒体包；
如果能够恢复丢失的媒体包，则恢复丢失的媒体包；或，
如果不能恢复丢失的媒体包，则向流媒体服务器发送丢包信息，请求流媒体服务器重新发送丢失的媒体包。
2.根据权利要求1所述的数据接收方法，其特征在于，所述媒体数据分组包括媒体包和前向纠错FEC包，该方法还包括：
设置FEC包的冗余度为不大于5％。
3.一种数据发送方法，其特征在于，包括：
发送媒体数据分组，并在发送媒体数据分组的同时，对所述媒体数据分组进行媒体缓存；
根据接收端反馈的重新发送丢失的媒体包的请求，从媒体缓存的媒体数据分组中查找对应的媒体包，并在新的媒体数据分组发送所述对应的媒体包和FEC包，包括：流媒体服务器将重传的媒体包加入新的媒体数据分组：
将媒体数据分组中丢包个数设为L，媒体数据分组中媒体包个数设为J；
如果流媒体服务器刚发送了另一个媒体数据分组的N个媒体包，而且N+L小于等于J，则流媒体服务器将所述另一个媒体数据分组的N个媒体包，L个重传的媒体包，J-L-N个媒体包以及这L个重传的媒体包对应的K个FEC包构成一个新分组，并继续发送这一新分组中剩下的媒体包；
如果流媒体服务器刚发送了另一个媒体数据分组的N个媒体包，N小于J但是N+L大于J，则将所述另一个媒体数据分组中的这N个媒体包和J-N个重传媒体包归于一个新分组，剩下的L-(J-N)个重传媒体包归入到与该新分组紧邻的下一个分组；
如果流媒体服务器当前正准备发送或者正在发送另一个媒体数据分组的FEC包，则继续发送完该分组的FEC包，将L个重传的媒体包做为下一个分组的前L个媒体包。
4.一种客户端，其特征在于，包括：
门限设置模块，用于设置丢包门限及重传门限；
丢包检测模块，用于按照以下方式在接收完一个媒体数据分组后，判断是否能够恢复丢失的媒体包：获取所述媒体数据分组的丢包率；如果所述媒体数据分组的丢包率不大于丢包门限，则确定能够恢复丢失的媒体包；如果所述媒体数据分组的丢包率大于丢包门限且不大于重传门限，则确定能够重传丢失的媒体包；
数据恢复模块，用于在所述丢包检测模块判定能够恢复丢失的媒体包时，恢复丢失的媒体包；
丢包信息上报模块，用于在所述丢包检测模块判定重传丢失的媒体包时，向流媒体服务器发送丢包信息，请求流媒体服务器重新发送丢失的媒体包。
5.根据权利要求4所述的客户端，其特征在于，所述媒体数据分组包括媒体包和前向纠错FEC包，该客户端还包括：
FEC设置模块，用于设置FEC包的冗余度为不大于5％。
6.一种流媒体服务器，其特征在于，包括：
媒体数据媒体缓存模块，用于在发送媒体数据分组的同时，对所述媒体数据分组进行媒体缓存；
丢包补偿模块，用于根据接收端反馈的重新发送丢失的媒体包的请求，从媒体缓存的媒体数据分组中查找对应的媒体包，并在新的媒体数据分组发送所述对应的媒体包和该媒体包的FEC包，按照以下方式将重传的媒体包加入新的媒体数据分组：
将媒体数据分组中丢包个数设为L，媒体数据分组中媒体包个数设为J；
如果刚发送了另一个媒体数据分组的N个媒体包，而且N+L小于等于J，则将所述另一个媒体数据分组的N个媒体包，L个重传的媒体包，J-L-N个媒体包以及这L个重传的媒体包对应的K个FEC包构成一个新分组，并继续发送这一新分组中剩下的媒体包；
如果刚发送了另一个媒体数据分组的N个媒体包，N小于J但是N+L大于J，则将所述另一个媒体数据分组中的这N个媒体包和J-N个重传媒体包归于一个新分组，剩下的L-(J-N)个重传媒体包归入到与该新分组紧邻的下一个分组；
如果当前正准备发送或者正在发送另一个媒体数据分组的FEC包，则继续发送完该分组的FEC包，将L个重传的媒体包做为下一个分组的前L个媒体包。
7.一种数据传输系统，其特征在于，包括如权利要求4-5中任一项所述的客户端和如权利要求6所述的流媒体服务器。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200910176422 CN101656597B (zh) | 2009-09-14 | 2009-09-14 | 数据接收和发送方法、装置及数据传输系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200910176422 CN101656597B (zh) | 2009-09-14 | 2009-09-14 | 数据接收和发送方法、装置及数据传输系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101656597A CN101656597A (zh) | 2010-02-24 |
| CN101656597B true CN101656597B (zh) | 2013-09-11 |
Family
ID=41710706
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 200910176422 Expired - Fee Related CN101656597B (zh) | 2009-09-14 | 2009-09-14 | 数据接收和发送方法、装置及数据传输系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101656597B (zh) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10218467B2 (en) | 2009-12-23 | 2019-02-26 | Pismo Labs Technology Limited | Methods and systems for managing error correction mode |
| CN102130821A (zh) * | 2010-08-11 | 2011-07-20 | 华为技术有限公司 | 一种iptv系统中丢包处理的方法、服务器及系统 |
| CN101989902B (zh) * | 2010-11-16 | 2014-12-31 | 中兴通讯股份有限公司 | 一种数据重传方法及装置 |
| CN103107952A (zh) * | 2013-03-08 | 2013-05-15 | 苏州工业园区云视信息技术有限公司 | 一种抗rtp媒体包网络丢包的方法 |
| US9603039B2 (en) * | 2013-04-03 | 2017-03-21 | Qualcomm Incorporated | Opportunistic media patching for a communication session |
| CN103533450B (zh) * | 2013-06-09 | 2018-03-09 | 浙江宇视科技有限公司 | 一种媒体流可靠传输和接收的方法以及装置 |
| CN104104480B (zh) * | 2014-07-31 | 2017-11-14 | 北京蓝汛通信技术有限责任公司 | 用于tcp协议的重传包丢失检测方法和装置 |
| CN106797281B (zh) * | 2014-12-24 | 2020-03-20 | 柏思科技有限公司 | 用于通过聚合连接传输数据的方法和系统 |
| CN106034011A (zh) * | 2015-03-11 | 2016-10-19 | 中国移动通信集团四川有限公司 | 一种组播传输质量保障的控制方法及系统 |
| CN106330930A (zh) * | 2016-08-29 | 2017-01-11 | 烽火通信科技股份有限公司 | 基于流媒体丢包二次重传系统及其方法 |
| CN107979449B (zh) * | 2016-10-25 | 2020-11-20 | 杭州海康威视数字技术股份有限公司 | 一种数据传输方法及装置 |
| CN108234080A (zh) * | 2018-01-12 | 2018-06-29 | 苏州汇万家数字科技有限公司 | 一种音视频传输方法 |
| CN110661995A (zh) * | 2018-06-29 | 2020-01-07 | 成都鼎桥通信技术有限公司 | 视频组呼的丢包重传方法及系统 |
| CN109064524A (zh) * | 2018-08-16 | 2018-12-21 | 上海联影医疗科技有限公司 | 一种数据传输方法、数据收集板、重建机及介质 |
| CN109862440A (zh) * | 2019-02-22 | 2019-06-07 | 深圳市凯迪仕智能科技有限公司 | 音视频传输前向纠错方法、装置、计算机设备及存储介质 |
| CN110233856B (zh) * | 2019-06-28 | 2022-04-05 | 北京云中融信网络科技有限公司 | 报文处理方法、装置及计算机可读存储介质 |
| CN111262658B (zh) * | 2020-02-11 | 2022-09-16 | 平安科技（深圳）有限公司 | 基于fec的重传方法、装置及可读存储介质 |
| CN112165655A (zh) * | 2020-08-19 | 2021-01-01 | 视联动力信息技术股份有限公司 | 基于视联网的数据传输方法、装置、设备及介质 |
| CN113938881A (zh) * | 2021-10-18 | 2022-01-14 | 上海华讯网络系统有限公司 | 适用于互联网数据的传输系统及方法 |
| CN115314479B (zh) * | 2022-07-05 | 2023-12-29 | 上海赛连信息科技有限公司 | 流媒体传输容错控制方法及其系统 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101136722A (zh) * | 2007-10-15 | 2008-03-05 | 北京交通大学 | 一种适用于高速移动终端的数据发送方法及传输设备 |
| CN101222302A (zh) * | 2007-01-11 | 2008-07-16 | 北京邮电大学 | 一种在组播业务中实现差错恢复的方法 |
| CN101252425A (zh) * | 2008-04-09 | 2008-08-27 | 杭州华三通信技术有限公司 | 一种自动适应网络的丢包纠错方法和系统 |
-
2009
- 2009-09-14 CN CN 200910176422 patent/CN101656597B/zh not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101222302A (zh) * | 2007-01-11 | 2008-07-16 | 北京邮电大学 | 一种在组播业务中实现差错恢复的方法 |
| CN101136722A (zh) * | 2007-10-15 | 2008-03-05 | 北京交通大学 | 一种适用于高速移动终端的数据发送方法及传输设备 |
| CN101252425A (zh) * | 2008-04-09 | 2008-08-27 | 杭州华三通信技术有限公司 | 一种自动适应网络的丢包纠错方法和系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101656597A (zh) | 2010-02-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101656597B (zh) | 数据接收和发送方法、装置及数据传输系统 | |
| US9312989B2 (en) | Importance-based FEC-aware error-repair scheduling | |
| CN101719809B (zh) | 一种媒体数据包丢包恢复的方法及系统 | |
| US8473825B2 (en) | Evolved universal terrestrial radio access acknowledged mode radio link control status report for segmented protocol data units | |
| CN103036904B (zh) | 一种在通信网络中使用udp协议进行数据可靠传输的方法 | |
| EP2437421B1 (en) | Method, device and communication system for retransmitting based on forward error correction | |
| CN102273118B (zh) | 数据重传的方法、装置及系统 | |
| CN106416179A (zh) | 实现扩展传输控制功能的传输加速器 | |
| CN104768081B (zh) | 一种实现流量控制的丢包重传方法 | |
| CN105721950A (zh) | 一种可靠媒体流传输装置 | |
| CN104579601A (zh) | 一种重传请求处理方法和装置 | |
| US8621311B2 (en) | Data transfer device, method, and program | |
| JP2010141413A5 (zh) | ||
| CN106034011A (zh) | 一种组播传输质量保障的控制方法及系统 | |
| CN112350803A (zh) | 数据包的传输方法、装置、系统、电子设备及存储介质 | |
| TWI310911B (en) | Method and apparatus for initiating a storage window in a periodic packet retransmission wireless communications system operated in unacknowledged mode | |
| CN105490773A (zh) | 传输多媒体数据的方法和装置 | |
| WO2006107423A2 (en) | Error recovery mechanism and network element comprising same | |
| CN112804028B (zh) | 一种数据包的传输方法、设备及存储介质 | |
| CN115189813A (zh) | Ott组播方法、系统、装置、组播代理和组播服务器 | |
| CN117040692A (zh) | 一种业务数据传输的方法及装置、电子设备、存储介质 | |
| US7100078B1 (en) | Method and apparatus for restoration of lost blocks in a multicast data transmission | |
| US10721171B2 (en) | Data transfer system and corresponding methods | |
| Sinha et al. | An adaptive multiple retransmission technique for continuous media streams | |
| CN102209240A (zh) | 运动图像发送装置、发送系统、发送方法和程序 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| C41 | Transfer of patent application or patent right or utility model | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20160518 Address after: 518057, A building, Zhongxing building, Nanshan District science and Technology Park, Shenzhen, Guangdong, five Patentee after: Shenzhen wisdom Technology Co., Ltd. Address before: 518057 Nanshan District Guangdong high tech Industrial Park, South Road, science and technology, ZTE building, Ministry of Justice Patentee before: ZTE Corporation |
|
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20130911 Termination date: 20170914 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |