CN101296184B - 一种数据传输的方法、***及装置 - Google Patents

一种数据传输的方法、***及装置 Download PDF

Info

Publication number
CN101296184B
CN101296184B CN2008101103226A CN200810110322A CN101296184B CN 101296184 B CN101296184 B CN 101296184B CN 2008101103226 A CN2008101103226 A CN 2008101103226A CN 200810110322 A CN200810110322 A CN 200810110322A CN 101296184 B CN101296184 B CN 101296184B
Authority
CN
China
Prior art keywords
data
packet
streaming media
media server
transmitting
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
CN2008101103226A
Other languages
English (en)
Other versions
CN101296184A (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.)
XFusion Digital Technologies Co Ltd
Original Assignee
Huawei Technologies 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN2008101103226A priority Critical patent/CN101296184B/zh
Publication of CN101296184A publication Critical patent/CN101296184A/zh
Priority to PCT/CN2009/071862 priority patent/WO2009143748A1/zh
Application granted granted Critical
Publication of CN101296184B publication Critical patent/CN101296184B/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
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/23805—Controlling the feeding rate to the network, e.g. by controlling the video pump
    • 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/6377—Control signals issued by the client directed to the server or network components directed to 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本发明公开了一种数据传输的方法、***及装置。该方法包括：流媒体服务器接收来自编码器的数据包并缓存；获取所述编码器预告的传输数据流量信息；根据所接收到的数据包大小、所述编码器的传输数据流量信息、输出信道的实时码率确定所述数据包的发送时间或/和调整数据发送速率，根据所确定的发送时间或/和发送速率发送数据。本发明还公开了相应的***和装置。根据本发明，可实现数据传输流量平滑，满足直播业务对实时数据传输的要求，达到良好的直播效果。

Description

一种数据传输的方法、***及装置
技术领域
本发明涉及多媒体广播及通信技术领域，具体涉及数据传输的方法、***及装置。
背景技术
随着流媒体、无线宽带、移动通信技术以及互联网技术融合发展，移动(手机)电视等新应用逐步形成热点，移动(手机)电视作为一场新媒介融合的变革，将带来巨大的商业机会和发展前景。
流媒体中有一种重要的业务，即直播业务Live TV，需要一台或多台编码器(Encoder)对流媒体数据进行实时压缩、编码得到直播数据，PSS从编码器接收直播数据，并实时将直播流推送到客户端。
鉴于直播数据的实时性要求，用户随时接入观看同一个频道时，所看到的节目应是一样的，也就是要求各个客户端几乎同时接收到同样的媒体数据。为了满足上述特性要求，现有技术中，PSS每接收到编码器的RTP包就给每个客户端拷贝一份发出去，这样PSS就相当于一个流量倍增器，有多少个并发用户几乎就要发送相应倍数的直播媒体数据，由于编码器输出的直播数据流是间断发送，一般每几十毫秒发送一帧数据(每帧数据可能有多个RTP数据包)，这样就会产生流量突变，对核心网设备如交换机/路由器/GGSN等的承载能力要求非常高，同时有其它数据业务存在的时候，造成数据丢包的概率非常大，因此，要求从PSS输出的数据流量能够平滑。
现有技术中的一种实现流量平滑的技术方案，具体如下：
每个直播频道采用预定的码率来压缩数据，此码率通常是该频道的平均码率，码率信息保存在SDP描述文件中，在编码器中每创建一个频道都会产生一个SDP文件。现有技术采用漏桶技术来实现数据流量平滑，即每次采用平均码率发送，其余的数据先缓存起来，即将“波峰”数据削减一部分，和“波谷”数据一起发送出去，但实际应用中，常常出现码率突变的情况，并会持续一段时间，
另外，随着并发用户数增加，也会导致数据流量不稳定。
发明内容
有鉴于此，本发明提供一种数据传输的方法、***及装置，可实现数据流量平滑传输。
本发明实施例提供的一种数据传输的方法，包括：
流媒体服务器接收来自编码器的数据包并缓存；
获取所述编码器预告的传输数据流量信息；
根据所接收到的数据包大小、所述编码器的传输数据流量信息、输出信道的实时码率确定所述数据包的发送时间或/和调整数据发送速率；
当所述编码器的输出数据的速率变化时，读取发包缓存区的缓存信息，包括：未发送的数据量NSF、未发送数据的最大希望发送时间点NMaxT，根据所缓存信息实时调整所述数据包的发送速率和/或时间。
该方法还包括：
根据所确定的发送时间或/和发送速率发送数据。
本发明实施例提供的一种实现数据传输的***，包括：流媒体服务器、编码器；
所述流媒体服务器接收来自所述编码器的数据包并缓存；
获取所述编码器预告的传输数据流量信息；
根据所接收到的数据包大小、输出信道的实时码率确定所述数据包的发送时间；
当所述编码器的输出数据的速率变化时，读取发包缓存区的缓存信息，包括：未发送的数据量NSF、未发送数据的最大希望发送时间点NMaxT，根据所缓存信息实时调整所述数据包的发送速率和/或时间；
所述流媒体服务器按照所确定的发送时间将数据包发送给所述客户端。
本发明实施例还提供一种实现数据传输的装置，包括：
接收单元，用于接收来自编码器的数据包及流量信息；
缓存单元，用于缓存所述接收单元接收的数据包；
数据流量控制单元，根据所接收到的数据包大小或/和输出信道的实时码率或/和流量信息控制所述数据包的发送时间或/和速率；当所述编码器的输出数据的速率变化时，读取发包缓存区的缓存信息，包括：未发送的数据量NSF、未发送数据的最大希望发送时间点NMaxT，根据所缓存信息实时调整所述数据包的发送速率和/或时间；
发送单元，在所述数据流量控制单元将所述缓存单元缓存的数据包发送给客户端。
存储单元，用于存储待编码的音、视频数据；
编码单元，用于对所述音、视频数据进行编码；
数据流量上报单元，根据所述存储单元保存的音、视频数据实时发送数据流量信息，所述数据流量信息包括：所述存储单元中所存储待编码的音、视频数据量，以及所述发送单元输出数据的速率；
发送单元，用于输出编码后的数据流。
本发明实施例提供的技术方案中，接收来自编码器的数据包并缓存；获取所述编码器预告的传输数据流量信息；根据所接收到的数据包大小、所述编码器的未来流量信息、输出信道的实时码率确定所述数据包的发送时间。根据本发明，可实现数据传输流量平滑，满足直播业务对实时数据传输的要求，达到良好的直播效果。
附图说明
图1为现有技术中的移动流媒体端对端组网示意图；
图2为现有技术中的RTP固定头字段构成示意图；
图3为现有技术中的RTP固定头扩展字段的构成示意图；
图4为本发明实施例中实现数据流平滑的原理示意图；
图5为本发明实施例中编码器输入到流媒体服务器的数据流量突变情况下的数据流量平滑处理示意图；
图6为本发明实施例中编码器输入到流媒体服务器的流量信息有偏差的情况下数据流量平滑处理示意图。
具体实施方式
参照图1，在移动(手机)电视电视***中，移动(手机)电视用户终端(UE)通过GGSN接入IP网络，机顶盒(STB)与PC通过各种接入手段，如ADSL直接接入到IP网中，分组域流媒体服务器(PSS，Packet-switched Streaming Server)一般处于核心网，为各种客户端提供流媒体业务。目前，流媒体一般使用RTSP/RTP/RTCP协议簇来控制、传输流媒体数据。RTSP(RFC 2326)用于建立和控制连续媒体的时间同步流，RTSP是标准的流媒体协议，并通常利用独立传输协议(如RTP)来传输媒体数据。RTP(RFC 1889、RFC 1890、RFC 3550)提供时间信息和实现A/V流同步。RTP不处理资源预定，并且不能保证实时服务的服务质量，而RTCP(RFC 3550)的主要功能是为数据的传送情况提供反馈。流媒体中有一种重要的业务，即直播业务Live TV，需要一台或多台编码器(Encoder)对流媒体数据进行实时压缩、编码得到直播数据，PSS从编码器接收直播数据，并实时将直播流推送到客户端。鉴于直播数据的实时性要求，用户随时接入观看同一个频道时，所看到的节目应是一样的，也就是要求各个客户端几乎同时接收到同样的媒体数据。本发明提供一种数据传输的方法、***及装置，可实现数据流量平滑传输。
为使本发明的原理、特性和优点更加清楚，下面对本发明进行详细描述。
流媒体直播Live TV业务***中包括处于核心网为各种客户端提供流媒体业务的流媒体服务器以及一台或多台编码器(Encoder)，所述编码器实时对采集的直播数据进行压缩、编码，然后发送给流媒体服务器，流媒体服务器从编码器接收直播数据并实时将直播数据流推送到客户端，从而实现直播服务。
由于编码器需要对动态音视频数据进行压缩、码率控制、以及重新编码等处理，因此，通常要缓冲一小段时间的数据，换而言之，编码器预先知道在未来一小段时间内将要输出的数据量。编码器通过将上述未来数据流量信息告知流媒体服务器，流媒体服务器就可较准确地知道编码器输出直播流的实时码率，每次发送数据时就可较准确计算出发送的数据的时间点和数据量。
流媒体服务器每接收到一个RTP数据包时，先将RTP数据缓存起来，然后根据此RTP数据包在内存中的指针，针对每个并发用户生成一条发包记录，放进发包缓冲区，每条发包记录的结构如下：RTP指针、希望发包时间点、用户信息、频道信息。计算出每条发包记录的希望发包时间点。采用高精度的定时器，定时启动发送数据的任务，根据预定规则从发包缓冲区取出满足条件的数据发送出去。接收来自编码器的数据包并缓存；获取所述编码器预告的传输数据流量信息；根据所接收到的数据包大小、输出信道的实时码率确定所述数据包的发送时间。当所述编码器的输出数据的速率变化时，根据所述编码器中缓存的数据量实时调整所述数据包的发送时间。
所有时间点都采用当前操作***的***时钟作为基准，以保证时间同步。
本发明实施例提供的技术方案中，流媒体服务器每次发送适当数量的数据，其余数据先缓存起来，等待后续波谷期间发送出去，本发明在实现流量平滑的同时，解决了由于各种误差累加导致的丢包、音视频不同步等问题。
本发明实施例提供的一种数据传输的方法，包括如下步骤：
S01，流媒体服务器接收来自编码器的数据包并缓存；
编码器实时对采集的直播数据进行压缩、编码，然后采用实时传输协议RTP将数据发送给流媒体服务器。流媒体服务器每接收到一个RTP数据包时，先把RTP数据缓存起来，然后根据此RTP数据包在内存中的指针，针对每个并发用户生成一条发包记录，放进发包缓冲区，每条发包记录包括RTP指针、希望发包时间点、用户信息、频道信息。
S02，获取所述编码器预告的传输数据流量信息；
本实施例中，编码器采用实时传输协议RTP传输数据给流媒体服务器，RTP协议是支持头扩展的，见图2的RTP协议头所示，把X位设置为1，头扩展的格式见图3。预告传输数据流量信息放在header extension字段中，前32位表示未来的时间段，单位为微秒，后24位表示未来时间段内的流量，单位为bit，最后8位表示对应的数据包的数量。
需要说明的是，编码器预告未来一段时间内的流量信息不一定采用RTP数据包的头扩展来传输，也可以采用RTCP数据包或者是RTSP协议来传输，或者特定的私有协议来传输，只是实时性以及实用性没有采用RTP头扩展好。
流媒体服务器收到RTP数据包后，解析RTP的头扩展字段，获取所述编码器的未来流量信息，可得知编码器未来多长时间内(FT，Future Time)将发送多少的数据量(FF，Future Flux)到流媒体服务器。
S03，根据所接收到的数据包大小、输出信道的实时码率确定所述数据包的发送时间。
流媒体服务器每次发完该发的数据后，记录最后一次发包的时间点，以此时间点作为开始时间点(ST，Start Time)，供后续发送数据包时参照。
流媒体服务器收到的RTP数据包大小为RtpSize，并发用户数为CUC(Current User Count)，发包周期为SC(Send Cycle)，上述所有时间点都折算为***时钟的精度。
直播频道的实时码率(Real Rate)为：RR＝FF/FT
每包RTP数据的理想的发送时长：RtpT＝RtpSize/RR
RtpT＝(RtpSize×FT)/FF
每RTP数据包最好在RtpT内发送给所有的并发用户。
需要考虑的情况是，编码器只告知PSS在FT时间内发送大小为FF的数据量，计算实时码率时取的是平均值，考虑到实际应用中，FF的数据量可能不是均匀地在FT时间段内发送出来，可能集中在某个时间点内发送出来，流媒体服务器需要自适应此种变化，即需要把缓冲区未发送的数据也考虑进来。当所述编码器的输出数据的速率变化时，需要读取发包缓存区的缓存信息，包括：未发送的数据量(NSF)、未发送数据的最大希望发送时间点(NMaxT)，根据所缓存信息实时调整所述数据包的发送速率和/或时间。
通常，客户端分别设置一个视频缓存区与音频缓存区，一般情况下，音频数据码率一般比较稳定，音频的缓存区要求比较小，假设客户端最少的缓冲时间为MinBT(Min Buffer Time)，但考虑特殊情况，MinBT不特指音频的最小缓冲时间，而是取视频缓冲与音频缓冲时间中较小的。为了实现音视频同步以及音视频流都能正常播放，所缓存数据包必须要求在最小缓冲时间MinBT内发送给客户端。
每个RTP数据包都要转发给CUC个并发用户，某RTPi数据包给第n个用户的希望发送时间点(EST，Expect Send Time)的计算方法如下：
情况Ⅰ：在编码器以恒定速率发送数据的前提下，如果计算的发送时长小于客户端的最小缓冲时间，即RtpT＜＝MinBT，并且之前收到RTP包计算出来的希望发送时间点比当前包计算出来的希望发送最大时间点还要靠后，即(NMaxT-ST)＜RtpT，则通过下式计算期望的发送码率(ESR，Expect Send Rate)：
ESR＝(RtpSize×CUC+NSF)/RtpT
(1)如果之前计算的发送码率偏低，即ESR1＞NSF/(NMaxT-ST)，那么NMaxT时间点之前需要新增加发送数据量为ESR(NMaxT-ST)-NSF，折算为RTP数据包数为：
M＝(ESR1(NMaxT-ST)-NSF)/RtpSize
即n＜＝M时，EST计算公式如下：
ESTn＝ST+n×(NMaxT-ST)/M
由上述两式得到：
ESTn＝ST+(n×RtpSize)/(ESR1-NSF/(NMaxT-ST))
n＞m时，即所计算得到的时间点都是在NMaxT之后，剩下的数据都是以ESR发送的，剩下的数据量为(n-M)×RtpSize，因此，EST计算公式如下：
ESTn＝NMaxT+(n-M)×RtpSize/ESR
(2)如果之前计算的发送码率偏高，即ESR1＞NSF/(NMaxT-ST)，考虑性能以及稳定性，进入发送缓冲区就不再作调整速率和发送时间，即新数据在NMaxT到(ST+RtpT)之间发送完毕，因此，EST的计算公式如下：
ESTn＝NMaxT+n×(ST+RtpT-NMaxT)/CUC
情况(Ⅱ)：当计算得到所接收数据包发送时长RtpT不小于客户端的最小缓冲时间MinBT，即RtpT＜＝MinBT，且所述流媒体服务器当前数据包计算确定的发送最大时间点在之前收到数据包计算确定的发送时间点之后，即(NMaxT-ST)＞＝RtpT，则在RtpT内实际要发送的数据量RSF(Real Send Flux)为：
RSF＝CUC×RtpSize+(NSF×RtpT)/NMaxT-ST
期望的发送码率为：RSF/RtpT，因此，EST的计算公式如下：
ESTn＝ST+n×RtpSize×RtpT/RSF
情况(Ⅲ)：当计算得到所接收数据包发送时长RtpT大于客户端的最小缓冲时间MinBT，即RtpT＞MinBT，且所述流媒体服务器之前收到数据包计算确定的发送时间点在当前数据包计算确定的发送最大时间点之后，即(NMaxT-ST)＜RtpT，则需要对所述流媒体服务器发送数据的速率进行调整，此时计算计算期望的发送码率ESR以及希望发送时间点EST的方式与情况(Ⅰ)类同，用MinBT替换RtpT来计算即可，期望的数据发送速率为：
ESR＝(RtpSize×CUC+NSF)/MinBT
RtpSize为所述流媒体服务器每次收到的数据包大小，CUC为并发用户数，NSF为所述流媒体服务器中缓存数据量。
情况(Ⅳ)：当计算得到所接收数据包发送时长RtpT大于客户端的最小缓冲时间MinBT，即RtpT＞MinBT，且所述流媒体服务器之前数据包计算确定的发送最大时间点在当前收到数据包计算确定的发送时间点之后，即(NMaxT-ST)＞＝RtpT，则此时计算计算期望的发送码率ESR以及希望发送时间点EST的方式与情况(Ⅱ)类同，用MinBT替换RtpT来计算即可，在RtpT内要发送的数据量RSF为：
RSF＝CUC×RtpSize+(NSF×MinBT)/NMaxT-ST。
编码器输入数据到PSS的速率不恒定的异常情况
如图5所示，图5的上曲线图中每隔一条虚竖线表示编码器的缓冲时间，即上述FT值，每条竖实线表示发送的数据包，每条竖实线等高表示数据包大小相等，这是为了描述方便，实际应用中，发送的数据包大小不一样的，但可以理解为分解成几个数据包同时发送，如上曲线图中前4条竖实线。图5的下曲线图的每条虚横线的间隔表示发送周期，图中的发送周期为50个单位时间，灰色框内的数字表示每单位时间的流量。
PSS接收到第1个数据包时，由于编码器此时只知1000单位时间内有5000个单位流量的数据量要发送，因此编码器把这一信息传给PSS。从图中可知，前4个数据包发送时间间隔很密，表示有流量突变，按理说，此时刻的码率很多，但PSS也只能计算了一个平均值作为实时的码率，即5000/1000＝5，即每单位时间发送5单位流量的数据量。本段文字就是要说明PSS如何自适应的应付此变化。
PSS接收到第2个数据包时，这做了一种较坏情况的假设，即已经发送有误差的码率发送了n个周期，为了方便说明，图中只假设按有误差的码率发送了1个周期，编码器此时因为没有新数据流入，因此传给PSS的信息是未来1000单位时间内发送4000单位流量的数据，因此，PSS根据新老数据，计算出来的实时码率为7，计算方式如下：
RtpT＝缓存周期×数据包大小/未来时间段内总流量
＝(1000/4000)×1000＝250
已发送数据＝发送周期×上次实时码率＝50×5＝250
剩余数据量＝新接收到+未发送出去的
＝1000+1000-250＝1750
当前的实时码率为＝1750/250＝7
后面如此类推，从图中可知，尽管由于输入的流量突变引起PSS输出流量波动，但PSS实时自适应的做了调整，误差不会不断积累，同时也使得波峰平滑了。
编码器计算的流量信息有偏差的情况
图6为本发明实施例中编码器输入到流媒体服务器的流量信息有偏差的情况下数据流量平滑处理示意图。
假设编码器由于异常原因没有统计到某个数据包，如第4数据包，见图6中虚竖线。
参照图6，PSS接收到第1个数据包时，编码器输入的流量信息是未来1000单位时间内有4000个单位流量的数据量要发送，PSS的第一个发送周期的实时码率就为4，如此类推，收到2个数据包的实时码率为3，收到第3个数据包的实时码率为2。
收到第4个数据包，编码器得到更正，给PSS输入的流量信息为未来1000单位时间内有2000个单位流量的数据量要发送，此时PSS及时进行自适应调整，因此，也不会累积误差。
本发明实施例还提供一种数据传输的***，包括：流媒体服务器、编码器；
编码器，包括：存储单元，用于存储待编码的音、视频数据；编码单元，用于对所述音、视频数据进行编码；数据流量上报单元，根据所述存储单元保存的音、视频数据实时发送数据流量信息，所述数据流量信息包括：所述存储单元中所存储待编码的音、视频数据量，以及所述发送单元输出数据的速率；发送单元，用于输出编码后的数据流。
所述流媒体服务器接收来自所述编码器的数据包并缓存；
具体包括：每接收到一个数据包时，将所述数据包缓存，然后根据每个并发用户生成一条发包记录，存入发包缓冲区，每条发包记录包括：RTP指针、希望发包时间点、用户信息、频道信息。
获取所述编码器预告的传输数据流量信息；
根据所接收到的数据包大小、输出信道的实时码率确定所述数据包的发送时间；
当所述编码器输出数据给所述流媒体服务器的速率变化时，根据所述编码器中缓存的数据量实时调整所述数据包的发送时间；
所述流媒体服务器按照所确定的发送时间将数据包发送给所述客户端。
所述编码器通过扩展所述数据包头携带传输数据流量信息以发送给所述流媒体服务器。
所述流媒体服务器根据计算得到所接收数据包发送时长RtpT、客户端的最小缓冲时间MinBT，数据包计算确定的发送时间点，实时对发送数据的速率进行调整。
本发明实施例还提供一种编码装置，包括：
存储单元，用于存储待编码的音、视频数据；
编码单元，用于对所述音、视频数据进行编码；
数据流量上报单元，根据所述存储单元保存的音、视频数据实时发送数据流量信息，所述数据流量信息包括：所述存储单元中所存储待编码的音、视频数据量，以及所述发送单元输出数据的速率；
发送单元，用于输出编码后的数据流。
本发明实施例还提供一种实现数据传输的装置，包括：
接收单元，用于接收来自编码器的数据包及后续流量信息；
缓存单元，用于缓存所述接收单元接收的数据包；
数据流量控制单元，根据所接收到的数据包大小、输出信道的实时码率以及后续流量信息控制所述数据包的发送时间；
发送单元，按照所确定的发送时间将所述缓存单元缓存的数据包发送给客户端。
发送单元启用一个精确的定时器来定时触发发包任务，一般而言，精度(即最小周期)设置得越小对流量平滑的效果越好，因此，需要设置一个适当值(如，2毫秒)，并可以根据实际平滑规格作调整。
所述装置还包括：控制单元，用于控制所述发送单元的发包线程，在希望发包时间之前，启动发包线程，确保当前启动时间点先于发包记录的希望发包时间点。
发包线程启动后，从发包缓冲区中读出要发送的数据包发送出去，因为发包记录已经包含要发送客户端的网络信息，按发包记录的信息直接发送。更适宜地，采用过滤条件：当前唤醒启动时间点先于发包记录的希望发包时间点，这样就可以消除了定时器的误差积累，每次定时误差都实时处理掉了，而不会等到一定积累后再处理。发包线程实际上就是一个高精度的定时器，定时被唤醒，执行一次发送任务后就sleep，等待下一次被唤醒。当前唤醒启动时间点是指发包线程被唤起的时刻，由于放到发送缓冲区的数据是超前预测的，或者说期望的发送时间可能比发包线程的当前唤醒启动时间还要靠后，考虑定时器可能也会有误差，采用上述过滤条件，可以实时消除误差积累。
综上所述，本发明实施例提供的技术方案中，接收来自编码器的数据包并缓存；获取所述编码器预告的传输数据流量信息；根据所接收到的数据包大小、所述编码器的未来流量信息、输出信道的实时码率确定所述数据包的发送时间。当所述编码器的输出数据的速率变化时，根据所述编码器中缓存的数据量实时调整所述数据包的发送时间。根据本发明，可在实现数据流量平滑的同时，解决了由于各种误差累加导致的丢包、音视频不同步等问题，满足直播业务对实时数据传输的要求，达到良好的直播效果。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (18)

1.一种数据传输的方法，其特征在于，包括：
流媒体服务器接收来自编码器的数据包并缓存；
获取所述编码器预告的传输数据流量信息；
根据所接收到的数据包大小、所述编码器预告的传输数据流量信息、输出信道的实时码率确定所述数据包的发送时间和/或数据发送速率；
当所述编码器的输出数据的速率变化时，流媒体服务器读取发包缓存区的缓存信息，所述缓存信息包括：未发送的数据量NSF、未发送数据的最大希望发送时间点NMaxT，根据所述缓存信息实时调整所述数据包的发送速率和/或时间；
当所述编码器的输出数据的速率变化时，根据调整后的发送时间和/或发送速率发送所述数据包；否则，根据所述确定的发送时间和/或发送速率发送所述数据包。
2.如权利要求1所述的方法，其特征在于，所述获取传输数据流量信息是通过下述方式实现的：
通过所述数据包的包头携带所述传输数据流量信息发送给所述流媒体服务器；或，
根据编码器中缓存数据包的数据量实时发送所述传输数据流量信息给所述流媒体服务器。
3.如权利要求1所述的方法，其特征在于，还包括：
当在编码器以恒定速率发送数据的前提下计算得到的所接收数据包发送时长RtpT小于客户端的最小缓冲时间MinBT，且流媒体服务器根据之前收到的数据包计算确定的发送时间点在根据当前数据包计算确定的最大希望发送时间点之后，即(NMaxT-ST)＜RtpT，其中，ST为上一次发送数据包的时间点，则根据所述流媒体服务器每次收到的数据包大小、并发用户数、所述流媒体服务器中缓存的未发送的数据量NSF以及所述流媒体服务器发送各数据包的理想时长对所述流媒体服务器发送数据的速率进行调整。
4.如权利要求3所述的方法，其特征在于，还包括：
若调整后的数据发送速率ESR大于之前计算确定的数据发送速率，则在所述未发送数据的最大希望发送时间点NMaxT之前需要增加发送数据量。
5.如权利要求3所述的方法，其特征在于，还包括：
若调整后的数据发送速率ESR小于之前计算确定的数据发送速率，则根据所述流媒体服务器发送各数据包的理想时长、并发用户数、所述未发送数据的最大希望发送时间点NMaxT调整所述流媒体服务器中数据的希望发送时间点。
6.如权利要求1所述的方法，其特征在于，还包括：
当计算得到所接收数据包发送时长RtpT大于客户端的最小缓冲时间MinBT，且流媒体服务器根据之前收到的数据包计算确定的发送时间点在根据当前数据包计算确定的最大希望发送时间点之后，即(NMaxT-ST)＜RtpT，其中，ST为上一次发送数据包的时间点，则根据所述流媒体服务器每次收到的数据包大小、并发用户数、所述流媒体服务器中缓存的未发送的数据量NSF以及最小缓冲时间MinBT对所述流媒体服务器发送数据的速率进行调整。
7.如权利要求6所述的方法，其特征在于，还包括：
若调整后的数据发送速率ESR大于之前计算确定的数据发送速率NSF/(NMaxT-ST)，则在所述未发送数据的最大希望发送时间点NMaxT之前至少增加发送数据量：
ESR×(NMaxT-ST)-NSF
其中，ST为上一次发送数据包的时间点，NSF为未发送的数据量。
8.如权利要求6所述的方法，其特征在于，还包括：
若调整后的数据发送速率ESR小于之前计算确定的数据发送速率NSF/(NMaxT-ST)，则调整所述流媒体服务器中数据的希望发送时间点。
9.如权利要求1所述的方法，其特征在于，还包括：
当计算得到所接收数据包发送时长RtpT不大于客户端的最小缓冲时间MinBT，且流媒体服务器根据当前数据包计算确定的最大希望发送时间点在根据之前收到的数据包计算确定的发送时间点之后，即(NMaxT-ST)＞＝RtpT，则在RtpT内至少要发送的数据量RSF为：
RSF＝CUC×RtpSize+(NSF×RtpT)/(NMaxT-ST)；
其中，CUC为并发用户数；RtpSize为RTP数据包大小；NSF为未发送的数据量；NMaxT为未发送数据的最大希望发送时间点；ST为上一次发送数据包的时间点。
10.如权利要求9所述的方法，其特征在于，期望的发送码率为：RSF/RtpT，按照下式计算确定所述流媒体服务器对第n个用户的数据希望发送时间点：
ESTn＝ST+n×RtpSize×RtpT/RSF。
11.如权利要求1所述的方法，其特征在于，还包括：
当计算得到所接收数据包发送时长RtpT大于客户端的最小缓冲时间MinBT，且流媒体服务器根据当前数据包计算确定的最大希望发送时间点在之前收到数据包计算确定的发送时间点之后，即(NMaxT-ST)＞＝RtpT，则在RtpT内要发送的数据量RSF为：
RSF＝CUC×RtpSize+(NSF×MinBT)/(NMaxT-ST)；
其中，CUC为并发用户数；RtpSize为RTP数据包大小；NSF为未发送的数据量；NMaxT为未发送数据的最大希望发送时间点；ST为上一次发送数据包的时间点。
12.如权利要求11所述的方法，其特征在于，期望的发送码率为：RSF/RtpT，按照下式计算确定所述流媒体服务器对第n个用户的数据希望发送时间点：
ESTn＝ST+n×RtpSize×MinBT/RSF。
13.一种数据传输***，包括：流媒体服务器和客户端，其特征在于，
所述流媒体服务器包括：
接收单元，接收来自编码器的数据包及后续数据流量信息；
缓存单元，用于缓存所述接收单元接收的数据包；
数据流量控制单元，根据所接收到的数据包大小或/和输出信道的实时码率或/和后续数据流量信息确定所述数据包的发送时间或/和速率；当所述编码器的输出数据的速率变化时，读取发包缓存区的缓存信息，所述缓存信息包括：未发送的数据量NSF、未发送数据的最大希望发送时间点NMaxT，根据所述缓存信息实时调整所述数据包的发送速率和/或时间；
发送单元，当所述编码器的输出数据的速率变化时，按照调整后的发送时间和/或发送速率，否则，按照所述确定的发送时间和/或发送速率将数据包发送给所述客户端。
14.如权利要求13所述的***，其特征在于，还包括编码器，
所述编码器用于进行数据编码，并将编码后得到的数据包及传输数据流量信息提供给所述流媒体服务器；通过扩展所述数据包的包头携带传输数据流量信息发送给所述流媒体服务器；或，
根据所缓存数据包的数据量实时发送所述传输数据流量信息给所述流媒体服务器。
15.如权利要求13所述的***，其特征在于，所述流媒体服务器接收来自所述编码器的数据包并缓存，具体包括：
每接收到一个数据包时，将所述数据包缓存，然后根据每个并发用户生成一条发包记录，存入发包缓冲区，每条发包记录包括：RTP指针、用户信息、频道信息。
16.一种实现数据传输的装置，其特征在于，包括：
接收单元，用于接收来自编码器的数据包及后续数据流量信息；
缓存单元，用于缓存所述接收单元接收的数据包；
数据流量控制单元，根据所接收到的数据包大小或/和输出信道的实时码率或/和后续数据流量信息确定所述数据包的发送时间或/和速率；当所述编码器的输出数据的速率变化时，读取发包缓存区的缓存信息，所述缓存信息包括：未发送的数据量NSF、未发送数据的最大希望发送时间点NMaxT，根据所述缓存信息实时调整所述数据包的发送速率和/或时间；
发送单元，当所述编码器的输出数据的速率变化时，按照调整后的发送时间和/或发送速率，否则，按照所述确定的发送时间和/或发送速率将所述缓存单元缓存的数据包发送给客户端。
17.如权利要求16所述的装置，其特征在于，还包括：
控制单元，用于控制所述发送单元的发包线程，在希望发包时间之前，启动发包线程。
18.一种编码装置，其特征在于，包括：
存储单元，用于存储待编码的音、视频数据；
编码单元，用于对所述音、视频数据进行编码；
发送单元，用于输出编码后的数据流；
数据流量上报单元，根据所述存储单元保存的音、视频数据实时发送数据流量信息给流媒体服务器，所述数据流量信息包括：存储单元中所存储的待编码的音、视频数据量，以及所述发送单元输出数据的速率。
CN2008101103226A 2008-05-30 2008-05-30 一种数据传输的方法、***及装置 Active CN101296184B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN2008101103226A CN101296184B (zh) 2008-05-30 2008-05-30 一种数据传输的方法、***及装置
PCT/CN2009/071862 WO2009143748A1 (zh) 2008-05-30 2009-05-20 一种数据传输的方法、***及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN2008101103226A CN101296184B (zh) 2008-05-30 2008-05-30 一种数据传输的方法、***及装置

Publications (2)

Publication Number Publication Date
CN101296184A CN101296184A (zh) 2008-10-29
CN101296184B true CN101296184B (zh) 2011-04-13

Family

ID=40066203

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2008101103226A Active CN101296184B (zh) 2008-05-30 2008-05-30 一种数据传输的方法、***及装置

Country Status (2)

Country Link
CN (1) CN101296184B (zh)
WO (1) WO2009143748A1 (zh)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101296184B (zh) * 2008-05-30 2011-04-13 华为技术有限公司 一种数据传输的方法、***及装置
CN101459852B (zh) * 2008-12-22 2011-04-13 华为技术有限公司 预测视频业务发生时延的方法和装置
CN101567853B (zh) * 2009-05-13 2011-08-10 中兴通讯股份有限公司 音频媒体发包控制装置、方法及音频媒体服务器
CN101808239A (zh) * 2010-03-01 2010-08-18 北京东方广视科技股份有限公司 一种控制ts流播出的方法和装置
CN102098681B (zh) * 2010-12-13 2013-08-07 北京航空航天大学 自适应中继选择的协作数据传输方法和***
CN102118602B (zh) * 2011-03-15 2013-08-21 深圳市捷视飞通科技有限公司 一种在多画面中显示辅流视频的方法及***
CN103167320B (zh) * 2011-12-15 2016-05-25 中国电信股份有限公司 音视频同步方法、***及手机直播客户端
CN102497445B (zh) * 2011-12-23 2015-06-24 广东威创视讯科技股份有限公司 数据传输方法和装置
CN102984078A (zh) * 2012-12-06 2013-03-20 苏州阔地网络科技有限公司 一种网页上实现流量控制的方法及***
CN103095519A (zh) * 2012-12-07 2013-05-08 大连奥林匹克电子城咨信商行 一种对通讯窗口传出数据进行监控的网络流量监控方法
CN104301744B (zh) * 2013-07-15 2018-05-11 广州市千钧网络科技有限公司 用于直播的流压缩方法和装置
CN103491382B (zh) * 2013-09-16 2016-09-14 天脉聚源(北京)传媒科技有限公司 一种流媒体的播放处理方法及装置
CN105338422B (zh) * 2014-06-09 2018-11-13 杭州海康威视数字技术股份有限公司 视频图像数据的网络发送速率的平滑方法
EP3151490B1 (en) * 2014-07-01 2018-10-17 Huawei Technologies Co. Ltd. Data transmission control method, passive optical network equipment and device, and passive optical network
CN104780401B (zh) * 2015-03-25 2017-12-22 腾讯科技（深圳）有限公司 视频数据的发送方法及装置
CN105554517B (zh) * 2015-12-03 2018-09-28 浙江大华技术股份有限公司 一种视频流发送方法及装置
CN106412664B (zh) * 2016-10-08 2019-08-13 Oppo广东移动通信有限公司 多媒体同步播放方法、装置、终端及***
CN106534884B (zh) * 2016-11-10 2019-03-15 中广热点云科技有限公司 一种视频编码中码率控制方法及***
CN107026856A (zh) * 2017-03-30 2017-08-08 上海七牛信息技术有限公司 一种网络推流质量的优化方法及优化***
CN107071567A (zh) * 2017-05-18 2017-08-18 深圳算云微豆投资中心（有限合伙） 一种多媒体数据传输过程的监控方法及***
CN109218847B (zh) * 2017-06-30 2022-03-04 中兴通讯股份有限公司 一种下载控制方法、装置以及多媒体终端
CN108737807B (zh) * 2018-05-10 2020-05-26 Oppo广东移动通信有限公司 一种数据处理方法、终端、服务器和计算机存储介质
CN110597643B (zh) * 2019-08-30 2022-08-12 Oppo广东移动通信有限公司 核间通信方法、处理器以及电子设备
CN111263206B (zh) * 2020-02-13 2022-06-10 Tcl移动通信科技（宁波）有限公司 多媒体信息的同步播放方法、装置、存储介质及移动终端
CN112637614B (zh) * 2020-11-27 2023-04-21 深圳市创成微电子有限公司 网络直播音视频处理方法、处理器、装置及可读存储介质
CN115378795B (zh) * 2022-08-19 2024-02-13 度小满科技(北京)有限公司 服务器网络质量监控方法、装置和电子设备及存储介质
CN115859394B (zh) * 2022-12-15 2023-11-21 深圳市数存科技有限公司 一种基于边缘计算的数据安全存储***及方法
CN115842789B (zh) * 2023-02-23 2023-05-09 鹏城实验室 数据包调度方法、设备及可读存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1472959A (zh) * 2002-07-30 2004-02-04 华为技术有限公司 实现多种视音频流格式转换的装置和方法
CN1655547A (zh) * 2004-09-09 2005-08-17 上海川海信息科技有限公司 一种流媒体传输***中的速率控制方法
CN1885828A (zh) * 2006-06-20 2006-12-27 ***通信集团公司 移动流媒体的计时方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004072765A2 (en) * 2003-02-13 2004-08-26 Nokia Corporation Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming
CN100469072C (zh) * 2005-09-29 2009-03-11 西安交通大学 多源流媒体传输QoS控制方法
CN101296184B (zh) * 2008-05-30 2011-04-13 华为技术有限公司 一种数据传输的方法、***及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1472959A (zh) * 2002-07-30 2004-02-04 华为技术有限公司 实现多种视音频流格式转换的装置和方法
CN1655547A (zh) * 2004-09-09 2005-08-17 上海川海信息科技有限公司 一种流媒体传输***中的速率控制方法
CN1885828A (zh) * 2006-06-20 2006-12-27 ***通信集团公司 移动流媒体的计时方法

Also Published As

Publication number Publication date
CN101296184A (zh) 2008-10-29
WO2009143748A1 (zh) 2009-12-03

Similar Documents

Publication Publication Date Title
CN101296184B (zh) 一种数据传输的方法、***及装置
US10547659B2 (en) Signaling and processing content with variable bitrates for adaptive streaming
CN101242359B (zh) 动态码率分配方法、分组域流媒体服务器
CN101917613B (zh) 一种流媒体采集编码服务***
US7979570B2 (en) Live media delivery over a packet-based computer network
CN102333089A (zh) 基于超文本传输协议流化的多码率媒体流自适应控制方法
CN102449977A (zh) 用于通过分组网络对媒体进行流传送的自适应比特率管理
CN101889425B (zh) 通过可变带宽信道进行同播的设备和方法
KR20160106618A (ko) 콘텐츠 전달
US20090168679A1 (en) Method and Device for Providing Programs to Multiple End User Devices
CN101305612A (zh) 用于对等订户小区的多源和弹性按需点播视频流媒体***
JP2004015111A (ja) データ配信システム
CN102130886B (zh) 网络视频流媒体***及传输处理方法、发送端
US20140317668A1 (en) Carriage Of Quality Information Of Content In Media Formats
CN103828324A (zh) 用于分组网络上的流媒体的按需自适应比特率管理
EP3016396B1 (en) Content supply device, content supply method, program, terminal device, and content supply system for providing zapping segments using mpeg-dash streaming
CN105306969A (zh) 一种流媒体自适应处理***及方法
CN115943631A (zh) 流式传输包括具有切换集的可寻址资源索引轨道的媒体数据
US20220295127A1 (en) Consolidating content streams to conserve bandwidth
WO2009103351A1 (en) Method and apparatus for obtaining media over a communications network
CN101822048A (zh) 用于流式接收音频和/或视频数据分组的设备
Potetsianakis et al. Buffer management for synchronous and low-latency playback of multi-stream user-generated content
US20230247205A1 (en) Bandwidth management using dynamic quality factor adjustments
Poon et al. Interactive broadcasting system for VBR encoded videos
Lee Staggered push-a linearly scalable architecture for push-based parallel video servers

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20211221

Address after: 450046 Floor 9, building 1, Zhengshang Boya Plaza, Longzihu wisdom Island, Zhengdong New Area, Zhengzhou City, Henan Province

Patentee after: Super fusion Digital Technology Co.,Ltd.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd.

TR01 Transfer of patent right