CN107231328B - 实时视频传输方法、装置、设备及*** - Google Patents

实时视频传输方法、装置、设备及*** Download PDF

Info

Publication number
CN107231328B
CN107231328B CN201610167888.7A CN201610167888A CN107231328B CN 107231328 B CN107231328 B CN 107231328B CN 201610167888 A CN201610167888 A CN 201610167888A CN 107231328 B CN107231328 B CN 107231328B
Authority
CN
China
Prior art keywords
key frame
frame
sending
data
video
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
CN201610167888.7A
Other languages
English (en)
Other versions
CN107231328A (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.)
Fujian Star Net Communication Co Ltd
Original Assignee
Fujian Star Net Communication 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 Fujian Star Net Communication Co Ltd filed Critical Fujian Star Net Communication Co Ltd
Priority to CN201610167888.7A priority Critical patent/CN107231328B/zh
Publication of CN107231328A publication Critical patent/CN107231328A/zh
Application granted granted Critical
Publication of CN107231328B publication Critical patent/CN107231328B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • 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/637—Control signals issued by the client directed to the server or network components
    • H04N21/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • 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/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

本发明属于流媒体数据网络传输技术领域，具体涉及一种实时视频传输方法、装置、设备及***。本发明的实时视频传输方法包括：发送端将视频帧数据编码为关键帧或非关键帧，发送RTP数据包给接收端；接收端对RTP数据包进行处理，若处理成功，则显示视频帧，若处理失败，则发送重编关键帧或重传关键帧中缺失的RTP数据请求给发送端；发送端接收后，重编关键帧并修改关键帧的发送时机后向接收端发送，或向接收端重传关键帧中缺失的RTP数据；重复上述步骤1‑3直至所有视频帧数据传输完成。本方法在数据处理中采用了重传关键帧中缺失的RTP数据，丢弃不完整非关键帧数据的方式保证视频质量，同时采用双缓冲区，提高了数据处理效率，降低了实时视频数据的显示延时。

Description

实时视频传输方法、装置、设备及***
技术领域
本发明属于流媒体数据网络传输技术领域，具体涉及一种实时视频传输方法、装置、设备及***。
背景技术
随着网络技术的不断发展，人们对于实时视频业务等占用较大带宽的网络通信业务的需求不断加强。目前常见的传输实时视频流的做法是通过将TS(Transport Stream，传输流)承载在RTP(Real-time Transport protocol，实时传输协议)上，而RTP底层使用UDP(User Datagram Protocol，用户数据报协议)进行传输，目前大量的使用wifi及3G、4G等无线网络通信连接互联网，由于UDP本身是不可靠传输协议，以及无线网络的相对不稳定性，不可避免的造成部分RTP数据丢失。
为了解决RTP丢包问题，IETF(The Internet Engineering Task Force，国际互联网工程任务组)分别制订了FEC(前向纠错，也叫前向纠错码)和NACK(协商确认，起到丢包重传的作用)两种算法来解决这个问题。但是，使用FEC算法会增加数据的冗余，加大流媒体数据的占用带宽。NACK算法引入了确认重传，会导致实时性较差。
根据现有技术常用的视频压缩编码算法，视频画面被编码为内部编码帧(I帧，又称关键帧)、多个前向预测帧(P帧)和双向内插帧(B帧)组成的图像序列。关键帧通常是每个GOP(Group of Pictures,画面组)的第一个帧，经过适度地压缩，做为随机访问的参考点，可以当成图像。P帧由在它前面的P帧和I帧预测而来，视频数据传输的过程中，由于数据丢失，会造成视频无法显示或显示模糊、卡顿，如果I帧数据不完整，会造成解码失败，无法显示视频画面，如果P帧丢失会影响到后面P帧的解码显示，使画面出现马赛克，P帧丢失的越多，马赛克越严重。在进行传输过程中，丢弃B帧数据包对于整个视频的解码显示影响很小。
申请号为201410577593.8的中国专利，公开了一种视频传输方法，通过获取当前网络传输质量信息，查找对应的视频编码参数，根据视频编码参数去除图片帧信息，再调整视频的码率和帧率，对视频编码后进行传输。该方法在网络质量下降时候调整了编码参数，降低了视频质量，导致视频画面的不清晰。另外，在网络质量经常变化情况下，该方法发送端会频繁地改变视频编码参数，进行相应的编码处理，导致处理效率的低下和处理延时的增大，影响接收端的用户体验。
发明内容
本发明的目的之一在于克服以上缺点，实现在网络质量出现下降的环境下，尽可能降低网络带宽的使用，同时保证视频的传输质量。
为了解决上述技术问题，本发明提供了一种实时视频传输方法，包括以下步骤：
步骤1：发送端将视频帧数据编码为关键帧或非关键帧，发送RTP数据包给接收端；所述关键帧的发送时机由配置的间隔参数确定；
步骤2：接收端对RTP数据包进行处理，若处理成功，则显示视频帧，若处理失败，则发送重编关键帧或重传关键帧中缺失的RTP数据请求给发送端；
步骤3：发送端接收后，重编关键帧并修改关键帧的发送时机后向接收端发送，或向接收端重传关键帧中缺失的RTP数据；
重复上述步骤1-3直至所有视频帧数据传输完成。
本发明提出动态的关键帧间隔，在网络质量正常的情况下通过设置较大的关键帧间隔，从而减少关键帧的数量，降低传输的总数据量；在网络质量下降导致数据处理失败的情况下，由接收端发送重编关键帧或重传关键帧中缺失的RTP数据包请求。对于重编关键帧请求，发送端根据请求动态地进行关键帧编码并修改关键帧发送时机，减少接收端视频恢复的等待时间，保证视频画面的及时恢复。
进一步地，所述步骤1，还包括：
发送端将已发送的RTP数据包放入发送数据缓冲区，当接收到重传关键帧中缺失的RTP数据请求时，优先查找所述发送数据缓冲区。
通过设置发送数据缓冲区，提高发送端重传关键帧中缺失的RTP数据时候查找数据的处理效率，缩短了处理时间。
进一步地，所述步骤2接收端对RTP数据包进行处理，具体为：
接收RTP数据包至接收数据缓冲区；
判断RTP数据包是否为请求重传关键帧中缺失的数据；
若非重传关键帧中缺失的RTP数据，进行正常数据帧处理；
若是重传关键帧中缺失的RTP数据，进行关键帧重处理。
进一步地，所述步骤2还包括：接收端设置等待缓冲区，用于缓存重传关键帧已接收的RTP数据包。
本发明的接收端采用了双缓冲区机制，等待缓冲区缓存重传关键帧已接收的RTP数据包，接收数据缓冲区可以继续接收后续的RTP数据包，进行组帧操作，当不完整的关键帧接收完整后，可以连续解码显示重传关键帧及后续的视频帧，减少由于等待重传数据造成的实时视频延时。
进一步地，所述接收端是根据设置的抖动延时从所述接收缓冲区读取RTP数据包。
通过添加抖动延时可缓解由于网络传输过程中造成的RTP数据包乱序的问题。
进一步地，所述正常数据帧处理，包括以下步骤：
对接收数据缓冲区中的RTP包进行组帧，并判断视频帧是否完整；
若视频帧完整，则进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败，并发送重编关键帧请求给发送端；
若视频帧不完整，则进一步判断视频帧是否为关键帧，若该视频帧为关键帧，将已接收的RTP数据包写入等待缓冲区，标记处理结果为失败，并发送重传关键帧中缺失的RTP数据请求给发送端，通知发送端重传关键帧中丢失的RTP数据；若该视频帧为非关键帧，则丢弃该视频帧，再判断两连续的关键帧之间已经抛弃的非关键帧数量是否达到阈值，若已经达到阈值，标记处理结果为失败，并发送重编关键帧请求给发送端，否则标记处理结果为成功。
上述技术方案在视频帧不完整的情况下，会根据视频帧的类型进行不同的处理：如果是关键帧则请求重传关键帧中缺失的RTP数据包，这样能够保证视频画面的完整性；如果是非关键帧且累计丢弃帧数在设置阀值范围内，则直接丢弃帧，等待下一个视频帧，这样处理的有益效果是减少重编关键帧的网络开销，保证视频的流畅度，而对视频画面的影响只有轻微马赛克或较小的延时；如果累计非关键帧丢弃帧数达到阀值，此时发送重编关键帧请求，保证视频画面的清晰度。
进一步地，所述进行关键帧重处理，包括以下步骤：
将接收的重传关键帧的RTP数据包写入等待缓冲区；
对等待缓冲区中的RTP包进行组帧，并判断等待缓冲区的重传关键帧是否完整；
若重传关键帧完整，则进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败，并发送重编关键帧请求给发送端；
若重传关键帧不完整，则进一步判断是否等待超时，若等待未超时，则继续等待，否则清空接收数据缓冲区和等待缓冲区，标识处理结果为失败，并发送重编关键帧请求给发送端。
上述技术方案通过设置等待超时阀值，保证在网络质量下降的情况下，接收端不会无限制的一直等待接收请求重传的关键帧中的RTP数据包而导致视频画面的卡顿。
相应地，本发明还提供了一种实时视频传输装置，包括：
发送模块一，用于执行步骤1：发送端将视频帧数据编码为关键帧或非关键帧，发送RTP数据包给接收端；所述关键帧的发送时机由配置的间隔参数确定；
接收模块，用于执行步骤2：接收端对RTP数据包进行处理，若处理成功，则显示视频帧，若处理失败，则发送重编关键帧或重传关键帧中缺失的RTP数据请求给发送端；
发送模块二，用于执行步骤3：发送端接收后，重编关键帧并修改关键帧的发送时机后向接收端发送，或向接收端重传关键帧中缺失的RTP数据；
循环模块，用于重复上述步骤1-3直至所有视频帧数据传输完成。
进一步地，所述接收模块，包括：
接收单元，用于接收RTP数据包至接收数据缓冲区；
判断单元，用于判断RTP数据包是否为请求重传关键帧中缺失的数据；
第一处理单元，用于若非重传关键帧中缺失的RTP数据，进行正常数据帧处理；
第二处理单元，用于若是重传关键帧中缺失的RTP数据，进行关键帧重处理。
进一步地，所述接收模块，还包括：
等待缓冲单元，用于接收端设置等待缓冲区，缓存重传关键帧已接收的RTP数据包。
进一步地，所述第一处理单元，包括：
第一判断构件，用于对接收数据缓冲区中的RTP包进行组帧，并判断视频帧是否完整；
第一解码构件，用于若视频帧完整，则进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败，并发送重编关键帧请求给发送端；
第一处理构件，用于若视频帧不完整，则进一步判断视频帧是否为关键帧，若该视频帧为关键帧，将已接收的RTP数据包写入等待缓冲区，标记处理结果为失败，并发送重传关键帧中缺失的RTP数据请求给发送端，通知发送端重传关键帧中丢失的RTP数据；若该视频帧为非关键帧，则丢弃该视频帧，再判断两连续的关键帧之间已经抛弃的非关键帧数量是否达到阈值，若已经达到阈值，标记处理结果为失败，并发送重编关键帧请求给发送端，否则标记处理结果为成功。
进一步地，所述第二处理单元，包括：
第二接收构件，用于将接收的重传关键帧的RTP数据包写入等待缓冲区；
第二判断构件，用于对等待缓冲区中的RTP包进行组帧，并判断等待缓冲区的重传关键帧是否完整；
第二解码构件，用于若重传关键帧完整，则进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败，并发送重编关键帧请求给发送端；
第二处理构件，用于若重传关键帧不完整，则进一步判断是否等待超时，若等待未超时，则继续等待，否则清空接收数据缓冲区和等待缓冲区，标识处理结果为失败，并发送重编关键帧请求给发送端。
相应地，本发明还提供了一种用于实时视频传输的设备，所述用于实时视频传输的设备为发送设备或接收设备，
所述发送设备用于将视频帧数据编码为关键帧或非关键帧，发送RTP数据包给接收设备；所述关键帧的发送时机由配置的间隔参数确定；所述发送设备还用于重编关键帧并修改关键帧的发送时机后向接收设备发送，或向接收设备发送请求的重传关键帧中缺失的RTP数据；
所述接收设备用于对RTP数据包进行处理，若处理成功，则显示视频帧，若处理失败，则发送重编关键帧或重传关键帧中缺失的RTP数据请求给发送设备。
相应地，本发明还提供了一种实时视频传输***，包括发送端和接收端,所述发送端用于将视频帧数据编码为关键帧或非关键帧，发送RTP数据包给接收端；所述关键帧的发送时机由配置的间隔参数确定；所述发送端还用于重编关键帧并修改关键帧的发送时机后向接收端发送，或向接收端发送请求的重传关键帧中缺失的RTP数据；
所述接收端用于对RTP数据包进行处理，若处理成功，则显示视频帧，若处理失败，则发送重编关键帧或重传关键帧中缺失的RTP数据请求给发送端。
进一步地，所述发送端设置发送数据缓冲区用于缓存已发送的RTP数据包，当接收到重传关键帧中缺失的RTP数据请求时，优先查找所述发送数据缓冲区。
进一步地，所述接收端设置接收数据缓冲区和等待缓冲区，所述接收数据缓冲区用于缓存接收到的RTP数据包，所述等待缓冲区用于缓存重传关键帧已接收的RTP数据包。
综上所述，本发明技术方案的有益效果有:
1.本发明提出动态的关键帧间隔，在网络质量正常的情况下通过设置较大的关键帧间隔，从而减少关键帧的数量，降低传输的总数据量；在网络质量下降导致数据处理失败的情况下，由接收端发送重编关键帧或重传关键帧中缺失的RTP数据包请求。对于重编关键帧请求，发送端根据请求动态地进行关键帧编码并修改关键帧发送时机，减少接收端视频恢复的等待时间，保证视频画面的及时恢复；
2.发送端设置发送数据缓冲区，提高重传关键帧中缺失的RTP数据时候查找数据的处理效率，缩短了处理时间。接收端设置等待缓冲区和接收数据缓冲区，可同时并发处理RTP数据包，将重传关键帧中缺失的RTP数据导致的等待时间降至最少；
3.在视频帧不完整的情况下，会根据视频帧的类型进行不同的处理：如果是关键帧则请求重传关键帧中缺失的RTP数据，这样能够保证视频画面的完整性；如果是非关键帧且累计丢弃帧数在设置阀值范围内，则直接丢弃帧，等待下一个视频帧，这样可减少重编关键帧的网络开销，保证视频的流畅度，而对视频画面的影响只有轻微马赛克或较小的延时；如果连续两关键帧之间累计非关键帧丢弃帧数达到阀值，此时发送重编关键帧请求，保证视频画面的清晰度；
4.接收端通过添加抖动延时缓解由于网络传输过程中造成的RTP数据包乱序的问题，同时通过设置等待超时阀值，保证在网络质量下降的情况下，接收端不会无限制的一直等待接收重传的关键帧RTP数据包而导致视频画面的卡顿。
附图说明
图1是本发明实施例的一种实时视频传输方法步骤流程图。
图2是本发明实施例的一种接收端对RTP数据包进行处理步骤流程图。
图3是本发明实施例的一种正常数据帧处理步骤流程图。
图4是本发明实施例的一种关键帧重处理步骤流程图。
图5是本发明实施例的一种实时视频传输装置结构框架图。
图6是本发明实施例的一种接收模块结构框架图。
图7是本发明实施例的一种第一处理单元结构框架图。
图8是本发明实施例的一种第二处理单元结构框架图。
图9是本发明实施例的一种用于实时视频传输的发送设备结构图。
图10是本发明实施例的另一种用于实时视频传输的接收设备结构图。
图11是本发明实施例的一种实时视频传输***结构框架图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
如图1，是本发明实施例的一种实时视频传输方法步骤流程图，包括以下步骤：
步骤1：发送端将视频帧数据编码为关键帧或非关键帧，发送RTP数据包给接收端；所述关键帧的发送时机由配置的间隔参数确定；
众所周知，视频就是利用人类视觉暂留的原理通过播放一系列的图片，使人眼产生运动的感觉，其中每一幅静止的图片，我们称之为视频帧。为了方便视频文件在网络传输和存储，需要对视频进行压缩编码，减小文件体积。
目前常见的运动图像专家组压缩标准第2版(MPEG-2，Moving Picture ExpertsGroup Compression Standard Version 2)、H.264/AVC(MPEG-4高级视频编码，AdvancedVideo Coding)、视频编解码器-1(Video Codec 1，VC-1)、数字音视频编解码标准(AVS，Audio Coding Standard)等视音频压缩编码算法中，视频画面被编码为由内部编码帧(I帧，又称关键帧)、多个前向预测帧(P帧)和双向内插帧(B帧)组成的图像序列。I帧通常是每个GOP(Group of Pictures,画面组)的第一个帧，经过适度地压缩，做为随机访问的参考点，可以理解为这一帧画面的完整保留，解码时只需要本帧数据就可以完成；P帧表示这一帧跟之前的一个I帧(或P帧)的差别，解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面，前面的P帧丢失会影响到后面P帧的解码显示，使画面出现马赛克；B帧记录的是本帧与前后帧的差别，换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面与本帧数据的叠加取得最终的画面。
三类帧里面，I帧压缩率最小，P帧压缩率其次，B帧压缩率最高，从对视频画面质量的影响来看，I帧影响最大，P帧其次，B帧影响很小。本发明的技术方案中，所述关键帧指的是I帧，所述非关键帧包括P帧和B帧，在不同网络质量环境下，本技术方案采用设置关键帧间隔参数来控制关键帧的数量，从而控制整个传输视频的数据量，该间隔参数可以根据网络质量情况设定不同的值，在网络质量允许的情况下尽可能设置较大的间隔参数。例如，在一网络环境较差的实施例中，该间隔参数设置为每隔5秒编码发送一幅关键帧数据；在另一网络环境较好的实施例中，间隔参数可以设置为10秒。
步骤2：接收端对RTP数据包进行处理，若处理成功，则显示视频帧，若处理失败，则发送重编关键帧或重传关键帧中缺失的RTP数据请求给发送端；
在视频传输的过程中，接收端主要负责接收RTP数据包，对RTP数据包进行组帧，再根据视频帧的不同类型采用对应方式解码成静态图像帧，最后将图像进行显示。在网络数据传输过程中，通常会遇到两种异常情况：第一种，由于网络的不稳定导致静态图像帧的数据包丢失，接收端无法得到完整的图像帧数据，此时接收端可根据对画面质量影响大小，决定是否向发送端请求重传RTP数据包；第二种，图像帧数据完整，但是在解码过程中出现错误，此时接收端将请求发送端重新编码关键帧。同时，由于视频是由一系列有序的图像画面组成，当进行重传RTP数据包的时候，后续的视频帧可进行组帧处理，但必须等待重传视频帧接收完整、组帧、解码、显示完成后，才能继续解码显示后续的视频帧；当请求重编视频帧的时候，接收端必须等待重编数据帧接收、组帧、解码、显示之后，再依次处理后续图像帧。
步骤3：发送端接收后，重编关键帧并修改关键帧的发送时机后向接收端发送，或向接收端重传关键帧中缺失的RTP数据；
虽然通过设置较大的关键帧间隔参数可以大大减少视频数据传输量，提高视频的流畅度，但是在发送数据包解码失败的时候，会造成视频画面的恢复时间较长，为解决该问题，本发明的技术方案允许接收端在数据包解码失败的时候发送重编关键帧请求，发送端接收到重编关键帧请求后，立即将要求重编的图像帧编码为关键帧后做为下一帧发送给接收端，实现动态调整关键帧的发送时机。当接收端发现数据包丢失时，发送重传关键帧中缺失的RTP数据请求，发送端接收到请求后，查找要求重传的关键帧中缺失的RTP数据并发送给接收端。通过固定间隔编码关键帧和根据接收端动态请求编码关键帧这两种方式的相结合，可以实现保证视频画面质量的前提下，减少视频数据传输量，提高流畅度。
例如，在一具体的实施例中，在关键帧发送频率固定的情况下，发送端设置的关键帧间隔参数为10秒，在传输数据正常的情况下每间隔10秒发送一次关键帧，优选地，视频刚开始传输时可进行特殊处理，发送端视频数据开始传送的第0秒、第2秒、第4秒编码成关键帧，这样可以解决发送端和接收端处理时间不一致造成的开头部分数据丢失问题(由于刚开始发送关键帧的时间间隔短，即使接收端未成功接收前面一两帧的关键帧，对视频现实影响不大)；同时，如果前4秒有收到重编关键帧的请求，为了避免频繁的发送关键帧，发送端不进行处理。从第4秒后开始，发送端每间隔10秒发送一次关键帧，即第14秒，第24秒…依此类推。如果有收到接收端重编关键帧的请求，立即将要求重编的图像帧编码为关键帧后做为下一帧发送给接收端，从发送该重编的关键帧起，然后再每间隔10秒发送下一个关键帧。例如，发送端第24秒编码关键帧后，在第28秒接收到重编关键帧请求，则立即将请求重编的图像帧编码为关键帧，并发送给接收端；然后在第38秒进行下一次发送关键帧。
当发送端接收到重传关键帧请求时，会将已经发送过的图像帧数据再次发送给接收端，优选地，本发明技术方案中的发送端还可设置发送数据缓冲区，缓存发送的RTP数据包，当接收到重传关键帧缺失的RTP数据包请求时，优先查找所述发送数据缓冲区。正常情况下，需要重传的关键帧均为刚发送不久的数据，通过设置发送数据缓冲区，可以减少从原始视频数据文件查找数据的概率，提高查找效率。例如，在网络延时较小的实施例中，可设置发送数据缓冲区大小为保存最近2秒钟已发送RTP数据；在网络延时较大的实施例中，可设置发送数据缓冲区大小为保存最近5秒钟已发送RTP数据。
重复上述步骤1-3直至所有视频帧数据传输完成。发送端和接收端协同工作，直至整个视频包含的所有图像帧都按照顺序接收、组帧、解码、显示完成。
如图2，是本发明实施例的一种接收端对RTP数据包进行处理步骤流程图，包括以下步骤：
步骤一、接收端将接收到的RTP数据包缓存至接收数据缓冲区；
接收端将所有的接收数据都存放在接收数据缓冲区内，再对数据进行组帧、解码、显示处理，由于视频图像帧的连续性，必须当前视频帧显示之后，才能显示下一帧视频图像。
在一优选的实施例中，除了接收数据缓冲区，接收端还设置等待缓冲区，在请求重传关键帧中缺失的RTP数据的情况下，用于缓存已接收不完整的帧数据，这样处理的有益效果是，接收数据缓冲区可以继续接收后续RTP数据包，进行后续视频帧的组帧处理，待重传关键帧接收完整、组帧、解码、显示完成后可立即解码显示后续视频帧，减少重传关键帧处理后的恢复时间。
步骤二、判断RTP数据包是否为重传关键帧中缺失的RTP数据；接收端根据接收数据包的类型选择后续的处理路径，做不同的处理；
步骤三、若非重传关键帧中缺失的RTP数据，进行正常数据帧处理；
如图3,是本发明实施例的一种正常数据帧处理步骤流程图，步骤如下：
对接收数据缓冲区中的RTP包进行组帧，并判断视频帧是否完整；
由于在视频数据网络传输过程中，一幅静态视频帧数据通常被分解成多个RTP数据包发送，每个RTP包都有网络序列号用于标识出数据的先后顺序，接收端收到RTP数据包后，要根据RTP包头信息，将多个RTP数据包组成原始的视频帧数据。
在一优选的实施例中，接收端对RTP数据包进行组帧前，是根据设置的抖动延时从接收缓冲区读取RTP数据包，添加抖动延时可缓解网络传输过程中RTP数据包乱序的问题。
若视频帧完整，则进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败；此处的解码是根据数据帧的类型做不同的处理：如果是I帧，只需要本帧数据就可以还原视频画面；如果是P帧，需要用之前缓存的画面叠加上本帧数据定义的差别，生成最终画面；如果是B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。若解码成功，则显示该视频帧，若解码失败，需要发送重编关键帧请求。
若视频帧不完整，则进一步判断，若该视频帧为关键帧，将RTP数据包写入等待缓冲区以便后续接收重传数据后再次组帧，并标记处理结果为失败。由于关键帧对画面质量影响较大，这种情况下，接收端都将发起重传关键帧中缺失的RTP数据请求；
若该视频帧不完整且为非关键帧，由于少量的非关键帧缺失对视频画面质量影响较小，所以本技术方案采用了直接丢弃该视频帧的方式，这样就不需要进行数据的重传，减少网络带宽的占用。但是，如果在两连续的关键帧之间直接抛弃的非关键帧达到一定的数量，也会引起视频画面卡顿或马赛克等情况，所以本技术方案可设置在两连续的关键帧之间丢弃非关键帧的上限阈值，若已经达到该上限阈值，标记处理结果为失败，请求重编关键帧，否则标记处理结果为成功，不请求重编关键帧。例如，在一具体实施例中，两连续的关键帧之间允许抛弃非关键帧的上限阈值设置为10，接收端每次处理关键帧的时候，都将抛弃非关键帧的累计值置零，当接收端抛弃一张非关键帧时，将累计值加1，若累计值不大于10，则继续处理后续视频帧，若累计值大于10，请求发送端重编关键帧，同时将累计值重新置零。
步骤四、若是重传关键帧中缺失的RTP数据，进行关键帧重处理。
如图4，是本发明实施例的一种关键帧重处理步骤流程图，步骤如下：
将接收的重传关键帧RTP数据包写入等待缓冲区；由于等待缓冲区里面已经缓存了之前收到的部分数据，后续只要将重传的RTP数据包写入等待缓冲区。
对等待缓冲区中的RTP包进行组帧，并判断等待缓冲区的重传关键帧数据是否完整；此处的组帧操作，与正常数据帧处理中的组帧操作方式一致。
若重传关键帧完整，则进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败；此处解码处理方式和正常帧处理方式一致，解码成功视频帧的进行画面显示，若解码失败，需要发送重编关键帧请求。
若重传关键帧不完整，此时需要根据设置的超时阈值判断，若等待时间未超过阈值，则继续等待，若等待时间已经超过阈值，这时候同时清空接收数据缓冲区和等待缓冲区，标识处理结果为失败，发送重编关键帧请求。
如图5，是本发明实施例的一种实时视频传输装置结构框架图，包括：
发送模块一，用于执行步骤1：发送端将视频帧数据编码为关键帧或非关键帧，发送RTP数据包给接收端；所述关键帧的发送时机由配置的间隔参数确定；
接收模块，用于执行步骤2：接收端对RTP数据包进行处理，若处理成功，则显示视频帧，若处理失败，则发送重编关键帧或重传关键帧中缺失的RTP数据请求给发送端；
发送模块二，用于执行步骤3：发送端接收后，重编关键帧并修改关键帧的发送时机后向接收端发送，或向接收端重传关键帧中缺失的RTP数据；
循环模块，用于重复上述步骤1-3直至所有视频帧数据传输完成。
如图6，是本发明实施例的一种接收模块结构框架图，包括：
接收单元，用于接收RTP数据包至接收数据缓冲区；
等待缓冲单元，用于接收端设置等待缓冲区，缓存重传关键帧已接收的RTP数据包；
判断单元，用于判断RTP数据包是否为请求重传关键帧中缺失的数据；
第一处理单元，用于若非重传关键帧中缺失的RTP数据，进行正常数据帧处理；
第二处理单元，用于若是重传关键帧中缺失的RTP数据，进行关键帧重处理。
如图7,是本发明实施例的一种第一处理单元结构框架图，包括：
第一判断构件，用于对接收数据缓冲区中的RTP包进行组帧，并判断视频帧是否完整；
第一解码构件，用于若视频帧完整，则进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败，并发送重编关键帧请求给发送端；
第一处理构件，用于若视频帧不完整，则进一步判断视频帧是否为关键帧，若该视频帧为关键帧，将已接收的RTP数据包写入等待缓冲区，标记处理结果为失败，并发送重传关键帧中缺失的RTP数据请求给发送端，通知发送端重传关键帧中丢失的RTP数据；若该视频帧为非关键帧，则丢弃该视频帧，再判断两连续的关键帧之间已经抛弃的非关键帧数量是否达到阈值，若已经达到阈值，标记处理结果为失败，并发送重编关键帧请求给发送端，否则标记处理结果为成功。
如图8,是本发明实施例的一种第二处理单元结构框架图，包括：
第二接收构件，用于将接收的重传关键帧的RTP数据包写入等待缓冲区；
第二判断构件，用于对等待缓冲区中的RTP包进行组帧，并判断等待缓冲区的重传关键帧是否完整；
第二解码构件，用于若重传关键帧完整，则进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败，并发送重编关键帧请求给发送端；
第二处理构件，用于若重传关键帧不完整，则进一步判断是否等待超时，若等待未超时，则继续等待，否则清空接收数据缓冲区和等待缓冲区，标识处理结果为失败，并发送重编关键帧请求给发送端。
同时，本发明提供了一种用于实时视频传输的设备，该设备可以为接收设备或发送设备，具体可以是手机、梯口机、门口机、室内机等具有视频传输功能的设备。其中，发送设备用于将视频帧数据编码为关键帧或非关键帧，发送RTP数据包给接收设备；关键帧的发送时机由配置的间隔参数确定；另外，发送设备还用于重编关键帧并修改关键帧的发送时机后向接收设备发送，或向接收设备发送请求的重传关键帧中缺失的RTP数据；
接收设备用于对RTP数据包进行处理，若处理成功，则显示视频帧，若处理失败，则发送重编关键帧或重传关键帧中缺失的RTP数据请求给发送设备。如图9,是本发明实施例的一种用于实时视频传输的发送设备结构图，通过包含本发明的实时视频传输装置中的发送模块一、发送模块二以及循环模块，可实现实时视频传输发送端的功能。其中，发送模块一，用于将视频帧数据编码为关键帧或非关键帧，发送RTP数据包给接收端；所述关键帧的发送时机由配置的间隔参数确定；发送模块二，用于重编关键帧并修改关键帧的发送时机后向接收端发送，或向接收端重传关键帧中缺失的RTP数据；循环模块，用于循环处理发送模块一和发送模块二的步骤直至所有视频帧数据传输完成。
如图10,是本发明实施例的另一种用于实时视频传输的接收设备结构图，通过包含本发明的实时视频传输装置中的接收模块，可实现实时视频传输接收端的功能。其中，接收模块用于对RTP数据包进行处理，若处理成功，则显示视频帧，若处理失败，则发送重编关键帧或重传关键帧中缺失的RTP数据请求给发送端。
在实际应用中，通过上述的发送端设备和接收端设备的协同工作，实现实时视频传输的功能。例如，在门禁***的来访客人视频传输过程中，发送端为门口机，接收端为室内机。门口机和室内机应用本发明的实时视频传输装置进行实时视频传输时，
门口机的发送模块一，用于将采集的来访客人视频帧数据编码为关键帧或非关键帧，并拆分成RTP数据包给室内机；其中，关键帧的发送时机由配置的间隔参数确定；
室内机的接收模块，用于接收门口机发送的RTP数据包，对RTP数据包进行组帧，再根据视频帧的不同类型采用对应方式解码成静态图像帧，最后将图像显示在室内机的屏幕上。在处理过程中，如果视频帧的数据不完整，此时室内机可根据对画面质量影响大小，决定是否向门口机请求重传缺失的数据包；如果图像帧数据完整，但是在解码过程中出现错误，此时室内机将请求门口机重编关键帧。
门口机的发送模块二，用于在接收到重编关键帧请求时，重编关键帧并修改关键帧的发送时机后向室内机发送；或接收到重传关键帧缺失的RTP数据请求时，向室内机重传缺失的RTP数据包；
门口机的循环模块，用于重复上述步骤直至所有视频帧数据发送给室内机。
又如，监控***中摄像头视频采集点和控制中心的视频数据传输，视频点播应用中的服务器和手机客户端之间的视频传输，均可采用本发明装置。总之，两个以上设备之间需要进行实时视频传输时，均可应用本发明的装置。
如图11，是本发明实施例的一种实时视频传输***结构框架图，包括发送端和接收端,发送端和接收端通过网络连接，发送端用于将视频帧数据编码为关键帧或非关键帧，其中关键帧为I帧，非关键帧包含P帧和B帧，并将视频帧数据拆分成多个RTP数据包发送给接收端；发送端根据配置的间隔参数确定关键帧；同时，发送端还用于重编关键帧并修改关键帧的发送时机后向接收端发送，或向接收端重传关键帧中缺失的RTP数据；
接收端主要负责接收RTP数据包，对RTP数据包进行组帧，再根据视频帧的不同类型采用对应方式解码成静态图像帧，最后将图像进行显示。同时，当某一静态图像帧发送过程中出现数据包丢失导致数据不完整时，接收端根据对画面质量影响情况确定是否需要请求重传关键帧中缺失的RTP数据；或在解码过程中出现错误的时候，发送重编关键帧请求。
在一优选的实施例中，实时视频传输***的发送端可设置发送数据缓冲区用于缓存已发送的RTP数据包，当接收到重传关键帧中缺失的RTP数据请求时，优先查找所述发送数据缓冲区，提高查找速度，缩短处理时间。
在另一优选的实施例中，实时视频传输***的接收端可设置接收数据缓冲区和等待缓冲区，接收数据缓冲区用于缓存接收到的RTP数据包，等待缓冲区用于缓存重传关键帧已经接收的RTP数据包，通过双缓冲区机制，等待缓冲区保存不完整的帧数据，接收数据缓冲区可以继续接收后续RTP数据包，进行后续视频帧的组帧处理，待重传关键帧接收完整、组帧、解码、显示完成后可立即解码显示后续视频帧，减少重传关键帧处理后的恢复时间。

Claims (11)

1.一种实时视频传输方法，其特征在于，包括以下步骤：
步骤1：发送端将视频帧数据编码为关键帧或非关键帧，发送RTP数据包给接收端；所述关键帧的发送时机由配置的间隔参数确定；
步骤2：接收端对RTP数据包进行处理，若处理成功，则显示视频帧，若处理失败，则发送重编关键帧或重传关键帧中缺失的RTP数据请求给发送端；所述接收端对RTP数据包进行处理，具体为：
接收RTP数据包至接收数据缓冲区；
判断RTP数据包是否为请求重传关键帧中缺失的数据；
若非重传关键帧中缺失的RTP数据，进行正常数据帧处理；所述正常数据帧处理，包括以下步骤：对接收数据缓冲区中的RTP包进行组帧，并判断视频帧是否完整；若视频帧完整，则进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败，并发送重编关键帧请求给发送端；若视频帧不完整，则进一步判断视频帧是否为关键帧，若该视频帧为关键帧，将已接收的RTP数据包写入等待缓冲区，标记处理结果为失败，并发送重传关键帧中缺失的RTP数据请求给发送端，通知发送端重传关键帧中丢失的RTP数据；若该视频帧为非关键帧，则丢弃该视频帧，再判断两连续的关键帧之间已经抛弃的非关键帧数量是否达到阈值，若已经达到阈值，标记处理结果为失败，并发送重编关键帧请求给发送端，否则标记处理结果为成功；
若是重传关键帧中缺失的RTP数据，进行关键帧重处理；
步骤3：发送端接收后，重编关键帧并修改关键帧的发送时机后向接收端发送，或向接收端重传关键帧中缺失的RTP数据；
重复上述步骤1-3直至所有视频帧数据传输完成。
2.如权利要求1所述的实时视频传输方法，其特征在于，所述步骤1，还包括：
发送端将已发送的RTP数据包放入发送数据缓冲区，当接收到重传关键帧中缺失的RTP数据请求时，优先查找所述发送数据缓冲区。
3.如权利要求1所述的实时视频传输方法，其特征在于，所述步骤2还包括：接收端设置等待缓冲区，用于缓存重传关键帧已接收的RTP数据包。
4.如权利要求1所述的实时视频传输方法，其特征在于，所述接收端是根据设置的抖动延时从所述接收缓冲区读取RTP数据包。
5.如权利要求3所述的实时视频传输方法，其特征在于，所述进行关键帧重处理，包括以下步骤：
将接收的重传关键帧的RTP数据包写入等待缓冲区；
对等待缓冲区中的RTP包进行组帧，并判断等待缓冲区的重传关键帧是否完整；
若重传关键帧完整，则进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败，并发送重编关键帧请求给发送端；
若重传关键帧不完整，则进一步判断是否等待超时，若等待未超时，则继续等待，否则清空接收数据缓冲区和等待缓冲区，标识处理结果为失败，并发送重编关键帧请求给发送端。
6.一种实时视频传输装置，其特征在于，包括：
发送模块一，用于将视频帧数据编码为关键帧或非关键帧，发送RTP数据包给接收模块；所述关键帧的发送时机由配置的间隔参数确定；
所述接收模块，用于对RTP数据包进行处理，若处理成功，则显示视频帧，若处理失败，则发送重编关键帧或重传关键帧中缺失的RTP数据请求给发送模块二；所述接收模块，包括：
接收单元，用于接收RTP数据包至接收数据缓冲区；
判断单元，用于判断RTP数据包是否为请求重传关键帧中缺失的数据；
第一处理单元，用于对非重传关键帧中缺失的RTP数据，进行正常数据帧处理；所述第一处理单元，包括：
第一判断构件，用于对接收数据缓冲区中的RTP包进行组帧，并判断视频帧是否完整；
第一解码构件，用于当视频帧完整时，进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败，并发送重编关键帧请求给所述发送模块二；
第一处理构件，用于当视频帧不完整时，进一步判断视频帧是否为关键帧，若该视频帧为关键帧，将已接收的RTP数据包写入等待缓冲区，标记处理结果为失败，并发送重传关键帧中缺失的RTP数据请求给所述发送模块二，通知所述发送模块二重传关键帧中丢失的RTP数据；若该视频帧为非关键帧，则丢弃该视频帧，再判断两连续的关键帧之间已经抛弃的非关键帧数量是否达到阈值，若已经达到阈值，标记处理结果为失败，并发送重编关键帧请求给所述发送模块二，否则标记处理结果为成功；
第二处理单元，用于对重传关键帧中缺失的RTP数据，进行关键帧重处理；
所述发送模块二，用于当接收到所述第一解码构件或所述第一处理构件发送的重编关键帧请求后，重编关键帧并修改关键帧的发送时机后向所述接收模块发送，或当接收到所述第一处理构件发送的重传关键帧中缺失的RTP数据请求后，向所述接收模块重传关键帧中缺失的RTP数据；
循环模块，用于循环调用所述发送模块一、所述接收模块以及所述发送模块二进行处理直至所有视频帧数据传输完成。
7.如权利要求6所述的实时视频传输装置，其特征在于，所述接收模块，还包括：
等待缓冲单元，用于设置等待缓冲区，缓存重传关键帧已接收的RTP数据包。
8.如权利要求7所述的实时视频传输装置，其特征在于，所述第二处理单元，包括：
第二接收构件，用于将接收的重传关键帧的RTP数据包写入等待缓冲区；
第二判断构件，用于对等待缓冲区中的RTP包进行组帧，并判断等待缓冲区的重传关键帧是否完整；
第二解码构件，用于当重传关键帧完整时，进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败，并发送重编关键帧请求给所述发送模块二；
第二处理构件，用于当重传关键帧不完整时，进一步判断是否等待超时，若等待未超时，则继续等待，否则清空接收数据缓冲区和等待缓冲区，标识处理结果为失败，并发送重编关键帧请求给所述发送模块二。
9.一种实时视频传输***，其特征在于，包括发送端和接收端,所述发送端用于将视频帧数据编码为关键帧或非关键帧，发送RTP数据包给接收端；所述关键帧的发送时机由配置的间隔参数确定；所述发送端还用于重编关键帧并修改关键帧的发送时机后向接收端发送，或向接收端发送请求的重传关键帧中缺失的RTP数据；
所述接收端用于对RTP数据包进行处理，若处理成功，则显示视频帧，若处理失败，则发送重编关键帧或重传关键帧中缺失的RTP数据请求给发送端；所述接收设备对RTP数据包进行处理，具体为：
接收RTP数据包至接收数据缓冲区；
判断RTP数据包是否为请求重传关键帧中缺失的数据；
若非重传关键帧中缺失的RTP数据，进行正常数据帧处理；所述正常数据帧处理，包括以下步骤：对接收数据缓冲区中的RTP包进行组帧，并判断视频帧是否完整；若视频帧完整，则进行视频帧解码操作，解码成功则标识处理结果为成功，否则标识处理结果为失败，并发送重编关键帧请求给发送端；若视频帧不完整，则进一步判断视频帧是否为关键帧，若该视频帧为关键帧，将已接收的RTP数据包写入等待缓冲区，标记处理结果为失败，并发送重传关键帧中缺失的RTP数据请求给发送端，通知发送端重传关键帧中丢失的RTP数据；若该视频帧为非关键帧，则丢弃该视频帧，再判断两连续的关键帧之间已经抛弃的非关键帧数量是否达到阈值，若已经达到阈值，标记处理结果为失败，并发送重编关键帧请求给发送端，否则标记处理结果为成功；
若是重传关键帧中缺失的RTP数据，进行关键帧重处理。
10.如权利要求9所述的实时视频传输***，其特征在于，所述发送端设置发送数据缓冲区用于缓存已发送的RTP数据包，当接收到重传关键帧中缺失的RTP数据请求时，优先查找所述发送数据缓冲区。
11.如权利要求9所述的实时视频传输***，其特征在于，所述接收端设置接收数据缓冲区和等待缓冲区，所述接收数据缓冲区用于缓存接收到的RTP数据包，所述等待缓冲区用于缓存重传关键帧已接收的RTP数据包。
CN201610167888.7A 2016-03-23 2016-03-23 实时视频传输方法、装置、设备及*** Active CN107231328B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610167888.7A CN107231328B (zh) 2016-03-23 2016-03-23 实时视频传输方法、装置、设备及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610167888.7A CN107231328B (zh) 2016-03-23 2016-03-23 实时视频传输方法、装置、设备及***

Publications (2)

Publication Number Publication Date
CN107231328A CN107231328A (zh) 2017-10-03
CN107231328B true CN107231328B (zh) 2020-08-28

Family

ID=59931630

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610167888.7A Active CN107231328B (zh) 2016-03-23 2016-03-23 实时视频传输方法、装置、设备及***

Country Status (1)

Country Link
CN (1) CN107231328B (zh)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107948142A (zh) * 2017-11-15 2018-04-20 广州杏雨信息科技有限公司 一种3d高清视频点对点实时传输方法及***
CN107846475B (zh) * 2017-12-06 2020-08-18 中国水利水电科学研究院 智能水利信息测控装置
CN108366306A (zh) * 2017-12-13 2018-08-03 天津天地伟业机器人技术有限公司 一种基于嵌入式设备的码流传输的控制方法
CN111326176A (zh) * 2018-12-14 2020-06-23 中移（杭州）信息技术有限公司 基于opus编码的rtp包的检测方法、装置及介质
CN109361935A (zh) * 2018-12-24 2019-02-19 广州微算互联信息技术有限公司 图片流视频传输方法与***
CN109862400B (zh) * 2019-02-18 2021-08-31 苏州长风航空电子有限公司 一种流媒体传输方法、装置及其***
CN110062003B (zh) * 2019-04-30 2022-01-25 北京金山云网络技术有限公司 视频数据发送方法、装置、电子设备及存储介质
CN110225347A (zh) * 2019-06-24 2019-09-10 北京大米科技有限公司 视频数据传输方法、装置、电子设备和存储介质
CN110225348A (zh) * 2019-06-24 2019-09-10 北京大米科技有限公司 视频数据的修复方法、装置、电子设备和存储介质
CN112449190B (zh) * 2019-09-05 2024-07-09 曙光网络科技有限公司 一种并发视频会话ipb帧图像组的解码方法
CN110557677A (zh) * 2019-09-27 2019-12-10 北京西山居互动娱乐科技有限公司 一种视频传输的方法及装置
CN110769380A (zh) * 2019-10-31 2020-02-07 联想(北京)有限公司 视频分发方法及装置
CN111163362B (zh) * 2019-12-30 2021-12-24 北京佳讯飞鸿电气股份有限公司 一种自适应重传等待时间的视频接收方法及***
CN113452953B (zh) * 2020-03-26 2022-06-14 浙江宇视科技有限公司 一种视频流传输控制方法、装置、设备和介质
CN111953612B (zh) * 2020-07-21 2024-02-23 西安万像电子科技有限公司 数据传输控制方法及装置
CN112291523B (zh) * 2020-10-29 2023-12-05 合肥安迅精密技术有限公司 一种贴片机设备的图像数据接收***及方法
CN112689160B (zh) * 2020-11-27 2022-12-09 烟台艾睿光电科技有限公司 一种应用于图像采集设备的视频传输方法及装置
CN113612962A (zh) * 2021-07-15 2021-11-05 深圳市捷视飞通科技股份有限公司 视频会议处理方法、***和装置
CN114567796A (zh) * 2022-03-04 2022-05-31 北京字节跳动网络技术有限公司 一种丢帧方法、装置、服务器和介质
CN115102927B (zh) * 2022-04-29 2023-10-27 厦门立林科技有限公司 一种保持视频清晰的sip对讲方法、***、存储装置
WO2023206910A1 (zh) * 2022-04-29 2023-11-02 厦门立林科技有限公司 基于局域网和广域网的sip对讲方法、***及存储介质
CN115208864B (zh) * 2022-08-12 2024-02-06 阿波罗智联(北京)科技有限公司 数据传输方法、装置、设备、车辆及存储介质
CN116112697B (zh) * 2022-11-28 2023-08-11 长沙千视电子科技有限公司 一种基于ndi的实时视频录像方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7174561B2 (en) * 2001-04-13 2007-02-06 Emc Corporation MPEG dual-channel decoder data and control protocols for real-time video streaming
CN100588249C (zh) * 2006-07-27 2010-02-03 腾讯科技（深圳）有限公司 调节视频质量的方法、***及终端
US20090303309A1 (en) * 2008-06-04 2009-12-10 Pantech Co., Ltd. Mobile terminal and method for transmitting video data in video telephony system
CN101998101A (zh) * 2009-08-31 2011-03-30 中兴通讯股份有限公司 可视电话的视频数据接收和发送***、视频数据处理方法
CN101909210A (zh) * 2009-12-17 2010-12-08 新奥特（北京）视频技术有限公司 一种网络流媒体服务器及其低带宽高质量解决方法
CN101860733A (zh) * 2010-06-11 2010-10-13 深圳市黄河数字技术有限公司 3g网络视频监控***与监控方法
CN101990087A (zh) * 2010-09-28 2011-03-23 深圳中兴力维技术有限公司 无线视频监控***及根据网络状态动态调整码流的方法
CN103533387B (zh) * 2013-10-21 2016-08-17 腾讯科技（深圳）有限公司 一种视频直播控制方法、设备及***
CN104869461A (zh) * 2015-05-22 2015-08-26 南京创维信息技术研究院有限公司 视频数据处理***及方法

Also Published As

Publication number Publication date
CN107231328A (zh) 2017-10-03

Similar Documents

Publication Publication Date Title
CN107231328B (zh) 实时视频传输方法、装置、设备及***
CN109729439B (zh) 实时视频传输方法
US8711929B2 (en) Network-based dynamic encoding
US8472520B2 (en) Systems and methods for transmitting and receiving data streams with feedback information over a lossy network
US10652580B2 (en) Video data processing method and apparatus
EP2061174B1 (en) Data communication system, data transmitting device and method, using probe packets and having a transmission buffer control
KR101242663B1 (ko) 패킷 송신 장치, 통신 시스템 및 컴퓨터 판독가능한 기록매체
US10944973B2 (en) Estimation of video quality of experience on media servers
US20110085602A1 (en) Video Communication System, Device and Method Based on Feedback Reference Frames
JP2001274861A (ja) データ伝送方法および装置
US20150103885A1 (en) Real time ip video transmission with high resilience to network errors
KR20040009928A (ko) 전송제어 파라미터 생성방법 및 프레임 특성에 따른선택적 자동 재전송 방법
JP2007150916A (ja) コミュニケーションシステム、端末装置及びコンピュータプログラム
CN110392284B (zh) 视频编码、视频数据处理方法、装置、计算机设备和存储介质
CN111093083B (zh) 数据传输方法及装置
JPH10126772A (ja) 動画像データ転送方法
JP2005033556A (ja) データ送信装置、データ送信方法、データ受信装置、データ受信方法
CN112995214B (zh) 一种实时视频传输***、方法及计算机可读存储介质
CN101645903A (zh) 一种多媒体数据的传输方法及装置
EP2908516A1 (en) Process for transmitting an ongoing video stream from a publisher to a receiver through a MCU unit during a live session
JP2006279436A (ja) マルチメディア通信システムおよび再送用データ削除方法
CN113542685B (zh) 一种基于可靠udp的实时超高清视频传输方法
JPH10200897A (ja) 動画像伝送装置
Ganguly et al. Synergized QoE-Centric Streaming for Telerobotics
CN114866523A (zh) 一种基于udp的视频快速传输方法及***

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
TA01 Transfer of patent application right

Effective date of registration: 20200722

Address after: Cangshan District of Fuzhou City, Fujian province 350000 Jinshan Road No. 618 juyuanzhou Ruijie Science Park building 19-22

Applicant after: FUJIAN STAR-NET COMMUNICATION Co.,Ltd.

Address before: Cangshan District of Fuzhou City, Fujian province 350000 Jinshan Road No. 618 juyuanzhou Ruijie Science Park building 19-22

Applicant before: FUJIAN STAR-NET COMMUNICATION Co.,Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant