CN110087140A - 一种传输流媒体数据的方法、装置、介质及设备 - Google Patents

一种传输流媒体数据的方法、装置、介质及设备 Download PDF

Info

Publication number
CN110087140A
CN110087140A CN201810078872.8A CN201810078872A CN110087140A CN 110087140 A CN110087140 A CN 110087140A CN 201810078872 A CN201810078872 A CN 201810078872A CN 110087140 A CN110087140 A CN 110087140A
Authority
CN
China
Prior art keywords
package
data packet
flow media
data packets
media data
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.)
Granted
Application number
CN201810078872.8A
Other languages
English (en)
Other versions
CN110087140B (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.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen 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 Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201810078872.8A priority Critical patent/CN110087140B/zh
Publication of CN110087140A publication Critical patent/CN110087140A/zh
Application granted granted Critical
Publication of CN110087140B publication Critical patent/CN110087140B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • 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/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/443OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4431OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB characterized by the use of Application Program Interface [API] libraries
    • 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
    • H04N21/6437Real-time Transport Protocol [RTP]
    • 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/64784Data processing by the network
    • H04N21/64792Controlling the complexity of the content stream, e.g. by dropping packets

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Library & Information Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本申请实施例提供一种传输流媒体数据的方法、装置、介质及设备,其中,应用于发送端的传输流媒体数据的方法包括:根据接收端反馈的相邻上一个已发送的第一包组的流媒体数据包数以及冗余数据包数,确定当前待发送的第二包组的编码冗余度;根据所述第二包组的编码冗余度,对所述第二包组的流媒体数据包进行前向纠错FEC冗余编码,得到所述第二包组的冗余数据包;发送所述第二包组的流媒体数据包以及冗余数据包。本申请实施例提供的实施方式,能够在尽量占用较少网络带宽的情况下,提供足以恢复丢失的流媒体数据包的编码冗余度,可避免由于流媒体数据包的丢失而造成的视频卡顿问题。

Description

一种传输流媒体数据的方法、装置、介质及设备
技术领域
本申请涉及多媒体传输技术领域,尤其涉及一种传输流媒体数据的方法、装置、介质及设备。
背景技术
本部分旨在为权利要求书中陈述的本申请的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
流媒体是指采用流式传输的方式在互联网播放的媒体格式,又称为流式媒体。商家用一个视频传输服务器需要播放的视频编码封装成数据包传输至互联网,用户可通过客户端对互联网中相应的数据包进行视频解码并播放解码得到的视频。
目前,多采用实时传输协议(Real-time Transport Protocol,RTP)传输流媒体数据,以保证传输的实时性。RTP通常采用UDP(User Datagram Protocol,用户数据报协议)实现数据在IP(Internet Protocol,网络协议)网络上的传输,由于UDP协议的传输过程没有重传机制,所以很容易造成传输数据的丢失,而流媒体在传输过程中的流媒体数据包丢失会造成视频卡顿的问题。
发明内容
本申请提供一种传输流媒体数据的方法、装置、介质及设备,用于解决现有技术中存在的由于流媒体在传输过程中的流媒体数据包丢失所造成的视频卡顿的问题。
第一方面,本申请实施例提供一种传输流媒体数据的方法,包括:
根据接收端反馈的相邻上一个已发送的第一包组的流媒体数据包数以及冗余数据包数,确定当前待发送的第二包组的编码冗余度;
根据所述第二包组的编码冗余度,对所述第二包组的流媒体数据包进行前向纠错FEC冗余编码,得到所述第二包组的冗余数据包;
发送所述第二包组的流媒体数据包以及冗余数据包。
可选地,所述确定当前待发送的第二包组的编码冗余度,具体包括:
将所述接收端反馈的所述第一包组的流媒体数据包数与冗余数据包数的和值作为第一和值;以及,
将保存的所述第一包组的流媒体数据包数与冗余数据包数的和值作为第二和值;
根据所述第一和值与所述第二和值,确定所述第一包组的丢包率;
确定所述第二包组的流媒体数据包数与所述第一包组的丢包率的乘积;
将所述乘积向上取整所得的结果作为所述第二包组的编码冗余度。
可选地,所述确定所述第一包组的丢包率,具体包括:
确定所述第一和值与所述第二和值的差值;
将所述差值的绝对值除以所述第二和值的所得的结果,作为所述第一包组的丢包率。
可选地,对所述第二包组的流媒体数据包进行FEC冗余编码之前,还包括:
确定存储的第二包组的流媒体数据包数等于预设值。
可选地,对所述第二包组的流媒体数据包进行FEC冗余编码之前,还包括:
对所述第二包组中长度小于预设长度的流媒体数据包的长度进行补0操作,以使其长度等于预设长度。
可选地,所述流媒体数据包包括扩展包头,该扩展包头包括该流媒体数据包所属包组的序号、该流媒体数据包的有效数据长度、该流媒体数据包在所属包组内的序号以及该流媒体数据包的判别标识;所述冗余数据包包括扩展包头,该扩展包头包括该冗余数据包所属包组的序号、该冗余数据包的有效数据长度、该冗余数据包在所属包组内的序号以及该冗余数据包的判别标识。
第二方面,本申请实施例提供一种传输流媒体数据的装置,包括:
第一确定模块,用于根据接收端反馈的相邻上一个已发送的第一包组的流媒体数据包数以及冗余数据包数,确定当前待发送的第二包组的编码冗余度;
编码模块,用于根据所述第二包组的编码冗余度,对所述第二包组的流媒体数据包进行前向纠错FEC冗余编码,得到所述第二包组的冗余数据包;
发送模块,用于发送所述第二包组的流媒体数据包以及冗余数据包。
第三方面,本申请实施例提供一种非易失性计算机存储介质,所述计算机存储介质存储有可执行程序,该可执行程序被处理器执行实现第一方面提供的任一传输流媒体数据的方法的步骤。
第四方面,本申请实施例提供一种计算机设备,包括存储器、处理器及存储在存储器上的计算机程序,所述处理器执行所述程序时实现第一方面提供的任一传输流媒体数据的方法的步骤。
第五方面,本申请实施例提供一种传输流媒体数据的方法,包括:
接收发送端发送的包组的流媒体数据包和冗余数据包,所述冗余数据包为前向纠错FEC冗余编码后得到的冗余数据包;
确定接收到的所述包组的流媒体数据包数以及冗余数据包数;
将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端。
可选地,所述将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端,具体包括:
在实时控制协议RTCP的接收者报告RR包中添加第一扩展字段、第二扩展字段以及第三扩展字段;
将所述包组的序号写入所述第一扩展字段,将所述包组的流媒体数据包数写入所述第二扩展字段,以及,将所述包组的冗余数据包数写入所述第三扩展字段,得到写入RR包;
将所述写入RR包反馈给所述发送端。
可选地,所述流媒体数据包包括扩展包头,该扩展包头包括该流媒体数据包所属包组的序号以及该流媒体数据包的判别标识,所述冗余数据包包括扩展包头,该扩展包头包括该冗余数据包所属包组的序号以及该冗余数据包的判别标识,则所述接收发送端发送的包组的流媒体数据包以及冗余数据包,具体包括:
响应于数据包到达通知,根据该数据包的扩展包头中的判别标识,确定该数据包是流媒体数据包还是冗余数据包;
若该数据包为流媒体数据包,将该流媒体数据包存储至第一链表缓存区;
若该数据包为冗余数据包,将该冗余数据包存储至第二链表缓存区。
可选地,所述确定接收到的所述包组的流媒体数据包数以及冗余数据包数,具体包括:
确定所述第一链表缓存区中扩展包头包含所述包组的序号的流媒体数据包数,以及,
确定第二链表缓存区中扩展包头包含所述包组的序号的冗余数据包数。
可选地,所述将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端,具体包括:
若确定的所述包组的流媒体数据包数与冗余数据包数之和不小于预设值,或者,若所述第一链表缓存区无可用空间,则将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端。
可选地,所述流媒体数据包的扩展包头还包括该流媒体数据包的有效数据长度以及该流媒体数据包在所属包组内的序号,所述冗余数据包的扩展包头还包括该冗余数据包的有效数据长度以及该冗余数据包在所属包组内的序号,则所述方法还包括:
将所述第一链表缓存区存储的所述包组的流媒体数据包,以及,所述第二链表缓存区存储的所述包组的冗余数据包存储至第三链表缓存区;
去除所述第三链表缓存区中的流媒体数据包和冗余数据包的扩展包头;
根据第三链表缓存区中各个流媒体数据包的扩展包头以及冗余数据包的扩展包头,以及去除扩展包头后的流媒体数据包和冗余数据包,对所述包组进行FEC解码处理。
可选地,本申请实施例提供的传输流媒体数据的方法,还包括:
删除所述第一链表缓存区中已进行FEC解码处理的流媒体数据包,以及,
删除所述第二链表缓存区中已进行FEC解码处理的冗余数据包;以及,
清空所述第三链表缓存区。
第六方面,本申请实施例提供一种传输流媒体数据的装置,包括:
接收模块,用于接收发送端发送的包组的流媒体数据包和冗余数据包,所述冗余数据包为前向纠错FEC冗余编码后得到的冗余数据包;
确定模块,用于确定接收到的所述包组的流媒体数据包数以及冗余数据包数;
反馈模块,用于将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端。
第七方面,本申请实施例提供一种非易失性计算机存储介质,所述计算机存储介质存储有可执行程序,该可执行程序被处理器执行实现第五方面提供的任一传输流媒体数据的方法的步骤。
第八方面,本申请实施例提供一种计算机设备,包括存储器、处理器及存储在存储器上的计算机程序,所述处理器执行所述程序时实现第五方面提供的任一传输流媒体数据的方法的步骤。
第九方面,本申请实施例提供一种传输流媒体数据的***,包括:
接收端,用于接收发送端发送的第一包组的流媒体数据包和冗余数据包,所述冗余数据包为前向纠错FEC冗余编码后得到的冗余数据包;确定接收到的所述第一包组的流媒体数据包数以及冗余数据包数;将确定的所述第一包组的流媒体数据包数以及冗余数据包数反馈给所述发送端;
发送端,用于根据接收端反馈的第一包组的流媒体数据包数以及冗余数据包数,确定当前待发送的第二包组的编码冗余度;根据所述第二包组的编码冗余度,对所述第二包组的流媒体数据包进行FEC冗余编码,得到所述第二包组的冗余数据包;发送所述第二包组的流媒体数据包以及冗余数据包,其中,第一包组为与所述第二包组相邻的上一个已发送包组。
本申请实施例提供的传输流媒体数据的方法、装置、介质及设备,具有以下有益效果:根据接收端反馈的相邻上一个已发送的第一包组的流媒体数据包数和冗余数据包数,确定当前待发送的第二包组的编码冗余度,并对第二包组进行FEC冗余编码后,发送第二包组的流媒体数据包和冗余数据包,从而实现了动态调整当前待发送包组的编码冗余度,能够在尽量占用较少网络带宽的情况下,提供足以恢复丢失的流媒体数据包的编码冗余度,可避免由于流媒体数据包的丢失而造成的视频卡顿问题。
附图说明
通过参考附图阅读下文的详细描述,本申请示例性实施例的上述以及其他目的、特征和优点将变得易于理解。在附图中,以示例性而非限制性的方式示出了本申请的若干实施方式,其中:
图1为本申请实施例的应用场景示意图;
图2为本申请实施例提供的应用于发送端的传输流媒体数据的方法流程示意图;
图3为本申请实施例提供的确定第二包组的编码冗余度的方法流程示意图;
图4为本申请实施例提供的数据包的格式示意图;
图5为本申请实施例提供的发送端的架构示意图;
图6为本申请实施例提供的视频编码数据报文格式示意图;
图7为本申请实施例提供的应用于接收端的传输流媒体数据的方法流程示意图;
图8为本申请实施例提供的将流媒体数据包数以及冗余数据包数反馈给发送端的方法流程示意图;
图9为本申请实施例提供的接收发送端发送的流媒体数据包以及冗余数据包的方法流程示意图;
图10为本申请实施例提供的接收端进行FEC冗余解码处理的方法流程示意图;
图11为本申请实施例提供的应用于发送端的传输流媒体数据的装置示意图;
图12为本申请实施例提供的应用于接收端的传输流媒体数据的装置示意图;
图13为本申请实施例提供的用于实现发送端的传输流媒体数据的方法的计算设备硬件结构示意图;
图14为本申请实施例提供的用于实现接收端的传输流媒体数据的方法的计算设备硬件结构示意图。
具体实施方式
现有技术中,为了缓解因流媒体数据包丢失造成的视频卡顿问题,在传输流媒体时可加入FEC(前向纠错,Forward Eeeor Correction)冗余数据包,以使流媒体接收端通过FEC冗余数据包以及接收到的流媒体数据包恢复出在流媒体传输过程中丢失的流媒体数据包。然而,发明人发现,现有的FEC冗余编码技术中,FEC的编码冗余度均为固定值,在网络环境较好的情况下,可能使用比固定值小的编码冗余度即可恢复出丢失的所有流媒体数据包,此时若使用固定值会导致占用较高网络带宽的问题;在网络环境较差的情况下,流媒体数据包的丢失个数较多,可能需要使用比固定值大的编码冗余度才可恢复出所有丢失的流媒体数据包,此时若使用固定值,依然会有流媒体数据包丢失。
为此,本申请实施例提供一种传输流媒体数据的方法,该方法可以包括:根据接收端反馈的相邻上一个已发送的第一包组的流媒体数据包数以及冗余数据包数,确定当前待发送的第二包组的编码冗余度;根据所述第二包组的编码冗余度,对所述第二包组的流媒体数据包进行前向纠错FEC冗余编码,得到所述第二包组的冗余数据包;发送所述第二包组的流媒体数据包以及冗余数据包。
本申请实施例提供的传输流媒体数据的方法,可根据接收端反馈的相邻上一个已发送的第一包组的流媒体数据包数和冗余数据包数,确定当前待发送的第二包组的编码冗余度,并对第二包组进行FEC冗余编码后,发送第二包组的流媒体数据包和冗余数据包,从而实现了动态调整当前待发送包组的编码冗余度,能够在尽量占用较少网络带宽的情况下,提供足以恢复丢失的流媒体数据包的编码冗余度,可避免由于流媒体数据包的丢失而造成的视频卡顿问题。
下面结合图1,对本申请实施例提供的传输流媒体数据的方案的应用场景进行说明,如图1所示,包括接收端101和发送端102,接收端101接收发送端102发送的包组的流媒体数据包和冗余数据包;确定接收到的包组的流媒体数据包数以及冗余数据包数;将确定的包组的流媒体数据包数以及冗余数据包数反馈给发送端102。发送端102根据接收端101反馈相邻上一个已发送的第一包组的流媒体数据包数以及冗余数据包数,确定当前待发送的第二包组的编码冗余度;根据第二包组的编码冗余度,对第二包组的流媒体数据包进行FEC冗余编码,得到第二包组的冗余数据包;向所述接收端101发送第二包组的流媒体数据包以及冗余数据包。其中,接收端101和发送端102通过可以通过局域网、广域网或移动互联网等通信网络进行通信;接收端和发送端可以为便携设备(例如:手机、平板、笔记本电脑等),也可以为个人电脑(PC,Personal Computer)。在一些情况下,发送端可以具备接收端的功能,接收端可具备发送端的功能,即接收端和发送端可以互换。可端的,接收端为客户端,发送端为服务器。图1中仅示出包括一个接收端的应用场景,在实际应用中,也可以包括多个接收端,即多个接收端分别与同一发送端进行流媒体数据的传输。
为使本申请的目的、技术方案和优点更加清楚,下面将对本申请可能的实施方式作进一步描述。需要注意的是,上述应用场景仅是为了便于理解本申请的精神和原理而示出,本申请的实施方式在此方面不受任何限制。相反,本申请的实施方式可以应用于适用的任何场景。
本申请实施例提供一种传输流媒体数据的方法,应用于发送端,如图2所示,包括:
步骤201,根据接收端反馈的相邻上一个已发送的第一包组的流媒体数据包数以及冗余数据包数,确定当前待发送的第二包组的编码冗余度。
发送端根据各个包组对应的视频帧的播放顺序,依次发送各个包组的数据包,包组的数据包包括流媒体数据包和冗余数据包,具体的,发送端向接收端发送包组的数据包。发送端发送的数据包经过网络的传输到达接收端,由于网络环境的不确定性,到达接收端的数据包可能有所丢失,为了实时调整当前待发送的第二包组的编码冗余度,接收端需要向发送端反馈相邻上一个已发送的第一包组的流媒体数据包数以及冗余数据包数。
其中,第一包组为与第二包组相邻的上一个已发送的包组,即第一包组为发送顺序位于第二包组之前且与第二包组相邻的一个已发送的包组,第二包组为发送端的当前待发送的包组。
具体实施时,发送端响应于接收端的RTSP(Real Time Streaming Protocol,实时流传输协议)地址访问请求,开始采集视频数据,每完成一帧视频数据的采集,即对采集到的该帧视频数据进行视频编码,得到该帧视频数据对应的视频编码数据;按照预设传输协议,将该帧视频数据对应的视频编码数据封装成流媒体数据包;对封装得到的流媒体数据包进行FEC冗余编码,将得到冗余数据包;将封装得到的流媒体数据包以及编码得到的冗余数据包组成一个包组,并发送该包组的流媒体数据包和冗余数据包。接收端可根据接收到的包组的流媒体数据包和冗余数据包进行相应的FEC解码处理以及视频解码处理,并解码得到的视频进行播放。其中,预设传输协议可以为RTP,即包组内的流媒体数据包以及冗余数据包均为RTP数据包。
具体实施时,可采用H.264视频编码技术对采集到的视频数据进行视频编码,也可采用其他视频编码技术对采集到的视频数据进行视频编码,这里不做限定。
步骤202,根据所述第二包组的编码冗余度,对所述第二包组的流媒体数据包进行FEC冗余编码,得到所述第二包组的冗余数据包。
具体实施时,针对采集到的每帧视频数据,每对该帧视频数据对应的视频编码数据封装得到一个流媒体数据包,则将该流媒体数据包存储至发送端,具体可存储至发送端的第一缓存区。实际应用中,可使用FEC冗余编码中的里所码(Reed-solomon codes,RS码)进行冗余编码,也可使用低密度奇偶校验码(Low Density Parity Check Code,LDPC)、LT数字喷泉码或Raptor码等进行冗余编码,这里不做限定。
可选地,对所述第二包组的流媒体数据包进行FEC冗余编码之前,还包括:确定存储的第二包组的流媒体数据包数等于预设值,其中,预设值为第二包组中包含的流媒体数据包的总数,或者,预设值为根据实际应用需求设定的值,这里不做限定。
可选地,对所述第二包组的流媒体数据包进行FEC冗余编码之前,还包括:对所述第二包组中长度小于预设长度的流媒体数据包的长度进行补0操作,以使其长度等于预设长度。
具体的,采用FEC冗余编码中的RS码进行冗余编码时,要求被编码的各个流媒体数据包的长度相同,因此需要对第二包组中长度小于预设长度的流媒体数据包进行补零操作,以使第二包组中各个流媒体数据包的长度相同。当流媒体数据包为RTP数据包时,预设长度为RTP数据包的最大长度,该最大长度为1448字节。其中,补零操作即在流媒体数据包的有效数据之后补零,以得到预设长度的流媒体数据包。
可选地,将第二包组的冗余数据包保存至发送端的第二缓存区;确定所述第二包组的流媒体数据包以及冗余数据包发送完毕时,释放所述第二缓存区,以节省发送端缓存空间。
步骤203,发送所述第二包组的流媒体数据包以及冗余数据包。
具体实施时,各个包组的流媒体数据包以及冗余数据包具有发送顺序,可根据包组的流媒体数据包和冗余数据包发送顺序的先后,为流媒体数据包和冗余数据包设置序号,其中,序号越小的流媒体数据包和冗余数据包的发送顺序越靠前,并且,包组的流媒体数据包的发送顺序先于冗余数据包。
需要说明的是,第一包组和第二包组为非第一发送顺序的包组,发送端在发送第一发送顺序的包组时,尚未接收到接收端反馈的流媒体数据包数和冗余数据包数,此时发送端可根据预设编码冗余度,对第一发送顺序的包组的流媒体数据包进行FEC冗余编码,该预设编码冗余度可根据实际应用需求设定,这里不做限定。
本申请实施例,可根据接收端反馈的相邻上一个已发送的第一包组的流媒体数据包数和冗余数据包数,确定当前待发送的第二包组的编码冗余度,并对第二包组进行FEC冗余编码后,发送第二包组的流媒体数据包和冗余数据包,从而实现了动态调整当前待发送包组的编码冗余度,能够在尽量占用较少网络带宽的情况下,提供足以恢复丢失的流媒体数据包的编码冗余度,可避免由于流媒体数据包的丢失而造成的视频卡顿问题。
本申请实施例中,若接收端反馈的流媒体数据包数和冗余数据包数过少,则说明当前网络环境较差,此时确定的当前待发送包组的编码冗余度较大;若接收端反馈的流媒体数据包数和冗余数据包数较多,则说明当前网络环境较好,此时确定的当前待发送包组的编码冗余度较小,根据接收端反馈的流媒体数据包数和冗余数据包数,可实现动态调整当前待发送包组的编码冗余度,这样能够在尽量占用较少网络带宽的情况下,提供足以恢复丢失的流媒体数据包的编码冗余度。
可选地,按照图3提供的内容,确定当前待发送的第二包组的编码冗余度:
步骤301,将所述接收端反馈的所述第一包组的流媒体数据包数与冗余数据包数的和值作为第一和值。
具体实施时,发送端发送包组的过程中,可能会由于网络环境较差等原因造成包组内数据包的丢失,本步骤中确定接收端反馈的第一包组的流媒体数据包数与冗余数据包数的和值,并将该和值作为第一和值,为后续确定第二包组的编码冗余度提供基础。
步骤302,将保存的所述第一包组的流媒体数据包数与冗余数据包数的和值,作为第二和值。
具体实施时,发送端发送包组的同时,在发送端中保存正在发送的包组的流媒体数据包和冗余数据包,此时保存的包组的媒体数据包和冗余数据包不会受网络环境影响而丢失。本步骤中,确定发送端保存的第一包组的流媒体数据包和冗余数据包的和值,并将该和值作为第二和值。其中,若发送端发送第一包组时发生数据包丢失,则第一和值小于第二和值。
具体实施时,不对步骤301和步骤302执行顺序先后进行限定,也可先执行步骤302后执行步骤301,或者二者同时执行。
步骤303,根据所述第一和值与所述第二和值,确定所述第一包组的丢包率。
具体实施时,可计算第一和值与第二和值的差值,将该差值的绝对值除以第二和值所得的结果,作为第一包组的丢包率。
步骤304,确定所述第二包组的流媒体数据包数与所述第一包组的丢包率的乘积。
步骤305,将所述乘积向上取整所得的结果作为所述第二包组的编码冗余度。
具体实施时,获取第二包组的流媒体数据包数,并确定获取的流媒体数据包数与第一包组的丢包率的乘积。对该乘积进行向上取整,并将对该乘积进行向上取整所得的结果,作为第二包组的编码冗余度。或者,也可将对该乘积进行向下取整所得的结果,作为第二包组的编码冗余度,这里不做限定。
可选地,在当前待发送的包组的流媒体数据包以及冗余数据包中添加扩展包头;所述流媒体数据包的扩展包头包括该流媒体数据包所属包组的序号、该流媒体数据包的有效数据长度、该流媒体数据包在所属包组内的序号以及该流媒体数据包的判别标识;所述冗余数据包的扩展包头包括该冗余数据包所属包组的序号、该冗余数据包的有效数据长度、该冗余数据包在所属包组内的序号以及该冗余数据包的判别标识。发送端发送包组的添加扩展包头后的流媒体数据包以及冗余数据包。接收端可根据扩展包头确定接收到的包组的流媒体数据包数以及冗余数据包数。此外,接收端还可根据接收到的包组的流媒体数据包和冗余数据包中的扩展包头对该包组进行FEC解码处理,以恢复出该包组在传输过程中丢失的流媒体数据包。
具体的,数据包(包括流媒体数据包和冗余数据包)的格式如图4所示,下面对图4中的各个字段进行介绍:
Pkt_Size字段用于填充数据包的有效数据长度,当该数据包为补零后的数据包时,该数据包的有效数据补零前的有效负载,这样接收端可根据该Pkt_Size字段恢复出该数据包中的有效负载,以避免将该数据包中所补充的零作为有效数据,可选地,Pkt_Size字段的长度为2字节。
Blk_Num字段用于填充该数据包所属包组的序号,其中,同一包组的流媒体数据包和冗余数据包中该Blk_Num字段的值相同,不同包组的流媒体数据包和冗余数据包中该Blk_Num字段的值不同,接收端可根据Blk_Num字段区分其接收到的各个数据包所属的包组,可选地,Blk_Num字段的长度为4字节。
Blk_Seq_Num字段用于填充该数据包在其所属包组内的序号,其中,按照包组的数据包由前到后的发送顺序,为该包组内的各个数据包设置序号,其中,在包组内的序号越大,该数据包的发送顺序越靠后,并且,冗余数据包的序号大于流媒体数据包的序号,且各个数据包的序号互不相同且后一数据包的序号在前一数据包的序号的基础上递增1,起始数据包的序号可以为0也可以为1,这里不做限定,此时,同一包组内所有数据包都会有唯一的序号,接收端可根据该Blk_Seq_Num字段以及Blk_Num字段,识别包组在传输至接收端后,该包组内丢失的数据包,可选地,Blk_Seq_Num字段的长度为1字节。
Pkt_Redundancy字段用于填充该数据包的判别标识,当该字段中填充的判别标识为特定值时,表示该数据包为冗余数据包,当该字段中填充的判别标识为非特定值时,表示该数据包为流媒体数据包,可选地,特定值为该数据包所属包组的编码冗余度,该特定值也可以为其它数值,比如为0xff。
上述各个字段的名称仅为示例性名称,也可根据将个字段的名称设置为其它名称,只要各个字段名称不同即可。
下面结合图5对本申请实施例提供的发送端架构进行介绍。
本申请实施例的发送端的架构如图5所示,其中,发送端的硬件架构为图5所示的Tiny6410硬件架构,发送端的软件架构由图5的H.264视频编码进程、流媒体发送端进程以及Linux内核组成,Linux内核包括硬件架构中相应硬件模块的驱动。发送端的硬件架构和软件架构相互配合,实现本申请实施例提供的发送端传输流媒体数据包的方法的步骤。当然,图5仅为适用于本申请实施例的一种发送端的架构示例,也可利用其它适用于本申请实施例的架构实现本申请实施例的传送端传输流媒体数据的方法。
下面对发送端中的Tiny6410硬件架构中各模块进行简单介绍:
Tiny6410为FriendlyARM公司定制的开发板,该开发板上集成了基于ARM11内核的S3C6410微处理器、OV9650图像传感器、RT3070USB WIFI、256M DDR RAM、256M Nand Flash等,还提供了USB Host、SD/MMC和CameraIF等多种外设接口(图中未示出)。视频采集部分选用了OV9650图像传感器,OV9650图像传感器支持最高30fps VGA(640x480)YUV模式,基本可以达到实时视频监控的需求;因S3C6410微处理器内部集成了一个硬件编码器(MultiFormat Codec,MFC),硬件编码时可不占用S3C6410微处理器的CPU资源,故选用了硬件编码器对采集到的视频数据进行视频硬件编码,具体可对采集到的视频数据进行H.264格式的视频硬件编码;发送端无线网络传输部分选用了RT3070USB WIFI模块搭建无线AP(AccessPoint,接入点),其传输速率最高可达150Mbps。
下面对发送端中的软件架构进行介绍:
H.264视频编码进程响应于接收端的RTSP地址访问请求,通过Unix DomainSocket进程间通信下发视频采集和视频编码指令给H.264视频编码进程;H.264视频编码进程每完成一帧视频数据的采集和编码后,将该帧视频数据的视频编码数据发送给流媒体发送端进程,流媒体发送端进程将接收到的视频编码数据封装成RTP流媒体数据包,并利用本身请实施例提供的传输流媒体数据包的方法进行流媒体数据包的发送。
H.264视频编码进程和流媒体发送端进程间通信的视频编码数据报文格式可如图6所示,其中,Command字段为1字节的自定义命令码,Datalen字段为4字节的整型变量。
在H.264视频编码进程向流媒体发送端进程发送该报文的情况下,图6中的Command字段用于填充开始发送视频编码数据报文标识,或者,Command字段用于填充准备结束标识,即,H.264视频编码进程结束向流媒体发送端进程发送报文,Datalen字段用于填充当前发送报文中去除报头后的有效视频编码数据长度,有效负载字段用于承载当前发送的报文中有效视频编码数据。
在流媒体发送端进程向H.264视频编码进程发送该报文的情况下,图6中的Command字段用于填充成功响应标识,该标识用于说明流媒体发送端进程接收到H.264视频编码进程发送的报文,或者,Command字段用于填充发送失败标识,该标识用于说明流媒体发送端进程未接收到H.264视频编码进程发送的报文,由于流媒体发送端进程向H.264视频编码进程反馈的报文中无需携带有效视频编码数据长度和有效负载,因此Datalen字段以及有效负载字段均为空。
其中,Command字段填充的不同的标识可使用不同的数值区分,这里不对具体数值进行限定。
H.264视频编码进程采用了多线程架构,包括Video4Linux2视频采集线程、H.264硬视频编码压缩线程和视频数据输出线程。各线程之间的数据交互采用Fifo(先入先出)机制来实现,各线程并行执行。
其中,V4L2(即Video4Linux2)是Linux***下主流的视频采集驱动程序的规范,直接调用V4L2API接口即可采集到OV9650图像传感器中的视频帧数据。为了简化视频采集的操作,V4L2视频采集线程对该V4L2规范进行了封装,简化为4个步骤:(1)视频采集初始化:调用V4L2命令完成打开图5中的图像传感器、查询图像传感器的设备属性、设置视频帧格式、请求图5的Linux内核中集成的V4L2驱动分配帧缓冲(帧缓冲指为视频帧数据单独开辟的一块内存空间)、驱动帧缓冲映射到用户空间(用于运行图5中H.264视频编码进程和流媒体发送端进程的空间)等工作;(2)获取一个视频帧:调用V4L2命令从图5中的图像传感器获取一个视频帧;(3)视频帧入队列:调用V4L2命令完成帧缓冲返回fifo队列的工作;(4)视频采集关闭:调用V4L2命令关闭图5中的图像传感器。
H.264硬视频编码压缩线程采用了S3C6410微处理器中的硬件编码器进行H.264硬件编码压缩,从而可以减少微处理器CPU资源的占用并提高视频编码速度。硬件编解码器提供了多个API接口用于执行H.264硬件编码压缩,压缩流程包括硬件编码器初始化、H.264硬件编码压缩的执行、H.264硬件编码后的视频编码数据生成以及硬件编码器释放等。
视频数据输出线程主要负责与流媒体发送端进程进行视频编码数据报文的交互,本线程主要将已经过视频编码后的视频编码数据发送给流媒体发送端进程。
其中,流媒体发送端进程可基于开源的LIVE555多媒体传输框架进行H.264编码格式的流媒体数据传输。具体实施时,可在该框架中创建BasicTaskScheduler对象和任务调试器,设置使用环境;创建RTSP服务和会话,并将会话加入到RTSP服务中,从而实现流媒体数据传输环境的搭建。之后,为了实现流媒体发送端进程传输流媒体数据包和冗余数据包,可在该框架中构造用于从视频数据输出线程获取视频编码数据的类(比如可以命名为PipeStreamSource类),该类将获取的视频编码数据转发给用于通知该类继续获取视频编码数据的接口(比如命名为doGetNextFrame()接口)和错误检测组件(比如命名为H264FrameSource组件),错误检测组件按照H.264码流结构分析该类转发的视频编码数据是否符合H.264的编码规范,若符合则生成相应的SDP描述,若不符合,则丢弃获取到的视频编码数据。将符合编码规范的视频编码数据发送给封装组件(比如命名为H264RTPSink组件),封装组件将视频编码数据封装成RTP流媒体数据包,封装组件将封转得到的RTP流媒体数据包发送给FEC冗余编码组件(比如命名为H264FecEncode组件),FEC冗余编码组件利用本申请实施例提供的发送端的传输流媒体数据包的方法发送包组的流媒体数据包和冗余数据包。
其中,FEC冗余编码组件可自定义封装3个API函数,包括:1、API函数AFecInit(RS_K,RS_R,FecBuf),用于完成FEC冗余编码结构初始化,并为得到的冗余数据包分配对应的冗余数据包缓存区(对应上述第二缓存区),该函数中RS_K为预设值,RS_R为编码冗余度,FecBuf为冗余数据包缓存区,其中,冗余数据包缓存区的大小可根据编码冗余度动态设置,该冗余数据包缓存区大小具体为编码冗余度与冗余数据包长度的乘积;2、API函数AFecEnc(SourceFec,RS_K*PktSize,PktSize),用于对包组的流媒体数据包进行FEC冗余编码,并将生成的FEC冗余数据包存放到分配的冗余数据包缓存区中,其中,PktSize为流媒体数据包的有效数据长度,RS_K为预设值;3、API函数AFecUninit(FecHandle pHandle),用于在一个包组的流媒体数据包和冗余数据包都发送完成时,释放冗余数据包缓存区。
本申请实施例可应用于家居安防、车载监控、目标跟踪等对可靠性、实时性要求高的***。
本申请实施例提供一种传输流媒体数据的方法,应用于发送端,如图7所示,包括:
步骤701,接收发送端发送的包组的流媒体数据包和冗余数据包,所述冗余数据包为FEC冗余编码后得到的冗余数据包。
具体实施时,发送端发送包组的流媒体数据包和冗余数据包后,相应的接收端可接收流媒体数据包和冗余数据包,受网络环境的影响,发送端发送包组的流媒体数据包和冗余数据包的过程中,可能会出现丢包的情况,此时,接收端可能无法接收包组的所有流媒体数据包和冗余数据包。其中,冗余数据包为发送端根据包组的流媒体数据包和编码冗余度进行FEC冗余编码后得到的冗余数据包。
可选地,接收端保存接收到的包组的流媒体数据包和冗余数据包。
可选地,发送端发送的包组相当于步骤201中的第一包组。
步骤702,确定接收到的所述包组的流媒体数据包数以及冗余数据包数。
步骤703,将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端。
具体实施时,可将确定的该包组的流媒体数据包数以及冗余数据包数单独反馈至发送端,也可通过在RTCP(Real-time Control Protocol,实时控制协议)的RR(接收者报告)包中添加包组的流媒体数据包数以及冗余数据包数,通过RR包将包组的流媒体数据包数以及冗余数据包数反馈给发送端。
可选地,若确定的所述包组的流媒体数据包数与冗余数据包数之和不小于预设值,则将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给发送端,其中,该预设值与上文提到的预设值相同。
可选地,按照图8提供的内容,将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端:
步骤801,在RTCP的RR包中添加第一扩展字段、第二扩展字段以及第三扩展字段。
具体可在RR包的头部添加第一扩展字段、第二扩展字段以及第三扩展字。
步骤802,将所述包组的序号写入所述第一扩展字段,将所述包组的流媒体数据包数写入所述第二扩展字段,以及,将所述包组的冗余数据包数写入所述第三扩展字段,得到写入RR包。
具体实施时,包组的序号用于区分不同的包组,在实际应用中,只要将包组的序号、该包组的流媒体数据包数以及该包组的冗余数据包数分别写入三个扩展字段即可,比如,还可将所述包组流媒体数据包数写入所述第一扩展字段,将所述包组的序号写入所述第二扩展字段,以及,将所述包组的冗余数据包数写入所述第三扩展字段。
需要说明的是,发送端和接收端需预先约定写入RR包的不同扩展字段所写入的内容,这样发送端接收到写入RR包后才可准确解析出相应的流媒体数据包数和冗余数据包数。
步骤803,将所述写入RR包反馈给所述发送端。
具体实施时,通过RTCP协议将写入RR包反馈给发送端,以使发送端根据写入RR包中的扩展字段,解析出相应包组的流媒体数据包数和冗余数据包数,作为接收端反馈的包组的流媒体数据包数和冗余数据包数。
本申请实施例,使用RTCP中的RR将包组的流媒体数据包数和冗余数据包数反馈给发送端,无需单独发送包组的流媒体数据包数和冗余数据包数反馈给发送端,在一定程度上节省了网络资源。
可选地,所述流媒体数据包包括扩展包头,该扩展包头包括该流媒体数据包所属包组的序号以及该流媒体数据包的判别标识,所述冗余数据包包括扩展包头,该扩展包头包括该冗余数据包所属包组的序号以及该冗余数据包的判别标识,其中,扩展包头中包组的序号和判别标识的含义上文已将介绍,这里不做赘述。
可选地,可按照图9提供的内容,接收发送端发送的包组的流媒体数据包以及冗余数据包:
步骤901,响应于数据包到达通知,根据该数据包的扩展包头中的判别标识,确定该数据包是流媒体数据包还是冗余数据包。
具体实施时,接收端的监听socket描述符收到数据包到达通知时,解析该数据包的扩展包头中的判别标识,在判别标识表示该数据包为流媒体数据包的情况下,执行步骤902,在判别标识表示该数据包为冗余数据包的情况下,执行步骤903。
更具体的,若该数据包的扩展包头中所属包组的序号小于或等于指定包组的序号,则将该数据包丢弃,指定包组为接收端最近反馈给发送端的包组的序号,其中,最近反馈给发送端的包组为所有已反馈给发送端的包组中序号最大的包组。
步骤902,将该流媒体数据包存储至第一链表缓存区。
可按照流媒体数据包其所属包组的序号由小到大的顺序,将包组的流媒体数据包存储至第一链表缓存区。
步骤903,将该冗余数据包存储至第二链表缓存区。
可按照冗余数据包在其所属包组的序号由小到大的顺序,将包组的冗余数据包存储至第二链表缓存区。
其中,第一链表缓存区和第二链表缓存区分别为具有链表结构且有序的缓存区,接收到的流媒体数据包会按照其在所属包组内的序号由小到大的顺序存储至第一链表缓存区,接收到的冗余数据包会按照其在所属包组内的序号由小到大的顺序存储至第二链表缓存区,以便在相应链表缓存区中进行快速查找遍历操作。
可选地,确定接收到的所述包组的流媒体数据包数以及冗余数据包数,具体包括:确定所述第一链表缓存区中扩展包头包含所述包组的序号的流媒体数据包数,以及,确定第二链表缓存区中扩展包头包含所述包组的序号的冗余数据包数。
具体实施时,根据数据包的扩展包头,分别遍历第一链表缓存区和第二链表缓存区,以统计第一链表缓存区中包含同一包组的序号的流媒体数据包数以及第二链表缓存区中包含该同一包组的序号的冗余数据包数。
可选地,若所述第一链表缓存区无可用空间,则将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给发送端。
具体实施时,在第一链表缓存区无可用空间时,接收端无法继续存储流媒体数据包,此时为了保证发送端能够实时确定出当前待发送包组的编码冗余度,可向发送端反馈包组的流媒体数据包数以及冗余数据包数。
可选地,所述流媒体数据包的扩展包头还包括该流媒体数据包的有效数据长度以及该流媒体数据包在所属包组内的序号,所述冗余数据包的扩展包头还包括该冗余数据包的有效数据长度以及该冗余数据包在所属包组内的序号,上文已对扩展包头中的所属包组内的序号以及有效数据长度进行说明,这里不做赘述。
如图10所示,本申请实施例提供的传输流媒体数据的方法,还包括:
步骤1001,将所述第一链表缓存区存储的所述包组的流媒体数据包,以及,所述第二链表缓存区存储的所述包组的冗余数据包存储至第三链表缓存区。
其中,第三链表缓存区为具有链表结构且有序的缓存区,可按照流媒体数据包和冗余数据包在其所属包组的序号由小到大的顺序,将包组的流媒体数据包和冗余数据包存储至第三链表缓存区,以便在第三链表缓存区中进行快速查找遍历操作,从而对第三链表缓存区中的流媒体数据包和冗余数据包进行FEC解码处理。
可选地,在步骤1001之前,确定第一链表缓存区中扩展包头中的所属包组的序号小于步骤1001中包组的序号的流媒体数据包;去除确定出的流媒体数据包的扩展包头,并对去除扩展包头后的流媒体数据包进行视频解码处理,具体当视频编码采用H.264视频编码算法时,视频解码相应采用H.264视频解码算法。
步骤1002,去除所述第三链表缓存区中的流媒体数据包和冗余数据包的扩展包头。
具体实施时,由于扩展包头为额外添加的包头,因此在对流媒体数据包和冗余数据包进行FEC解码处理之前,需要将流媒体数据包的扩展包头以及冗余数据包的扩展包头去除。
步骤1003,根据第三链表缓存区中各个流媒体数据包的扩展包头以及冗余数据包的扩展包头,以及去除扩展包头后的流媒体数据包和冗余数据包,对所述包组进行FEC解码处理。
具体实施时,针对任一包组中每个去除扩展包头后的数据包(数据包为流媒体数据包或者冗余数据包),解析该数据包的扩展包头,根据扩展包头中的数据包所属包组的序号,确定该数据包所属的包组;根据扩展包头中的判别标识确定该数据包是流媒体数据包还是冗余数据包;根据该数据包的有效数据长度以及该数据包的长度,确定该数据包是否进行了补零操作,若是,对该数据包进行去零操作,以得到原始数据包;记录该数据包在所属包组内的序号。根据该任一包组中各个数据包的序号,确定是否丢失数据包,若是,则根据该任一包组的去除扩展包头后的流媒体数据包和冗余数据包,对该任一包组进行FEC解码处理,并对FEC解码处理后的数据进行相应的视频解码。当视频编码采用H.264视频编码算法时,视频解码相应采用H.264视频解码算法。
可选地,在进行FEC视频解码处理后,删除所述第一链表缓存区中已进行FEC解码处理的流媒体数据包,以及,删除所述第二链表缓存区中已进行FEC解码处理的冗余数据包;以及,清空所述第三链表缓存区。这样可以释放接收端的缓存空间。可选地,第一链表缓存区、第二链表缓存区以及第三链表缓存区的大小相同,比如均为预设值与流媒体数据包大小的乘积的2倍。当然,第一链表缓存区、第二链表缓存区以及第三链表缓存区的大小也可以不同,这里不做限定。
可选地,在第一链表缓存区无可用空间的情况下,对第一链表缓存区中扩展包头的所属包组的序号最小的流媒体数据包进行视频解码,并删除第一链表缓存区中扩展包头的所属包组的序号最小的流媒体数据包,同时,删除第二链表缓存区中相应的冗余数据包,相应的冗余数据包为与第一链表缓存区删除的流媒体数据包属于同一包组的冗余数据包。
本申请实施例进行FEC解码处理时,可将FFmpeg多媒体编解码框架下的ffplay模块作为解码基础,具体可在ffplay模块下构建FEC解码组件,以实现本申请实施例中传输流媒体数据的步骤。
本申请实施例可应用于家居安防、车载监控、目标跟踪等对可靠性、实时性要求高的***。
本申请实施例还提供一种传输流媒体数据的***,包括:
接收端,用于接收发送端发送的第一包组的流媒体数据包和冗余数据包,所述冗余数据包为前向纠错FEC冗余编码后得到的冗余数据包;确定接收到的所述第一包组的流媒体数据包数以及冗余数据包数;将确定的所述第一包组的流媒体数据包数以及冗余数据包数反馈给所述发送端;
发送端,用于根据接收端反馈的第一包组的流媒体数据包数以及冗余数据包数,确定当前待发送的第二包组的编码冗余度;根据所述第二包组的编码冗余度,对所述第二包组的流媒体数据包进行FEC冗余编码,得到所述第二包组的冗余数据包;发送所述第二包组的流媒体数据包以及冗余数据包,其中,第一包组为与所述第二包组相邻的上一个已发送包组。
本申请实施例还提供一种传输流媒体数据的装置,应用于发送端,如图11所示,包括:
第一确定模块1101,用于根据接收端反馈的相邻上一个已发送的第一包组的流媒体数据包数以及冗余数据包数,确定当前待发送的第二包组的编码冗余度;
编码模块1102,用于根据所述第二包组的编码冗余度,对所述第二包组的流媒体数据包进行前向纠错FEC冗余编码,得到所述第二包组的冗余数据包;
发送模块1103,用于发送所述第二包组的流媒体数据包以及冗余数据包。
可选地,所述第一确定模块1101,具体用于:
将所述接收端反馈的所述第一包组的流媒体数据包数与冗余数据包数的和值作为第一和值;以及,
将保存的所述第一包组的流媒体数据包数与冗余数据包数的和值作为第二和值;
根据所述第一和值与所述第二和值,确定所述第一包组的丢包率;
确定所述第二包组的流媒体数据包数与所述第一包组的丢包率的乘积;
将所述乘积向上取整所得的结果作为所述第二包组的编码冗余度。
可选地,所述第一确定模块1101,具体用于:
确定所述第一和值与所述第二和值的差值;
将所述差值的绝对值除以所述第二和值的所得的结果,作为所述第一包组的丢包率。
可选地,本申请实施例提供的传输流媒体数据的装置,还包括:
第二确定模块1104,用于在所述编码模块对所述第二包组的流媒体数据包进行FEC冗余编码之前,确定存储的第二包组的流媒体数据包数等于预设值。
可选地,本申请实施例提供的传输流媒体数据的装置,还包括:
补零模块1105,用于在所述编码模块对所述第二包组的流媒体数据包进行FEC冗余编码之前,对所述第二包组中长度小于预设长度的流媒体数据包的长度进行补0操作,以使其长度等于预设长度。
可选地,所述流媒体数据包包括扩展包头,该扩展包头包括该流媒体数据包所属包组的序号、该流媒体数据包的有效数据长度、该流媒体数据包在所属包组内的序号以及该流媒体数据包的判别标识;所述冗余数据包包括扩展包头,该扩展包头包括该冗余数据包所属包组的序号、该冗余数据包的有效数据长度、该冗余数据包在所属包组内的序号以及该冗余数据包的判别标识。
本申请实施例还提供一种传输流媒体数据的装置,应用于接收端,如图12所示,包括:
接收模块1201,用于接收发送端发送的包组的流媒体数据包和冗余数据包,所述冗余数据包为前向纠错FEC冗余编码后得到的冗余数据包;
确定模块1202,用于确定接收到的所述包组的流媒体数据包数以及冗余数据包数;
反馈模块1203,用于将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端。
可选地,所述反馈模块1203,具体用于:
在实时控制协议RTCP的接收者报告RR包中添加第一扩展字段、第二扩展字段以及第三扩展字段;
将所述包组的序号写入所述第一扩展字段,将所述包组的流媒体数据包数写入所述第二扩展字段,以及,将所述包组的冗余数据包数写入所述第三扩展字段,得到写入RR包;
将所述写入RR包反馈给所述发送端。
可选地,所述流媒体数据包包括扩展包头,该扩展包头包括该流媒体数据包所属包组的序号以及该流媒体数据包的判别标识,所述冗余数据包包括扩展包头,该扩展包头包括该冗余数据包所属包组的序号以及该冗余数据包的判别标识,则所述接收模块1201,具体用于:
响应于数据包到达通知,根据该数据包的扩展包头中的判别标识,确定该数据包是流媒体数据包还是冗余数据包;
若该数据包为流媒体数据包,将该流媒体数据包存储至第一链表缓存区;
若该数据包为冗余数据包,将该冗余数据包存储至第二链表缓存区。
可选地,所述确定模块1202,具体用于:
确定所述第一链表缓存区中扩展包头包含所述包组的序号的流媒体数据包数,以及,
确定第二链表缓存区中扩展包头包含所述包组的序号的冗余数据包数。
可选地,所述反馈模块1203,具体用于:
若确定的所述包组的流媒体数据包数与冗余数据包数之和不小于预设值,或者,若所述第一链表缓存区无可用空间,则将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端。
可选地,所述流媒体数据包的扩展包头还包括该流媒体数据包的有效数据长度以及该流媒体数据包在所属包组内的序号,所述冗余数据包的扩展包头还包括该冗余数据包的有效数据长度以及该冗余数据包在所属包组内的序号,则本申请实施例提供的传输流媒体数据的装置,还包括:
存储模块1204,用于将所述第一链表缓存区存储的所述包组的流媒体数据包,以及,所述第二链表缓存区存储的所述包组的冗余数据包存储至第三链表缓存区;
去除模块1205,用于去除所述第三链表缓存区中的流媒体数据包和冗余数据包的扩展包头;
解码模块1206,用于根据第三链表缓存区中各个流媒体数据包的扩展包头以及冗余数据包的扩展包头,以及去除扩展包头后的流媒体数据包和冗余数据包,对所述包组进行FEC解码处理。
可选地,本申请实施例提供的传输流媒体数据的装置,还包括:
删除模块1207,删除所述第一链表缓存区中已进行FEC解码处理的流媒体数据包,以及,删除所述第二链表缓存区中已进行FEC解码处理的冗余数据包;以及,清空所述第三链表缓存区。
本申请实施例提供一种非易失性计算机存储介质,该计算机存储介质存储有可执行程序,该可执行程序被处理器执行实现上述实施例提供的任一应用于发送端的传输流媒体数据的方法的步骤。
本申请实施例还提供一种计算机设备,包括存储器、处理器及存储在存储器上的计算机程序,所述处理器执行所述程序时实现上述实施例提供的任一应用于发送端的传输流媒体数据的方法的步骤。
本申请实施例提供的计算机设备,用于执行上述实施例中的任一应用于发送端的传输流媒体数据的方法,如图13所示,为本申请实施中所述的计算机设备的硬件结构示意图,该计算机设备具体可以为台式计算机、便携式计算机、智能手机、平板电脑等。具体地,该计算机设备可以包括存储器1301、处理器1302及存储在存储器上的计算机程序,所述处理器执行所述程序时实现上述实施例中的任一应用于发送端的传输流媒体数据的方法的步骤。其中,存储器1301可以包括只读存储器(ROM)和随机存取存储器(RAM),并向处理器1302提供存储器1301中存储的程序指令和数据。
进一步地,本申请实施例中所述的计算机设备还可以包括输入装置1303以及输出装置1304等。输入装置1303可以包括键盘、鼠标、触摸屏等;输出装置1304可以包括显示设备,如液晶显示器(Liquid Crystal Display,LCD)、阴极射线管(Cathode Ray Tube,CRT),触摸屏等。存储器1301,处理器1302、输入装置1303和输出装置1304可以通过总线或者其他方式连接,图13中以通过总线连接为例。
处理器1302调用存储器1301存储的程序指令并按照获得的程序指令执行上述实施例提供的任一应用于发送端的传输流媒体数据的方法。
本申请实施例提供一种非易失性计算机存储介质,该计算机存储介质存储有可执行程序,该可执行程序被处理器执行实现上述实施例提供的任一应用于接收端的传输流媒体数据的方法的步骤。
本申请实施例还提供一种计算机设备,包括存储器、处理器及存储在存储器上的计算机程序,所述处理器执行所述程序时实现上述实施例提供的任一应用于接收端的传输流媒体数据的方法的步骤。
本申请实施例提供的计算机设备,用于执行上述实施例中的任一应用于接收端的传输流媒体数据的方法,如图14所示,为本申请实施中所述的计算机设备的硬件结构示意图,该计算机设备具体可以为台式计算机、便携式计算机、智能手机、平板电脑等。具体地,该计算机设备可以包括存储器1401、处理器1402及存储在存储器上的计算机程序,所述处理器执行所述程序时实现上述实施例中的任一应用于接收端的传输流媒体数据的方法的步骤。其中,存储器1401可以包括只读存储器(ROM)和随机存取存储器(RAM),并向处理器1402提供存储器1401中存储的程序指令和数据。
进一步地,本申请实施例中所述的计算机设备还可以包括输入装置1403以及输出装置1404等。输入装置1403可以包括键盘、鼠标、触摸屏等;输出装置1404可以包括显示设备,如液晶显示器(Liquid Crystal Display,LCD)、阴极射线管(Cathode Ray Tube,CRT),触摸屏等。存储器1401,处理器1402、输入装置1403和输出装置1404可以通过总线或者其他方式连接,图14中以通过总线连接为例。
处理器1402调用存储器1401存储的程序指令并按照获得的程序指令执行上述实施例提供的任一应用于接收端的传输流媒体数据的方法。
本申请实施例提供的传输流媒体数据的方法、装置、介质及设备,具有以下有益效果:根据接收端反馈的相邻上一个已发送的第一包组的流媒体数据包数和冗余数据包数,确定当前待发送的第二包组的编码冗余度,并对第二包组进行FEC冗余编码后,发送第二包组的流媒体数据包和冗余数据包,从而实现了动态调整当前待发送包组的编码冗余度,能够在尽量占用较少网络带宽的情况下,提供足以恢复丢失的流媒体数据包的编码冗余度,可避免由于流媒体数据包的丢失而造成的视频卡顿问题。
应当注意,尽管在上文详细描述中提及了传输流媒体数据的装置的若干模块,但是这种划分仅仅是示例性的并非强制性的。实际上,根据本申请的实施方式,上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之,上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。
本申请是参照根据本申请实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

Claims (15)

1.一种传输流媒体数据的方法,其特征在于,包括:
根据接收端反馈的相邻上一个已发送的第一包组的流媒体数据包数以及冗余数据包数,确定当前待发送的第二包组的编码冗余度;
根据所述第二包组的编码冗余度,对所述第二包组的流媒体数据包进行前向纠错FEC冗余编码,得到所述第二包组的冗余数据包;
发送所述第二包组的流媒体数据包以及冗余数据包。
2.根据权利要求1所述的方法,其特征在于,所述确定当前待发送的第二包组的编码冗余度,具体包括:
将所述接收端反馈的所述第一包组的流媒体数据包数与冗余数据包数的和值作为第一和值;以及,
将保存的所述第一包组的流媒体数据包数与冗余数据包数的和值作为第二和值;
根据所述第一和值与所述第二和值,确定所述第一包组的丢包率;
确定所述第二包组的流媒体数据包数与所述第一包组的丢包率的乘积;
将所述乘积向上取整所得的结果作为所述第二包组的编码冗余度。
3.根据权利要求2所述的方法,其特征在于,所述确定所述第一包组的丢包率,具体包括:
确定所述第一和值与所述第二和值的差值;
将所述差值的绝对值除以所述第二和值的所得的结果,作为所述第一包组的丢包率。
4.根据权利要求1所述的方法,其特征在于,对所述第二包组的流媒体数据包进行FEC冗余编码之前,还包括:
确定存储的第二包组的流媒体数据包数等于预设值。
5.根据权利要求1所述的方法,其特征在于,对所述第二包组的流媒体数据包进行FEC冗余编码之前,还包括:
对所述第二包组中长度小于预设长度的流媒体数据包的长度进行补0操作,以使其长度等于预设长度。
6.根据权利要求1-5任一所述的方法,其特征在于,所述流媒体数据包包括扩展包头,该扩展包头包括该流媒体数据包所属包组的序号、该流媒体数据包的有效数据长度、该流媒体数据包在所属包组内的序号以及该流媒体数据包的判别标识;所述冗余数据包包括扩展包头,该扩展包头包括该冗余数据包所属包组的序号、该冗余数据包的有效数据长度、该冗余数据包在所属包组内的序号以及该冗余数据包的判别标识。
7.一种传输流媒体数据的方法,其特征在于,包括:
接收发送端发送的包组的流媒体数据包和冗余数据包,所述冗余数据包为前向纠错FEC冗余编码后得到的冗余数据包;
确定接收到的所述包组的流媒体数据包数以及冗余数据包数;
将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端。
8.根据权利要求7所述的方法,其特征在于,所述将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端,具体包括:
在实时控制协议RTCP的接收者报告RR包中添加第一扩展字段、第二扩展字段以及第三扩展字段;
将所述包组的序号写入所述第一扩展字段,将所述包组的流媒体数据包数写入所述第二扩展字段,以及,将所述包组的冗余数据包数写入所述第三扩展字段,得到写入RR包;
将所述写入RR包反馈给所述发送端。
9.根据权利要求7所述的方法,其特征在于,所述流媒体数据包包括扩展包头,该扩展包头包括该流媒体数据包所属包组的序号以及该流媒体数据包的判别标识,所述冗余数据包包括扩展包头,该扩展包头包括该冗余数据包所属包组的序号以及该冗余数据包的判别标识,则所述接收发送端发送的包组的流媒体数据包以及冗余数据包,具体包括:
响应于数据包到达通知,根据该数据包的扩展包头中的判别标识,确定该数据包是流媒体数据包还是冗余数据包;
若该数据包为流媒体数据包,将该流媒体数据包存储至第一链表缓存区;
若该数据包为冗余数据包,将该冗余数据包存储至第二链表缓存区。
10.根据权利要求9所述的方法,其特征在于,所述确定接收到的所述包组的流媒体数据包数以及冗余数据包数,具体包括:
确定所述第一链表缓存区中扩展包头包含所述包组的序号的流媒体数据包数,以及,
确定第二链表缓存区中扩展包头包含所述包组的序号的冗余数据包数。
11.根据权利要求9所述的方法,其特征在于,所述将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端,具体包括:
若确定的所述包组的流媒体数据包数与冗余数据包数之和不小于预设值,或者,若所述第一链表缓存区无可用空间,则将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端。
12.根据权利要求9所述的方法,其特征在于,所述流媒体数据包的扩展包头还包括该流媒体数据包的有效数据长度以及该流媒体数据包在所属包组内的序号,所述冗余数据包的扩展包头还包括该冗余数据包的有效数据长度以及该冗余数据包在所属包组内的序号,则所述方法还包括:
将所述第一链表缓存区存储的所述包组的流媒体数据包,以及,所述第二链表缓存区存储的所述包组的冗余数据包存储至第三链表缓存区;
去除所述第三链表缓存区中的流媒体数据包和冗余数据包的扩展包头;
根据第三链表缓存区中各个流媒体数据包的扩展包头以及冗余数据包的扩展包头,以及去除扩展包头后的流媒体数据包和冗余数据包,对所述包组进行FEC解码处理。
13.一种传输流媒体数据的装置,其特征在于,包括:
第一确定模块,用于根据接收端反馈的相邻上一个已发送的第一包组的流媒体数据包数以及冗余数据包数,确定当前待发送的第二包组的编码冗余度;
编码模块,用于根据所述第二包组的编码冗余度,对所述第二包组的流媒体数据包进行前向纠错FEC冗余编码,得到所述第二包组的冗余数据包;
发送模块,用于发送所述第二包组的流媒体数据包以及冗余数据包。
14.一种传输流媒体数据的装置,其特征在于,包括:
接收模块,用于接收发送端发送的包组的流媒体数据包和冗余数据包,所述冗余数据包为前向纠错FEC冗余编码后得到的冗余数据包;
确定模块,用于确定接收到的所述包组的流媒体数据包数以及冗余数据包数;
反馈模块,用于将确定的所述包组的流媒体数据包数以及冗余数据包数反馈给所述发送端。
15.一种传输流媒体数据的***,其特征在于,包括:
接收端,用于接收发送端发送的第一包组的流媒体数据包和冗余数据包,所述冗余数据包为前向纠错FEC冗余编码后得到的冗余数据包;确定接收到的所述第一包组的流媒体数据包数以及冗余数据包数;将确定的所述第一包组的流媒体数据包数以及冗余数据包数反馈给所述发送端;
所述发送端,用于根据接收端反馈的第一包组的流媒体数据包数以及冗余数据包数,确定当前待发送的第二包组的编码冗余度;根据所述第二包组的编码冗余度,对所述第二包组的流媒体数据包进行前向纠错FEC冗余编码,得到所述第二包组的冗余数据包;发送所述第二包组的流媒体数据包以及冗余数据包,其中,第一包组为与所述第二包组相邻的上一个已发送包组。
CN201810078872.8A 2018-01-26 2018-01-26 一种传输流媒体数据的方法、装置、介质及设备 Active CN110087140B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810078872.8A CN110087140B (zh) 2018-01-26 2018-01-26 一种传输流媒体数据的方法、装置、介质及设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810078872.8A CN110087140B (zh) 2018-01-26 2018-01-26 一种传输流媒体数据的方法、装置、介质及设备

Publications (2)

Publication Number Publication Date
CN110087140A true CN110087140A (zh) 2019-08-02
CN110087140B CN110087140B (zh) 2022-07-05

Family

ID=67412679

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810078872.8A Active CN110087140B (zh) 2018-01-26 2018-01-26 一种传输流媒体数据的方法、装置、介质及设备

Country Status (1)

Country Link
CN (1) CN110087140B (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111464262A (zh) * 2020-03-18 2020-07-28 腾讯科技(深圳)有限公司 数据处理方法、装置、介质及电子设备
CN112087631A (zh) * 2020-08-10 2020-12-15 翟文国 基于gpu同步并行视频编解码与流媒体传输***及方法
CN112583524A (zh) * 2019-09-30 2021-03-30 杭州海康威视数字技术股份有限公司 数据包恢复方法及装置
CN112751644A (zh) * 2019-10-29 2021-05-04 腾讯科技(深圳)有限公司 数据传输方法、装置及***、电子设备
CN112820306A (zh) * 2020-02-20 2021-05-18 腾讯科技(深圳)有限公司 语音传输方法、***、装置、计算机可读存储介质和设备
CN116192341A (zh) * 2023-02-27 2023-05-30 东方空间技术(山东)有限公司 运载火箭遥测***pcm/fm码流传输方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6167060A (en) * 1997-08-08 2000-12-26 Clarent Corporation Dynamic forward error correction algorithm for internet telephone
CN102111232A (zh) * 2009-12-29 2011-06-29 华为技术有限公司 前向纠错方法和装置
CN106656422A (zh) * 2017-01-03 2017-05-10 珠海全志科技股份有限公司 一种动态调整fec冗余度的流媒体传输方法
CN107483144A (zh) * 2016-06-07 2017-12-15 中兴通讯股份有限公司 前向纠错反馈信息传输方法、装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6167060A (en) * 1997-08-08 2000-12-26 Clarent Corporation Dynamic forward error correction algorithm for internet telephone
CN102111232A (zh) * 2009-12-29 2011-06-29 华为技术有限公司 前向纠错方法和装置
CN107483144A (zh) * 2016-06-07 2017-12-15 中兴通讯股份有限公司 前向纠错反馈信息传输方法、装置
CN106656422A (zh) * 2017-01-03 2017-05-10 珠海全志科技股份有限公司 一种动态调整fec冗余度的流媒体传输方法

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112583524A (zh) * 2019-09-30 2021-03-30 杭州海康威视数字技术股份有限公司 数据包恢复方法及装置
CN112583524B (zh) * 2019-09-30 2022-08-05 杭州海康威视数字技术股份有限公司 数据包恢复方法及装置
CN112751644A (zh) * 2019-10-29 2021-05-04 腾讯科技(深圳)有限公司 数据传输方法、装置及***、电子设备
CN112751644B (zh) * 2019-10-29 2022-10-28 腾讯科技(深圳)有限公司 数据传输方法、装置及***、电子设备
CN112820306A (zh) * 2020-02-20 2021-05-18 腾讯科技(深圳)有限公司 语音传输方法、***、装置、计算机可读存储介质和设备
CN112820306B (zh) * 2020-02-20 2023-08-15 腾讯科技(深圳)有限公司 语音传输方法、***、装置、计算机可读存储介质和设备
CN111464262A (zh) * 2020-03-18 2020-07-28 腾讯科技(深圳)有限公司 数据处理方法、装置、介质及电子设备
CN112087631A (zh) * 2020-08-10 2020-12-15 翟文国 基于gpu同步并行视频编解码与流媒体传输***及方法
CN116192341A (zh) * 2023-02-27 2023-05-30 东方空间技术(山东)有限公司 运载火箭遥测***pcm/fm码流传输方法
CN116192341B (zh) * 2023-02-27 2024-04-26 东方空间技术(山东)有限公司 运载火箭遥测***pcm/fm码流传输方法

Also Published As

Publication number Publication date
CN110087140B (zh) 2022-07-05

Similar Documents

Publication Publication Date Title
CN110087140A (zh) 一种传输流媒体数据的方法、装置、介质及设备
CN102143367B (zh) 一种纠错校验方法、设备和***
EP2894831B1 (en) Transport mechanisms for dynamic rich media scenes
CN104836748B (zh) 拥塞控制比特率算法
CN102598617B (zh) 用于从移动设备向无线显示器传送内容的***和方法
KR102117445B1 (ko) 패킷 헤더 압축을 위한 방법 및 장치
US9386125B2 (en) Method for transmitting packet-based media data having header in which overhead is minimized
US20130202025A1 (en) Method and system for transmitting video frame data to reduce slice error rate
US20050123042A1 (en) Moving picture streaming file, method and system for moving picture streaming service of mobile communication terminal
MX2007012338A (es) Almacenamiento temporal en la distribucion de corriente de datos.
MX2010012117A (es) Manipulacion de canal rapida y proteccion de corriente de alta calidad sobre un canal de difusion.
TWI766883B (zh) 用於傳送視訊之方法及資料傳送器
CN108174234A (zh) 一种流媒体传输方法及***
CN101272495A (zh) 用于传输基于分组的图像帧的方法和装置
WO2019149053A1 (zh) 一种基于融合传输***的数据传输方法
CN110312147A (zh) 业务数据传输的方法、***与存储介质
CN104869461A (zh) 视频数据处理***及方法
US20060190593A1 (en) Signaling buffer parameters indicative of receiver buffer architecture
CN104253996B (zh) 视频数据的发送、接收方法及其装置以及传输***
CN108111531B (zh) 一种增强视频直播质量的方法及装置
CN103414956A (zh) 基于传输控制协议的实时数据传输方法及其***
US10250654B2 (en) Method and apparatus for transceiving data packet for transmitting and receiving multimedia data
CN104168439A (zh) 一种视频编码方法和装置
CN101814973B (zh) 一种基于amr音频帧的rtp快速聚包方法
US9936266B2 (en) Video encoding method and apparatus

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
GR01 Patent grant
GR01 Patent grant