[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

CN104040993A - 用于发送相应地接收媒体流的方法 - Google Patents

用于发送相应地接收媒体流的方法 Download PDF

Info

Publication number
CN104040993A
CN104040993A CN201280067351.3A CN201280067351A CN104040993A CN 104040993 A CN104040993 A CN 104040993A CN 201280067351 A CN201280067351 A CN 201280067351A CN 104040993 A CN104040993 A CN 104040993A
Authority
CN
China
Prior art keywords
fragment
index
media
media stream
uri
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.)
Pending
Application number
CN201280067351.3A
Other languages
English (en)
Inventor
T.洛马
F.加宾
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of CN104040993A publication Critical patent/CN104040993A/zh
Pending legal-status Critical Current

Links

Classifications

    • 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/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • 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/70—Media network packetisation
    • 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
    • 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/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • 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/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明提议一种用于接收媒体流的方法，由此将媒体流分段在多个连续片段中。开始时，接收清单文件，由此清单文件包括以URI模板方式的媒体片段的指示和引用所述媒体流的第一片段的开始索引。从清单文件内的接收信息组装不同URI，由此组装的URI引用所述多个片段的片段，并且由此组装是基于所述指示和索引，由此索引基于开始索引进行计算，并且对于每个连续片段增加预确定的值。借助于这些组装的URI，接收所述片段，由此接收是基于允许识别相同片段的分组的标识符，由此所述片段散布在多个分组上，并且特定片段的每个分组包括所述特定标识符，由此索引映射到标识符。重新组装获取的媒体片段分组以形成所述媒体流。本发明还提议了一种用于以上述方式提供所述媒体流的方法及允许执行相应方法的相应设备。

Description

用于发送相应地接收媒体流的方法
技术领域
本发明涉及用于接收媒体流的方法。
背景技术
迄今为止，通过移动网络的标准化直播视频分组服务依赖RTP（实时传输协议）传输媒体流（也称为内容）。其后，3GPP/ETSI、MPEG和开放IPTV论坛组织已定义了动态和适应性HTTP流传送(DASH)系统。DASH定义成通过HTTP协议传输内容。然而，它定义也能够通过象例如FLUTE的其它文件传送协议传输的文件格式。DASH由此描述通过HTTP的动态适应性流传送，而FLUTE涉及通过单向传输的文件输送。FLUTE上的DASH (DASH over FLUTE)基本上描述“文件流传送”服务，由此客户端从单独获取的文件的序列重新组装流。
图1中示出在“HTTP流传送”与提议的DASH直播流传送（“文件流传送”）原理之间的差别。
在可以MPEG2-传输流分组(MPEG2-TS)形式提供的“HTTP流传送”内容的情况下，可通过例如TCP管道的单个管道发送。在例如通过使用HTTP请求/HTTP响应循环打开HTTP/TCP管道后，客户端接收MPEG-TS分组而不发送任何另外的HTTP请求。
在“适应性HTTP流传送”的情况下，提供内容的服务器将流细分成多个连续媒体片段，每个片段包含某个持续时间的媒体数据（一般大约1秒或10秒）。客户端单独获取这些媒体片段，即，在某个时间点发送对每个媒体片段的HTTP请求，并且在客户端侧上联结获取的媒体片段，从而形成连续的流。
DASH标准由两个主要部分组成。
第一部分提供用于媒体呈现描述(MPD)，MPD将由客户端用于得出接入内容的适当链路。
第二部分识别内容的格式，内容在媒体片段方面指ISO文件格式（3GP或MP4）和MPEG2-TS格式的扩展。
用于媒体片段检索的默认协议是基于HTTP的，但其它协议也可使用。允许此类检索的协议将能够独特地识别媒体片段，例如，通过使用URL或诸如此类。
MPD的用途是向客户端提供与可用内容版本的特性（例如，视频分辨率、比特率）的信息、位置和定时，使得客户端能够获取和播放特定内容的媒体片段。
MPD语法以XML方式定义。一般情况下，在流传送会话开始时使用HTTP获取MPD文件，但为了灵活性，也可在预确定的时间间隔流逝后更新/重新获取MPD。
如图2以示意图方式所示的MPD包括三个主要组成，即，时期、表示和片段。虽然在下述内容中以分层方式描述，但要理解的是，可选择允许有关组成的明确归属的任何适当格式。
如图2所示，时期元素是MPD的最外部分。时期一般表示将按顺序向用户呈现的更大块的媒体。
在某个时期内，可出现内容的多个不同编码。每个备选称为表示。这些备选表示可提供用于不同比特率和/或不同帧速率和/或视频分辨率及诸如此类。
最后，每个表示例如通过使用HTTP URL描述一系列的片段。这些URL在表示（并且可能因此类似于播放列表）中明确描述，或者URL通过模板构造描述，这允许客户端得到用于表示的每个片段的有效URL。
如所述的，MPD格式是灵活的，并且能够支持诸如MPEG-2 TS的其它媒体容器格式。MPD甚至也允许内容播放列表和/或广告插入功能性，这是因为不同内容的时期可链接在表示或时期内。
电信系统中广泛使用的3GP文件格式及因此还有3G2和MP4文件格式是基于ISO基本媒体文件格式(ISO-FF)。在下述内容中，我们将只引用3GP，但由此假设也包含3G2和MP4。图3中以示意图方式显示3GP媒体流的一部分。
用于HTTP流传送的3GP片段可以是初始化片段或媒体片段。
初始化片段包括配置数据（其可格式化为文件格式的“ftyp”和“moov”盒）。
媒体片段类似于一个片段类型盒（“styp”）和媒体指针和样本的一个或更多个电影片段（“moof”和“mdat”盒）的级联。
将初始化片段与相同表示的一个或更多个媒体片段级联将产生有效的3GP文件。
3GP文件格式被扩展用于特定的HTTP流传送要求。现在它也提供“sidx”、“tfad”和“tfdt”盒，而“styp”盒非常类似于“ftyp”盒。
片段索引盒（“sidx”）提供与时期开始有关的相对定时信息以用于在搜寻后的时间恢复。片段索引盒（“sidx”）也可提供随机接入点的列表。此类信息也可作为样本标志输送。
另一方面，轨道片段调整盒（“tfad”）提供在轨道之间的相对定时信息用于媒体同步。
轨道片段基本媒体解码时间（“tfdt”）盒在轨道片段中提供第一样本的解码时间用于媒体同步。
这些盒（即，“sidx”、“tfdt”和“sidx”）是可选的。
众所周知，旧式播放器经常丢弃“ftyp”盒。
提议的适应性HTTP流传送的特征是媒体片段将对所有用户是相同的。通过为客户端提供在备选表示的片段之间交换的可能性，获得适应性方式。
由于可为多个用户容易地缓存媒体片段，因此，此属性使3GP-DASH HTTP缓存和内容输送网络(CDN)友好。由其URL识别的媒体片段然后能够以与任何其它Web内容相同的方式由中间HTTP代理/缓存提供。
3GPP中HTTP流传送的另一特征是可再使用为诸如3GPP PSS流传送的其它流传送解决方案定义的编解码器，由此消除提供另外编解码器的需要。
此外，在其它领域，如在IPTV（因特网协议电视）中，可能采用类似的概念，如例如采纳了类似规范作为在2010年9月公布的其第2版的一部分的开放IPTV论坛(OIPF)。MPD语法和语义被再使用，只示出较小的适应。
此外，指定了允许在MPEG2传输流(MPEG2-TS)格式中支持媒体片段的扩展。OIPF提供的MPEG2-TS扩展与由只示出较小的适应的3GP媒体片段提供的扩展对齐。MPD可使用例如MIME类型“视频/mpeg”或“视频/mp2t”指示媒体片段的格式为MPEG2-TS。
OIPF MPEG-2 TS格式可被理解为完全TS格式的子集。因此，通过联结客户端获取的媒体片段，可能形成符合MPEG2-TS的流。
节目特定信息(PSI)表可包括在初始化片段中和/或在一个或更多个媒体片段中。
每个媒体片段将以随机接入点开始。所有媒体表示将是时间对齐的，从而允许简化的交换及比特率适应。MPEG2-TS random_access_indicator字段可用于表明在一个或更多个媒体片段内的随机接入点，由此允许客户端侧上简化的特技播放和/或搜寻操作。
DASH规范现在可用于具有3GP和MPEG2-TS文件格式的服务器和客户端实现器。
至今，即使上述设置提供了几个益处，但还有主要问题要解决。
也描述为MBMS下载的MBMS文件输送未设计用于直播视频分布。直播视频分布及其它直播服务依赖诸如RTP的实时协议。
能够设想对“FLUTE上的DASH”设计的改变。然而，此类设计要求通过新文件输送表(FDT)实例通告每个媒体片段。FDT实例由此将包括用于相应媒体片段的文件名和相应FEC配置（例如，符号大小和内容长度）。包含在FTD实例中的文件名与是整数的传输对象ID相关联。此传输对象标识符要包括在属于相应媒体片段的每个分组中。另外，每个分组包括经常称为FEC有效负载ID的序号，序号用于识别片段内分组的顺序。
为示出此问题，我们将在下述内容中参照涉及MBMS上的DASH 的过程的图4和5。
其中，MPD包括URL模板，模板将通过将字符（此处为$Index$）的良好定义的顺序替换为是索引的整数（此处为“10”到“12”）的字符来描述有效的URL构造。索引的范围也在MPD中给出。默认开始索引可以为“1”。
媒体客户端可使用模板http://www.example.com/FIFA_2min-$Index$.3gs和索引来构建用于媒体片段的有效URI。如果索引为10，则用于媒体片段的有效URI能够是http://www.example.com/FIFA_2min-10.3gs。
FLUTE协议的性质由此要允许为例如http://www.example.com/FIFA_2min-10.3gs 的每个文件URI指派例如10的传输对象ID (TOI)（参见图4）。注意，URI引用的文件仍可分成几个分组，例如，UDP分组，并且TOI由媒体客户端用于收集属于相同文件的FLUTE分组。由于具有相同TOI的所有分组保持为相同文件的一部分，因此，这可以完成。
图5是通过FLUTE的DASH片段流的传送。其中，例如FIFA-seg003.3gs的每个媒体片段在简化显示的FLUTE FDT实例内通知，并且指派有单个传输对象ID，即，在所示示例中，TOI 21指派到名为FIFA-seg003.3gs的文件（简化的内容位置），而TOI 22指派到文件URI FIFA-seg004.3gs。此外，每个FLUTE FDT实例指示诸如FEC符号大小、FEC编码和其它FEC信息、文件大小的FEC参数及内容类型和确切的内容位置，如图4所示。在FDT实例后，可接收和重新组装所述文件“FIFA-seg003.3gs”的相应“UDP/Flute”分组。在分组的序列之间，通过重复“FDT Inst #x”分组，可如图5所示重复FDT实例。
缺点是如果对应于所述实例的FDT实例未收到，或者如果FDT实例损坏，则FLUTE接收器将丢弃整个片段，这是因为在没有适当FEC配置以及丢失在FDT实例内提供的内容位置相应地内容的正确类型（MIME类型）和/或文件大小的情况下，FLUTE接收器不能将媒体片段解码。此类丢弃将导致服务质量被感觉为差，由此减小了允许再使用已知编解码器和输送机制并且由此最小化市场化的时间及总体软件开发和维护成本的常见方案的总体益处。
发明内容
一个目的是消除至少一些上述缺点并且提供用于发送相应地接收媒体流的改进方法以及因此改进的装置。
因此，本发明提议一种用于接收媒体流的方法，由此将媒体流分段在多个连续片段中。开始时，接收清单文件，由此清单文件包括以URI模板方式的媒体片段的指示和引用所述媒体流的第一片段的开始索引。从清单文件内的接收信息组装不同URI，由此组装的URI引用所述多个片段的片段，并且由此组装是基于所述指示和索引，由此索引基于开始索引进行计算，并且对于每个连续片段增加预确定的值。借助于这些组装的URI，接收所述片段，由此接收是基于允许识别相同片段的分组的标识符，由此所述片段散布在多个分组上，并且特定片段的每个分组包括所述特定标识符，由此索引映射到标识符。重新组装获取的媒体片段分组以形成所述媒体流。
本发明也提议了一种用于以上述方式提供所述媒体流的方法及允许执行相应方法的相应设备。
附图说明
在下述内容中，将参照附图进一步详细描述本发明，其中
图1以示意图方式示出传统媒体流和分段的媒体流的比较；
图2以示意图方式示出媒体呈现描述的一般布置；
图3以示意图方式示出片段的基于3gp格式的http流传送的典型布置；
图4以示意图方式示出允许识别媒体流的单独URI的现有技术的设计原理；
图5以示意图方式示出通过FLUTE的DASH片段的传送；
图6以示意图方式示出在允许利用本发明的益处的系统内根据本发明的装置的布置；
图7示出显示根据本发明的实施例的客户端的方面的流程图，以及
图8示出显示根据本发明的实施例的服务器的方面的流程图。
具体实施方式
在详细描述本发明的实施例之前，要理解本发明不限于所述装置的特定组件部分或所述方法的步骤，这是因为此类装置和方法可有所不同。也要理解，本文使用的术语只是为了描述特定实施例，而无意于限制。必须注意的是，除非上下文另外明确指明，否则，如说明书和随附权利要求中使用的，单数形式“一”和“该”也包括单数和/或复数指示物。
发明者注意到，文件序列的多个连续文件提供几乎相同大小和/或持续时间。因此，此类似大小和/或提供类似持续时间的大多数FEC参数也将是类似的。这可同样对于流的一些或甚至所有文件是正确的。此外，发明者注意到，MPD文件及FDT实例各自至少部分包括类似信息，而其它信息只在FDT内提供，如文件大小和FEC参数及文件大小。
本发明提议直接传送例如ISO-FF或MPEG2-TS或诸如此类的媒体片段，例如，经由如IETF定义的ALC（异步分层编码）协议，由此消除对IETF FLUTE协议的需要。为允许此类传输，类似的信息被布置使得它变得相同，而传统上在FLUTE FDT实例中传输的静态信息移向MPD。可变信息通过不同方式传输，例如，它可编码到报头中，例如，作为扩展。
本发明因此允许增加的鲁棒性。
MPD能够描述采用具有单独索引的URI模板形式的媒体片段URI的序列。MPD包括开始索引，并且可选择地也包括结束索引。此类结束索引可事先已知，例如，在直播会话的已知结束时间的情况下。客户端可通过组合URI模板和索引而形成媒体片段URI。
示例模板可以是“http://server/path/seg$Index$.3gs”，其中，序列“$Index$”要由索引替换，例如，索引的整数值。作为示例，如果$Index$的值为9，则产生的URI将是“http://server/path/seg9.3gs”。
FLUTE协议通过常规文件输送功能扩展ALC（异步分层编码）。具体而言，FLUTE提供了将象文件名和MIME类型的文件属性关联到ALC/LCT TOI元素（传输对象ID）的功能性。因此，每个UDP分组包括其所属的传输对象（即，文件）的TOI值。
FLUTE也可提供允许客户端移除TOI到文件关联的超时机制。
除其它之外，FDT条目还可包括
· TOI（条目）
· 用于关联的截止时间
· 文件名（内容位置）
· MIME类型（内容类型）
· 内容长度
· FEC符号大小
· FEC编码ID
· 源块长度
· 其它FEC OTI参数
例如，如具“MBMS上的DASH”能力的客户端的通过本发明使能的具有能力的装置可通过使用诸如ALC TOI值的允许识别相同片段的分组的标识符作为用于媒体片段URI创建的索引来创建媒体片段URI。标识符可直接用作$Index$，或者可在预确定的方案内使用，如在预确定的计算方案内。即，$index$与ALC TOI方案对齐，其中，索引一般以1开始。为此，索引直接映射到MPD片段索引和ALC TOI。MPD也可包括内容类型（MIME类型）（因为这一般是用于流的片段的静态数据），相应地它的分组。向如通过本发明使能的客户端提供的MPD将包括专用“广播”表示（或适应集），客户端可在通过MBMS接收媒体片段时使用它。
此类广播表示将包括FEC编码ID（并且可选择地也包括FEC实例ID），从而允许描述使用的FEC方案。注意，甚至NO-CODE FEC也是包括编码ID 0的有效FEC方案。MPD中的广播表示也可包括FEC符号大小，并且还可基于需要而包括其它FEC方案特定信息。FEC方案特定信息可涉及每编码符号的子块数量和/或子符号数量。
如果媒体输送要求跨不同表示的时间对齐，则媒体片段将提供用于相同持续时间的媒体播放时间。因此，媒体片段可由于视频的性质而在大小方面有所不同，一般示出可变比特率。
在此情况下，将为例如ALC传输块的每个文件提供对象长度或编码符号的数量。为此，可在诸如LCT报头扩展的报头内提供信息，从而允许携带必需的信息，例如作为ALC报头的一部分。此类报头可与每个分组一起提供。
如果媒体输送允许恒定大小的媒体片段，则每个媒体片段的播放时间将一般是不同的，即，如果媒体片段具有恒定大小（以字节为单位），则每个片段提供的媒体播放时间一般有所不同。
在此情况下，文件大小或源符号的数量可在MPD中提供。
为使能与现有FLUTE接收器的后向兼容性，可设想作为提供此类增强服务的服务器的广播-多播-服务中心(BM-SC)还可创建有效FDT实例并且标记为TOI 0。由于媒体流的第一媒体片段从TOI=1开始，因此，预期无负相互作用。
为使能在媒体会话内的MPD更新，例如，象图5所示的，其中，在传送UDP/Flute分组流的同时包括了第二FDT INST#X，可设想更新的MPD将例如通过在FLUTE/ALC报头中使用不同传输会话标识符TSI而单独输送，例如，在例如另一FLUTE/ALC信道的单独信道中输送，和/或例如通过使用不同UDP端口而作为不同(FLUTE)会话输送。显而易见的是，即使使用术语“更新”，MPD更新也可只是以前发送的MPD的副本。
下面示出使能“MBMS上的优化DASH”的示例MPD。此MPD允许组合模板URI构造和与FLUTE FDT实例有关的信息。此构造消除了在单独消息中发送这些FLUTE FDT实例的需要，并且由此本发明提供了允许更可靠传输的有利方案。
因此，根据本发明的MPD也包括允许直接ALC传输对象识别和文件URI关联的模板。对于后向兼容性，模板可被布置使得它也允许经典FLUTE传输对象识别和文件URI关联。
在下述内容中，给出了示出根据本发明的特征的示例MPD。下面的示例示出具有时间对齐媒体片段的MPD实现示例。
<MPD xmlns="urn:3GPP:ns:PSS:AdaptiveHTTPStreamingMPD:2009" availabilityStartTime="2010-10-11T13:50:44Z" availabilityEndTime="2010-10-11T16:50:44Z" timeShiftBufferDepth="PT1M0.00S" type="Live" minBufferTime="PT10.00S">
<Period segmentAlignmentFlag="true">
<Representation bandwidth="128000" mimeType="video/3gpp" >
<SegmentInfo duration="PT10S" baseURL="mt500">
<InitialisationSegmentURL sourceURL="fifa128seg_i.3gp"/>
<UrlTemplate sourceURL="$Index$.3gs"/>
</SegmentInfo>
</Representation>
<Representation bandwidth="512000" mimeType="video/3gpp">
<SegmentInfo duration="PT10S" baseURL="mt1000">
<InitialisationSegmentURL sourceURL="fifa512seg_i.3gp"/>
<UrlTemplate sourceURL="$Index$.3gs"/>
</SegmentInfo>
</Representation>
<Representation bandwidth="512000" mimeType="video/3gpp" mbms=="true">
<MbmsReception>
<bearer sdp=”http://example.com/link/del.sdp” />
<fec fecId=”1” symLen=”135” schemeInfo=”AAEBBA==”>
</MbmsReception>
<SegmentInfo duration="PT10S" baseURL="mt1000">
<InitialisationSegmentURL sourceURL="fifa512seg_i.3gp"/>
<UrlTemplate sourceURL="$Index$.3gs"/>
</SegmentInfo>
</Representation>
</Period>
</MPD>
MPD示出信息的分层布置。第一信息是在字段availabilityStartTime="2010-10-11T13:50:44Z"中给出的开始索引信息。此外，可选的结束索引可在另一字段availabilityEndTime="2010-10-11T16:50:44Z"中提供。涉及所有表示的其它参数也可给出，例如，涉及媒体的缓冲器和/或类型的信息。
示范MPD包括三个表示。此处，前两个表示<Representation bandwidth="128000" mimeType="video/3gpp">和<Representation bandwidth="512000" mimeType="video/3gpp">描述使用HTTP的媒体片段的单播接收，由此第一表示和第二表示在所需带宽方面相互不同，并且因此也提供用于不同基准URL。
第三表示<Representation bandwidth="512000" mimeType="video/3gpp" mbms=="true">包括名为“mbms”的属性，该属性将指示媒体片段的mbms接收，即，媒体片段的多播或广播接收。
在所述第三表示内，有详细描述用于广播/多播输送的参数的部分<MbmsReception>。它包括名为承载的元素，其sdp属性涉及详细描述输送会话描述的SDP文件。SDP文件可描述FLUTE会话（后向兼容性），或者可描述在MBMS上的直接会话，如在MBMS上的ALC会话。
备选地或另外地，也可将来自SDP文件的这些参数直接包括到MPD中。具体而言，可提供TMGI（临时移动群组标识符，即，MBMS承载id）、IP多播地址、UDP目的地端口和TSI信息。
元素fec包含那些FEC参数，这些参数可适用于所有媒体片段，即，它们是静态的。这些FEC参数具体而言是fec-id，识别将使用哪个FEC代码、符号大小(symLen)和方案特定信息，例如，源块和子块的数量。这些FEC参数要用于所有媒体片段。
文件大小或源符号的数量可在诸如LCT扩展报头的报头内提供到客户端。
如果提供了文件大小，则客户端将源符号的数量计算为最高限度（ceil）（文件大小/符号大小）。在FEC解码期间可将最后的符号填充为完整符号。
取决于要求的鲁棒程度，此报头可在开始时提供一次，或者它可在输送内提供若干次。
在下述内容中，给出了示出根据本发明的特征的另一示例MPD：
媒体输送也提供使用大小对齐的媒体片段的可能性。然后，所有媒体片段（大约）具有相同大小。携带的时间量一般随片段的不同而不同，这是因为多媒体内容可能进行了可变比特率编码。
这些大小对齐的片段也可表示为字节对齐的片段。片段持续时间可在媒体片段内显式或隐式携带。
例如，在ISO-FF的情况下，一些表（称为盒）携带用于每个片段的解码定时信息。在MPEG TS的情况下，DTS和PTS（解码和呈现时间戳）携带定时信息。
因此，由于此片段持续时间可从以任何方式提供的此信息得出，因此，无需如前面相对于时间对齐片段在报头内提供信息。
下面的示例示出具有大小对齐的媒体片段的另一MPD实现示例。
<MPD xmlns="urn:3GPP:ns:PSS:AdaptiveHTTPStreamingMPD:2009" availabilityStartTime="2010-10-11T13:50:44Z" availabilityEndTime="2010-10-11T16:50:44Z" timeShiftBufferDepth="PT1M0.00S" type="Live" minBufferTime="PT10.00S">
<Period segmentAlignmentFlag="true">
<Representation bandwidth="128000" mimeType="video/3gpp" >
<SegmentInfo duration="PT10S" baseURL="mt500">
<InitialisationSegmentURL sourceURL="fifa128seg_i.3gp"/>
<UrlTemplate sourceURL="$Index$.3gs"/>
</SegmentInfo>
</Representation>
<Representation bandwidth="512000" mimeType="video/3gpp" >
<SegmentInfo duration="PT10S" baseURL="mt1000">
<InitialisationSegmentURL sourceURL="fifa512seg_i.3gp"/>
<UrlTemplate sourceURL="$Index$.3gs"/>
</SegmentInfo>
</Representation>
<Representation bandwidth="512000" mimeType="video/3gpp" mbms=”true”>
<MbmsReception>
<bearer sdp=”http://example.com/link/del.sdp” />
<fec fecId=”1” symLen=”135” schemeInfo=”AAEBBA==” noSym=1000>
</MbmsReception>
<SegmentInfo duration="PT10S" baseURL="mt1000">
<InitialisationSegmentURL sourceURL="fifa512seg_i.3gp"/>
<UrlTemplate sourceURL="$Index$.3gs"/>
</SegmentInfo>
</Representation>
</Period>
</MPD>
MPD示出信息的分层布置。第一信息是在字段availabilityStartTime="2010-10-11T13:50:44Z"中给出的开始索引信息。此外，可选的结束索引可在另一字段availabilityEndTime="2010-10-11T16:50:44Z"中提供。涉及所有表示的其它参数也可给出，例如，涉及媒体的缓冲器和/或类型的信息。
示范MPD包括三个表示。此处，前两个表示<Representation bandwidth="128000" mimeType="video/3gpp">和<Representation bandwidth="512000" mimeType="video/3gpp">描述使用HTTP的媒体片段的单播接收，由此第一表示和第二表示在所需带宽方面相互不同，并且因此也提供用于不同基准URL。
第三表示<Representation bandwidth="512000" mimeType="video/3gpp" mbms=="true">包括名为“mbms”的属性，该属性将指示媒体片段的mbms接收，即，媒体片段的多播或广播接收。
在所述第三表示内，有详细描述用于广播/多播输送的参数的部分<MbmsReception>。它包括名为承载的元素，其sdp属性涉及详细描述输送会话描述的SDP文件。SDP文件可描述FLUTE会话（后向兼容性），或者可描述在MBMS上的直接会话，如在MBMS上的ALC会话。
备选地或另外地，也可将来自SDP文件的这些参数直接包括到MPD中。具体而言，可提供TMGI（临时移动群组标识符，例如，MBMS承载id）、IP多播地址、UDP目的地端口和TSI信息。
元素fec包含那些FEC参数，这些参数可适用于所有媒体片段，即，它们是静态的。这些FEC参数具体而言是fec-id，识别将使用哪个FEC代码、符号大小(symLen)和方案特定信息，例如，源块和子块的数量。这些FEC参数要用于所有媒体片段。
元素fec包括名为“noSym”的另一属性，该属性指示用于每个媒体片段的源符号的数量。媒体客户端可将源块大小计算为noSym * symLen。由于源块（即，片段）将具有完全相同的长度，因此，如果分组未完全使用，不必传送最后分组的填充信息。
收到分组时，通过标识符识别片段的分组。此标识符被布置使得它映射到引用媒体片段的索引。例如，如果使用基于ALC的输送，则可将传输对象标识符TOI直接用作对片段的索引的引用。
图6中示出根据本发明的系统。图中服务器SRV除其它之外还包括CPU 110、I/O单元120和存储器130，而诸如硬盘或诸如此类的其它硬件未示出。CPU 110适用于控制I/O单元120并且由此能够在提供媒体流服务的同时发送和接收消息。存储器130可存储相应的应用程序以便执行和/或它可存储要输送的一个或更多个媒体流片段。具体而言，CPU 110可操作以发送根据本发明的MPD，由此允许诸如示范客户端CL1、CL2、CL3的客户端获取相应媒体流的相应媒体片段。客户端CL1、CL2、CL3和服务器被布置以使得它们可借助地其相应I/O单元使用诸如移动电信网络的通信网络相互进行通信。示例通信网络可以是本领域中已知的基于LTE、UMTS或EDGE的网络及要开发的任何适当前身。此外，服务器SRV也可位于诸如电视广播系统的广播系统内，由此广播系统可以或可以不例如经另一无线或基于有线的通信系统向单独客户端提供反向信道。
客户端CL1、CL2、CL3除其它之外还包括CPU 210、I/O单元220和存储器230，而诸如硬盘或诸如此类的其它硬件未示出。CPU 210适用于控制I/O单元220并且由此能够在提供媒体流服务的同时发送和接收消息。存储器230可存储相应的应用程序以便执行和/或它可存储要组装的一个或更多个媒体流片段。具体而言，CPU 210可操作以接收根据本发明的MPD，由此允许客户端CL1、CL2、CL3获取相应媒体流的相应媒体片段。组装的媒体流或其部分然后可通过相应媒体播放器向用户提供，媒体播放器也可实施为在存储器230中存储并且由CPU 210执行的应用程序。此外，客户端CL1、CL2、CL3也可位于诸如电视广播系统的广播系统内，由此广播系统可以或可以不例如经由另一无线或基于有线的通信系统向提供服务器SRV通过反向信道。
可使得客户端CL1、CL2、CL3能够执行如图7中所突出的方法。
在步骤100中，客户端CL1、CL2、CL3接收清单文件，由此清单文件包括以URI模板方式的媒体片段的指示、引用所述媒体流的第一片段的开始索引。
在步骤200中，客户端CL1、CL2、CL3组装来自不同清单文件的不同URI，由此组装的URI引用所述多个片段的片段，由此组装是基于所述指示和索引，以及由此索引是基于开始索引进行计算，并且对于每个连续片段增加预确定的值。
在步骤300中，客户端CL1、CL2、CL3借助于组装的URI接收所述片段，由此获取是基于允许识别相同片段的分组的标识符，由此所述片段散布在多个分组上，并且特定片段的每个分组包括所述标识符，由此索引映射到所述标识符。虽然使用了接收的术语，但涉及的过程可以是被动或主动的。
在步骤400中，客户端CL1、CL2、CL3重新组装所述片段以形成所述媒体流。
一旦所有片段已收到并且向用户提供，或者在严重故障或用户请求的情况下，方法结束。
可使得服务器SRV能够执行如图8中所突出的方法。
在步骤500中，服务器SRV提供清单文件，由此清单文件包括以URI模板方式的媒体片段的指示和引用所述媒体流的第一片段的开始索引，由此清单文件允许从收到的清单文件组装不同URI，由此组装的URI引用所述多个片段的片段，由此组装是基于所述指示和索引，由此索引是基于开始索引进行计算，并且对每个连续片段增加预确定的值。
在步骤600中，借助于所述组装的URI服务器SRV提供所述片段，由此提供是基于允许识别相同片段的分组的标识符，由此所述片段散布在多个分组上，并且特定片段的每个分组包括所述标识符，由此索引映射到所述标识符，由此允许重新组装所述片段以形成所述媒体流。虽然使用了提供的术语，但涉及的过程可以是被动或主动的。
在本发明的一实施例中，可预见索引是传输对象标识符，例如，ALC协议的传输对象标识符。
在本发明的另一实施例中，可预见清单文件MPD包括结束索引。这例如可在结束时间已知的情况下使用。
根据又一实施例，以单播或广播或多播方式提供流。通过允许不同输送类型，允许简化的服务器和客户端体系结构。
根据仍有的另一实施例，片段具有实质相同的大小和/或实质相同的持续时间。
在片段具有实质相同大小的情况下，不要求有关文件大小或符号数量的另外的信息，但要求基于其它信息计算定时信息的引用。因此，在大小对齐的片段的情况下，MPD可包括与源符号的数量“noSym”有关的另外的信息。
在片段具有实质相同持续时间的情况下，要求有关文件大小和/或符号数量的其它信息。此信息可在报头中提供，例如作为LCT报头扩展。取决于要求的鲁棒程度，此报头可在开始时提供一次，或者它可在输送内提供若干次。
根据还有的另一实施例，提供更新的清单文件MPD以便接收，由此增加鲁棒性并且允许更新。
在本发明的另一实施例中，可预见清单文件MPD包括提供不同比特率和/或不同分辨率和/或不同帧速率的媒体片段的多个指示。为此，可实现HTTP上动态适应性流传送(DASH)的益处。
本发明虽然相对于特定实施例进行描述，但可在多种情形中采用，包括广播、多播和单播环境。因此，本发明不但可在双向通信系统内使用，而且可在诸如用于数字视频的广播系统和/或数字音频广播系统的单向通信系统中使用。
上述详细实施例中要素和特征的特定组合只是示范；这些实施例和本文中公开的其它实施例的互换和替代也明确考虑。如本领域技术人员将认识的，在不脱离所要求保护的本发明的精神和范围的情况下，本领域普通技术人员能够想到本文中所述内容的变化、修改和其它实现。因此，上述描述只作为示例而无意限制。本发明的范围在随附权利要求及其等同物中定义。此外，在描述和权利要求中使用的标号不限制所要求保护的本发明的范围。

Claims (9)

1. 一种用于接收媒体流的方法，由此将媒体流分段在多个连续片段中，
接收清单文件，由此所述清单文件
包括以URI模板方式的媒体片段的指示，
包括引用所述媒体流的第一片段的开始索引，
从所述收到的清单文件组装不同URI，
由此组装的URI引用所述多个片段的片段，
由此组装是基于所述指示和索引，
由此所述索引是基于所述开始索引进行计算，并且对于每个连续片段增加预确定的值，
借助于所述组装的URI接收所述片段，由此接收是基于允许识别相同片段的分组的标识符，由此所述片段散布在多个分组上，并且特定片段的每个分组包括所述标识符，由此所述索引映射到所述标识符，
重新组装所述片段以形成所述媒体流。
2. 一种用于提供媒体流的方法，由此将媒体流分段在多个连续片段中，
提供清单文件，由此所述清单文件
包括以URI模板方式的媒体片段的指示，
包括引用所述媒体流的第一片段的开始索引，
由此所述清单文件允许从所述收到的清单文件组装不同URI，
由此组装的URI引用所述多个片段的片段，
由此组装是基于所述指示和索引，
由此所述索引是基于所述开始索引进行计算，并且对于每个连续片段增加预确定的值，
借助于所述组装的URI提供所述片段，由此提供是基于允许识别相同片段的分组的标识符，由此所述片段散布在多个分组上，并且特定片段的每个分组包括所述标识符，由此所述索引映射到所述标识符，由此允许重新组装所述片段以形成所述媒体流。
3. 如权利要求1或2所述的方法，由此所述索引是传输对象标识符。
4. 如权利要求1或2或3所述的方法，由此所述清单文件包括结束索引。
5. 如前面权利要求任一项所述的方法，由此所述流以单播或广播或多播方式提供。
6. 如前面权利要求任一项所述的方法，由此所述片段具有实质相同的大小和/或实质相同的持续时间。
7. 如前面权利要求任一项所述的方法，由此提供更新的清单文件用于接收。
8. 如前面权利要求任一项所述的方法，由此所述清单文件包括提供不同比特率和/或不同分辨率和/或不同帧速率的媒体片段的多个指示。
9. 一种允许执行如权利要求1到8任一项所述方法的设备。
CN201280067351.3A 2012-01-17 2012-01-17 用于发送相应地接收媒体流的方法 Pending CN104040993A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2012/050647 WO2013107502A1 (en) 2012-01-17 2012-01-17 Method for sending respectively receiving a media stream

Publications (1)

Publication Number Publication Date
CN104040993A true CN104040993A (zh) 2014-09-10

Family

ID=45491616

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201280067351.3A Pending CN104040993A (zh) 2012-01-17 2012-01-17 用于发送相应地接收媒体流的方法

Country Status (4)

Country Link
US (1) US20150172348A1 (zh)
EP (1) EP2805463A1 (zh)
CN (1) CN104040993A (zh)
WO (1) WO2013107502A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106254300A (zh) * 2015-06-08 2016-12-21 中兴通讯股份有限公司 流媒体传输方法、播放方法、传输装置及播放装置
CN107409234A (zh) * 2015-03-04 2017-11-28 高通股份有限公司 基于lct利用dash格式的基于文件格式的流式传输
WO2018014523A1 (zh) * 2016-07-18 2018-01-25 华为技术有限公司 一种媒体数据的获取方法和装置
CN107743708A (zh) * 2015-06-18 2018-02-27 瑞典爱立信有限公司 用于存储媒体段的基于目录限制的系统和方法
CN112385242A (zh) * 2018-07-11 2021-02-19 高通股份有限公司 用于媒体流的时间信令

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120034550A (ko) 2010-07-20 2012-04-12 한국전자통신연구원 스트리밍 컨텐츠 제공 장치 및 방법
US9467493B2 (en) 2010-09-06 2016-10-11 Electronics And Telecommunication Research Institute Apparatus and method for providing streaming content
EP2615841B1 (en) * 2010-09-06 2017-12-13 Electronics And Telecommunications Research Institute Apparatus and method for providing streaming content
US9736121B2 (en) * 2012-07-16 2017-08-15 Owl Cyber Defense Solutions, Llc File manifest filter for unidirectional transfer of files
US20140156865A1 (en) * 2012-11-30 2014-06-05 Futurewei Technologies, Inc. Generic Substitution Parameters in DASH
KR20150077461A (ko) * 2013-01-16 2015-07-07 후아웨이 테크놀러지 컴퍼니 리미티드 적응형 스트리밍에 있어서 url 파라미터의 삽입과 추가
US9160515B2 (en) * 2013-04-04 2015-10-13 Intel IP Corporation User equipment and methods for handover enhancement using scaled time-to-trigger and time-of-stay
US9900166B2 (en) * 2013-04-12 2018-02-20 Qualcomm Incorporated Methods for delivery of flows of objects over broadcast/multicast enabled networks
EP3017605B1 (en) 2013-07-03 2022-12-07 Koninklijke KPN N.V. Streaming of segmented content
CN105359536B (zh) * 2013-07-17 2020-07-24 索尼公司 内容供给装置及方法、终端装置、以及内容供给系统
JP2015061307A (ja) * 2013-09-20 2015-03-30 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
EP3063943B1 (en) * 2013-11-01 2019-08-21 LG Electronics Inc. Apparatus for transmitting and method for transmitting broadcast signals
EP3090561B1 (en) * 2014-01-03 2019-04-10 LG Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
KR101924703B1 (ko) 2014-02-13 2019-02-20 코닌클리즈케 케이피엔 엔.브이. 단일 메세지 요청에 기초하여 네트워크 노드로부터 다수의 청크 요청
CN105745899B (zh) * 2014-02-24 2023-12-26 Lg 电子株式会社 发送广播信号的设备、接收广播信号的设备、发送广播信号的方法和接收广播信号的方法
JP6426901B2 (ja) * 2014-03-14 2018-11-21 富士通クライアントコンピューティング株式会社 配信方法、再生装置、配信装置、転送制御プログラムおよび配信制御プログラム
US9432431B2 (en) * 2014-03-18 2016-08-30 Accenture Global Servicse Limited Manifest re-assembler for a streaming video channel
JP2015192407A (ja) * 2014-03-28 2015-11-02 ソニー株式会社 送信装置、送信方法、受信装置、受信方法、及び、プログラム
US20170188062A1 (en) * 2014-04-09 2017-06-29 Lg Electronics Inc. Method and apparatus for transmitting/receiving broadcast signal
KR101814403B1 (ko) * 2014-05-21 2018-01-04 엘지전자 주식회사 방송 신호 송/수신 처리 방법 및 장치
US10523723B2 (en) 2014-06-06 2019-12-31 Koninklijke Kpn N.V. Method, system and various components of such a system for selecting a chunk identifier
EP3175624A4 (en) 2014-07-31 2018-02-28 LG Electronics Inc. Apparatus and method for transmitting/receiving processes of a broadcast signal
WO2016060410A1 (ko) * 2014-10-14 2016-04-21 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10645432B2 (en) 2015-01-07 2020-05-05 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving media information in communication system
US9946743B2 (en) * 2015-01-12 2018-04-17 Cisco Technology, Inc. Order encoded manifests in a content centric network
WO2016128803A1 (en) * 2015-02-11 2016-08-18 Expway Method of handling packet losses in transmissions based on dash standard and flute protocol
US9826016B2 (en) 2015-02-24 2017-11-21 Koninklijke Kpn N.V. Fair adaptive streaming
US9787430B2 (en) * 2015-05-01 2017-10-10 Qualcomm Incorporated Dynamic setting of FEC in eMBMS video streaming
KR101743228B1 (ko) * 2016-01-22 2017-06-05 네이버 주식회사 스트리밍 장치 및 그 방법, 이를 이용한 스트리밍 서비스 시스템 및 컴퓨터로 판독 가능한 기록매체
CN107562765A (zh) * 2016-07-01 2018-01-09 中兴通讯股份有限公司 一种信息处理方法及装置
US10440085B2 (en) * 2016-12-30 2019-10-08 Facebook, Inc. Effectively fetch media content for enhancing media streaming

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090300690A1 (en) * 2008-05-29 2009-12-03 Samsung Electronics Co., Ltd. Method and apparatus for sending and receiving broadcast service in a digital broadcasting system
US20110096828A1 (en) * 2009-09-22 2011-04-28 Qualcomm Incorporated Enhanced block-request streaming using scalable encoding
CN102131114A (zh) * 2010-11-17 2011-07-20 华为技术有限公司 一种播放列表提供方法及系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101750048B1 (ko) * 2009-11-13 2017-07-03 삼성전자주식회사 변속 재생 서비스 제공 방법 및 장치
US9621610B2 (en) * 2010-01-18 2017-04-11 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for HTTP media stream distribution
US9596447B2 (en) * 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US8190677B2 (en) * 2010-07-23 2012-05-29 Seawell Networks Inc. Methods and systems for scalable video delivery
US10511887B2 (en) * 2010-08-30 2019-12-17 Saturn Licensing Llc Reception apparatus, reception method, transmission apparatus, transmission method, program, and broadcasting system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090300690A1 (en) * 2008-05-29 2009-12-03 Samsung Electronics Co., Ltd. Method and apparatus for sending and receiving broadcast service in a digital broadcasting system
US20110096828A1 (en) * 2009-09-22 2011-04-28 Qualcomm Incorporated Enhanced block-request streaming using scalable encoding
CN102131114A (zh) * 2010-11-17 2011-07-20 华为技术有限公司 一种播放列表提供方法及系统

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107409234A (zh) * 2015-03-04 2017-11-28 高通股份有限公司 基于lct利用dash格式的基于文件格式的流式传输
CN107409234B (zh) * 2015-03-04 2020-12-25 高通股份有限公司 基于lct利用dash格式的基于文件格式的流式传输
CN106254300A (zh) * 2015-06-08 2016-12-21 中兴通讯股份有限公司 流媒体传输方法、播放方法、传输装置及播放装置
CN106254300B (zh) * 2015-06-08 2020-04-21 中兴通讯股份有限公司 流媒体传输方法、播放方法、传输装置及播放装置
CN107743708A (zh) * 2015-06-18 2018-02-27 瑞典爱立信有限公司 用于存储媒体段的基于目录限制的系统和方法
CN107743708B (zh) * 2015-06-18 2020-06-16 瑞典爱立信有限公司 经由dash来参与abr流传送会话的方法、装置和节点
WO2018014523A1 (zh) * 2016-07-18 2018-01-25 华为技术有限公司 一种媒体数据的获取方法和装置
CN107634930A (zh) * 2016-07-18 2018-01-26 华为技术有限公司 一种媒体数据的获取方法和装置
CN107634930B (zh) * 2016-07-18 2020-04-03 华为技术有限公司 一种媒体数据的获取方法和装置
CN112385242A (zh) * 2018-07-11 2021-02-19 高通股份有限公司 用于媒体流的时间信令
US11638062B2 (en) 2018-07-11 2023-04-25 Qualcomm Incorporated Time signaling for media streaming
US11997349B2 (en) 2018-07-11 2024-05-28 Qualcomm Incorporated Time signaling for media streaming

Also Published As

Publication number Publication date
EP2805463A1 (en) 2014-11-26
US20150172348A1 (en) 2015-06-18
WO2013107502A1 (en) 2013-07-25

Similar Documents

Publication Publication Date Title
CN104040993A (zh) 用于发送相应地接收媒体流的方法
US11805286B2 (en) Apparatus and method for transmitting/receiving processes of a broadcast signal
JP6441521B2 (ja) 放送システムにおける制御メッセージ構成装置及び方法
TWI714602B (zh) 超級本文傳輸協定(http)上動態自適應串流(dash)客戶經驗品質度量之中間軟體傳遞
TWI740878B (zh) 決定用於媒體傳輸的媒體傳遞事件位置
CN106165434B (zh) 一种用于获取媒体数据的方法及计算机可读介质
JP6545804B2 (ja) オーバージエアブロードキャストメディアデータに関するセッション記述情報
EP1897326B1 (en) Transport mechanisms for dynamic rich media scenes
US9900166B2 (en) Methods for delivery of flows of objects over broadcast/multicast enabled networks
CN100583880C (zh) 用于广播多媒体内容的系统
US10560866B2 (en) Method of handling packet losses in transmissions based on DASH standard and FLUTE protocol
Walker et al. ROUTE/DASH IP streaming-based system for delivery of broadcast, broadband, and hybrid services
JP2017528022A (ja) ネットワークを介して交換されたファイルのためのエラー処理
US20210306703A1 (en) Determination of availability of chunks of data for network streaming media data
KR101855327B1 (ko) 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20140910