CN113169969A - 多播到单播转换 - Google Patents

多播到单播转换 Download PDF

Info

Publication number
CN113169969A
CN113169969A CN201980078710.7A CN201980078710A CN113169969A CN 113169969 A CN113169969 A CN 113169969A CN 201980078710 A CN201980078710 A CN 201980078710A CN 113169969 A CN113169969 A CN 113169969A
Authority
CN
China
Prior art keywords
packet
unicast
multicast
segment
packets
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
CN201980078710.7A
Other languages
English (en)
Inventor
R·特恩布尔
T·史蒂文斯
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.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
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 British Telecommunications PLC filed Critical British Telecommunications PLC
Publication of CN113169969A publication Critical patent/CN113169969A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/765Media network packet handling intermediate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1881Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with schedule organisation, e.g. priority, sequence management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/70Media network packetisation

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

提出了用于将多播媒体流转换为单播段以在诸如因特网的通用IP网络上传送的方法。单播段可以被再次转换回多播流,该多播流与更接近消费客户端设备的原始多播流相同。从生成的单播段重新生成与原始多播流相同的多播流所需的附加信息也被编码到生成的单播段的文件名中。此外,当生成单播段时不需要的来自多播流的RTP头信息被存储在链接到生成的单播段的文件中,从而即使在RTP级别,也可以使重新生成的多播流与原始多播流相同。

Description

多播到单播转换
技术领域
本发明涉及多播到单播转换的领域,并且具体地涉及从多播流生成可以被转换回原始多播流的相同副本的单播段。
背景技术
当前,当通过IP网络传送时,诸如直播电视频道的线性媒体传送使用两种完全不同的联网技术中的一者:一种基于多播,而另一种基于单播。通过多播传输,将承载内容的单个多播流同时从内容服务器推送到多个网络节点,这些网络节点复制内容并根据需要转发到任何后续节点或客户端。在单播传输的情况下,通常使用TCP上的HTTP从服务器拉取多个内容流,每个消耗该内容的设备的一个流。
当同时向许多终端设备传送相同的内容时,多播有效地利用网络。然而,无论观看的量如何,通常需要对网络资源进行连续分配,使得即使实际上没有人观看频道,也要通过网络传该送频道。另外,目前并非所有的终端设备(诸如,某些平板计算机和智能手机)都支持多播。类似地,并非所有网络都设置为支持多播。
单播需要通过网络发送相同频道内容的多个副本,但是不需要网络资源的使用无关的分配。然而,如果预期某个频道的观众较少,则取而代之地通过单播传送该频道可能在整体上更有效率。这意味着对于网络的没有观看者的那些部分,频道不会被传送,并且网络容量可以重新使用。单播还能够传送到几乎所有终端设备。
IPTV服务(诸如,申请人的BT TV服务)可以使用多播通过宽带传送到机顶盒(STB)。BT TV包含约140个线性频道和一系列点播内容。线性频道是通过专用IP多播网络传送的。然而,并行单播网络被用于向其他设备(诸如,智能电话和平板计算机)进行传送,因为这些设备中的许多设备本身都不支持多播,并且在大多数情况下,支持的移动网络可能不具有多播支持。
多播网络和单播网络是分开的,这些技术已经独立发展并大量地使用了不兼容的媒体格式,即使原始视频是相同的,对于多播和单播来说,编码、打包、格式化和加密也是不同的。
因此,具有以下解决方案将是有益的:允许选择是通过多播还是单播来承载视频,而终端客户端无需了解视频所采用的路由,并且能够随着观众规模变化而在两者之间进行切换。
发明内容
本发明的实施方式的目的是提供一种从多播流生成单播段的方法,所述单播段可以被转换回多播流的原本。
根据本发明的一个方面,提供了一种将多播流分割成单播段的方法,所述方法包括:
接收包括多个传输流分组的多播流;
生成包括从多播流获取的传输流分组的多个单播段,其中,每个传输流分组包括报头部分和有效载荷;以及
针对每个单播段生成文件名,其中,每个给定单播段的文件名包括从该单播段中的一个或更多个传输流分组的报头部分得到的数据。
多播流可以包括实时传输协议分组,并且实时传输协议分组包括多个传输流分组。
该方法还可以包括使用来自单播段的文件名的数据,从多个单播段生成另一多播流。
根据任何前述权利要求所述的方法,其中,每个生成的单播段中的传输流分组包括随机接入指示符,并且所述文件名数据包括包含所述随机接入指示符的所述传输流分组的偏移量。
随机接入指示符的偏移量可以参考相应的实时传输协议分组的开始来测量。
每个生成的单播段中的传输流分组可以包括节目时钟参考字段,并且文件名数据可以是节目时钟参考字段的值。
从多播流获取的传输流分组被顺序写入到生成的单播段中。然而,来自多播流的一个或更多个传输流分组可能未被写入单播段,并且文件名数据可以包括未被写入的一个或更多个传输流分组的偏移量。未被写入的一个或更多个传输流分组可以包括节目分配表或节目映射表。
根据本发明的第二方面,提供了一种将多播流分割成单播段的模块,所述模块在使用中用于:
接收包括多个传输流分组的多播流;
生成包括从多播流获取的传输流分组的多个单播段,其中,每个传输流分组包括报头部分和有效载荷;以及
针对每个单播段生成文件名,其中,针对给定单播段生成的文件名包括从该单播段中的一个或更多个传输流分组的报头部分得到的数据。
附图说明
现在将仅以举例的方式参考附图更好地理解本发明,其中:
图1是本发明的示例中的布置的网络图;
图2示出了示例RTP-TS分组的分组结构;
图3是概述在“启动状态阶段”中本发明的示例的步骤的流程图;
图4是概述在“稳定状态阶段”中本发明的示例的步骤的流程图;
图5示出了示例RTP流和生成的单播段。
具体实施方式
本文中参考特定示例描述了本发明。然而,本发明不限于这些示例。
本发明的示例提出了将多播媒体流转换为单播段的方法,所述单播段可以通过诸如公共互联网之类的通用IP网络来传送。单播段可以被再次转换回多播流,该多播流与更接近消费客户端设备的原始多播流相同。这样,客户端将不知道转换,因此不需要进行任何修改即可消耗重新生成的多播流。用于帮助单播流和原始多播流之间无缝切换的信息被编码到生成的单播段的文件名中。从所生成的单播段重新生成与原始多播流相同的多播流所需的附加信息也被编码到所生成的单播段的文件名中。此外,在生成单播段时不需要的来自多播流的RTP报头信息被存储在链接到生成的单播段的文件中,从而即使在RTP级别,也可以使重新生成的多播流与原始多播流相同。
由于多播-单播-多播转换过程导致原始多播流的精确再生成,因此网络智能可以决定是通过多播网络还是通过单播网络来承载业务,而不会给现有的仅多播服务的客户端设备造成问题。最终的单播到多播转换步骤可以在例如家庭网关中执行。这也将允许在传送模式之间进行动态切换,以在使用单播和多播网络的方式上提供更大的灵活性。
所生成的单播段是符合标准的HLS,因此原则上可以在仅单播的设备(诸如,平板计算机、智能手机和计算机)上播放。
图1示出了本发明的示例中的网络布置100。网络100包含被布置成对诸如与线性TV频道相关联的视频和音频流的媒体内容进行编码并将其发送到客户端设备的元件。取决于客户端设备支持单播还是多播,媒体被承载为单播业务或者多播业务。本发明的示例提出了多播分割模块120,其可以将多播流分割成可通过单播网络发送的单播段。切换模块115可以将那些单播段重新组合成原始多播段(单播段是从原始多播段生成的)的精确副本,并控制原始单播流和再生成的多播流之间的切换。以下描述列出了作为整体的网络的一般操作以及多播分割模块120和切换模块115的特定操作。
网络100包括线性视频源102,该线性视频源102以与直播TV频道相关联的未压缩视频和音频流的形式生成媒体内容。实际上,线性视频源可以提供与多个TV频道相关联的媒体内容,但是为了简单起见,本发明的示例的操作将描述与单个频道相关联的内容。
与频道相关联的未压缩的视频和音频流被传递到编码器104。编码器104对未压缩的视频进行编码以生成编码的视频流。在该示例中,所使用的视频编码方法是根据ITUH.264标准的,本发明不限于这样的标准,并且可以替代地使用其他视频编码方法。编码器104还对未压缩的音频执行音频编码以生成编码的音频流,编码的音频流与编码的视频流复用。
编码器104还执行将编码的视频和音频流打包成多路复用的格式,诸如ISO/IEC13818-1中指定的MPEG-2传输流,该多路复用的格式通常用于多播流。MPEG-2传输流由一系列传输流分组(在此称为TS分组)组成。每个TS分组承载184个字节的有效载荷数据,并以4字节的报头作为前缀。因此,可能需要数百甚至数千个TS分组来承载持续时间为一秒的视频内容,尽管这将在很大程度上取决于用于对内容进行编码的比特率。
TS分组包含各种不同的数据类型(基本流和表),这些数据类型承载在TS分组的有效载荷部分中。基本流承载代表正在被流传输的媒体的视频、音频、字幕等。典型的节目或媒体序列将具有一个视频基本流和几个音频基本流(因为通常有多个音轨),每个基本流都需要非常大量的TS分组。另外,还存在元数据,元数据被表示为表(Table),并提供了对于理解TS分组中承载哪些数据来说重要的信息。其他表将包含节目指南数据、服务标识信息等。每个TS分组将仅包含一个数据类型(基本流或表)。
TS分组可选地被传递到内容保护模块106,内容保护模块106可以使用合适的条件访问***(CAS)技术来应用内容保护,并且对TS分组有效载荷部分进行加密。TS分组报头保持未加密。所得的TS分组被传递到封装模块108。
在该示例中,封装模块108使用RTP(实时传输协议)对TS分组进行封装。具体地,TS分组被承载封装在RTP分组的有效载荷部分中。来自封装模块108的输出是RTP分组的流,所述RTP分组的流有效地形成了多播流。
图2示出了示例RTP分组200及其所承载的基础TS分组的分组结构。
RTP分组200由长度为12个字节的RTP报头部分202和随后的有效载荷部分204组成。在此示例中,有效载荷部分由7个TS分组(204a–204g)组成,每个分组长188个字节,导致RTP分组的总大小为12+7*188=1328个字节。
如前所述,每个TS分组包括4个字节长的TS报头部分210和184个字节长的TS有效载荷部分212。TS头210总是未加密的,这使得本发明的示例即使在已经采用CAS的情况下也可以使用存储在其中的某些数据。
TS报头210包括以下字段:同步字节SB 220(8位长)、传输错误指示符TEI 222(1位)、有效载荷单元开始指示符PUSI 224(1位)、传输优先级TP 226(1位)、分组标识符PID228(13位)、传输加扰控制TSC 230(2位)、自适应字段控制AFC 232(2位)、连续性计数器CC234(4位)。如果在AFC中用信号通知,则TS报头210还可以在连续性计数器字段之后包括(可变长度的)自适应字段。适应字段可以包含各种附加字段。图中已经示出了两个选定的附加字段(为简单起见,其他字段已省略)-随机接入指示符RAI 238(1位)和节目时钟参考PCR240(42位),这两个字段均用于本发明的示例中。
PID被分配给每个基本流或表。因此,与给定基本流相关联的所有TS分组将具有分配给该基本流的相同PID。MPEG-2传输流中始终存在的两个表是单个节目关联表(PAT)和一个或更多个节目映射表(PMT)。总是将包含PAT的TS分组分配为零的PID。PAT包含每个频道或节目的指示该频道或节目的PMT使用的PID的条目。给定频道的PMT包含与该频道相关联的所有基本流的PID。PAT和PMT位于相应TS分组的有效载荷中。
因此,包含PAT和PMT的TS分组对于允许客户端解码器了解所有TS分组包含什么来说至关重要。解码器必须在该解码器能够使用从PAT获得的PMT的PID识别包含PMT的分组之前,首先接收带有PAT(PID=0)的TS分组,并且因而解码流的其余部分的内容。在没有PAT和PMT的情况下,其余流实际上是没有意义的,因为解码器不知道每个分组中有什么。PAT和PMT通常以~200ms的间隔周期性地出现在多播流中。
PCR 240在自适应字段中至少每100ms出现一次。PCR 240用于得到***定时时钟,并且是使用27MHz***时钟测量的。随机接入指示符238是指示当前TS分组具有一些信息以帮助从该点开始的随机接入的标志。PCR 240和随机接入指示符238都位于自适应字段中。标准规范还指出,如果存在PCR字段,则只能将RAI标志设置为T。因此,如果RAI标志被设置为T,则PCR 240将总是存在。
连续性计数器234对于每个PID是唯一的,并且对于与PID相关联的每个TS分组单调递增,在达到其最大值之后包装(wrap)为零。
RTP报头202还包含各种字段。这些字段包括从传输流PCR得到的时间戳和序列号,所述序列号允许客户端检测RTP分组丢失或重新排序(因为基础UDP传输是不可靠的)。
参考回图1,离开封装模块108的多播流被适当地格式化以用于多播传输。该多播流被传递到多播摄取服务器110以及多播分割模块120。
多播摄取服务器110接收多播流,并控制多播流到多播传送网络112上的传送。经由家庭网关114中的切换模块115,将多播流通过多播网络112传送到诸如机顶盒(STB)之类的支持多播的设备116。家庭网关114使用例如DSL连接来连接到多播网络以及诸如因特网的其他网络。诸如多播设备116之类的客户端设备可以通过局域网连接到家庭网关114。
因此,多播客户端116可以订阅并接收通过多播网络112从多播摄取服务器110传送的多播流中的多播媒体内容。
然而,如前所述,使用单播传送通过标准因特网连接传送内容将是有益的。因此,可以根据需要在单播或多播之间执行动态切换。
为了实现这一点,提供了多播分割模块120,该多播分割模块120根据从封装模块108接收到的多播流生成单播段。生成的单播段符合RFC8216中规定的Apple的HLS(HTTP直播流传输)协议,因此可以在符合HLS单播的客户端设备(诸如,智能手机或平板计算机126)上重放。此外,单播段可以被切换模块115用来重新生成原始多播流的相同副本,该切换模块115优选地位于家庭网关114中。然后,可以将重新生成的多播流从家庭网关114传送到多播设备116。
由多播分割模块120生成的HLS段被传递到单播源服务器122。还会生成播放列表或“m3u8”清单文件,所述播放列表或“m3u8”清单文件包含生成的单播段的顺序列表。单播段通常被存储在与清单相同的位置(在这里是源服务器122),如果不是,也可以在清单中明确声明。每当生成新的单播段时,清单都会被更新。通常将最旧的片段引用从清单的顶部去除,而将新的片段引用添加到底部。通常,清单包含对五个或六个片段的引用,这些片段本身保存着2到5秒之间的媒体内容。为了对内容进行流传输,单播客户端读取清单并按顺序对每个片段发出“HTTP GET”请求。客户端将片段连接起来,以在播放期间重新形成连续的流。
使用HLS进行单播传送的优点是HLS遵循与用于多播流相同的通用MPEG-2传输流格式,从而促进了从多播到单播的转换。本质上,HLS段是由多播流中使用的相同TS分组组成的,其中,每个HLS段通常包括大量的TS分组。然而,当将多播流分割为多个单播段时,需要考虑一些重要因素。
为了使所得到的单播段符合HLS并且可以在单播设备上播放,不能通过对(TS分组的)多播流进行任意分割来生成单播段。如前所述,为了使客户端处理TS分组,必须首先找到PAT和PMT表并进行处理。提出了用于捕获所需的PAT和PMT数据并生成包括所需的PAT和PMT数据的单播段的方法。
此外,即使存在所需的PAT和PMT数据,生成的单播段也不能以任意TS分组开始。代替地,新的单播段必须以标记有RAI标志的TS分组开始(在PAT和PMT分组之后),使得解码器能够在没有另外的信息的情况下开始解码。然而,RAI可能不存在于多播流中RTP报头之后的第一个TS分组中。
将参考图3和图4的流程图来描述与从多播流生成单播段有关的多播分割模块120的操作。
图3描述了在“启动状态阶段”期间的步骤,当多播分割模块120首先读取多播流时,TS分组被读取,直到找到单播段所需的所有起始分组为止。如前所述,符合HLS的片段所需的起始分组是包含PAT的TS分组、包含PMT的TS分组以及包含RAI的TS分组。
图4描述了在“稳定状态阶段”期间发生的步骤,该“稳定状态阶段”发生在图3的“启动状态阶段”之后。
图5示出了包括RTP分组的连续流的多播流的示例,其中,每个RTP分组包括RTP报头和多个TS分组(例如,RTP报头500和TS分组502至514)。图5还示出了示例HLS段以及从RTP分组到生成的HLS段的TS分组之间的映射。
现在将参考图3和图4的流程图来描述多播流到HLS(单播)段的分割。
以图3开始。在步骤300中,在多播分割模块120处接收多播流。
在步骤302中,生成空清单,并将其存储在源服务器122中,以供以后与所生成的单播段一起使用。
在步骤304,处理第一RTP分组及其内容(TS分组)。RTP报头(例如,图5中的500)被存储在临时存储部中,以便稍后写入文件。在启动状态阶段期间的任何时间仅存储一个RTP报头,导致在步骤322中仅一个RTP报头被写入文件。如稍后将描述的,一旦处理移至稳定状态阶段,则可以临时存储多于一个的RTP报头。因此,如果处理循环回到步骤304,其中,需要存储另一个RTP报头,则将有效地删除任何先前存储的RTP报头。
在步骤306,处理TS分组。当首先开始处理时,对已读取的RTP分组中的第一个TS分组进行处理。以图5为例,正在处理的第一个TS分组是502。在步骤308,进行检查以确定正在处理的TS分组是否包含PAT或PMT。如果TS分组包含PAT或PMT,则该TS分组在处理进入步骤310之前被存储。在该示例中,TS分组502不包含PAT或PMT,因此处理继续到步骤310而未存储TS分组。接下来在步骤310中,进行检查以确定TS分组是否包括RAI标志集。如果不存在RAI,则处理进行到步骤312,以检查当前的TS分组是否是正在被处理的RTP分组中的最后一个TS分组。如果不是最后一个TS分组,则在循环回到步骤306以处理下一个TS分组之前,处理在步骤314移至下一个TS分组。如果是最后一个TS分组,则在循环回到步骤304以处理该RTP分组之前,处理在步骤316中移至多播流中的下一个RTP分组。
因此,对于不包含PAT、PMT或RAI的TS分组502,处理简单地循环回到步骤306以处理下一个分组(TS分组504),从而有效地丢弃TS分组502。下一个分组TS(分组504)确实包含PAT,因此在处理循环回到步骤306以处理下一个TS分组506之前,该分组被临时存储(以便稍后写入生成的HLS段)。下一个分组TS分组506不包含PAT、PMT或RAI,因此处理循环回到步骤306以处理下一个分组(TS分组508),从而有效地丢弃TS分组506。TS分组508包含PMT,使得在处理循环回到步骤306以处理下一个TS数据包510之前存储该分组。接下来的两个分组(TS分组510和512)均不包含PAT、PMT或RAI,因此处理循环回到步骤306以处理下一个分组(TS分组514),从而有效地丢弃TS分组510和512。
现在,TS分组514确实包含RAI,因此当处理到达步骤310以检查是否存在RAI时,答案为是,则处理进行到步骤318。
在步骤318中,存储具有RAI的TS分组(TS分组514),并且进行检查以确定是否已经发现了PAT和PMT二者。在该示例中,它们具有(TS分组504和508,并且被存储在步骤308的较早的循环中)。处理然后进行到步骤320。然而,如果尚未发现PAT和PMT,则处理返回到步骤312。
因此,循环执行步骤304至318的处理,直到全部找到所需的PAT、PMT和RAI的起始TS分组为止。一旦已经找到这些TS分组,处理就跳出循环并进入步骤320,以开始将所需的起始分组以及接着将随后的TS分组写入新的HLS段的过程。
在步骤320中,从包含RAI的当前TS分组读取PCR值(注意,当存在符合标准的RAI时,PCR字段将始终存在)。
在步骤322中,将从步骤304临时存储的RTP报头写入RTP文件。稍后将对此方面进行讨论。注意,由于在步骤304中仅存储了一个RTP报头,所以此时仅将一个RTP头写到RTP头文件中。然后清除临时存储。
在步骤324中,计算并存储RTP分组中的RAI TS分组的偏移量。在RAI TS分组514的该示例中,其偏移量是7,也就是说,具有RAI的TS分组是RTP分组中的第7个TS分组。
在步骤326中,生成HLS段文件名。如前所述,用于帮助在生成的单播流与原始多播流之间切换的附加信息被编码到生成的单播段的文件名中。从生成的单播段重新生成与原始多播流相同的多播流所需的附加信息也被编码到生成的单播段的文件名中。
在本发明的示例中,将五条信息或五个字段编码为段文件名:
1.基本名称,例如,Btbarker
2.PCR值,例如,1055988510639
3.RTP帧内的起始TS分组(即,RAI分组)的偏移量,例如7
4.已经去除了第一个PAT的位置,例如,3
5.已经去除了第一个PMT的位置,例如,5
这五个字段可以被连接成得到的文件名。在此示例中,文件名将是:Btbarker_1055988510639_5_3_5.ts
注意,上面显示的值仅是示例,实际上,某些值可能会完全不同。特别是,PAT和PMT偏移量可能会显著更大。
现在将讨论每条信息的相关性。请注意,PAT/PMT位置直到该过程的后期才可用。
以基本名称开头,这是在文件名开头使用的任意名称。
切换模块115使用PCR值来使重新生成的多播流与原始多播流同步,以实现两者之间的无缝切换。PCR是在所述流中每隔100ms出现的高分辨率时钟,并且是在步骤320中从TS分组报头获得的。PCR被编码在HLS段文件名中,使得只要该段被读取就向切换模块115提供PCR。实际上,切换模块115只要已经读取了具有HLS文件名的清单,并且进一步地当其已经读取了HLS文件本身时,就会知道正确的PCR。
这意味着切换模块115可以发起无缝切换,而不必对在HLS段的各个TS分组内发现的PCR进行解码。还允许在多个位置发生分割,并确保文件名保持一致,这对于定位正确的RTP报头来说很重要,这将在后面讨论。
重新生成的多播流与原始多播流之间的同步是在两个流中都有匹配的PCR值的同步点处。
然而,从HLS文件名知道PCR意味着无需立即开始从HLS段重新生成多播流,直到发现与原始多播流具有匹配的PCR值的HLS段为止。这避免了在到达同步点之前不得不可能重新生成不需要的大量RTP分组。
RTP帧内的起始TS分组的偏移量也被编码在文件名中。也就是说,如在步骤324中获得的,包含RAI的TS分组的偏移量。偏移量是切换模块115重构原始多播流的准确副本所需要的。
最后,对第一个PAT和第一个PMT分组已被去除的位置进行编码。但是,这些在此阶段不可用。这些分组的去除及其意义将在稍后参考图4进行描述。
因此,在步骤326的该阶段,文件名将缺失被去除的PAT和PMT位置,但是其他信息将是可用的,因此可以使用该信息生成文件名。因此,在基本文件名是“Btbarker”的情况下,PCR是1055988510639,RAI偏移量是7,则生成的HLS文件名是Btbarker_1055988510639_7.ts。当已经去除了以下PAT和PMT分组时,将在以后添加已去除的PAT和PMT位置的缺失信息。
回到图3的流程图,在步骤328中,使与所存储的PAT相关联的连续性计数器CC和与所存储的PMT相关联的连续性计数器CC增加。这是因为我们正在写到HLS段的PAT/PMT是正在使用的RAI之前的更早的PAT/PMT。可以代替地使用下一PAT和PMT对(即,分组522和526),但这将需要对从RAI 514开始的中间TS分组进行缓冲,直到已经读取了分组522和526为止。代替地,此处选择的解决方案是使用已可用的PAT和PMT(分组504和508),并去除下一PAT和PMT(分组522和526),同时使针对所使用的PAT和PMT(分组504和508)的连续性计数器增加以确保所使用的连续性计数器与本应使用但现在将被删除的对的那些连续性计数器匹配。
在步骤330中,将在步骤308中存储的包含PAT的TS分组写入新的HLS段,给予新的段在步骤326中生成的文件名。参考图5,其示出包含来自多播流的PAT的、被写入新的HLS段的TS分组504。
随后在步骤332中,其中,将在步骤308中存储的包含PMT的TS分组接着写入HLS段(在PAT TS分组之后的紧邻位置)。再次,参考图5,其示出包含来自多播流的PMT的、被写入新的HLS段的TS分组508。
然后,在步骤334中,将在步骤318中存储的包含RAI的TS分组写入HLS段(位于PMTTS分组之后)。再次,参考图5,其示出包含来自多播流的RAI的、被写入新的HLS段的TS分组514。
处理然后进行到步骤336,并到图4上的步骤400,在步骤400从RTP段复制剩余的TS分组,直到生成的HLS段处于所需的持续时间为止。
图4所示的方法的步骤涵盖“稳定状态阶段”,其中,来自多播流的后续TS分组被写入新的HLS段,直到生成的HLS段的持续时间达到期望的预定持续时间为止。之后,将生成新的HLS段。
从步骤400开始,处理进行到步骤412,在步骤412进行检查以确定正在被处理的当前TS分组是否是RTP分组中的最后的TS分组。如果它不是最后的TS分组,则在处理进行到步骤404以处理下一个TS分组之前,处理将在步骤414移至RTP分组中的下一个TS分组。如果它是最后的TS分组(在此示例中,TS分组514正在被处理,并且是最后的分组),则在进行到步骤402之前,处理在步骤416中会移至多播流中的下一个RTP分组。在步骤402,读取RTP分组及其内容(TS分组)。在处理进行到步骤404之前,RTP报头(在此示例中,RTP报头是图5中的元素516)被存储在临时存储器中以供稍后使用。注意,现在可以临时存储多于一个RTP报头,因此,如果处理循环回到该点,则可以临时存储其他RTP报头。
在步骤404,处理TS分组。在图5的示例中,当前TS分组是TS分组518。在步骤406,进行检查以确定TS分组是否包含PAT或PMT。如果TS分组不包含PAT或PMT,则处理继续到步骤418,在步骤418,进行检查以确定TS分组是否包括RAI标志集。如果不存在RAI,则在确定要处理的下一个TS分组之前,在返回到步骤412以检查当前TS分组是否是RTP分组中的最后的分组之前,处理进行到步骤420以将当前TS分组写入到生成的HLS段。步骤406、步骤418和步骤420的效果是在类似地处理下一个TS分组之前,任何不包含PAT、PMT或RAI的TS分组将被添加到HLS段。因此,在图5的示例中,因为TS分组518和520不包含PAT、PMT或RAI,所以它们二者被直接写入HLS段。
要处理的下一个TS分组是确实包含PAT的TS分组522。
因此,当处理到达步骤406,在步骤406进行检查以确定是否存在PAT或PMT时,TS分组522是PAT,因此处理进行到步骤408。在步骤408中,进行检查以确定PAT或PMT是否是起始PAT或PMT之后的第一个PAT或第一个PMT(来自步骤308/330/332以及分组504和508)。如果是,则处理进行到步骤410,在步骤410,存储PAT或PMT的偏移量。
PAT和PMT偏移量可以通过多种方式进行测量。一种方法是参考当前HLS段的开始,或者换句话说,如果接下来要写入,则是PAT或PMT分组将在当前HLS段中所位于的位置。在第二种方法中,可以参考RTP流中的起始RAI分组,或者换句话说,PAT TS分组相对于起始RAI分组的位置(仅对TS分组进行计数,不包括RTP报头)。
回到示例TS分组522,这是起始PAT之后的第一个PAT(分组504),并且因此在处理经由步骤412移至下一个TS分组之前,存储PAT分组的偏移量。使用参考HLS段的开始的第一种方法,PAT偏移量将为6。使用参考起始RAI分组的第二种方法,PAT偏移量将为3。这里,使用了第二种方法。因此,在起始PAT PMT之后具有第一PAT/PMT的TS分组不被写入HLS段,而是仅存储偏移量以供稍后使用(参见图5中的分组522)。
然而,如果在步骤408中,PAT/PMT不是起始PAT/PMT之后的第一个分组,则处理进行到步骤417,在步骤417存储PAT/PMT TS分组。注意,在任何一次,仅存储一个PAT TS分组和一个PMT TS分组。因此,后面的PAT和PMT TS分组将覆写以前存储的PAT和PMT TS分组。存储这些PAT和PMT TS分组的目的是,它们是生成的下一个HLS段的开始所必需的。
处理转到步骤418,并且如上所述地继续进行。因此,如果TS分组是PAT或PMT,并且不是在起始PAT或PMT之后的第一个分组,则在步骤420中将该TS分组写入HLS段。
存储起始PAT分组和PMT分组之后的第一个PAT分组和PMT分组的偏移量的目的是,不将起始分组之后的这些第一个分组写入生成的HLS段。实际上,使用了较早的一组PAT/PMT分组(参见分组504和508)。因此,删除这些“第一个”PAT和PMT分组以平衡输出的分组数量。然而,从步骤410存储的偏移量允许将这些“删除”的PAT和PMT分组被重新***到重新生成的多播流中的正确位置。
要处理的下一个数据分组是TS分组524,TS分组524中不包含PAT、PMT或RAI。因此,TS分组524被写入HLS段。
在TS分组524之后,TS分组526被处理。这是在起始PMT之后的第一个包含PMT的TS分组,因此存储了偏移量,但未将TS分组写入HLS段。这里,使用了用于测量偏移量的第二种方法(根据PAT偏移),该方法参考了起始RAI分组,导致PMT偏移量为5。
然后,处理不包含PAT、PMT或RAI的TS分组528,并将其写入HLS段。
要处理的下一个TS分组是TS分组532(在读取新的RTP分组之后)。该TS分组包含RAI。因此,当处理到达步骤418时,发现存在RAI,并且处理进行到步骤422。
在步骤422中,从包含RAI的当前TS分组获得PCR值(如先前所讨论的,当存在根据标准的RAI时,PCR字段将总是存在)。
然后,在步骤424中,将来自步骤422的PCR值与来自步骤320的初始PCR值结合使用,以确定当前HLS段的持续时间是否至少等于预定目标持续时间。例如,目标持续时间可以是5秒钟,因此PCR值的差异必须至少等于5秒钟。
目的是在当前HLS段至少等于目标段持续时间时,以带有RAI的TS分组开始生成新的HLS段。否则,将继续写入当前段,直到下一个RAI分组和持续时间检查重复为止。
因此,在步骤424中,如果当前HLS段的持续时间不处于期望的持续时间,则处理返回到步骤420以在处理下一分组之前将TS分组写入HLS段。
然而,如果在步骤424,当前HLS段处于所需的持续时间,则处理移至步骤426。
在步骤426中,在完成RTP报头文件生成之前,关闭生成的HLS段,这有效地结束了该HLS段的生成。结果是生成的HLS段和关联的生成的RTP报头文件。
为了完成RTP报头文件(与步骤322相同的RTP报头文件)的生成,从临时存储器向其写入其他RTP报头。具体地,在从存储器中删除那些报头之前,除最新的条目外的所有RTP报头都将从临时存储器写入RTP文件。最新的条目保留在存储器中,以供稍后写入与要生成的下一个HLS段相关联的新RTP报头文件。然后,关闭RTP报头文件。RTP报头文件可以与HLS段一起存储在源服务器122中。
分配给RTP报头文件的名称采用特殊格式。在本发明的示例中,RTP报头文件名使用与已经生成的对应的新生成的HLS段相似的命名约定。用于RTP文件的命名约定可以使用HLS段文件名中使用的字段的子集,只要这些字段在组合时足以将RTP文件链接到正确的HLS段即可。一种方法是使用与用于相应HLS段文件名的PCR值连接的基本文件名,可以表示为:
<base_filename>_<PCR>.rtp
在此处的示例中,RTP文件名由此将为:
Btbarker_1055988510639.rtp
实际上,RTP头文件的文件名使用构成关联的HLS段文件名的字段或部分的子集。
以这种方式存储RTP头使得即使在RTP报头级别也可以使重新生成的多播流与原始多播流相同。此外,对链接到关联的HLS段文件名的RTP头文件名使用文件命名约定使得一旦已经识别了HLS文件名就可以直接从HLS文件名识别出正确的RTP文件。
实际上,可以使用链接到关联的HLS段名的任何文件名来命名RTP报头文件。因此,如果以不包括在步骤326中识别的所有字段的更一般的方式生成HLS段名,则该方法仍将起作用。关键方面是报头文件和HLS段文件的文件名例如通过共享公共唯一字段或唯一字段的子集而链接在一起。在此示例中,该唯一字段是PCR值。
在步骤428中,使用所存储的来自步骤410的PAT/PMT偏移量来重命名生成的HLS段文件名。回想一下,在步骤326中,只有基本名称、PCR和RAI偏移量是可用的,但是(在起始PAT和PMT分组之后的第一PAT和PMT的)PAT和PMT偏移量尚不可用。这些偏移量现在是可用的(从步骤410开始),因此可以添加到HLS段文件名中。偏移量与现有文件名连接在一起。在该示例中,PAT偏移量为3,并且PMT偏移量为5,导致HLS文件名Btbarker_1055988510639_7._3_5.ts。
在步骤430中,将包括文件位置的HLS段文件名添加到清单文件。客户端设备现在将能够在读取清单文件后定位HLS段。
在步骤432中,存储与当前TS分组相关联的当前RAI偏移量。
在步骤434中,连续性计数器CC针对所存储的PAT和PMT TS分组二者(来自步骤417)增加。
在步骤436中,生成新的HLS段。新的HLS段将所存储的PAT和PMT TS分组写入(具有增加的连续性计数器)。
在被从临时存储器中删除之前,存储在存储器中的剩余RTP报头被写入新的RTP文件。当读取其他RTP分组以填充新的HLS段时,该新的RTP报头文件将与其他RTP报头一起写入。在然后处理转向下一个TS分组之前,处理然后返回到步骤420,在步骤420,具有RAI的当前TS分组被写入HLS段,如先前所描述的。
结果,HLS段由多播分割模块120生成并且与来自多播流的TS分组一起被写入,总是以PAT、PMT和RAI TS分组开始。
生成的HLS段与清单文件一起被存储在单播源服务器122上。为了对内容进行流传输,客户端读取清单并按顺序对每个片段发出“HTTP GET”请求。客户端的示例包括单播设备126以及切换模块115,切换模块115在重新生成RTP分组以作为多播流传递到多播设备116之前对HLS段进行请求。重新生成的多播流与原始多播流相同。
切换模块115负责根据生成的HLS段和RTP报头文件重新生成多播流。
切换模块115通过对清单进行HTTP请求、然后对该清单进行解析并在HLS段出现时对HLS段进行HTTP请求来颠倒多播分割模块120执行的过程。切换模块115能够借助于RTP报头文件被类似地命名为关联的HLS段文件或与关联的HLS段文件共享相同名称的一部分的事实来识别关联的RTP报头。特别是,HLS段名和RTP报头文件名二者中的公共PCR允许将关联的文件链接起来。可以使用HTTP GET请求里获取RTP报头文件。
切换模块115使用来自RTP头文件的RTP头来创建正在被重新生成的RTP分组的RTP报头部分。
HLS段文件名中的RAI偏移量允许切换模块115将第一个TS分组放置在重新生成的RTP分组中的正确位置(在以上示例中的位置5)。切换模块115在HLS段的开始处发现PAT和PMT时读取并记住所述PAT和PMT,但不将它们写入重新生成的RTP分组中,直到达到HLS段文件名中编码的正确偏移量。
现在,下面是对RTP报头文件及其命名的进一步讨论。
尽管针对生成的HLS段用作单播的消耗不需要RTP报头,但重新生成原始多播流的精确副本时需要RT报头头。因此,在分割成HLS段期间,通过将RTP报头存储在使用与生成的HLS段类似的命名约定命名的文件中来保留RTP报头。实际上,仅PCR字段对于将HLS段与RTP报头文件进行匹配是至关重要的。这使得切换模块115能够从在清单中发布的HLS段名中推断出RTP文件名,并将RTP报头与适当的TS段配对以重新生成原始多播流。与尝试在切换模块115中生成RTP报头相比,这具有许多优点:
·减少家庭网关(切换模块115)的计算工作量
·从PCR推导RTP时间戳(在RTP标头中发现)并不是简单的,并且即使RFC2250中描述了RTP时间戳推导,也不一定会产生与原始流相同的时间戳
·确保与原始多播流的精确匹配。使在原始多播流与重新生成的多播流之间进行切换成为可能。它还消除了由于在头端生成的RTP报头与切换模块115处本地生成的RTP报头之间的不兼容性而导致的任何其他潜在问题。
·将它们存储在以与相应HLS段相同的PCR命名的RTP报头文件中可使对齐变得简单。
以下是来自HLS清单中的示例碎片,示出了5个HLS段:
#EXTM3U
#EXT-X-VERSIONS
#EXT-X-TARGETDURATION:4
#EXFINF 4.41
Btbarker_1055988510639_2_129_346.ts
#EXFINF 4.15
Btbarker_1056107672303_3_355_124.ts
#EXFINF 4.80
Btbarker_1056219849499_0_159_341.ts
#EXFINF 4.34
Btbarker_1056349369182_5_149_324.ts
#EXFINF 4.99
Btbarker_1056466469070_1_51_254.ts
...
在此示例中,清单中未列出对应的RTP报头文件(Btbarker_1055988510639.rtp等),但是了解此方法的客户端将知道需要取来什么作为单播的一部分来进行多播重新生成。常规的HLS客户端不知道要这样做,而只能请求并播放单播HLS段文件。
一般而言,在本文中注意到,尽管以上描述了本发明的示例,但是在不脱离所附权利要求所限定的本发明的范围的情况下,可以对所描述的示例进行多种变型和修改。本领域技术人员将认识到对所描述的示例的修改。

Claims (10)

1.一种将多播流分割成单播段的方法,所述方法包括:
接收所述多播流,所述多播流包括多个传输流分组;
生成包括从所述多播流获取的传输流分组的多个单播段,其中,各个传输流分组包括报头部分和有效载荷;以及
针对所述单播段中的各个单播段生成文件名,其中,各个给定单播段的文件名包括从该单播段中的所述传输流分组中的一个或更多个传输流分组的所述报头部分得到的数据。
2.根据权利要求1所述的方法,其中,所述多播流包括实时传输协议分组,并且所述实时传输协议分组包括所述多个传输流分组。
3.根据权利要求1或2所述的方法,所述方法还包括:
使用来自所述单播段的所述文件名的数据,根据所述多个单播段生成另一多播流。
4.根据前述权利要求中任一项所述的方法,其中,各个生成的单播段中的传输流分组包括随机接入指示符,并且所述文件名的数据包括包含所述随机接入指示符的所述传输流分组的偏移量。
5.根据从属于权利要求2时的权利要求4所述的方法,其中,所述随机接入指示符的偏移量是关于相应的实时传输协议分组的开始来测量的。
6.根据前述权利要求中任一项所述的方法,其中,各个生成的单播段中的传输流分组包括节目时钟参考字段,并且所述文件名的数据是所述节目时钟参考字段的值。
7.根据前述权利要求中任一项所述的方法,其中,从所述多播流获取的所述传输流分组被顺序写入所生成的单播段中。
8.根据权利要求7所述的方法,其中,来自所述多播流的一个或更多个传输流分组未被写入所述单播段,并且所述文件名的数据包括还未被写入的一个或更多个传输流分组的偏移量。
9.根据权利要求7所述的方法,其中,所述一个或更多个传输流分组包括节目分配表或节目映射表。
10.一种将多播流分割成单播段的模块,所述模块被适配为在使用时:
接收所述多播流,所述多播流包括多个传输流分组;
生成包括从所述多播流获取的传输流分组的多个单播段,其中,各个传输流分组包括报头部分和有效载荷;
针对所述单播段中各个单播段生成文件名,其中,针对给定单播段生成的所述文件名包括从该单播段中的所述传输流分组中的一个或更多个传输流分组的所述报头部分得到的数据。
CN201980078710.7A 2018-11-30 2019-11-28 多播到单播转换 Pending CN113169969A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP18209653.7 2018-11-30
EP18209653 2018-11-30
PCT/EP2019/082950 WO2020109491A1 (en) 2018-11-30 2019-11-28 Multicast to unicast conversion

Publications (1)

Publication Number Publication Date
CN113169969A true CN113169969A (zh) 2021-07-23

Family

ID=64572129

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980078710.7A Pending CN113169969A (zh) 2018-11-30 2019-11-28 多播到单播转换

Country Status (4)

Country Link
US (1) US20220131921A1 (zh)
EP (1) EP3888318A1 (zh)
CN (1) CN113169969A (zh)
WO (1) WO2020109491A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020109496A1 (en) 2018-11-30 2020-06-04 British Telecommunications Public Limited Company Multicast to unicast conversion

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102598691A (zh) * 2009-11-03 2012-07-18 瑞典爱立信有限公司 利用数据分段的可选广播传送的流传输
CN102948159A (zh) * 2010-05-28 2013-02-27 高通股份有限公司 使用文件***提取、广播调度消息和选择性接收的通过广播网络的文件传递
US20140123199A1 (en) * 2012-10-30 2014-05-01 Kt Corporation Content relaying scheme
CN105052159A (zh) * 2013-03-19 2015-11-11 索尼公司 内容提供设备、内容提供方法、程序、和内容提供***
CN105340280A (zh) * 2013-07-02 2016-02-17 索尼公司 内容供应装置、内容供应方法、程序、终端装置及内容供应***
US20170127147A1 (en) * 2014-03-31 2017-05-04 British Telecommunications Public Limited Company Multicast streaming
CN107113461A (zh) * 2014-12-24 2017-08-29 英特尔公司 媒体内容流
CN107852534A (zh) * 2015-07-09 2018-03-27 思科技术公司 在广播流和单播流之间转换
CN108370281A (zh) * 2015-12-02 2018-08-03 瑞典爱立信有限公司 流式传输内容的多播传送的数据速率适配
CN108702527A (zh) * 2015-12-15 2018-10-23 瑞典爱立信有限公司 用于使用通用夹层分发格式的媒体传送的***和方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4407007B2 (ja) * 2000-05-02 2010-02-03 ソニー株式会社 データ送信装置及び方法
US7133922B1 (en) * 2000-08-07 2006-11-07 The Hong Kong University Of Science And Technology Method and apparatus for streaming of data
US8270425B2 (en) * 2009-12-29 2012-09-18 Symbol Technologies, Inc. Method and system for multicast video streaming over a wireless local area network (WLAN)
US9787751B2 (en) * 2014-08-06 2017-10-10 At&T Intellectual Property I, L.P. Method and apparatus for delivering media content utilizing segment and packaging information
WO2016107733A1 (en) * 2014-12-31 2016-07-07 British Telecommunications Public Limited Company Improved multicast to unicast conversion

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102598691A (zh) * 2009-11-03 2012-07-18 瑞典爱立信有限公司 利用数据分段的可选广播传送的流传输
CN102948159A (zh) * 2010-05-28 2013-02-27 高通股份有限公司 使用文件***提取、广播调度消息和选择性接收的通过广播网络的文件传递
US20140123199A1 (en) * 2012-10-30 2014-05-01 Kt Corporation Content relaying scheme
CN105052159A (zh) * 2013-03-19 2015-11-11 索尼公司 内容提供设备、内容提供方法、程序、和内容提供***
CN105340280A (zh) * 2013-07-02 2016-02-17 索尼公司 内容供应装置、内容供应方法、程序、终端装置及内容供应***
US20170127147A1 (en) * 2014-03-31 2017-05-04 British Telecommunications Public Limited Company Multicast streaming
CN107113461A (zh) * 2014-12-24 2017-08-29 英特尔公司 媒体内容流
CN107852534A (zh) * 2015-07-09 2018-03-27 思科技术公司 在广播流和单播流之间转换
CN108370281A (zh) * 2015-12-02 2018-08-03 瑞典爱立信有限公司 流式传输内容的多播传送的数据速率适配
CN108702527A (zh) * 2015-12-15 2018-10-23 瑞典爱立信有限公司 用于使用通用夹层分发格式的媒体传送的***和方法

Also Published As

Publication number Publication date
EP3888318A1 (en) 2021-10-06
US20220131921A1 (en) 2022-04-28
WO2020109491A1 (en) 2020-06-04

Similar Documents

Publication Publication Date Title
US10129609B2 (en) Method for transceiving media files and device for transmitting/receiving using same
US20210176506A1 (en) Apparatus and method for transmitting/receiving processes of a broadcast signal
CN107409234B (zh) 基于lct利用dash格式的基于文件格式的流式传输
US8527845B2 (en) System and method for ingesting media content in a peer-to-peer network
JP6317872B2 (ja) 異なるネットワークを介して受信したコンテンツのレンダリングを同期するデコーダ及びそれにおける方法
KR101797507B1 (ko) 미디어 컨텐트 송수신 방법 및 그를 이용한 송수신 장치
JP5086285B2 (ja) 映像配信システム,映像配信装置,及び同期補正処理装置
US20170127147A1 (en) Multicast streaming
US20090300673A1 (en) Peer- to- peer set-top box system
CN106034262B (zh) 自适应流媒体处理方法及装置
KR20170089863A (ko) 멀티미디어 및 파일 전송을 위한 전송 인터페이스
KR20140066265A (ko) 미디어 콘텐트 송수신 방법 및 그를 이용한 송수신 장치
US10666697B2 (en) Multicast to unicast conversion
CN102752669A (zh) 多通道实时流媒体文件的传送处理方法与***、接收装置
US11445000B2 (en) Multicast to unicast conversion
CN113169969A (zh) 多播到单播转换
WO2009080116A1 (en) Method and apparatus for distributing media over a communications network

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
AD01 Patent right deemed abandoned

Effective date of abandoning: 20240329

AD01 Patent right deemed abandoned