CN1885828A

CN1885828A - 移动流媒体的计时方法

Info

Publication number: CN1885828A
Application number: CNA2006100865280A
Authority: CN
Inventors: 朱春梅; 张炎; 武威
Original assignee: China Mobile Communications Group Co Ltd
Current assignee: China Mobile Communications Group Co Ltd
Priority date: 2006-06-20
Filing date: 2006-06-20
Publication date: 2006-12-27
Anticipated expiration: 2026-06-20
Also published as: CN100456743C

Abstract

本发明涉及一种移动流媒体的计时方法，包括：移动终端每接收到一个RTP数据包，就向流媒体服务器反馈一个接收方报告；流媒体服务器根据接收方报告计算流媒体的播放时间长度。流媒体服务器根据接收方报告计算移动终端接收到的RTP数据包数目，并根据移动终端接收到的RTP数据包数目、RTP数据包实际负荷尺寸及流媒体编码速率计算流媒体的播放时间长度。若流媒体的编码速率和/或封包格式可变，在计算RTP数据包数目时，针对不同的编码速率和/或封包格式分别计数。本发明实现了流媒体播放的准确计时，能有效避免将由网络传输时延等问题引起的播放中断时间计入实际播放时间，由此得到的播放时长是移动终端实际接收到的流媒体数据的播放时长。

Description

移动流媒体的计时方法

技术领域

本发明涉及移动流媒体技术，尤其涉及对移动流媒体的播放进行计时的方法。

背景技术

流媒体是指把连续的影像和声音信息经过压缩处理后放到网络服务器上，使移动终端可以边下载边播放。流媒体技术是网络音视频技术和移动通信技术发展到一定阶段的产物，它融合了多种网络技术，涉及到流媒体数据的采集、压缩、存储以及网络通信等。

终端播放器实时从流媒体服务器上获取流媒体数据，边下载边播放，流媒体内容不在终端设备上存储。如果同一内容需要多次重复播放，需要每次播放时从流媒体服务器上重新下载数据。

根据流媒体内容的来源，流媒体业务可分为点播和直播两种：流媒体点播是内容提供者预先对一段多媒体内容进行编辑、压缩编码，形成指定格式的文件，然后存储到流媒体服务器上，用户根据需要选择流媒体服务器上的内容文件进行播放。流媒体直播是指终端播放器播放流媒体直播内容时，内容的播放时刻与内容源事件的发生时刻相同，即流媒体编码服务器对内容源进行实时地压缩编码，经由流媒体服务器发送到用户终端。

实时传输协议(Real-time Transport Protocol，简称RTP)是用于Internet上针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP通常使用用户报文协议(User Datagram Protocal，简称UDP)来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给实时传输控制协议(Real-timeTransport Control Protocol，简称RTCP)。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。

RTCP和RTP一起提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。

RTP包头有以下格式：

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V＝2|P|X| CC |M| PT | sequence number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| timestamp |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| synchronization source (SSRC) identifier |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

| contributing source (CSRC) identifiers |

| .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTCP主要有五种分组类型，它们携带不同的控制信息。发送方报告(Sender Report，简称SR)，接收方报告(Receiver Report，简称RR)，源描述分组(Source DEScription，简称SDES)，结束参与指示分组BYE和特别应用功能分组APP。

APP包用于开发新应用，不要求注册包类型值。下一应用数据单元应用(Next Application Data Unit Application，简称NADU APP)是3GPP R6针对流媒体功能作的功能性扩展，可以传递多种信息，例如，终端可用缓存(Free Buffer Space，简称FBS)，下一个应用数据单元序列号(Nextapplication data unit Sequence Number，简称NSN)，播放延迟(PlayoutDelay)等信息，可供流媒体平台调整传输策略。NADU APP具体内容用二进制编码方式包含在RR中传递。NADU报告的数据格式如下：

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Playout Delay | NSN |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Reserved | NUN | Free Buffer Space (FBS) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

一种常用的流媒体业务计费方式为按时长计费。在现有的按时长计费方法中，服务器从开始向终端播放流媒体开始计时，直到用户主动中止或连接超时后才停止计时，然后服务器根据这段播放时间计算费用。但是，由于流媒体是边下载边播放，播放过程中由于网络带宽降低，流媒体播放会出现暂停，等待内容下载到一定量后再继续播放，这样用户实际收看时长除了实际播放时间，还有用户等待播放的时间，而用户期望的按时长计费应该是根据用户接收到的内容的实际播放时间进行计费，这不同于现有服务器计算的播放时间。参见图1，流媒体服务器通过移动网络向移动终端发送流媒体数据，终端共播放了10秒的流媒体内容，由于传输带宽问题，播放过程中断了10秒，在播放完10秒的流媒体数据后，终端与服务器的连接发生了中断，在中断60秒后，由于中断超时，服务器停止计时；从服务器开始传输数据至中断超时，共计80秒，而用户实际上只收看了10秒的流媒体内容；在有的计费方法中，会按照80秒计费，而在有的计费方法中，会将中断超时的60秒扣除，按照20秒计费，但即使是这样，由于播放过程出现了暂停，计费时长还是比用户收到内容的实际播放时长多10秒。

发明内容

本发明的目的在于针对现有技术所存在的缺陷，提供一种移动流媒体的计时方法，能够对流媒体的实际播放进行更为准确的计时。

为了实现上述目的，本发明提供了一种移动流媒体的计时方法，包括：移动终端每接收到一个RTP数据包，就向流媒体服务器反馈一个接收方报告；流媒体服务器根据接收方报告计算流媒体的播放时间长度。

其中，在计算流媒体的播放时间长度时，流媒体服务器可根据接收方报告计算移动终端接收到的RTP数据包数目，然后根据移动终端接收到的RTP数据包数目、RTP数据包实际负荷尺寸及流媒体编码速率计算流媒体的播放时间长度。

在计算RTP数据包数目时，流媒体服务器可根据接收报告中携带的下一应用数据单元序列号信息及序列号制定规则计算移动终端接收到的RTP数据包数目；也可对接收方报告计数，将接收报告的数目作为移动终端接收到的RTP数据包数目。

当流媒体的编码速率和/或封包格式可变时，流媒体服务器根据接收报告确定该接收报告对应的RTP数据包的编码速率和/或封包格式，针对不同的编码速率和/或封包格式，对接收方报告分别计数。

流媒体服务器可在封装RTP数据包时，将每个RTP数据包的序列号及媒体流的编码速率和/或封包格式记录于RTP数据包信息表中，在流媒体播放时，根据接收报告中携带的下一应用数据单元序列号确定该接收报告对应的RTP数据包的序列号，并在RTP数据包信息表中查询该RTP数据包序列号对应的编码速率和/或封包格式，从而确定RTP数据包的编码速率和/或封包格式；或者，在接收报告中携带编码速率和/或封包格式信息，根据接收报告中携带的编码速率和/或封包格式信息确定接收报告对应的RTP数据包的编码速率。

流媒体服务器可根据流媒体的编码格式及封包格式计算RTP数据包实际负荷尺寸。

本发明根据移动终端反馈的接收方报告对流媒体的播放进行计时，能有效避免将由网络传输时延等问题引起的播放中断时间计入实际播放时间，由此得到的播放时长是移动终端实际接收到的流媒体数据的播放时长，从而实现了流媒体播放的准确计时。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

图1为现有的移动流媒体的计时方法示意图；

图2为本发明的移动流媒体的计时方法流程图；

图3为流媒体编码速率可变，封包格式不变时的RTP数据包计数方法流程图。

具体实施方式

如图2所示，为本发明的移动流媒体的计时方法流程图，该方法包括如下步骤：

步骤1、在使用流媒体业务时，移动终端每接收到一个RTP数据包，就向流媒体服务器反馈一个接收方报告RR；

步骤2、在流媒体业务结束后，流媒体服务器根据接收方报告RR计算流媒体的播放时间长度。

其中，流媒体业务的结束可能是由于移动终端主动终止使用业务而结束的，也可能是由于连接中断超时而结束的。

由于本发明是根据移动终端在使用流媒体业务时的实时反馈计算流媒体播放时长，因此播放时间的计算更为准确。

在计算时间长度时，需要如下参数：RTP数据包实际负荷尺寸(RTP数据包中实际包括的媒体数据的尺寸)，移动终端接收到的RTP数据包数目，以及流媒体的编码速率。

RTP数据包实际负荷尺寸可根据流媒体的编码格式及封包格式计算。

移动终端接收到的RTP数据包的数目是根据接收报告RR计算的。在计算时，在流媒体服务器对收到的每一个接收报告逐一计数，将接收报告的数目作为移动终端接收到的RTP数据包数目。

在本发明一具体实施例中，流媒体业务参数如下：

视频流编码速率：128kbps

采样率：44.1MHz

MPEG包尺寸：417bytes

RTP数据包实际负荷尺寸：3×417＝1251bytes

每个RTP数据包的播放时间：Tpacket＝1251×8/128000＝0.078s

在使用流媒体业务时，移动终端每接收到一个RTP数据包，就向流媒体服务器反馈一个接收报告RR，流媒体服务器对接收报告RR进行计数。流媒体业务可能在用户主动终止，或在连接超时时结束，当流媒体业务结束后，流媒体服务器将总共接收到的接收报告RR的数目作为移动终端时间接收到的RTP数据包的数目，计算实际播放时长，例如，总共接收到1000个接收报告，那么播放时长为0.078×1000＝78s。

另外，也可根据NSN计算移动终端接收到的RTP数据包的数目。在实时传输控制协议RTCP的接收报告RR中，携带下一ADU的序列号NSN，即下一个RTP数据包的序列号。流媒体服务器先后发送的相邻RTP数据包的序列号是递增的，并且在数据传输过程中，序列号增量是固定的。通常每一RTP数据包的序列号比前一RTP数据包序列号增一，也有增量为二或三的情况。流媒体服务器可根据序列号的制定规则，通过NSN获知移动终端接收到的RTP数据包数目。例如，若序列号的增量为二，那么流媒体服务器需要从收到的各接收报告RR中提取NSN，用最大的序列号NSNmax减去最小的序列号NSNmin，然后再除以增量二，就可以得到移动终端接收到的RTP数据包的数目了。但是，这种方法存在一些缺陷，在发送最后一个接收报告之前，若用户接收的流媒体数据出现了丢包，虽然用户没有收看到相应的流媒体，但仍会将丢包的播放时间计算在内，因此，与这种方法相比，计数的方法计算得到的RTP数据包数目更为准确。

在上述实施例中，流媒体业务是固定码率的，即在一次会话中RTP数据包的编码速率是恒定不变的。流媒体业务的编码速率也可能是变化的，即在一次会话中，RTP数据包的编码速率是可变的。移动终端在使用流媒体业务时，由于空中无线接收信号的不稳定，当无线网络的带宽低于内容文件的编码速率时，会造成移动终端不停地缓冲，影响用户的观看。在这种情况下，流媒体服务器可根据终端当前的网络带宽的情况，选择低编码速率的流媒体文件传送给终端，尽可能保证用户流畅的感觉。当无线网络的带宽高于内容文件的编码速率时，移动终端不会缓冲，为了充分利用无线带宽，流媒体服务器可选择高编码速率的流媒体文件传送给终端，使用户可以观看更为清晰的业务内容。

由于在媒体数据一定的情况下，编码速率不同，播放的时间就会有所不同，因此，在流媒体业务的编码速率可变时，需要根据编码速率确定各RTP数据包的播放时间，对不同编码速率的RTP数据包分别计数。

另外，当RTP数据包的封包格式(RTP数据包包括的媒体数据包的数目)不同时，其包括的实际负荷尺寸不同，在编码速率一定的情况下，其播放时间也是不同的，因此，若流媒体业务的RTP数据包的封包格式可变，那么在计算流媒体播放时间时，还需要将其考虑在内。

每个RTP数据包的编码速率信息以及封包格式信息至少可通过两种方式记录和获取：一种是在接收报告中增加新的字段，用来标识每个RTP数据包的编码速率和封包格式，流媒体服务器接收到接收报告后，通过读取字段就可得到相应的信息；另一种是流媒体在封装RTP数据包时，将序列号、编码速率及封包格式记录在RTP数据包信息表中，从而，流媒体服务器在接收到接收报告后，可根据其中携带的下一ADU的序列号NSN确定RTP数据包的编码速率和封包格式。其中，RTP数据包信息表可存储于流媒体服务器内部，也可存储在其外部的数据库中。

如图3所示，为流媒体编码速率可变，封包格式不变时的RTP数据包计数方法流程图，包括：

步骤101、流媒体服务器在封装RTP数据包时，在内部数据库中记录每个RTP数据包的序列号及其媒体流的编码速率；

步骤102、流媒体服务器在收到实时传输控制协议RTCP的接收报告RR后，从中提取下一ADU的序列号NSN，即下一个RTP数据包的序列号；

步骤103、根据NSN确定接收报告RR对应的RTP数据包的序列号；

例如，在序列号增一的情况下，将NSN减一即可获得接收报告RR对应的RTP数据包的序列号SN；

步骤104、流媒体服务器在RTP数据包信息表中查询序列号SN对应的编码速率；

步骤105、将相应编码速率的RTP数据包数目加一。

上述步骤可实现对不同编码速率的RTP数据包分别进行计数，从而根据各编码速率的RTP数据包数目以及单个RTP数据包的播放时间即可计算出流媒体播放时间。当编码速率相同封装格式不同时，需针对不同的封装格式分别计数。当编码速率及封装格式均不同时，需要对每一种RTP数据包分别计数。例如，编码速率有两种，64kpbs及128kpbs，封装格式也有两种，2个MPEG包和3个MPEG包，那么，可能需要对四种RTP数据包分别计数，四种RTP数据包分别是：编码速率为64kpbs封装2个MPEG包的RTP数据包，编码速率为128kpbs封装3个MPEG包的RTP数据包，编码速率为64kpbs封装3个MPEG包的RTP数据包，以及编码速率为128kpbs封装2个MPEG包的数据包。

在本发明的另一具体实施例中，移动终端使用的流媒体业务的编码速率从128kbps切换到了64kbps，封包格式从封装3个MPEG包变成了封装2个MPEG包，流媒体业务的参数如下：

视频流1

视频流编码速率：128kbps

采样率：44.1MHz

MPEG包尺寸：417bytes

RTP数据包实际负荷尺寸：3×417＝1251bytes

每个RTP数据包实际播放时间：Tpacket＝1251×8/128000＝0.078s

视频流2

视频流编码速率：64kbps

采样率：44.1MHz

MPEG包尺寸：417bytes

RTP数据包实际负荷尺寸：2×417＝834bytes

每个RTP数据包播放时间：Tpacket＝834×8/64000＝0.10425s

从上述参数可知，在流媒体播放的过程中存在两种RTP数据包：编码速率为128kpbs封装3个MPEG包的RTP数据包，以及编码速率为64kpbs封装2个MPEG包的RTP数据包。在本实施例中，由于编码速率相同的RTP数据包，其封包格式也是相同的，从而可通过RTP数据包的编码速率确定RTP数据包的种类，因此可采用上述的流媒体编码速率可变封包格式不变时的RTP数据包计数方法，对两种RTP数据包分别计数。

在流媒体业务结束后，流媒体服务器根据RTP数据包的数目计算播放时间。假设编码速率为128kbps的RTP数据包和编码速率为64kbps的RTP数据包分别为600个和400个，那么移动终端的流媒体实际播放时长为：0.078×600+0.10425×400＝88.5s。

最后应当说明的是：以上实施例仅用以说明本发明的技术方案而非对其限制；尽管参照较佳实施例对本发明进行了详细的说明，所属领域的普通技术人员应当理解，依然可以对本发明的具体实施方式进行修改或者对部分技术特征进行等同替换；而不脱离本发明技术方案的精神，其均应涵盖在本发明请求保护的技术方案范围当中。

Claims

1、一种移动流媒体的计时方法，其中包括：移动终端每接收到一个RTP数据包，就向流媒体服务器反馈一个接收方报告；流媒体服务器根据接收方报告计算流媒体的播放时间长度。

2、根据权利要求1所述的移动流媒体的计时方法，其中所述的流媒体服务器根据接收方报告计算流媒体的播放时间长度具体为：流媒体服务器根据接收方报告计算移动终端接收到的RTP数据包数目，并根据移动终端接收到的RTP数据包数目、RTP数据包实际负荷尺寸及流媒体编码速率计算流媒体的播放时间长度。

3、根据权利要求2所述的移动流媒体的计时方法，其中所述的计算移动终端接收到的RTP数据包数目具体为：流媒体服务器根据接收报告中携带的下一应用数据单元序列号信息及序列号制定规则计算移动终端接收到的RTP数据包数目。

4、根据权利要求2所述的移动流媒体的计时方法，其中所述的计算移动终端接收到的RTP数据包数目具体为：流媒体服务器对接收方报告计数，将接收报告的数目作为移动终端接收到的RTP数据包数目。

5、根据权利要求4所述的移动流媒体的计时方法，其中所述流媒体的编码速率和/或封包格式是可变的，流媒体服务器根据接收报告确定该接收报告对应的RTP数据包的编码速率，针对不同的编码速率和/或封包格式，对接收方报告分别计数。

6、根据权利要求5所述的移动流媒体的计时方法，其中还包括：流媒体服务器在封装RTP数据包时，将每个RTP数据包的序列号及媒体流的编码速率和/或封包格式记录于RTP数据包信息表中。

7、根据权利要求6所述的移动流媒体的计时方法，其中所述的根据接收报告确定该接收报告对应的RTP数据包的编码速率和/或封包格式具体为：根据接收报告中携带的下一应用数据单元序列号确定该接收报告对应的RTP数据包的序列号，并在RTP数据包信息表中查询该RTP数据包序列号对应的编码速率和/或封包格式。

8、根据权利要求5所述的移动流媒体的计时方法，其中所述接收报告中携带有编码速率和/或封包格式信息，所述的根据接收报告确定该接收报告对应的RTP数据包的编码速率和/或封包格式具体为：根据接收报告中携带的编码速率和/或封包格式信息确定接收报告对应的RTP数据包的编码速率和/或封包格式。

9、根据权利要求2-8任一所述的移动流媒体的计时方法，其中还包括：流媒体服务器根据流媒体的编码格式及封包格式计算RTP数据包实际负荷尺寸。