CN110602452B - 一种保障全球udp音视频流远距离实时传输流畅的方法 - Google Patents

一种保障全球udp音视频流远距离实时传输流畅的方法 Download PDF

Info

Publication number
CN110602452B
CN110602452B CN201910835003.XA CN201910835003A CN110602452B CN 110602452 B CN110602452 B CN 110602452B CN 201910835003 A CN201910835003 A CN 201910835003A CN 110602452 B CN110602452 B CN 110602452B
Authority
CN
China
Prior art keywords
packet
audio
readback
video
packets
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.)
Active
Application number
CN201910835003.XA
Other languages
English (en)
Other versions
CN110602452A (zh
Inventor
余涛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Miluoxing Technology Group Co ltd
Original Assignee
Hangzhou Miluoxing Technology Group Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hangzhou Miluoxing Technology Group Co ltd filed Critical Hangzhou Miluoxing Technology Group Co ltd
Priority to CN201910835003.XA priority Critical patent/CN110602452B/zh
Publication of CN110602452A publication Critical patent/CN110602452A/zh
Application granted granted Critical
Publication of CN110602452B publication Critical patent/CN110602452B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/64784—Data processing by the network
    • H04N21/64792—Controlling the complexity of the content stream, e.g. by dropping packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/18—Closed-circuit television [CCTV] systems, i.e. systems in which the video signal is not broadcast

Abstract

本发明公开了一种保障全球UDP音视频流远距离实时传输流畅的方法。它通过自定义传输协议、动态采集传输链路丢包率、动态分组、实时转发编码策略，动态开启FEC，动态确定冗余度、分组大小，保证传输实时性，在保证音视频传输流畅的前提下，节省网络带宽的使用，提升用户的跨国音视频通话体验。本发明的有益效果是：抗弱网、抗网络抖动效果更佳，经过实际测试，在30％的网络丢包率的情况下，音视频基本流畅，在网络良好的情况不会产生冗余包，不会浪费网络带宽，完全兼容NACK，可以同时生效，自定义的传输协议不关心底层音视频使用什么传输协议，兼容目前所有基于UDP的音视频传输协议。

Description

一种保障全球UDP音视频流远距离实时传输流畅的方法
技术领域
本发明涉及音视频网络传输相关技术领域，尤其是指一种保障全球UDP音视频流远距离实时传输流畅的方法。
背景技术
在全球一体化的今天，全球音视频流远距离实时传输有着广泛的应用场景：比如跨国教育、跨国会议、跨国直播等场景。在上述应用场景，音视频的流畅度与实时性在很大程度上影响着用户体验，而跨国网络通常不是很稳定容易丢包，因此对于跨国音视频服务供应商来说，需要找到一种方法来保障跨国音视频传输流畅度与实时性。
目前音视频网络传输领域对抗UDP丢包的方法主要有两种：NACK与FEC。NACK：丢包重传，接收端根据接收到的音视频包的序列号，计算出哪些包没有收到，然后告诉发送端重新发送丢掉的音视频包。FEC：前向纠错，在发送端产生一些冗余包，这样即使传输的过程中丢掉一些原始包，后续收到冗余包也可以把原始包恢复出来。
在跨国传输的场景中，由于RTT比较大，300-400ms都是正常的，NACK显然并不适用于此，如果发生丢包，即使在最理想的情况下，第二次重传就成功，接收端收到重传包也需要1.5个RTT，如果丢掉的是视频关键帧的包，卡顿已经发生，如果通过增加接收端音视频包缓冲区的大小来避免卡顿的话，实时性就得不到保证，进而影响通话体验。而FEC就比较适合这种场景了，假设我们把10个包分为一组，然后每组产生一个冗余包，这样在平均丢包率为10％的情况下，每组丢一个包，我们也能通过多出来的一个冗余包来恢复丢掉的包，如果丢掉的包正好是冗余包就不用恢复了。看起来很美好，但是FEC方案还有一些问题需要我们解决：一，我们应该如何确认冗余度？在现实网络中，丢包率不是一成不变的，上一秒是10％，下一秒就可能30％了；二，我们应该把多少个数据包分为一组？如果一组的包数量太大了，会导致恢复原始包的时间过长，同样会导致卡顿；三，我们应该如何编码才能保证实时性？我们不可能在发送端等一组数据包全部收集到以后，再计算出冗余包，然后再一起发送出去。
发明内容
本发明是为了克服现有技术中存在上述的不足，提供了一种保证传输实时性和流畅性的保障全球UDP音视频流远距离实时传输流畅的方法。
为了实现上述目的，本发明采用以下技术方案：
一种保障全球UDP音视频流远距离实时传输流畅的方法，具体包括如下步骤：
(1)通过传输链路丢包率采集模块采集传输链路的丢包率，接收端每秒统计一次，然后告诉发送端，发送端收到接收端反馈的丢包率，决定是否开启FEC策略，以及确定分组大小和冗余度的大小；
(2)在有丢包率的情况下，发送端每需要传送一个RTP包，都把这个RTP包包装成redpacket，设置好redpacket的包头，实时发送给接收端，然后用一个编码组存储发出去的redpacket，当达到FEC策略的分组大小条件的时候，立马采用reed-solomon算法进行编码，通过编码组里面存储的redpacket包，得到几个冗余包，然后把冗余包包装成fecpacket；
(3)在接收端，收到redpacket的时候，把redpacket里面真正的RTP音视频包转发给需要的下一级，然后通过比对redpacket和fecpacket来确定是否需要解码。
本发明通过自定义传输协议、动态采集传输链路丢包率、动态分组、实时转发编码策略，动态开启FEC，动态确定冗余度、分组大小，保证传输实时性，在保证音视频传输流畅的前提下，节省网络带宽的使用，提升用户的跨国音视频通话体验。与传统跨国音视频传输抗丢包方案相比，本发明的优势如下：抗弱网、抗网络抖动效果更佳，经过实际测试，在30％的网络丢包率的情况下，音视频基本流畅，本方案在网络良好的情况不会产生冗余包，不会浪费网络带宽，本方案完全兼容NACK，可以同时生效，自定义的传输协议不关心底层音视频使用什么传输协议，兼容目前所有基于UDP的音视频传输协议。
作为优选，在步骤(1)中，采集传输链路的丢包率包括以下两种情况：(11)在没有开启FEC策略的时候，统计的是RTP包的丢包率，故可以通过SequenceNum来计算；(12)当开启FEC策略的时候，需要同时考虑原始RTP包与冗余包来计算丢包率。
作为优选，在步骤(1)中，开启FEC策略的条件如下：当发送端收到比上一次更高的丢包率反馈时，立即更新，并记下更新时间；反之，不立即更新，只有当本次反馈的丢包率与上一次更新时间相差超过2分钟的时候才更新。
作为优选，在步骤(1)中，FEC策略的分组大小以及冗余度大小的确定如下：根据音视频的帧数和一个固定值来决定，通过RTP包头的MAKER位可知这个包是一帧的结尾还是开头，按每6帧或者每10个包来分组，当达到其中任何一个条件的时候，分组大小就确定了，然后根据之前的丢包率，就可以计算出需要多少个冗余包。
作为优选，在步骤(2)中，redPacket是自定义传输协议，redPacket依次包括tag、gId、esi、pt、pl、payload，
tag：一个字节，redpakcet包标记，用来标记这个是redpacket；
gId：一个字节，groupId，标记这个redpacket属于哪一个编码组；
esi：一个字节，encodingSymbolIndex，标记这个redpacket在一个编码组组中的下标；
pt：一个字节，payloadType，标记负载的类型；
pl：两个字节，payloadLength，标记负载的长度；
payload：负载，大小为pl，装载音视频原始包。
作为优选，在步骤(2)中，fecPacket是自定义传输协议，fecPacket依次包括tag、gId、esi、pt、k、n、esl、payload，
tag：一个字节，fecpacket包标记，用来标记这个是fecpacket；
gId：一个字节，groupId，标记这个fecpacket属于哪一个编码组；
esi：一个字节，encodingSymbolIndex，标记这个fecpacket在一个编码组组中的下标；
pt：一个字节，payloadType，标记负载的类型；
k：一个字节，标记这个编码组中redpacket的个数；
n：一个字节，标记这个编码组中redpacket与fecpacket的总个数；
esl：两个字节，encodingSymbolLength，编码长度，设置编解码器参数的时候会用到；
payload：负载，大小就是esl，装载编码器产生的冗余包。
作为优选，在步骤(2)中，在fecpacket中k为队列里面redpacket的个数，n为k加上冗余包的个数，esl为队列里面redpacket最长那个包的长度，接收端那边只需要收到总和为k个的redpacket和fecpacket就可以恢复出所有的redpacket。
作为优选，在步骤(3)中，具体操作如下：在接收端，收到redpacket的时候，立马可以把payload里面真正的RTP音视频包转发给需要的下一级，然后根据redpacket的gId先存储着，当收到gId相同的fecpacket就可以看看是否可以解码，如果发现这个分组的存储队列里面的redpacket个数和fecpacket包头的k值一样，说明该分组的原始包全部收到，不需要进行解码；否则需要等到这个分组的存储队列的redpacket和fecpacket个数总和为k的时候，才能进行解码。
作为优选，在步骤(3)中，通过fecpacket包头里面的k、n、esl设置好解码器参数，然后按照redpacket和fecpacket包头里面的esi设置好各自在解码器分组的位置好，就可以进行解码；恢复出所有的redpacket以后，把没有转发过的RTP包取出来转发给下一级。
作为优选，在步骤(3)中，如果没有办法进行解码就放弃，这里最多维持10个分组的缓存，达到分组缓存上限以后，就把老的清理掉。
本发明的有益效果是：抗弱网、抗网络抖动效果更佳，经过实际测试，在30％的网络丢包率的情况下，音视频基本流畅，在网络良好的情况不会产生冗余包，不会浪费网络带宽，完全兼容NACK，可以同时生效，自定义的传输协议不关心底层音视频使用什么传输协议，兼容目前所有基于UDP的音视频传输协议。
具体实施方式
下面结合具体实施方式对本发明做进一步的描述。
一种保障全球UDP音视频流远距离实时传输流畅的方法，具体包括如下步骤：
(1)通过传输链路丢包率采集模块采集传输链路的丢包率，采集传输链路的丢包率包括以下两种情况：(11)在没有开启FEC策略的时候，统计的是RTP包的丢包率，故可以通过SequenceNum来计算；(12)当开启FEC策略的时候，需要同时考虑原始RTP包与冗余包来计算丢包率，比如在一个分组里面，原始包一个没有丢，但是冗余包丢掉了几个，如果还是统计RTP包的丢包率，这个时候丢包率为0，这样统计是有误差的。接收端每秒统计一次，然后告诉发送端，发送端收到接收端反馈的丢包率，决定是否开启FEC策略，以及确定分组大小和冗余度的大小。
由于网络的丢包率不稳定，所以我们不能实时采用接收端反馈的丢包率，故开启FEC策略的条件如下：当发送端收到比上一次更高的丢包率反馈时，立即更新，并记下更新时间；反之，不立即更新，只有当本次反馈的丢包率与上一次更新时间相差超过2分钟的时候才更新，这样可以有效的抵抗丢包率抖动，但是付出的带宽会高一些。至于FEC策略的分组大小以及冗余度大小的确定如下：需要同时考虑实时性与卡顿，这样就不能固定死几个包，因为在码率低的情况下，一个包就是一个视频帧，如果中间原始包丢了几个，就算后续通过冗余包恢复出来了，也会因为包乱序的情况严重，导致卡顿，所以我们可以根据音视频的帧数和一个固定值来决定，通过RTP包头的MAKER位可知这个包是一帧的结尾还是开头，按每6帧或者每10个包来分组，当达到其中任何一个条件的时候，分组大小就确定了，然后根据之前的丢包率，就可以计算出需要多少个冗余包。
(2)在有丢包率的情况下，发送端每需要传送一个RTP包，都把这个RTP包包装成redpacket，设置好redpacket的包头，实时发送给接收端，然后用一个编码组存储发出去的redpacket，当达到FEC策略的分组大小条件(即6帧或者10个包)的时候，立马采用reed-solomon算法进行编码，通过编码组里面存储的redpacket包，得到几个冗余包，然后把冗余包包装成fecpacket。
redPacket和fecpacket均是自定义传输协议，如下：
tag gld esi pt pl payload
RedPakcet
tag gld esl pt k n <u>esl</u> payload
FecPakcet
其中，redPacket依次包括tag、gId、esi、pt、pl、payload，
tag：一个字节，redpakcet包标记，用来标记这个是redpacket；
gId：一个字节，groupId，标记这个redpacket属于哪一个编码组；
esi：一个字节，encodingSymbolIndex，标记这个redpacket在一个编码组组中的下标；
pt：一个字节，payloadType，标记负载的类型；
pl：两个字节，payloadLength，标记负载的长度；
payload：负载，大小为pl，装载音视频原始包。
其中，fecPacket依次包括tag、gId、esi、pt、k、n、esl、payload，
tag：一个字节，fecpacket包标记，用来标记这个是fecpacket；
gId：一个字节，groupId，标记这个fecpacket属于哪一个编码组；
esi：一个字节，encodingSymbolIndex，标记这个fecpacket在一个编码组组中的下标；
pt：一个字节，payloadType，标记负载的类型；
k：一个字节，标记这个编码组中redpacket的个数；
n：一个字节，标记这个编码组中redpacket与fecpacket的总个数；
esl：两个字节，encodingSymbolLength，编码长度，设置编解码器参数的时候会用到；
payload：负载，大小就是esl，装载编码器产生的冗余包。
在fecpacket中k为队列里面redpacket的个数，n为k加上冗余包的个数，esl为队列里面redpacket最长那个包的长度，接收端那边只需要收到总和为k个的redpacket和fecpacket就可以恢复出所有的redpacket。
(3)在接收端，收到redpacket的时候，把redpacket里面真正的RTP音视频包转发给需要的下一级，然后通过比对redpacket和fecpacket来确定是否需要解码。
具体操作如下：在接收端，收到redpacket的时候，立马可以把payload里面真正的RTP音视频包转发给需要的下一级，然后根据redpacket的gId先存储着，当收到gId相同的fecpacket就可以看看是否可以解码，如果发现这个分组的存储队列里面的redpacket个数和fecpacket包头的k值一样，说明该分组的原始包全部收到，不需要进行解码；否则需要等到这个分组的存储队列的redpacket和fecpacket个数总和为k的时候，才能进行解码。通过fecpacket包头里面的k、n、esl设置好解码器参数，然后按照redpacket和fecpacket包头里面的esi设置好各自在解码器分组的位置好，就可以进行解码；恢复出所有的redpacket以后，把没有转发过的RTP包取出来转发给下一级。如果没有办法进行解码就放弃，这里最多维持10个分组的缓存，达到分组缓存上限以后，就把老的清理掉。
本发明通过自定义传输协议、动态采集传输链路丢包率、动态分组、实时转发编码策略，动态开启FEC，动态确定冗余度、分组大小，保证传输实时性，在保证音视频传输流畅的前提下，节省网络带宽的使用，提升用户的跨国音视频通话体验。与传统跨国音视频传输抗丢包方案相比，本发明的优势如下：抗弱网、抗网络抖动效果更佳，经过实际测试，在30％的网络丢包率的情况下，音视频基本流畅，本方案在网络良好的情况不会产生冗余包，不会浪费网络带宽，本方案完全兼容NACK，可以同时生效，自定义的传输协议不关心底层音视频使用什么传输协议，兼容目前所有基于UDP的音视频传输协议。

Claims (7)

1.一种保障全球UDP音视频流远距离实时传输流畅的方法，其特征是，具体包括如下步骤：
（1）通过传输链路丢包率采集模块采集传输链路的丢包率，接收端每秒统计一次，然后告诉发送端，发送端收到接收端反馈的丢包率，决定是否开启FEC策略，以及确定分组大小和冗余度的大小；
（2）在有丢包率的情况下，发送端每需要传送一个RTP包，都把这个RTP包包装成redpacket，设置好redpacket的包头，实时发送给接收端，然后用一个编码组存储发出去的redpacket，当达到FEC策略的分组大小条件的时候，立马采用reed-solomon算法进行编码，通过编码组里面存储的redpacket包，得到几个冗余包，然后把冗余包包装成fecpacket；
其中：redPacket是自定义传输协议，redPacket依次包括tag、gId、esi、pt、pl、payload，
tag：一个字节，redpakcet包标记，用来标记这个是redpacket；
gId：一个字节，groupId，标记这个redpacket属于哪一个编码组；
esi：一个字节，encodingSymbolIndex，标记这个redpacket在一个编码组组中的下标；
pt：一个字节，payloadType，标记负载的类型；
pl：两个字节，payloadLength，标记负载的长度；
payload：负载，大小为pl，装载音视频原始包；
其中：fecPacket是自定义传输协议，fecPacket依次包括tag、gId、esi、pt、k、n、esl 、payload，
tag：一个字节，fecpacket包标记，用来标记这个是fecpacket；
gId：一个字节，groupId，标记这个fecpacket属于哪一个编码组；
esi：一个字节，encodingSymbolIndex，标记这个fecpacket在一个编码组组中的下标；
pt：一个字节，payloadType，标记负载的类型；
k：一个字节，标记这个编码组中redpacket的个数；
n：一个字节，标记这个编码组中redpacket与fecpacket的总个数；
esl：两个字节，encodingSymbolLength，编码长度，设置编解码器参数的时候会用到；
payload：负载，大小就是esl，装载编码器产生的冗余包；
（3）在接收端，收到redpacket的时候，把redpacket里面真正的RTP音视频包转发给需要的下一级，然后通过比对redpacket和fecpacket来确定是否需要解码；具体操作如下：在接收端，收到redpacket的时候，立马可以把payload里面真正的RTP音视频包转发给需要的下一级，然后根据redpacket的gId先存储着，当收到gId相同的fecpacket就可以看看是否可以解码，如果发现这个分组的存储队列里面的redpacket个数和fecpacket包头的k值一样，说明该分组的原始包全部收到，不需要进行解码；否则需要等到这个分组的存储队列的redpacket和fecpacket个数总和为k的时候，才能进行解码。
2.根据权利要求1所述的一种保障全球UDP音视频流远距离实时传输流畅的方法，其特征是，在步骤（1）中，采集传输链路的丢包率包括以下两种情况：（11）在没有开启FEC策略的时候，统计的是RTP包的丢包率，故可以通过SequenceNum来计算；（12）当开启FEC策略的时候，需要同时考虑原始RTP包与冗余包来计算丢包率。
3.根据权利要求1或2所述的一种保障全球UDP音视频流远距离实时传输流畅的方法，其特征是，在步骤（1）中，开启FEC策略的条件如下：当发送端收到比上一次更高的丢包率反馈时，立即更新，并记下更新时间；反之，不立即更新，只有当本次反馈的丢包率与上一次更新时间相差超过2分钟的时候才更新。
4.根据权利要求1或2所述的一种保障全球UDP音视频流远距离实时传输流畅的方法，其特征是，在步骤（1）中，FEC策略的分组大小以及冗余度大小的确定如下：根据音视频的帧数和一个固定值来决定，通过RTP包头的MAKER位可知这个包是一帧的结尾还是开头，按每6帧或者每10个包来分组，当达到其中任何一个条件的时候，分组大小就确定了，然后根据之前的丢包率，就可以计算出需要多少个冗余包。
5.根据权利要求1所述的一种保障全球UDP音视频流远距离实时传输流畅的方法，其特征是，在步骤（2）中，在fecpacket中k为队列里面redpacket的个数，n为k加上冗余包的个数，esl为队列里面redpacket最长那个包的长度，接收端那边只需要收到总和为k个的redpacket和fecpacket就可以恢复出所有的redpacket。
6.根据权利要求1所述的一种保障全球UDP音视频流远距离实时传输流畅的方法，其特征是，在步骤（3）中，通过fecpacket包头里面的k、n、esl设置好解码器参数，然后按照redpacket和fecpacket包头里面的esi设置好各自在解码器分组的位置好，就可以进行解码；恢复出所有的redpacket以后，把没有转发过的RTP包取出来转发给下一级。
7.根据权利要求1或6所述的一种保障全球UDP音视频流远距离实时传输流畅的方法，其特征是，在步骤（3）中，如果没有办法进行解码就放弃，这里最多维持10个分组的缓存，达到分组缓存上限以后，就把老的清理掉。
CN201910835003.XA 2019-09-05 2019-09-05 一种保障全球udp音视频流远距离实时传输流畅的方法 Active CN110602452B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910835003.XA CN110602452B (zh) 2019-09-05 2019-09-05 一种保障全球udp音视频流远距离实时传输流畅的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910835003.XA CN110602452B (zh) 2019-09-05 2019-09-05 一种保障全球udp音视频流远距离实时传输流畅的方法

Publications (2)

Publication Number Publication Date
CN110602452A CN110602452A (zh) 2019-12-20
CN110602452B true CN110602452B (zh) 2020-12-25

Family

ID=68857562

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910835003.XA Active CN110602452B (zh) 2019-09-05 2019-09-05 一种保障全球udp音视频流远距离实时传输流畅的方法

Country Status (1)

Country Link
CN (1) CN110602452B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115278376B (zh) * 2022-05-25 2024-03-22 西安万像电子科技有限公司 一种音视频数据传输方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103957222A (zh) * 2014-05-20 2014-07-30 艾诺通信系统（苏州）有限责任公司 一种基于fec算法的视频传输自适应方法
CN106656422A (zh) * 2017-01-03 2017-05-10 珠海全志科技股份有限公司 一种动态调整fec冗余度的流媒体传输方法
CN107483144A (zh) * 2016-06-07 2017-12-15 中兴通讯股份有限公司 前向纠错反馈信息传输方法、装置
CN108616328A (zh) * 2016-12-12 2018-10-02 北京视联动力国际信息技术有限公司 一种音视频流丢包恢复方法及音视频流发送端和接收端
CN109412753A (zh) * 2018-10-25 2019-03-01 网易（杭州）网络有限公司 数据传输方法及装置、电子设备以及存储介质
CN109862440A (zh) * 2019-02-22 2019-06-07 深圳市凯迪仕智能科技有限公司 音视频传输前向纠错方法、装置、计算机设备及存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101686106B (zh) * 2008-09-28 2013-04-17 华为技术有限公司 自适应前向纠错的方法、装置和系统
EP3119022B1 (en) * 2012-07-09 2018-06-13 Telefonaktiebolaget LM Ericsson (publ) Method and arrangement for distributing information during broadcast delivery
JP6443173B2 (ja) * 2015-03-27 2018-12-26 富士通株式会社 映像データ処理装置、映像データ処理システム、映像データ処理方法、及び、映像データ処理プログラム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103957222A (zh) * 2014-05-20 2014-07-30 艾诺通信系统（苏州）有限责任公司 一种基于fec算法的视频传输自适应方法
CN107483144A (zh) * 2016-06-07 2017-12-15 中兴通讯股份有限公司 前向纠错反馈信息传输方法、装置
CN108616328A (zh) * 2016-12-12 2018-10-02 北京视联动力国际信息技术有限公司 一种音视频流丢包恢复方法及音视频流发送端和接收端
CN106656422A (zh) * 2017-01-03 2017-05-10 珠海全志科技股份有限公司 一种动态调整fec冗余度的流媒体传输方法
CN109412753A (zh) * 2018-10-25 2019-03-01 网易（杭州）网络有限公司 数据传输方法及装置、电子设备以及存储介质
CN109862440A (zh) * 2019-02-22 2019-06-07 深圳市凯迪仕智能科技有限公司 音视频传输前向纠错方法、装置、计算机设备及存储介质

Also Published As

Publication number Publication date
CN110602452A (zh) 2019-12-20

Similar Documents

Publication Publication Date Title
CN108183774B (zh) 一种流媒体传输的前向纠错方法和系统
CN101061659B (zh) 自适应前向纠错的方法和设备
US9246630B2 (en) Method, device, and system for forward error correction
US8711884B2 (en) Data communication system, data transmitting apparatus, data transmitting method, and method for determining packet size and redundancy
EP2437421B1 (en) Method, device and communication system for retransmitting based on forward error correction
US7889654B2 (en) Loss tolerant transmission control protocol
WO2006105713A1 (en) Video transmission protection method based on h.264
US20060150055A1 (en) Adaptive information delivery system using FEC feedback
US20050013249A1 (en) Redundant packets for streaming video protection
US20080225735A1 (en) Reducing effects of packet loss in video transmissions
US20060251010A1 (en) Loss tolerant transmission control protocol
US8335516B2 (en) Method and apparatus for transmitting data in wireless network
CN108174234A (zh) 一种流媒体传输方法及系统
JP2020502832A (ja) データストリーミングの前方誤り訂正
CN106911699B (zh) 一种基于rtp协议实现i帧重传的方法
US20060250949A1 (en) Loss tolerant transmission control protocol
CN111787413B (zh) 流媒体数据传输方法、系统、发送装置及接收装置
CN108696491B (zh) 音频数据的发送处理方法与装置、接收处理方法与装置
CN114337928A (zh) 一种基于arq与fec自适应选择的实时视频传输方法
CN1611027A (zh) 采用基于理德－所罗门码的前向纠错的不均等差错保护
CN110602452B (zh) 一种保障全球udp音视频流远距离实时传输流畅的方法
Gasiba et al. System design and advanced receiver techniques for MBMS broadcast services
US20180091406A1 (en) User defined protocol for self correcting zero-added-jitter transmission of layer-2 datagrams across one-way lossy packet-switched network links
CN101662339A (zh) 一种对前向纠错恢复的数据进行校验的方法及装置
CN101645903A (zh) 一种多媒体数据的传输方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant