CN106792262A - 视频数据传输方法及装置 - Google Patents

视频数据传输方法及装置 Download PDF

Info

Publication number
CN106792262A
CN106792262A CN201611106405.9A CN201611106405A CN106792262A CN 106792262 A CN106792262 A CN 106792262A CN 201611106405 A CN201611106405 A CN 201611106405A CN 106792262 A CN106792262 A CN 106792262A
Authority
CN
China
Prior art keywords
udp message
message bag
numbering
packet
data 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.)
Pending
Application number
CN201611106405.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.)
LeTV Holding Beijing Co Ltd
LeTV Cloud Computing Co Ltd
Original Assignee
LeTV Holding Beijing Co Ltd
LeTV Cloud Computing 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 LeTV Holding Beijing Co Ltd, LeTV Cloud Computing Co Ltd filed Critical LeTV Holding Beijing Co Ltd
Priority to CN201611106405.9A priority Critical patent/CN106792262A/zh
Publication of CN106792262A publication Critical patent/CN106792262A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/643Communication protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331Caching operations, e.g. of an advertisement for later insertion during playback
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/647Control 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/64746Control signals issued by the network directed to the server or the client
    • H04N21/64761Control signals issued by the network directed to the server or the client directed to the server
    • H04N21/64776Control 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

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

Abstract

本发明实施例提供一种视频数据传输方法,包括:基于接收到的第一UDP数据包的序号信息和与接收缓冲区内时间最新的第二UDP数据包的序号信息之间的连续性,并根据至少两种丢包确认机制确定丢失数据包;根据所确定的丢失数据包,向发送端发送相应的UDP重发请求。本发明还提供了相应的装置。本发明实施例提供的视频数据传输方法及装置,由于基于UDP协议来传输视频数据,使得传输数据尤其是流媒体数据的实时性大大提高。且通过对丢失的数据包进行重发,实现了数据的选择性传输,降低了数据大量重发时发生网络堵塞严重、数据乱序和丢失的风险,减少了视频播放卡顿和延迟的现象,加强了在不同网络状态下的丢包管理,提升了装置性能。

Description

视频数据传输方法及装置
技术领域
本发明涉及数据传输领域,具体涉及一种视频数据传输方法及装置。
背景技术
随着网络技术的发展,越来越多的人开始关注视频直播业务。目前,在各视频直播业务中,例如网络直播、多人视频会议等,为了保证数据的可靠性,通常使用基于TCP(Transmission Control Protocol,传输控制协议)的协议来对音视频数据进行传输。
TCP协议是面向连接的传输协议,通信前需先建立连接,传输时延较大。且TCP协议中的确认和重发机制、流量控制机制虽能保证数据的可靠传输,但处理过程复杂,效率不高,在网络不稳定的情况下会导致延迟不可控。对于音频和视频数据来说,无法满足其传输时较高的实时性要求。由于UDP(User Datagram Protocol,用户数据报协议)协议是一种无连接的传输层协议,通信时直接向对端发送数据,不记录连接状态,具有控制选项较少、资源消耗小、处理速度快、在数据传输过程中延迟小、数据传输效率高的优点,节省了大量的网络资源,提高了网络传输效率,因此,在音频、视频等实时性要求较高的数据传输中得到广泛的应用。
在实现本发明过程中,发明人发现相关技术中至少存在如下问题:尽管利用UDP协议进行数据传输能够满足较高的实时性要求,但由于UDP协议并不提供数据传送的保证机制,传输数据前不需要建立逻辑链路,也没有自动重发机制来保证数据传输的正确性,因此会造成以下问题:1、容易产生数据包丢失的现象,即UDP数据包在传输过程中可能会因数据损坏或拥塞而被丢弃;2、容易发生数据包乱序到达的现象,即发送端按顺序发出的UDP数据包在到达接受端时可能会顺序错乱,从而影响数据的解析。
发明内容
本发明实施例提供一种视频数据传输方法及装置,用以至少解决上述阐述的现有技术中传输视频数据时容易发生数据包乱序、丢失的问题。
第一方面,本发明实施例提供了一种视频数据传输方法,包括:
基于接收到的第一UDP数据包的序号信息和与接收缓冲区内时间最新的第二UDP数据包的序号信息之间的连续性,并根据至少两种丢包确认机制确定丢失数据包;
根据所确定的丢失数据包,向发送端发送相应的UDP重发请求。
第二方面,本发明实施例提供了一种视频数据传输装置,包括:
丢包确定模块,用于基于接收到的第一UDP数据包的序号信息和与接收缓冲区内时间最新的第二UDP数据包的序号信息之间的连续性,并根据至少两种丢包确认机制确定丢失数据包;
请求重发模块,用于根据所确定的丢失数据包,向发送端发送相应的UDP重发请求。
第三方面,本发明实施例还提供了一种非易失性计算机存储介质,存储有计算机可执行指令,所述计算机可执行指令用于执行本发明上述任一项视频数据传输方法。
第四方面,本发明实施例还提供了一种电子设备,包括:至少一个处理器;以及存储器;其中,所述存储器存储有可被所述至少一个处理器执行的程序,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行本发明上述任一项视频数据传输方法。
第五方面,本发明实施例还提供了一种计算机程序产品,包括至少一个非易失性计算机存储介质,所述非易失性计算机存储介质具有存储在其中的计算机可执行程序代码指令,所述计算机可执行程序代码指令能够执行上述任一项所述的视频数据传输方法。
本发明实施例提供的视频数据传输方法及装置,由于基于UDP协议来传输视频数据包,使得传输数据尤其是流媒体数据的实时性大大提高。当发生数据包丢失的情况时,通过接收到的数据包的序号信息和接收缓冲区内的数据包的序号信息之间的连续性确定丢失数据包,从而对丢失数据包进行重发,实现了数据的选择性重发。由于无需舍弃任何已接收到的数据包,避免了已接收的数据包被舍弃后再次重发的问题,降低了数据大量重发时发生网络堵塞严重、数据乱序和丢失的风险,保证了数据传输时的可靠性。通过接收缓冲区将乱序的数据进行排序和缓冲,减少了视频播放卡顿和延迟的现象,提升了装置性能。此外,本发明确定丢失数据包的丢包确认机制至少有两种,完善了确定丢失数据包的场景,增加了对丢失数据包进行重发的可能性,加强了在不同网络状态下的丢包管理。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明一实施例的数据传输方法的流程图;
图2是本发明一实施例的视频数据传输装置的结构示意图;
图3是本发明一实施例提供的实施视频数据传输方法的电子设备的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
需要说明的是,在不冲突的情况下,本发明中的实施方式及实施方式中的特征可以相互组合。
本发明可用于众多通用或专用的计算系统环境或配置中。例如:个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。
本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”,不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
图1是本发明一实施例的数据传输方法的流程图。如图1所示,该方法包括:
S10:基于接收到的第一UDP数据包的序号信息和与接收缓冲区内时间最新的第二UDP数据包的序号信息之间的连续性,并根据至少两种丢包确认机制确定丢失数据包,所述序号信息包括UDP数据包的编号和UDP数据包与所在视频帧有关的帧序号;
S20:根据所确定的丢失数据包,向发送端发送相应的UDP重发请求。
本发明实施例中,用于接收UDP数据包的接收端可以是服务器,也可以是其他具有数据传输功能的电子设备,本发明对此不做限制。
由于以太网(Ethernet)的物理特性,以太网数据帧的长度必须在46-1500字节之间,该1500字节被称为链路层的MTU(Maximum Transmission Unit,最大传输单元),指一种通信协议的某一层上面所能通过的最大数据包大小(以字节为单位)。如果网络层要传输的数据其长度大于链路层的MTU,就要对该数据进行分片(fragmentation),把该数据分成若干片,使得每一个分片都小于MTU。因此,MTU的大小会影响视频帧分片的大小,视频帧分片的大小其实就是单个UDP数据包最大承载的数据大小。在视频分辨率要求较高(例如为1080P)的情况下大部分视频帧的大小都大于UDP的MTU大小,因此需要对视频帧进行分片,生成相应的UDP数据包。例如,MTU的大小为1000字节时,某个视频帧的大小为3500字节,则需要将该视频帧切分为4个数据包,前三个数据包的大小可以是1000字节,相应地,最后一个数据包的大小为500字节。
由于一个视频帧即一帧图像有可能被切分成多个数据包独立地传输,因此需要对数据包设置序号信息并写入数据包的头部,使得接收端可以根据这些数据包头部中的信息正确地组装和解析这些数据包。
本发明实施例中,UDP数据包的序号信息可以包括UDP数据包的编号和该UDP数据包所属视频帧的帧序号。帧序号指UDP数据包所属的视频帧具有的序号,该序号可以根据视频帧被播放的时间先后顺序设置(例如按照每个视频帧的时间戳进行排序)。播放时间越晚的视频帧,其帧序号数值越大。UDP数据包的编号可以理解为:先将视频帧按照播放时间的先后顺序排序,再将每个视频帧切片,按照切片顺序生成每个视频帧对应的至少一个数据包,根据此时得到的排序为数据包赋予连续的号码,即可得到每个数据包的编号。因此可以理解,属于同一个视频帧的数据包具有相同的帧序号,且按照切片顺序具有连续的编号;相邻视频帧中前一个视频帧对应的最后一个数据包的编号与后一个视频帧对应的第一个数据包的编号是连续的。例如,视频帧A、B、C的帧序号是连续的,将A、B、C切片后,生成了A1、A2,B1、B2、B3,C1、C2、C3、C4九个数据包,则这些数据包的序号信息如下表(假设视频帧A为第一个视频帧):
数据包 A1 A2 B1 B2 B3 C1 C2 C3 C4
帧序号 0 0 1 1 1 2 2 2 2
编号 0 1 2 3 4 5 6 7 8
表1本发明实施例中UDP数据包的序号信息举例
下面先对本发明实施例中的UDP数据包的结构作说明以便于理解本发明实施例提供的方法。
本发明实施例中UDP数据包分为头部和数据部两部分。数据部承载的是具体的数据内容。头部长度为8字节,包括媒体数据传输类型(type)、帧序号(Frame ID)、帧内分片号(Inner ID)、帧内分片数(Frame Count)、编号(Sequence Number)和补齐项目(Padding)。其中,媒体数据传输类型包括原始数据(取值0)和重传数据(取值1),长度为4位,通过记录接收的数据包的类型可以分析出该时间段内的网络传输状况;帧序号表示该数据包属于哪个视频帧,取值为0-65535,长度为65536位;帧内分片号表示该数据包为一帧内的第几片数据,取值为0-4095,长度为4096位;帧内分片数表示该数据包属于的视频帧被分割的数据包总片数,长度为4096位,取值为0-4095;编号表示该数据包在被传输的视频中的序列号,通过补齐项目补齐字节,使得UDP头部的长度满足8字节。
重发请求的结构可以是,例如,包括请求总长度(Message Total Length)、重发数据类型(Retransmission)、序号(Number)和索引(Index)。其中,请求总长度的长度为16位;重发数据类型可以是例如语音、视频等类型,长度为32位;序号指丢失数据包在该重发请求中对应的顺序,由于重发请求对应的丢失数据包可以为一个,也可以为多个,当重发请求中请求重新发送的数据包的数量为多个例如3个时,序号为0-2。索引内记录的是丢失数据包的编号,便于发送端根据该重发请求找到相应的丢失数据包。
本实施例的步骤10中,接收端设置有接收缓冲区,可以对接收到的UDP数据包按照序号信息进行先后排序,并在接收缓冲区内缓冲一段时间后经过组合、解析等过程后再进行视频的播放。这样可以减少视频动作加快或者放慢的现象发生。接收端接收来自发送端的UDP数据包后,将该数据包的序号信息与已缓存在接收缓冲区内的UDP数据包的序号信息进行比较,再根据多种丢包确认机制来确定丢失的数据包。时间最新不是指接收时间最新,而是指该数据包所属视频帧对应的播放时间最新,也即该数据包的编号数值最大。步骤20中,在步骤10确定了丢失数据包后,向发送端发送对应于丢失数据包的UDP重发请求。该重发请求至少包括丢失数据包(一个或多个UDP数据包)的编号以使得发送端根据该编号将编号对应的数据包再次向接收端发送。因此,发送端中可以设置发送缓冲区,用于存放一段时间已发送的UDP数据包,以使得接收端确定了丢失数据包并将重发请求发送至发送端后,发送端可以从发送缓冲区中快速定位需要重新发送的丢失数据包。
具体地,发送缓冲区可以为固定长度(1024的幂次倍)的数组,用于存放一段时间已发送的数据,以在发送端接收到接收端发送的重发请求后从发送缓冲区直接重新发送相应的数据包。缓存的规则是用收到数据包的编号和队列最大长度做取模运算,得到的结果作为队列的数组下标,并根据该数组下标存放数据包,记录存放时间。存放有效时间T用来判断是否为过期数据,超过存放有效时间T的数据为过期数据。过期的数据不需要删除,会被后面的有效数据直接覆盖掉。有效时间T跟队列的最大长度有关。队列的最大长度不得超过数据包的最大编号值。上述发送缓冲区可以不用动态维护队列长度,减少内存申请释放,有效避免内存泄漏。队列的插入和查找时间复杂度为O(1),节省了CPU的计算资源。
相应地,接收缓冲区的数据结构与发送缓冲区类似,唯一不同的是添加了两个指针变量:读指针和写指针。读写指针之间的数据包编号应该是连续的,如果不连续即数据包丢失,接收端需要生成相关的重发请求发送给发送端。
本发明实施例提供的视频数据传输方法,通过使用UDP协议来传输视频数据,避免了TCP协议繁重的三次握手、四次挥手和各种繁杂的传输特性,使得传输数据尤其是音视频数据的实时性大大提高。且本发明实施例通过对丢失的数据包进行重发,保证了数据传输时的可靠性。由于只对丢失的数据包进行重新传输,不会将已接收的数据舍弃后再次传输,实现了数据的选择性重发,降低了数据大量重发时发生网络堵塞严重、数据乱序和丢失的风险,也避免了带宽浪费。通过接收缓冲区将乱序的数据进行排序和缓冲,减少了视频播放失真的情况,提升了装置性能。此外,本发明确定丢失数据包的丢包确认机制至少有两种,完善了确定丢失数据包的场景,增加了对丢失数据包进行重发的可能性,加强了在不同网络状态下的丢包管理。
在上述实施例中,当所述至少两种丢包确认机制中的其中一种丢包确认机制确定的丢失数据包中包括其中另一种丢包确认机制已确定为丢失数据包的UDP数据包时,从其中一种丢包确认机制所确定的丢失数据包中除去其中另一种丢包确认机制已确定的UDP数据包,将剩余的数据包确定为需要发送UDP重发请求的丢失数据包。
本实施例中,当一种丢包确认机制确定的丢失数据包与另一种丢包确认机制已确定的丢失数据包有重合时,若将二者确定的丢失数据包都进行重发,则发生重合的数据包部分对应的重发请求会被发送至少两次,这会对网络带宽造成不必要的浪费,严重时会导致网络发生堵塞从而导致数据包丢包现象更加严重。因此,为避免这种情况发生,需要从(时间上)后确定的丢失数据包中除去重合的丢失数据包,将剩余的数据包作为(时间上)后确定的真正的(需要发送相应的UDP重发请求的)丢失数据包。
本实施例通过将前后两种丢包确认机制确定的丢失数据包中除去重合的数据包部分,再发送剩余数据包的相应重发请求,可以避免对重复的丢失数据包进行重发,减少了资源浪费,降低了数据大量重发时发生网络堵塞严重、数据乱序和丢失的风险。
上述实施例中,所述至少两种丢包确认机制中的其中一种机制A包括:
当所述第一UDP数据包的第一编号与所述第二UDP数据包的第二编号不连续且所述第一编号大于所述第二编号时,若在预定超时时间内未接收到所述第一编号与所述第二编号之间的编号对应的其他UDP数据包,则将所述其他UDP数据包确定为丢失数据包。
本实施例中,由于第二UDP数据包在接收缓冲区内时间最新即编号最大,因此,当第一UDP数据包的编号大于第二UDP数据包的编号且第一UDP数据包的编号与第二UDP数据包的编号不连续时,表明第一UDP数据包和第二UDP数据包之间的数据包在接收端接收第一UDP数据包的时刻未到达接收端。造成这种情况至少有两种原因,其一是:原本应该比编号大于第二UDP数据包且小于第一UDP数据包的数据包晚到达接收端,由于发生了数据乱序,第一UDP数据包提早到达了接收端。其二是:编号在第一UDP数据包和第二UDP数据包之间的各数据包在传输过程中丢失。为避免第一种原因下还对这些数据包进行重发,导致带宽浪费和网络拥塞,需在接收到第一UDP数据包之后,等待预定超时时间,若在该预定超时时间内编号在第一UDP数据包和第二UDP数据包之间的数据包还是没有到达接收端,则此时可以确定这些数据包为已丢失的数据包。
作为一个示例,假设接收缓冲区内时间最新(即编号最大)的第二UDP数据包其编号为6,接收到的第一UDP数据包编号为10,则第一UDP数据包和第二UDP数据包之间编号为7、8、9的数据包还没被接收端接收。等待预定超时时间,若在此预定超时时间内接收端未接收到数据包7、8、9,则将数据包7、8、9确定为丢失数据包;若在此预定超时时间内接收到了数据包7、8、9中的任意一个或多个数据包,则在本次丢包确认过程中第一UDP数据包和第二UDP数据包之间没有丢失的数据包。
本实施例中,等待预定超时时间是为了确认这些编号对应的数据包是否真的已丢失。因为通过UDP协议传输数据是无序的,导致接收端接收到的UDP数据包可能是乱序的。如果确认了第一编号和第二编号不连续就立即发送重发请求要求发送端重传,可能会使第一编号和第二编号之间的编号对应的数据包在被发送至接收端的过程当中又被发送了一次,从而造成带宽浪费和网络拥塞。因此,实施例中的丢包确认机制在等待预定超时时间后再确定丢失数据包,在网络状况较好时基本能够满足大部分的数据丢包管理,可以减少发生带宽浪费和网络拥塞的风险,提升装置性能。
上述实施例中,所述至少两种丢包确认机制中的其中一种机制B包括:
若所述第一UDP数据包的第一帧序号与所述第二UDP数据包的第二帧序号不同且所述第一UDP数据包的第一编号大于所述第二UDP数据包的第二编号,等待预定帧超时时间,将所述第一帧序号对应的UDP数据包中未接收到的UDP数据包确定为丢失数据包。
本实施例中,预定帧超时时间可以理解为一个视频帧从第一个数据包被接收起到最后一个数据包被接收结束所用时间的最大时间阈值。当视频帧被接收的时间超过该阈值,表明该视频帧内的部分数据包可能已丢失。
具体来讲,由于第二UDP数据包在接收缓冲区内时间最新即编号最大,因此,当第一UDP数据包的编号大于第二UDP数据包的编号且第一UDP数据包的帧序号不同于第二UDP数据包的帧序号时,表明第一UDP数据包与第二UDP数据包不属于同一视频帧,且第一UDP数据包是其所在视频帧对应的各个数据包中第一个被接收端接收的数据包。当接收端接收到了该视频帧中的第一个数据包(不一定是该视频帧中编号最小的数据包,因为数据包有可能乱序到达接收端)时,若从此数据包的接收时间开始计时,在预定帧内超时时间内该视频帧对应的各个数据包中存在未到达接收端(即未被接收端接收)的数据包,说明这些未到达的数据包可能已在传输过程或解析过程中丢失。由此可以将这些在预定帧内超时时间内未到达接收端的数据包确定为丢失数据包。
继续以上述示例为例,假设每个视频帧都被切分为了4片,接收的第一UDP数据包的帧序号为3,编号为10;接收缓冲区内时间最新(编号最大)的第二UDP数据包的帧序号为2,编号为6。数据包10是帧序号为3的数据包中第一个被接收的数据包。从接收数据包10的时刻起,等待预定帧超时时间,若在此等待期间没有接收到编号为8、9、11的数据包,则将编号为8、9、11对应的三个数据包确定为丢失数据包;或者,若在此等待期间接收到了三个数据包中的任意一个或多个例如只接收到了数据包8,则将未接收到的数据包9和11确定为丢失数据包。即,从第一个帧序号为3的数据包被接收时算起,将经过预定帧超时时间后还未接收的帧序号为3的数据包确定为丢失数据包。
本实施例中的丢包确认机制适用于在极端网络情况下的连续丢包的情况,或者由于帧率比较低导致发送频率不均匀的情况,能够有效提高由于发送端发送不均匀到达时序不稳定之下的补发的效率,减少一帧中后接收的数据包接收时刻较迟,导致根据其他丢包确认机制重发的数据包较上一帧图像过分延迟,从而使画面显示发生明显卡顿的现象发生的风险,提高了视频播放的实时性,降低了装置负担。
应当理解的是,该丢包确认机制中的预定帧超时时间应大于上一丢包确认机制中的预定超时时间。预定超时时间和预定帧超时时间的具体数值可以根据实时的网络状况来确定,例如考虑到某一时刻的网络抖动时间来确定该时刻的预定超时时间和预定帧超时时间,关于网络抖动时间的具体确定过程,现有技术中已有相关的技术,本发明在此不再赘述。
此外,若各个视频帧中的分片数相等,则每个帧对应的预定帧超时时间相同;若各个视频帧中的分片数不全部相同,则每个帧对应的预定帧超时时间与各自的分片数相关,分片数越多,预定帧超时时间越长。
在上述实施例中,所述至少两种丢包确认机制中的其中一种机制C包括:
若所述第一UDP数据包的第一帧序号与所述第二UDP数据包的第二帧序号不连续且所述第一UDP数据包的第一编号大于所述第二UDP数据包的第二编号,至少基于与所述第二帧序号连续的帧序号对应的UDP数据包确定丢失数据包。
由于第二UDP数据包的编号是接收缓冲区内数值最大的,因此当接收端接收的来自发送端的第一UDP数据包的帧序号与第二UDP数据包的帧序号不连续时,可以得知此时接收端隔帧接收了数据包。又由于传输一个视频帧的时间并不短,即使因为网络原因使得第一UDP数据包提早到达接收端,第一帧序号和第二帧序号之间的帧序号对应的各数据包此时也应该至少有部分到达接收端,故而此时可以确定,第一UDP数据包所在视频帧和第二UDP数据包所在视频帧之间的视频帧已丢失。
作为一个示例,假设当前时刻接收到的第一UDP数据包的帧序号为7。此时,接收缓冲区内时间最新的第二UDP数据包的帧序号为4。由于接收缓冲区内时间最新的数据包的帧序号为4,表明接收端在当前时刻还未接收到帧序号为5或6的任一数据包。然而视频播放时,是严格按照数据包内部的时间戳进行的,即播放完帧序号为4对应的所有数据包即第五视频帧(第一视频帧的序号为0)后,要立即播放帧序号为5对应的所有数据包即第六视频帧。帧序号为7的第一UDP数据包即使在当前时刻提早到达,也无法对其进行播放。而接收端在接收了帧序号为7的第一UDP数据包的时刻,都没有接收到帧序号为5对应的各数据包,表明帧序号为5对应的各数据包可能因为网络原因等已丢失。此时接收端可以确定帧序号为5对应的各数据包为丢失数据包,向发送端发送相应的重发请求。本实施例是对第二帧序号(本例中为4)和第一帧序号(本例中为7)之间接续第二帧序号的帧序号(本例中为5)对应的各数据包生成重发请求,本发明也可以将第二帧序号(本例中为4)和第一帧序号(本例中为7)之间所有的帧序号(本例中为5和6)对应的各数据包确定为丢失数据包以生成相应的重发请求发送至发送端,本发明对此不做限制。
本实施例是基于帧层面的连续性来确定丢失数据包以生成重发请求的。通过将第一UDP数据包的第一帧序号和接收缓冲区内时间最新的第二UDP数据包的第二帧序号进行对比,将二者之间的、与第二帧序号连续的帧序号对应的数据包确定为丢失数据包,可以在网络发生拥塞或异常时快速地作出反应,有效地抗击由于网络状况引起的连续大片丢包造成的数据包丢失问题,最大化地提升数据传输的实时性,使视频的卡顿、延迟等现象发生的可能性降到最低,降低了装置负担。
在上述实施例中,步骤S20根据所确定的丢失数据包,向发送端发送的相应的UDP重发请求可以包括:
将所述重发请求以预定时间间隔重复发送至所述发送端,并记录所述重发请求从第一次发送开始计算的已发送时间及发送次数;
当所述重发请求的已发送时间达到预定时间间隔时,确定是否接收到所述丢失数据包中的任一数据包;
-若是,则停止发送所述重发请求;
-否则,确定所述重发请求的发送次数是否达到发送次数阈值,或者所述重发请求的已发送时间是否大于超时时间阈值;
--当所述重发请求的发送次数达到发送次数阈值或者所述重发请求的已发送时间大于超时时间阈值时,停止发送所述重发请求。
本实施例通过将重发请求重复发送,增加了接收丢失数据包的可能性,适时保证了视频的画面质量。并通过设定重发次数阈值和重发超时时间阈值,适时减少了大量重发数据造成带宽浪费和网络拥塞的情况。
应当理解的是,在上述实施例中,若两种丢包确认机制确定的丢失数据包发生重合时,需要从后确定的丢失数据包中除去发生重合的且该重合的丢失数据包对应的重发请求的发送时间小于预定时间间隔。若重合的丢失数据包对应的重发请求的发送时间大于预定时间间隔,则不必从后确定的丢失数据包中除去。预定时间间隔的时间值应至少大于发送端和接收端之间的往返时延。
可选地,当编码器请求发送端发送新的视频帧时,如果时延大于拥塞阈值,则可认为网络发生拥塞,此时根据最近20秒接收端确认收到的数据大小计算一个带宽值,并把这个带宽值反馈给编码器,编码器收到反馈后,可根据带宽调整编码码率。如果多次发生要求降低码率的反馈,则可以缩小图像的分辨率来保证视频的流畅性和实时性。由于网络可能会发生阶段性拥塞,过后却恢复正常,可以设置一个定时器来定时检查发送端的重发数据包数量和时延,如果发现网络恢复正常,则可以逐步增大编码器编码码率,使发送端发送的视频帧恢复到指定的分辨率和清晰度。
下面以具体实施例对本发明实施例提供的数据传输方法及装置进行说明。其中,假设每个视频帧具有5个分片,即5个数据包。则前四帧(帧序号为0-3)中各UDP数据包的编号分别为0-4、5-9、10-14和15-19。
假设往返时延RTT为60ms,预定时间间隔为60ms,预定超时时间RTO为40ms,预定帧超时时间为120ms,重发时间阈值Max RTO为200ms,重发次数为4次,相邻视频帧发送间隔为60ms。
接收端已接收了数据包0、1、2,其中第一个数据包的接收时间为t=30ms。
t=60ms时确认接收数据包3。
t=100ms时,确认接收数据包8。
t=140ms时,由于数据包8和数据包3的编号不连续,且此时距离数据包8的接收时间经过了预定超时时间,因此丢包确定模块根据丢包确认机制A可确定数据包4、5、6、7为丢失数据包,接收端中的请求重发模块生成了对应于数据包4、5、6、7的UDP重发请求并向发送端发送该重发请求。
t=150ms时,距离第一帧(帧序号为0)内第一个数据包的接收时间已经过预定帧超时时间,丢包确定模块根据丢包确认机制B,确定数据包4为丢失数据包。然而数据包4已在t=140ms时根据丢包确认机制A被确定为丢失数据包,且此时距离数据包5的重发请求发送时间仅经过了10ms,未到达预定时间间隔60ms,因此此刻没有丢失数据包。
t=160ms时,接收端确认接收数据包5。
t=170ms时,接收端确认接收数据包6。
t=220ms时,距离第二帧(帧序号为1)内第一个数据包(数据包8)的接收时间(t=100ms)已经过预定帧超时时间120ms,根据丢包确认机制B,可确定数据包7和9为丢失数据包。接收端生成对应于数据包7和9的UDP重发请求并向发送端发送该重发请求。
t=300ms时,接收端确认接收数据包17。此时接收缓冲区内编号最大的数据包为数据包8。由于数据包8的帧序号为1,数据包17的帧序号为3,二者的帧序号不连续,因此根据丢包确认机制C,丢包确定模块可确定帧序号为2的数据包即数据包10、11、12、13、14为丢失数据包。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作合并,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
图2是本发明一实施例的视频数据传输装置的结构示意图。本发明所述的视频数据传输方法可以基于本实施例中的视频数据传输装置实施。如图2所示,该装置包括:
丢包确定模块21,用于基于接收到的第一UDP数据包的序号信息和与接收缓冲区内时间最新的第二UDP数据包的序号信息之间的连续性,并根据至少两种丢包确认机制确定丢失数据包,所述序号信息包括UDP数据包的编号和UDP数据包与所在视频帧有关的帧序号;
请求重发模块22,用于根据所确定的丢失数据包,向发送端发送相应的UDP重发请求。
本发明实施例提供的视频数据传输装置,通过使用UDP协议来传输视频数据,避免了TCP协议繁重的三次握手、四次挥手和各种繁杂的传输特性,使得传输数据尤其是音视频数据的实时性大大提高。且本发明实施例通过丢包确定模块确定丢失的数据包,并通过请求重发模块向发送端发送对丢失的数据包进行重发的请求,保证了数据传输时的可靠性。由于只对丢失的数据包进行重新传输,不会将已接收的数据舍弃后再次传输,实现了数据的选择性重发,降低了数据大量重发时发生网络堵塞严重、数据乱序和丢失的风险,也避免了带宽浪费。通过设置接收缓冲区将乱序的数据进行排序和缓冲,减少了视频播放失真的情况,提升了装置性能。此外,本发明确定丢失数据包的丢包确认机制至少有两种,完善了确定丢失数据包的场景,增加了对丢失数据包进行重发的可能性,加强了在不同网络状态下的丢包管理。
在一些实施方式中,丢包确定模块用于:
当所述至少两种丢包确认机制中的其中一种丢包确认机制确定的丢失数据包中包括其中另一种丢包确认机制已确定为丢失数据包的UDP数据包时,从其中一种丢包确认机制所确定的丢失数据包中除去其中另一种丢包确认机制已确定的UDP数据包,将剩余的数据包确定为丢失数据包。丢包确定模块
在一些实施方式中,丢包确定模块用于:
当所述第一UDP数据包的第一编号与所述第二UDP数据包的第二编号不连续且所述第一编号大于所述第二编号时,若在预定超时时间内未接收到所述第一编号与所述第二编号之间的编号对应的其他UDP数据包,则将所述其他UDP数据包确定为丢失数据包。
在一些实施方式中,丢包确定模块用于:
若所述第一UDP数据包的第一帧序号与所述第二UDP数据包的第二帧序号不同且所述第一UDP数据包的第一编号大于所述第二UDP数据包的第二编号,等待预定帧超时时间,将所述第一帧序号对应的UDP数据包中未接收到的UDP数据包确定为丢失数据包。
在一些实施方式中,丢包确定模块用于:
若所述第一UDP数据包的第一帧序号与所述第二UDP数据包的第二帧序号不连续且所述第一UDP数据包的第一编号大于所述第二UDP数据包的第二编号,至少基于与所述第二帧序号连续的帧序号对应的UDP数据包确定丢失数据包。
本发明实施例提供了一种非易失性计算机存储介质,所述计算机存储介质存储有计算机可执行指令,该计算机可执行指令可执行上述任意方法实施例中的视频数据传输方法;
作为一种实施方式,本发明的非易失性计算机存储介质存储有计算机可执行指令,所述计算机可执行指令设置为:
基于接收到的第一UDP数据包的序号信息和与接收缓冲区内时间最新的第二UDP数据包的序号信息之间的连续性,并根据至少两种丢包确认机制确定丢失数据包;
根据所确定的丢失数据包,向发送端发送相应的UDP重发请求。
作为一种非易失性计算机可读存储介质,可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块,如本发明实施例中的视频数据传输方法对应的程序指令/模块(例如,附图2所示的丢包确定模块21和请求重发模块22)。所述一个或者多个模块存储在所述非易失性计算机可读存储介质中,当被处理器执行时,执行上述任意方法实施例中的视频数据传输方法。
非易失性计算机可读存储介质可以包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需要的应用程序;存储数据区可存储根据视频数据传输装置的使用所创建的数据等。此外,非易失性计算机可读存储介质可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中,非易失性计算机可读存储介质可选包括相对于处理器远程设置的存储器,这些远程存储器可以通过网络连接至视频数据传输装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
特别地,本申请还提供了一种计算机程序产品,包括至少一个非易失性计算机存储介质,所述非易失性计算机存储介质具有存储在其中的计算机可执行程序代码指令,所述计算机可执行程序代码指令能够执行上述任意方法实施例中的视频数据传输方法。
本发明实施例中可以通过硬件处理器(hardware processor)来实现相关功能模块。
图3是本发明一实施例提供的实施视频数据传输方法的电子设备即持续集成服务器的结构示意图。如图3所示,该设备包括:
一个或多个处理器310以及存储器320,图3中以一个处理器310为例。
视频数据传输装置还可以包括:输入装置330和输出装置340。
处理器310、存储器320、输入装置330和输出装置340可以通过总线或者其他方式连接,图3中以通过总线连接为例。
存储器320为上述的非易失性计算机可读存储介质。处理器310通过运行存储在存储器320中的非易失性软件程序、指令以及模块,从而执行服务器的各种功能应用以及数据处理,即实现上述方法实施例所示视频数据传输方法。
输入装置330可接收输入的数字或字符信息,以及产生与视频数据传输装置的用户设置以及功能控制有关的键信号输入。输出装置340可包括显示屏等显示设备。
上述产品可执行本发明实施例所提供的方法,具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节,可参见本发明实施例所提供的方法。
作为一种实施方式,上述电子设备包括:至少一个处理器;以及,与所述至少一个处理器通信连接的存储器;其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够:
基于接收到的第一UDP数据包的序号信息和与接收缓冲区内时间最新的第二UDP数据包的序号信息之间的连续性,并根据至少两种丢包确认机制确定丢失数据包;
根据所确定的丢失数据包,向发送端发送相应的UDP重发请求。
本发明实施例的电子设备以多种形式存在,包括但不限于:
(1)移动通信设备:这类设备的特点是具备移动通信功能,并且以提供话音、数据通信为主要目标。这类终端包括:智能手机(例如iPhone)、多媒体手机、功能性手机,以及低端手机等。
(2)超移动个人计算机设备:这类设备属于个人计算机的范畴,有计算和处理功能,一般也具备移动上网特性。这类终端包括:PDA、MID和UMPC设备等,例如iPad。
(3)便携式娱乐设备:这类设备可以显示和播放多媒体内容。该类设备包括:音频、视频播放器(例如iPod),掌上游戏机,电子书,以及智能玩具和便携式车载导航设备。
(4)服务器:提供计算服务的设备,服务器的构成包括处理器、硬盘、内存、系统总线等,服务器和通用的计算机架构类似,但是由于需要提供高可靠的服务,因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。
(5)其他具有数据交互功能的电子装置。
需要说明的是,本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于一计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(ROM)或随机存储记忆体(RAM)等。
以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
通过以上的实施例的描述,本领域的技术人员可以清楚地了解到各实施例可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
本领域内的技术人员应明白,本发明的实施例可提供为方法、装置、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令系统的制造品,该指令系统实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种视频数据传输方法,包括:
基于接收到的第一UDP数据包的序号信息和与接收缓冲区内时间最新的第二UDP数据包的序号信息之间的连续性,并根据至少两种丢包确认机制确定丢失数据包,所述序号信息包括UDP数据包的编号和UDP数据包与所在视频帧有关的帧序号;
根据所确定的丢失数据包,向发送端发送相应的UDP重发请求。
2.根据权利要求1所述的方法,其中,当所述至少两种丢包确认机制中的其中一种丢包确认机制确定的丢失数据包中包括其中另一种丢包确认机制已确定为丢失数据包的UDP数据包时,从其中一种丢包确认机制所确定的丢失数据包中除去其中另一种丢包确认机制已确定的UDP数据包,将剩余的数据包确定为丢失数据包。
3.根据权利要求2所述的方法,其中,所述至少两种丢包确认机制中的其中一种包括:
当所述第一UDP数据包的第一编号与所述第二UDP数据包的第二编号不连续且所述第一编号大于所述第二编号时,若在预定超时时间内未接收到所述第一编号与所述第二编号之间的编号对应的其他UDP数据包,则将所述其他UDP数据包确定为丢失数据包。
4.根据权利要求2所述的方法,其中,所述至少两种丢包确认机制中的其中一种包括:
若所述第一UDP数据包的第一帧序号与所述第二UDP数据包的第二帧序号不同且所述第一UDP数据包的第一编号大于所述第二UDP数据包的第二编号,等待预定帧超时时间,将所述第一帧序号对应的UDP数据包中未接收到的UDP数据包确定为丢失数据包。
5.根据权利要求2中所述的方法,其中,所述至少两种丢包确认机制中的其中一种包括:
若所述第一UDP数据包的第一帧序号与所述第二UDP数据包的第二帧序号不连续且所述第一UDP数据包的第一编号大于所述第二UDP数据包的第二编号,至少基于与所述第二帧序号连续的帧序号对应的数据包确定丢失数据包。
6.一种视频数据传输装置,包括:
丢包确定模块,用于基于接收到的第一UDP数据包的序号信息和与接收缓冲区内时间最新的第二UDP数据包的序号信息之间的连续性,并根据至少两种丢包确认机制确定丢失数据包,所述序号信息包括UDP数据包的编号和UDP数据包与所在视频帧有关的帧序号;
请求重发模块,用于根据所确定的丢失数据包,向发送端发送相应的UDP重发请求。
7.根据权利要求6所述的装置,其中,所述丢包确定模块用于:
当所述至少两种丢包确认机制中的其中一种丢包确认机制确定的丢失数据包中包括其中另一种丢包确认机制已确定为丢失数据包的UDP数据包时,从其中一种丢包确认机制所确定的丢失数据包中除去其中另一种丢包确认机制已确定的UDP数据包,将剩余的数据包确定为丢失数据包。
8.根据权利要求7所述的装置,其中,所述丢包确定模块用于:
当所述第一UDP数据包的第一编号与所述第二UDP数据包的第二编号不连续且所述第一编号大于所述第二编号时,若在预定超时时间内未接收到所述第一编号与所述第二编号之间的编号对应的其他UDP数据包,则将所述其他UDP数据包确定为丢失数据包。
9.根据权利要求7所述的装置,其中,所述丢包确定模块用于:
若所述第一UDP数据包的第一帧序号与所述第二UDP数据包的第二帧序号不同且所述第一UDP数据包的第一编号大于所述第二UDP数据包的第二编号,等待预定帧超时时间,将所述第一帧序号对应的UDP数据包中未接收到的UDP数据包确定为丢失数据包。
10.根据权利要求7中所述的装置,其中,所述丢包确定模块用于:
若所述第一UDP数据包的第一帧序号与所述第二UDP数据包的第二帧序号不连续且所述第一UDP数据包的第一编号大于所述第二UDP数据包的第二编号,至少基于与所述第二帧序号连续的帧序号对应的数据包确定丢失数据包。
CN201611106405.9A 2016-12-05 2016-12-05 视频数据传输方法及装置 Pending CN106792262A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201611106405.9A CN106792262A (zh) 2016-12-05 2016-12-05 视频数据传输方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611106405.9A CN106792262A (zh) 2016-12-05 2016-12-05 视频数据传输方法及装置

Publications (1)

Publication Number Publication Date
CN106792262A true CN106792262A (zh) 2017-05-31

Family

ID=58878856

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611106405.9A Pending CN106792262A (zh) 2016-12-05 2016-12-05 视频数据传输方法及装置

Country Status (1)

Country Link
CN (1) CN106792262A (zh)

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107454466A (zh) * 2017-08-11 2017-12-08 中广热点云科技有限公司 一种视频数据处理方法
CN107613583A (zh) * 2017-10-25 2018-01-19 上海海洋大学 一种分布式无线传感器网络数据汇总网关
CN107809415A (zh) * 2017-08-07 2018-03-16 国网河南省电力公司 基于双单向通道传输技术的网络隔离系统及其实现方法
CN107911668A (zh) * 2017-11-29 2018-04-13 天津聚飞创新科技有限公司 无线图传系统及方法
CN108322836A (zh) * 2018-01-24 2018-07-24 北京奇艺世纪科技有限公司 一种数据传输的方法及装置
CN108632559A (zh) * 2017-09-18 2018-10-09 北京视联动力国际信息技术有限公司 一种视频数据处理方法及装置
CN109274554A (zh) * 2018-09-28 2019-01-25 中国科学院长春光学精密机械与物理研究所 图像数据丢包测试方法、装置、设备以及可读存储介质
CN109560901A (zh) * 2018-11-14 2019-04-02 广州虎牙信息科技有限公司 一种数据重传方法、装置、终端设备及存储介质
CN109729396A (zh) * 2017-10-31 2019-05-07 华为技术有限公司 视频分片数据传输方法和装置
CN109847342A (zh) * 2019-03-19 2019-06-07 Oppo广东移动通信有限公司 网络检测方法及相关装置
CN110290224A (zh) * 2019-07-23 2019-09-27 北京达佳互联信息技术有限公司 资源上传、转发方法及装置、移动终端、网关和存储介质
CN111147884A (zh) * 2020-01-02 2020-05-12 广州虎牙科技有限公司 数据处理方法、装置、系统、用户端及存储介质
CN112492118A (zh) * 2018-06-21 2021-03-12 深圳市道通智能航空技术有限公司 数据传输控制方法、信息发送端、接收端及飞行器图传系统
CN112637162A (zh) * 2020-12-14 2021-04-09 上海金仕达软件科技有限公司 一种udp数据包处理方法及装置
CN112702411A (zh) * 2020-12-21 2021-04-23 上汽大通汽车有限公司 一种解决cantp多帧丢包重传的方法
CN112738417A (zh) * 2020-12-24 2021-04-30 浙江赫千电子科技有限公司 一种车载视频的数据采集存储显示方法
CN112769708A (zh) * 2019-11-05 2021-05-07 北京华为数字技术有限公司 数据传输的方法、装置及计算机可读存储介质
CN112969075A (zh) * 2021-01-29 2021-06-15 北京字节跳动网络技术有限公司 直播过程中的补帧方法、装置及计算设备
CN112996053A (zh) * 2019-12-16 2021-06-18 成都鼎桥通信技术有限公司 语音数据包的重排序方法、装置及设备
CN113064888A (zh) * 2021-03-25 2021-07-02 珠海格力电器股份有限公司 数据校对方法、装置和系统、服务器、设备
CN113132065A (zh) * 2019-12-30 2021-07-16 西安诺瓦星云科技股份有限公司 数据通信方法、装置及系统、存储介质和视频处理设备
CN113489575A (zh) * 2021-06-25 2021-10-08 阿波罗智联(北京)科技有限公司 一种数据传输方法、装置及电子设备
CN113708895A (zh) * 2020-05-21 2021-11-26 北京金山云网络技术有限公司 数据传输方法、装置及电子设备
CN113726811A (zh) * 2021-09-08 2021-11-30 苏州洛翌鑫珂智能科技有限公司 一种电梯视频监控数据传输的丢包补偿方法
CN113765726A (zh) * 2020-06-02 2021-12-07 中国移动通信集团安徽有限公司 S1-u口数据包丢包数的统计方法、装置及计算设备
CN114024914A (zh) * 2021-10-27 2022-02-08 杭州海康威视数字技术股份有限公司 视频数据传输方法、装置及电子设备
CN114051173A (zh) * 2021-10-09 2022-02-15 广州广哈通信股份有限公司 一种基于rtp扩展头部的视频帧可靠传输方法、装置及设备
CN114584264A (zh) * 2022-01-29 2022-06-03 天津瑞发科半导体技术有限公司 具有物理层重传和实时传输功能的视频传输系统
CN115038115A (zh) * 2022-06-21 2022-09-09 美的集团股份有限公司 数据传输方法、装置、电子设备、存储介质和产品
CN115297335A (zh) * 2022-08-03 2022-11-04 深圳市野草声学有限公司 基于接收缓冲区的视频直播时的音频传输方法及系统
CN115550606A (zh) * 2022-08-31 2022-12-30 合肥埃科光电科技股份有限公司 一种基于网络协议的图像采集系统及方法
CN115776357A (zh) * 2022-11-22 2023-03-10 厦门鸿谷智芯科技有限公司 一种实现Can数据透传质量提升的方法及其装置
CN115942010A (zh) * 2022-11-11 2023-04-07 北京奇艺世纪科技有限公司 一种质量评估结果获取方法、装置、服务器及存储介质
WO2023179538A1 (zh) * 2022-03-23 2023-09-28 维沃移动通信有限公司 数据传输方法、装置、电子设备和存储介质

Cited By (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107809415A (zh) * 2017-08-07 2018-03-16 国网河南省电力公司 基于双单向通道传输技术的网络隔离系统及其实现方法
CN107454466A (zh) * 2017-08-11 2017-12-08 中广热点云科技有限公司 一种视频数据处理方法
CN107454466B (zh) * 2017-08-11 2019-07-05 中广热点云科技有限公司 一种视频数据处理方法
CN108632559A (zh) * 2017-09-18 2018-10-09 北京视联动力国际信息技术有限公司 一种视频数据处理方法及装置
CN107613583B (zh) * 2017-10-25 2021-08-06 上海海洋大学 一种分布式无线传感器网络数据汇总网关
CN107613583A (zh) * 2017-10-25 2018-01-19 上海海洋大学 一种分布式无线传感器网络数据汇总网关
CN109729396A (zh) * 2017-10-31 2019-05-07 华为技术有限公司 视频分片数据传输方法和装置
CN109729396B (zh) * 2017-10-31 2022-03-11 华为技术有限公司 视频分片数据传输方法和装置
CN107911668B (zh) * 2017-11-29 2019-12-06 天津聚飞创新科技有限公司 无线图传系统及方法
CN107911668A (zh) * 2017-11-29 2018-04-13 天津聚飞创新科技有限公司 无线图传系统及方法
CN108322836A (zh) * 2018-01-24 2018-07-24 北京奇艺世纪科技有限公司 一种数据传输的方法及装置
CN112492118B (zh) * 2018-06-21 2023-11-17 深圳市道通智能航空技术股份有限公司 数据传输控制方法、信息发送端、接收端及飞行器图传系统
CN112492118A (zh) * 2018-06-21 2021-03-12 深圳市道通智能航空技术有限公司 数据传输控制方法、信息发送端、接收端及飞行器图传系统
CN109274554A (zh) * 2018-09-28 2019-01-25 中国科学院长春光学精密机械与物理研究所 图像数据丢包测试方法、装置、设备以及可读存储介质
CN109560901B (zh) * 2018-11-14 2021-09-21 广州虎牙信息科技有限公司 一种数据重传方法、装置、终端设备及存储介质
CN109560901A (zh) * 2018-11-14 2019-04-02 广州虎牙信息科技有限公司 一种数据重传方法、装置、终端设备及存储介质
US12042725B2 (en) 2019-03-19 2024-07-23 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method for network detection, electronic device, and non-transitory computer-readable storage medium
CN109847342A (zh) * 2019-03-19 2019-06-07 Oppo广东移动通信有限公司 网络检测方法及相关装置
CN110290224A (zh) * 2019-07-23 2019-09-27 北京达佳互联信息技术有限公司 资源上传、转发方法及装置、移动终端、网关和存储介质
CN110290224B (zh) * 2019-07-23 2022-05-24 北京达佳互联信息技术有限公司 资源上传、转发方法及装置、移动终端、网关和存储介质
CN112769708A (zh) * 2019-11-05 2021-05-07 北京华为数字技术有限公司 数据传输的方法、装置及计算机可读存储介质
CN112996053A (zh) * 2019-12-16 2021-06-18 成都鼎桥通信技术有限公司 语音数据包的重排序方法、装置及设备
CN113132065A (zh) * 2019-12-30 2021-07-16 西安诺瓦星云科技股份有限公司 数据通信方法、装置及系统、存储介质和视频处理设备
CN111147884A (zh) * 2020-01-02 2020-05-12 广州虎牙科技有限公司 数据处理方法、装置、系统、用户端及存储介质
CN113708895A (zh) * 2020-05-21 2021-11-26 北京金山云网络技术有限公司 数据传输方法、装置及电子设备
CN113765726A (zh) * 2020-06-02 2021-12-07 中国移动通信集团安徽有限公司 S1-u口数据包丢包数的统计方法、装置及计算设备
CN112637162A (zh) * 2020-12-14 2021-04-09 上海金仕达软件科技有限公司 一种udp数据包处理方法及装置
CN112702411B (zh) * 2020-12-21 2023-01-17 上汽大通汽车有限公司 一种解决cantp多帧丢包重传的方法
CN112702411A (zh) * 2020-12-21 2021-04-23 上汽大通汽车有限公司 一种解决cantp多帧丢包重传的方法
CN112738417A (zh) * 2020-12-24 2021-04-30 浙江赫千电子科技有限公司 一种车载视频的数据采集存储显示方法
CN112969075A (zh) * 2021-01-29 2021-06-15 北京字节跳动网络技术有限公司 直播过程中的补帧方法、装置及计算设备
CN113064888A (zh) * 2021-03-25 2021-07-02 珠海格力电器股份有限公司 数据校对方法、装置和系统、服务器、设备
CN113489575A (zh) * 2021-06-25 2021-10-08 阿波罗智联(北京)科技有限公司 一种数据传输方法、装置及电子设备
CN113726811A (zh) * 2021-09-08 2021-11-30 苏州洛翌鑫珂智能科技有限公司 一种电梯视频监控数据传输的丢包补偿方法
CN114051173A (zh) * 2021-10-09 2022-02-15 广州广哈通信股份有限公司 一种基于rtp扩展头部的视频帧可靠传输方法、装置及设备
CN114051173B (zh) * 2021-10-09 2023-08-08 广州广哈通信股份有限公司 一种基于rtp扩展头部的视频帧可靠传输方法、装置及设备
CN114024914B (zh) * 2021-10-27 2024-03-01 杭州海康威视数字技术股份有限公司 视频数据传输方法、装置及电子设备
CN114024914A (zh) * 2021-10-27 2022-02-08 杭州海康威视数字技术股份有限公司 视频数据传输方法、装置及电子设备
CN114584264A (zh) * 2022-01-29 2022-06-03 天津瑞发科半导体技术有限公司 具有物理层重传和实时传输功能的视频传输系统
WO2023179538A1 (zh) * 2022-03-23 2023-09-28 维沃移动通信有限公司 数据传输方法、装置、电子设备和存储介质
CN115038115A (zh) * 2022-06-21 2022-09-09 美的集团股份有限公司 数据传输方法、装置、电子设备、存储介质和产品
CN115297335A (zh) * 2022-08-03 2022-11-04 深圳市野草声学有限公司 基于接收缓冲区的视频直播时的音频传输方法及系统
CN115297335B (zh) * 2022-08-03 2024-05-14 深圳市野草声学有限公司 基于接收缓冲区的视频直播时的音频传输方法及系统
CN115550606A (zh) * 2022-08-31 2022-12-30 合肥埃科光电科技股份有限公司 一种基于网络协议的图像采集系统及方法
CN115942010A (zh) * 2022-11-11 2023-04-07 北京奇艺世纪科技有限公司 一种质量评估结果获取方法、装置、服务器及存储介质
CN115942010B (zh) * 2022-11-11 2024-07-19 北京奇艺世纪科技有限公司 一种质量评估结果获取方法、装置、服务器及存储介质
CN115776357A (zh) * 2022-11-22 2023-03-10 厦门鸿谷智芯科技有限公司 一种实现Can数据透传质量提升的方法及其装置

Similar Documents

Publication Publication Date Title
CN106792262A (zh) 视频数据传输方法及装置
Mittal et al. Revisiting network support for RDMA
US10791054B2 (en) Flow control and congestion management for acceleration components configured to accelerate a service
CN106134147A (zh) 实现请求管理器和连接管理器功能的传输加速器
CN106416179A (zh) 实现扩展传输控制功能的传输加速器
CN104735077B (zh) 一种使用环形缓存和环形队列实现udp高效并发的方法
CN104579601B (zh) 一种重传请求处理方法和装置
WO2016033948A1 (zh) 一种发送窗口流量控制方法和终端
CN108809859A (zh) 一种面向数据包截止时间的传输层控制方法
EP3563535B1 (en) Transmission of messages by acceleration components configured to accelerate a service
WO2023093879A1 (zh) 数据传输方法、装置、设备和介质
CN109951260A (zh) 一种数据包发送方法及相关设备
CN107613409A (zh) 多媒体数据的处理方法及装置
CN104468509A (zh) 手机网络游戏数据传输的方法、系统和手机用户端
CN113676605A (zh) 数据传输方法、装置、设备及计算机可读存储介质
Al Osman et al. Alphan: Application layer protocol for haptic networking
JP7123194B2 (ja) データ送信方法、送信デバイス、データ受信方法、および受信デバイス
US9590909B2 (en) Reducing TCP timeouts due to Incast collapse at a network switch
WO2023078222A1 (zh) 数据传输方法、装置、设备和介质
CN113242318B (zh) 数据传输方法和电子设备
CN106341348B (zh) 一种面向tcp业务的流量控制方法及接入网网元
Khalid et al. Optimal latency in collaborative virtual environment to increase user performance: A survey
Gokhale et al. On QoS-compliant telehaptic communication over shared networks
WO2017063589A1 (zh) 数据传输的方法及装置
Mittal Towards a More Stable Network Infrastructure

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20170531