CN1917639A - 使用丢包重传的视频信号增强方法 - Google Patents
使用丢包重传的视频信号增强方法 Download PDFInfo
- Publication number
- CN1917639A CN1917639A CN 200610112807 CN200610112807A CN1917639A CN 1917639 A CN1917639 A CN 1917639A CN 200610112807 CN200610112807 CN 200610112807 CN 200610112807 A CN200610112807 A CN 200610112807A CN 1917639 A CN1917639 A CN 1917639A
- Authority
- CN
- China
- Prior art keywords
- rtp
- packet
- rtp packet
- video reception
- transmission
- 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
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种对视频信号使用丢包重传的增强方法,包括如下步骤:视频发送端将每次产生的RTP数据包发送,并放入历史缓冲区;接收端判断此次接收的RTP数据包之前是否有丢包现象,若无丢包现象,则该RTP数据包放入RTP链表组帧,反之,向发送端发出重传请求;发送端收到重传请求后,补发需重传的所有RTP数据包;接收端收到补发的RTP数据包后,将其放入RTP链表组帧;若接收端再次收到相同RTP数据包,则产生一重传失误报告;接收端检测到该报告后,暂停重传RTP数据包,并通知上层应用程序采取措施解决。本发明采取丢包重传与重传抑制措施解决了视频信号的丢包问题,实现了画面的连贯播放,消除了停顿现象,抑制了网络堵塞现象,且视频数据能够被完整存储。
Description
技术领域
本发明涉及一种视频信号增强方法,具体地说,是涉及一种基于RTP/RTCP协议、使用丢包重传的视频信号增强方法。
背景技术
对于因特网多媒体数据流的传输,目前公知的协议有RTP协议(实时传输协议)和RTCP协议(实时传输控制协议)。RTP协议的目的是实现多媒体数据流的同步传输,并提供多媒体数据流的传输时间信息。而RTCP协议主要提供流量控制、拥塞控制,负责当前应用进程之间的控制信息的交换与管理。在会话期间,各应用进程之间周期性地传送RTCP包,RTCP包主要包含已发送数据包的数量、丢失数据包的数量等统计信息。通过RTCP包中的控制信息,各发送端便可以动态改变传输速率等参数,甚至改变有效载荷的类型。所以,RTP协议与RTCP协议配合使用,可以将有用信息即时反馈,使传输开销最小化,传输效率最佳,且这种RTP协议与RTCP协议特别适用于网上数据的实时传输。
但是,在RTP协议与RTCP协议下,如果视频数据流在传输过程中发生了丢包,则视频画面往往会出现停顿现象,致使画面播放不连贯,且必须等到下一个关键帧到达客户端后,视频画面才能够继续播放,使得观看人员无法在第一时间看到监控画面。
对于重要场所的视频监控来说,视频信息还应该进行完整保存,以备日后检索。而这种传输过程中因丢包引起的视频数据的间断,则很可能会使视频信息无法完整保存,这样会给以后的信息检索带来不便。
发明内容
本发明的目的是提供一种使用丢包重传的视频信号增强方法,该方法不改变原有的RTP/RTCP协议,而是在RTP/RTCP协议的基础上进行改进,来解决视频信号在传输过程中的丢包问题,从而提高视频信号传输质量。
为此,本发明采用以下技术方案:
一种使用丢包重传的视频信号增强方法,其特征在于它包括如下步骤:
a)视频信号发送端将每次产生的一个RTP数据包发送到视频信号接收端后,将该RTP数据包放入历史缓冲区;
b)视频信号接收端接收视频信号发送端传输的RTP数据包,并判断此次传送的RTP数据包之前是否有丢包现象,如果判断结果为没有发生丢包现象,则视频信号接收端将该RTP数据包放入RTP链表,并进行组帧,不向视频信号发送端发出重传请求,否则,视频信号接收端将该RTP数据包放入RTP链表,但不进行组帧,而向视频信号发送端发出重传请求;
c)视频信号发送端收到视频信号接收端发出的重传请求后,补发所请求重传的所有RTP数据包;
d)视频信号接收端收到补发的RTP数据包后,将RTP数据包放入RTP链表,并进行组帧;
e)若视频信号接收端再次收到视频信号发送端补发的RTP数据包,则产生一个重传失误的报告;
f)若视频信号接收端检测到重传失误的报告产生,则暂停RTP数据包的重传,并通知上层应用程序,由上层应用程序采取措施解决各异常状况。
在所述步骤b)中,判断RTP数据包是否有丢包现象的方法为判断此次收到的RTP数据包与前一次收到的RTP数据包之间的RTP序列号间隔N是否大于1,若N大于1,则发生丢包现象,且丢失RTP数据包的数量为(N-1)个。
在所述步骤f)中,上层应用程序的解决措施有两种:
一种是视频信号接收端向视频信号发送端通过RTCP协议发出严重错误警告,视频信号发送端收到严重错误警告后,降低视频数据的流量,从而在数据发送源端消除网络堵塞异常状况。
另外一种是视频信号接收端向客户端发出带宽不足的警报,从而使用户停止RTP会话或采取其他方式来消除网络堵塞异常状况。
本发明适用于一视频信号发送端到一视频信号接收端的数据流单播方式,也适用于一视频信号发送端到多视频信号接收端的数据流多播方式。其中,多播方式中的丢包重传方式采用单播方式。
本发明的优点是:由于在RTP/RTCP协议的基础上采用了丢包重传措施来解决视频信号传输过程中的丢包问题,从而实现了视频画面的连贯播放,消除了停顿现象,且视频数据能够被完整存储。另外,通过判断视频信号接收端收到相同RTP数据包的数量,便可以检测出此刻网络堵塞程度,进而通过重传失误报告通知上层应用程序采取相应重传抑制措施来解决网络堵塞现象。
附图说明
图1是本发明的流程图。
图2是本发明实施例的实施流程示意图。
具体实施方式
参阅图1,本发明为一种对视频信号使用丢包重传的增强方法,它包括如下步骤:
a)视频信号发送端将每次产生的一个RTP数据包发送到视频信号接收端后,再将该RTP数据包放入历史缓冲区;
b)视频信号接收端接收视频信号发送端传输的RTP数据包,并判断此次传送的RTP数据包之前是否有丢包现象,如果判断结果为没有发生丢包现象,则视频信号接收端将该RTP数据包放入RTP链表,并进行组帧,不向视频信号发送端发出重传请求,否则,视频信号接收端将该RTP数据包放入RTP链表,但不进行组帧,而是向视频信号发送端发出重传请求;
c)视频信号发送端收到视频信号接收端发出的重传请求后,补发所请求重传的所有RTP数据包;
d)视频信号接收端收到补发的RTP数据包后,将RTP数据包放入RTP链表,并进行组帧;
e)若视频信号接收端再次收到视频信号发送端补发过的RTP数据包,则产生一个重传失误的报告;
f)若视频信号接收端检测到重传失误的报告产生,则暂停RTP数据包的重传,并通知上层应用程序,由上层应用程序采取措施解决各异常状况。
在所述步骤b)中,判断RTP数据包是否有丢包现象的方法为判断此次收到的RTP数据包与前一次收到的RTP数据包之间的RTP序列号间隔N是否大于1,若N大于1,则发生丢包现象,且丢失RTP数据包的数量为(N-1)个。
在所述步骤f)中,上层应用程序的解决措施有两种:
一种是视频信号接收端向视频信号发送端通过RTCP协议发出严重错误警告,视频信号发送端收到严重错误警告后,降低视频数据的流量,从而在数据发送源端消除网络堵塞异常状况。
另外一种是视频信号接收端向客户端发出带宽不足的警报,从而使用户停止RTP会话或采取其他方式来消除网络堵塞异常状况。
对于步骤e)中所遇到的连续接收到两次相同的RTP数据包现象,是由于RTP数据包错序到达,即UDP“后发先到”,视频信号接收端误判丢包而要求发送端重传RTP数据包所产生的。视频信号接收端收到的两个相同的RTP数据包分别为因重传而首先接收到的RTP数据包和因先发后到缘故迟到的RTP数据包。收到两次相同的RTP数据包的现象发生得越频繁,就表明网络越拥塞,因此视频接收端检测相同RTP数据包的收到次数可以用来衡量网络堵塞的状况。但这种现象一般只发生在Internet路由发生变动、网络节点堵塞的情况下,一般来说WAN的路由结构是稳定不变的,不会发生这种现象。
当网络处于带宽极差,堵塞现象比较严重的情况下时,即使将丢失的RTP数据包重传,也不能将重传的RTP数据包成功地送达到视频信号接收端。因此,当一次检测到丢失RTP数据包的数量大于1个时,也可以不进行重传请求,即以牺牲QoS(网络服务质量)性能来减少数据传输量,从而减小RTP数据包重传的响应时间。同样,也可以针对RTP数据包的序列号间隔N来设置重传门限,从而折衷QoS与RTP数据包重传的响应时间两个指标。
请参阅图2所示本发明的一个应用实例。其中:IP摄像机和PC为视频监控系统中的流媒体传输子系统的两个组成部分,IP摄像机是视频信号发送端,PC是视频信号接收端。IP摄像机到PC的视频信号传输的实现步骤如下:
1)IP摄像机启动,同时建立数据发送、数据接收、数据监听、RTP历史缓冲等单元;
2)IP摄像机捕获视频数据;
3)IP摄像机进行视频编码;
4)IP摄像机将编码后的数据组装成RTP数据包发送给PC;
5)同时,IP摄像机将该RTP数据包存入RTP历史缓冲单元中;
6)PC接收RTP数据包;
7)当PC连续接收RTP数据包的序列号间隔N大于1且小于6时,则认为有丢包现象,例如连续接收到的RTP数据包序列号为12及15,间隔N大于1且小于6,则认为序列号为13、14的RTP数据包丢失,且丢包数量为2;
8)PC发送关于序列号为13、14的数据包的丢包信息给IP摄像机的数据监听单元,完成丢包反馈,所发送的丢包信息主要包括最先丢失的RTP数据包的序列号和连续丢包数量两个数据信息;
9)IP摄像机收到丢包反馈的信息后,提取最先丢失的RTP数据包的序列号和连续丢包数量两个数据信息,以进行丢包查询,即从RTP历史缓冲单元中提取历史RTP数据包;
10)IP摄像机将所丢失的RTP数据包重新发送给PC;
11)PC接收到重传的RTP数据包后,进行重新组帧。
在实际应用中,重传RTP数据包到达视频信号接收端的时间可以达到理论计算理想值。下面进行详细阐述。
假设某一RTP数据包从视频信号发送端发出的时刻为t1,一个RTP数据包从视频信号发送端到视频信号接收端的传输时间为T,而相邻的两个RTP数据包的发送间隔为dt,那么,正常情况下视频信号接收端收到该RTP数据包的时刻为t2,且t2=t1+T。若该RTP数据包丢失,则视频信号接收端在下一个RTP数据包即将发送时,才会判断出该RTP数据包在前一时刻已经丢失,因此视频信号接收端检测出丢包发生的时刻为t2’,且t2’=t1+T+dt。然后,视频信号接收端立即发出重传请求,重传请求到达视频信号发送端的时刻为t3,且t3=t2’+T。视频信号发送端获得重传请求后,从RTP历史缓冲区中找到该RTP数据包,并进行重新发送,则重新发送的RTP数据包到达视频信号接收端的时刻为t4,且t4=t3+T。经换算可得:
t4=t1+3T+dt (1)
考虑到视频信号发送端与接收端的软件开销和延时抖动的影响,式(1)修正为:
t4=t1+3T+dt+S1+S2+D (2)
其中,S1为视频信号发送端的软件开销时间,S2为视频信号接收端的软件开销时间,D为延时抖动所花费的时间。一般,D的平均值可为0。若视频信号发送端与接收端采用高效软件,则可将S1和S2降低到毫秒级。
当一次检测发现丢失RTP数据包的数量N1大于1时,式(2)变为:
t4=t1+3T+N1dt+S1+S2+D (3)
由式(3)得出,视频信号接收端等待重传RTP数据包的时间t4受N1、dt的影响。实际测试表明,N1一般为1,有时为2或3,极少情况超过3,可见t4主要受dt的影响,且dt越大,影响越大。
假设视频传输帧率为F fps(每秒帧数),传输码率为B kbps(每秒千比特数),那么每帧大小S为(F/B)bit。由于每字节为8bit,则有S=F/(B*8)Byte。若每个RTP数据包大小为RTP_Payload Byte,每帧平均有K个RTP数据包,则K=S/RTP_Payload个RTP数据包。经换算可得:
K=F/(B*8*RTP_Payload)
以H.263格式传输视频为例,若帧率F为512fps,以25kbps的传输码率在以太网上传输,则每帧平均有K=512000/(25*8*RTP_Payload)个RTP数据包。由于TCP/IP协议限制所传输的每一数据包的最大字节数为MTU(最大传输单位),为了适应各种宽带带宽的接入,MTU取值为1492Byte。安全起见,去除RTP数据包包头,则RTP_Payload最大为1460Byte,故计算得出K约为2。
由于帧间传送间隔为df=1/25秒,则RTP数据包的发送间隔dt为df/K秒,经换算可得dt=1/(25*K),因此dt=0.02s,即20毫秒。
以N1为1为例,对于Intranet来说,20毫秒对式(2)的影响很大,应有t4≈t1+dt,而对于Internet来说,应有t4≈t1+3T+dt,即视频信号发送端产生一个RTP数据包后,视频信号接收端的等待时间需要大约dt(Intranet情形)或3T+dt(Internet情形)时间。
测试表明,在Intranet网络环境下,dt为20毫秒,实际检测t4平均值为22毫秒,而t4的理论值为20毫秒。在Internet网络环境下,dt为20毫秒,若视频信号的发送端与接收端分别在北京和上海,则T为15毫秒。假设使用ADSL传输视频信号,则实测检测的t4平均值为68毫秒,而t4的理论值为65毫秒。可见,RTP数据包重传达到接收端的速度较快,基本达到了理论计算的理想值,能够满足视频画面连续播放的条件。
本发明适用于一视频信号发送端到一视频信号接收端的数据流单播方式,也适用于一视频信号发送端到多视频信号接收端的数据流多播方式。但需注意,在多播方式下,视频信号发送端对每一视频信号接收端采取一对多同时发送RTP数据包的多播方式,但对于某一视频信号接收端RTP数据包的丢包重传则采用单播方式,以避免重传的RTP数据包被其它视频信号接收端接收到,产生信号误传。
本发明方法不修改RTP/RTCP,只是在它的基础上进行了增强,能以最快的反映速度有效恢复偶尔丢失的数据包,适合视频监控这个特殊的应用环境。
Claims (7)
1、一种使用丢包重传的视频信号增强方法,其特征在于它包括如下步骤:
a)视频信号发送端将每次产生的一个RTP数据包发送到视频信号接收端后,将该RTP数据包放入历史缓冲区;
b)视频信号接收端接收视频信号发送端传输的RTP数据包,并判断此次传送的RTP数据包之前是否有丢包现象,如果判断结果为没有发生丢包现象,则视频信号接收端将该RTP数据包放入RTP链表,并进行组帧,不向视频信号发送端发出重传请求,否则,视频信号接收端将该RTP数据包放入RTP链表,但不进行组帧,而向视频信号发送端发出重传请求;
c)视频信号发送端收到视频信号接收端发出的重传请求后,补发所请求重传的所有RTP数据包;
d)视频信号接收端收到补发的RTP数据包后,将RTP数据包放入RTP链表,并进行组帧;
e)若视频信号接收端再次收到视频信号发送端补发过的RTP数据包,则产生一个重传失误的报告;
f)若视频信号接收端检测到重传失误的报告产生,则暂停RTP数据包的重传,并通知上层应用程序,由上层应用程序采取措施解决各异常状况。
2、如权利要求1所述的使用丢包重传的视频信号增强方法,其特征在于:
所述步骤b)中的判断RTP数据包是否有丢包现象的方法为判断此次收到的RTP数据包与前一次收到的RTP数据包之间的RTP序列号间隔N是否大于1,若N大于1,则发生丢包现象,且丢失RTP数据包的数量为(N-1)个。
3、如权利要求1所述的使用丢包重传的视频信号增强方法,其特征在于:
所述步骤f)中的上层应用程序解决措施为视频信号接收端向视频信号发送端通过RTCP协议发出严重错误警告,视频信号发送端收到严重错误警告后,降低视频数据的流量,从而在数据发送源端消除网络堵塞异常状况。
4、如权利要求1所述的使用丢包重传的视频信号增强方法,其特征在于:
所述步骤f)中的上层应用程序解决措施为视频信号接收端向客户端发出带宽不足的警报,从而使用户停止RTP会话或采取其他方式来消除网络堵塞异常状况。
5、如权利要求1所述的使用丢包重传的视频信号增强方法,其特征在于:
所述步骤适用于一视频信号发送端到一视频信号接收端的数据流单播方式。
6、如权利要求1所述的使用丢包重传的视频信号增强方法,其特征在于:
所述步骤适用于一视频信号发送端到多视频信号接收端的数据流多播方式。
7、如权利要求6所述的使用丢包重传的视频信号增强方法,其特征在于:
所述多播方式中的丢包重传方式采用单播方式。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200610112807 CN1917639A (zh) | 2006-09-01 | 2006-09-01 | 使用丢包重传的视频信号增强方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200610112807 CN1917639A (zh) | 2006-09-01 | 2006-09-01 | 使用丢包重传的视频信号增强方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1917639A true CN1917639A (zh) | 2007-02-21 |
Family
ID=37738510
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 200610112807 Pending CN1917639A (zh) | 2006-09-01 | 2006-09-01 | 使用丢包重传的视频信号增强方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1917639A (zh) |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101742437A (zh) * | 2009-12-11 | 2010-06-16 | 中兴通讯股份有限公司 | 移动视频的通信方法及服务端、服务器 |
WO2010088836A1 (zh) * | 2009-02-09 | 2010-08-12 | 中兴通讯股份有限公司 | 用户数据报协议传输模式下丢包补偿方法与装置 |
CN101849378A (zh) * | 2007-11-01 | 2010-09-29 | 汤姆森特许公司 | 用于流传输可缩放多媒体数据流的方法和装置 |
CN102480618A (zh) * | 2010-11-24 | 2012-05-30 | 中国电信股份有限公司 | 实现h264视频编码格式播放优化的方法及系统 |
US8693333B2 (en) | 2008-10-31 | 2014-04-08 | Huawei Technologies Co., Ltd. | Method, network node and system for suppressing lost packet retransmission |
WO2015000337A1 (zh) * | 2013-07-02 | 2015-01-08 | 华为技术有限公司 | 视频传输方法及设备 |
CN104320490A (zh) * | 2014-11-12 | 2015-01-28 | 深圳市博康系统工程有限公司 | 一种基于sip的断点续传的可靠数据传输方法和系统 |
CN104506287A (zh) * | 2014-12-29 | 2015-04-08 | 重庆邮电大学 | 一种td-lte应急通信下的实时语音通信方法 |
CN106330930A (zh) * | 2016-08-29 | 2017-01-11 | 烽火通信科技股份有限公司 | 基于流媒体丢包二次重传系统及其方法 |
CN106416112A (zh) * | 2015-04-09 | 2017-02-15 | 华为技术有限公司 | 一种数据传输的方法及装置 |
CN106792265A (zh) * | 2017-01-11 | 2017-05-31 | 广州偕作信息科技有限公司 | 一种网络实时流媒体传输方法和系统 |
CN109792444A (zh) * | 2016-09-30 | 2019-05-21 | 网络洞察力知识产权公司 | 实况内容分发系统中的播出缓冲 |
CN110768753A (zh) * | 2018-07-25 | 2020-02-07 | 成都鼎桥通信技术有限公司 | 一种丢包重传方法和系统 |
CN112995685A (zh) * | 2021-02-05 | 2021-06-18 | 杭州朗和科技有限公司 | 数据发送方法及装置、数据接收方法及装置、介质、设备 |
CN113365098A (zh) * | 2021-06-01 | 2021-09-07 | 平安国际智慧城市科技股份有限公司 | 视频帧组装方法、装置、电子设备及存储介质 |
CN114051173A (zh) * | 2021-10-09 | 2022-02-15 | 广州广哈通信股份有限公司 | 一种基于rtp扩展头部的视频帧可靠传输方法、装置及设备 |
CN114422397A (zh) * | 2021-12-27 | 2022-04-29 | 中国电信股份有限公司 | 流媒体通道监测方法、装置、电子设备和可读存储介质 |
CN117834090A (zh) * | 2024-03-06 | 2024-04-05 | 无锡沐创集成电路设计有限公司 | 一种基于rdma的半纠错视频图像透传装置、方法和系统 |
-
2006
- 2006-09-01 CN CN 200610112807 patent/CN1917639A/zh active Pending
Cited By (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101849378A (zh) * | 2007-11-01 | 2010-09-29 | 汤姆森特许公司 | 用于流传输可缩放多媒体数据流的方法和装置 |
US8395990B2 (en) | 2007-11-01 | 2013-03-12 | Thomson Licensing | Method and apparatus for streaming scalable multimedia data streams |
CN101849378B (zh) * | 2007-11-01 | 2013-05-08 | 汤姆森特许公司 | 用于流传输可缩放多媒体数据流的方法和装置 |
US8693333B2 (en) | 2008-10-31 | 2014-04-08 | Huawei Technologies Co., Ltd. | Method, network node and system for suppressing lost packet retransmission |
WO2010088836A1 (zh) * | 2009-02-09 | 2010-08-12 | 中兴通讯股份有限公司 | 用户数据报协议传输模式下丢包补偿方法与装置 |
RU2501172C2 (ru) * | 2009-02-09 | 2013-12-10 | Зте Корпорейшн | Способ и устройство для компенсации потери пакетов в режиме передачи данных по протоколу пользовательских дейтаграмм |
WO2010149003A1 (zh) * | 2009-12-11 | 2010-12-29 | 中兴通讯股份有限公司 | 移动视频的通信方法及服务端、服务器 |
CN101742437A (zh) * | 2009-12-11 | 2010-06-16 | 中兴通讯股份有限公司 | 移动视频的通信方法及服务端、服务器 |
CN101742437B (zh) * | 2009-12-11 | 2013-08-07 | 中兴通讯股份有限公司 | 移动视频的通信方法及服务端、服务器 |
CN102480618B (zh) * | 2010-11-24 | 2015-09-16 | 中国电信股份有限公司 | 实现h264视频编码格式播放优化的方法及系统 |
CN102480618A (zh) * | 2010-11-24 | 2012-05-30 | 中国电信股份有限公司 | 实现h264视频编码格式播放优化的方法及系统 |
CN104284135A (zh) * | 2013-07-02 | 2015-01-14 | 华为技术有限公司 | 视频传输方法及设备 |
WO2015000337A1 (zh) * | 2013-07-02 | 2015-01-08 | 华为技术有限公司 | 视频传输方法及设备 |
CN104320490A (zh) * | 2014-11-12 | 2015-01-28 | 深圳市博康系统工程有限公司 | 一种基于sip的断点续传的可靠数据传输方法和系统 |
CN104506287A (zh) * | 2014-12-29 | 2015-04-08 | 重庆邮电大学 | 一种td-lte应急通信下的实时语音通信方法 |
CN106416112A (zh) * | 2015-04-09 | 2017-02-15 | 华为技术有限公司 | 一种数据传输的方法及装置 |
CN106416112B (zh) * | 2015-04-09 | 2019-11-05 | 华为技术有限公司 | 一种数据传输的方法及装置 |
CN106330930A (zh) * | 2016-08-29 | 2017-01-11 | 烽火通信科技股份有限公司 | 基于流媒体丢包二次重传系统及其方法 |
CN109792444B (zh) * | 2016-09-30 | 2022-11-15 | 网络洞察力知识产权公司 | 实况内容分发系统中的播出缓冲 |
CN109792444A (zh) * | 2016-09-30 | 2019-05-21 | 网络洞察力知识产权公司 | 实况内容分发系统中的播出缓冲 |
CN106792265A (zh) * | 2017-01-11 | 2017-05-31 | 广州偕作信息科技有限公司 | 一种网络实时流媒体传输方法和系统 |
CN110768753A (zh) * | 2018-07-25 | 2020-02-07 | 成都鼎桥通信技术有限公司 | 一种丢包重传方法和系统 |
CN112995685A (zh) * | 2021-02-05 | 2021-06-18 | 杭州朗和科技有限公司 | 数据发送方法及装置、数据接收方法及装置、介质、设备 |
CN112995685B (zh) * | 2021-02-05 | 2023-02-17 | 杭州网易智企科技有限公司 | 数据发送方法及装置、数据接收方法及装置、介质、设备 |
CN113365098A (zh) * | 2021-06-01 | 2021-09-07 | 平安国际智慧城市科技股份有限公司 | 视频帧组装方法、装置、电子设备及存储介质 |
CN113365098B (zh) * | 2021-06-01 | 2022-07-22 | 平安国际智慧城市科技股份有限公司 | 视频帧组装方法、装置、电子设备及存储介质 |
CN114051173A (zh) * | 2021-10-09 | 2022-02-15 | 广州广哈通信股份有限公司 | 一种基于rtp扩展头部的视频帧可靠传输方法、装置及设备 |
CN114051173B (zh) * | 2021-10-09 | 2023-08-08 | 广州广哈通信股份有限公司 | 一种基于rtp扩展头部的视频帧可靠传输方法、装置及设备 |
CN114422397A (zh) * | 2021-12-27 | 2022-04-29 | 中国电信股份有限公司 | 流媒体通道监测方法、装置、电子设备和可读存储介质 |
CN117834090A (zh) * | 2024-03-06 | 2024-04-05 | 无锡沐创集成电路设计有限公司 | 一种基于rdma的半纠错视频图像透传装置、方法和系统 |
CN117834090B (zh) * | 2024-03-06 | 2024-05-10 | 无锡沐创集成电路设计有限公司 | 一种基于rdma的半纠错视频图像透传装置、方法和系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1917639A (zh) | 使用丢包重传的视频信号增强方法 | |
Xu et al. | CMT-QA: Quality-aware adaptive concurrent multipath data transfer in heterogeneous wireless networks | |
US9306708B2 (en) | Method and apparatus for retransmission decision making | |
US5905871A (en) | Method of multicasting | |
US6694471B1 (en) | System and method for periodic retransmission of messages | |
EP2529528B1 (en) | A method and apparatus for parsing a network abstraction-layer for reliable data communication | |
KR100537499B1 (ko) | 전송제어 파라미터 생성방법 및 프레임 특성에 따른선택적 자동 재전송 방법 | |
CN105721950A (zh) | 一种可靠媒体流传输装置 | |
KR20030020968A (ko) | 스트리밍 애플리케이션들에서의 실시간 패킷화 및 재전송 | |
CN101075957A (zh) | Avs流媒体传输控制方法 | |
CN101155311A (zh) | 一种视频通信中的视频码流错误检测和处理方法 | |
WO2012155821A1 (zh) | 差错控制的方法、接收端、发送端和系统 | |
GB2485765A (en) | Effecting flow control by notifying loss events to congestion controller dependent upon urgency of reception | |
WO2008119259A1 (fr) | Système et procédé de correction d'erreurs sans voie de retour adaptative dynamique dans un réseau iptv | |
CN110876091B (zh) | 一种利用rtp扩展头部解决视频帧丢包的方法及装置 | |
WO2015000337A1 (zh) | 视频传输方法及设备 | |
CN111669545A (zh) | 一种改善视频传输延迟的方法及装置 | |
JP2005045469A (ja) | マルチメディアコンテンツ受信装置及びマルチメディアコンテンツ受信方法 | |
CN1791002A (zh) | 下一代网络中mgc获取服务质量信息的实现方法 | |
Liu et al. | CMT-SR: A selective retransmission based concurrent multipath transmission mechanism for conversational video | |
JP5523163B2 (ja) | 送信装置、送信方法、プログラム | |
Li et al. | An adaptive retransmission‐based multipath transmission mechanism for conversational video | |
EP1947859A1 (en) | Video transmission method and system | |
Lifen et al. | The performance study of transmitting MPEG4 over SCTP | |
CN118282585B (zh) | 一种基于udp的数据传输方法、设备及可读存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |