媒体流文件的处理方法和装置的制造方法
【专利摘要】本发明公开了一种媒体流文件的处理方法和装置。其中，该方法包括：接收媒体流请求消息，其中，媒体流请求消息用于指示从预先存储的媒体段文件中获取子媒体段文件，媒体段文件为由多个子媒体段文件合并而成的文件，多个子媒体段文件为对播放器待播放的媒体流文件进行切割后得到的文件；以及响应媒体流请求消息，从预先存储的媒体段文件中获取子媒体段文件，并将获取到的子媒体段文件发送至播放器进行播放。本发明解决了相关技术中将媒体流文件切割成大量的小文件将会降低对小文件进行存取的效率，而将媒体流文件切割成大文件又将会导致对大文件请求的延迟大的技术问题。
【专利说明】
媒体流文件的处理方法和装置
技术领域
[0001 ]本发明涉及视频处理领域，具体而言，涉及一种媒体流文件的处理方法和装置。
【背景技术】
[0002]在对媒体流文件的处理过程中，常用的流媒体协议主要有HTTP渐进下载和基于RTSP/RTP的实时流媒体协议，这两种协议基本是完全不同的。目前比较方便又好用的是用HTTP渐进下载方法，其中，以HTTP Live Streaming为代表。HTTP Live Streaming最初是针对iPhone、iPod、iTouch以及iPad等移动设备而开发的流，随着技术的发展，该技术也已经在桌面上被广泛应用，HTML5可以直接支持该技术。
[0003]HLS(HTTP Live Streaming)是一种动态码率自适应技术，主要用于Apple终端和PC的音视频服务，包括有一个核心的m3u8文件(也即索引文件或播放列表文件)，TS媒体段文件和Key加密文件，其中，m3u8文件中包含了播放器需要播放的各个小视频列表。图1是根据现有技术的利用HLS技术对媒体流文件的处理流程的示意图，如图1所示，服务器获取视频文件或者视频流;将获取到的视频文件或视频流转换成h264+aac格式并生成m3u8文件；将视频文件或者视频流切割成视频段文件，即TS文件，并更新m3u8文件，将其一并存储在存储系统中；播放器通过Web服务器或缓存服务器请求待播放的视频的m3u8文件以获取播放列表，并解析对应的TS文件的地址;播放器根据TS文件的地址通过Web服务器或缓存服务器从服务器中下载并获取待播放的TS文件进行解码播放，播放完一个TS文件后继续重复上述流程以播放下一个TS文件。
[0004]上述利用HLS技术对媒体流文件的处理流程存在以下缺陷:
[0005]1、利用HLS将媒体流文件切割成小切片会生成大量的文件，存储或处理这些文件将会造成大量的资源浪费。如果要实现数天的时移，索引量将会非常巨大，且明显影响请求速度。因此，HLS对存储I/O要求相当苛刻。如果将媒体流文件切割成大量的小文件不管是本地文件存储系统还是云存储系统对小文件进行存取的效率均较低。
[0006]2、如果利用HLS将媒体流文件切割成大文件可以解决上述存储系统对小文件进行存取的效率较低的问题，但是，这样将会造成文件请求时间慢，时延大，并且播放器在播放时快进或快退跳幅过大，比如按5分钟切割成一个TS文件，那么快进或快退都是以5分钟为一个单位，将会严重影响用户使用体验。
[0007]3、当大量用户播放视频时存在带宽受限、负载过高、服务器异常受影响面积较大等性能问题和可靠性问题，因此需要有引入缓存服务器缓存视频源的压力，以提高系统的吞吐量和可靠性。
[0008]针对相关技术中将媒体流文件切割成大量的小文件将会降低对小文件进行存取的效率，而将媒体流文件切割成大文件又将会导致对大文件请求的延迟大的问题，目前尚未提出有效的解决方案。
【发明内容】
[0009]本发明实施例提供了一种媒体流文件的处理方法和装置，以至少解决相关技术中将媒体流文件切割成大量的小文件将会降低对小文件进行存取的效率，而将媒体流文件切割成大文件又将会导致对大文件请求的延迟大的技术问题。
[0010]根据本发明实施例的一个方面，提供了一种媒体流文件的处理方法，包括:接收媒体流请求消息，其中，媒体流请求消息用于指示从预先存储的媒体段文件中获取子媒体段文件，媒体段文件为由多个子媒体段文件合并而成的文件，多个子媒体段文件为对播放器待播放的媒体流文件进行切割后得到的文件；以及响应媒体流请求消息，从预先存储的媒体段文件中获取子媒体段文件，并将获取到的子媒体段文件发送至播放器进行播放。
[0011 ]进一步地，在接收媒体流请求消息之前，该方法还包括:将媒体流文件切割成多个子媒体段文件，并创建播放列表文件，其中，播放列表文件用于记录多个子媒体段文件的文件名；将多个子媒体段文件中的至少两个子媒体段文件合并成媒体段文件进行存储，并更新播放列表文件，其中，播放列表文件中记录的每个子媒体段文件的文件名用于指示以下信息:媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量、子媒体段文件的大小或子媒体段文件的结束位置。
[0012]进一步地，接收媒体流请求消息包括:获取播放器依据播放列表文件发起的请求，其中，请求用于请求播放播放列表文件中记录的文件名对应的子媒体段文件，请求中携带有子媒体段文件所属的媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量、子媒体段文件的大小或子媒体段文件的结束位置;将请求转换为媒体流请求消息，其中，子媒体段文件的文件名替换为媒体段文件的文件名，子媒体段文件在媒体段文件中的偏移量和子媒体段文件的大小之前添加由HTTP协议的Content-Range头部。
[0013]进一步地，获取播放器依据播放列表文件发起的请求包括:按照播放列表文件中记录的文件名的顺序依次发起对每个文件名对应的子媒体段文件的请求;或按照播放列表文件中记录的文件名的顺序同时发起对多个文件名对应的子媒体段文件的请求。
[0014]进一步地，响应媒体流请求消息，从预先存储的媒体段文件中获取子媒体段文件，并将获取到的子媒体段文件发送至播放器进行播放包括:根据媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量以及子媒体段文件的大小从媒体段文件中获取带有Content-Range头部的子媒体段文件;将获取到的带有Content-Range头部的子媒体段文件中的Content-Range头部去掉，得到子媒体段文件;将子媒体段文件发送至播放器进行播放。
[00?5]进一步地，在获取带有Content-Range头部的子媒体段文件之后，该方法还包括:缓存获取到的带有Content-Range头部的子媒体段文件，其中，当再次接收到媒体流请求消息时直接将缓存的带有Content-Range头部的子媒体段文件中的Content-Range头部去掉，得到子媒体段文件，并将子媒体段文件发送至播放器进行播放。
[0016]根据本发明实施例的另一方面，还提供了一种媒体流文件的处理装置，包括:接收模块，用于接收媒体流请求消息，其中，媒体流请求消息用于指示从预先存储的媒体段文件中获取子媒体段文件，媒体段文件为由多个子媒体段文件合并而成的文件，多个子媒体段文件为对播放器待播放的媒体流文件进行切割后得到的文件；以及响应模块，用于响应媒体流请求消息，从预先存储的媒体段文件中获取子媒体段文件，并将获取到的子媒体段文件发送至播放器进行播放。
[0017]进一步地，该装置还包括:切割模块，用于在接收媒体流请求消息之前，将媒体流文件切割成多个子媒体段文件，并创建播放列表文件，其中，播放列表文件用于记录多个子媒体段文件的文件名；合并模块，用于将多个子媒体段文件中的至少两个子媒体段文件合并成媒体段文件进行存储，并更新播放列表文件，其中，播放列表文件中记录的每个子媒体段文件的文件名用于指示以下信息:媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量、子媒体段文件的大小或子媒体段文件的结束位置。
[0018]进一步地，接收模块包括:第一获取模块，用于获取播放器依据播放列表文件发起的请求，其中，请求用于请求播放播放列表文件中记录的文件名对应的子媒体段文件，请求中携带有子媒体段文件所属的媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量、子媒体段文件的大小或子媒体段文件的结束位置;转换模块，用于将请求转换为媒体流请求消息，其中，子媒体段文件的文件名替换为媒体段文件的文件名，子媒体段文件在媒体段文件中的偏移量和子媒体段文件的大小之前添加由HTTP协议的Content-Range头部。
[0019]进一步地，第一获取模块包括:第一请求模块，用于按照播放列表文件中记录的文件名的顺序依次发起对每个文件名对应的子媒体段文件的请求;或第二请求模块，用于按照播放列表文件中记录的文件名的顺序同时发起对多个文件名对应的子媒体段文件的请求。
[0020]进一步地，响应模块包括:第二获取模块，用于根据媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量以及子媒体段文件的大小从媒体段文件中获取带有Content-Range头部的子媒体段文件;处理模块，用于将获取到的带有Content-Range头部的子媒体段文件中的Content-Range头部去掉，得到子媒体段文件;发送模块，用于将子媒体段文件发送至播放器进行播放。
[0021 ]进一步地，响应模块还包括:缓存模块，用于在获取带有Content-Range头部的子媒体段文件之后，缓存获取到的带有Content-Range头部的子媒体段文件，其中，当再次接收到媒体流请求消息时直接将缓存的带有C ο n t e n t - R a n g e头部的子媒体段文件中的Content-Range头部去掉，得到子媒体段文件，并将子媒体段文件发送至播放器进行播放。
[0022]在本发明实施例中，通过将播放器待播放的媒体流文件切割成多个子媒体段文件，将多个子媒体段文件中的至少两个子媒体段文件合并成媒体段文件进行存储，避免了将媒体流文件切割成大量的小文件降低对小文件进行存取的效率的问题。同时，播放器发起对子媒体段文件的请求时，可以将对子媒体段文件的请求转换为媒体流请求消息，以实现从预先存储的媒体段文件中获取子媒体段文件，避免了将媒体流文件切割成大文件导致对大文件请求的延迟大的问题。本发明实施例的媒体流文件的处理方法达到了既提高媒体段文件的存取效率，又减小对媒体段文件的请求时延的目的，从而实现了提高媒体流文件的处理效率，缩短播放器对流媒体文件的请求时延的技术效果，进而解决了相关技术中将媒体流文件切割成大量的小文件将会降低对小文件进行存取的效率，而将媒体流文件切割成大文件又将会导致对大文件请求的延迟大的技术问题。
【附图说明】
[0023]此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中:
[0024]图1是根据现有技术的利用HLS技术对媒体流文件的处理流程的示意图；
[0025]图2是根据本发明实施例的媒体流文件的处理方法的流程图；
[0026]图3是根据本发明优选实施例的媒体流文件的处理流程的示意图；以及
[0027]图4是根据本发明实施例的媒体流文件的处理装置的示意图。
【具体实施方式】
[0028]为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
[0029]需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
[0030]根据本发明实施例，提供了一种媒体流文件的处理方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
[0031]在对本发明实施例的媒体流文件的处理方法进行详细说明之前，此处首先对本发明实施例进行描述的过程中出现的部分名词或术语适用于如下解释:
[0032]1、TS文件，是指对媒体流文件进行切割后得到的子媒体段文件。
[0033]2、m3u8文件，是指播放列表文件，m3u8文件中可以包括多个标识tag，每个tag的功能和属性如下所述:
[0034]#EXTM3U
[0035]每个m3u8文件的第一行必须是这个tag，起标识作用。
[0036]#EXT-X-MEDIA-SEQUENCE:140651513
[0037]每一个media URI在PlayList中只有一个唯一的序号，相邻之间序号+ 1，一个media URI并不是必须要包含的，如果没有，默认为O。
[0038]#EXTINF
[0039]指定每个媒体段文件TS的持续时间(秒)，仅对其后面的URI有效，title是下载资源的URL。
[0040]#EXT-X-TARGETDURAT1N
[0041 ]指定最大的媒体段时间长(秒)。因此，#EXTINF中指定的时间长度必须小于或是等于这个最大值。这个tag在整个PlayList文件中只能出现一次。需要说明的是，在嵌套的情况下，一般有真正TS urI的m3u8才会出现该tag。
[0042]#EXT-X_KEY
[0043]表示怎么对media segments进行解码。其作用范围是下次该tag出现前的所有media URI，属性为NONE或者AES-WSc3NONE表示URI以及IV(Initializat1n Vector)属性必须不存在，AES_128(Advanced Encrypt1nStandard)表不URI必须存在，IV可以不存在。
[0044]需要说明的是，对于AES-128的情况，keytag和URI属性共同表示了一个key文件，通过URI可以获得这个key，如果没有IV( Initializat 1n Vector)，则使用序列号作为IV进行编解码，将序列号的高位赋到16个字节的buffer中，左边补O;如果有IV，则将改值当成16个字节的16进制数。
[0045]#EXT-X-PR0GRAM-DATE-TIME
[0046]将一个绝对时间或是日期和一个媒体段中的第一个sample相关联，只对下一个meida URI有效，格式如下:
[0047 ] #EXT-X-PR0GRAM-DATE-TIME:
[0048]例如:#EXT-X-PR0GRAM-DATE-HME:2010-02-19T14:54:23.031+08:00
[0049]#EXT-X-ALL0ff-CACHE
[0050]表示是否允许做cache，这个可以在PlayList文件中任意地方出现，并且最多出现一次，作用效果是所有的媒体段。格式如下:
[0051 ] SEXT-X-ALLOff-CACHE:
[0052]#EXT-X-PLAYLIST-TYPE
[0053]提供关于PlayList的可变性的信息，这个对整个PlayList文件有效，是可选的，格式如下:
[0054]#EXT-X-PLAYLIST-TYPE:
[0055]如果是VOD，则服务器不能改变PlayList文件;如果是EVENT，则服务器不能改变或是删除PlayList文件中的任何部分，但是可以向该文件中增加新的一行内容。
[0056]#EXT-X_ENDLIST
[0057]表示PlayList的末尾了，它可以在PlayList中任意位置出现，但是只能出现一个，格式如下:
[0058]#EXT-X_ENDLIST
[0059]#EXT-X-MEDIA
[0060]被用来在PlayList中表示相同内容的不用语种/译文的版本，比如可以通过使用3个这种tag表示3中不用语音的音频，或者用2个这个tag表示不同角度的video在PlayLists中。这个标签是独立存在的，属性包含:
[0061 ] UR1:如果没有，则表示这个tag描述的可选择版本在主PlayList的EXT-X-STREAM-1NF中存在；
[0062]TYPE:AUD1 and VIDEO；
[0063]GROUP-1D:具有相同ID的MEDIAtag，组成一组样式；
[0064]LANGUAGE:确定使用的主要语言；
[0065]NAME:人类可读的语言的翻译；
[0066]DEFAULT: YES或是NO，默认是No，如果是YES，则客户端会以这种选项来播放，除非用户自己进行选择；
[0067]AUTOSELECT: YES或是NO，默认是No，如果是YES，则客户端会根据当前播放环境来进行选择(用户没有根据自己偏好进行选择的前提下)。
[0068]#EXT-X-STREAM-1NF
[0069]指定一个包含多媒体信息的mediaURI作为PlayList，一般做m3u8的嵌套使用，它只对紧跟后面的URI有效，格式如下:
[0070]#EXT-X-STREAM-1NF:
[0071]有以下属性:
[0072]BANDWIDTH:带宽，必须有；
[0073]PROGRAM-1D:该值是一个十进制整数，唯一地标识一个在PlayList文件范围内的特定的描述。一个PlayList文件中可能包含多个有相同ID的该tag;
[0074]CODECS:不是必须的；
[0075]RESOLUT1N:分辨率；
[0076]AUD1:这个值是必须的。
[0077]3、HLS协议的具体流程描述如下:
[0078](I)服务器通过各种协议如FTP、HTTP、UDP等从本地磁盘读取的方式获取到视频文件或者视频流。
[0079](2)视频文件或者视频流每隔一段时间间隔被转换成h264+aac格式的TS文件，并生成一份m3u8文件存在存储系统中，如下面的例子:
[0080]#EXTM3U
[0081 ] #EXT-X-TARGETDURAT10N:8
[0082]#EXT-X-MEDIA-SEQUENCE:2680
[0083]#EXTINF:8,
[0084]f ileSequence2680.ts
[0085]#EXTINF:8,
[0086]fileSequence2681.ts
[0087]#EXTINF:8,
[0088]fileSequence2682.ts
[0089]其中，m3u8和对应的TS文件都存储在同一个目录下。
[0090](3)播放器根据url利用HTTP协议请求待播放的视频的m3u8文件，并解析对应的TS文件地址。
[0091](4)播放器根据TS的url下载对应列表的TS文件并解码播放，播放完一个TS后继续播放下一个TS。
[0092]基于上述描述，下面将详细介绍本发明实施例的媒体流文件的处理方法。图2是根据本发明实施例的媒体流文件的处理方法的流程图，如图2所示，该方法包括如下步骤:
[0093]步骤S102，接收媒体流请求消息，其中，媒体流请求消息用于指示从预先存储的媒体段文件中获取子媒体段文件，媒体段文件为由多个子媒体段文件合并而成的文件，多个子媒体段文件为对播放器待播放的媒体流文件进行切割后得到的文件；
[0094]步骤S104，响应媒体流请求消息，从预先存储的媒体段文件中获取子媒体段文件，并将获取到的子媒体段文件发送至播放器进行播放。
[0095]需要说明的是，上述步骤可以由服务器执行。通过上述步骤，可以实现既提高媒体段文件的存取效率，又减小对媒体段文件的请求时延的目的，进而解决了相关技术中将媒体流文件切割成大量的小文件将会降低对小文件进行存取的效率，而将媒体流文件切割成大文件又将会导致对大文件请求的延迟大的技术问题，实现了提高媒体流文件的处理效率，缩短播放器对流媒体文件的请求时延的技术效果。
[0096]在步骤S102提供的方案中，服务器的存储系统中可以预先存储有至少一个媒体段文件，其中，媒体段文件可以为由多个子媒体段文件合并而成的文件，其中，多个子媒体段文件为对播放器待播放的媒体流文件进行切割后得到的文件。需要说明的是，本发明实施例对播放器不做具体限定，其可以是网页播放器，也可以是客户端播放器。播放器待播放的媒体流文件可以是视频文件，也可以是音频文件。对媒体流文件进行切割可以得到多个子媒体段文件，即TS文件。为了避免服务器存储系统存储大量的子媒体段文件导致存取效率较低的问题，本发明实施例可以将对媒体流文件进行切割可以得到多个子媒体段文件中的至少两个子媒体段文件合并成媒体段文件进行存储，以达到提高媒体段文件存取效率，进而提高媒体流文件处理效率的目的。
[0097]作为一种可选的实施例，在步骤S102服务器接收媒体流请求消息之前，服务器存储系统可以存储媒体段文件，具体存储过程可以通过以下步骤实现:
[0098]步骤S1012，将媒体流文件切割成多个子媒体段文件，并创建播放列表文件，其中，播放列表文件用于记录多个子媒体段文件的文件名。
[0099]在步骤S1012提供的技术方案中，服务器可以通过各种协议，比如FTP、HTTP、UDP从本地磁盘读取的方式获取媒体流文件，并将获取到的媒体流文件转换成h264+aac格式。在转换格式的同时服务器还可以创建播放列表文件，也即m3u8文件，创建m3u8文件之后写入文件头。服务器可以将媒体流文件切割成多个子媒体段文件，每个字媒体流文件均有一个文件名，多个子媒体段文件的文件名可以记录在m3u8文件中。
[0100]步骤S1014，将多个子媒体段文件中的至少两个子媒体段文件合并成媒体段文件进行存储，并更新播放列表文件，其中，播放列表文件中记录的每个子媒体段文件的文件名用于指示以下信息:媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量、子媒体段文件的大小或子媒体段文件的结束位置。
[0101]在步骤S1014提供的技术方案中，服务器在将媒体流文件切割成多个子媒体段文件之后，为了避免存储大量的子媒体段文件导致子媒体段文件存取效率低，可以将多个子媒体段文件中的至少两个子媒体段文件合并成媒体段文件，并将得到的媒体段文件存储在服务器的存储系统中。在存储由至少两个子媒体段文件合并成的媒体段文件后，服务器可以更新m3u8文件，具体可以更新每个字媒体段文件的文件名，更新后的子媒体段文件的文件名可以用于指示以下信息:媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量、子媒体段文件的大小或子媒体段文件的结束位置。比如，更新后的m3u8文件中记录的子媒体段文件的文件名的形式可以为:big_offsert_end.ts，其中，big为媒体段文件的文件名，offsert是该子媒体段文件在媒体段文件big.ts文件中的偏移量，end是该子媒体段文件的大小。需要说明的是，m3u8文件中记录的子媒体段文件的文件名还可以用于指示其他信息，此处不再一一举例说明。
[0102]在步骤S102提供的方案中，还需要说明的是，媒体流请求消息可以用于指示从预先存储的媒体段文件中获取子媒体段文件。播放器可以从服务器的存储系统中下载获取m3u8文件，然后依据m3u8文件依次向服务器请求并播放该m3u8文件中记录的文件名对应的子媒体段文件。由于服务器存储系统中存储的媒体段文件为由至少两个子媒体段文件合并而成，因此，服务器接收到的媒体段请求可以表示播放器向服务器请求从预先存储的媒体段文件中获取并播放子媒体段文件。
[0103]可选地，接收媒体流请求消息可以包括以下步骤:
[0104]步骤S1022，获取播放器依据播放列表文件发起的请求，其中，请求用于请求播放播放列表文件中记录的文件名对应的子媒体段文件，请求中携带有子媒体段文件所属的媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量、子媒体段文件的大小或子媒体段文件的结束位置；
[0105]在步骤S1022提供的技术方案中，播放器从服务器的存储系统中下载并获取m3u8文件后，可以获取到媒体段文件的播放列表，播放器可以按照该播放列表中记录的文件名的顺序依次向服务器发起请求，请求文件名对应的子媒体段文件进行播放。当服务器接收到播放器发起的请求时，可以对该请求进行解析，从获取到该请求中可以携带有子媒体段文件所属的媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量、子媒体段文件的大小或子媒体段文件的结束位置等信息，需要说明的是，本发明实施例中播放器发起的请求中还可以携带有其他内容，此处不再一一举例说明。
[0106]可选地，步骤S1022获取播放器依据播放列表文件发起的请求可以包括:按照播放列表文件中记录的文件名的顺序依次发起对每个文件名对应的子媒体段文件的请求;或按照播放列表文件中记录的文件名的顺序同时发起对多个文件名对应的子媒体段文件的请求。
[0107]需要说明的是，播放器可以按照播放列表文件中记录的文件名的顺序采用串发或者并发方式向服务器发起请求，串发方式可以为按照播放列表文件中记录的文件名的顺序逐个地发起对每个文件名对应的子媒体段文件的请求;并发方式可以为按照播放列表文件中记录的文件名的顺序一次性发起对多个文件名对应的多个子媒体段文件的请求。本发明实施例对播放器发起请求的方式不做具体限定，播放器可以采用串发方式，也可以采用并发方式。
[0108]步骤S1024，将请求转换为媒体流请求消息，其中，子媒体段文件的文件名替换为媒体段文件的文件名，子媒体段文件在媒体段文件中的偏移量和子媒体段文件的大小之前添加由http协议的Content-Range头部。
[0109]在步骤S1024提供的技术方案中，服务器在获取到播放器发起的请求后可以将该请求转换为媒体流请求消息，需要说明的是，该转换过程可以依据请求中携带的相关信息，具体转换过程可以包括:将子媒体段文件的文件名替换为该子媒体段文件所属的媒体段文件的文件名;将子媒体段文件在媒体段文件中的偏移量和子媒体段文件的大小之前添加由http协议的Content-Range头部。需要说明的是，将播放器发起的请求转换为媒体流请求消息，实质为将对子媒体段文件的请求转换为对服务器的存储系统中存储的媒体段文件的请求，但是，需要说明的是，服务器在接收到该媒体流请求消息后响应该媒体流请求消息向播放器反馈的仍是子媒体段文件，这样可以缩短播放器请求大文件的时延，进而达到提高播放器播放效果的目的。
[0110]在步骤S104提供的技术方案中，服务器在接收到媒体流请求消息之后，响应该媒体流请求消息，具体响应过程可以为从服务器存储系统中预先存储的至少一个媒体段文件中获取请求的子媒体段文件，并将获取到的子媒体段文件发送至播放器进行播放。可选地，服务器从存储系统中存储的至少一个媒体段文件中获取请求的子媒体段文件可以包括:依据请求的子媒体段文件所属的媒体段文件的文件名从存储系统中存储的至少一个媒体段文件中定位与该文件名对应的媒体段文件;依据请求的子媒体段文件在媒体段文件中的偏移量定位该媒体段文件中请求的子媒体段文件的位置;依据请求的子媒体段文件的大小获取从上述位置开始整个子媒体段文件。
[0111]作为一种可选的实施例，步骤S104响应媒体流请求消息，从预先存储的媒体段文件中获取子媒体段文件，并将获取到的子媒体段文件发送至播放器进行播放可以包括以下步骤:
[0112]步骤S1042，根据媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量以及子媒体段文件的大小从媒体段文件中获取带有Content-Range头部的子媒体段文件。
[0113]步骤SI 044，将获取到的带有Content-Range头部的子媒体段文件中的Content-Range头部去掉，得到子媒体段文件。
[0114]步骤S1046，将子媒体段文件发送至播放器进行播放。
[0115]需要说明的是，上述步骤中服务器根据媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量以及子媒体段文件的大小从存储系统中存储的至少一个媒体段文件中获取请求的子媒体段文件的过程已经在上述实施例中进行了详细介绍，此处不再赘述。但需要说明的是，服务器通过查找获取到的子媒体段文件为带有Content-Range头部的子媒体段文件，这是因为服务器在响应媒体流请求消息之前对播放器发起的请求进行了转换，在子媒体段文件在媒体段文件中的偏移量以及子媒体段文件的大小前添加了 Content-Range头部。
[0116]需要说明的是，为了保证反馈至播放器播放的子媒体段文件的准确性，服务器在获取到带有Content-Range头部的子媒体段文件后，可以将该Content-Range头部去掉，得到播放器请求的子媒体段文件，并将该子媒体段文件发送至播放器播放。本发明实施例利用Content-Range头部的功能实现了用媒体段文件模拟子媒体段文件的目的，进而解决了服务器存储系统存储小文件效率低和存储大文件播放器请求时延大的问题。
[0117]作为一种可选的实施例，在步骤S1044获取带有Content-Range头部的子媒体段文件之后，该可选实施例还可以包括:缓存获取到的带有Content-Range头部的子媒体段文件，其中，当再次接收到媒体流请求消息时直接将缓存的带有Content-Range头部的子媒体段文件中的Content-Range头部去掉，得到子媒体段文件，并将子媒体段文件发送至播放器进行播放。
[0118]需要说明的是，缓存带有Content-Range头部的子媒体段文件可以由服务器执行，也可以由Web服务器或者缓存服务器执行，本发明不做具体限定。利用Web服务器或者缓存服务器缓存带有Content-Range头部的子媒体段文件，使得再次接收到媒体流请求消息时无需再次向服务器发起请求从存储系统中获取请求的子媒体段文件，这样可以使得服务器负载均衡，提高系统吞吐能力，提高播放器播放效果。
[0119]本发明实施例还提供可以一种优选实施例，图3是根据本发明优选实施例的媒体流文件的处理流程的示意图，需要说明的是，该优选实施例中媒体流文件以视频文件或视频流为例进行说明，且该优选实施例对视频文件或视频流的处理流程可以由服务器和Web服务器或缓存服务器共同协作完成。如图3所示，该优选实施例的处理流程可以描述如下:
[0120]服务器获取视频文件或者视频流，并将其转换成h264+aac格式。
[0121]创建m3u8文件，写入文件头。
[0122]服务器存储文件时按照小TS文件来切割，但是将η个小TS文件small.ts sma
12.ts smal3.ts…smaln.ts存储成一个大TS文件，大TS文件的文件名是big.ts,记录每个小TS文件的大小和在big.ts中的偏移量。需要说明的是，此处的小TS文件对应上述实施例中的子媒体段文件，大TS文件对应上述实施例中的媒体段文件。
[0123]往m3u8文件的#EXTINF字段写入小TS文件的时长等信息，小TS文件的文件名是big_offsert_end.ts，其中big与大TS文件的文件名中的big保持一致，offert是当前小TS文件在big.ts文件中的偏移量，end是偏移量和当前小TS文件长度，例如:
[0124]#EXTM3U
[0125]SEXT-X-MEDIA-SEQUENCE:62101
[0126]#EXT-X-TARGETDURAT1N:60
[0127]#EXT-X-VERS10N:1
[0128]#EXTINF:10,
[0129]#EXTINF:10,
[0130]1453254427_0_2352631.ts
[0131]#EXTINF:10,
[0132]1453254427_2352632_4454283.ts
[0133]#EXTINF:11,
[0134]1453254427_4454284_6777023.ts
[0135]需要说明的是，如果不使用作为分界符，而是使用“?”等符号，在功能上不受影响，但是影响缓存服务器的性能，因为对于同样的url，“?”后面的查询参数不同会被当做不同的url，因此，后端缓存服务器缓存的是小TS文件，存在与源站一样的小文件性能问题。
[0136]播放器可以通过Web服务器或者缓存服务器从存储系统中下载m3u8文件，以获取播放器的播放列表，然后自动根据m3u8文件中的TS文件名请求并播放TS文件，因此请求的TS地址的后缀名就是big_offsert_end.ts，通过第三方模块如nginx的Iua模块或者Web模块识别此类型的TS文件名并截获该小TS文件请求，获取小TS文件名。偏移量以及大小。
[0137]Web模块修改小TS文件的请求，将请求的文件名替换成big.ts，并添加http的Content-Range头部，例如:Range: bytes = 2352632-4454283。需要说明的是，Content-Range头部与带“? ”的查询语句相比更有利于缓存服务器缓存文件，并且保证缓存的是大的TS文件。
[0138]缓存服务器转发带Content-Range头部的请求，向服务器请求数据。服务器响应该请求将响应数据即带Content-Range头部的TS文件发送至缓存服务器，缓存服务器去掉响应头中的Content-Range头部后将请求的TS文件反馈给播放器，这样对于播放器是完全透明的，播放器不知道请求被修改过。
[0139]需要说明的是，Web模块转发请求到缓存服务器，缓存服务器代理该请求并缓存大TS文件，响应带Content-Range头部的请求。后续同样的TS请求可以对其直接响应不需要再去重复请求了。
[0140]播放器播放请求的TS文件。
[0141]本发明通过在生成m3u8文件时适当地修改TS文件的文件名，从而实现利用大TS文件的模拟小TS文件，进而解决了存储系统处理小TS文件效率低下和处理大TS文件播放器播放效果差和用户体验差的矛盾。本发明主要的发明点包括:利用HLS切割媒体流文件时按照小TS文件切割，但是存储成大TS文件，m3u8文件保存的是小TS文件的信息，但是小TS文件的文件名格式是被修改后的;Web服务器或者缓存服务器需要开启HTTP Range支持，利用小TS文件的功能实现用大TS文件模拟小TS文件;利用播放器请求TS文件时文件名固定的特性依靠第三方组件将小TS文件的请求转换成大TS文件请求;利用缓存服务器缓存大TS文件，使得服务器负载均衡，提高了系统吞吐能力和用户播放体验。
[0142]根据本发明实施例，还提供了一种媒体流文件的处理装置的装置实施例，需要说明的是，该媒体流文件的处理装置可以用于执行本发明实施例中的媒体流文件的处理方法，本发明实施例中的媒体流文件的处理方法可以在该媒体流文件的处理装置中执行。
[0143]图4是根据本发明实施例的媒体流文件的处理装置的示意图，如图4所示，该装置可以包括:
[0144]接收模块22，用于接收媒体流请求消息，其中，媒体流请求消息用于指示从预先存储的媒体段文件中获取子媒体段文件，媒体段文件为由多个子媒体段文件合并而成的文件，多个子媒体段文件为对播放器待播放的媒体流文件进行切割后得到的文件；以及响应模块24，用于响应媒体流请求消息，从预先存储的媒体段文件中获取子媒体段文件，并将获取到的子媒体段文件发送至播放器进行播放。
[0145]需要说明的是，该实施例中的接收模块22可以用于执行本申请实施例中的步骤S102，该实施例中的响应模块24可以用于执行本申请实施例中的步骤S104。上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。
[0146]作为一种可选的实施例，该实施例的媒体流文件的处理装置还可以包括:切割模块212，用于在接收媒体流请求消息之前，将媒体流文件切割成多个子媒体段文件，并创建播放列表文件，其中，播放列表文件用于记录多个子媒体段文件的文件名;合并模块214，用于将多个子媒体段文件中的至少两个子媒体段文件合并成媒体段文件进行存储，并更新播放列表文件，其中，播放列表文件中记录的每个子媒体段文件的文件名用于指示以下信息:媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量、子媒体段文件的大小或子媒体段文件的结束位置。
[0147]需要说明的是，该实施例中的切割模块212可以用于执行本申请实施例中的步骤S1012，该实施例中的合并模块214可以用于执行本申请实施例中的步骤S1014。上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。
[0148]可选地，接收模块22可以包括:第一获取模块222，用于获取播放器依据播放列表文件发起的请求，其中，请求用于请求播放播放列表文件中记录的文件名对应的子媒体段文件，请求中携带有子媒体段文件所属的媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量、子媒体段文件的大小或子媒体段文件的结束位置;转换模块224，用于将请求转换为媒体流请求消息，其中，子媒体段文件的文件名替换为媒体段文件的文件名，子媒体段文件在媒体段文件中的偏移量和子媒体段文件的大小之前添加由http协议的Content-Range 头部。
[0149]需要说明的是，该实施例中的第一获取模块222可以用于执行本申请实施例中的步骤S1022，该实施例中的转换模块224可以用于执行本申请实施例中的步骤S1024。上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。
[0150]可选地，第一获取模块222可以包括:第一请求模块，用于按照播放列表文件中记录的文件名的顺序依次发起对每个文件名对应的子媒体段文件的请求;或第二请求模块，用于按照播放列表文件中记录的文件名的顺序同时发起对多个文件名对应的子媒体段文件的请求。
[0151 ]可选地，响应模块24可以包括:第二获取模块242，用于根据媒体段文件的文件名、子媒体段文件在媒体段文件中的偏移量以及子媒体段文件的大小从媒体段文件中获取带有Content-Range头部的子媒体段文件;处理模块244，用于将获取到的带有Content-Range头部的子媒体段文件中的Content-Range头部去掉，得到子媒体段文件;发送模块246，用于将子媒体段文件发送至播放器进行播放。
[0152]需要说明的是，该实施例中的第二获取模块242可以用于执行本申请实施例中的步骤S1022，该实施例中的处理模块244可以用于执行本申请实施例中的步骤S1024，该实施例中的发送模块246可以用于执行本申请实施例中的步骤S1026。上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。
[0153]作为一种可选的实施例，响应模块24还可以包括:缓存模块，用于在获取带有Content-Range头部的子媒体段文件之后，缓存获取到的带有Content-Range头部的子媒体段文件，其中，当再次接收到媒体流请求消息时直接将缓存的带有Content-Range头部的子媒体段文件中的Content-Range头部去掉，得到子媒体段文件，并将子媒体段文件发送至播放器进行播放。
[0154]本发明实施例的媒体流文件的处理装置可以实现既提高媒体段文件的存取效率，又减小对媒体段文件的请求时延的目的，进而解决了相关技术中将媒体流文件切割成大量的小文件将会降低对小文件进行存取的效率，而将媒体流文件切割成大文件又将会导致对大文件请求的延迟大的技术问题，实现了提高媒体流文件的处理效率，缩短播放器对流媒体文件的请求时延的技术效果。
[0155]上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
[0156]在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
[0157]在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
[0158]所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0159]另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0160]所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、只读存储器(R0M，Read-0nly Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
[0161]以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
【主权项】
1.一种媒体流文件的处理方法，其特征在于，包括: 接收媒体流请求消息，其中，所述媒体流请求消息用于指示从预先存储的媒体段文件中获取子媒体段文件，所述媒体段文件为由多个所述子媒体段文件合并而成的文件，多个所述子媒体段文件为对播放器待播放的媒体流文件进行切割后得到的文件；以及 响应所述媒体流请求消息，从预先存储的所述媒体段文件中获取所述子媒体段文件，并将获取到的所述子媒体段文件发送至所述播放器进行播放。2.根据权利要求1所述的方法，其特征在于，在接收媒体流请求消息之前，所述方法还包括: 将所述媒体流文件切割成多个所述子媒体段文件，并创建播放列表文件，其中，所述播放列表文件用于记录多个所述子媒体段文件的文件名； 将多个所述子媒体段文件中的至少两个所述子媒体段文件合并成所述媒体段文件进行存储，并更新所述播放列表文件，其中，所述播放列表文件中记录的每个所述子媒体段文件的文件名用于指示以下信息:所述媒体段文件的文件名、所述子媒体段文件在所述媒体段文件中的偏移量、所述子媒体段文件的大小或所述子媒体段文件的结束位置。3.根据权利要求2所述的方法，其特征在于，接收媒体流请求消息包括: 获取所述播放器依据所述播放列表文件发起的请求，其中，所述请求用于请求播放所述播放列表文件中记录的文件名对应的所述子媒体段文件，所述请求中携带有所述子媒体段文件所属的所述媒体段文件的文件名、所述子媒体段文件在所述媒体段文件中的偏移量、所述子媒体段文件的大小或所述子媒体段文件的结束位置； 将所述请求转换为所述媒体流请求消息，其中，所述子媒体段文件的文件名替换为所述媒体段文件的文件名，所述子媒体段文件在所述媒体段文件中的偏移量和所述子媒体段文件的大小之前添加由http协议的Content-Range头部。4.根据权利要求3所述的方法，其特征在于，获取所述播放器依据所述播放列表文件发起的请求包括: 按照所述播放列表文件中记录的文件名的顺序依次发起对每个文件名对应的所述子媒体段文件的请求;或 按照所述播放列表文件中记录的文件名的顺序同时发起对多个文件名对应的所述子媒体段文件的请求。5.根据权利要求3或4所述的方法，其特征在于，响应所述媒体流请求消息，从预先存储的所述媒体段文件中获取所述子媒体段文件，并将获取到的所述子媒体段文件发送至所述播放器进行播放包括: 根据所述媒体段文件的文件名、所述子媒体段文件在所述媒体段文件中的偏移量以及所述子媒体段文件的大小从所述媒体段文件中获取带有Content-Range头部的子媒体段文件； 将获取到的带有Content-Range头部的子媒体段文件中的Content-Range头部去掉，得到所述子媒体段文件； 将所述子媒体段文件发送至所述播放器进行播放。6.根据权利要求5所述的方法，其特征在于，在获取带有Content-Range头部的子媒体段文件之后，所述方法还包括: 缓存获取到的带有Content-Range头部的子媒体段文件，其中，当再次接收到所述媒体流请求消息时直接将缓存的带有Content-Range头部的子媒体段文件中的Content-Range头部去掉，得到所述子媒体段文件，并将所述子媒体段文件发送至所述播放器进行播放。7.一种媒体流文件的处理装置，其特征在于，包括: 接收模块，用于接收媒体流请求消息，其中，所述媒体流请求消息用于指示从预先存储的媒体段文件中获取子媒体段文件，所述媒体段文件为由多个所述子媒体段文件合并而成的文件，多个所述子媒体段文件为对播放器待播放的媒体流文件进行切割后得到的文件；以及 响应模块，用于响应所述媒体流请求消息，从预先存储的所述媒体段文件中获取所述子媒体段文件，并将获取到的所述子媒体段文件发送至所述播放器进行播放。8.根据权利要求7所述的装置，其特征在于，所述装置还包括: 切割模块，用于在接收媒体流请求消息之前，将所述媒体流文件切割成多个所述子媒体段文件，并创建播放列表文件，其中，所述播放列表文件用于记录多个所述子媒体段文件的文件名； 合并模块，用于将多个所述子媒体段文件中的至少两个所述子媒体段文件合并成所述媒体段文件进行存储，并更新所述播放列表文件，其中，所述播放列表文件中记录的每个所述子媒体段文件的文件名用于指示以下信息:所述媒体段文件的文件名、所述子媒体段文件在所述媒体段文件中的偏移量、所述子媒体段文件的大小或所述子媒体段文件的结束位置。9.根据权利要求8所述的装置，其特征在于，所述接收模块包括: 第一获取模块，用于获取所述播放器依据所述播放列表文件发起的请求，其中，所述请求用于请求播放所述播放列表文件中记录的文件名对应的所述子媒体段文件，所述请求中携带有所述子媒体段文件所属的所述媒体段文件的文件名、所述子媒体段文件在所述媒体段文件中的偏移量、所述子媒体段文件的大小或所述子媒体段文件的结束位置； 转换模块，用于将所述请求转换为所述媒体流请求消息，其中，所述子媒体段文件的文件名替换为所述媒体段文件的文件名，所述子媒体段文件在所述媒体段文件中的偏移量和所述子媒体段文件的大小之前添加由HTTP协议的Content-Range头部。10.根据权利要求9所述的装置，其特征在于，所述第一获取模块包括: 第一请求模块，用于按照所述播放列表文件中记录的文件名的顺序依次发起对每个文件名对应的所述子媒体段文件的请求;或 第二请求模块，用于按照所述播放列表文件中记录的文件名的顺序同时发起对多个文件名对应的所述子媒体段文件的请求。11.根据权利要求9或10所述的装置，其特征在于，所述响应模块包括: 第二获取模块，用于根据所述媒体段文件的文件名、所述子媒体段文件在所述媒体段文件中的偏移量以及所述子媒体段文件的大小从所述媒体段文件中获取带有Content-Range头部的子媒体段文件； 处理模块，用于将获取到的带有Content-Range头部的子媒体段文件中的Content-Range头部去掉，得到所述子媒体段文件； 发送模块，用于将所述子媒体段文件发送至所述播放器进行播放。12.根据权利要求11所述的装置，其特征在于，所述响应模块还包括: 缓存模块，用于在获取带有Content-Range头部的子媒体段文件之后，缓存获取到的带有Content-Range头部的子媒体段文件，其中，当再次接收到所述媒体流请求消息时直接将缓存的带有Content-Range头部的子媒体段文件中的Content-Range头部去掉，得到所述子媒体段文件，并将所述子媒体段文件发送至所述播放器进行播放。
【文档编号】H04N21/643GK105828096SQ201610341723
【公开日】2016年8月3日
【申请日】2016年5月19日
【发明人】刘成彦, 陈发民
【申请人】网宿科技股份有限公司