CN108476332B - 客户端、服务器、接收方法及发送方法 - Google Patents

Abstract

一种接收基于MPEG－DASH(Moving Picture Experts Group－Dynamic Adaptive Streaming over HTTP)标准的流媒体数据的客户端(20A)，具备：发送部(202)，向服务器发送MPD(Media Presentation Description)的请求或段的请求；以及接收部(201)，接收由MPD指定的MPD及由段的请求指定的段；MPD的请求包含请求将起始段以推送方式发送的信息；接收部(201)接收以推送方式发送的起始段。

Description

客户端、服务器、接收方法及发送方法

技术领域

本发明涉及使用MPEG－DASH格式、在带宽变化的网络上进行多媒体内容的流媒体的接收的客户端、以及进行该流媒体的发送的服务器、和客户端的接收方法及服务器的发送方法。

背景技术

非专利文献1公开了作为基于HTTP(HyperText Transfer Protocol：超文本传输协议)的自适应流媒体技术的标准规格的MPEG－DASH(Moving Picture Experts Group(运动图像专家组)－Dynamic Adaptive Streaming over HTTP(基于HTTP的动态自适应流媒体))。DASH服务器将与画质及比特率不同的多个表现对应的内容数据作为与段(segment)或子段对应的文件来提供，所述段是以时间划分的单位，所述子段是将段划分而成的。段或子段例如是以几秒单位划分的单位，与段或子段对应的文件是包括影像或声音的MP4文件。与段或子段对应的文件例如可以指定URL地址而用HTTP取得。DASH客户端能够基于记述有内容整体或一部分的结构及开始段的指定的清单文件(所谓的MPD(Media PresentationDescription：媒体表示描述))，根据当前的网络的状态和吞吐量来请求适当的品质(所谓的表现)的与段或子段对应的文件。

现有技术文献

非专利文献

非专利文献1：Information technology－Dynamic adaptive streaming overHTTP(DASH)－Part 1：Media presentation description and segment formats，INTERNATIONAL STANDARD，ISO/IEC 23009－1：2014(E)

发明内容

发明要解决的课题

但是，在非专利文献1所公开的技术中，未能减少在客户端及服务器中进行的处理的处理量。

用来解决课题的手段

有关本发明的一技术方案的客户端，是接收基于MPEG－DASH(Moving PictureExperts Group－Dynamic Adaptive Streaming over HTTP)标准的流媒体数据的客户端，具备：发送部，向服务器发送MPD(Media Presentation Description)的请求或段的请求；以及接收部，接收由上述MPD的请求指定的MPD及由上述段的请求指定的段；上述MPD的请求包含请求将起始段以推送方式发送的信息；上述接收部接收以推送方式发送来的起始段。

有关本发明的一技术方案的服务器，是发送基于MPEG－DASH标准的流媒体数据的服务器，具备：接收部，从客户端接收MPD的请求或段的请求；以及发送部，将由上述接收部接收到的上述MPD的请求所指定的MPD、和由上述接收部接收到的上述段的请求所指定的段以推送方式发送给上述客户端；上述MPD的请求包含请求将起始段以推送方式发送的信息；上述发送部将上述起始段以推送方式发送。

另外，这些整体或具体的技术方案也可以由系统、方法、集成电路、计算机程序或计算机可读取的CD－ROM等记录介质实现，也可以由系统、方法、集成电路、计算机程序及记录介质的任意的组合来实现。

发明效果

根据上述技术方案，能够减少在客户端及服务器中进行的处理的处理量。

附图说明

图1是用来对有关实施方式2的通信系统进行说明的图。

图2是表示TCP头的结构的图。

图3是表示从Wireshark(注册商标)的会话的摘录的图。

图4是表示以100KByte/s的TCP带宽进行传送的情况下的吞吐量的推测结果的曲线图。

图5是表示以500KByte/s的TCP带宽进行传送的情况下的吞吐量的推测结果的曲线图。

图6是表示不限制带宽而传送的情况下的吞吐量的推测结果的曲线图。

图7是表示不限制带宽而传送的情况下的吞吐量的推测结果的曲线图。

图8是表示不限制带宽而传送的情况下的吞吐量的推测结果的曲线图。

图9是表示不限制带宽而传送的情况下的吞吐量的推测结果的曲线图。

图10是表示实施方式2的通信系统的详细结构的另一例的图。

图11是表示变形例的通信系统的动作的顺序图。

图12是表示通信系统的具体的结构的另一例的图。

图13是用来说明包括服务器的发送方法及客户端的接收方法的、通信系统的动作的顺序图。

具体实施方式

有关本发明的一技术方案的客户端，是接收基于MPEG－DASH(Moving PictureExperts Group－Dynamic Adaptive Streaming over HTTP)标准的流媒体数据的客户端，具备：发送部，向服务器发送MPD(Media Presentation Description：媒体表示描述)的请求或段的请求；以及接收部，接收由上述MPD的请求指定的MPD及由上述段的请求指定的段；上述MPD的请求包含请求将起始段以推送方式发送的信息；上述接收部接收以推送方式发送来的起始段。

有关本发明的一技术方案的服务器，是发送基于MPEG－DASH标准的流媒体数据的服务器，具备：接收部，从客户端接收MPD的请求或段的请求；以及发送部，将由上述接收部接收到的上述MPD的请求所指定的MPD、和由上述接收部接收到的上述段的请求所指定的段以推送方式发送上述客户端；上述MPD的请求包含请求将起始段以推送方式发送的信息；上述发送部将上述起始段以推送方式发送。

另外，这些整体或具体的技术方案也可以由系统、方法、集成电路、计算机程序或计算机可读取的CD－ROM等记录介质实现，也可以由系统、方法、集成电路、计算机程序及记录介质的任意的组合来实现。

以下，参照附图对有关本发明的一技术方案的客户端、服务器、接收方法及发送方法具体地进行说明。

另外，以下说明的实施方式都表示本发明的一具体例。在以下的实施方式中表示的数值、形状、材料、构成要素、构成要素的配置位置及连接形态、步骤、步骤的顺序等是一例，并不是限定本发明的意思。此外，关于以下的实施方式的构成要素中的、在表示最上位概念的独立权利要求中没有记载的构成要素，设为任意的构成要素进行说明。

(实施方式1)

[1－1.背景技术]

MPEG－DASH指定用于被进行ISO－BMFF格式化的媒体段的URL地址指定形式，清单文件被称作MPD(Media Presentation Description，媒体表示描述)。DASH原本是为了经由可变吞吐量的网络(例如，没有受到管理的因特网连接(OTT))来应对媒体的传输而提出的。MPEG－DASH的系统是客户端中心的技术思想，利用了已经可利用的技术。因此，现有的HTTP－WEB服务器和DASH对应客户端能够实现动态流媒体会话。

最初的概念被MPEG扩大了范围，新的概念被导入到SAND(Server－And－Network－Assisted－DASH)、CAPCO(Content－Aggregation－and－Playback Control)及FDH(Full－Duplex－HTTP)等中。后者的FDH利用了最近被批准的HTTP/2标准，服务器能够向没有被客户端自身请求的客户端推送。所定义的关联推送指令的优点主要在于削减开销。对于全部的推送段，来自客户端的对应的HTTP请求可以省略，由此能够节约带宽。

DASH的FDH部分目前在ISO/IEC23009部分6中指定，包含有目前为止用来从服务器向客户端推送内容的4个策略。这些策略被称作推送指令(push directive)，由推送类型(push type)和附加的推送参数(push parameter)构成。推送类型例如包括后续推送(pushnext)、无推送(push none)、推送模板(push template)及推送时间(push time)。

后续推送和推送参数K表示为了使用作为初始索引被请求的段进行推送而考虑接下来的K段。

无推送表示没有发生推送。在此情况下，不使用参数。

推送模板表示为了推送而考虑由URI模板说明的若干个段。推送参数被称作URI模板。

推送时间是为了从被请求的段的开始起到段超过时间T的被指定的段时间为止的推送而考虑的。将时间T作为推送参数进行信号传输(signalling)。

后续推送及推送时间表示，通过将它们的推送参数设为0，能够选择服务器无限地进行推送。这已经包含在本发明的主旨中，但不使服务器进行超过表现的选择的控制，也不对比特率的变动起作用。

[1－2.典型的DASH－FDH会话]

客户端用推送指令最先请求MPD，接着请求媒体段。在接收到所请求的MPD后，客户端分别使用DASH段URL和推送指令，开始从服务器请求媒体段。并且，服务器用所请求的媒体段进行响应。如由推送策略(push strategy)表示那样，媒体段通过推送循环而继续。客户端在接收到最小量的数据后，开始媒体的再现。上述的过程反复进行，直到媒体流媒体会话结束。

另外，服务器为了准备用于下个媒体段的客户端，也可以不仅发送MPD，还同时事前以推送方式发送起始段(Initialization Segment)。起始段是包含段的头信息的信息。

推送指令的优点在于开销的削减。上述推送指令的全部在还有被请求的段数的某个在被提供(后续推送)、或段时间超过的(推送时间)情况下，为了请求新的段而需要客户端。以下说明的是作为本发明一技术方案的新的推送指令，它使得服务器能够自动地在整个总媒体期间中选择段而推送。由此，将由段的请求带来的开销降低到最小限度。此外，关于用于向客户端的连接的全部或一部分的单播及/或多播模式的应用，能够使服务器侧决定。服务器自动决定的也可以仅是段的比特率或分辨率等的与服务器和接收终端之间的网络频带关联的参数。

[1－3.服务器中的客户端侧的吞吐量的推测]

本发明的一部分，是基于在TCP/IP连接期间从客户端发送给服务器的确认响应包中包含的确认响应号，在服务器中推测客户端的经验的吞吐量的方法。这些确认响应包是TCP层的不可或缺的部分，所以为了使用该方法，不用生成或不需要追加的开销。该吞吐量推测方法与自动推送指令一起，维持基于当前的吞吐量来切换显示这样的DASH的技术思想，并且使总开销减小到最小限度。

DASH基于普遍HTTP协议。并且，在此期间，HTTP依赖于为了传送请求、响应及数据而成为基础的TCP/IP层。TCP/IP层将数据流分割为包，保证其可靠性高的传送。到该过程为止，HTTP层完全不可见。打包处理及重构处理由作为TCP头中包含的2个字段的序列号和确认响应号启用。

序列号及确认响应号在TCP连接(3次握手)的初始阶段期间在双方的端点生成。两个号用于打包及包重构处理。它们最初是2个随机的32位的整数，在服务器与客户端之间被交换。

关于序列号，由服务器增加与当前发送的字节数相当的量。由此，包之间的相对的序列号作为向总数据字节流中的当前的包的开始位置的指针发挥功能。

更重要的是，为了向服务器通知正常接收到的字节数，从客户端向服务器发送确认响应号。因而，具有对确认响应包的到达时间进行计测的外部计时器的服务器能够容易地推测客户端的当前的经验的吞吐量。

[1－4.效果等]

如上所述，有关本发明的系统由于不需要度量值(metric)消息及段请求，所以能够降低开销。此外，有关本发明的系统能够集中管理单播模式及多播模式的切换。此外，有关本发明的系统能够在中央管理其资源。即，服务器能够一边监视吞吐量一边预测吞吐量的瓶颈，能够顺畅地减少传送比特率，由此，能够避免表现的不想要的高动态变化。HTTP/2对应的客户端不需要跟踪流量(traffic)诊断。流量诊断能够同时实现节电和成本削减。

进而，典型的是，服务器向多个客户端提供数据。如果利用自动推送指令和吞吐量推测的机制，则服务器在多个客户端同时请求了相同的内容的情况下(例如，与实况转播TV传送关联)，能够选择从单播模式向更有效的多播模式的切换。例如能够根据通道条件，将单播模式或多播模式分配给全部或一部分的上述客户端。

特别是，在事件会场等特定的区域内的通信的情况下，也有可能基于入场者数、区域内的通信终端固有的信息等其他信息，能够预先推测被选择的可能性高的速率或段自身。在这样的情况下，服务器中的判断和选择处理被简单化，能够进行延迟量少且理想的分发。

[1－5.本发明的概略]

·新的DASH的自动推送指令

·DASH的推送参数/功能指标：客户端需要在服务器无期限地提供媒体段之前知道客户端的能力。

·基于TCP的确认响应号的吞吐量推测方法

·现有的DASH推送指令(后续、时间、模板)与被要求的新的自动DASH推送指令的组合

·例：服务器自动推送接下来的K段，然后，接收用来自动推送接下来的L段的新的推送请求。

·用于同时请求相同的内容的全部或一部分的客户端的单播模式或多播模式的自动及动态选择(基于上述的吞吐量测定值)

[1－5－1.详细1]

新的DASH推送指令以被服务器监视的方式使得服务器能够选择数据并向客户端推送。以下，将该推送指令称作自动推送指令。

[1－5－2.详细2]

DASH随着推送指令而推送参数。此外，客户端的能力被通知给服务器。客户端例如是关于可利用的媒体解码器、可再现的图像分辨率及帧速率进行处理的装置。在实施方式中，推送参数也可以如表1－1及表1－2所示，通过拥有从接收能力表(RCT：ReceiverCapability Table)取出的字段的复合数据类型来表现。本实施方式不应被限定地理解。例如，不应被限定于涉及起到向服务器的对客户端的能力进行通信的相同的目的的接收能力表的任意的形式。

[表1－1]

[表1－2]

“modeIndicator”在选择实际的参数时指引服务器。适合的模式例如是最高品质、最低品质、以及表现的切换的低动态。它们被表示在表2中。也可以是其他的模式，不应理解为本发明限定于所示出的这些模式。

[表2]

[1－5－3.详细3]

其他的DASH的推送指令的组合具有自动或推送自动速度的推送指令。在本发明的一实施方式中，用来与自动推送指令组合的适当的推送指令也可以是后续推送、推送时间及推送模板。另外，不应限定于这些组合。

例如，进行指定以使用后续推送来接收接下来的N个段，并且指定推送自动速率(push－automatic－rate)，由此服务器自动地选择N个段的比特率。或者，推送自动速率也可以到通过另行规定的推送指令即推送通道自动速率(push－cancel－automatic－rate)无效化为止为有效。此时，如果没有发出推送通道自动速率，则对于在上述N个段的发送后被传送的段，推送自动速率也为有效。

即使是被指定了推送全自动(push－full－automatic)后，在段的发送中服务器接收到“无推送”的情况下，服务器也立即或在发送中的段的最终数据发送后停止段的发送。

[1－5－4.详细4]

推测方法及推测装置利用外部计时器计测确认响应包的到达时间，从而基于从客户端向服务器在TCP头中发送的确认响应号，进行客户端的吞吐量的推测。

表示作为当前的确认响应号与最初的确认响应号之间之差的相对的确认响应号，同样，表示作为当前的确认响应包的到达时间与最初的确认响应包的到达时间之间之差的相对的时间。用于吞吐量推测的最初的方法，是计算相对的确认响应号与相对的时间的商。

表示作为最后与从最后起第2个确认响应包之间的差的确认响应号的差。同样，表示作为最后与从最后起第2个确认响应包之间的到达时间的差的时间差。用于吞吐量推测的第二方法，是计算适当的数字滤波器的确认响应号的差与时间差的连续的商的平均值。

[1－5－5.详细5]

(在各段的极端的情形中)进行自动及动态的选择。在自动及动态的选择中，基于上述的吞吐量计测方法(表示向各个单一的客户端的连接的品质)，进行用于同时请求了相同的内容的全部或一部分的客户端的单播模式或多播模式的选择。

(实施方式2)

[2－1.背景技术]

DASH的哲学基于由客户端计测吞吐量、根据这些计测值请求段。最近，HTTP/2导入了服务器能够向没有请求的客户端发送数据的新的推送功能。在DASH规格的部分6中，MPEG考虑了为了DASH而想要利用该新的HTTP/2功能。部分6被称作FDH。4个推送指令已经存在(后续推送、无推送、推送模板、推送时间)，但它们依然大部分被客户端驱动。

如在实施方式1中说明那样，向客户端的吞吐量可以在服务器侧测定。即，在服务器中，能够通过使用新的自动推送指令来管理客户端。

段的选择在一部分或全部中由服务器基于推送指令来控制。即，传送段的数量或时间和其比特率等由服务器决定。

[2－2.计测的设置]

图1是用来对有关实施方式2的通信系统进行说明的图。图1的(a)是表示通信系统的结构的一例的框图，图1的(b)是用来对通信系统中的通信状况进行说明的图。

如图1的(a)所示，通信系统1具备服务器10、和经由通信网络30与服务器10通信连接的客户端20。

服务器10是HTTP/2服务器。服务器10为了用户流量整形而执行Dummynet。服务器10通过执行用来对包的取得状况及协议进行解析的软件(例如，Wireshark(注册商标))，捕获向pcap文件(用具有scapy包的Python进行进一步的处理)的全部的包。这里，所谓pcap(packet capture：包捕获)，是计算机网络管理领域中的用于抓包器(包分析器)的API(Application Programming Interface)。在Unix(注册商标)类的系统中，pcap被作为libpcap安装。

服务器10将1MB的文件与PRBS(Pseudo－Random Bit Sequence：伪随机比特序列)一起发送。Dummynet用于流量整形、特别是用于控制发送带宽。Wireshark(注册商标)捕获TCP/IP流量并保存。Python用于基于Wireshark(注册商标)的捕获来进行数据集成和评价。

服务器10既可以由处理器及保存有规定的程序的存储器实现，也可以由专用电路实现。服务器10包括计算机。

客户端20也可以由TV、播放器、记录机、智能电话、平板终端、PC等实现。

如图1的(b)所示，能够取得从服务器10发送文件的定时(时间戳)、和从客户端20发送对该文件的ACK的时间。

[2－3.Dummynet]

接着，对由服务器10执行的Dummynet进行说明。

Dummynet是网络仿真工具。Dummynet对于队列、带宽限制、延迟、丢包进行模拟，安装有各种各样的调度算法。Dummynet可在任意的操作系统内执行，通过监听经由网络堆栈在中途选择的流量而动作。它向安装有队列的设置、调度器及链路、全部可设定的功能(带宽、延迟、损失率、队列尺寸、调度方针…)的管路移交包。关于流量的选择，使用作为用于Dummynet的主用户接口的ipfw防火墙来进行。对“Hello world”、全部的发信TCP流量制作管路，将带宽设定为500kByte/s。例如，作为包过滤器型的防火墙的ipfw(ipfirewall)对于proto tcp之外追加1个管路。此外，例如ipfw的1个管路将带宽设定为500kByte/s。

[2－4.TCP头]

接着，对TCP头进行说明。

图2是表示TCP头的结构的图。

如图2所示，TCP头包括序列号(Sequence Number)和响应确认号(Acknowledgement Number)。

序列号是向整体的发送数据的字节流中的当前的有效载荷的位置的指针。此外，序列号用于将接收到的包按与该包被发送的顺序相同的顺序排序。

响应确认号表示具有特定的序列号的包被正确地接收。此外，响应确认号包括接下来预想的序列号。

根据(从客户端向服务器发送的)响应确认号，服务器10能够导出正常地接收到的字节数。如果还使用ACK包的定时，则能够推测当前的吞吐量。

在3次握手的期间，双方的端点(即，服务器10及客户端20)关于分别对应的序列号生成随机的32比特的整数，将它们交换。如从Wireshark(注册商标)的会话的摘录(图3)所示，由四方形包围的部分表示序列号及响应确认号。发送的端点根据当前发送的字节数使其序列号增加。响应确认号由客户端为了表示被正确地接收到的字节数而使用。

图4～图9是表示实际被传送的字节数和通过上述方法推测的吞吐量的结果的曲线图。图4是表示以100kByte/s的TCP带宽传送的情况下的吞吐量的推测结果的曲线图。图5是表示以500KByte/s的TCP带宽传送的情况下的吞吐量的推测结果的曲线图。图6～图9是表示不限制带宽而传送的情况下的吞吐量的推测结果的曲线图。

如图4～图9所示，推测结果与实际被传送的字节数大致一致，所以能够利用推测结果。

如上述那样，上述服务器侧吞吐量测定表示主要能够执行。

由此，服务器10能够主要管理该资源。服务器10能够进一步避免客户端20侧的表现的偏差。客户端20也可以不智能，不需要跟踪流量诊断。通过将度量值/诊断消息保存，能够减小开销。

例如，如表3所示，也可以采用追加了推送自动速率及推送全自动的推送指令。

[表3]

图10是表示实施方式2的通信系统的详细的结构的另一例的图。

通信系统1具备服务器10和客户端20。服务器10和客户端20经由通信网络30相互被通信连接。

服务器10及客户端20具有处理器、存储设备及包含收发机的通信机。

服务器10及客户端20的各自具备的处理器执行由顺序图(参照图11)表示的处理。处理器使用与服务器10及客户端20或其他装置的协同中的其他单元。典型地，用来执行流程图中表示的处理的程序分别被存储在服务器10及客户端20具备的存储设备中。

服务器10具备选择部11及发送部12。

关于服务器10及客户端20的详细的说明分别在通信系统1的动作的说明中进行。

图11是表示通信系统的动作的一例的顺序图。

首先，客户端20向服务器10发送表示MPD的请求的MPD请求(MPD request)(S11)。

接着，服务器10接收从客户端20发送的MPD请求，服务器10的发送部12将与接收到的MPD请求对应的MPD(对应MPD)发送给客户端20(S12)。另外，如在实施方式1中说明那样，在S12中，服务器10也可以除了与接收到的MPD请求对应的MPD以外，还将一部分或全部的起始段以推送方式发送给客户端20。以下，将根据MPD请求、除了由MPD请求中指定的MPD以外还将起始段及更新后的新的MPD等的其他文件以推送方式发送的情况称作MPD推送(MPDpush)。

另外，服务器10不将起始段以推送方式发送的情况下的客户端20的动作，和与不对应于推送发送的服务器进行通信的情况是同样的。即，客户端20发送指定了在接收到的MPD中记载的起始段中的需要的起始段的段请求。服务器10将由接收到的段请求指定的起始段发送给客户端20。

客户端20接收对应MPD，将表示段#n的请求的段请求(Segment request)与1个以上的推送指令一起发送给服务器10，计测Ack(S13)。

服务器10接收指定了推送指令的段#n的段请求，服务器10的选择部11基于接收到的段的推送指令，决定固定速率或自适应速率，基于接收到的段#n的段请求，选择要发送的段(S14)。

服务器10发送由段请求指定的段n，将选择部11选择的段n+1以后的段以推送方式依次发送(S15、S16)。以下，将根据段请求而将由段请求指定的段以外的段以推送方式发送的情况也称作段推送(Segment push)。

另外，段n的发送也可以在决定固定速率或自适应速率之前进行。此外，选择部11基于通过上述利用Ack的计测得到的吞吐量，来进行段n以后的段的选择。另外，在由段#n的段请求指定的推送指令是对推送自动速率或推送全自动以外的推送发送进行请求的推送指令的情况下，选择部11不进行吞吐量的计测，而按照由段#n的段请求指定的推送指令，选择段n+1以后的段。

另外，在图10中，作为服务器10具备的结构，仅记载了为了以自适应速率发送段而需要的选择部11及发送部12。但是，服务器10当然具备例如在非专利文献1中记载的作为DASH服务器的动作中需要的其他结构。例如，服务器10具备接收部、处理部等，该接收部接收由客户端20发送的MPD请求或段请求等的消息，该处理部进行在接收到的消息中包含的DASH命令的解释、作为针对MPD请求或段请求等的消息的响应而向客户端20发送的消息的生成等。

在图10中，表示了MPD配送功能配置在服务器10的外部的例子，但这表示也可以将MPD从与服务器10不同的通信装置向客户端20发送。但是，如以下的图11的说明那样，在根据从客户端20发送的MPD请求而服务器10向客户端20发送MPD的情况下，服务器10具备MPD发送功能。

在图10中，表示了吞吐量计测模块被配置在服务器10的外部的例子，但也可以是服务器10具备吞吐量计测模块。

另外，在服务器10不对应于上述的推送自动速率或推送全自动这样的在服务器侧进行比特率的控制的推送指令的情况下，也可以没有在图10中表示的吞吐量计测模块。在此情况下，服务器10的选择部11基于附加在从客户端20接收到的段请求中的、在服务器侧进行比特率的控制的推送指令以外的推送指令(例如，后续推送、推送模板、推送时间)，选择推送发送的段。另外，在指定了无推送的情况下，客户端20对服务器10发送指定了再现所需要的段的段请求，取得该段。

此外，在图10中，关于客户端20没有公开详细的结构，但客户端20当然具备例如在非专利文献1中记载的作为DASH客户端的在动作中需要的其他结构。例如，客户端20具备对服务器10或其他通信装置发送MPD请求、段请求及Ack等的消息的发送部、及从服务器10或其他通信装置接收包括MPD、段、DASH命令的消息等的接收部。进而，客户端20具备进行接收到的消息中包含的DASH命令的解释、MPD请求或段请求等的向服务器10或其他通信装置发送的DASH命令的生成的DASH访问部。此外，客户端20也可以具备解码部，该解码部将由DASH访问部取得的媒体数据进行解码，并将解码后的声音信号或影像信号显示在客户端的内部、或与客户端以有线或无线方式连接的外部的显示部上。另外，上述的显示部例如是显示器或扬声器等。此外，客户端20也可以具备执行由DASH访问部取得的事件数据的应用部。

[3.变形例]

在上述的实施方式中，能够采用以下这样的变形。

[3－1.变形例1]

在上述的实施方式中，举例说明了将推送自动速率、推送全自动规定为与后续推送、无推送并列的能够指定为“push Type(推送类型)”的新的推送策略的情况，但也可以以其他的形式来规定。

例如，推送自动速率、推送全自动也可以定义为与在通过PushType选择了后续推送的情况下指定的参数(PUSH_PARAMS)即“K：Number”并列的(能够并记的)参数。在此情况下，在推送指令或PushAck的PUSH_PARAMS中并记多个参数。同样，在作为PushType而选择了推送模板或推送类型的情况下，也能够在PUSH_PARAMS中指定是否是“automatic”、或“automatic”的模式。

此外，例如推送自动速率、推送全自动也可以在推送指令中定义为与PUSH_TYPE并列的(并记的)参数。在此情况下，在推送指令的格式中，与PUSH_TYPE另行地设置指定是否是“automatic”、或“automatic”的模式的区域。

[3－2.变形例2]

在上述的实施方式中，能够应用以下这样的变形。但是，以下的结构也可以不与上述的实施方式(例如，段推送中的“automatic”指定)组合而使用。通过像这样将“automatic”作为独立的属性，不仅是服务器10送出的段的个数、时间长、比特率，关于其他参数，服务器10也能够指定是否自动地决定。

例如，在MPD请求中，在使用推送指令(或其他的Data Type(数据类型))指定MPD推送的情况下，也可以使用以下的某种结构、或以下的任意的结构的组合。

(1)

也可以是，如果在MPD请求中使用推送指令指定了MPD推送的实施，则当MPD被更新，服务器10就将新的MPD以推送方式发送。

(2)

也可以是，如果在MPD请求中使用推送指令指定了MPD推送的实施，则服务器10除了被指定的MPD以外，还将与媒体数据的解码或显示相关联的元数据以推送方式发送。这里，作为元数据的一例，可以列举媒体数据是MP4的情况下的MP4的头信息(即起始段)。在元数据中，例如保存向声音或影像编码数据的访问信息、PTS/DTS等。即，服务器10也可以将起始段与MPD一起向客户端20发送。另外，在此情况下，也可以使得能够通过MPD请求的推送指令来指定是否将元数据以推送方式发送。

(3)

MPD(或元数据)由服务器10以推送方式发送的期间或数量例如也可以由pushtype指定。即，服务器10也可以将由push type指定的期间或数量的MPD(及元数据)以推送方式发送。

(4)

也可以是，在被指定了MPD推送的情况下，服务器10进行预先规定的动作(默认动作)，MPD请求中的推送指令仅指定是否实施MPD推送。但是，也可以使得能够从客户端20或服务器10指定MPD推送的中止(不进行)。

另外，在客户端20发送了指定了请求MPD推送的推送指令的MPD请求、但服务器10指定为不进行MPD推送的情况下，客户端20的以后的动作当然与不对应于MPD推送的客户端的动作是同样的。即，客户端20通过向服务器10发送段请求来取得希望的媒体的再现所需要的起始段。

这样，通过使得服务器10能够指定不进行MPD推送，对于请求起始段的推送发送的客户端20，服务器10也能够决定不进行起始段的推送发送并向客户端通知，所以服务器10的控制的自由度变高。

(5)

在MPD推送中，与段推送的情况不同，例如也能够发送全部的起始段，所以服务器10或客户端20有可能不需要从对应的多个段(例如，具有相互不同的比特率的段)中选择某一个段。这样，在能够以MPD推送选择的推送策略与能够以段推送选择的推送策略不同的情况下，也可以将MPD请求中用来指定推送策略的“MPD push Directive”和段请求中用来指定推送策略的“Segment push Directive”分开规定。此外，在MPD请求和段请求中使用相同格式的推送指令，但也可以限制在MPD请求中能够使用的参数。例如，通过禁止automatic的使用，来限制在MPD请求中能够使用的参数。

(6)

也可以使得在MPD请求的推送指令中能够指定媒体段的推送策略。

例如，也可以在MPD请求中分别地指定MPD推送的推送策略和段的推送策略。

此外，例如也可以是，如果在MPD请求中指定媒体段的推送策略，则自动地选择/生成与被指定的段的推送策略对应的MPD推送的推送策略(包括无推送)。

此外，例如也可以是，如果在MPD请求中指定MPD推送的推送策略，则自动地选择或生成与被指定的MPD推送的推送策略对应的段的推送策略(包括无推送)。

[4.补充：客户端及服务器]

在使用图10及图11的说明中，表示了能够用推送指令来指定自动的客户端及服务器。以下，对在上述变形例的说明中言及的推送指令中不使用自动的情况下的、作为接收MPEG－DASH标准的流媒体数据的接收装置的客户端，以及作为发送该流媒体数据的发送装置的服务器的结构的一例进行说明。

图12是表示通信系统的结构的另一例的图。

服务器10A及客户端20A如在图10中也说明的那样，具有处理器、存储设备及包括收发机的通信机。

通信系统1A通过将服务器10A及客户端20A用未图示的通信网络相互通信连接而构成。

服务器10A具备接收部101和发送部102。接收部101及发送部102分别由例如微型计算机、处理器或专用电路等实现。此外，虽然在图12中没有图示，但与图10的服务器10同样，服务器10A也可以具备选择部及处理部。

另外，服务器10A具备的(1)MPD的发送、(2)段的发送(3)接收到的DASH命令的解释和DASH命令向客户端20A的发送的功能，既可以由同一个服务器实施，也可以是多个服务器分别具有至少某一个功能，由该多个服务器作为综合了上述的功能的动作而向客户端20A提供。

客户端20A具备接收部201和发送部202。接收部202及发送部202分别例如由微型计算机、处理器或专用电路等实现。此外，虽然在图12中没有图示，但与图10的客户端20同样，客户端20A也可以具备DASH访问部、解码部、应用部。

关于服务器10A及客户端20A的各构成要素实施的动作的说明，分别在发送方法及接收方法的说明中进行。

使用图13，对服务器10A及客户端20A实施的发送方法及接收方法的一例进行说明。

图13是用来说明包括服务器的发送方法及客户端的接收方法的通信系统的动作的顺序图。

对客户端20A的动作(接收方法)进行说明。

客户端20A的发送部202将指定了需要的MPD的MPD请求与1个以上的推送指令一起发送给服务器(S201)。在客户端20A发送的MPD请求中，除了由MPD请求指定的MPD以外，还设定了请求将由该MPD参照的起始段以推送方式发送的推送指令。

客户端20A的接收部201接收由MPD请求指定的MPD和以推送方式发送的起始段。

并且，客户端20A的发送部202将指定了段n的段请求与1个以上的推送指令一起发送(S202)。

对服务器10A的动作(发送方法)进行说明。

服务器10A的接收部101从客户端20A接收在步骤S201中发送的1个以上的推送指令及指定了MPD的MPD请求。

服务器10A的发送部102除了由接收部101接收到的MPD请求所指定的MPD以外，还将起始段发送给客户端20A(S101)。

服务器10A的接收部101接收由步骤S202发送的1个以上的推送指令和指定了段n的段请求。

服务器10A的发送部102将由段请求指定的段n发送给客户端20A(S102)。

同样，服务器10A的发送部102将段n+1以后的段以推送方式发送给客户端20A(S103)。

这样，客户端20A将MPD请求与意味着起始段的请求的推送指令一起发送给服务器10A，所以与以往的如在发送MPD请求并接收到MPD后发送指定了起始段的段请求而接收起始段那样、将MPD请求和起始段请求分开发送的情况相比，能够将处理削减1个步骤。因此，能够有效地减少处理量。

另外，在上述各实施方式中，各构成要素也可以由专用的硬件构成、或通过执行适合于各构成要素的软件程序来实现。各构成要素也可以通过由CPU或处理器等程序执行部将记录在硬盘或半导体存储器等记录介质中的软件程序读出并执行来实现。这里，实现上述各实施方式的接收方法及发送方法等的软件是以下这样的程序。

即，该程序使计算机执行接收方法，所述接收方法是接收基于MPEG－DASH标准的流媒体数据的客户端中的接收方法，将MPD的请求或段的请求发送给服务器，接收由上述MPD的请求指定的MPD及由上述段的请求指定的段，上述MPD的请求包含请求将起始段以推送方式发送的信息，在上述接收中，接收以推送方式发送的起始段。

此外，该程序使计算机执行发送方法，所述发送方法是发送基于MPEG－DASH标准的流媒体数据的服务器中的发送方法，从客户端接收MPD的请求或段的请求，将由接收到的上述MPD的请求指定的MPD和由接收到的上述段的请求指定的段以推送方式发送给上述客户端，上述MPD的请求包含请求将起始段以推送方式发送的信息，在上述发送中，将上述起始段以推送方式发送。

以上，基于实施方式对有关本发明的一个或多个技术方案的客户端、服务器、接收方法及发送方法进行了说明，但本发明并不限定于该实施方式。只要不脱离本发明的主旨，对本实施方式实施了本领域技术人员想到的各种变形后的形态、将不同的实施方式的构成要素组合而构建的形态也可以包含在本发明的一个或多个技术方案的范围内。

产业上的可利用性

本发明能够适用于进行基于MPEG－DASH标准的流媒体数据的发送或接收的装置或设备。

标号说明

1 通信系统

10、10A 服务器

11 选择部

12 发送部

20、20A 客户端

30 通信网络

101 接收部

102 发送部

201 接收部

202 发送部

Claims (2)

1.一种客户端，遵循MPEG－DASH标准，其特征在于，具备：

发送部，向服务器发送包含推送指令的媒体表示描述即MPD的请求；以及

接收部，从上述服务器接收由上述MPD的请求指定的MPD及至少一个起始段；

上述发送部参照接收到的上述MPD，生成段请求；

上述发送部向上述服务器发送包含推送指令的上述段请求；

上述接收部从上述服务器接收由上述段请求指定的段、以及比该段靠后的由上述段请求中包含的推送指令指定的至少一个第2段；

上述至少一个起始段包含由上述服务器从与多个表现分别对应的多个起始段中选择的至少一个起始段；

上述MPD的请求中包含的推送指令和上述段请求中包含的推送指令中分别记述有定义了从上述服务器向上述客户端推送信息的策略的推送类型，并且上述MPD的请求中包含的推送指令表示除了上述至少一个起始段以外是否还推送媒体段。

2.一种接收方法，是遵循MPEG－DASH标准的客户端所实施的接收方法，其特征在于，包括：

发送步骤，向服务器发送包含推送指令的媒体表示描述即MPD的请求；以及

接收步骤，从上述服务器接收由上述MPD的请求指定的MPD及至少一个起始段；

在上述发送步骤中，

参照接收到的上述MPD，生成段请求；

向上述服务器发送包含推送指令的上述段请求；

在上述接收步骤中，从上述服务器接收由上述段请求指定的段、以及比该段靠后的由上述段请求中包含的推送指令指定的至少一个第2段；

上述至少一个起始段包含由上述服务器从与多个表现分别对应的多个起始段中选择的至少一个起始段；

上述MPD的请求中包含的推送指令和上述段请求中包含的推送指令中分别记述有定义了从上述服务器向上述客户端推送信息的策略的推送类型，并且上述MPD的请求中包含的推送指令表示除了上述至少一个起始段以外是否还推送媒体段。

Images