CN112367527A - 一种传送流文件生成方法、装置、设备及存储介质 - Google Patents

一种传送流文件生成方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN112367527A
CN112367527A CN202011173330.2A CN202011173330A CN112367527A CN 112367527 A CN112367527 A CN 112367527A CN 202011173330 A CN202011173330 A CN 202011173330A CN 112367527 A CN112367527 A CN 112367527A
Authority
CN
China
Prior art keywords
file
media
media stream
server
stream
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.)
Withdrawn
Application number
CN202011173330.2A
Other languages
English (en)
Inventor
郑丁华
陈毓亮
苏强卫
邝景森
吴济宇
黄金强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangzhou Wangxing Information Technology Co Ltd
Original Assignee
Guangzhou Wangxing Information Technology Co Ltd
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 Guangzhou Wangxing Information Technology Co Ltd filed Critical Guangzhou Wangxing Information Technology Co Ltd
Priority to CN202011173330.2A priority Critical patent/CN112367527A/zh
Publication of CN112367527A publication Critical patent/CN112367527A/zh
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • 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
    • 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/762Media network packet handling at the source 

Landscapes

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

Abstract

本发明实施例公开了一种传送流文件生成方法、装置、设备及存储介质。其中,该方法包括:从媒体源端获取原始媒体流;识别所述原始媒体流中的关键帧;根据关键帧识别结果对所述原始媒体流进行切分,得到传送流TS文件,其中,所述TS文件的第一个媒体包为关键帧,所述TS文件的长度为关键帧间隔时长的预设倍数,所述TS文件的分片序号由所述TS文件中预设位置的媒体包的属性信息确定。本发明实施例提供的技术方案,可以保证不同服务端针对同路媒体流的切分方式统一以及不同服务端对TS文件的分片序号的命名统一,从而有利于解决用户播放HLS媒体流时,多服务端响应不一致导致的断流问题。

Description

一种传送流文件生成方法、装置、设备及存储介质
技术领域
本发明实施例涉及直播技术领域,尤其涉及一种传送流文件生成方法、装置、设备及存储介质。
背景技术
随着直播技术的发展,内容分发网络(Content Delivery Network,简称CDN)在直播领域的传输协议通常有3种:实时消息传输协议(Real Time Messaging Protocol,简称RTMP)、基于http的流媒体网络传输(Http Live Streaming,简称HLS)协议、流媒体格式(Flash Video,简称FLV)。RTMP、FLV在浏览器兼容性方面比HLS差,故HLS常作为CDN在线移动端重要的播放协议。CDN在实际应用中通过域名访问服务端,拉取直播音视频流。在短链接的情况,部分播放器和浏览器会发起多个链接来请求HLS的m3u8索引里的传送流(Transport Stream,简称TS)分片。而DNS服务器解析返回的服务端网际互连协议(Internet Protocol,简称IP)通常不止一个,导致不同请求被随机发送到不同的服务端机器。
服务端的媒体流,其内部传输格式可能并非HLS协议。可能以RTMP媒体包,亦或其他私有封装协议传输。因此,尽管是同路直播流,若不同服务端收到的请求时间不同,则开始生成TS的时间不同,各自切割出的TS分片序列存在差异。导致有些服务端的m3u8索引里的TS文件,在另一些服务端无法获取到,造成直播断流。
现有技术中对于直播断流问题有以下解决方案:例如,部分CDN架构会自建专门的CDN域名解析(Domain name resolution,简称DNS)服务器,把用户单次播放请求通过DNS解析固定到一台服务器处理,避免出现同一观众的播放流落在不同的机器,从根源上规避HLS流断播的出现,但该架构依赖于自建CDN DNS服务器集群,且硬件成本高、初次建立链接经过的链路节点较多,出视频较慢;又如通过Nginx反向代理的方式,利用配置Nginx的IP哈希(hash)方式转发用户请求到匹配哈希规则的服务器,同时服务端响应也经由Nginx服务。该方式所有的请求和响应均通过Nginx服务器,当实时直播媒体流链路数据量较大时,Nginx服务器易成为带宽瓶颈,因同路播放流的不同的请求需被分配到同一个后端处理,要求Nginx服务器集群的IP hash配置需保持一致,当CDN缓存服务器增减机器(如机器宕机),原有的IP配置无法及时变更,易引发一致性问题;此外,还有提供网络地址转换(NetworkAddress Translation,简称NAT)网关,只有小部分公网IP提供对外访问的方法,该方法将不同的请求通过NAT网关映射转发给内网的CDN服务器集群处理。由于NAT网关可配置,同个用户同路直播流可稳定映射到对应服务器处理,该方案也容易引发一致性问题。
发明内容
本发明实施例提供了传送流文件生成方法、装置、设备及存储介质,可以保证不同服务端针对同路媒体流的切分方式统一以及不同服务端对TS文件的分片序号的命名统一,有利于解决用户播放HLS媒体流时,多服务端响应不一致导致的断流问题。
第一方面,本发明实施例提供了一种传送流文件生成方法,该方法包括:
从媒体源端获取原始媒体流;
识别所述原始媒体流中的关键帧;
根据关键帧识别结果对所述原始媒体流进行切分,得到传送流TS文件,其中,所述TS文件的第一个媒体包为关键帧,所述TS文件的长度为关键帧间隔时长的预设倍数,所述TS文件的分片序号由所述TS文件中预设位置的媒体包的属性信息确定。
第二方面,本发明实施例提供了一种传送流文件生成装置,该装置包括:
原始媒体流获取模块,用于从媒体源端获取原始媒体流;
关键帧识别模块,用于识别所述原始媒体流中的关键帧;
TS文件获取模块,用于根据关键帧识别结果对所述原始媒体流进行切分,得到传送流TS文件,其中,所述TS文件的第一个媒体包为关键帧,所述TS文件的长度为关键帧间隔时长的预设倍数,所述TS文件的分片序号由所述TS文件中预设位置的媒体包的属性信息确定。
第三方面,本发明实施例提供了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现如本发明实施例提供的传送流文件生成方法。
第四方面,本发明实施例提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如本发明实施例提供的传送流文件生成方法。
本发明实施例中提供的传送流文件生成方案,首先从媒体源端获取原始媒体流,然后识别原始媒体流中的关键帧,最后根据关键帧识别结果对原始媒体流进行切分,得到传送流TS文件,TS文件的第一个媒体包为关键帧,TS文件的长度为关键帧间隔时长的预设倍数,TS文件的分片序号由TS文件中预设位置的媒体包的属性信息确定。通过采用上述技术方案,可以保证不同服务端针对同路媒体流的切分方式统一以及不同服务端对TS文件的分片序号的命名统一,有利于解决用户播放HLS媒体流时,多服务端响应不一致导致的断流问题,无需依赖额外的专用服务器,能够降低成本。
附图说明
图1为本发明实施例提供的一种传送流文件生成方法所适用的应用场景的场景架构图;
图2A为本发明实施例一提供的一种传送流文件生成方法的流程示意图;
图2B为本发明实施例一提供的一种传送流文件生成方法的原理示意图;
图3A为本发明实施例二提供的一种传送流文件生成方法的流程示意图;
图3B为本发明实施例二提供的一种传送流文件生成方法的原理示意图;
图4A为本发明实施例三提供的一种传送流文件生成方法的流程示意图;
图4B为本发明实施例三提供的一种传送流文件生成方法的原理示意图;
图5为本发明实施例四提供的一种传送流文件生成装置的结构示意图;
图6为本发明实施例五提供的一种计算机设备的结构示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释本发明,而非对本发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与本发明相关的部分而非全部结构。此外,在不冲突的情况下,本发明中的实施例及实施例中的特征可以相互组合。
相关技术中,在解决用户播放HLS媒体流时多服务端响应不一致导致的断流问题时,需要依赖额外的专用服务器,例如DNS服务器、Nginx代理服务器以及NAT等网关服务器,会增加额外的硬件成本,且Nginx代理服务器和NAT等网关服务器容易引发一致性问题。本发明实施例设计一种新的传送流文件生成方法,首先从媒体源端获取原始媒体流,然后识别所述原始媒体流中的关键帧,最后根据关键帧识别结果对所述原始媒体流进行切分,得到传送流TS文件,从而可以保证不同服务端针对同路媒体流的切分方式统一以及不同服务端对TS文件的分片序号的命名统一,有利于解决用户播放HLS媒体流时,多服务端响应不一致导致的断流问题。
图1为本发明实施例提供的一种传送流文件生成方法所适用的应用场景的场景架构图。具体的,参考图1,该应用场景中可以包括DNS服务器10、客户端20、A服务端30和B服务端40。HLS以TS文件的分片形式供浏览器下载播放,不仅允许浏览器以长链接发起请求,而且兼容单次链接仅请求一个TS文件的分片的短链接形式。CDN在实际应用中通过域名访问服务端,拉取直播的媒体流。在短链接情况下,用户端20发送媒体流获取请求,部分播放器和浏览器会发起多个链接来请求HLS的m3u8索引中的TS文件的分片。而DNS服务器10解析返回的服务端IP通常不止一个,例如A服务端30的IP和B服务端40的IP,将会导致TS文件请求被发往不同IP对应的服务端,而同路媒体流在不同服务端的TS文件的分片是非共享的,按需生成的,若不同服务端收到请求的时间不同,则开始生成TS文件的时间不同,导致有些服务端(例如A服务端30)的m3u8索引里的TS文件,在另一些服务端(例如B服务端40)无法获取到,造成直播断流。
需要说明的是,在实际应用过程中服务端可能不止两个,本实施例只是以两个服务端(A服务端30和B服务端40)为例进行说明,对服务端的个数不进行限制。
实施例一
图2A为本发明实施例一提供的一种传送流文件生成方法的流程示意图,图2B为本发明实施例一提供的一种传送流文件生成方法的原理示意图。该方法可以由传送流文件生成装置执行,其中该装置可由软件和/或硬件实现,一般可集成在计算机设备中。如图2A所示,该方法包括:
S201,从媒体源端获取原始媒体流。
具体的,媒体源端可以为CDN原始媒体包传输集群,能够存储媒体流数据。由此,服务端在收到某一个媒体流的请求时(该请求可以是客户端发送的)能够从媒体源端获取到原始媒体流,以便后续识别原始媒体流中的关键帧。
S202,识别所述原始媒体流中的关键帧。
其中,关键帧也称作帧内编码图像(Intra-coded picture)帧或I帧,它不参考其他图像帧,只利用本帧的信息进行编码,在视频传输过程中,关键帧可单独当做图像,不需要依赖前后帧进行解压显示。
服务端在从媒体源端获取到原始媒体流之后,可以通过基于镜头的方法、帧平均法、直方图平均法、基于运动的分析方法以及基于聚类的方法等,识别出原始媒体流中的关键帧。其中,基于镜头的方法主要是将镜头检测中得到的镜头中的首帧(或尾帧)作为镜头关键帧;帧平均法是从镜头中取所有帧在某个位置上像素值的平均值,然后将镜头中该点位置的像素值最接***均值的帧作为关键帧;直方图平均法则是将镜头中所有帧的统计直方图取平均,然后选择与该平均直方图最接近的帧作为关键帧;基于运动的分析法方法通过光流分析来计算镜头中的运动量,在运动量局部最小值处选取关键帧;基于聚类的方法可以通过对视频帧进行聚类来选取关键帧。得到关键帧识别结果以后,方便后续根据关键帧识别结果对原始媒体流进行切分,得到TS文件。
S203,根据关键帧识别结果对所述原始媒体流进行切分,得到传送流TS文件。
其中,所述TS文件的第一个媒体包为关键帧,所述TS文件的长度为关键帧间隔时长的预设倍数,所述TS文件的分片序号由所述TS文件中预设位置的媒体包的属性信息确定。关键帧间隔时长可以由主播来设置。
在得到关键帧识别结果之后,可以根据关键帧识别结果对原始媒体流进行切分,也就是根据关键帧间隔时长来对TS文件原始媒体流进行切分,由于TS文件是由一系列媒体包封装生成的,那么经过上述的切分之后得到的每个TS文件的第一个媒体包都是关键帧,相应的TS文件的长度为关键帧间隔时长的预设倍数,TS文件的分片序号可以由TS文件中预设位置的媒体包的属性信息确定。同时由于不同的服务端都从媒体源端获取原始媒体流,那么上述方法就能够保证不同服务端针对同路媒体流的切分方式统一且不同服务端对序号的命名统一,进而可以解决同路直播流中不同服务端收到的请求时间不同,开始生成TS文件的时间不同,各自切割出的TS文件的分片序号也存在差异,导致有些服务端的m3u8索引中的TS文件,在另一些服务端无法获取到,造成直播断流的问题。
可选的,所述TS文件的分片序号可以具体通过以下方式确定:将所述TS文件中预设位置的媒体包的属性信息与媒体流切割单位相除并取整,得到第一数值,其中,所述属性信息以数值形式表示;将所述第一数值作为所述TS文件的分片序号。
其中,TS文件时长一般为几秒,一个音视频包时长一般为几十~几百毫秒,那么预设位置可以是第一个音视频包,也可以是第二个音视频包等等。HLS媒体流的切割单位通常用HLS_fragment表示,代表单个TS文件包含的最小播放时长,通常为4~12秒,初始时可以设置为4秒。
将TS文件中预设位置的媒体包的属性信息与媒体流切割单位相除并取整后,得到第一数值,将第一数值作为TS文件的分片序号,可以使得不同服务端对TS文件的分片序号的命名统一,以便客户端可以根据分片序号来获取对应的TS文件。
进一步的,所述属性信息可以具体包括:媒体包对应的时间戳;或者媒体包对应的由推流方设置的序号信息;或者媒体包对应的由原始媒体流接收服务端解封成私有传输协议时设置的序号信息。
其中,媒体包对应的由原始媒体流接收服务端解封成私有传输协议时设置的序号信息可以为:接收主播视频的上行方对媒体包进行编号,服务端对该编号进行解封就可以得到序号信息。例如主播通过私有的软件开发工具包(Software Development Kit,简称SDK)进行封装,SDK会给媒体包编上连续的序号。
具体的,通过上述属性信息中的任意一种与媒体流切割单位相除并取整后,得到第一数值,该第一数值为TS文件的分片序号。例如,当属性信息为TS文件中第一个媒体包对应的时间戳时,可以设定TS文件的分片序号=[dts/HLS_fragment],其中,dts表示组成TS文件第一个视频包的时间戳,HLS_fragment表示HLS媒体流切割单位。假设关键帧间隔时长为2秒,即前后关键帧时间戳dts2-dts1为2秒,HLS_fragment设置为4秒,那么生成的第一个TS文件的分片序号是[dts1/4],经过两个关键帧后dts3-dts1为4秒,且[dts3/4]与[dts1/4]不相等,且差值为1,以此保证在不同的服务端,连续的媒体包生成的TS文件的分片序号是一致且递增1的。
更进一步的,若检测到所述关键帧间隔时长超过预设媒体流切割单位,则将所述关键帧间隔时长的值作为当前的媒体流切割单位的值。
具体的,如果服务端检测到关键帧间隔时长超过预设媒体流切割单位,那么按照上述的切分方式,将无法保证TS文件的分片序号是递增1的,此时就将关键帧间隔时长的值作为当前的媒体流切割单位的值,以便确定的TS文件的分片序号能够满足要求。
本实施例提供的技术方案,首先从媒体源端获取原始媒体流,然后识别原始媒体流中的关键帧,最后根据关键帧识别结果对原始媒体流进行切分,得到传送流TS文件,TS文件的第一个媒体包为关键帧,TS文件的长度为关键帧间隔时长的预设倍数,TS文件的分片序号由TS文件中预设位置的媒体包的属性信息确定,从而可以保证不同服务端针对同路媒体流的切分方式统一以及不同服务端对TS文件的分片序号的命名统一,有利于解决用户播放HLS媒体流时,多服务端响应不一致导致的断流问题。
实施例二
图3A为本发明实施例二提供的一种传送流文件生成方法的流程示意图,图3B为本发明实施例二提供的一种传送流文件生成方法的原理示意图。本实施例是在上述各可选实施例的基础上进行优化。具体的,如图3A所示,本实施例中对当预设位置为第一个媒体包时,根据关键帧识别结果对原始媒体流进行切分,得到传送流TS文件的过程进行详细的解释说明。
S301,从媒体源端获取原始媒体流。
S302,识别所述原始媒体流中的关键帧。
S303,确定当前接收到的第一媒体包为关键帧时,根据所述第一媒体包的属性信息计算当前第一数值,将所述当前第一数值确定为待生成的第一TS文件的第一分片序号。
当预设位置为第一个媒体包时,由于TS文件的第一个媒体包为关键帧,此时可以对第一个媒体包是否为关键帧进行判断,当确定当前接收到的第一媒体包为关键帧时,则根据第一媒体包的属性信息计算当前第一数值,然后再将当前第一数值确定为待生成的第一TS文件的第一分片序号。
本发明实施例通过确定当前接收到的第一媒体包为关键帧时,计算当前第一数值,并将当前第一数值确定为待生成的第一TS文件的第一分片序号,从而可以保证不同服务端针对同路媒体流的切分方式统一。
S304、若检测到新收到的第二媒体包为关键帧,且根据所述第二媒体包的属性信息计算得到的第一数值不等于所述第一分片序号,则根据所述第一媒体包和所述第二媒体包的上一个媒体包之间的所有媒体包生成第一TS文件,并将所述第二媒体包作为下一个TS文件的首个媒体包。
如果服务端检测到新收到的第二媒体包为关键帧,并且根据第二媒体包的属性信息计算得到的第一数值不等于第一分片序号,为了保证生成的第一TS文件分片序号的一致性以及相邻分片序号的差值为1的特性,则根据第一媒体包和第二媒体包的上一个媒体包之间的所有媒体包生成第一TS文件,并将第二媒体包作为下一个TS文件的首个媒体包。
本发明实施例通过判断根据第二媒体包的属性信息计算得到的第一数值是否等于第一分片序号,从而保证相邻TS文件的首个媒体包都是关键帧,进而保证TS文件分片序号的一致性。
本实施例提供的技术方案,首先从媒体源端获取原始媒体流,接着识别所述原始媒体流中的关键帧,然后确定当前接收到的第一媒体包为关键帧时,根据第一媒体包的属性信息计算当前第一数值,将当前第一数值确定为待生成的第一TS文件的第一分片序号,最后若检测到新收到的第二媒体包为关键帧,且根据第二媒体包的属性信息计算得到的第一数值不等于第一分片序号,则根据第一媒体包和第二媒体包的上一个媒体包之间的所有媒体包生成第一TS文件,并将第二媒体包作为下一个TS文件的首个媒体包,通过对当前接收到的第一媒体包是否为关键帧进行判断,以及根据第二媒体包的属性信息计算得到的第一数值是否等于第一分片序号进行判断,可以保证相邻TS文件的首个媒体包都是关键帧,使得不同服务端对TS文件的分片序号的命名统一且相邻分片序号的差值为1,有利于解决用户播放HLS媒体流时,多服务端响应不一致导致的断流问题。
实施例三
图4A为本发明实施例三提供的一种传送流文件生成方法的流程示意图,图4B为本发明实施例三提供的一种传送流文件生成方法的原理示意图。本实施例是在上述各可选实施例的基础上进行优化。具体的,如图4A所示,本实施例中对当传送流文件生成方法应用于第一服务端,在从媒体源端获取原始媒体流之前的过程进行详细的解释说明。
S401,接收客户端的媒体流获取请求。
其中,所述客户端基于短链接形式向域名解析服务器请求服务端地址,由所述域名解析服务器向所述客户端返回所述第一服务端的第一地址信息,所述客户端基于所述第一地址信息向所述第一服务端发送媒体流获取请求。
HLS协议中以TS文件的分片形式供浏览器下载播放,既允许浏览器以长链接发起请求,亦兼容单次链接仅请求一个TS文件的分片的短链接形式进行。当客户端基于短链接形式向域名解析服务器请求服务端地址时,如果域名解析服务器向客户端返回第一服务端的第一地址信息,那么客户端就基于第一地址信息向第一服务端发送媒体流获取请求,然后第一服务端就会接收到客户端的媒体流获取请求。TS文件是累积一定时长媒体包生成的,而为了减少不必要的传输、性能消耗,只有当服务端接收到客户端的媒体流获取请求时,才会向客户端发送所生成的TS文件。
S402,从媒体源端获取原始媒体流。
S403,识别所述原始媒体流中的关键帧。
S404,根据关键帧识别结果对所述原始媒体流进行切分,得到传送流TS文件。
可选的,在所述得到传送流TS文件之后,还可以具体包括:向所述客户端发送所生成的TS文件,并在发送过程中携带所述第一地址信息。
由于第一服务端接收到了客户端的媒体流获取请求,因此在得到传送流TS文件之后,第一服务端就会向客户端发送所生成的TS文件,并在发送过程中携带第一地址信息,例如,http头携带set-Cookie:current=[base64(ip:port)],相应的第一地址信息可以存放在cookie中或者seasion中,具体存放位置不做限制。
可选的,在所述接收客户端的媒体流获取请求之后,还可以具体包括:获取所述媒体流获取请求中的目标分片序号,所述目标分片序号为第二TS文件的分片序号的下一个分片序号,所述第二TS文件为所述客户端已接收到的最后一个TS文件;若检测到本地不存在所述目标分片序号对应的TS文件,则检查所述媒体流获取请求中是否存在第二服务端的第二地址信息,其中,所述第二TS文件由所述第二服务端发送至所述客户端;若存在,则根据所述第二地址信息向所述第二服务端请求获取所述目标分片序号对应的TS文件。
第一服务端在接收到客户端的媒体流获取请求之后,可以获取媒体流获取请求中的目标分片序号,目标分片序号是客户端已接收到的相对于第一服务端而言的,上一个服务端的最后一个TS文件的分片序号的下一个分片序号,此时如果第一服务端检测到本地不存在目标分片序号对应的TS文件,说明第一服务端还未生成该TS文件,为了避免客户端的延时,在直播场景中造成客户端观看的画面卡顿,可以检查媒体流获取请求中是否存在第二服务端(即当前服务端的上一个服务端)的第二地址信息,如果存在,则根据第二地址信息向第二服务端请求获取目标分片序号对应的TS文件。
进一步的,在所述根据所述第二地址信息向所述第二服务端请求获取所述目标分片序号对应的TS文件之后,还包括:若接收到所述第二服务端返回的所述目标分片序号对应的TS文件,则将所接收到的TS文件转发至所述客户端。
相应的,如果在第一服务端根据第二地址信息向第二服务端请求获取目标分片序号对应的TS文件之后,如果收到第二服务端返回的目标分片序号对应的TS文件,则第一服务端将所接收到的TS文件转发给客户端,响应客户端的媒体流获取请求,实现播放不断流,避免因等待第一服务端生成客户端所需的TS文件所造成的延时以及播放画面跳变,卡顿等情况。
更进一步的,在从媒体源端获取原始媒体流的同时,根据所述第二地址信息向所述第二服务端请求获取所述目标分片序号对应的TS文件。
具体的,可以在从媒体源端获取原始媒体流的同时,根据第二地址信息向第二服务端请求获取目标分片序号对应的TS文件,这样可以减少客户端等待的时间,提高客户端用户的使用体验。同时为了减小数据交互,前一个服务端可以直接返回请求响应(发送完毕或者文件不存在时关闭链接)给当前服务端。
可选的,若所述媒体流获取请求中不存在所述第二地址信息,或者未成功解析出所述第二地址信息,或者未成功接收所述第二服务端返回的TS文件,则暂停响应所述媒体流获取请求;从媒体源端的缓存中拉取预设数量的连续的音视频包,其中,所述连续的音视频包中包含预设个数的关键帧;根据所拉取到的音视频包生成第三TS文件;在当前生成的第三TS文件的分片序号大于或等于所述目标分片序号时,将所述第三TS文件发送至所述客户端。
如果媒体流获取请求中不存在第二地址信息,说明客户端可能是首次观看的用户,或者如果没有成功解析出第二地址信息,或者没有成功接收到第二服务端返回的TS文件,为了避免客户端断播,当前服务端应避免直接返回404NOT FOUND,此时要暂停响应该媒体流获取请求。然后从媒体源端的缓存中拉取预设数量的连续的音视频包,预设数量一般可以设置为3个,根据所拉取到的音视频包生成第三TS文件,并计算当前生成的第三TS文件的分片序号,在计算出的分片序号大于或等于目标分片序号时,将第三TS文件发送至客户端,从而能够保证客户端不断播,提高客户端的使用体验。
本发明实施例在收到请求的当前服务端发现本地缓存不存在对应的TS文件时,通过向上一个服务端请求对应的TS文件,可以避免播放画面跳变及卡顿。
进一步的,当某一服务端机器宕机时,可以通过探测进程(daemon)自动发起摘除DNS映射,其上的用户请求可快速切换到另一台服务器。具体的,服务端进程可以主动定时向daemon汇报自己的状态,假如daemon一段时间没收到汇报,就认为服务端出现了问题,DNS服务器把这个IP的域名摘掉。或者,daemon可以定期扫描域名下的那些IP机器是不是能访问,例如发一个http请求,看能否收到响应,如果几次收不到就认为。还可以是以上两种方法结合使用,(即不仅收不到汇报,而且发请求没有响应,才认为服务端出现了异常)避免因网络问题导致误判,还可以降低维护成本。
具体的,下面通过一个CDN直播场景来对切服务端HLS不断播进行说明,主播采用RTMP协议推流到服务端,用户借助浏览器通过HLS协议观看直播流。上行的协议,服务间传输的私有协议与观看的协议可以不一致。首先在管理后台添加主播的推流域名和观众的播流域名,并将推流域名和拉流域名注册cname绑定到CDN服务器端,接着主播配置obs播放器推RTMP协议媒体流,用户可以通过vlc或浏览器拉HLS流播放,最后切服务端HLS不断播生效验证。具体验证过程为:通过chrome(浏览器)开发者工具可直接查看请求响应,例如请求1234-8276.ts媒体文件,DNS解析获取的IP是60.9.4.39,而下一个1234-8277.ts请求,又重新DNS解析到另一个服务端IP 42.56.85.111。通过应用本实施例中的方案,服务端的切换并没有引起异常和断流。二者请求响应延时没有明显差异,不影响后续正常播流。
本发明实施例中服务端之间媒体流传输无需局限于HLS格式,可用更小的未封装原始媒体流传输(如h264、aac),易扩展新协议,更灵活且可以节省带宽。
本实施例提供的技术方案,首先接收客户端的媒体流获取请求,接着从媒体源端获取原始媒体流,然后识别原始媒体流中的关键帧,最后根据关键帧识别结果对原始媒体流进行切分,得到传送流TS文件,可以解决用户播放HLS媒体流时,多服务端响应不一致导致的断流问题,并且无需依赖额外的专用服务器,能够节省机器成本,接收用户访问的各服务端机器是等价的,播放流可由不同的服务端提供,保证连续。
实施例四
图5为本发明实施例四提供的一种传送流文件生成装置的结构示意图,该装置可由软件和/或硬件实现,一般可集成在计算机设备中。如图5所示,该装置可以包括:
原始媒体流获取模块501,用于从媒体源端获取原始媒体流;
关键帧识别模块502,用于识别所述原始媒体流中的关键帧;
TS文件获取模块503,用于根据关键帧识别结果对所述原始媒体流进行切分,得到传送流TS文件,其中,所述TS文件的第一个媒体包为关键帧,所述TS文件的长度为关键帧间隔时长的预设倍数,所述TS文件的分片序号由所述TS文件中预设位置的媒体包的属性信息确定。
本实施例提供的技术方案,首先从媒体源端获取原始媒体流,然后识别原始媒体流中的关键帧,最后根据关键帧识别结果对原始媒体流进行切分,得到传送流TS文件,TS文件的第一个媒体包为关键帧,TS文件的长度为关键帧间隔时长的预设倍数,TS文件的分片序号由TS文件中预设位置的媒体包的属性信息确定。通过采用上述技术方案,可以保证不同服务端针对同路媒体流的切分方式统一以及不同服务端对TS文件的分片序号的命名统一,有利于解决用户播放HLS媒体流时,多服务端响应不一致导致的断流问题。
本实施例提供的传送流文件生成装置可适用于上述任意实施例提供的传送流文件生成方法,具备相应的功能和有益效果。
实施例五
图6为本发明实施例五提供的一种计算机设备的结构示意图,如图6所示:该计算机设备包括存储器601、处理器602和通信装置603;计算机设备中处理器602的数量可以是一个或多个,图6中以一个处理器602为例;计算机设备中的存储器601、处理器602和通信装置603可以通过总线或其他方式连接,图6中以通过总线连接为例。
本实施例提供的一种计算机设备可用于执行上述任意实施例提供的传送流文件生成方法,具备相应的功能和有益效果。
实施例六
本发明实施例六提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时可实现上述任意实施例提供的传送流文件生成方法。该方法可以具体包括:
从媒体源端获取原始媒体流;
识别所述原始媒体流中的关键帧;
根据关键帧识别结果对所述原始媒体流进行切分,得到传送流TS文件,其中,所述TS文件的第一个媒体包为关键帧,所述TS文件的长度为关键帧间隔时长的预设倍数,所述TS文件的分片序号由所述TS文件中预设位置的媒体包的属性信息确定。
当然,本发明实施例所提供的一种包含计算机可执行指令的存储介质,其计算机可执行指令不限于如上所述的方法操作,还可以执行本发明任意实施例提供的传送流文件生成方法中的相关操作。
通过以上关于实施方式的描述,所属领域的技术人员可以清楚地了解到,本发明可借助软件及必需的通用硬件来实现,当然也可以通过硬件实现,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
值得注意的是,上述传送流文件生成装置的实施例中,所包括的各个单元和模块只是按照功能逻辑进行划分的,但并不局限于上述的划分,只要能够实现相应的功能即可;另外,各功能单元的具体名称也只是为了便于相互区分,并不用于限制本发明的保护范围。
以上所述仅为本发明的优选实施例,并不用于限制本发明,对于本领域技术人员而言,本发明可以有各种改动和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (14)

1.一种传送流文件生成方法,其特征在于,包括:
从媒体源端获取原始媒体流;
识别所述原始媒体流中的关键帧;
根据关键帧识别结果对所述原始媒体流进行切分,得到传送流TS文件,其中,所述TS文件的第一个媒体包为关键帧,所述TS文件的长度为关键帧间隔时长的预设倍数,所述TS文件的分片序号由所述TS文件中预设位置的媒体包的属性信息确定。
2.根据权利要求1所述的方法,其特征在于,所述TS文件的分片序号通过以下方式确定:
将所述TS文件中预设位置的媒体包的属性信息与媒体流切割单位相除并取整,得到第一数值,其中,所述属性信息以数值形式表示;
将所述第一数值作为所述TS文件的分片序号。
3.根据权利要求2所述的方法,其特征在于,所述属性信息包括:
媒体包对应的时间戳;或者媒体包对应的由推流方设置的序号信息;或者媒体包对应的由原始媒体流接收服务端解封成私有传输协议时设置的序号信息。
4.根据权利要求2所述的方法,其特征在于,所述预设位置为第一个媒体包,所述根据关键帧识别结果对所述原始媒体流进行切分,得到传送流TS文件,包括:
确定当前接收到的第一媒体包为关键帧时,根据所述第一媒体包的属性信息计算当前第一数值,将所述当前第一数值确定为待生成的第一TS文件的第一分片序号;
若检测到新收到的第二媒体包为关键帧,且根据所述第二媒体包的属性信息计算得到的第一数值不等于所述第一分片序号,则根据所述第一媒体包和所述第二媒体包的上一个媒体包之间的所有媒体包生成第一TS文件,并将所述第二媒体包作为下一个TS文件的首个媒体包。
5.根据权利要求2所述的方法,其特征在于,若检测到所述关键帧间隔时长超过预设媒体流切割单位,则将所述关键帧间隔时长的值作为当前的媒体流切割单位的值。
6.根据权利要求1-5任一所述的方法,其特征在于,应用于第一服务端,在所述从媒体源端获取原始媒体流之前,还包括:
接收客户端的媒体流获取请求,其中,所述客户端基于短链接形式向域名解析服务器请求服务端地址,由所述域名解析服务器向所述客户端返回所述第一服务端的第一地址信息,所述客户端基于所述第一地址信息向所述第一服务端发送媒体流获取请求。
7.根据权利要求6所述的方法,其特征在于,在所述得到传送流TS文件之后,还包括:
向所述客户端发送所生成的TS文件,并在发送过程中携带所述第一地址信息。
8.根据权利要求7所述的方法,其特征在于,在所述接收客户端的媒体流获取请求之后,还包括:
获取所述媒体流获取请求中的目标分片序号,所述目标分片序号为第二TS文件的分片序号的下一个分片序号,所述第二TS文件为所述客户端已接收到的最后一个TS文件;
若检测到本地不存在所述目标分片序号对应的TS文件,则检查所述媒体流获取请求中是否存在第二服务端的第二地址信息,其中,所述第二TS文件由所述第二服务端发送至所述客户端;
若存在,则根据所述第二地址信息向所述第二服务端请求获取所述目标分片序号对应的TS文件。
9.根据权利要求8所述的方法,其特征在于,在所述根据所述第二地址信息向所述第二服务端请求获取所述目标分片序号对应的TS文件之后,还包括:
若接收到所述第二服务端返回的所述目标分片序号对应的TS文件,则将所接收到的TS文件转发至所述客户端。
10.根据权利要求9所述的方法,其特征在于,在从媒体源端获取原始媒体流的同时,根据所述第二地址信息向所述第二服务端请求获取所述目标分片序号对应的TS文件。
11.根据权利要求10所述的方法,其特征在于,还包括:;
若所述媒体流获取请求中不存在所述第二地址信息,或者未成功解析出所述第二地址信息,或者未成功接收所述第二服务端返回的TS文件,则暂停响应所述媒体流获取请求;
从媒体源端的缓存中拉取预设数量的连续的音视频包,其中,所述连续的音视频包中包含预设个数的关键帧;
根据所拉取到的音视频包生成第三TS文件;
在当前生成的第三TS文件的分片序号大于或等于所述目标分片序号时,将所述第三TS文件发送至所述客户端。
12.一种传送流文件生成装置,其特征在于,包括:
原始媒体流获取模块,用于从媒体源端获取原始媒体流;
关键帧识别模块,用于识别所述原始媒体流中的关键帧;
TS文件获取模块,用于根据关键帧识别结果对所述原始媒体流进行切分,得到传送流TS文件,其中,所述TS文件的第一个媒体包为关键帧,所述TS文件的长度为关键帧间隔时长的预设倍数,所述TS文件的分片序号由所述TS文件中预设位置的媒体包的属性信息确定。
13.一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时实现如权利要求1-11中任一项所述的方法。
14.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现如权利要求1-11中任一所述的方法。
CN202011173330.2A 2020-10-28 2020-10-28 一种传送流文件生成方法、装置、设备及存储介质 Withdrawn CN112367527A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011173330.2A CN112367527A (zh) 2020-10-28 2020-10-28 一种传送流文件生成方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011173330.2A CN112367527A (zh) 2020-10-28 2020-10-28 一种传送流文件生成方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
CN112367527A true CN112367527A (zh) 2021-02-12

Family

ID=74511130

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011173330.2A Withdrawn CN112367527A (zh) 2020-10-28 2020-10-28 一种传送流文件生成方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN112367527A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113965714A (zh) * 2021-09-10 2022-01-21 北京百度网讯科技有限公司 视频流的处理方法、装置、电子设备及存储介质
CN114845132A (zh) * 2022-04-29 2022-08-02 抖动科技(深圳)有限公司 基于哈希算法的低延迟直播缓存方法、装置、设备及介质
CN115086714A (zh) * 2022-06-13 2022-09-20 京东科技信息技术有限公司 数据处理方法、装置、设备及存储介质
CN117336311A (zh) * 2023-11-30 2024-01-02 深圳市小溪流科技有限公司 一种使多台hls服务器切片保持一致性的方法及其装置

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113965714A (zh) * 2021-09-10 2022-01-21 北京百度网讯科技有限公司 视频流的处理方法、装置、电子设备及存储介质
CN114845132A (zh) * 2022-04-29 2022-08-02 抖动科技(深圳)有限公司 基于哈希算法的低延迟直播缓存方法、装置、设备及介质
CN114845132B (zh) * 2022-04-29 2023-05-12 厦门理工学院 基于哈希算法的低延迟直播缓存方法、装置、设备及介质
CN115086714A (zh) * 2022-06-13 2022-09-20 京东科技信息技术有限公司 数据处理方法、装置、设备及存储介质
CN117336311A (zh) * 2023-11-30 2024-01-02 深圳市小溪流科技有限公司 一种使多台hls服务器切片保持一致性的方法及其装置
CN117336311B (zh) * 2023-11-30 2024-03-12 深圳市小溪流科技有限公司 一种使多台hls服务器切片保持一致性的方法及其装置

Similar Documents

Publication Publication Date Title
CN112367527A (zh) 一种传送流文件生成方法、装置、设备及存储介质
EP3780523B1 (en) Network traffic identification method and related device
US7185084B2 (en) Server-side measurement of client-perceived quality of service
JP6444398B2 (ja) セグメント化コンテンツのストリーミング
US20160080470A1 (en) Server-side playlist stitching
CN110876080B (zh) 视频投屏方法、装置、计算机设备及存储介质
US10003999B2 (en) HTTP-based buffer status updating method and device, and buffer status processor
RU2647654C2 (ru) Система и способ доставки аудиовизуального контента в клиентское устройство
US10313710B1 (en) Synchronizing encoding between encoders
JP2016530751A (ja) 品質対ビットレートが変動するメディアデータストリームの品質を決定するための概念
EP3123734A1 (en) Targeted advertisement insertion for streaming media data
CN109495505B (zh) 流媒体协议转换方法、装置、***及计算机可读介质
TW201332343A (zh) 可適性串流建立與遞送之虛擬化
CN108924609B (zh) 流媒体数据传输的方法、电子设备、装置及存储介质
CN105471869A (zh) 一种互联网电视内容请求的连接复用方法及***
US9813475B1 (en) Delivering a video stream
WO2023061060A1 (zh) 音视频码流的调度方法、***、介质及电子装置
CN107920072B (zh) 一种基于数据特征的多媒体共享方法及***
WO2015154549A1 (zh) 数据的处理方法及装置
US11095699B1 (en) Streaming media file management
US9432731B2 (en) Method and system for detecting live over the top (OTT) streams in communications networks
KR20160138044A (ko) 미디어 데이터를 스트리밍하기 위한 목표된 광고 삽입
US20180146261A1 (en) Message Sending Method and Device, Code Stream Processing Method and Device
US20150036526A1 (en) Method and system for efficient transmission of over-the-top streams over fixed-line networks
CN108632681B (zh) 播放媒体流的方法、服务器及终端

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
WW01 Invention patent application withdrawn after publication

Application publication date: 20210212

WW01 Invention patent application withdrawn after publication