CN114866523A - 一种基于udp的视频快速传输方法及系统 - Google Patents

一种基于udp的视频快速传输方法及系统 Download PDF

Info

Publication number
CN114866523A
CN114866523A CN202210330826.9A CN202210330826A CN114866523A CN 114866523 A CN114866523 A CN 114866523A CN 202210330826 A CN202210330826 A CN 202210330826A CN 114866523 A CN114866523 A CN 114866523A
Authority
CN
China
Prior art keywords
data
udp
retransmission
window
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
Application number
CN202210330826.9A
Other languages
English (en)
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.)
Guangdong Yuewuji Network Technology Co ltd
Original Assignee
Guangdong Yuewuji Network Technology 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 Guangdong Yuewuji Network Technology Co ltd filed Critical Guangdong Yuewuji Network Technology Co ltd
Priority to CN202210330826.9A priority Critical patent/CN114866523A/zh
Publication of CN114866523A publication Critical patent/CN114866523A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1806—Go-back-N protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/22—Traffic shaping
    • H04L47/225—Determination of shaping rate, e.g. using a moving window
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种基于UDP的视频快速传输方法及系统，所述方法包括如下步骤：步骤S1，在传输层，在UDP数据报文的基础上对UDP数据报文中的数据增加包含序列号以及拥塞发送控制窗口字段的控制头，并对增加控制头后的数据报文进行封装；步骤S2，在传输层采用滑动窗口机制发送封装后的视频数据包。

Description

一种基于UDP的视频快速传输方法及系统
技术领域
本发明涉及云手机技术领域，特别是涉及一种云手机与真机之间的基于UDP(UserDatagram Protocol，用户数据包协议)的视频快速传输方法及系统。
背景技术
云手机是通过在云服务器端通过虚拟容器的方式，将一台云服务器划分成多个虚拟机来独立运行的android系统，然后提供远程操作让手机等终端设备操作使用，使得各种应用运行在云端，方便管理，可以大大减少真实手机本地资源的消耗。
由于程序运行在云端，真机需要看到云手机的运行界面，并进行操作，因此需要的把云手机的运行界面编码后传送给真机界面播放显示；在真机模拟场景，真机也需要把本地摄像头的数据采集编码后，传送到云手机端进行解码识别使用。
随着云游戏、云应用、云教育、云健身等应用场景场景越来越多，真机和云机之间会进行大量的视频数据传输，由于云手机的终端的使用无线网络，网络环境比较复杂。如何在真机和云机之间进行高可靠、高质量和低延时的快速视频数据传输成为云手机体验的重要指标，这都需要一种高效快速的云手机视频快速传输技术来支持。
目前一些实现云手机通信的实现案例多数都是集成了一些开源的音视频通信协议，比如WebRTC，WebRTC的好处是免费，强大的NAT和防火墙穿透技术，现在WebRTC技术内置于浏览器中，用户就可以通过浏览器来实现实时通信。
但是针对云手机的场景，WebRTC有一定的局限性，比如：WebRTC主要面向Web应用，虽然也可以用于Native开发，但是由于涉及到的领域知识(音视频采集、处理、编解码、实时传输等)较多，整个框架设计比较复杂，API粒度也比较细，导致连工程项目的编译都不是一件容易的事；WebRTC的传输设计基于P2P，难以保障传输质量，优化手段也有限，只能做一些端到端的优化，难以应对复杂的互联网环境，比如对跨地区、跨运营商、低带宽、高丢包等场景；WebRTC更多的针对视频聊天的场景，很多云手机的场景比如真机模拟、多平互动并不适用，用在云手机上会存在一定局限性。
发明内容
为克服上述现有技术存在的不足，本发明之目的在于提供一种基于UDP的视频快速传输方法及系统，实现了云手机与真机之间基于UDP的视频数据的快速传输，并结合智能重传(ARQ)、前向纠错(FEC)技术，降低了网络抖动带来的影响，并结合容错措施适当丢帧并快速恢复，充分保证视频数据传输的可靠性和实时性。
为达上述目的，本发明提出一种基于UDP的视频快速传输方法，包括如下步骤：
步骤S1，在传输层，在UDP数据报文的基础上对UDP数据报文中的数据增加包含序列号以及拥塞发送控制窗口字段的控制头，并对增加控制头后的数据报文进行封装；
步骤S2，在传输层采用滑动窗口机制发送封装后的视频数据包。
优选地，所述滑动窗口机制为发送方在滑动窗口内发送多个数据包，然后等待接收方确认，接收方维护一个接收窗口，以限制发送方在未收到确认之前只能发送拥塞窗口值大小的数据。
优选地，步骤S2进一步包括：
步骤S200，数据包发送采用慢开始，然后实时发送数据的窗口值指数增长的方式，直到实时发送数据的窗口值达到拥塞窗口值；
步骤S201，根据接收方对当前滑动窗口内的数据包的接收结果调整滑动窗口的拥塞窗口值。
优选地，于步骤S200中，从1个数据包开始发送数据，然后呈指数增长，直至实时发送数据的窗口值增加至当前数据包中的拥塞窗口值。
优选地，步骤S201进一步包括：
步骤S201a，根据接收方对当前滑动窗口内的数据包的接收结果判断是否出现丢包，若未出现丢包，则进入步骤S201b，否则进入步骤S201c；
步骤S201b，若未出现丢包，则进一步判断当前视频编码码率是否满足视频传输带宽，若满足，则按照当前窗口值继续通信；若不满足，则提高当前视频编码码率，并增加滑动窗口的拥塞窗口值及实时发送数据的窗口值，直到当前视频编码码率达到配置的码率值后停止增加；
步骤S201c，若出现丢包，则启动智能重传策略。
优选地，所述智能重传策略包括发送方超时重传、接收主动请求快速重传，所述发送方超时重传主要依据RTO重传超时时间来进行，所述接收主动请求快速重传是指当接收方接收到了序号跳跃的数据包，则立即给发送方发送最后一个连续的数据包的ACK，发送方则以ACK跨越数为依据，决定是否快速重传。
优选地，所述智能重传策略还包括选择性重传，只重传真正丢失的数据包。
优选地，在出现丢包由发送方进行重传时，由发送方进行FEC编码引入冗余包，接收方进行FEC解码并恢复丢失的数据包。
优选地，于步骤S201c中，若丢包严重，则减小拥塞发送控制窗口值，并相应进行减低视频编码码率，从而保证正常传输。
为达到上述目的，本发明还提供一种基于UDP的视频快速传输系统，包括：
数据包封装处理单元，用于在UDP数据报文的基础上增加控制头，在传输层对视频数据进行封装；
数据包发送传输单元，在传输层，在UDP数据报文的基础上对UDP数据报文中的数据增加包含序列号以及拥塞发送控制窗口字段的控制头，并对增加控制头后的数据报文进行封装。
与现有技术相比，本发明一种基于UDP的视频快速传输方法及系统通过在传输层实现拥塞控制机制，结合智能重传(ARQ)、前向纠错(FEC)等技术实现一套网络优化策略，降低网络抖动带来的影响，结合容错措施，适当丢帧并快速恢复，充分保证数据传输的可靠性性和实时性，本发明与基于TCP的数据传输方式相比，以较小的带宽的代价，大大减低了延时，尤其是在网络拥堵情况下解决了TCP协议的网络速度慢的问题，适合网络复杂的环境，更加符合云手机对延时要求很高的场景。
附图说明
图1为本发明一种云手机与真机的数据通信方法的步骤流程图；
图2为本发明实施例中采用自定义的网络传输协议进行数据通信的示意图；
图3为本发明一种云手机与真机的数据通信系统的系统结构图。
具体实施方式
以下通过特定的具体实例并结合附图说明本发明的实施方式，本领域技术人员可由本说明书所揭示的内容轻易地了解本发明的其它优点与功效。本发明亦可通过其它不同的具体实例加以施行或应用，本说明书中的各项细节亦可基于不同观点与应用，在不背离本发明的精神下进行各种修饰与变更。
图1为本发明一种基于UDP的视频快速传输方法的步骤流程图。如图1所示，本发明一种基于UDP的视频快速传输方法，包括如下步骤：
步骤S1，在传输层，在UDP数据报文的基础上对UDP数据报文中的数据增加控制头，并对增加控制头后的数据报文进行封装。
UDP协议能实现快速传输，但UDP协议包头中并没有定义一个序列号字段，UDP协议层无法确认是否丢包，也就无法检测当前网络是否拥塞，是一种不可靠的传输协议。因此，本发明为了实现UDP的可靠传输，在UDP数据报文的基础上增加控制头，在传输层对数据进行封装，该控制头格式如下表1所示：
表1
Figure BDA0003572994090000051
其中，各字段定义如下：
sessionId：会话ID
Command:区分数据包的类型
Fragment:数据分包传输序号
Wnd：拥塞发送控制窗口
Timestamp：发送时刻的时间戳
seqNo：发送序列号
unAckNo：待接收消息序列号
也就是说，由于UDP在网络中的传输是不可靠的，因此可能会出现丢包和包的乱序，本发明通过参考TCP的拥塞控制方法，在UDP数据报文的基础上的控制头中包含序列号字段seqNo、拥塞发送控制窗口Wnd等信息，以在传输层实现拥塞控制。
步骤S2，在传输层采用滑动窗口机制发送封装后的数据包。
在本发明中，为了提高发送速度，发送方可以不必每发送一个包后就进行等待确认，而是可以发送多个包出去，然后等待接收方一一确认；又由于接收方不可能同时处理无限多的数据，因此需要限制发送方往网络中发送的数据数量，接收方维护一个接收窗口，接收方限制发送方在未收到确认之前只能发送所述拥塞发送控制窗口wnd大小的数据，这个机制叫做滑动窗口机制，在本发明中，发送方可以是云手机端，也可以是真机端，同样地，接收方也可以是云手机端或真机端。
具体地，如图2所示，步骤S2进一步包括：
步骤S200，数据包发送采用慢开始，然后窗口值指数增长的方式，直到窗口值达到拥塞窗口值。
具体地，所述慢开始是指先从1个数据包即窗口值为1个数据包大小，开始发送，然后呈指数增长，即实时发送数据的窗口值呈指数增长，所述指数增长指以2的次方一直翻倍(1，2，4，8...)增长，直至窗口值增加至拥塞窗口值，所述拥塞窗口值为当前数据包的控制头中包括的拥塞发送控制窗口Wnd值，表示一定时间内限制发送的数据包。
步骤S201，根据接收方对当前滑动窗口内的数据包的接收结果调整滑动窗口的拥塞窗口值。
在本发明中，发送方不是每发送一个包后则进行等待确认，而是在滑动窗口内发送多个数据包，然后等待接收方确认，若滑动窗口内的数据包在规定时间内正常完成接收，则增加滑动窗口的窗口拥塞值，例如:当发送的数据包<拥塞窗口值wnd时，按2的指数对实时发送数据的窗口值进行翻倍增加，而当发送的数据包>＝拥塞窗口值wnd后，则按加1的方式增加窗口拥塞值，同时按加1的方式增加实时发送数据的窗口值，直到出现拥塞丢包或当前视频编码码率(也就是说，本发明中视频编码码率根据动态码率调整，具体的动态码率调整可采用现有技术)达到配置的码率值，则停止增加，该配置的码率值一般为用户设定分辨率(比如高清720P)对应的最大码率。
当出现丢包现象，即RTO时间内没有收到接收方回复数据包的ACK，则判断丢包，此时启动智能重传策咯，并在必要时(例如当丢包的数据超过设定值，则认为丢包严重，数据拥塞时)，调低滑动窗口水位，即减小拥塞发送控制窗口，即拥塞窗口值wnd(例如按2的指数减少)，并相应进行减低视频编码码率，以保证正常传输。
具体地，步骤S201进一步包括：
步骤S201a，根据接收方对当前滑动窗口内的数据包的接收结果判断是否出现丢包，若未出现丢包，则进入步骤S201b，否则进入步骤S201c。
在本发明中，接收方维护一个接收窗口以限制发送方在未收到确认之前只能发送窗口拥塞值wnd大小的数据，当接收窗口收到序号的分包，将该数据放入接收队列供应用层取用，具体地，如果按照顺序接收到数据包，则直接处理，即放入接收队列，并返回接收结果；如果收到的数据在窗口范围内但顺序有点乱，那么则将数据先保存起来，在一个滑动窗口数据包接收完后则根据顺序进行处理并返回接收结果，例如接收到序号为n的数据包，下一个数据包应是序号为n+1的数据包，而此时接收到序号n+2的数据包，则先将序号为n+2的数据包缓存起来，等到接收到序号为n+1的数据包后，再将序号为n+1和序号为n+2一起处理，放入接收队列。
步骤S201b，若未出现丢包，则认为滑动窗口内的数据包在规定时间内正常完成接收，则进一步判断当前视频编码码率是否满足视频传输带宽，若满足，则按照当前窗口值继续通信；若不满足，则提高当前视频编码码率，并增加滑动窗口的拥塞窗口值，此时拥塞窗口值以加1的方式增加，同时按加1的方式增加实时发送数据的窗口值，直到当前视频编码码率达到配置的码率值后停止增加；
步骤S201c，若出现丢包，则启动智能重传策略，并在丢包严重的情况下，则调低滑动窗口水位，即减小拥塞窗口值，即拥塞发送控制窗口wnd，并相应进行减低视频编码码率，从而保证正常传输。所述智能重传策略包括发送方超时重传、接收主动请求快速重传以及选择性重传。
具体地，所述发送方超时重传主要依据RTO(Retransmission Time Out)重传超时时间来进行，本发明的方法在快速模式下1次RTO即发起重传，保证可靠性的同时，大大减少重传时间，保证了实时性。
所述接收方主动请求快速重传是指，如果接收端接收到了序号跳跃的数据包，则立即给发送方发送最后一个连续的数据包的ACK(重复确认)，以ACK跨越数为依据，决定是否快速重传，本发明默认设置为ACK跨越2个包，直接发起重传，不等RTO重传超时时间，充分保证实时性。
TCP丢包时会全部重传从丢的那个包开始以后的数据包，而本发明采用选择性重传，例如根据需要重传的数据是否超过了预设时间来确定是否重传，假设延时要求为200ms，若数据包已经超过了该时间，则无必要再重传，从而实现只重传真正丢失的数据包，为了保证质量和实时性，在网络比较差的情况下，可以选择只针对I帧重传，避免黑屏，可以保证云手机的最基本使用，这样可以大大减少重传的次数，减少拥塞，加快恢复，充分保证实时性。
优选地，在出现丢包由发送方进行重传时，由发送方进行FEC编码引入冗余包，接收方进行FEC解码并恢复丢失的数据包，在终端算力足够和网络抖动明显的情况下，能提升UDP传输的丢包、乱序抵抗力，为上层服务提供有力保障。比如一个丢包的数据包为m个字节，发送方通过FEC编码，在包头增加n个字节，然后传输的数据是(m+n)个字节，当由于传输网络抖动，导致数据包里面有p(p<n)个数据出错了，可以根据编码所增加的n个字节发现并恢复这p个出错的数据，不需要重新传输改数据包，从而减少延迟。
优选地，在本发明中，超时重传和快速重传可以是并列的，即符合条件就执行，选择性重传则是在超时重传和快速重传效果不大的情况下，则采取丢掉一些无用数据，只传最重要的数据，比如I帧。
优选地，在本发明中，在传输过程中还需引入一些必要的业务层容错机制，最严重的情况就是丢帧，会导致画面短暂花屏，要能用I帧快速恢复，也就是根据延时情况，延时比较长时进行丢帧，清除延时过长的缓存，避免延时叠加；如果网络确实很差，则丢的包比较多，只传能独立解码的I帧。
图3为本发明一种基于UDP的视频快速传输系统的系统结构图。如图3所示，本发明一种基于UDP的视频快速传输系统，包括：
数据包封装处理单元30，用于在传输层，在UDP数据报文的基础上对UDP数据报文中的数据增加控制头，并对增加控制头后的数据报文进行封装。
UDP协议能实现快速传输，但UDP协议包头中并没有定义一个序列号字段，UDP协议层无法确认是否丢包，也就无法检测当前网络是否拥塞，是一种不可靠的传输协议。因此，本发明为了实现UDP的可靠传输，在UDP数据报文的基础上增加控制头，在传输层对数据进行封装，该控制头格式如下表2所示：
表2
Figure BDA0003572994090000091
其中，各字段定义如下：
sessionId：会话ID
Command:区分数据包的类型
Fragment:数据分包传输序号
Wnd：拥塞发送控制窗口
Timestamp：发送时刻的时间戳
seqNo：发送序列号
unAckNo：待接收消息序列号
也就是说，由于UDP在网络中的传输是不可靠的，因此可能会出现丢包和包的乱序，本发明通过参考TCP的拥塞控制方法，在UDP数据报文的基础上的控制头中包含序列号字段seqNo、拥塞发送控制窗口Wnd等信息，以在传输层实现拥塞控制。
数据包发送传输单元31，在传输层采用滑动窗口机制发送封装后的数据包。
在本发明中，为了提高发送速度，发送方可以不必每发送一个包后就进行等待确认，而是可以发送多个包出去，然后等待接收方一一确认；又由于接收方不可能同时处理无限多的数据，因此需要限制发送方往网络中发送的数据数量，接收方维护一个接收窗口，接收方限制发送方在未收到确认之前只能发送所述拥塞发送控制窗口wnd大小的数据，这个机制叫做滑动窗口机制，在本发明中，发送方可以是云手机端，也可以是真机端，同样地，接收方也可以是云手机端或真机端。
具体地，数据包发送传输单元31进一步包括：
初始发送处理模块310，用于数据包发送采用慢开始，然后窗口值指数增长的方式，直到窗口值达到拥塞窗口值。
具体地，所述慢开始是指先从1个数据包即窗口值为1个数据包大小，开始发送，然后呈指数增长，即实时发送数据的窗口值呈指数增长，所述指数增长指以2的次方一直翻倍(1，2，4，8...)增，直至窗口值增加至拥塞窗口值，所述拥塞窗口值为当前数据包的控制头中包括的拥塞发送控制窗口Wnd值，表示一定时间内限制发送的数据包。
拥塞调整模块311，用于根据接收方对当前滑动窗口内的数据包的接收结果调整滑动窗口的拥塞窗口值。
在本发明中，发送方不是每发送一个包后则进行等待确认，而是在滑动窗口内发送多个数据包，然后等待接收方确认，若滑动窗口内的数据包在规定时间内正常完成接收，则增加滑动窗口的窗口拥塞值，例如:当发送的数据包<拥塞窗口值wnd时，按2的指数对实时发送数据的窗口值进行翻倍增加，而当发送的数据包>＝拥塞窗口值wnd后，则按加1的方式增加窗口拥塞值，同时按加1的方式增加实时发送数据的窗口值，直到出现拥塞丢包或当前视频编码码率(也就是说，本发明中视频编码码率根据动态码率调整，具体的动态码率调整可采用现有技术)达到配置的码率值，则停止增加，该配置的码率值一般为用户设定分辨率(比如高清720P)对应的最大码率。
当出现丢包现象，即RTO时间内没有收到接收方回复数据包的ACK，则判断丢包，此时启动智能重传策咯，并在必要时(例如当丢包的数据超过设定值，则认为丢包严重，数据拥塞时)，调低滑动窗口水位，即减小拥塞发送控制窗口，即拥塞窗口值wnd(例如按2的指数减少)，并相应进行减低视频编码码率，以保证正常传输。
具体地，拥塞调整模块311进一步包括：
丢包判断模块,用于根据接收方对当前滑动窗口内的数据包的接收结果判断是否出现丢包，若未出现丢包，则进入步骤未丢包处理单元，否则进入步骤丢包处理单元。
在本发明中，接收方维护一个接收窗口以限制发送方在未收到确认之前只能发送窗口拥塞值wnd大小的数据，当接收窗口收到序号的分包，将该数据放入接收队列供应用层取用，具体地，如果按照顺序接收到数据包，则直接处理，即放入接收队列，并返回接收结果；如果收到的数据在窗口范围内但顺序有点乱，那么则将数据先保存起来，在一个滑动窗口数据包接收完后则根据顺序进行处理并返回接收结果，例如接收到序号为n的数据包，下一个数据包应是序号为n+1的数据包，而此时接收到序号n+2的数据包，则先将序号为n+2的数据包缓存起来，等到接收到序号为n+1的数据包后，再将序号为n+1和序号为n+2一起处理，放入接收队列。
未丢包处理单元，用于在判断未出现丢包时，认为滑动窗口内的数据包在规定时间内正常完成接收，则进一步判断当前视频编码码率是否满足视频传输带宽，若满足，则按照当前窗口值继续通信；若不满足，则提高当前视频编码码率，并增加滑动窗口的拥塞窗口值，此时拥塞窗口值以加1的方式增加，同时按加1的方式增加实时发送数据的窗口值，直到当前视频编码码率达到配置的码率值后停止增加；
丢包处理单元，用于在判断出现丢包时启动智能重传策略，并在丢包严重的情况下，则调低滑动窗口水位，即减小拥塞窗口值，即拥塞发送控制窗口wnd，并相应进行减低视频编码码率，从而保证正常传输。所述智能重传策略包括发送方超时重传、接收主动请求快速重传以及选择性重传。
具体地，所述发送方超时重传主要依据RTO(Retransmission Time Out)重传超时时间来进行，本发明的方法在快速模式下1次RTO即发起重传，保证可靠性的同时，大大减少重传时间，保证了实时性。
所述接收方主动请求快速重传是指，如果接收端接收到了序号跳跃的数据包，则立即给发送方发送最后一个连续的数据包的ACK(重复确认)，以ACK跨越数为依据，决定是否快速重传，本发明默认设置为ACK跨越2个包，直接发起重传，不等RTO重传超时时间，充分保证实时性。
TCP丢包时会全部重传从丢的那个包开始以后的数据包，而本发明采用选择性重传，例如根据需要重传的数据是否超过了预设时间来确定是否重传，假设延时要求为200ms，若数据包已经超过了该时间，则无必要再重传，从而实现只重传真正丢失的数据包，为了保证质量和实时性，在网络比较差的情况下，可以选择只针对I帧重传，避免黑屏，可以保证云手机的最基本使用，这样可以大大减少重传的次数，减少拥塞，加快恢复，充分保证实时性。
优选地，在出现丢包由发送方进行重传时，由发送方进行FEC编码引入冗余包，接收方进行FEC解码并恢复丢失的数据包，在终端算力足够和网络抖动明显的情况下，能提升UDP传输的丢包、乱序抵抗力，为上层服务提供有力保障。比如一个丢包的数据包为m个字节，发送方通过FEC编码，在包头增加n个字节，然后传输的数据是(m+n)个字节，当由于传输网络抖动，导致数据包里面有p(p<n)个数据出错了，可以根据编码所增加的n个字节发现并恢复这p个出错的数据，不需要重新传输改数据包，从而减少延迟。
优选地，在本发明中，超时重传和快速重传可以是并列的，即符合条件就执行，选择性重传则是在超时重传和快速重传效果不大的情况下，则采取丢掉一些无用数据，只传最重要的数据，比如I帧。
优选地，在本发明中，在传输过程中还需引入一些必要的业务层容错机制，最严重的情况就是丢帧，会导致画面短暂花屏，要能用I帧快速恢复，也就是根据延时情况，延时比较长时进行丢帧，清除延时过长的缓存，避免延时叠加；如果网络确实很差，则丢的包比较多，只传能独立解码的I帧。
综上所述，本发明一种基于UDP的视频快速传输方法及系统通过在传输层实现拥塞控制机制，结合智能重传(ARQ)、前向纠错(FEC)等技术实现一套网络优化策略，降低网络抖动带来的影响，结合容错措施，适当丢帧并快速恢复，充分保证数据传输的可靠性性和实时性，本发明与基于TCP的数据传输方式相比，以较小的带宽的代价，大大减低了延时，尤其是在网络拥堵情况下解决了TCP协议的网络速度慢的问题，适合网络复杂的环境，更加符合云手机对延时要求很高的场景。
上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何本领域技术人员均可在不违背本发明的精神及范畴下，对上述实施例进行修饰与改变。因此，本发明的权利保护范围，应如权利要求书所列。

Claims (10)

1.一种基于UDP的视频快速传输方法，包括如下步骤：
步骤S1，在传输层，在UDP数据报文的基础上对UDP数据报文中的数据增加包含序列号以及拥塞发送控制窗口字段的控制头，并对增加控制头后的数据报文进行封装；
步骤S2，在传输层采用滑动窗口机制发送封装后的视频数据包。
2.如权利要求1所述的一种基于UDP的视频快速传输方法，其特征在于：所述滑动窗口机制为发送方在滑动窗口内发送多个数据包，然后等待接收方确认，接收方维护一个接收窗口，以限制发送方在未收到确认之前只能发送拥塞窗口值大小的数据。
3.如权利要求2所述的一种基于UDP的视频快速传输方法，其特征在于，步骤S2进一步包括：
步骤S200，数据包发送采用慢开始，然后实时发送数据的窗口值指数增长的方式，直到实时发送数据的窗口值达到拥塞窗口值；
步骤S201，根据接收方对当前滑动窗口内的数据包的接收结果调整滑动窗口的拥塞窗口值。
4.如权利要求3所述的一种基于UDP的视频快速传输方法，其特征在于：于步骤S200中，从1个数据包开始发送数据，然后呈指数增长，直至实时发送数据的窗口值增加至当前数据包中的拥塞窗口值。
5.如权利要求4所述的一种基于UDP的视频快速传输方法，其特征在于,步骤S201进一步包括：
步骤S201a，根据接收方对当前滑动窗口内的数据包的接收结果判断是否出现丢包，若未出现丢包，则进入步骤S201b，否则进入步骤S201c；
步骤S201b，若未出现丢包，则进一步判断当前视频编码码率是否满足视频传输带宽，若满足，则按照当前窗口值继续通信；若不满足，则提高当前视频编码码率，并增加滑动窗口的拥塞窗口值及实时发送数据的窗口值，直到当前视频编码码率达到配置的码率值后停止增加；
步骤S201c，若出现丢包，则启动智能重传策略。
6.如权利要求5所述的一种基于UDP的视频快速传输方法，其特征在于：所述智能重传策略包括发送方超时重传、接收主动请求快速重传，所述发送方超时重传主要依据RTO重传超时时间来进行，所述接收主动请求快速重传是指当接收方接收到了序号跳跃的数据包，则立即给发送方发送最后一个连续的数据包的ACK，发送方则以ACK跨越数为依据，决定是否快速重传。
7.如权利要求6所述的一种基于UDP的视频快速传输方法，其特征在于：所述智能重传策略还包括选择性重传，只重传真正丢失的数据包。
8.如权利要求7所述的一种基于UDP的视频快速传输方法，其特征在于：在出现丢包由发送方进行重传时，由发送方进行FEC编码引入冗余包，接收方进行FEC解码并恢复丢失的数据包。
9.如权利要求8所述的一种基于UDP的视频快速传输方法，其特征在于：于步骤S201c中，若丢包严重，则减小拥塞发送控制窗口值，并相应进行减低视频编码码率，从而保证正常传输。
10.一种基于UDP的视频快速传输系统，包括：
数据包封装处理单元，用于在UDP数据报文的基础上增加控制头，在传输层对视频数据进行封装；
数据包发送传输单元，在传输层，在UDP数据报文的基础上对UDP数据报文中的数据增加包含序列号以及拥塞发送控制窗口字段的控制头，并对增加控制头后的数据报文进行封装。
CN202210330826.9A 2022-03-30 2022-03-30 一种基于udp的视频快速传输方法及系统 Pending CN114866523A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210330826.9A CN114866523A (zh) 2022-03-30 2022-03-30 一种基于udp的视频快速传输方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210330826.9A CN114866523A (zh) 2022-03-30 2022-03-30 一种基于udp的视频快速传输方法及系统

Publications (1)

Publication Number Publication Date
CN114866523A true CN114866523A (zh) 2022-08-05

Family

ID=82628563

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210330826.9A Pending CN114866523A (zh) 2022-03-30 2022-03-30 一种基于udp的视频快速传输方法及系统

Country Status (1)

Country Link
CN (1) CN114866523A (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090213850A1 (en) * 2008-01-30 2009-08-27 Canon Kabushiki Kaisha Method for transmitting a data stream with anticipation of acknowledgments, correspondence input device and computer-readable storage medium
CN103067301A (zh) * 2013-01-17 2013-04-24 广东石油化工学院 基于用户数据报协议的快速可靠的拥塞控制改进算法
CN108111434A (zh) * 2017-12-14 2018-06-01 四川大学 一种基于可靠udp和喷泉码的航空自组网可靠传输方法
CN109474365A (zh) * 2018-12-29 2019-03-15 深圳市柠檬互动科技有限公司 一种帧同步udp网络同步方法
CN110830472A (zh) * 2019-11-07 2020-02-21 西北工业大学 基于tcp/ip协议的灵活数据传输协议的灵活数据传输方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090213850A1 (en) * 2008-01-30 2009-08-27 Canon Kabushiki Kaisha Method for transmitting a data stream with anticipation of acknowledgments, correspondence input device and computer-readable storage medium
CN103067301A (zh) * 2013-01-17 2013-04-24 广东石油化工学院 基于用户数据报协议的快速可靠的拥塞控制改进算法
CN108111434A (zh) * 2017-12-14 2018-06-01 四川大学 一种基于可靠udp和喷泉码的航空自组网可靠传输方法
CN109474365A (zh) * 2018-12-29 2019-03-15 深圳市柠檬互动科技有限公司 一种帧同步udp网络同步方法
CN110830472A (zh) * 2019-11-07 2020-02-21 西北工业大学 基于tcp/ip协议的灵活数据传输协议的灵活数据传输方法

Similar Documents

Publication Publication Date Title
CN107231328B (zh) 实时视频传输方法、装置、设备及系统
KR101644215B1 (ko) 신뢰성 있는 데이터 통신을 위한 네트워크 추상화 계층을 파싱하는 방법 및 장치
JP6023368B1 (ja) インタラクティブなリアルタイムメディアの転送プロトコル
CN109729439B (zh) 实时视频传输方法
US9306708B2 (en) Method and apparatus for retransmission decision making
CN106341738B (zh) 流媒体网络传输的带宽计算方法、服务器端和系统
CN113037440B (zh) 数据重传处理方法、装置、计算机设备和存储介质
US8499212B2 (en) Method and apparatus for adaptive forward error correction with merged automatic repeat request for reliable multicast in wireless local area networks
EP2493105A1 (en) Method and system for recovering lost media data packets
US20150103885A1 (en) Real time ip video transmission with high resilience to network errors
JP2007537640A (ja) パケット化データのビットレートの適合化とデータパケットの再送信との間の連携
CN103780971A (zh) 一种互联网条件下基于rudp的实时视频传输方法
CN112436924B (zh) 一种数据传输方法及电子设备
WO2015066836A1 (zh) 视频业务数据传输方法、数据接收装置和数据发送装置
CN110943808A (zh) 数据传输方法、装置、电子设备和存储介质
CN112350803A (zh) 数据包的传输方法、装置、系统、电子设备及存储介质
CN101969372A (zh) 基于帧丢失预测的蜂窝网络上行视频通信QoS优化方法
US9426260B2 (en) Real time communication over TCP
CN113315823A (zh) 一种低延迟音视频传输方法
CN111092907B (zh) 基于udp协议的数据流快速传输方法、系统及介质
Kim et al. UDP-based extremely low latency streaming
CN114866523A (zh) 一种基于udp的视频快速传输方法及系统
CN115766519A (zh) 便携通信设备的数据传输方法及系统
CN113542685B (zh) 一种基于可靠udp的实时超高清视频传输方法
Fracchia et al. R-RoHC: A single adaptive solution for header compression

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
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20220805