CN106464932A - 多播流传输 - Google Patents

多播流传输 Download PDF

Info

Publication number
CN106464932A
CN106464932A CN201580013610.8A CN201580013610A CN106464932A CN 106464932 A CN106464932 A CN 106464932A CN 201580013610 A CN201580013610 A CN 201580013610A CN 106464932 A CN106464932 A CN 106464932A
Authority
CN
China
Prior art keywords
block
multicast
content
fragment
chunk
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
CN201580013610.8A
Other languages
English (en)
Inventor
I·克拉布特里
M·尼尔森
R·特恩布尔
S·阿普尔比
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 CN106464932A publication Critical patent/CN106464932A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21Server components or server architectures
    • H04N21/218Source of audio or video content, e.g. local disk arrays
    • H04N21/2187Live feed
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383Accessing a communication channel
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/64Addressing
    • H04N21/6405Multicasting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/64Addressing
    • H04N21/6408Unicasting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84Generation or processing of descriptive data, e.g. content descriptors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提出了一种生成用于传输诸如直播电视这样的视频内容的多播流的方法。首先,视频内容被编码,并且被分段为时间块。取决于每个块的大小,所述块随后被封装在一个或者多个RTP包中,并且采用块标签来标记每一个RTP包,以指示块之间的边界位于包中的哪一个。随后通过封装该RTP包来生成多播流,优选地使用UDP将该RTP包封装在IP包中。通过在RTP有效载荷头部中的专用字段来提供该块标签。该块标签可以是块索引或者块偏移。两者可以被独立地和组合地用于确定块之间的边界。

Description

多播流传输
技术领域
本发明涉及多播流传输(multicast streaming)领域,并且具体地涉及用于与单播流同步的包括多个块的多播流的生成。
背景技术
当前通过IP网络传送的直播电视使用两种完全不同的网络技术中的一个:一个是基于多播的网络技术,并且另一个是基于单播的网络技术。采用多播传输,携带内容的单个多播流被从内容服务器同时推送到多个网络节点,这些网络节点复制所述内容,并且根据需要转发到任意后续节点或者客户端。采用单播传输,通常使用通过TCP的HTTP以及自适应比特率技术将多个内容流从该服务器拉出(pull),一个内容流用于每一个消耗内容的装置。
当在相同的时间将相同的内容传送给多个终端装置时,多播对网络进行了有效的使用,但是通常需要连续分配网络资源而不考虑观看量。此外,诸如一些平板电脑以及智能电话这样的很多终端装置当前不支持多播。
单播面临通过网络发送相同内容的多个副本,但是不需要网络资源的独立使用分配。此外,单播能够传送给所有终端装置,即使在存在到该终端装置的低的或者变化的网络吞吐量的情况下,这对于通过例如无线技术连接的装置是频繁发生的。
US专利申请2013/0024582描述了这样一种系统和方法,其用于响应于并发访问媒体内容的需求的变化而在媒体内容的单播传送和多播传送之间动态地切换。此外,包括在视频帧中的序列号被用于在单播流内容和多播流内容之间对齐(align)。
发明内容
本发明的实施方式的目的是,提供一种生成用于携带视频内容的多播流的、支持改进的切换到单播流的和从单播流切换的方法。
根据本发明的一个方面,提供了一种多播视频传送的方法,所述方法包括如下步骤:
接收编码的视频内容的多个片段,其中,每个片段包括编码的视频的多个帧;
生成多个传输协议包,其中,每个片段被携带在一个或者多个传输协议包的有效载荷中;
使用第一片段标识符来标记每个传输协议包,其中,第一片段标识符标识携带给定片段的一个或者多个传输协议包;
传输包括多个传输协议包的多播流。
第一片段标识符可以是与片段相关联的序列号,其中,对于不同的片段,序列号的值是不同的,并且使用与给定片段相关联的序列号来标记携带该片段的每个传输协议包。
该方法还可包括如下步骤:使用第二片段标识符来标记每个传输协议包,其中,该第二标识符是如下的偏移,该偏移包括如下数值,该数值随着携带给定片段的每个传输协议包而递增,并且对于新的片段的第一个包被重置。用于标记给定包的偏移可表示在针对给定片段的先前包中携带的数据的字节的总数。
片段标识符可以是传输协议有效载荷头部字段。传输协议可以是实时传输协议。
多播流可包括:使用用户数据报协议封装在IP包中的传输协议包。
可以以传输流块的形式来携带所述片段中的每一个,并且其中,每个传输流块包括多个传输流包。
本发明的示例允许多播和单播一起使用,相较于单独使用任一技术更加顺畅和有效地传送直播电视内容。通过标记块边界,改进了在多播和单播之间的切换,其在传输层级处完成,并且因此避免了需要检查视频内容本身以及需要在图片级的帧或者组来同步。
在另选的示例中,代理被引入到内容服务器和客户端之间的路径中,并且允许通过单播或者多播将内容传送到该代理。代理可位于路由器或者集线器中。根据各种因素来做出是否能够使用多播和单播的选择,例如网络条件、以及根据在观看该内容的客户端的总数量方面该内容被观看的受欢迎程度。代理与内容服务器通信从而确定该客户端请求的内容通过单播和/或多播是否是可用的。代理基于其对诸如到该客户端的网络吞吐量的因素的了解,来确定哪一种是最适合的使用形式,并且在选择多播传送的情况下,执行必要的功能,例如IGMP加入,从而接收多播流,缓冲多播流,并且随后能够多播流其作为单播资源呈现给客户端。通过这样做,可以针对受欢迎的内容使用多播传送到代理,其中,单播会低效率地使用网络容量,但是如果这些客户端不支持多播,还允许从代理到客户端通过单播的后续传送。
附图说明
为了更好地理解本发明,现在将仅通过举例的方式来参考附图,其中:
图1是本发明的示例中的网络图;
图2是更为详细地示出了内容生成器和内容服务器的系统图;
图3是概括了本发明的示例的主要步骤的流程图;
图4例示了如何使用RTP经由IP包来携带传输流块;
图5示出了UDP头部的格式;
图6示出了RTP头部的格式;
图7示出了在本发明的示例中的RTP有效载荷头部格式的格式;
图8示出了在本发明的示例中的完整IP包的格式。
具体实施方式
在此参考具体的示例来描述本发明。但是,本发明不限制于这些示例。
本发明的示例提出了一种生成用于传输诸如直播电视这样的视频内容的多播流的方法。首先,视频内容被编码,并且被分段(segmented)成时间块。每个块随后取决于该块的大小而被封装在一个或者多个RTP包中,并且采用块标签来标记每个RTP包,以指示在块之间的边界位于这些包中的哪一个。随后通过封装该RTP包来生成多播流,优选地使用UDP来封装在IP包中。通过在该RTP有效载荷头部中的专用字段来提供该块标签。该块标签可以是块索引或者块偏移。两者可以被独立地和组合地用于确定块之间的边界。
图1示出了包括与内容服务器104通信的内容生成器102的系统100。内容生成器负责接收诸如直播TV这样的未压缩的视频内容,并且编码和封装该视频内容,以传输到内容服务器104。内容服务器104负责存储接收到的视频内容,并且在单播传送的情况下,内容被从该服务器拉出,而对于多播传送,内容被从该服务器中推送到通过该网络106连接的合适配置的客户端。在该示例中,示出了三个客户端108、110和112。客户端可以是适于支持例如MPEG DASH或者苹果公司的HTTP直播流媒体(HLS)的标准HTTP自适应比特率流传输客户端。客户端适于发现内容、请求和处理清单文件、通过单播请求内容的块、以及处理那些块用于观看。同时,可以通过网络106直接将内容传送到这些客户端,可以通过位于每个客户端的代理实现传送,这具有某些好处。
内容服务器104还包括如下机构:其用于在诸如电视节目或者电影这样的任意给定编码内容传送期间,在单播传送方法和多播传送方法之间切换,并生成多播流。
在图2中更详细地示出了内容生成器102以及内容服务器104。将会参考图3的流程图来描述内容生成器102和内容服务器104的操作和部件,图3的流程图大体描绘了总体方法。
如在图2中所示,内容生成器102包括:视频编码器206、音频编码器208、分段模块210、封装模块212、以及输出接口214。通过该内容生成器102来接收包括未压缩的视频流202和未压缩的音频流的未压缩的视频内容。具体地,视频编码器206获得未压缩的视频流202,并且编码该视频从而生成编码的视频流。在该示例中,所使用的视频编码方法是根据ITU H.264标准的,但是本发明不限制于这一标准,并且可以替代使用其他的编码方法。类似地,音频编码器208获得未压缩的音频流204,并且编码该音频从而生成编码的音频流。在该示例中,该音频编码方法是MPEG-4HEAAC v2,但是本发明不限制于这一标准,并且可以替代使用其他的编码方法。该未压缩的视频流可以被以多个比特率来编码(相关联的未压缩音频流通常仅被以一个比特率来编码,但是也可以被以多个比特率来编码),因此生成针对每个比特率的编码的流。该编码的视频流包括多个帧或者图片,它们进而能够被聚合成图片的组或者GOP。图3的步骤300中示出了对视频内容进行编码的该第一步。
接下来在步骤302中,通过分段模块210将编码的视频流和编码的音频流(或者如果以多个比特率来编码内容,则每个编码的视频流和编码的音频流)分段为离散视频和音频片段或者块。可以想象的是,每个块等同于在未压缩的视频/音频的时长中的2秒到15秒之间,但是可以使用更长或者更短的时长(duration)。同时分段模块210被示出为在编码器206和208之后操作,可以在对未压缩的视频和音频流进行编码之前对它们执行该分段。因此,未压缩的视频和音频可以首先被分段,并且随后所获得的未压缩的片段可以被编码,以生成编码的视频和音频片段。
分段模块210可以考虑服务要求来选择片段时长。例如较短的片段允许在流之间(同时在单播流和多播流之间,或者在不同的编码比特率之间)的切换发生得更快。但是,较长的片段更容易通过系统部件来处理,具体地通过CDN(内容传送网络)节点来处理,但是会引起在传送模式之间的较慢的切换,并且可给直播服务引入更多的端到端延时。
在步骤304中,通过封装模块212处理视频和音频片段。在该示例中,封装模块212的输出是所谓的复用格式,例如在IS 13818-1中规定的MPEG-2传输流。该MPEG-2传输流通常用于实时的数字电视传送。封装模块还可以以所谓的非复用格式来输出,例如在IS14496-12中规定的ISO基本媒体文件格式。MP4片段也可以被替代输出。
MPEG-2传输流包括多个传输流包。每个传输流包携带184字节的有效载荷数据,由4字节头部作为前缀。编码的视频和音频片段被携带在该传输流有效载荷中,其中,每个有效载荷通常携带单种媒体类型,例如,音频、视频或者字幕数据。通常,会需要数个传输流包以携带音频和视频的每一个片段。所需要的传输流包的精确数量将依赖于通过分段模块210创建的音频和视频的每个片段的时长。因此,封装模块112将输出多个传输流块,以携带各个视频和音频片段,并且每个传输流块包括一个或者多个传输流包。如果使用MP4片段,则数个MP4片段将被用于携带相同的片段。
本领域技术人员将会意识到,通过编码器、分段模块以及封装模块执行的功能可以通过单个、合适配置的、通用视频编码器模块来执行。
在步骤306中,传输流块被传输给输出接口214,在该输出接口214处它们进而被传送到内容服务器120。
此外,内容生成器102还生成清单文件,并且还将该清单文件传输到内容服务器104,所述清单文件描述了编码的内容(在该示例中是传输流块),以及如何能够获得它。在MPEG-DASH下,该清单被称为MPD(Media Presentation Description,媒体呈现描述)。苹果公司的自适应视频流传输技术,即HLS(HTTP直播流媒体),提供了播放列表文件(.m3u文件)形式的清单。
如后面将要描述的,在本发明的一个示例中,清单文件可以被内容服务器修改,从而发出从单播到多播的切换的信号。该清单文件描述了针对每个传输流块的可用比特率,以及每个传输流块所位于的位置(该块被存储在内容服务器104中的位置的地址)。该清单文件被客户端用于单播流传输。
内容服务器120在输入接口222处从内容生成器102接收呈传输流块形式的块中的编码的内容以及任意相关联的清单文件。内容服务器104包括:输入接口222、用于存储视频内容的数据存储器224、多播流生成器230、切换逻辑232、以及输出接口234。数据存储器224可以形成标准网络服务器的一部分,该标准网络服务器能够经由输出接口234响应于单播请求而服务于各个传输流块。通过单播提供的内容在客户端请求时从网络服务器中被有效地“拉出”。
传输流块和清单文件被从输入接口222传输到数据存储器224,它们被存储在该数据存储器224中。数据存储器224可以存储多个清单文件228(所述多个清单文件228中的一个用于视频的每个目的地项)以及视频内容226(呈传输流块的形式)。如之前建议的,可以有多个相同的视频内容的版本,每个以不同比特率来编码,这些反映在相关联的清单文件中。
多播流生成器230负责生成多播流,所述多播流通常将携带多个传输流块。多播流被“推”出至客户端。
客户端可以通过首先向该内容服务器104发出对与期望的内容相关联的合适的清单文件的请求来发起单播流传输。在接收到清单文件后,客户端可以使用与在清单中发现的每个块相关联的位置信息来发出对编码块、传输流块的具体请求。该请求针对每个块采用HTTP请求的形式,并且该请求被内容服务器104处理,并且具体地被网络服务器部件处理。传输流块被网络服务器封装为标准TCP/IP包,并且通过网络传送到客户端。传送机构因此是一个可靠的传送机构。客户端如从内容服务器104中请求的,还可以请求更新的清单文件。后面将会更详细描述该过程。
内容服务器104中的切换逻辑232确定是否使得传输流块可用于通过多播的传送以及通过单播的传送,并且当需要的时候,将指示多播流生成器230生成多播流,并且发出该多播流是可用的信号。可以通过如下面将要描述的对该清单文件的合适的更新来执行后者。
切换逻辑232针对每个编码的内容流,确定这些编码的块的哪个(如果有的话)通过多播传送和通过单播传送是可用的。例如,切换逻辑232可以在一个时间点上确定对于给定段内容的所有内容块仅通过单播是可用的;并且在稍后的时间点上,切换逻辑232可以确定该内容(或者以一个特定比特率编码的具体流)还应附加地通过多播是可用的;并且在甚至更后的时间点上,切换逻辑232可以确定所有的内容块再次仅可以通过单播是可用的。
关于何时从单播切换到多播的决定可基于请求特定段内容的客户端的数量。如果网络仅允许单个多播流,则最受欢迎的内容可以被选择用于多播传送,从而降低网络中使用的总带宽。但是,其可能没有那么简单,因为内容可以被以不同比特率编码,并且客户端可处理的速率也可以变化,因此切换决定会更加复杂。但是,因此对于切换逻辑232来说,在任何时候知道有多少客户端正在经由单播接收哪个内容,以及经由多播接收哪个内容以能够做出合适的切换决定是非常重要的。
当切换逻辑确定所存储的内容中的一些经由多播传送应当是可用的时,内容服务器104修改清单文件,从而也表示多播传送的可能性以及如何接收该多播流。内容服务器随后在切换逻辑已经表示用于多播传送的多播流中传输该编码的内容。
在已知的系统中,视频的多播流传输通过在使用诸如通过IP的RTP这样的传送机构之前,编码该内容并且将所编码的内容封装到传输流包中来工作。但是,这一方法并没有导致其自身向携带视频的单播切换以及从携带视频的单播切换,其中,需要在所编码的内容之间的精确同步,以避免干扰内容的播放(playback)。
在本发明的示例中,如上所述,内容已经被划分为预定时长的片段,并且被携带在传输流块中。随后,使用诸如RTP(实时传输协议)这样的传输协议来封装传输流块。具体地,传输流块被携带在该包中,具体地在RTP有效载荷中,并且使用UDP(用户数据报协议)将该RTP包封装在IP包中,用于多播传输。
图4例示出了传输流块和RTP包的格式,其中它们被携带用于多播流。示出了三个传输流块400、402和404,每个传输流块携带如之前所述的所分段的内容。每个传输流块包括多个传输流包410,其中,每个传输流包具有相关联的头部412和有效载荷414。传输流包被携带在RTP包的有效载荷420中。每个新的传输流块在新的RTP有效载荷中开始,因此避免了一个RTP有效载荷可以携带一个传输流块的结束(end)以及下一个传输流块的开始(start)的情况。RTP包包括标准RTP头部422。使用UDP将包括RTP头部422和RTP有效载荷420的RTP包封装到IP包430中,并且因此示出了UDP头部422和IP头部426。实际上,该RTP有效载荷420和RTP头部422形成了该UDP包的有效载荷,并且该UDP有效载荷和该UDP头部424进而形成该IP包430的有效载荷。
举例来说,如果内容是1Mbit/s视频流,并且被分段为2秒的块,每个块将包含2Mbit或者250Kbyte。因此,每个块将通过大约190个RTP有效载荷来携带,每个RTP有效载荷包括最多七个188字节的传输流包。
图5中更详细地示出了UDP头部424的格式。
图6中更详细地示出了RTP头部422的格式。
在本发明的示例中,提出了使用附加的RTP头部来帮助在多播流中识别块边界。这需要通过接收客户端来识别单独的块,从而使得干脆利索地进行在通过单播传送的块和那些通过多播传送的块之间的切换。在本发明的示例中,提出了使用一些附加标签来表示哪些RTP有效载荷正携带哪些块,以及块边界位于哪里。在实践中,每个传输流块将通过很多RTP有效载荷来携带,并且因此块边界在很多RTP有效载荷之后出现(参见上面其中2秒的块需要大约190个RTP有效载荷的示例)。在一个最简单的方案中,携带块的结束(end)的RTP包可以被标记,以表示该块的结束。
但是,如在该示例中,多播传送通常使用RTP/UDP来执行,并且因此是不可靠的:通过内容服务器104传输的一些包可能没有被客户端接收到。尽管通常采用多播传送,但使用重传服务器以使用可靠的TCP传输来重传客户端所请求的丢失的包。尽管失败仍然是可能的,但是由于在重传中的丢失可以导致丢失的多播数据被传送给客户端,所以传送得太晚以至于不能被有效地解码。
因此,针对多播流,需要在发送块在哪些包中结束的信令中的一些弹性,因为该单个包标签可以驻留在丢失的多播包的一个中。所提出的方案在多播流的每个RTP包中包括附加信息,通过使用修改的头部来给出关于块编号以及块边界的信息。该附加信息可以以RTP有效载荷头部格式被携带。
在本申请中,该附加信息包括两个附加数值参数:CHUNK_INDEX(块索引)参数和CHUNK_OFFSET(块偏移)参数。CHUNK_INDEX参数和CHUNK_OFFSET参数都在图7的RTP有效载荷头部格式中示出。任意一个可以被单独地或者组合地使用,以表示哪些块存在在哪个RTP有效载荷中。
CHUNK_INDEX参数是序列号,其标识哪些块被携带在哪些包中,并且还表示块边界。CHUNK_INDEX还用于将在多播流中的块与在相关联的单播流中的块匹配。
在单播中,块在清单文件中与URL相关联以访问该文件,但是在一些情况下,块还被附加地与例如由苹果公司HLS使用的EXT-X-MEDIA-SEQUENCE参数的数值参数相关联。在本发明中,每个单播块与通过清单文件的分析而确定的数值参数相关联。该数值参数等于例如从EXT-X-MEDIA-SEQUENCE参数中得出的、在清单文件中的明确数值(如果存在明确数值的话)。否则该数值参数从该块的URL中得出,该数值参数等于该块的URL的数值文件名称后缀部分,其中整个URL由文件路径、根文件名、以及数值文件名后缀串联组成。
当块通过多播传输时,与该块相关联的数值以一对一的方式对应于与该块相关联的CHUNK_INDEX参数的值。这种一对一映射的示例是使用该数值作为CHNUK_INDEX的值。
下面是示例性的HLS清单-EXT-X-MEDIA-SEQUENCE表示与在该文件中的第一块相关联的值(2680),并且因此剩下的值(2681和2682)是从该第一值得出的。注意,这些值与可从对应文件的数值后缀中得出的值(其在下面的示例中也是2680、2681和2682)一致:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:8
#EXT-X-MEDIA-SEQUENCE:2680
#EXTINF:7.975,
https://priv.example.com/fileSequence2680.ts
#EXTINF:7.941,
https://priv.example.com/fileSequence2681.ts
#EXTINF:7.975,
https://priv.example.com/fileSequence2682.ts
因此,该数值作为在单播中的种类(sort)的序列号,并且在多播流中,分配CHUNK_INDEX值也遵循相同的惯例,携带块或者块的一部分的包被分配了CHUNK_INDEX,该CHUNK_INDEX等于被分配给等效单播块的序列号。内容服务器104用该CHUNK_INDEX来标记每个包的有效载荷头部。
举例来说,如果在单播中块序列号是2680,则对于多播流,用于携带该块的所有包被标记了2680的CHUNK_INDEX。随后当处理具有在单播中2681的序列号的下一个块时,携带该块的包具有2681的CHUNK_INDEX。
现在转向CHUNK_OFFSET参数,在第一示例中,CHUNK_OFFSET参数采用随给定块的每个包增加1并且在新块的第一个包中被设置为零的数值。在这一情况下,CHUNK_OFFSET参数可以随后用于识别块边界,不仅通过用值零将包标识为块的第一个,并且还在这种包丢失的情况下,通过CHUNK_OFFSET的值的减小来识别块边界。为了例示,针对携带块的第一个包的CHUNK_OFFSET可被设置为0,并且随后携带相同块的一部分的第二个包将具有被设置为1的CHUNK_OFFSET,并且携带该相同块的最后部分的第三个包将具有被设置为2的CHUNK_OFFSET。则在此后的携带新块的下一个包将具有被重设为0或者低于2的任意值的CHUNK_OFFSET。因此,为0的CHUNK_OFFSET参数或者从先前CHUNK_OFFSET参数的简单的减小发出新块的开始的信号。
在第二个示例中,CHUNK_OFFSET参数可用于表示携带给定块的全部先前包的有效载荷中的数据的总字节数。块的第一个包将因此携带0的值,并且后续的包将携带单调增加的值。如在第一个示例中,通过等于零的CHUNK_OFFSET或者通过CHUNK_OFFSET的减小的值可以识别内容块边界。
使用具有CHUNK_OFFSET参数的CHUNK_INDEX解决了失去携带单个块的包的精确数量的不大可能解决的问题,这意味着仅CHUNK_OFFSET参数仍会如期望地递增。CHUNK_INDEX作为块的序列号,并且将会突出(highlight)丢失块,以及提供与单播流块的同步。
CHUNK_OFFSET参数表示携带在针对给定块的先前包的有效载荷中的数据的总字节数的示例,实现了其他的优点。具体地,如果多播流用于传送呈ISO基本媒体文件格式的编码的内容,并且不具有在多播传输期间针对包丢失的重传服务,或者如果该重传失败。对于基于包的传输流,任意丢失的包可以通过客户端使用例如CHUNK_INDEX来搜索下一个传输流块的开始来处理。但是,如果该内容是ISO基本媒体文件格式,则这就没那么简单了,因为该编码的视频内容被封装,并且需要具有关于该块的开始的偏移值的索引表,从而对其解包。因此,如果一些数据丢失了,则除非知道丢失数据的量,否则丢失数据之后的数据不能用作偏移值不再是有效的。通过将CHUNK_OFFSET参数设置为将字节数表示关于块的内容的数据,包的丢失将不会导致未知量的丢失信息,而丢失信息的精确量可以被推出,并且在索引表中的偏移仍然可用于处理该内容块的后续的包。
通过多播流生成器230来处理针对多播传输的IP包的标记和生成,并且在步骤308中执行该IP包的标记和生成。通过输出接口234输出获得的多播流,在该输出接口234多播流可以被传送到网络。
在视频的块的传输级的级别上的标记确保了系统可以容忍在视频规格上的任意改变。例如,即使使用了新的视频/音频格式,使用这一方法仍然可以确定块边界。
更具体地,在传输级上标记块边界避免了需要更深入地处理该块数据,并且因此不需要知道视频和音频比特流规格,以及不需要知道传输容器格式,例如MPEG-2传输流。其因此支持另外的和新的视频和音频格式。此外,在音频和/或视频被加密的情况下,在单播传送和多播传送之间的切换可以被无缝执行,而无需客户端或者其他处理装置知道解密密钥。
现在将会参考客户端中的一个来探究发起单播流、并且随后切换到多播流的处理。
从客户端向内容服务器104针对与内容相关联的清单文件发出的初始请求而开始处理。内容服务器104返回清单文件,清单文件包括标识该编码的内容在数据存储器224中的位置的信息。
客户端随后开始从内容服务器104或者更具体地从数据存储器224(或者网络服务器),通过单播以HTTP请求的形式,针对在该清单中设定的特定块来请求编码的内容块。因此,客户端有效地将该内容从寄存编码的内容的网络服务器中拉出。所请求的块在该示例中是单独的传输流块。
客户端还可定期从内容服务器104请求更新的清单。当内容服务器104针对任意给定内容接收到进一步的传输流块时,内容服务器104可以更新与该内容相关联的清单文件。建立更新的清单,从而反映从内容生成器102接收到的这些附加块,并且当被请求时提供给客户端。
不久,切换逻辑可以决定使得当前被单播检索到的内容通过多播也是可用的。注意,该内容对于从数据存储器224的单播将仍是可用的,因为可以具有不能够接收多播,或者没有被配置为接收多播的客户端。内容服务器104采用切换到多播的指示符来更新该清单。在.m3u8清单文件的情况下,该指示符可以是以下形式:
#EXT-X-SWITCH:udp://239.1.2.3:4321
其中,EXT-X-SWITCH表示具有一些种类的切换,并且udp://239.1.2.3:4321表示其是多播,给出了多播地址239.1.2.3,端口号4321。
同时,多播流生成器230将开始生成如上所述的、具有识别块边界的特定传输层包头部的多播流。基于在上述清单中的这一指示符,通过在端口4321的、具有地址239.1.2.3的输出接口来输出所获得的多播流。
客户端将及时请求包括切换指示符的更新的该清单文件。但是,如果立即传送切换到多播的信号是非常重要的,则只要该清单已经被更新,内容服务器104就可以在内容块中包括事件消息,其通过单播传送以发送对该清单的更新的信号。客户端可以随后请求该更新的清单。
针于MP4文件的事件消息在ISO/IEC 23009-1中定义,并且携带在事件消息框(Event Message box)(‘emsg’)中。
针于传输流的事件消息在ISO/IEC 13818-1:2013Amd.4中定义,其中,定义了具有PID值0x0004的传输包被用于携带自适应流传输信息数据,其有效载荷格式与针对MP4文件的有效载荷格式相同,并且因此还被规定在ISO/IEC 23009-1中。
当读取更新的清单文件后,客户端将知道多播组是可用的,并且试图通过发出IGMP加入请求来加入其中。
客户端已经读取和知道已经被传送的当前单播块的块序列号或者索引,并且将针对CHUNK_INDEX参数检查当前流传输的多播流,以识别将要从该源传送的后续块(多个后续块)。
当客户端首次加入多播流时,其接收的第一个数据可以不是来自于块的开始的数据。客户端需要识别在多播流中的、对应于已经接收到的单播数据中的点的点。一个这样的点是块的开始,如上所述,通过观察CHUNK_OFFSET参数的值的减小或者CHUNK_INDEX参数的改变,来在本发明中识别出所述一个这样的点。客户端通过与在多播中的CHUNK_INDEX参数的值中的变化类似的、在与单播块相关联的数值参数的变化,来识别在已经接收的单播数据中的相同点。客户端处理单播块直到该识别的点,并且随后从该相同的点开始处理多播块。
参数可以用在多播流中,以表示该多播流将要停止,以及应发起针对该单播流的清单的请求。
一种发送多播传送将很快变为不可用的信号的方式是,在RTP有效载荷头部中传送该多播传送将很快变为不可用。这可以作为在每个RTP包中的一个比特标签来发送信号,当该比特标签设置为“1”时表示该内容块是最后要被多播传送的内容块;或者其可以以表示包括当前的块的、将通过多播传送的块的数量的多比特数值来发送信号,该多比特数值的零值表示多播传送的结束没有逼近。
当客户端正在通过单播接收内容时,其针对清单更新向内容服务器发送定期HTTPGET请求。这些请求可以通过HTTP日志由切换逻辑获得,并且用于帮助确定是否以及何时在单播和多播之间切换。但是,当通过多播传送时,客户端不发出定期请求,因为客户端所需要的用于切换回单播的所有信息被嵌入到多播流中的标签包中。
因此,在本发明的另一示例中,客户端被配置为,针对对清单的更新而向内容服务器104发出定期HTTP‘HEAD’请求。HEAD请求通常返回与所请求的文件相关联的元数据,在此情况下是清单文件。而清单文件在多播流期间并不是实际需要的,迫使客户端定期发送HEAD请求同时接收多播流,给内容服务器104提供了客户端积极接收该多播流的反馈。因此,切换逻辑能够确定网络中有多少客户端正在积极通过多播通道接收任意给定内容。
通过在内容服务器104处将HEAD请求的数量与(通过单播接收客户端提出用于请求该内容的具体块做出的)GET请求的数量进行比较,切换逻辑232可以在任意时间确定有多少客户端正在接收哪个内容,以及是否使用了多播或者单播。根据该知识,切换逻辑232针对具体段的内容能够做出多播或者单播的合适选择。
迫使接收客户端发送HEAD请求而不是GET请求,允许内容服务器容易在来自单播(GET)的反馈和来自多播(HEAD)的反馈之间区分。
此外,这一方法的另一个主要优点是,其独立于任意较低等级的多播逻辑。例如,即使一个人对IGMP加入多播流做了计数,也没有办法说出哪些客户端仍然在消费该内容。客户端可明确地离开多播组,但是它们还可以简单地停止监听。这一方法提供了解决方案。
虽然已经结合使用单播或者多播直接将内容流传输到客户端描述了上述示例,但是提出了使用客户端代理的另一可选的的示例。客户端代理可以驻留在位于客户端的合适配置的路由器或者集线器中,其可以给多于一个的客户端提供代理服务。客户端代理的主要目的是,通过多播接收内容块数据,本地地存储该内容块数据,并且在通过单播可用的时从客户端代理将其广播到客户端。这将使得多播传送用于传送到客户端代理,获得多播传送的网络效率效益,并且能够使用不太适合通过多播传送数据的技术(例如WiFi),来最终传送到可能不支持多播和/或连接到代理的客户端。
一般来说,应当注意到,虽然上面描述了本发明的实施方式,但是还存在可对所描述的示例作出的多种变化和修改,而不偏离由所附权利要求限定的本发明的范围。本领域技术人员将能够辨别对所描述的示例的修改。

Claims (8)

1.一种多播视频传送的方法,该方法包括如下步骤:
接收编码的视频内容的多个片段,其中,每个片段包括编码的视频的多个帧;
生成多个传输协议包,其中,每个片段被携带在一个或者多个传输协议包的有效载荷中;
使用第一片段标识符来标记每个传输协议包,其中,所述第一片段标识符标识携带给定片段的所述一个或者多个传输协议包;
传输包括多个传输协议包的多播流。
2.根据权利要求1所述的方法,其中,所述第一片段标识符是与片段相关联的序列号,其中,对于不同的片段,所述序列号的值是不同的,并且使用与给定片段相关联的序列号来标记携带该片段的每个传输协议包。
3.根据权利要求2所述的方法,其中,所述方法还包括如下步骤:
使用第二片段标识符来标记每个传输协议包,其中,所述第二标识符是如下偏移,该偏移包括如下数值,该数值随着携带给定片段的每个传输协议包而递增,并且对于新的片段的第一个包被重置。
4.根据权利要求3所述的方法,其中,用于标记给定包的所述偏移表示在针对所述给定片段的先前包中携带的数据的字节的总数。
5.根据前述权利要求中的任一项所述的方法,其中,所述片段标识符是传输协议有效载荷头部字段。
6.根据前述权利要求中的任一项所述的方法,其中,所述传输协议是实时传输协议。
7.根据前述权利要求中的任一项所述的方法,其中,所述多播流包括:使用用户数据报协议封装在IP包中的传输协议包。
8.根据前述权利要求中的任一项所述的方法,其中,以传输流块的形式来携带所述片段中的每一个,并且其中,每个传输流块包括多个传输流包。
CN201580013610.8A 2014-03-31 2015-03-24 多播流传输 Pending CN106464932A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP14250065.1 2014-03-31
EP14250065 2014-03-31
PCT/GB2015/050872 WO2015150736A1 (en) 2014-03-31 2015-03-24 Multicast streaming

Publications (1)

Publication Number Publication Date
CN106464932A true CN106464932A (zh) 2017-02-22

Family

ID=50489031

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201580013610.8A Pending CN106464932A (zh) 2014-03-31 2015-03-24 多播流传输

Country Status (4)

Country Link
US (1) US20170127147A1 (zh)
EP (1) EP3127333A1 (zh)
CN (1) CN106464932A (zh)
WO (1) WO2015150736A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108769789A (zh) * 2018-05-31 2018-11-06 海能达通信股份有限公司 一种基于切片的rtp流媒体存储、读取方法及装置
CN110099087A (zh) * 2018-01-31 2019-08-06 国广融合(北京)传媒科技发展有限公司 一种基于融合传输系统的文件传输方法
CN113475084A (zh) * 2019-02-27 2021-10-01 英国电讯有限公司 多播辅助传送
US11729232B2 (en) 2020-08-19 2023-08-15 British Telecommunications Public Limited Company Content delivery

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10735823B2 (en) 2015-03-13 2020-08-04 Telefonaktiebolaget Lm Ericsson (Publ) System and method for optimized delivery of live ABR media
US10432688B2 (en) 2015-03-13 2019-10-01 Telefonaktiebolaget Lm Ericsson (Publ) System and method for optimized delivery of live ABR media
CN105744380B (zh) * 2016-02-25 2018-11-30 深圳创维数字技术有限公司 一种基于Android系统的媒体数据流播放方法及系统
US10231159B2 (en) 2016-08-29 2019-03-12 At&T Intellectual Property I, L.P. Methods and system for providing multiple video content streams over different communication networks
WO2018058993A1 (zh) * 2016-09-30 2018-04-05 华为技术有限公司 一种视频数据的处理方法及装置
CN107888993B (zh) * 2016-09-30 2020-11-06 华为技术有限公司 一种视频数据的处理方法及装置
CN107948762B (zh) 2016-10-13 2021-05-11 华为技术有限公司 直播视频的传输方法、装置和系统
US10838924B2 (en) * 2017-10-02 2020-11-17 Comcast Cable Communications Management, Llc Multi-component content asset transfer
US10182269B1 (en) * 2018-04-24 2019-01-15 Verizon Patent And Licensing Inc. HTTP live streaming delivery over multicast
EP3888318A1 (en) * 2018-11-30 2021-10-06 British Telecommunications public limited company Multicast to unicast conversion
US11445000B2 (en) 2018-11-30 2022-09-13 British Telecommunications Public Limited Company Multicast to unicast conversion
FR3096203A1 (fr) * 2019-05-13 2020-11-20 Expway Procede de diffusion de contenus multimedia avec une faible latence
WO2022178762A1 (en) * 2021-02-25 2022-09-01 Huawei Technologies Co., Ltd. Ad-hoc multicast delivery of unicast services

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1568603A (zh) * 2001-08-16 2005-01-19 高通股份有限公司 用于在无线通信系统内消息分段的方法和设备
WO2012074874A1 (en) * 2010-12-03 2012-06-07 General Instrument Corporation Method and apparatus for receiving multicast video using a playlist
CN102577308A (zh) * 2009-09-22 2012-07-11 高通股份有限公司 使用可伸缩编码的增强型块请求流送
EP2665261A1 (en) * 2011-01-14 2013-11-20 Sharp Kabushiki Kaisha Content reproduction device, content reproduction method, delivery system, content reproduction program, recording medium, and data structure

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7643480B2 (en) * 2004-01-22 2010-01-05 Hain-Ching Liu Method and system for reliably and efficiently transporting data over a network
US9197857B2 (en) * 2004-09-24 2015-11-24 Cisco Technology, Inc. IP-based stream splicing with content-specific splice points
US20120140645A1 (en) * 2010-12-03 2012-06-07 General Instrument Corporation Method and apparatus for distributing video
US8532171B1 (en) * 2010-12-23 2013-09-10 Juniper Networks, Inc. Multiple stream adaptive bit rate system
US8819264B2 (en) * 2011-07-18 2014-08-26 Verizon Patent And Licensing Inc. Systems and methods for dynamically switching between unicast and multicast delivery of media content in a wireless network
US8831001B2 (en) * 2012-06-24 2014-09-09 Audiocodes Ltd. Device, system, and method of voice-over-IP communication
CN104737514B (zh) * 2012-10-23 2018-08-17 瑞典爱立信有限公司 用于分布媒体内容服务的方法和设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1568603A (zh) * 2001-08-16 2005-01-19 高通股份有限公司 用于在无线通信系统内消息分段的方法和设备
CN102577308A (zh) * 2009-09-22 2012-07-11 高通股份有限公司 使用可伸缩编码的增强型块请求流送
WO2012074874A1 (en) * 2010-12-03 2012-06-07 General Instrument Corporation Method and apparatus for receiving multicast video using a playlist
EP2665261A1 (en) * 2011-01-14 2013-11-20 Sharp Kabushiki Kaisha Content reproduction device, content reproduction method, delivery system, content reproduction program, recording medium, and data structure

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110099087A (zh) * 2018-01-31 2019-08-06 国广融合(北京)传媒科技发展有限公司 一种基于融合传输系统的文件传输方法
CN110099087B (zh) * 2018-01-31 2021-02-02 国广融合(北京)传媒科技发展有限公司 一种基于融合传输系统的文件传输方法
CN108769789A (zh) * 2018-05-31 2018-11-06 海能达通信股份有限公司 一种基于切片的rtp流媒体存储、读取方法及装置
CN113475084A (zh) * 2019-02-27 2021-10-01 英国电讯有限公司 多播辅助传送
US11812115B2 (en) 2019-02-27 2023-11-07 British Telecommunications Public Limited Company Multicast assisted delivery
CN113475084B (zh) * 2019-02-27 2024-02-02 英国电讯有限公司 多播辅助传送
US11729232B2 (en) 2020-08-19 2023-08-15 British Telecommunications Public Limited Company Content delivery

Also Published As

Publication number Publication date
US20170127147A1 (en) 2017-05-04
EP3127333A1 (en) 2017-02-08
WO2015150736A1 (en) 2015-10-08

Similar Documents

Publication Publication Date Title
CN106464932A (zh) 多播流传输
CN106233735A (zh) 多播流传输
US11032344B2 (en) Content delivery
CN105594219B (zh) 用于广播信号的发射/接收处理的设备和方法
US10034058B2 (en) Method and apparatus for distributing video
JP6122982B2 (ja) 放送システムにおける制御メッセージ構成装置及び方法
CN107743703B (zh) 用于媒体数据传输的方法、设备及计算机可读存储介质
KR101501347B1 (ko) 멀티미디어 시스템에서 미디어 컨텐츠 전송 방법
CN103262556B (zh) 收发媒体内容的方法和利用该方法进行收发的装置
US20120140645A1 (en) Method and apparatus for distributing video
CN104040993A (zh) 用于发送相应地接收媒体流的方法
KR20130040090A (ko) 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법
WO2016136489A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法
US20200021867A1 (en) Broadcast signal transmitting and receiving method and device
KR20190018142A (ko) Mmt 전송 패킷의 설정 방법 및 전송 방법
US20070033609A1 (en) Media stream multicast distribution method and apparatus
KR102176404B1 (ko) 통신 장치, 통신 데이터 생성 방법, 및 통신 데이터 처리 방법
JP2021040337A (ja) 送信装置および送信方法
JP2021180517A (ja) 送信方法および受信装置
EP3595254A1 (en) Multicast signal transmission/reception method and device
EP4123967A1 (en) Method and apparatus for processing multicast signal
Asrar Haghighi MPEG-4 delivery: DMIF based unicast and multicast systems
KR20150035857A (ko) 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20170222

RJ01 Rejection of invention patent application after publication