CN108605154B - 一种消息交互的方法和客户端设备 - Google Patents

一种消息交互的方法和客户端设备 Download PDF

Info

Publication number
CN108605154B
CN108605154B CN201780009115.9A CN201780009115A CN108605154B CN 108605154 B CN108605154 B CN 108605154B CN 201780009115 A CN201780009115 A CN 201780009115A CN 108605154 B CN108605154 B CN 108605154B
Authority
CN
China
Prior art keywords
media
parameter
list
segment
value
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
CN201780009115.9A
Other languages
English (en)
Other versions
CN108605154A (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.)
MediaTek Inc
Original Assignee
MediaTek Inc
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 MediaTek Inc filed Critical MediaTek Inc
Publication of CN108605154A publication Critical patent/CN108605154A/zh
Application granted granted Critical
Publication of CN108605154B publication Critical patent/CN108605154B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • 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
    • H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • H04L47/365—Dynamic adaptation of the packet size
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • 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/25—Management 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
    • 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/647—Control 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/64746—Control signals issued by the network directed to the server or the client
    • 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
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明公开了一种消息交互的方法和系统，其用于控制与使用DASH从服务器到客户端的多媒体流服务相关的流程。在一种方法中，一个或多个推送指令从客户端发送至服务器，以指示与所请求的媒体数据相关的信息。至少一个所选择的推送指令使用包括媒体参数值的列表的一个URL模板，以及其中每个媒体参数值对应与所请求的一个媒体段相关的一个媒体参数。随后，服务器根据媒体参数值的列表向客户端推送用于所请求的媒体数据的一个或多个数据组。在另一方法中，至少一个所选择的推送指令使用包括表示与请求的多个媒体段相关的多个媒体参数值的重复差数的第一数的一个URL模板。

Description

一种消息交互的方法和客户端设备
优先权声明
本申请要求在2016年02月03日提出申请号为62/290,494的美国临时专利申请、在2016年02月18日提出申请号为62/296,628的美国临时专利申请以及在2016年05月24日提出申请号为62/340,614的美国临时专利申请的优先权。上述申请整体以引用方式并入本文中。
技术领域
本发明涉及互联网上的媒体流。具体地，本发明涉及一种方法及系统，其提高与使用关于全双工协议(Full-duplex Protocols，FDP)的基于超文本传输协议的动态自适应流(Dynamic Adaptive Streaming over HTTP，DASH)的媒体流相关的消息交互的效率。
背景技术
超文本传输协议(HyperText Transfer Protocol，HTTP)为一标准集合，其允许万维网(World Wide Web)的用户交互网页(web page)上找到的信息。它已成为当今互联网访问的事实上的标准。来自各种开发人员的浏览器均支持HTTP作为通信协议，以将客户端连接到互联网上的Web服务器。通过HTTP，用户与服务器之间的连接可以被建立，使得超文本标记语言(HyperText Markup Language，HTML)也可以被发送至用户的浏览器。这个协议也可以用于从服务器下载文件到浏览器或者使用HTTP的任何其他请求应用。
近年来，互联网上的视频流已成为一个重要应用。目前，视频流有助于互联网流量最大化。各种多媒体流协议已被广泛地使用，且这些协议中的一些是基于HTTP的。DASH，也称为MPEG-DASH，是一种自适应比特率流技术，其使得能够基于传统的HTTP网络服务器在互联网上传输媒体内容。
基于全双工兼容HTTP协议的媒体服务的整体流程如下。客户端和服务器首先初始化媒体通道，其中，如由HTTP/2服务器推送或WebSocket消息传递所使能，服务器可以主动地向客户端推送数据。该通道是通过HTTP/1.1协议升级机制建立的。在升级之后，DASH客户端通过URL(Universal Resource Locator，通用资源定位符)和“推送策略”，向服务器请求媒体或媒体呈现描述(Media Presentation Description，MPD)。该策略通知服务器客户端希望媒体传输如何发生(由服务器初始化或由客户端初始化)。一旦服务器接收到该请求，其会用所请求的数据进行响应并初始化推送策略中定义的推送周期。
图1示出了使用服务器推送的视频流的整体流程的示例，其中，方框110对应于客户端侧所发生的动作，方框120对应于服务器侧所发生的动作。在步骤111中，客户端向服务器发送MPD请求。在步骤121中，服务器接收MPD请求，并在步骤122中通过发送MPD来响应。在步骤112中，客户端接收新的MPD，并在步骤113中请求段(segment)。在步骤123中，服务器接收段请求，并在步骤124中向客户端发送段。在步骤114中，客户端接收段，并在步骤115中播放视频数据。如果客户端希望播放更多的媒体数据，则客户端可以返回到步骤111以请求MPD，并且服务器也将返回步骤121以接收MPD请求。推送策略是使用“推送指令(pushdirective)”来发信的。推送指令有一种类型，且基于该类型，可以有一个或多个与之相关的额外参数。例如，具有额外参数的推送类型如下所示：
PUSH_DIRECTIVE＝PUSH_TYPE“，”PUSH_PARAMS。
一种类型的推送指令，即“推送-模板”，其使用URL模板作为其参数来描述特定URL集合，被考虑用于推送。客户端可以使用模板来显性地发信在推送交易期间待推送的段。当全部被评估时，整个的URL列表描述了该推送交易内待推送的段的序列。推送模板的URL模板中定义了三种类型的子句变量(Clause Variable)：{ID}、{Number}以及{Time}。
子句变量{ID}指定根据表示(representation)ID不同的URL范围，且可以使用所提供的范围变量进行扩展。
子句变量{Number}指定根据段编号不同的URL范围。服务器生成由范围变量所提供的范围(包括两端点)中的每个段编号的URL。通过为每个段确定的URL，服务器将能够向客户端推送所请求的段数据。
子句变量{Time}指定根据段时间不同的范围或URL。将为每个后续段生成URL，直至段时间(即，第一帧的呈现时间)超过由时间变量所提供的指示时间。
DASH第6部分FDH的当前工作草案，即W15685(V.Swaminathan，K.Streeter，I.Bouazizi，and F.Denoual，“Working Draft for 23009-6:DASH over Full DuplexHTTP-based Protocols(FDH)”，MPEG#113，Geneva，Document:W15685，Oct.2015)有关于使用URL模板的推送模板的以下未解决的问题。
A.处理编号值的列表
当前URL模板语法不能有效地表示具有非连续地址编号的段。例如，如果客户端请求段编号25、段编号50、段编号75和段编号100，则URL模板将为如下所示：
·“../rep1/segment{Number}”:{25-25}:{50-50}:{75-75}:{100-100}
换而言之，段必须被指定为范围，即使其表示四个单个的非连续地址编号。在MPEG输入文件M37432(L.Liu，X.Zhang，and Z.Guo，“Comments on DASH-FDH URL Templates”，MPEG#113，Geneva，Document:M37432，Oct.2015)中所呈现的另一示例中，URL模板将为如下所示：
http://cdn1.example.com/SomeMovie/180180.mp4v
http://cdn1.example.com/SomeMovie/360360.mp4v
http://cdn1.example.com/SomeMovie/540540.mp4v
http://cdn1.example.com/SomeMovie/720720.mp4v
在上述示例中，四个电影段的URL必须被指定为如下所示的单个的范围，即使其表示四个单个的非连续地址编号。
“http://cdn1.example.com/SomeMovie/{Number}.mp4v”:
{180180-180180}:{360360-360360}:{540540-540540}:{720720-720720}
B.处理基于段时间线(SegmentTimeline)的段URL
在当前URL模板中，{Time}参数指定将为每个后续段生成URL，直至段时间超过指示时间。然而，如FDH工作草案W15685中所述，可能存在限制：
“注意(来自MPEG#113)：可能存在URL模板无法处理推送模
板的实例，尤其是当参数是用TIME表达的，且MPD将段URL描
述为基于具有持续时间的段时间线(SegmentTimeline)的模板
URL，该持续时间在段之间不恒定。”
来自DASH第1部分规范，W15686(“Draft Text of ISO/IEC 23009-1 3rdEdition”，Geneva，Document:W15686，Oct.2015)，当MDP描述基于段时间线的段URL时，通过用从段时间线中获得的最早呈现时间来替换$Time$标识符，以获得媒体段的段URL。客户端可以通过解析MPD并执行替换以构建URL列表，例如：
http://mvsite.com/MovieC/rep1/15000.mp4v
http://mvsite.com/MovieC/rep1/25000.mp4v
http://mvsite.com/MovieC/rep1/30000.mp4v
http://mvsite.com/MovieC/rep1/35000.mp4v
如DASH第1部分W15686中所指定，URL地址中的值15000、值25000、值30000和值35000是从段时间线中获得的最早呈现时间。使用当前URL模板，这类URL是无法有效表示的。
C.处理表示切换(Representation switching)
在某些实例中，为了从当前表示中获取目标表示，如M36570(C.Liu，S.Liu，andS.Lei，“Push Representation switch strategy over full duplex protocols”，MPEG#112，Warsaw，Document:M36570，Jun.2015)中所指定，来自中间表示的段必须被传输至客户端。例如，段请求为“../rep1/segment3.mp4”，推送指令可以请求来自rep2和rep4中的每个的一个段，然后请求目标rep7。值得注意的是，在上述中，所涉及的表示无需具有连续表示ID编号。在当前FDH工作草案W15685中，可以通过以下两种方式指定这类推送指令：
·“../rep{ID}/segment{Number}”:{2，4-4}:{4，5-5}:{7，6-6}，或
·“../rep2/segment4.mp4”:{}，“../rep4/segment5.mp4”:{}，
“../rep7/segment6.mp4”:{}
两个URL模板表示都不是有效的。此外，当前URL模板表示既不能有效地支持具有给定表示中的非连续段编号的表示切换，也不能有效地支持具有基于段时间线的URL地址的表示切换。
D.处理URL地址中的编号列表和时间值
在DASH第6部分FDH，即W15685的工作草案中，不允许单个值列表、编号和/或时间戳。即使单个值列表、编号和/或时间戳可以由新的语法结构使能，其可能仍需要进一步改进语法表示。例如，客户端可能请求具有重复相等距离的较长的段列表，例如段编号25、段编号50、段编号75、段编号100、段编号125、段编号150、段编号175、段编号200、段编号225等。又例如，客户端可能请求具有基于时间的URL寻址的段，即10000、15000、20000、25000、30000、35000、40000、45000等。需要开发新的消息传递技术以提高消息传递效率。因此，非常需要使能用于这些实例的更紧凑的表示的语法结构。
发明内容
本发明公开了一种消息交互的方法和系统，用于控制与使用DASH从服务器到客户端的多个多媒体流服务相关的流程。根据该方法，由客户端向服务器发送的一个或多个推送指令，以指示与所请求的媒体数据相关的信息。至少一个所选的推送指令使用包括媒体参数值的列表的一个URL模板，以及其中每个媒体参数值对应与所请求的一个媒体段相关的一个媒体参数。服务器随后根据媒体参数值的列表向客户端推送所请求的媒体数据的一个或多个数据组。客户端随后播放接收到的媒体数据的一个或多个数据组。
媒体参数列表可以表示从包括参数{Number}、参数{Time}、参数{ID}和参数{Timestamp}的组中选择的一个或多个媒体参数。在一实施例中，每个媒体参数值对应于参数{Number}，以指示与一个媒体段相关的段编号。在服务器侧，服务器将生成对应于媒体参数值的列表中的一个值的每个段编号的URL。可选地，服务器可以通过使用媒体参数值的列表中的每个值来替换{Number}，以生成每个段的URL。
在另一实施例中，每个媒体参数值对应于参数{Timestamp}，以向服务器指示通过使用媒体参数值的列表中的每个值来替换{Timestamp}，以生成每个段的URL。在又一实施例中，每个媒体参数值对应于参数{Time}，并且一符号以指示指定用于参数{Time}的一个或多个值是用于时间范围或时间戳列表的，其中，符号可以对应于字符“-”。对于每个媒体参数值对应于参数{Time}，服务器通过使用每个媒体参数值来替换{Time}，以生成每个段的URL。
在一实施例中，媒体参数值的列表属于不同的媒体参数，并且不同的媒体参数由分隔符分隔，例如竖条字符“|”。在这种情况中，对于每个指定的表示ID，如果一个或多个指示的媒体参数存在，则多个URL被生成以用于一个或多个指示的媒体参数的所有媒体参数值，其中，一个或多个所指示的媒体参数属于包括参数{Number}、参数{Timestamp}和参数{Time}的组。媒体参数值的列表可以包括用于参数{ID}的值范围、值列表中至少一个的多个第一值和用于另一媒体参数的多个第二值。在这种情况中，对于每个指定的表示ID，如果参数{Number}、参数{Timestamp}或参数{Time}存在，则相应的值或范围被指定以用于参数{Number}、参数{Timestamp}或参数{Time}。媒体参数值的列表可以包括用于参数{ID}的多个列表值，以指示与用于参数{ID}的两个或多个列表值相关的多个表示之间的表示切换。
在又一实施例中，URL模板还包括第一推送参数，以指示媒体参数值的列表是否被压缩。如果第一推送参数指示媒体参数值的列表被压缩，则URL模板还包括第二推送参数，以指示选择用于压缩媒体参数值的列表的字符串压缩处理。在另一实施例中，URL模板还包括推送参数，以指示选择用于压缩媒体参数值的列表的字符串压缩处理或没有压缩处理用于媒体参数值的列表。
本发明公开了另一种消息交互的方法和系统，用于控制与使用DASH从服务器向客户端的多媒体流服务相关的流程。根据该方法，从客户端向服务器发送一个或多个推送指令，以指示与所请求的媒体数据相关的信息，其中至少一个所选择的推送指令使用一个URL模板，该一个URL模板包括表示与请求的多个媒体段相关的多个媒体参数值的重复差数的第一数。根据与请求的多个媒体段相关的多个媒体参数值，服务器向客户端推送所请求的媒体数据的一个或多个数据组。客户端随后播放接收到的媒体数据的一个或多个数据组。URL模板还可以包括指示起始媒体参数值的第二数和指示多个媒体参数值的重复差的第三数。
附图说明
图1示出了使用服务器推送的视频流的整体流程的示例，其中，在服务器和客户端之间使用通信程序集合以进行媒体流。
图2示出了根据本发明一实施例的包括对常规URL模板所做出的改变的URL模板的示例。
图3示出了根据本发明另一实施例的包括对常规URL模板所做出的改变的URL模板的示例。
图4示出了根据本发明又一实施例的包括对常规URL模板所做出的改变的URL模板的示例。
图5示出了根据本发明一实施例的包括消息交互的系统的示例性流程图，其中消息交互用于控制与使用DASH从服务器到客户端的多媒体流服务相关的流程。
图6示出了根据本发明另一实施例的包括消息交互的系统的示例性流程图，其中消息交互用于控制与使用DASH从服务器到客户端的多媒体流服务相关的流程。
具体实施方式
以下描述为实施本发明的最佳方式。本描述的目的在于阐释本发明的一般原理，并非起限定意义。本发明的保护范围当视权利要求书所界定为准。
如前所述，现有的流媒体协议具有一些缺点，其影响了流的消息传递的效率。因此，本发明公开了克服这些缺点的技术。
在本发明的一个方面，公开了对工作草案的修改以旨在使能以下：
A.URL地址的值的显性列表的紧凑表示，例如{Number}、{Time}
或{Timestamp}。
B.基于段时间线的URL的显性列表的紧凑表示。
C.包括条目A和条目B的能力的表示切换。
上述修改可以被实现，而不是修改某些参数或者为URL模板引入新的参数。下面讨论根据本发明的各种实施例的具体说明。在本发明中，这些参数也称为媒体参数(mediaparameter)。
值列表(编号或时间/时间戳)的URL模板
根据此方法，允许参数{Number}的值列表的紧凑表示。例如，先前指定的推送指令可以被修改为：
a.“../rep1/segment{Number}”:{25，50，75，100}，以及
b.“http://cdn1.example.com/SomeMovie/{Number}.mp4v”:{180180，360360，540540，720720}。
如示例a所示，修改后的推送指令允许为表示(即rep1)所发信的多个非连续段(即25、50、75和100)。在示例b中，修改后的推送指令可以使用单个URL模板。因此，根据此方法的URL模板允许推送指令的有效发信。值得注意的是，用于包括参数{ID}和参数{Number}的推送模板需要额外考虑。目前，如果两个参数均存在，则符号“，”用于分隔这两个参数类型的值，例如{ID，Number}:{2，5-7}。将在后续部分中讨论关于此的更多。
具有基于段时间线的段URL的URL模板
为了支持基于段时间线的段URL，其中URL地址为从段时间线中获得的最早呈现时间，公开了一种用于扩展或使用如上讨论的值列表的相似语法结构的方法，以用于处理时间戳列表。其可以是与{Number}相同的参数类型，或者引入另一个参数{Timestamp}，例如：
·“http://mvsite.com/MovieC/rep1/{Number}.mp4v”:{15000，25000，30000}，
或
·“http://mvsite.com/MovieC/rep1/{Timestamp}.mp4v”:{15000，25000，30000}
上述修改提供了具有从段时间线中获得的基于时间寻址的显性URL列表。因此，服务器不需要解析MPD。同样地，当时间戳URL列表与参数{ID}在推送-模板中一起使用时，需要额外考虑。后续将讨论关于此的更多。
在上述示例之一中，参数{Number}用于表示URL列表中的呈现时间。换而言之，对于值列表，获取URL地址的拓展是相同的，而无论底层值是用于编号还是用于时间戳的。因此，编号和时间戳的参数可以在列表中互相交换。不需要区分该值是用于段编号还是用于时间的。
在另一示例中，URL模板可以通过指定在参数{Time}下的时间戳列表来构建，而不是在参数{Number}下或在新参数{Timestamp}下。
具有重复值差(repeated value difference)的值列表
公开了两种用于具有重复差的值的紧凑表示的方法。
第一种方法引入分隔符(delimiter)以指示指定“值的差”而不是“值”本身的子序列值。
·“../rep1/segment{Number}”:{25；5；10}//Starting value，difference，repeat
在此示例中，符号“；”用作分隔符，值25为第一URL地址值，位于分隔符“；”之后的值“5”为待添加以产生下一值的值差，值10指示待重复的次数，即{25，30，35，40，45，50，55，60，65，70，75}。
在另一示例中，通过发信末端值来构建URL模板，而不是指定重复次数，以表示{25，30，35，40，45，50，55，60，65，70，75}。
·“../rep1/segment{Number}”：{25；5；75}//Starting value，difference，endvalue
第二种方法引入一种包含具有重复差的值的格式，而不引入额外的分隔符。
·“../rep1/segment{Number}”：{(25，5，10)}//Start value，difference，repeat
在此示例中，具有括号对“(”和“)”的三个值指定了起始值、差和重复的次数。一旦遇到符号“(”，拓展流程就了解该格式，从而不需要使用不同的分隔符来分隔值和差。
在另一示例中，通过发信末端值来构建URL模板，而不是指定重复次数。
·“../rep1/segment{Number}”:{(25，5，75)}//Start value，difference，endvalue
只要符号不引起歧义，其他符号可以用作第一种方法的分隔符。除了括号对“(”和“)”之外，只要符号不会导致歧义，其他符号对也可以用于包含值和差。例如，括号对“[”和“]”可用作分隔符对。
处理表示切换
为了方便使用具有参数{ID}和段列表的推送-模板，根据本发明，公开了一种使用分隔符来清楚地分隔指定用于不同参数的单个值的方法。例如，如果选择“|”作为分隔符，则可以使用以下来指定表示改变(即表示切换)，其中，可以请求来自每个表示的多个非连续段：·a.“../rep{ID}/segment{Number}”:{2|4}:{4|5}:{7|6}
这可表示如下：
../rep2/segment4，../rep4/segment5，../rep7/segment6
·b.“../rep{ID}/segment{Number}”:{2|8，16，24}:{4|32，40}:{7|48}
这可表示如下：
../rep2/segment8，../rep2/segment16，../rep2/segment24，
../rep4/segment32，../rep4/segment40，
../rep7/segment48，
使用推送-模板，具有基于段时间线的URL的表示切换也可以被显性地指定：
·“../rep{ID}/{Number}”:
{2|15000，25000，30000}:{4|35000，40000，50000}:{7|60000，65000}
或
·“../rep{ID}/{Timestamp}”:
{2|15000，25000，30000}:{4|35000，40000，50000}:{7|60000，65000}
这两个示例都可以表示如下：
../rep2/15000，../rep2/25000，../rep2/30000，
../rep4/35000，../rep4/40000，../rep4/50000，
../rep7/60000，../rep7/65000
URL地址中的值是客户端从段时间线中获得的最早呈现时间。
对于具有重复差的值列表：
·“../rep{ID}/segment{Number}”:{2|8；8；5}:{4|48；8；5}
或
·“../rep{ID}/segment{Number}”:{2|(8，8，5)}:{4|(48，8，5)}
这两个示例都可以表示如下：
../rep2/segment8，../rep2/segment16，../rep2/segment24，../rep2/segment32.
./rep2/segment40，
../rep4/segment48，../rep4/segment56，../rep4/segment64，../rep4/segment7
2，../rep4/segment80，
在上述示例中，段编号8、段编号16、段编号24、段编号32和段编号40均来自rep2，段48、段56、段64、段72和段80均来自rep4。
在指定时间值的另一示例中，客户端从段时间线中获取时间值。
·“../rep{ID}/{Number/Timestamp}”:{2|10000；5000；5}:{4|35000；5000；5}
或
·“../rep{ID}/{Number/Timestamp}”:{2|(10000，5000，5)}:{4|(35000，5000，5)}
这两个示例都可以表示如下：
../rep2/10000，../rep2/15000，../rep2/20000，../rep2/25000，../rep2/30000，
../rep4/35000，../rep4/40000，../rep4/45000，../rep4/50000，../rep4/55000，
在上述示例中，段地址10000、段地址15000、段地址20000、段地址25000和段地址30000均来自rep2，段地址35000、段地址40000、段地址45000、段地址50000和段地址55000均来自rep4。
实施例策略A
为了实现上述公开的能力，此策略的实施例将“值列表”变量、{Timestamp}参数变量和分隔符引入到FDH工作草案中。例如，URL模板可以被修改成如图2所示，其中，从常规URL模板所做出的改变被突出显示为粗体文本。例如，在图2中，如标号210所示，新的子句变量{Timestamp}(即CLAUSE_VAR_TIMESTAMP)被引入。如标号220所示，是{Timestamp}的格式。如标号230所示，竖条字符“|”被用作分隔符。如标号240所示，是“VAL_LIST”的格式。
每个模板条目被形成为包括相对于正被请求的段的参数化的宏的URL。
{number}参数被用于指定根据段编号不同的URL的范围。使用所提供的范围变量或所提供的VAL_LIST变量来拓展{number}参数。参数{Timestamp}用于指定根据段时间不同的URL的范围。使用所提供的VAL_LIST变量来拓展参数{Timestamp}。参数{Time}用于指定根据段时间不同的URL的范围。使用所提供的时间变量来扩展参数{Time}。参数{ID}用于指定根据表示ID不同的URL的范围。使用所提供的范围变量来扩展参数{ID}。
模板可以包括如下中的一个：参数{number}、参数{Timestamp}或参数{Time}。
通过在服务器处评估所提供的参数，将从每个模板条目中生成URL列表。对于编号范围，服务器将生成所提供的范围(包括两端点)中的每个段编号的URL。对于编号值列表，服务器将生成值列表中显性提供的每个段编号的URL。对于时间戳值列表，通过用值列表中所显性提供的每个值来替换{Timestamp}，服务器将生成每个段的URL。对于时间范围，为每个后续段编号生成URL，直至段时间(即第一帧的呈现时间)超过指示时间。
按照定义明确的顺序扩展参数，以防止在模板扩展中的任何歧义。对于指定范围中的每个表示ID，如果其存在于如指定的位于分隔符“|”之后，则URL被生成，以用于指示的参数{Number}，{Timestamp}或{Time}的所有值。换而言之，{ID}扩展表示扩展处理的“外环(outer loop)”。
在另一实施例中，通过扩展参数{Number}的使用，可以构建URL模板，以在使用VAL_LIST的URL中指定时间戳。本实施例无需引入新参数{Timestamp}。
在又一实施例中，参数的值可以是单个值、值列表和值范围的混合。
在上述示例中，用于分隔VAL_LIST中的值的分隔符“，”和用于分隔不同参数的值的分隔符“|”仅是根据本发明实施例的示例。其他符号也可以被使用以构造无歧义的参数值。
根据本发明实施例的更多示例如下所示。
a.具有段编号地址列表的推送模板的示例
此示例示出了与采用段编号寻址的URL一起使用的推送模板。此示例示出了段编号25、编号50和编号75的推送序列。请注意，URL中的相对寻址被使用。
·“../rep1/segment{Number}.mp4”:{25，50，75}
这可表示如下：
../rep1/segment25.mp4，../rep1/segment50.mp4，../rep1/segment75.mp4
b.具有基于段时间线的段寻址的推送模板的示例
此示例示出了与在MPD中使用段时间线所描述的UPL一起使用的推送模板。此示例示出了段URL地址15000、URL地址25000、URL地址30000和URL地址35000的推送序列。请注意，URL中的相对寻址被使用。
·“../rep1/{Timestamp}.mp4”:{15000，25000，30000，35000}
这可表示如下：
../rep1/15000.mp4，../rep1/25000.mp4，../rep1/30000.mp4，../rep1/35000.mp4
在上述示例中，URL地址中的值15000、值25000和值30000均为客户端从段时间线中获取的最早呈现时间。
c.具有表示ID和编号寻址的推送模板的示例
此示例示出了推送来自不同表示的段的推送模板。此示例示出了推送序列推送来自表示1的段1-段4，接着推送来自表示2的段5-段7。
·“../rep{ID}/segment{Number}”:{1|2-4}:{2|5-7}
这可表示如下：
../rep1/segment2，../rep1/segment3，../rep1/segment4
../rep2/segment5，../rep2/segment6，../rep2/segment7
d.具有多个表示的推送模板的示例
此示例示出了推送来自不同表示的段的推送模板。此示例示出了一推送序列，其将导致来自不同表示(即分别为表示ID 2、4和7)的段2-4的推送。请注意，URL中的相对寻址被使用。
·“../rep{ID}/segment{Number}”:{2|2}:{4|3}:{7|4}
这可表示如下：
../rep2/segment2，../rep4/segment3，../rep7/segment4
e.具有多个表示和编号地址列表的推送模板的示例
此示例示出了推送来自不同表示的段的推送模板。此示例示出了一推送序列，其将导致来自表示2的段编号8、段编号16和段编号24，来自表示4的段32和40以及来自表示7的段48的推送。请注意，URL中的相对寻址被使用。
·“../rep{ID}/segment{Number}”:{2|8，16，24}:{4|32，40}:{7|48}
这可表示如下：
../rep2/segment8，../rep2/segment16，../rep2/segment24，
../rep4/segment32，../rep4/segment40，
../rep7/segment48，
f.具有多个表示和基于段时间线的地址的推送模板的示例
此示例示出了推送来自不同表示的段的推送模板。此示例示出了一推送序列，其将导致来自表示2的URL地址15000，25000和30000，来自表示4的URL地址35000，40000和40000，以及来自表示7的URL地址60000和65000的推送。请注意，URL中的相对寻址被使用。
·“../rep{ID}/{Timestamp}”:{2|15000，25000，30000}:{4|35000，40000，50000}:{7|60000，65000}
这可表示如下：
../rep2/15000，../rep2/25000，../rep2/30000，
../rep4/35000，../rep4/40000，../rep4/50000，
../rep7/60000，../rep7/65000
在上述示例中，URL地址的值均为客户端从段时间线中获取的最早呈现时间。
实施例策略B
根据本策略的实施例，通过扩展{time}参数的使用来构建URL模板，以覆盖两个时间范围作为当前FDH规范和时间戳列表(即本发明中的VAL_LIST)。这是通过使用符号“-”作为标识以在时间范围和时间戳列表之间进行区分来实现的。例如，URL模板可以被修改成如图3所示，其中，从常规URL模板所做出的改变被突出显示为粗体文本。例如，在图3中，如标号310所示，竖条字符“|”被用作分隔符。如标号320所示，是“VAL_LIST”的格式。参数{Time}可以由末端值(例如“-”INTEGER)或时间列表(即VAL_LIST)来表示。
每个模板条目被形成为包括相对于正被请求的段的参数化的宏的URL。参数{number}被用于指定根据段编号不同的URL范围。使用所提供的范围变量或所提供的VAL_LIST变量来扩展参数{number}。参数{Time}用于指定根据段时间不同的范围或URL。使用所提供的时间变量来扩展参数{Time}。参数{ID}用于指定根据表示ID不同的URL的范围。使用所提供的范围变量来扩展参数{ID}。
模板可以包括参数{number}或者参数{Time}，但不同时包括这两个。通过评估所提供的参数，将从每个模板条目中生成URL列表。对于编号范围，服务器将生成所提供的范围(包括两端点)中的每个段编号的URL。对于编号值列表，服务器将生成值列表中显性提供的每个段编号的URL。对于使用符号“-”INTEGER所指定的时间范围，为每个后续段编号生成URL，直至段时间(即第一帧的呈现时间)超过指示时间。对于使用VAL_LIST所指定的时间值列表，通过使用值列表中所显性提供的每个值来替换{Time}，服务器将生成每个段的URL。
按照定义明确的顺序扩展参数，以防止模板扩展中的任何歧义。对于指定范围内的每个表示ID，如果其存在于如指定的位于分隔符“|”之后，则URL被生成，以用于指示的参数{Number}或{Time}的所有值。换而言之，{ID}扩展表示扩展处理的“外环”。
在其他实施例的示例中，参数的值可以是单个值、值列表和值范围的混合。用于分隔VAL_LIST中的值的分隔符“，”和用于分隔不同参数的值的分隔符“|”仅是根据本发明实施例的示例。其它符号也可以用于构造无歧义的参数值。
根据本发明实施例的更多示例如下所示。为实施例策略A所呈现的一些示例也适用于实施例策略B。因此，如下仅列出与实施例策略A不同的示例。
a.具有基于时间的寻址的推送模板的示例
此示例示出了与采用基于时间的寻址的URL一起使用的推送模板。此示例示出了结束于呈现时间10000的推送序列。请注意，URL中的相对寻址被使用。
·“../rep1/segment{Time}.mp4”:{-10000}
b.具有基于段时间线的段寻址的推送模板的示例
此示例示出了与在MPD中使用段时间线所描述的UPL一起使用的推送模板。此示例示出了段URL地址15000、URL地址25000、URL地址30000和URL地址35000的推送序列。请注意，URL中的相对寻址被使用。
·“../rep1/{Time}.mp4”:{15000，25000，30000，35000}
这可表示如下：
../rep1/15000.mp4，../rep1/25000.mp4，../rep1/30000.mp4，../rep1/35000.mp4
在上述示例中，URL地址中的值15000、值25000和值30000均为客户端从段时间线中获取的最早呈现时间。
在实施例策略A和实施例策略B中的分隔符(例如“|”)的使用还可以被归一化，使得{ID}的参数值也可以是一个范围、一个值或为空。例如，如下可选表示(alternativerepresentation)可以被使用：
a.指示ID为固定的空ID值
·“../rep1/segment{Number}.mp4”:{|25，50，75}
这可表示如下：
../rep1/segment25.mp4，../rep1/segment50.mp4，../rep1/segment75.mp4
·“../rep1/segment{Timestamp}.mp4”:{|15000，25000，30000，35000}
这可表示如下：
../rep1/segment15000.mp4，../rep1/segment25000.mp4，
../rep1/segment30000.mp4，../rep1/segment35000.mp4
b.ID的范围或值列表
·“../rep{ID}/segment{Number}”:{1-2|2-4，5-7}
这可表示如下：
../rep1/segment2，../rep1/segment3，../rep1/segment4
../rep2/segment5，../rep2/segment6，../rep2/segment7
·“../rep{ID}/segment{Number}”:{2，4，7|2，3，4}
这可表示如下：
../rep2/segment2，../rep4/segment3，../rep7/segment4
·“../rep{ID}/segment{Number}”:{2|8，16，24}:{4|32，40}:{7|48}
这可表示如下：
../rep2/segment8，../rep2/segment16，../rep2/segment24，
../rep4/segment32，../rep4/segment40，
../rep7/segment48，
·“../rep{ID}/{Timestamp}”:{2|15000，25000，30000}:{4|35000，40000，50000}:{7|60000，65000}
这可表示如下：
../rep2/15000，../rep2/25000，../rep2/30000，
../rep4/35000，../rep4/40000，../rep4/50000，
../rep7/60000，../rep7/65000
·“../rep{ID}/segment{Timestamp}.mp4”:{1-3|500-1000，2000-3000，15000-35000}
这可表示如下：
具有500-1000之间的时间戳值的表示1(rep1)中的段，
具有2000-3000之间的时间戳值的表示2(rep2)中的段，
具有15000-35000之间的时间戳值的表示3(rep3)中的段，
·“../rep{ID}/segment{Time}.mp4”:{1-3|-1000，-3000，-35000}
这可表示如下：
具有小于1000的时间戳值的表示1(rep1)中的段，
具有1000-3000之间的时间戳值的表示2(rep2)中的段，
具有3000-35000之间的时间戳值表示3(rep3)中的段，
实施例策略C
根据本策略的实施例，通过将“值列表”变量和“具有相同差的值列表”变量引入到FDH工作草案来构建URL模板。例如，URL模板可以修改成如图4所示，其中，从常规URL模板所做出的改变被突出显示为粗体文本。例如，在图4中，参数包括VAL_LIST和LIST_DIFF(即具有相同差的值列表)，其如标号410所示由竖条字符“|”作为分隔符进行分隔。“VAL_LIST”的格式如标号420所示，以及“LIST_DIFF”的格式如标号430所示，其中，字符“，”被用作分隔符以分隔LIST_DIFF中的列表值。可选地，如标号440所示，字符“；”可以被用作分隔符以分隔LIST_DIFF中的列表值。如标号450所示，参数{Time}可以由起始值(即INTEGER”)表示。
通过评估所提供的参数，将从每个模板条目中生成URL列表。对于编号范围，这意味着生成所提供的范围(包括两端点)中的每个段编号的URL。对于值列表(即VAL_LIST)，这意味着通过使用值列表中显性提供的每个值来替换{Parameter(Time，Number，Timestamp)}以生成每个段的URL。对于具有相同差的值列表(即LIST_DIFF)，这意味着首先生成从起始值开始的值列表，添加该差以产生下一值，直到达到重复的次数(或直到超过末端值)。随后，通过使用第一步骤中获得的每个值来替换{Parameter(Time，Number，Timestamp)}，来生成每个段的URL。对于时间范围，为每个后续段生成URL，直到段时间(即第一帧的呈现时间)超过指示时间。
按照定义明确的顺序扩展参数，以防止模板扩展中的任何歧义。对于指定范围中的每个表示ID，如果其存在于如指定的位于分隔符“|”之后，则URL被生成，以用于指示的{Number}，{Timestamp}或{Time}参数的所有值。换而言之，{ID}扩展表示扩展处理的“外环”。
URL列表值，表示切换
用特定URL地址请求多个段的最通用方法是使用URL列表作为URL模板的特定示例。例如，可以用编号值来指定URL列表。
·“../rep1/segment25.mp4”，“../rep1/segment50.mp4”，
“../rep1/segment75.mp4“
例如，可以用段时间来指定URL列表：
·“../SomeMovie/rep1/15000.mp4v”，“../SomeMovie/rep1/25000.mp4v”，
“../SomeMovie/rep1/30000.mp4v”.
又例如，可以使用表示切换来指定URL列表：
·“../rep1/segment2.mp4”，“../rep1/segment3.mp4”，“../rep2/segment4.mp4“
对于紧凑表示，也可以使用具有宏扩展的URL模板来实现前述示例，例如：
·“../rep1/segment{}.mp4”:{25，50，75}
·“../SomeMovie/rep1/{}.mp4v”:{15000，25000，30000}
·“../rep{}/segment{}.mp4”:{1|2，3}:{2|4}
观察到URL模板的关键是仅指定参数(即表示、段编号、时间等)的值，而URL的公共部分仅被发信一次。相同的精神也可以在字符串压缩方法中找到，其清除重复的字符串。因此，除了URL模板的使用之外，本发明还公开了具有压缩的URL列表。表1示出了根据本发明实施例的具有压缩的URL列表的示例。
表1
Figure GDA0001748768410000201
在上述示例中，对于推送类型push-urllist，1比特二进制值C先被发信以指示压缩是否用于后续URL列表。如果C的值为0，则下一个参数将为URL列表，其显性指定所请求的段的每个URL。如果C的值为1，则下一个参数将为k比特值N，其指定用于压缩后续URL列表的压缩方法。例如，如果k等于2，值00、值01、值10和值11可用于指示不同的压缩方法。如表2所示，常见的字符串压缩方法，例如DEFLATE(IETFRFC1951)、HPACK(IETFRFC7541头压缩)、LZ等，可被选择。下一个参数将为已压缩的URL列表，其显性指定所请求的段的每个URL。在接收到该推送类型和相应的参数时，服务器可以使用指定的压缩方法(例如，值N)来解压缩URL列表。
表2
N(2比特的示例) 压缩
00 DEFLATE
01 HPACK
10 LZMA
11 LZ77
表3示出了根据本发明实施例的具有压缩方法的URL列表的另一示例。
表3
Figure GDA0001748768410000211
Figure GDA0001748768410000221
在上述示例中，对于推送类型push-urllist，k比特字段值N首先被发信。其指定压缩是否被使用以及用于压缩URL地址的后续列表的压缩方法。例如，如表4所示，如果k等于2，值00、值01、值10和值11可用于指示四种不同的压缩方法。
表4
N(2比特的示例) 压缩
00 不压缩
01 DEFLATE
10 HPACK
11 LZMA
下一个参数将为已压缩的URL列表，其显性指定所请求的段的每个URL。在接收到该推送类型和相应参数时，服务器可以使用指定的压缩方法(值N)解压缩URL列表。
除了用于值N的固定长度编解码之外，还可以使用可变长度编码。不同示例示于表5至表8。
表5
N 压缩
1 DEFLATE
01 HPACK
001 LZMA
0001 LZ77
表6
N 压缩
0 DEFLATE
10 HPACK
110 LZMA
1110 LZ77
表7
N 压缩
0 不压缩
10 DEFLATE
110 HPACK
1110 LZMA
表8
Figure GDA0001748768410000231
Figure GDA0001748768410000241
图5示出了根据本发明一实施例的包括消息交互的系统的示例性流程图，其中消息交互用于控制与使用DASH从服务器到客户端的多媒体流服务相关的流程。本流程图中所示的步骤可以被实现为服务器侧和/或客户端侧处的一个或多个处理器(例如，一个或多个CPU)上可执行的程序代码。本流程图中所示的步骤也可以基于硬件而被实现，例如，用于执行本流程图中的步骤的一个或多个电子设备或者处理器。根据本方法，在步骤510中，客户端向服务器发送的一个或多个推送指令，以指示与所请求的媒体数据相关的信息，其中至少一个所选择的推送指令使用包括媒体参数值的列表的一个URL模板，其中每个媒体参数值对应于与所请求的一个媒体段相关的一个媒体参数。如本发明中所描述，媒体参数值的列表的使用允许URL模板以紧凑形式被发信。在步骤520中，根据媒体参数值的列表，对所请求的媒体数据，服务器向客户端推送一个或多个数据组。如本发明中所述，服务器将评估并将以紧凑形式发信的URL模板扩展到全URL地址，以定位待发送的段。随后，在步骤530中，客户端对接收到的媒体数据播放所述一个或多个数据组。
在图5中，根据本发明实施例的用于控制与多媒体流服务相关的流的消息交互步骤被公开以用于服务器侧和客户端侧。但是，在服务器侧和客户端侧中的每个的步骤可以被相应地识别。
图6示出了根据本发明另一实施例的包括消息交互的系统的示例性流程图，其中消息交互用于控制与使用DASH从服务器到客户端的多媒体流服务相关的流程。本流程图中所示的步骤可以被实现为服务器侧和客户端侧处的一个或多个处理器(例如，一个或多个CPU)上可执行的程序代码。本流程图中所示的步骤也可以基于硬件而被实现，例如，用于执行本流程图中的步骤的一个或多个电子设备或者处理器。根据本方法，在步骤610中，客户端向服务器发送一个或多个推送指令，以指示与所请求的媒体数据相关的信息，其中至少一个所选择的推送指令使用一个URL模板，该模板包括一第一数，用来表示一个与所请求的媒体段相关的媒体参数值的重复差数。如本发明中所描述，媒体参数值的列表与媒体参数值的重复差数的使用允许URL模板以紧凑形式被发信。在步骤620中，根据与所请求的媒体段相关的媒体参数值，对所请求的媒体数据，服务器推送的一个或多个数据组。如本发明中所述，服务器将评估并将以紧凑形式发信的URL模板扩展到全URL地址，以定位待发送的段。随后，在步骤630中，客户端对接收到的媒体数据播放所述的一个或多个数据组。
在图6中，根据本发明实施例的用于控制与多媒体流服务相关的流的消息交互步骤被公开以用于服务器侧和客户端侧。但是，在服务器侧和客户端侧中的每个的步骤可以被相应地识别。
本发明所示的流程图用于示出根据本发明实施例的用于媒体流的服务器与客户端之间的消息传递的示例。在不脱离本发明的精神的情况，本领域的技术人员可以修改每个步骤、重组这些步骤、将一个步骤进行分离或者组合这些步骤而实施本发明。
上述说明，使得本领域的普通技术人员能够在特定应用程序的内容及其需求中实施本发明。对本领域技术人员来说，所描述的实施例的各种变形将是显而易见的，并且本文定义的一般原则可以应用于其他实施例中。因此，本发明不限于所示和描述的特定实施例，而是将被赋予与本文所公开的原理和新颖特征相一致的最大范围。在上述详细说明中，说明了各种具体细节，以便透彻理解本发明。尽管如此，将被本领域的技术人员理解的是，本发明能够被实践。
如上所述的本发明的实施例可以在各种硬件、软件代码或两者的结合中实现。例如，本发明的实施例可以是集成在视频压缩芯片内的电路，或者是集成到视频压缩软件中的程序代码，以执行本文所述的处理。本发明的一个实施例也可以是在数字信号处理器(Digital Signal Processor，DSP)上执行的程序代码，以执行本文所描述的处理。本发明还可以包括由计算机处理器、数字信号处理器、微处理器或现场可编程门阵列(fieldprogrammable gate array，FPGA)所执行的若干函数。根据本发明，通过执行定义了本发明所实施的特定方法的机器可读软件代码或者固件代码，这些处理器可以被配置为执行特定任务。软件代码或固件代码可以由不同的编程语言和不同的格式或样式开发。软件代码也可以编译为不同的目标平台。然而，执行本发明的任务的不同的代码格式、软件代码的样式和语言以及其他形式的配置代码，不会背离本发明的精神和范围。
本发明以不脱离其精神或本质特征的其他具体形式来实施。所描述的例子在所有方面仅是说明性的，而非限制性的。因此，本发明的范围由附加的权利要求来表示，而不是前述的描述来表示。权利要求的含义以及相同范围内的所有变化都应纳入其范围内。

Claims (17)

1.一种消息交互的方法，其特征在于，所述方法用于控制与由客户端使用超文本传输协议上的动态自适应流而执行的多个多媒体流服务相关的流程，所述方法包括：
向服务器发送一个或多个推送指令，以指示与所请求的媒体数据相关的信息，其中，至少一个所选择的推送指令使用包括媒体参数值的列表的一个URL模板，以及其中，每个媒体参数值对应于与所请求的一个媒体段相关的一个媒体参数，所述媒体参数值的列表包括用于参数{ID}的至少一个第一媒体参数值，以及用于另一媒体参数的至少一个第二媒体参数值，并且所述至少一个第一媒体参数值与所述至少一个第二媒体参数值在同一子句中仅由第一分隔符来分隔，所述至少一个第二媒体参数值为使用第二分割符来分割的连续值或者不连续值，其中参数{ID}用于指定多媒体表示，所述另一媒体参数用于指定多媒体表示{ID}中的媒体段，其中一个多媒体表示{ID}对应该多媒体表示{ID}的多个媒体段；
根据所述媒体参数值的列表，对所请求的所述媒体数据，接收从所述服务器推送的一个或多个数据组；以及
对接收到的所述媒体数据，播放所述一个或多个数据组。
2.根据权利要求1所述的消息交互的方法，其特征在于，所述媒体参数值的列表表示从包括参数{Number}、参数{Time}、参数{ID}和{Timestamp}的组中选择的一个或多个媒体参数。
3.根据权利要求2所述的消息交互的方法，其特征在于，每个媒体参数值对应于参数{Number}，以指示与所述一个媒体段相关的段编号。
4.根据权利要求2所述的消息交互的方法，其特征在于，每个媒体参数值对应于参数{Timestamp}，以指示所述服务器通过使用所述媒体参数值的列表中的每个值来替换{Timestamp}，以生成每个段的URL。
5.根据权利要求2所述的消息交互的方法，其特征在于，每个媒体参数值对应于参数{Time}，并且一符号用于指示指定用于参数{Time}的一个或多个值是用于时间范围或时间戳列表的。
6.根据权利要求5所述的消息交互的方法，其特征在于，所述符号对应于字符“-”。
7.根据权利要求5所述的消息交互的方法，其特征在于，所述每个媒体参数值对应于参数{Time}以指示所述服务器通过使用所述每个媒体参数值来替换{Time}，以生成每个段的URL。
8.根据权利要求1所述的消息交互的方法，其特征在于，所述分隔符对应于竖条字符“|”。
9.根据权利要求1所述的消息交互的方法，其特征在于，对于每个指定的表示ID，如果一个或多个指示的媒体参数存在，则多个URL被生成以用于所述一个或多个指示的媒体参数的所有媒体参数值，其中，所述一个或多个指示的媒体参数属于包括参数{Number}、参数{Time}、参数{ID}和参数{Timestamp}的组。
10.根据权利要求1所述的消息交互的方法，其特征在于，对于每个指定的表示ID，如果参数{Number}、参数{Timestamp}或参数{Time}存在，则相应的值或范围被指定以用于参数{Number}、参数{Timestamp}或参数{Time}。
11.根据权利要求1所述的消息交互的方法，其特征在于，所述媒体参数值的列表包括用于参数{ID}的多个列表值，以指示与用于所述参数{ID}的两个或多个列表值相关的多个表示之间的表示变换。
12.根据权利要求1所述的消息交互的方法，其特征在于，
所述媒体参数值的列表包括多个段编号和多个段时间线，以用于所述服务器扩展一个或多个URL模板，以使用所述媒体参数值的列表来生成一个或多个URL地址，以及
用于所述多个段编号和所述多个段时间线的多个底层值是通过用所述媒体参数值的列表中的每个值替换每个参数的相同方式处理的。
13.根据权利要求1所述的消息交互的方法，其特征在于，
所述一个URL模板还包括第一推送参数，以指示所述媒体参数值的列表是否被压缩，以及
如果第一推送参数指示所述媒体参数值的列表被压缩，则所述一个URL模板还包括第二推送参数，以指示选择用于压缩所述媒体参数值的列表的字符串压缩处理。
14.根据权利要求1所述的消息交互的方法，其特征在于，所述一个URL模板还包括推送参数，以指示选择用于压缩所述媒体参数值的列表的字符串压缩处理或没有压缩处理用于所述媒体参数值的列表。
15.根据权利要求1所述的消息交互的方法，其特征在于，所述一个URL模板包括表示与请求的多个媒体段相关的多个媒体参数值的重复差数的第一数，所述一个URL模板还包括指示起始媒体参数值的第二数和指示所述多个媒体参数值的重复次数的第三数。
16.一种消息交互的方法，其特征在于，所述方法用于控制与由服务器使用超文本传输协议上的动态自适应流而执行的多个多媒体流服务相关的流程，所述方法包括：
从客户端接收一个或多个推送指令，以指示与所请求的媒体数据相关的信息，其中，至少一个所选择的推送指令使用包括多个媒体参数值的一个URL模板，其中每个媒体参数值对应于与所请求的一个媒体段相关的一个媒体参数，所述媒体参数值的列表包括用于参数{ID}的至少一个第一媒体参数值，以及用于另一媒体参数的至少一个第二媒体参数值，并且所述至少一个第一媒体参数值与所述至少一个第二媒体参数值在同一子句中仅由第一分隔符来分隔，所述至少一个第二媒体参数值为使用第二分割符来分割的连续值或者不连续值，其中参数{ID}用于指定多媒体表示，所述另一媒体参数用于指定多媒体表示中的媒体段，其中一个多媒体表示对应该多媒体表示的多个媒体段；以及
根据与请求的所述多个媒体段相关的所述多个媒体参数值，对所请求的所述媒体数据，向所述客户端推送一个或多个数据组，以通过所述客户端对接收到的所述媒体数据播放所述一个或多个数据组。
17.一种客户端设备，其特征在于，用于接收使用超文本传输协议上的动态自适应流的多个媒体服务，所述客户端设备包括一个或多个电子电路或处理器，用于：
向服务器发送一个或多个推送指令，以指示与所请求的媒体数据相关的信息，其中，至少一个所选择的推送指令使用一个URL模板，所述一个URL模板包括表示与请求的多个媒体段相关的多个媒体参数的媒体参数值，所述媒体参数值的列表包括用于参数{ID}的至少一个第一媒体参数值，以及用于另一媒体参数的至少一个第二媒体参数值，并且所述至少一个第一媒体参数值与所述至少一个第二媒体参数值在同一子句中仅由第一分隔符来分隔，所述至少一个第二媒体参数值为使用第二分割符来分割的连续值或者不连续值，其中参数{ID}用于指定多媒体表示，所述另一媒体参数用于指定多媒体表示中的媒体段，其中一个多媒体表示对应该多媒体表示的多个媒体段；
根据与请求的所述多个媒体段相关的所述多个媒体参数值，对所请求的所述媒体数据，从所述服务器接收一个或多个数据组；以及
对接收到的所述媒体数据，播放所述一个或多个数据组。
CN201780009115.9A 2016-02-03 2017-02-03 一种消息交互的方法和客户端设备 Active CN108605154B (zh)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201662290494P 2016-02-03 2016-02-03
US62/290,494 2016-02-03
US201662296628P 2016-02-18 2016-02-18
US62/296,628 2016-02-18
US201662340614P 2016-05-24 2016-05-24
US62/340,614 2016-05-24
PCT/CN2017/072817 WO2017133659A1 (en) 2016-02-03 2017-02-03 Method and system of push-template and url list for dash on full-duplex protocols

Publications (2)

Publication Number Publication Date
CN108605154A CN108605154A (zh) 2018-09-28
CN108605154B true CN108605154B (zh) 2022-02-25

Family

ID=59500114

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201780009115.9A Active CN108605154B (zh) 2016-02-03 2017-02-03 一种消息交互的方法和客户端设备

Country Status (4)

Country Link
US (1) US10820025B2 (zh)
EP (1) EP3406079A4 (zh)
CN (1) CN108605154B (zh)
WO (1) WO2017133659A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA3011330A1 (en) * 2017-07-14 2019-01-14 Comcast Cable Communications, Llc Reduced content manifest size
CN110086797B (zh) * 2019-04-22 2021-05-28 北京开广信息技术有限公司 媒体流的实时接收方法、客户端、计算机设备和存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10104190B2 (en) * 2013-07-12 2018-10-16 Canon Kabushiki Kaisha Adaptive data streaming method with push messages control
KR101924703B1 (ko) * 2014-02-13 2019-02-20 코닌클리즈케 케이피엔 엔.브이. 단일 메세지 요청에 기초하여 네트워크 노드로부터 다수의 청크 요청
US20150271233A1 (en) * 2014-03-20 2015-09-24 Samsung Electronics Co., Ltd. Method and apparatus for dash streaming using http streaming
CN107077541B (zh) * 2014-03-24 2020-01-03 华为技术有限公司 应用于动态自适应流媒体的部分url签名系统和方法
US10902474B2 (en) * 2014-03-24 2021-01-26 Qualcomm Incorporated Targeted advertisement insertion for streaming media data

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Client-requested push for DASH[CE-FDH];Emmanuel Thomas(TNO),et al.;《ISO/IEC JTC1/SC29/WG11》;20141031;全文 *

Also Published As

Publication number Publication date
CN108605154A (zh) 2018-09-28
EP3406079A1 (en) 2018-11-28
WO2017133659A1 (en) 2017-08-10
US10820025B2 (en) 2020-10-27
US20190045238A1 (en) 2019-02-07
EP3406079A4 (en) 2019-07-10

Similar Documents

Publication Publication Date Title
US11652903B2 (en) Method and system for streaming applications using rate pacing and MPD fragmenting
JP5542872B2 (ja) メディアコンテナファイルの管理
CN102055718B (zh) 一种在http streaming系统中实现分层请求内容的方法,装置和系统
CN105828096B (zh) 媒体流文件的处理方法和装置
JP2004515004A (ja) Ｘｍｌのためのパーサー
US20080319994A1 (en) Method for registering a template message, generating an update message, regenerating and providing an application request, computer arrangement, computer program and computer program product
CN108605154B (zh) 一种消息交互的方法和客户端设备
CN105049931A (zh) 对移动终端中非支持格式的视频进行转换的方法及系统
JP2004318188A (ja) 構造化データの受信プログラム
US9237178B2 (en) Combined binary string for signaling byte range of media fragments in adaptive streaming
CN112350986A (zh) 一种音视频网络传输碎片化的整形方法及系统
CN114501049B (zh) 直播连接的建立方法、装置及系统
WO2022253079A1 (zh) 基于hls流的字幕显示方法及装置
Yuan et al. Design and implementation of embeded streaming media player based on STB
Dong et al. A Study on H. 264 Live Video Technology with Android System
CN113905025A (zh) 一种传输流数据的方法、装置、介质及计算机设备
CN109845273A (zh) 用于实现与数字媒体分发相关联的通信的系统和方法
JP2004234672A (ja) 構造化データの送信装置
JP2004234673A (ja) 構造化データの送信装置
JP2004318806A (ja) 構造化データの受信方法
JP2004234669A (ja) 構造化データの送信装置
JP2004234679A (ja) 構造化データの送信装置
JP2004320073A (ja) 構造化データの受信プログラム
JP2004234674A (ja) 構造化データの送信装置
JP2004234675A (ja) 構造化データの送信装置

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