CN109982080A - 一种视频传输的方法、存储介质、机器人及控制系统 - Google Patents

一种视频传输的方法、存储介质、机器人及控制系统 Download PDF

Info

Publication number
CN109982080A
CN109982080A CN201711468570.3A CN201711468570A CN109982080A CN 109982080 A CN109982080 A CN 109982080A CN 201711468570 A CN201711468570 A CN 201711468570A CN 109982080 A CN109982080 A CN 109982080A
Authority
CN
China
Prior art keywords
sent
rtp packet
queue
code rate
encoder
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
CN201711468570.3A
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.)
Shenzhen Ubtech Technology Co ltd
Original Assignee
Shenzhen Ubtech 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 Shenzhen Ubtech Technology Co ltd filed Critical Shenzhen Ubtech Technology Co ltd
Priority to CN201711468570.3A priority Critical patent/CN109982080A/zh
Publication of CN109982080A publication Critical patent/CN109982080A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/115Selection of the code volume for a coding unit prior to coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146Data rate or code amount at the encoder output

Landscapes

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

Abstract

本申请公开了一种视频传输的方法、存储介质、机器人及控制系统。该方法包括:采用编码器将视频数据转化为码流数据,形成待发送RTP包;将RTP包放入待发送队列末端;从待发送队列首端取出RTP包,并将取出的RTP包发送出去;其中,编码器的码率由待发送RTP包队列的长度确定。通过待发送RTP包队列的长度确定编码器的码率,使得编码器的码率跟随待发送RTP包队列的长度变化,自适应调节编码器的码率,提高编码效率。

Description

一种视频传输的方法、存储介质、机器人及控制系统
技术领域
本申请涉及通信技术领域,具体涉及一种视频传输的方法、存储介质、机器人及控制系统。
背景技术
目前实时视频传输大多采用RTP(实时传输协议)协议来传输,而RTP包一般都采用TCP(Transmission Control Protocol,传输控制协议)或者UDP(User DatagramProtocol,用户数据报协议)协议来传输,在不稳定的网络(比如无线网络)中,直接采用TCP容易出现延迟、卡顿的情况,无法保证视频的实时性,而直接采用UDP协议容易导致丢包(通信数据包丢失),从而引起花屏的问题。在应用层上没有其他的措施来解决传输层的问题情况下,无法保证一个较好的图像效果。
发明内容
本申请主要解决的问题是提供一种视频传输的方法、存储介质、机器人及控制系统,使得编码器的码率跟随待发送RTP包队列的长度变化,自适应调节编码器的码率,提高编码效率。
为解决上述技术问题,本申请采用的技术方案是提供一种视频传输的方法。该方法包括采用编码器将视频数据转化为码流数据,形成待发送RTP包;将RTP包放入待发送队列末端;从待发送队列首端取出RTP包,并将取出的RTP包发送出去;其中,编码器的码率由待发送RTP包队列的长度确定。
为解决上述技术问题,本申请采用的另一技术方案是提供一种机器人,该机器人包括通信模组、存储器以及处理器,存储器和通信模组均耦接处理器,通信模组用于获取信息,存储器用于存储计算机程序,处理器在执行存储器存储的计算机程序时,用于配合通信模组实现上述的方法。
为解决上述技术问题,本申请采用的另一技术方案是提供一种机器人控制系统,包括机器人和移动终端,机器人是上述的机器人,机器人将使用上述的视频传输方法得到的视频发送给移动终端。
为解决上述技术问题,本申请采用的另一技术方案是提供一种存储介质,用于存储计算机程序,计算机程序在被处理器执行时,用于实现上述的视频传输方法。
通过上述方案,本申请的有益效果是:首先利用编码器将视频数据转化为码流数据,形成待发送RTP包;再将RTP包放入待发送队列末端;根据待发送RTP包队列的长度确定编码器的码率,使得编码器的码率跟随待发送RTP包队列的长度变化,自适应调节编码器的码率,提高编码效率。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。其中:
图1是本申请提供的视频传输的方法第一实施例的流程示意图;
图2是本申请提供的视频传输的方法第一实施例的待发送队列示意图;
图3是本申请提供的视频传输的方法第二实施例的流程示意图;
图4是本申请提供的视频传输的方法第二实施例中画面组示意图;
图5是本申请提供的视频传输的方法第三实施例的流程示意图;
图6是本申请提供的视频传输的方法第四实施例的流程示意图;
图7是本申请提供的视频传输的方法第五实施例的流程示意图;
图8是本申请提供的视频传输的方法中RTP协议层次的示意图;
图9是本申请提供的传统的RTP协议层次的示意图;
图10是本申请提供的机器人一实施例的结构示意图;
图11是本申请提供的机器人控制系统一实施例的结构示意图;
图12是本申请提供的存储介质一实施例的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性的劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
参阅图1,图1是本申请提供的视频传输的方法第一实施例的流程示意图,该方法包括:
步骤11:采用编码器将视频数据转化为码流数据,形成待发送RTP包。
编码器的作用是压缩原始的视频数据,码流为压缩后的数据。原始的视频由一帧帧的图像组成(格式为RGB或者YUV),编码器的作用就是对RGB或者YUV格式的每帧图像进行压缩,输出I帧、P帧或者B帧的码流数据。
在将视频数据转化为码流数据后,需要将码流数据打包成RTP包进行传输。
步骤12:将RTP包放入待发送队列末端。
将码流数据打包成RTP包后,需要将RTP包发送出去,新的RTP包将排列在待发送队列末端,形成新的待发送队列。例如,如图2所示,待发送队列中有四个RTP包:RTP11、RTP12、RTP13和RTP14,新的RTP包RTP15形成后,RTP15会被放在待发送队列的末端,即RTP14的后面。
步骤13:从待发送队列首端取出RTP包,并将取出的RTP包发送出去。
为了将待发送队列中的RTP包发送出去,首先要从待发送队列的首端将RTP包取出,然后再将其发送出去。
当前各厂家所生产的前端,媒体单元普遍没有采用码流平滑技术,通常所宣称的码率是1s的平均流量大小;例如720P的码率为4M/s,但是通过实际抓包分析视频流量特点,发现视频流量的瞬时带宽能够达到28M/s,峰值流量是平均流量的七倍,因此很容易造成丢包。
数据在通信网络上是以数据包为单位传输的,每个数据包中有表示数据信息和提供数据路由的帧,丢包在通信中是指通信数据包丢失。丢包对视频质量的影响主要有:马赛克现象、局部变形(图像的某些区域不清晰)、图像模糊、屏幕频繁刷新或闪烁、视音频不同步、帧率下降、图像静止等。
因此对于视频业务,有必要根据实际情况调整码率,减少丢包情况的发生。
编码器的码率由待发送RTP包队列的长度确定,根据待发送RTP包队列的长度自适应调整编码器的码率,通过待发送RTP包队列的长度检测网络情况,然后根据网络情况调整编码器的码率,使编码器的码率在指定范围内动态调整,适应网络情况。
区别于现有技术,本实施例提供的视频传输的方法,首先利用编码器将视频数据转化为码流数据,形成待发送RTP包;再将RTP包放入待发送队列末端;根据待发送RTP包队列的长度确定编码器的码率,使得编码器的码率跟随待发送RTP包队列的长度变化,自适应调节编码器的码率,提高编码效率。
参阅图3,图3是本申请提供的视频传输的方法第二实施例的流程示意图,该方法包括:
步骤31:采用编码器将视频数据转化为码流数据,形成待发送RTP包。
步骤32:将RTP包放入待发送队列末端。
步骤33:判断RTP包放入待发送队列的时间至从待发送队列取出的时间之间的时间长度是否超过预设时间阈值。
获取每个RTP包放入待发送队列的时间至从待发送队列取出的时间之间的时间长度T。
步骤34:若RTP包放入待发送队列的时间至从待发送队列取出的时间之间的时间长度超过预设时间阈值,则丢弃该RTP包。
步骤35:若RTP包放入待发送队列的时间至从待发送队列取出的时间之间的时间长度未超过预设时间阈值,则将该RTP包发送出去。
当时间长度T大于预设时间阈值T0时,将该RTP包丢弃,避免接收的视频出现卡顿;当时间长度T小于或等于预设时间阈值T0时,将该RTP包发送出去。
例如,发送某一RTP包的时刻为75ms,在接收端接收到该RTP包的时刻为140ms,预设时间阈值T0为50ms,则时间长度T为65ms,时间长度T大于预设时间阈值T0,需要将该RTP包丢弃,否则在实时观看视频时,将会出现卡顿的情况。
进一步地,当RTP包放入待发送队列的时间至从待发送队列取出的时间之间的时间长度超过预设时间阈值时,除了丢弃RTP包之外,还需丢弃RTP包所属画面组(GOP,Groupof Pictures)中所有RTP包。
一个GOP是一组视频帧(以I帧开头、接着是若干P帧或者B帧)组成的序列,RTP包就是用来打包视频帧数据的,RTP包的大小一般有限制,所以一般一个视频帧会有多个RTP包,传输的时候如果因超时丢掉一个RTP包,一个GOP组打出的所有RTP包都要丢掉。因为GOP值为两个I帧之间的视频帧数,I帧可以独立解码,而P帧解码会依赖前一帧,如果不丢掉会出现花屏现象,丢掉带来的结果是画面跳跃,与花屏现象相比画面跳跃带来的观看感受更好。
如图4所示,RTP包RTP11-RTPmn(m和n为自然数)属于同一个GOP,如果检测到其中一个RTP包超时,在执行丢包操作时,需要RTP11到RTPmn之间所有的RTP包都丢掉,以免在观看时出现花屏现象。
区别于现有技术,本实施例提供的视频传输的方法,首先利用编码器将视频数据转化为码流数据,形成待发送RTP包;再将RTP包放入待发送队列末端;根据待发送RTP包队列的长度确定编码器的码率,使得编码器的码率跟随待发送RTP包队列的长度变化,自适应调节编码器的码率,提高编码效率;另外采用超时丢包策略,对于放入待发送队列的时间至从待发送队列取出的时间之间的时间长度超过预设时间阈值的RTP包,将其丢弃,以免视频卡顿和花屏,影响视频观看效果。
参阅图5,图5是本申请提供的视频传输的方法第三实施例的流程示意图,该方法包括:
步骤51:采用编码器将视频数据转化为码流数据,形成待发送RTP包。
步骤52:检测待发送RTP包队列长度。
由于编码器的码率由待发送RTP包队列的长度确定,因此在调整编码器的码率之前需要检测待发送RTP包队列长度,以便实时调整编码器的码率。
步骤53:将RTP包放入待发送队列末端。
步骤54:从待发送队列首端取出RTP包,并将取出的RTP包发送出去。
其中,步骤51和步骤53-54可以具体参考上述步骤11-13,这里不再赘述。
区别于现有技术,本实施例提供的视频传输的方法,通过检测待发送RTP包的队列长度,再根据待发送RTP包的队列长度实时调整编码器的码率,使得编码器的码率适应待发送队列长度,提高编码效率。
参阅图6,图6是本申请提供的视频传输的方法第四实施例的流程示意图,该方法包括:
步骤61:采用编码器将视频数据转化为码流数据,形成待发送RTP包。
步骤62:判断待发送RTP包的队列长度是否大于第一队列阈值。
由于要根据待发送队列长度确定编码器的码率,因此需要判定当前待发送队列长度与预设第一队列阈值之间的大小,确定当前网络状况是否拥挤,是否需要调整编码器的码率;其中,第一队列阈值为系统默认或用户设定。
步骤63:当待发送RTP包的队列长度大于第一队列阈值时,判断编码器的码率是否大于第一码率阈值。
在确定待发送RTP包的队列长度大于第一队列阈值时,需要获取当前编码的码率是否过高。
步骤64:若待发送RTP包的队列长度大于第一队列阈值,且编码器的码率大于第一码率阈值,则降低编码器的码率。
步骤65:当待发送RTP包的队列长度小于或等于第一队列阈值时,判断编码器的码率是否小于第一码率阈值。
在确定当前网络状况良好时,需要确定当前编码器的码率是否低于预设第一码率阈值,从而调整编码器的码率。
步骤66:若待发送RTP包的队列长度小于或等于第一队列阈值,且编码器的码率小于第一码率阈值,则提高编码器的码率。
根据待发送RTP包的队列长度确定编码器的码率,当待发送RTP包的队列长度L大于第一队列阈值L1时,说明排队等待被发送的RTP包较多;当编码器的码率C大于第一码率阈值C1时,说明编码器的码率C过高,可能无法对每个RTP包进行编码,从而出现丢包现象,因此应当降低编器的码率。
当待发送RTP包的队列长度L小于或等于第一队列阈值L1时,说明排队等待被发送的RTP包较少;当编码器的码率C小于或等于第一码率阈值C1时,说明编码器的码率C过低,因此应当提高编器的码率。
例如,待发送RTP包的队列长度L为200,第一队列阈值L1为500,编码器的码率为2M/s,第一码率阈值C1为3M/s,可见此时网络状况良好,不存在堵塞的情况,因此可以提高编器的码率以减少编码时间。
上述步骤62-66可以在步骤61后执行或者在步骤67之后执行,即在形成码流数据后可以根据待发送队列的长度调整编码器的码率,也可以在将RTP包放入待发送队列末端后调整编码器的码率。
步骤67:将RTP包放入待发送队列末端。
步骤68:从待发送队列首端取出RTP包,并将取出的RTP包发送出去。
其中,步骤61和步骤67-68可以具体参考上述步骤11-13,这里不再赘述。
区别于现有技术,本实施例提供的视频传输的方法,通过比较待发送RTP包的队列长度和第一队列阈值确定网络是否拥挤,当网络拥挤时,确定编码器的码率是否大于第一码率阈值,如果编码器的码率大于第一码率阈值则降低编码器的码率;当网络比较良好时,如果编码器的码率小于或等于第一码率阈值则提高编码器的码率,使得编码器的码率根据实际需要进行调整,提高编码效率。
参阅图7,图7是本申请提供的视频传输的方法第五实施例的流程示意图,该方法包括:
步骤71:采用编码器将视频数据转化为码流数据,形成待发送RTP包。
步骤72:判断待发送RTP包的队列长度是否大于第二队列阈值。
步骤73:当待发送RTP包的队列长度大于第二队列阈值时,判断编码器的码率是否大于第二码率阈值。
步骤74:若待发送RTP包的队列长度大于第二队列阈值,且编码器的码率大于第二码率阈值,则降低编码器的码率。
步骤75:判断待发送RTP包的队列长度是否小于第三队列阈值。
步骤76:当待发送RTP包的队列长度小于第三队列阈值时,判断编码器的码率是否小于第三码率阈值。
步骤77:若待发送RTP包的队列长度小于第三队列阈值,且编码器的码率小于第三码率阈值,则提高编码器的码率。
其中,第二队列阈值大于或等于第三队列阈值;第二码率阈值小于或等于第三码率阈值。
编码器的码率由待发送RTP包的队列长度确定,当待发送RTP包的队列长度L大于第二队列阈值L2时,说明排队等待被发送的RTP包较多,网络比较拥挤;当编码器的码率C大于第二码率阈值C2时,说明编码器的码率过高,应当降低编器的码率,否则可能出现丢包状况。
当待发送RTP包的队列长度L小于或等于第三队列阈值L3时,说明排队等待被发送的RTP包较少,网络状况良好;当编码器的码率C小于第三码率阈值C3时,说明编码器的码率过低,因此可以提高编器的码率。
例如,待发送RTP包的队列长度L为800,第二队列阈值L2为500,第三队列阈值L3为300,编码器的码率为2.8M/s,第二码率阈值为2.5M/s,第三码率阈值为3M/s,由于待发送RTP包的队列长度L大于第二队列阈值L2,可知此时网络拥挤,因此可以降低编器的码率至2.5M/s以下。
上述步骤72-77可以在步骤71后执行或者在步骤78之后执行,即在形成码流数据后可以根据待发送队列的长度调整编码器的码率,也可以在将RTP包放入待发送队列末端后调整编码器的码率。
步骤78:将RTP包放入待发送队列末端。
步骤79:从待发送队列首端取出RTP包,并将取出的RTP包发送出去。
其中,步骤71和步骤78-79可以具体参考上述步骤11-13,这里不再赘述。
区别于现有技术,本实施例提供的视频传输的方法,通过比较待发送RTP包的队列长度和第二队列阈值确定网络是否拥挤,当网络拥挤时,确定编码器的码率是否大于第二码率阈值,如果编码器的码率大于第二码率阈值则降低编码器的码率;当待发送RTP包的队列长度小于第三队列阈值时,网络比较良好,如果编码器的码率小于第三码率阈值则提高编码器的码率,使得编码器的码率根据实际需要进行调整,提高编码效率,减少丢包状况的发生。
参阅图8,图8是本申请提供的视频传输的方法中RTP协议层次的示意图,该传输层包括基于用户数据报协议的数据传输协议层(UDT,UDP-based Data Transfer Protocol)、用户数据报协议层(UDP,User Datagram Protocol)和网际协议层(IP,InternetProtocol),传统的RTP协议层次如图9所示。
本申请在传输层上采用基于用户数据报协议的数据传输协议传输RTP包,实现RTP包可靠、高效的传输。
UDT协议兼有UDP协议的高效性和TCP协议的稳定性,能够用来稳定高效的传输RTP包,提高了带宽利用率和网络传输效率,在应用层上再结合码率自适应调节和超时丢包策略,可有效解决视频流实时传输导致的延迟、卡顿及花屏等问题。
参阅图10,图10是本申请提供的机器人一实施例的结构示意图。该机器人100包括:通信模组101、存储器102以及处理器103,存储器102和通信模组101均耦接处理器103,通信模组101用于收发信息,存储器102用于存储计算机程序,处理器103在执行存储器102存储的计算机程序时,用于配合通信模组101实现上述的视频传输的方法。
参阅图11,图11是本申请提供的机器人控制系统一实施例的结构示意图。该机器人控制系统110包括:机器人111和移动终端112,机器人111是上述实施例中的机器人,移动终端112通过WIFI或者蓝牙等连接方式连接机器人111,移动终端112用于向机器人111发送指令,机器人111还用于在接收到指令后向移动终端112发送视频文件。
其中,该移动终端112可以为手机、平板电脑、笔记本和车载电脑等。
参阅图12,图12是本申请提供的存储介质一实施例的结构示意图,该存储介质120用于存储计算机程序121,计算机程序121在被处理器执行时,用于实现上述实施例中的视频传输的方法。可以理解的,在本实施例中的存储介质120存储的计算机程序121,所用来执行的方法与上述实施例提供的方法类似,其原理和步骤相同,这里不再赘述。
其中,该存储介质120包括:服务器、U盘、移动硬盘、只读存储器(ROM,Read-OnlyMemory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
在本申请所提供的几个实施方式中,应该理解到,所揭露的方法以及设备,可以通过其它的方式实现。例如,以上所描述的设备实施方式仅仅是示意性的,例如,模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。
作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。
另外,在本申请各个实施方式中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
以上仅为本申请的实施例,并非因此限制本申请的专利范围,凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本申请的专利保护范围内。

Claims (10)

1.一种视频传输的方法,其特征在于,包括:
采用编码器将视频数据转化为码流数据,形成待发送RTP包;
将所述RTP包放入待发送队列末端;
从所述待发送队列首端取出RTP包,并将取出的RTP包发送出去;
其中,所述编码器的码率由所述待发送RTP包队列的长度确定。
2.根据权利要求1所述的方法,其特征在于,
所述从所述待发送队列首端取出RTP包,并将取出的RTP包发送出去的步骤,包括:
判断所述RTP包放入所述待发送队列的时间至从所述待发送队列取出的时间之间的时间长度是否超过预设时间阈值;
若是,丢弃所述RTP包;
若否,将所述RTP包发送出去。
3.根据权利要求1所述的方法,其特征在于,
所述将所述RTP包放入待发送队列末端的步骤之前,包括:
检测所述待发送RTP包队列长度。
4.根据权利要求1所述的方法,其特征在于,
根据所述待发送RTP包队列的长度确定所述编码器的码率的方法,包括:
当所述待发送RTP包的队列长度大于第一队列阈值时,判断所述编码器的码率是否大于第一码率阈值;若是,降低所述编码器的码率;
当所述待发送RTP包的队列长度小于第一队列阈值时,判断所述编码器的码率是否小于第一码率阈值;若是,提高所述编码器的码率。
5.根据权利要求1所述的方法,其特征在于,
根据所述待发送RTP包队列的长度确定所述编码器的码率的方法,包括:
当所述待发送RTP包的队列长度大于第二队列阈值时,判断所述编码器的码率是否大于第二码率阈值;若是,降低所述编码器的码率;
当所述待发送RTP包的队列长度小于第三队列阈值时,判断所述编码器的码率是否小于第三码率阈值;若是,提高所述编码器的码率;
其中,所述第二队列阈值大于或等于所述第三队列阈值;所述第二码率阈值小于或等于所述第三码率阈值。
6.根据权利要求2所述的方法,其特征在于,
当所述RTP包放入所述待发送队列的时间至从所述待发送队列取出的时间之间的时间长度超过预设时间阈值时,丢弃所述RTP包之外,还包括丢弃所述RTP包所属画面组中所有RTP包。
7.根据权利要求1所述的方法,其特征在于,
在传输层上采用基于用户数据报协议的数据传输协议传输所述RTP包;其中所述传输层包括基于用户数据报协议的数据传输协议层、用户数据报协议层和网际协议层。
8.一种机器人,其特征在于,包括通信模组、存储器以及处理器,所述存储器和所述通信模组均耦接所述处理器,所述通信模组用于收发信息,所述存储器用于存储计算机程序,所述处理器在执行所述存储器存储的计算机程序时,用于配合所述通信模组实现如权利要求1-7任一项所述的视频传输的方法。
9.一种机器人控制系统,包括机器人和移动终端,其特征在于,
所述机器人是如权利要求8所述的机器人,所述移动终端用于向所述机器人发送指令,所述机器人还用于在接收到所述指令后向所述移动终端发送视频文件。
10.一种存储介质,用于存储计算机程序,其特征在于,所述计算机程序在被处理器执行时,用于实现如权利要求1-7任一项所述的视频传输的方法。
CN201711468570.3A 2017-12-27 2017-12-27 一种视频传输的方法、存储介质、机器人及控制系统 Pending CN109982080A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201711468570.3A CN109982080A (zh) 2017-12-27 2017-12-27 一种视频传输的方法、存储介质、机器人及控制系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201711468570.3A CN109982080A (zh) 2017-12-27 2017-12-27 一种视频传输的方法、存储介质、机器人及控制系统

Publications (1)

Publication Number Publication Date
CN109982080A true CN109982080A (zh) 2019-07-05

Family

ID=67075461

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201711468570.3A Pending CN109982080A (zh) 2017-12-27 2017-12-27 一种视频传输的方法、存储介质、机器人及控制系统

Country Status (1)

Country Link
CN (1) CN109982080A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115474075A (zh) * 2022-07-31 2022-12-13 浙江工业大学 一种面向移动机器人的视频编码参数控制方法
WO2023160403A1 (zh) * 2022-02-25 2023-08-31 阿里巴巴(中国)有限公司 数据处理方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140314145A1 (en) * 2012-01-11 2014-10-23 Hitachi Maxell, Ltd. Method of encoding picture and picture encoding device
CN104917688A (zh) * 2014-03-12 2015-09-16 中国科学院声学研究所 一种流媒体网关的码率控制方法
CN106331717A (zh) * 2015-06-30 2017-01-11 成都鼎桥通信技术有限公司 视频码率自适应调整方法及发送端设备
CN106534884A (zh) * 2016-11-10 2017-03-22 中广热点云科技有限公司 一种视频编码中码率控制方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140314145A1 (en) * 2012-01-11 2014-10-23 Hitachi Maxell, Ltd. Method of encoding picture and picture encoding device
CN104917688A (zh) * 2014-03-12 2015-09-16 中国科学院声学研究所 一种流媒体网关的码率控制方法
CN106331717A (zh) * 2015-06-30 2017-01-11 成都鼎桥通信技术有限公司 视频码率自适应调整方法及发送端设备
CN106534884A (zh) * 2016-11-10 2017-03-22 中广热点云科技有限公司 一种视频编码中码率控制方法及系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023160403A1 (zh) * 2022-02-25 2023-08-31 阿里巴巴(中国)有限公司 数据处理方法及装置
CN115474075A (zh) * 2022-07-31 2022-12-13 浙江工业大学 一种面向移动机器人的视频编码参数控制方法

Similar Documents

Publication Publication Date Title
US8345740B2 (en) System, transmitter, receiver, method and software for transmitting and receiving ordered sets of video frames
CN103475902B (zh) 一种视频编码及网络传输方法和一种视频转发服务器
CA2737728C (en) Low latency video encoder
CN104125429B (zh) 视频数据传输的调节方法及装置
CN103632671B (zh) 数据编解码方法、装置及数据通信系统
CN106028053B (zh) 视频服务器和服务质量管理器
CN104735470A (zh) 一种流媒体数据传输方法及装置
CN103929681B (zh) 一种提升低速网络中rtp视频流处理效率的方法
CN105812711B (zh) 视频通话过程中优化图像质量的方法及系统
CN106341738A (zh) 流媒体网络传输的带宽计算方法、服务器端和系统
CN107566918A (zh) 一种视频分发场景下的低延时取流秒开方法
CN101909208A (zh) 一种适用于cdma2000的视频无线传输控制方法
CN104519325A (zh) 一种基于4g网络的无线视频监控系统自适应保障方法
US20160006667A1 (en) Anti-packet-loss real-time communication method, system and related device based on hierarchical coding
CN105812710B (zh) 视频通话过程中优化图像质量的方法及系统
CN103607665A (zh) 一种多链路的无线实时视频传输方法及系统
CN103686446A (zh) 视频数据传输的丢包重传方法和系统
CN101146032A (zh) 一种媒体流传输带宽自适应的方法
CN107295364A (zh) 用于弹幕视频的实时流传输控制方法、控制装置
US20140112354A1 (en) Method, apparatus, and system for processing streaming media data
CN109982080A (zh) 一种视频传输的方法、存储介质、机器人及控制系统
CN102223218A (zh) 媒体报文重传抑制方法和设备
CN109862400B (zh) 一种流媒体传输方法、装置及其系统
CN102547411A (zh) 流视频的传输和播放方法及其实现装置
CN106210785B (zh) 媒体流网络自适应单向控制方法及系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20190705