CN117527922A - 流媒体多协议的转换方法、流媒体服务器、设备和介质 - Google Patents

流媒体多协议的转换方法、流媒体服务器、设备和介质 Download PDF

Info

Publication number
CN117527922A
CN117527922A CN202311704415.2A CN202311704415A CN117527922A CN 117527922 A CN117527922 A CN 117527922A CN 202311704415 A CN202311704415 A CN 202311704415A CN 117527922 A CN117527922 A CN 117527922A
Authority
CN
China
Prior art keywords
media stream
protocol
original audio
media
format
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
CN202311704415.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.)
China United Network Communications Group Co Ltd
Unicom Digital Technology Co Ltd
Unicom Cloud Data Co Ltd
Original Assignee
China United Network Communications Group Co Ltd
Unicom Digital Technology Co Ltd
Unicom Cloud Data 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 China United Network Communications Group Co Ltd, Unicom Digital Technology Co Ltd, Unicom Cloud Data Co Ltd filed Critical China United Network Communications Group Co Ltd
Priority to CN202311704415.2A priority Critical patent/CN117527922A/zh
Publication of CN117527922A publication Critical patent/CN117527922A/zh
Pending legal-status Critical Current

Links

Classifications

    • 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/08Protocols for interworking; Protocol conversion
    • 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
    • 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/643Communication protocols
    • 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/643Communication protocols
    • H04N21/6437Real-time Transport Protocol [RTP]

Landscapes

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

Abstract

本发明公开一种流媒体多协议的转换方法、流媒体服务器、设备和介质,涉及数据处理技术领域。方法包括:获取第一媒体流。第一媒体流采用的协议标准为第一协议标准。根据第一媒体流的格式对第一媒体流进行解析,以获取第一媒体流的原始音视频帧。以及,根据预设的标准格式对第一媒体流的原始音视频帧进行封装,得到第二媒体流,以对第二媒体流进行后处理。其中,第一协议标准为RTMP,或者HLS,或者RTSP,或者GB28181。第二媒体流的格式为预设的标准格式。后处理包括播放,和/或录制,和/或智能分析。本发明能同时支持大规模应用的GB28181流媒体收流,RTSP的推拉流,RTMP的推拉流和HLS的拉流。支持大规模同质化部署,利于上层业务层进行以流为基本单元的调度形式。

Description

流媒体多协议的转换方法、流媒体服务器、设备和介质
技术领域
本发明涉及数据处理技术领域,尤其涉及一种流媒体多协议的转换方法、流媒体服务器、设备和介质。
背景技术
流媒体技术应用广泛,在多个行业场景中都有具体的表现形式。
流媒体技术在具体的某个场景或者行业一般会使用特定的协议标准,例如,在视频直播中,常见的协议标准是实时消息协议RTMP(Real Time Messaging Protocol)和基于超文本传送协议Http(Hypertext Transfer Protocol)的实时流媒体传输协议HLS(HttpLive Streaming)。在安防监控中,常见的协议标准是实时流传输协议RTSP(RealTime Streaming Protocol,或Real Time Stream Protocol)和视频监控领域的国家标准GB28181。在网络课堂和视频会议中,常见的协议标准是网页实时通信协议WEBRTC(WebReal-Time Communications)。
其中,RTMP的底层传输协议是传输控制协议TCP(Transfer Control Protocol),RTMP同时支持推流和拉流模式。HLS的底层传输协议是TCP,但其本身是在应用层协议Http上再进行协议封装,HLS协议只支持拉流模式,不支持推流模式。RTSP同时支持用户数据报协议UDP(User Datagram Protocol)或者TCP,且同时支持推流和拉流模式,应用层基于实时传输协议RTP(Real-time Transport Protocol)再进行协议封装。GB28181协议在流媒体部分底层传输协议也可以同时支持UDP或者TCP,流媒体交互依靠会话初始协议SIP(Session initialization Protocol)信令通信建立流媒体传输通道。WEBRTC流媒体传输应用层基于RTP再进行协议封装,底层也同时支持UDP或者TCP,但其信令交互方式与RTSP和GB28181差距极大。从而,上述各个协议有各自的特点,各个协议之间差别极大。
各厂商在实际应用中对协议的实现可以做到符合标准,但是具体的实现方案或者技术细节的差异较大,从而导致流媒体服务在对接各个协议的过程中会面对许多兼容性的问题。
发明内容
本发明所要解决的技术问题是:现有技术中流媒体服务在对接各个协议的过程中面对的许多兼容性的问题。
针对现有技术的上述不足,提供以下方案:
第一方面,本发明提供一种流媒体多协议的转换方法,应用于流媒体服务器,转换方法包括:获取第一媒体流。第一媒体流采用的协议标准为第一协议标准。根据第一媒体流的格式对第一媒体流进行解析,以获取第一媒体流的原始音视频帧。以及,根据预设的标准格式对第一媒体流的原始音视频帧进行封装,得到第二媒体流,以对第二媒体流进行后处理。其中,第一协议标准为实时消息协议RTMP,或者基于超文本传送协议Http的实时流媒体传输协议HLS,或者实时流传输协议RTSP,或者视频监控领域的国家标准GB28181。第二媒体流的格式为预设的标准格式。后处理包括播放,和/或录制,和/或智能分析。
可选地,获取第一媒体流包括:响应于接收到来自用户的指令,获取第一媒体流。
可选地,获取第一媒体流,包括:调用第一接口,通过第一接口向第一设备返回第一网络地址,以使第一设备基于第一网络地址与流媒体服务器建立网络连接。第一网络地址指向流媒体服务器。第一设备是第一媒体流的来源。以及,通过第一接口接收来自第一设备的第一媒体流。
可选地,方法还包括:响应于流媒体服务器与第一设备之间已建立的网络连接断开,流媒体服务器再次调用所述第一接口,以重新建立与第一设备的连接。
可选地,方法还包括:将获取到的第一媒体流的原始音视频帧送入缓冲区。根据预设的标准格式对第一媒体流的原始音视频帧进行封装,包括:从缓冲区提取第一媒体流的原始音视频帧,并根据预设的标准格式对第一媒体流的原始音视频帧进行封装。
可选地,响应于第一协议标准为GB28181,根据第一媒体流的格式对第一媒体流进行解析,以获取第一媒体流的原始音视频帧,包括:按照RTP格式的解析方法对第一媒体流进行解析,以获取多个第一数据包。校验多个第一数据包的SSRC值,以确定多个第一数据包是否来自第一设备。响应于多个第一数据包来自第一设备,获取多个第一数据包中每个第一数据包的时间戳的值。从多个第一数据包中提取多个第二数据包。按照PS格式的解析方法对多个第二数据包进行解析,以提取第一媒体流的原始音视频帧中时间戳的值为第一数值的原始音视频帧。以及,根据第一媒体流的原始音视频帧中时间戳的值为第一数值的原始音视频帧获取第一媒体流的原始音视频帧。其中,第一设备是第一媒体流的来源。多个第二数据包中每个第二数据包的时间戳的值为第一数值。第一数值为多个第一数据包中每个第一数据包的时间戳的值中任一个时间戳的值。第一媒体流的原始音视频帧中时间戳的值为第一数值的原始音视频帧包括按照PS格式的解析方法对多个第二数据包进行解析后的数据。
可选地,响应于第一协议标准为RTSP,根据第一媒体流的格式对第一媒体流进行解析,以获取第一媒体流的原始音视频帧,包括:按照RTP格式的解析方法对第一媒体流进行解析,以获取多个第三数据包。校验多个第三数据包的SSRC值,以确定多个第三数据包是否来自第一设备。响应于多个第三数据包来自第一设备,获取多个第三数据包中每个第三数据包的时间戳的值。从多个第三数据包中提取多个第四数据包。根据多个第四数据包获取第一媒体流的原始音视频帧中时间戳的值为第二数值的原始音视频帧。以及,根据第一媒体流的原始音视频帧中时间戳的值为第二数值的原始音视频帧获取第一媒体流的原始音视频帧。其中,第一设备是第一媒体流的来源。多个第四数据包中每个第四数据包的时间戳的值为第二数值。第二数值为多个第三数据包中每个第三数据包的时间戳的值中的任一个时间戳的值。
可选地,响应于第一协议标准为RTMP,根据第一媒体流的格式对第一媒体流进行解析,以获取第一媒体流的原始音视频帧,包括:将第一媒体流解析为多个RTMP数据块,并根据多个RTMP数据块获取多个RTMP数据单元。从多个RTMP数据单元中提取出多个音视频类的RTMP数据单元。获取多个音视频类的RTMP数据单元中每个音视频类的RTMP数据单元的时间戳的值。从多个音视频类的RTMP数据单元中提取多个第一数据单元。根据多个第一数据单元获取第一媒体流的原始音视频帧中时间戳的值为第三数值的原始音视频帧。以及,根据第一媒体流的原始音视频帧中时间戳的值为第三数值的原始音视频帧获取第一媒体流的原始音视频帧。其中,多个第一数据单元中每个第一数据单元的时间戳的值为第三数值。第三数值为多个音视频类的RTMP数据单元中每个音视频类的RTMP数据单元的时间戳的值中任一个时间戳的值。
可选地,响应于第一协议标准为HLS,根据第一媒体流的格式对第一媒体流进行解析,以获取第一媒体流的原始音视频帧,包括:通过Http获取HLS媒体列表m3u8格式文件。对HLS媒体列表m3u8格式文件进行解析,以获取HLS媒体文件路径与名称。基于HLS媒体文件路径与名称通过Http获取HLS媒体文件的TS格式文件。以及,对HLS媒体文件的TS格式文件进行解析,以提取第一媒体流的音视频流格式及第一媒体流的原始音视频帧。
第二方面,本发明提供一种流媒体服务器,包括第一媒体流获取模块,解析模块和封装模块。其中,第一媒体流获取模块设置为:获取第一媒体流。第一媒体流采用的协议标准为第一协议标准。第一协议标准为实时消息协议RTMP,或者基于超文本传送协议Http的实时流媒体传输协议HLS,或者实时流传输协议RTSP,或者视频监控领域的国家标准GB28181。解析模块设置为:根据第一媒体流的格式对第一媒体流进行解析,以获取第一媒体流的原始音视频帧。封装模块设置为:根据预设的标准格式对第一媒体流的原始音视频帧进行封装,得到第二媒体流,以对第二媒体流进行后处理。第二媒体流的格式为预设的标准格式。后处理包括播放,和/或录制,和/或智能分析。
第三方面,本发明提供一种计算机设备,包括存储器和处理器,存储器中存储有计算机程序,当处理器运行存储器存储的计算机程序时,处理器执行上述流媒体多协议的转换方法。
第四方面,本发明提供一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时,处理器执行上述流媒体多协议的转换方法。
本发明提供的流媒体多协议的转换方法、流媒体服务器、设备和介质,能同时支持大规模应用的GB28181协议流媒体收流,RTSP协议的推拉流,RTMP协议的推拉流和HLS协议的拉流。支持大规模同质化部署,利于上层业务层进行以流为基本单元的调度形式。同时给出了以原始音视频帧为缓存的中间数据格式,与相关技术中多种协议模式相比,更具通用性。并且同时支持多种协议的转换且各协议之间互不影响,各协议的支持独立实现,协议兼容性升级不会造成其他协议支持断流等,有利于保持平台更高的录像完整率的要求,对于对接多种协议时如何针对不同的协议标准提取出原始音视频帧的问题,本发明的实施例给出了具体的实施步骤,有独特的实现方式,更易兼容标准协议的不同具体实现。不同协议标准化为自定义格式后以本地换回网络发送后处理服务性能损失小,网络协议栈处理效率高。
附图说明
图1为本发明实施例中一种流媒体多协议的转换方法的流程图;
图2为本发明实施例中另一种流媒体多协议的转换方法的流程图;
图3为本发明实施例中再一种流媒体多协议的转换方法的流程图;
图4为本发明实施例中又一种流媒体多协议的转换方法的流程图;
图5为本发明实施例中又一种流媒体多协议的转换方法的流程图;
图6为本发明实施例中又一种流媒体多协议的转换方法的流程图;
图7为本发明实施例中又一种流媒体多协议的转换方法的流程图;
图8为本发明实施例中一种流媒体服务器的结构图;
图9为本发明实施例中另一种流媒体服务器的结构图;
图10为本发明实施例中再一种流媒体服务器的结构图;
图11为本发明实施例中又一种流媒体服务器的结构图;
图12为本发明实施例中又一种流媒体服务器的结构图;
图13为本发明实施例中又一种流媒体服务器的结构图;
图14为本发明实施例中一种计算机设备的结构图。
具体实施方式
为使本领域技术人员更好地理解本发明的技术方案,下面将结合附图对本发明实施方式作进一步地详细描述。
可以理解的是,此处描述的具体实施例和附图仅仅用于解释本发明,而非对本发明的限定。
可以理解的是,在不冲突的情况下,本发明中的各实施例及实施例中的各特征可相互组合。
可以理解的是,为便于描述,本发明的附图中仅示出了与本发明相关的部分,而与本发明无关的部分未在附图中示出。
可以理解的是,本发明的实施例中所涉及的每个单元、模块可仅对应一个实体结构,也可由多个实体结构组成,或者,多个单元、模块也可集成为一个实体结构。
可以理解的是,在不冲突的情况下,本发明的流程图和框图中所标注的功能、步骤可按照不同于附图中所标注的顺序发生。
可以理解的是,本发明的流程图和框图中,示出了按照本发明各实施例的***、装置、设备、方法的可能实现的体系架构、功能和操作。其中,流程图或框图中的每个方框可代表一个单元、模块、程序段、代码,其包含用于实现规定的功能的可执行指令。而且,框图和流程图中的每个方框或方框的组合,可用实现规定的功能的基于硬件的***实现,也可用硬件与计算机指令的组合来实现。
可以理解的是,本发明实施例中所涉及的单元、模块可通过软件的方式实现,也可通过硬件的方式来实现,例如单元、模块可位于处理器中。
针对多种协议的兼容问题,相关技术中,流媒体服务领域主要包括两种实现方式。
一种方式是围绕特定的协议实现收发流,使用一个服务器针对特定的某种协议实现网络包的转发,该方式下服务主要的缓存数据都是该协议的封装包。例如,以RTMP为核心的流媒体服务器(比如,以围绕RTMP协议为核心的CRtmpServer,以围绕RTSP协议为核心的Live555)数据流转核心一般都是RTMP-MESSAGE(或称为Rtmp-Message)封装格式,服务的协议一般仅支持RTMP推拉流和FLV(一种RTMP协议的封装)推拉流,同样以RTSP或者WEBRTC为核心的流媒体服务器数据流转核心一般都是RTP的数据包,不会解析到音视频原始帧。此种情况下,可能存在协议核心数据格式问题不一致导致的转换到别的协议的时候要做大量复杂的解析与再封装,扩展协议支持是比较困难的。该方式的优点是不同服务器组用来完成自己独立的协议接入,无需关心其他协议的实现和业务稳定。但是在当前业务融合程度越来越高的情况下,该种方式对业务层业务调度压力要求较高,同时不利于大规模部署与运营。
另一种方式可以支持多种协议的接入,但仅支持部分协议的输出。例如,同时支持RTSP和RTMP以及其他某些协议的接入,但仅输出为RTMP/HLS/FLV三协议,多见于将需要接入的协议解析封装为自定义封装格式并转换为直播三协议(RTMP/HLS/FLV)。此种情况下,若要扩展新的协议格式,接入端也需要进行大量复杂的解析与再封装,扩展输出协议时同样比较很困难,需要打破原设计体系,并且,升级扩展协议接入会对其他已接入协议的正常传输造成影响。此外,这种方式上对各个协议的支持可能不够完整,例如对GB28181的支持中,服务可能不支持主动模式的TCP方式,对RTMP和RTSP协议的支持中,服务可能只支持推流模式,不支持拉流模式,而如果想对每种协议的支持进行改造,能难度比较大,协议之间可能做不到兼容。例如,同时支持GB28181和RTSP的方式中,GB28181和RTSP虽然都是以RTP方式的数据进行流转,但是RTSP本身包含了信令部分,同时支持拉流和推流并支持GB28181的一般信令部分可以独立实现,同时支持UDP和TCP,在TCP中又分支持主动模式和被动模式,这样若对其完整实现改造难度较大,对GB28181中RTP封装的是PS各种数据,其负载(payload)的类型(type)是96,也能直接封装H264和H265,其负载的类型是97和98,而RTSP中负载类型96代表的是H264,如此就与GB28181中的定义有冲突,所以很难做到同时全部支持GB28181和RTSP。该方式从性能上具有更高的理论值,协议的转换可以做到同类型协议以协议封装中间态转发,不同类型协议的转换可以自定义一个标准中间数据封装格式转发,由于都是内存中操作,性能上可以做到最好,但是对技术要求高,不同协议支持的稳定性也会影响其他协议支持的稳定程度。
考虑到相关技术中多协议的兼容实现难度的问题,本发明的实施例提供一种流媒体多协议的转换方法,应用于流媒体服务器,如图1所示,该方法包括步骤101至步骤103。
步骤101、获取第一媒体流。
步骤101中第一媒体流采用的协议标准为第一协议标准。第一协议标准为RTMP,或者HLS,或者RTSP,或者GB28181。
可以理解地,RTMP,或者HLS,或者RTSP,或者GB28181均支持拉流,RTSP或者RTMP,或者GB28181还支持推流。推流指的是把采集阶段封包好的内容传输到服务器的过程。拉流是指根据协议类型(如RTMP、RTP、RTSP、HTTP等)服务器与客户端主动建立连接并接收数据,进行拉取的过程。
可以理解地,GB28181全称为GB/T-28181《安全防范视频监控联网***信息传输、交换、控制技术要求》,是视频监控场景下主流的协议标准。GB28181中媒体流传输协议采用RTP/实时传输控制协议RTCP(Real-time ControlProtocol)(依据RFC4571规范),媒体流以MPEG2-PS封装。
可以理解地,本发明的实施例设计了GB28181网关(或称为GB28181Gateway),GB28181网关支持三个应用程序编程接口API(Application Programming Interface),该三个API分别为:gb28181新建接口(或称为create_gb28181接口),gb28181删除接口(或称为delete_gb28181接口)和gb28181更新接口(或称为update_gb28181接口)。gb28181新建接口通过下发流ID和对应该流ID的同步信源标识符SSRC(synchronization sourceidentifier),通过gb28181删除接口删除对流ID的接收,通过gb28181更新接口来设置可能更新的流相关信息,比如SSRC(GB28181协议标准存在更新SSRC的情况)等。综上,gb28181新建接口可以建立流ID和SSRC的关系,并向信令服务返回收流的地址,以使信令服务将收流的地址发送给摄像头(即第一设备),从而建立摄像头(第一设备)与服务器(流媒体服务器)之间的流媒体传输通道。gb28181删除接口可以删除对某个流ID的接收,并关闭对应套接字(或称为socket)可以停止对某路GB28181流的接收。
可以理解地,RTSP多见于视频会议,安防监控等场景,是多个业务场景的主流协议标准。RTSP中媒体流传输协议也采用RTP/RTCP传输,但依据的是RFC2326规范,媒体流以原始音视频帧封装,依照RFC3984规范分帧拆包。
可以理解地,在对RTSP的支持中,本发明的实施例同时支持了RTSP议的推流和拉流,RTSP网关(或称为RTSPGateway)可以启动监听554端口,以接收RTSP推流,比如,可以根据554端口下对应信令的交互结果老确定流ID与SSRC的对应关系,并可以根据554端口下对应信令的交互结果来接收RTSP推流。同时,RTSP网关提供rtsp新建接口(或称为create_rtsp接口)来支持RTSP拉流,通过下发流ID和对应的RTSP拉流地址,实现RTSP网关主动向摄像头(第一设备)发起RTSP信令交互并拉取摄像头的RTSP流。此外,RTSP网关还提供rtsp更新接口(或称为update_rtsp接口)来更新流ID和RTSP拉流地址之间的对应关系,RTSP网关还提供rtsp删除接口(或称为delete_rtsp接口)来关闭RTSP拉流,以停止拉取RTSP并转换为统一的后处理流格式。
可以理解地,RTMP多见于网络直播,网络点播等场景,常见于设备端主动推流的模式场景。RTMP采用基于数据块(Chunk)的传输方式,媒体流以RTMP数据单元(Rtmp-Message)的格式进行封装。
可以理解地,对RTMP协议的支持,本发明的实施例也同时支持RTMP推流和RTMP拉流。在RTMP网关(RTMPGateway)启动后,可以直接监听1935端口以接收RTMP的推流。同时,本发明的实施例提供rtmp新建接口(或称为create_rtmp接口)用于下发流ID和拉流RTMP的统一资源***url(Uniform Resource Locator)地址,以主动访问RTMP服务器并建立流媒体通道,从而收取RTMP流。本发明的实施例提供rtmp更新接口(或称为update_rtmp接口)用于更新流ID和RTMP拉流地址之间的对应关系,提供rtmp删除接口(或称为delete_rtmp接口)用于停止拉流RTMP,并关闭该流ID和url拉流之间的对应关系。
可以理解地,HLS是基于Http的流媒体传输协议,由于浏览器对其良好原生支持,其广泛应用于视频点播和直播领域。HLS通过Http提供媒体列表文件并支持媒体文件下载,从而达到流式传输的效果,其传输层协议仅通过Http即可完成,媒体流以传输流MPEG2-TS(MPEG-2Transport Stream,又称MPEG-TS、MTS、TS,是一种传输和存储包含视频、音频与通信协议各种数据的标准格式,用于数字电视广播***)封装。
可以理解地,由于HLS协议仅支持HTTP的拉流,我们设计的HLS网关提供hls新建接口(或称为create_hls接口)用于建立流id和拉流hlsurl之间的关系,用于将http下载ts后解析的流统一封装为标准格式并发送到后处理服务,提供hls更新接口(或称为update_hls接口)用于更新拉流ID和HLS拉流地址之间的对应关系,提供hls删除接口(或称为delete_hls接口)用于关闭拉流hls,并取消流id和该拉流hls之间的关系。
在一些实施例中,步骤101的实现方式可以包括:响应于接收到来自用户的指令,获取第一媒体流。
可以理解地,在用户有使用需求的情况下,可以向流媒体服务器发出请求。
在一些实施例中,如图2所示,步骤101的实现方法可以包括步骤1011与步骤1012。
步骤1011、调用第一接口,通过第一接口向第一设备返回第一网络地址,以使第一设备基于第一网络地址与流媒体服务器建立网络连接。
步骤1011中,第一网络地址指向流媒体服务器。第一设备是第一媒体流的来源。
示例性地,第一接口可以指的是gb28181新建接口或gb28181新建或rtmp新建接口。
步骤1012,通过第一接口接收来自第一设备的第一媒体流。
可以理解地,步骤1011与步骤1012所展示的获取第一媒体流的方法适用于通过拉流的方式获取媒体流的情况。
在一些实施例中,方法还包括:响应于流媒体服务器与第一设备之间已建立的网络连接断开,流媒体服务器再次调用第一接口,以重新建立与第一设备的连接。
可以理解地,流媒体服务器与第一设备之间正在传输数据时,有可能出现网络断开的情况,此种情况下,流媒体服务器可以再次调用第一接口,以重新建立与第一设备的连接。
在一些实施例中,响应于第一协议标准为RTSP或者RTMP,,步骤101的实现方式可以包括:监听第二接口,以通过第二接口接收第一媒体流。
可以理解地,在第一协议标准包括RTSP或者RTMP的情况下,可以通过监听第二接口以通过第二接口接收第一媒体流。第一协议标准包括RTSP的情况下,第二接口可以为554端口。第一协议标准包括RTMP的情况下,第二接口可以为1953端口。
可以理解地,在第一协议标准包括RTSP或者RTMP的情况下,用户可以触发第一设备上的推流,流媒体服务器可以通过第二接口获取由第一设备主动推送的第一媒体流。
步骤102、根据第一媒体流的格式对第一媒体流进行解析,以获取第一媒体流的原始音视频帧。
在一些实施例中,如图3所示,响应于第一协议标准为GB28181,步骤102的实现方式包括步骤301至步骤306。
步骤301、按照RTP格式的解析方法对第一媒体流进行解析,以获取多个第一数据包。
步骤302、校验多个第一数据包的SSRC值,以确定多个第一数据包是否来自第一设备。
步骤302中,第一设备是第一媒体流的来源。
步骤303、响应于多个第一数据包来自第一设备,获取多个第一数据包中每个第一数据包的时间戳的值。
步骤304、从多个第一数据包中提取多个第二数据包。
步骤304中,多个第二数据包中每个第二数据包的时间戳的值为第一数值,第一数值为多个第一数据包中每个第一数据包的时间戳的值中任一个时间戳的值。
步骤305、按照PS格式的解析方法对多个第二数据包进行解析,以提取第一媒体流的原始音视频帧中时间戳的值为第一数值的原始音视频帧。
步骤305中,第一媒体流的原始音视频帧中时间戳的值为第一数值的原始音视频帧包括按照PS格式的解析方法对多个第二数据包进行解析后的数据。
可以理解地,多个第二数据包中每个第二数据包的时间戳的值为第一数值,说明多个第二数据包可以对应于第一媒体流的原始音视频帧中时间戳的值为第一数值的原始音视频帧。也就是说,多个第二数据包是根据PS格式对第一媒体流的原始音视频帧中时间戳的值为第一数值的原始音视频帧进行封装而形成的。从而,按照PS格式的解析方法对多个第二数据包进行解析,即可以得到第一媒体流的原始音视频帧中时间戳的值为第一数值的原始音视频帧。
步骤306、根据第一媒体流的原始音视频帧中时间戳的值为第一数值的原始音视频帧获取第一媒体流的原始音视频帧。
可以理解地,第一数值为多个第一数据包中每个第一数据包的时间戳的值中任一个时间戳的值,从而通过步骤301至步骤305,可以获取第一媒体流的原始音视频帧中时间戳的值为任一个时间戳的值的原始音视频帧,从而,可以根据第一媒体流的原始音视频帧中时间戳的值为任一个时间戳的值的原始音视频帧获取第一媒体流的原始音视频帧。
示例性地,对第一媒体流的原始音视频帧中的每一帧原始音视频的时间戳的值进行排序,即可按照第一媒体流的原始音视频帧中的每一帧原始音视频的时间戳的值的顺序对第一媒体流的原始音视频帧中的每一帧原始音视频排序,从而获取第一媒体流的原始音视频帧。
可以理解地,在对GB28181的支持中,相关技术在解析时,有些方法是跳过RTP协议的解析,以查找PS头为开始。如此可能会造成的问题是在RTP丢包的情况下容易造成错误数据被解析到PS中。还有些方法在对RTP进行解析时,遇到字段Marker则认为是一帧的结尾,再解析PS,然而有些摄像头(第一设备)在发送的RTP包在帧结束的时候并不打Marker标记,从而无法实现在对RTP进行解析时,遇到字段Marker则认为是一帧的结尾的方法。
可以理解地,步骤301至步骤306以时间戳相同的RTP数据为一帧PS数据,这种方法更具通用性,在有些摄像头(第一设备)的实现中会存在一个Marker中间的RTP包打多个时间戳,步骤301至步骤306也仍然可以兼容该种方式,比如,可以对其时间戳进行矫正,从而形成在一个Marker中间是同一个时间戳,同时就可以实现我们的设计以时间戳进行分帧处理。
在一些实施例中,如图4所示,响应于第一协议标准为RTSP,步骤102的实现方式包括步骤401至步骤406。
步骤401、按照RTP格式的解析方法对第一媒体流进行解析,以获取多个第三数据包。
步骤402、校验多个第三数据包的SSRC值,以确定多个第三数据包是否来自第一设备。
步骤402中,第一设备是第一媒体流的来源。
步骤403、响应于多个第三数据包来自第一设备,获取多个第三数据包中每个第三数据包的时间戳的值。
步骤404、从多个第三数据包中提取多个第四数据包。
步骤404中,多个第四数据包中每个第四数据包的时间戳的值为第二数值。第二数值为多个第三数据包中每个第三数据包的时间戳的值中的任一个时间戳的值。
步骤405、根据多个第四数据包获取第一媒体流的原始音视频帧中时间戳的值为第二数值的原始音视频帧。
可以理解地,多个第四数据包中每个第二数据包的时间戳的值为第二数值,说明多个第四数据包可以对应于第一媒体流的原始音视频帧中时间戳的值为第二数值的原始音视频帧。也就是说,可以根据多个第四数据包获取第一媒体流的原始音视频帧中时间戳的值为第二数值的原始音视频帧。
步骤406、根据第一媒体流的原始音视频帧中时间戳的值为第二数值的原始音视频帧获取第一媒体流的原始音视频帧。
可以理解地,第二数值为多个第三数据包中每个第三数据包的时间戳的值中的任一个时间戳的值,从而通过步骤401至步骤405,可以获取第一媒体流的原始音视频帧中时间戳的值为任一个时间戳的值的原始音视频帧,即可以获取第一媒体流的原始音视频帧中的每一帧原始音视频。从而,可以根据第一媒体流的原始音视频帧中的每一帧原始音视频获取第一媒体流的原始音视频帧。
示例性地,对第一媒体流的原始音视频帧中的每一帧原始音视频的时间戳的值进行排序,即可按照第一媒体流的原始音视频帧中的每一帧原始音视频的时间戳的值的顺序对第一媒体流的原始音视频帧中的每一帧原始音视频排序,从而获取第一媒体流的原始音视频帧。在一些实施例中,如图5所示,响应于第一协议标准为RTMP,步骤102的实现方式包括步骤501至步骤506。
步骤501、将第一媒体流解析为多个RTMP数据块,并根据多个RTMP数据块获取多个RTMP数据单元。
步骤502、从多个RTMP数据单元中提取出多个音视频类的RTMP数据单元。
步骤503、获取多个音视频类的RTMP数据单元中每个音视频类的RTMP数据单元的时间戳的值。
步骤504、从多个音视频类的RTMP数据单元中提取多个第一数据单元。
步骤504中,多个第一数据单元中每个第一数据单元的时间戳的值为第三数值。第三数值为多个音视频类的RTMP数据单元中每个音视频类的RTMP数据单元的时间戳的值中任一个时间戳的值。
步骤505、根据多个第一数据单元获取第一媒体流的原始音视频帧中时间戳的值为第三数值的原始音视频帧。
可以理解地,多个第一数据单元中每个第一数据单元的时间戳的值为第三数值,说明多个第一数据单元可以对应于第一媒体流的原始音视频帧中时间戳的值为第三数值的原始音视频帧。也就是说,可以根据多个第一数据单元获取第一媒体流的原始音视频帧中时间戳的值为第三数值的原始音视频帧。
步骤506、根据第一媒体流的原始音视频帧中时间戳的值为第三数值的原始音视频帧获取第一媒体流的原始音视频帧。
可以理解地,第三数值为多个音视频类的RTMP数据单元中每个音视频类的RTMP数据单元的时间戳的值中任一个时间戳的值,从而通过步骤501至步骤505,可以获取第一媒体流的原始音视频帧中时间戳的值为任一个时间戳的值的原始音视频帧,即可以获取第一媒体流的原始音视频帧中的每一帧原始音视频。从而,可以根据第一媒体流的原始音视频帧中的每一帧原始音视频获取第一媒体流的原始音视频帧。
示例性地,对第一媒体流的原始音视频帧中的每一帧原始音视频的时间戳的值进行排序,即可按照第一媒体流的原始音视频帧中的每一帧原始音视频的时间戳的值的顺序对第一媒体流的原始音视频帧中的每一帧原始音视频排序,从而获取第一媒体流的原始音视频帧。
在一些实施例中,如图6所示,响应于第一协议标准为HLS,步骤102的实现方式包括步骤601至步骤604。
步骤601、通过Http获取HLS媒体列表m3u8格式文件。
步骤602、对HLS媒体列表m3u8格式文件进行解析,以获取HLS媒体文件路径与名称。
步骤603、基于HLS媒体文件路径与名称通过Http获取HLS媒体文件的TS格式文件。
步骤604、对HLS媒体文件的TS格式文件进行解析,以提取第一媒体流的音视频流格式及第一媒体流的原始音视频帧。
可以理解地,以上支持的GB28181,RTSP,RTMP议和HLS都以独立服务的形式存在,相互之间不影响,可以做到协议隔离。
步骤103、根据预设的标准格式对第一媒体流的原始音视频帧进行封装,得到第二媒体流,以对第二媒体流进行后处理。
步骤103中,第二媒体流的格式为预设的标准格式。后处理包括播放,和/或录制,和/或智能分析。
可以理解地,智能分析是视频智能化应用的一个场景需求,例如,根据实时视频分析视频中的画面,如检测人员入侵,检测火情,检测烟雾报警等等。
在一些实施例中,如图7所示,步骤103之前,方法还包括步骤104。
步骤104、将获取到的第一媒体流的原始音视频帧送入缓冲区。
如此,如图7所示,步骤103的实现方式可以为:从缓冲区提取第一媒体流的原始音视频帧,并根据预设的标准格式对第一媒体流的原始音视频帧进行封装,得到第二媒体流,以对第二媒体流进行后处理。
可以理解地,在得到第二媒体流之后,可以通过本地环回网络(即网络通信地址127.0.0.1)发送至后处理服务,如此,协议层不过内核,性能损耗小,无丢包,网络无延迟。
可以理解地,由于本地环回网络处理从TCP协议栈上不用进入内核封包转化,其性能损失小,延迟累积小,对于安防/录像等场景对录像完整率要求更高,对延迟要求更低的场景更实用。另一方面,某些场景例如播放场景可能要求较高的低延迟特性,我们该种方案的优势是可以后处理服务将播放请求转给原流所在的服务上直接输出为对应播放协议的场景,从而实现低延迟特性。
本发明的实施例提供的一种流媒体多协议的转换方法,能同时支持大规模应用的GB28181协议流媒体收流,RTSP协议的推拉流,RTMP协议的推拉流和HLS协议的拉流。支持大规模同质化部署,利于上层业务层进行以流为基本单元的调度形式。同时给出了以原始音视频帧为缓存的中间数据格式,与相关技术中多种协议模式相比,更具通用性。并且同时支持多种协议的转换且各协议之间互不影响,各协议的支持独立实现,协议兼容性升级不会造成其他协议支持断流等,有利于保持平台更高的录像完整率的要求,对于对接多种协议时如何针对不同的协议标准提取出原始音视频帧的问题,本发明的实施例给出了具体的实施步骤,有独特的实现方式,更易兼容标准协议的不同具体实现。不同协议标准化为自定义格式后以本地换回网络发送后处理服务性能损失小,网络协议栈处理效率高。
本发明的实施例提供的一种流媒体多协议的转换方法具有广泛的应用价值,尤其在安防监控、视频直播、网络会议等场景因为需要支持多种标准协议,协议之间需要相互转换,以统一的标准中间格式对服务的稳定性和兼容性都具有较高的价值。
本发明的实施例提供一种流媒体服务器,如图8所示,流媒体服务器800包括第一媒体流获取模块801,解析模块802和封装模块803。
第一媒体流获取模块801设置为:获取第一媒体流。第一媒体流采用的协议标准为第一协议标准。第一协议标准包括实时消息协议RTMP,或者基于超文本传送协议Http的实时流媒体传输协议HLS,或者实时流传输协议RTSP,或者视频监控领域的国家标准GB28181。
解析模块802设置为:根据第一媒体流的格式对第一媒体流进行解析,以获取第一媒体流的原始音视频帧。
封装模块803设置为:根据预设的标准格式对第一媒体流的原始音视频帧进行封装,得到第二媒体流,以对第二媒体流进行后处理。第二媒体流的格式为预设的标准格式。后处理包括播放,和/或录制,和/或智能分析。
在一些实施例中,如图9所示,流媒体服务器800还包括用户指令接收模块804。用户指令接收模块804设置为:接收来自用户的指令。第一媒体流获取模块801设置为:响应于接收到来自用户的指令,获取第一媒体流。
在一些实施例中,如图10所示,第一媒体流获取模块801还包括第一接口805。第一媒体流获取模块801设置为:调用第一接口,通过所述第一接口向第一设备返回第一网络地址,以使第一设备基于第一网络地址与流媒体服务器建立网络连接。第一网络地址指向流媒体服务器。第一设备是第一媒体流的来源。以及,通过第一接口接收来自第一设备的第一媒体流。
在一些实施例中,第一媒体流获取模块801还设置为:响应于流媒体服务器与第一设备之间已建立的网络连接断开,流媒体服务器再次调用所述第一接口,以重新建立与第一设备的连接。
在一些实施例中,如图11所示,流媒体服务器800还包括缓冲区806。解析模块802还设置为:将获取到的第一媒体流的原始音视频帧送入缓冲区。封装模块803还设置为:从缓冲区提取第一媒体流的原始音视频帧,并根据预设的标准格式对第一媒体流的原始音视频帧进行封装。
在一些实施例中,响应于第一协议标准为GB28181,解析模块802设置为:按照RTP格式的解析方法对第一媒体流进行解析,以获取多个第一数据包。校验多个第一数据包的SSRC值,以确定多个第一数据包是否来自第一设备。响应于多个第一数据包来自第一设备,获取多个第一数据包中每个第一数据包的时间戳的值。从多个第一数据包中提取多个第二数据包。按照PS格式的解析方法对多个第二数据包进行解析,以提取第一媒体流的原始音视频帧中时间戳的值为第一数值的原始音视频帧。以及,根据第一媒体流的原始音视频帧中时间戳的值为第一数值的原始音视频帧获取第一媒体流的原始音视频帧。其中,第一设备是第一媒体流的来源。多个第二数据包中每个第二数据包的时间戳的值为第一数值。第一数值为多个第一数据包中每个第一数据包的时间戳的值中任一个时间戳的值。第一媒体流的原始音视频帧中时间戳的值为第一数值的原始音视频帧包括按照PS格式的解析方法对多个第二数据包进行解析后的数据。
在一些实施例中,响应于第一协议标准为RTSP,解析模块802设置为:按照RTP格式的解析方法对第一媒体流进行解析,以获取多个第三数据包。校验多个第三数据包的SSRC值,以确定多个第三数据包是否来自第一设备。响应于多个第三数据包来自第一设备,获取多个第三数据包中每个第三数据包的时间戳的值。从多个第三数据包中提取多个第四数据包。根据多个第四数据包获取第一媒体流的原始音视频帧中时间戳的值为第二数值的原始音视频帧。以及,根据第一媒体流的原始音视频帧中时间戳的值为第二数值的原始音视频帧获取第一媒体流的原始音视频帧。其中,第一设备是第一媒体流的来源。多个第四数据包中每个第四数据包的时间戳的值为第二数值。第二数值为多个第三数据包中每个第三数据包的时间戳的值中的任一个时间戳的值。
在一些实施例中,响应于第一协议标准为RTMP,解析模块802设置为:将第一媒体流解析为多个RTMP数据块,并根据多个RTMP数据块获取多个RTMP数据单元。从多个RTMP数据单元中提取出多个音视频类的RTMP数据单元。获取多个音视频类的RTMP数据单元中每个音视频类的RTMP数据单元的时间戳的值。从多个音视频类的RTMP数据单元中提取多个第一数据单元。根据多个第一数据单元获取第一媒体流的原始音视频帧中时间戳的值为第三数值的原始音视频帧。以及,根据第一媒体流的原始音视频帧中时间戳的值为第三数值的原始音视频帧获取第一媒体流的原始音视频帧。其中,多个第一数据单元中每个第一数据单元的时间戳的值为第三数值。第三数值为多个音视频类的RTMP数据单元中每个音视频类的RTMP数据单元的时间戳的值中任一个时间戳的值。
在一些实施例中,响应于第一协议标准为HLS,解析模块802设置为:通过Http获取HLS媒体列表m3u8格式文件。对HLS媒体列表m3u8格式文件进行解析,以获取HLS媒体文件路径与名称。基于HLS媒体文件路径与名称通过Http获取HLS媒体文件的TS格式文件。以及,对HLS媒体文件的TS格式文件进行解析,以提取第一媒体流的音视频流格式及第一媒体流的原始音视频帧。
示例性地,如图12所示,流媒体服务器800包括GB28181网关,RSTP网关,RTMP网关和HLS网关。
GB28181网关包括gb28181新建接口01,gb28181删除接口02,gb28181更新接口03,解析单元8021,缓冲单元8061和解析单元8031。第一接口805可以包括gb28181新建接口01,解析模块802可以包括解析单元8021,缓冲区806可以包括缓冲单元8061,解析模块803可以包括解析单元8031。解析单元8021可以实现上述实施例提供的一种流媒体多协议的转换方法中步骤301至步骤306。
RSTP网关包括rtsp新建接口04,rtsp更新接口05,rtsp删除接口06,554端口07,解析单元8022,缓冲单元8062和解析单元8032。第一接口805可以包括rtsp新建接口04,第二接口可以包括554端口07,解析模块802可以包括解析单元8022,缓冲区806可以包括缓冲单元8062,解析模块803可以包括解析单元8032。解析单元8022可以实现上述实施例提供的一种流媒体多协议的转换方法中步骤401至步骤406。关于第二接口的描述可以参考上述实施例提供的一种流媒体多协议的转换方法中的相关描述,此处不再赘述。
RTMP网关包括rtmp新建接口08,rtmp更新接口09,rtmp删除接口10,1935端口11,解析单元8023,缓冲单元8063和解析单元8033。第一接口805可以包括rtmp新建接口08,第二接口可以包括1935端口11,解析模块802可以包括解析单元8023,缓冲区806可以包括缓冲单元8063,解析模块803可以包括解析单元8033。解析单元8023可以实现上述实施例提供的一种流媒体多协议的转换方法中步骤501至步骤506。
HLS网关包括hls新建接口12,hls更新接口13,hls删除接口14,解析单元8024,缓冲单元8064和解析单元8034。第一接口805可以包括hls新建接口12,解析模块802可以包括解析单元8024,缓冲区806可以包括缓冲单元8064,解析模块803可以包括解析单元8034。解析单元8024可以实现上述实施例提供的一种流媒体多协议的转换方法中步骤601至步骤604。
在一些实施例中,如图13所示,流媒体服务器800还可以包括后处理模块807。后处理模块807设置为:获取第二媒体流并对第二媒体流进行播放,和/或录制,和/或智能分析。
本发明的一些实施例提供的一种流媒体服务器800的具体方案及有益效果可参考本发明的一些实施例提供的一种流媒体多协议的转换方法的相关描述,此处不再赘述。
本发明的一些实施例提供一种计算机设备,如图14所示,计算机设备1400包括存储器1401和处理器1402,存储器1401中存储有计算机程序,当处理器1402运行存储器1401存储的计算机程序时,处理器1402执行上述的流媒体多协议的转换方法。
本发明的一些实施例提供的一种计算机设备的具体方案及有益效果可参考本发明的一些实施例提供的一种流媒体多协议的转换方法的相关描述,此处不再赘述。
本发明的一些实施例提供一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时,处理器执行上述的流媒体多协议的转换方法。
本发明的一些实施例提供的一种计算机可读存储介质的具体方案及有益效果可参考本发明的一些实施例提供的一种流媒体多协议的转换方法的相关描述,此处不再赘述。
可以理解的是,以上实施方式仅仅是为了说明本发明的原理而采用的示例性实施方式,然而本发明并不局限于此。对于本领域内的普通技术人员而言,在不脱离本发明的精神和实质的情况下,可以做出各种变型和改进,这些变型和改进也视为本发明的保护范围。

Claims (12)

1.一种流媒体多协议的转换方法,其特征在于,应用于流媒体服务器,所述转换方法包括:
获取第一媒体流;所述第一媒体流采用的协议标准为第一协议标准;所述第一协议标准为实时消息协议RTMP,或者基于超文本传送协议Http的实时流媒体传输协议HLS,或者实时流传输协议RTSP,或者视频监控领域的国家标准GB28181;
根据所述第一媒体流的格式对所述第一媒体流进行解析,以获取所述第一媒体流的原始音视频帧;以及
根据预设的标准格式对所述第一媒体流的原始音视频帧进行封装,得到第二媒体流,以对所述第二媒体流进行后处理;所述第二媒体流的格式为所述预设的标准格式;所述后处理包括播放,和/或录制,和/或智能分析。
2.根据权利要求1所述的流媒体多协议的转换方法,其特征在于,所述获取第一媒体流包括:响应于接收到来自用户的指令,获取所述第一媒体流。
3.根据权利要求1所述的流媒体多协议的转换方法,其特征在于,所述获取第一媒体流,包括:
调用第一接口,通过所述第一接口向第一设备返回第一网络地址,以使所述第一设备基于所述第一网络地址与所述流媒体服务器建立网络连接;所述第一网络地址指向所述流媒体服务器;所述第一设备是所述第一媒体流的来源;以及
通过所述第一接口接收来自所述第一设备的所述第一媒体流。
4.根据权利要求3所述的流媒体多协议的转换方法,其特征在于,
响应于所述流媒体服务器与所述第一设备之间已建立的网络连接断开,所述流媒体服务器再次调用所述第一接口,以重新建立与所述第一设备的连接。
5.根据权利要求1所述的流媒体多协议的转换方法,其特征在于,还包括:将获取到的所述第一媒体流的原始音视频帧送入缓冲区;所述根据预设的标准格式对所述第一媒体流的原始音视频帧进行封装,包括:从所述缓冲区提取所述第一媒体流的原始音视频帧,并根据预设的标准格式对所述第一媒体流的原始音视频帧进行封装。
6.根据权利要求1所述的流媒体多协议的转换方法,其特征在于,响应于所述第一协议标准为所述GB28181,所述根据所述第一媒体流的格式对所述第一媒体流进行解析,以获取所述第一媒体流的原始音视频帧,包括:
按照RTP格式的解析方法对所述第一媒体流进行解析,以获取多个第一数据包;
校验所述多个第一数据包的同步信源标识符SSRC值,以确定所述多个第一数据包是否来自第一设备;所述第一设备是所述第一媒体流的来源;
响应于所述多个第一数据包来自所述第一设备,获取所述多个第一数据包中每个第一数据包的时间戳的值;
从所述多个第一数据包中提取多个第二数据包,所述多个第二数据包中每个第二数据包的时间戳的值为第一数值;所述第一数值为所述多个第一数据包中每个第一数据包的时间戳的值中任一个时间戳的值;
按照PS格式的解析方法对所述多个第二数据包进行解析,以提取第一媒体流的原始音视频帧中时间戳的值为所述第一数值的原始音视频帧;所述第一媒体流的原始音视频帧中时间戳的值为所述第一数值的原始音视频帧包括按照PS格式的解析方法对所述多个第二数据包进行解析后的数据;以及
根据所述第一媒体流的原始音视频帧中时间戳的值为所述第一数值的原始音视频帧获取所述第一媒体流的原始音视频帧。
7.根据权利要求1所述的流媒体多协议的转换方法,其特征在于,响应于所述第一协议标准为所述RTSP,所述根据所述第一媒体流的格式对所述第一媒体流进行解析,以获取所述第一媒体流的原始音视频帧,包括:
按照RTP格式的解析方法对所述第一媒体流进行解析,以获取多个第三数据包;
校验所述多个第三数据包的SSRC值,以确定所述多个第三数据包是否来自第一设备;所述第一设备是所述第一媒体流的来源;
响应于所述多个第三数据包来自所述第一设备,获取所述多个第三数据包中每个第三数据包的时间戳的值;
从所述多个第三数据包中提取多个第四数据包,所述多个第四数据包中每个第四数据包的时间戳的值为第二数值;所述第二数值为所述多个第三数据包中每个第三数据包的时间戳的值中任一个时间戳的值;
根据所述多个第四数据包获取第一媒体流的原始音视频帧中时间戳的值为所述第二数值的原始音视频帧;以及
根据所述第一媒体流的原始音视频帧中时间戳的值为所述第二数值的原始音视频帧获取所述第一媒体流的原始音视频帧。
8.根据权利要求1所述的流媒体多协议的转换方法,其特征在于,响应于所述第一协议标准为所述RTMP,所述根据所述第一媒体流的格式对所述第一媒体流进行解析,以获取所述第一媒体流的原始音视频帧,包括:
将所述第一媒体流解析为多个RTMP数据块,并根据所述多个RTMP数据块获取多个RTMP数据单元;
从所述多个RTMP数据单元中提取出多个音视频类的RTMP数据单元;
获取所述多个音视频类的RTMP数据单元中每个音视频类的RTMP数据单元的时间戳的值;
从所述多个音视频类的RTMP数据单元中提取多个第一数据单元,所述多个第一数据单元中每个第一数据单元的时间戳的值为第三数值;所述第三数值为所述多个音视频类的RTMP数据单元中每个音视频类的RTMP数据单元的时间戳的值中任一个时间戳的值;
根据所述多个第一数据单元获取第一媒体流的原始音视频帧中时间戳的值为所述第三数值的原始音视频帧;以及
根据所述第一媒体流的原始音视频帧中时间戳的值为所述第三数值的原始音视频帧获取所述第一媒体流的原始音视频帧。
9.根据权利要求1所述的流媒体多协议的转换方法,其特征在于,响应于所述第一协议标准为所述HLS,所述根据所述第一媒体流的格式对所述第一媒体流进行解析,以获取所述第一媒体流的原始音视频帧,包括:
通过所述Http获取HLS媒体列表m3u8格式文件;
对所述HLS媒体列表m3u8格式文件进行解析,以获取HLS媒体文件路径与名称;
基于所述HLS媒体文件路径与名称通过所述Http获取所述HLS媒体文件的TS格式文件;以及
对所述HLS媒体文件的TS格式文件进行解析,以提取所述第一媒体流的音视频流格式及所述第一媒体流的原始音视频帧。
10.一种流媒体服务器,其特征在于,包括:
第一媒体流获取模块,其设置为:获取第一媒体流;所述第一媒体流采用的协议标准为第一协议标准;所述第一协议标准为实时消息协议RTMP,或者基于超文本传送协议Http的实时流媒体传输协议HLS,或者实时流传输协议RTSP,或者视频监控领域的国家标准GB28181;
解析模块,其设置为:根据所述第一媒体流的格式对所述第一媒体流进行解析,以获取所述第一媒体流的原始音视频帧;
封装模块,其设置为:根据预设的标准格式对所述第一媒体流的原始音视频帧进行封装,得到第二媒体流,以对所述第二媒体流进行后处理;所述第二媒体流的格式为所述预设的标准格式;所述后处理包括播放,和/或录制,和/或智能分析。
11.一种计算机设备,其特征在于,包括存储器和处理器,所述存储器中存储有计算机程序,当所述处理器运行所述存储器存储的计算机程序时,所述处理器执行根据权利要求1至9中任一项所述的流媒体多协议的转换方法。
12.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时,所述处理器执行根据权利要求1至9中任一项所述的流媒体多协议的转换方法。
CN202311704415.2A 2023-12-12 2023-12-12 流媒体多协议的转换方法、流媒体服务器、设备和介质 Pending CN117527922A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311704415.2A CN117527922A (zh) 2023-12-12 2023-12-12 流媒体多协议的转换方法、流媒体服务器、设备和介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311704415.2A CN117527922A (zh) 2023-12-12 2023-12-12 流媒体多协议的转换方法、流媒体服务器、设备和介质

Publications (1)

Publication Number Publication Date
CN117527922A true CN117527922A (zh) 2024-02-06

Family

ID=89747855

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311704415.2A Pending CN117527922A (zh) 2023-12-12 2023-12-12 流媒体多协议的转换方法、流媒体服务器、设备和介质

Country Status (1)

Country Link
CN (1) CN117527922A (zh)

Similar Documents

Publication Publication Date Title
US20160337424A1 (en) Transferring media data using a websocket subprotocol
CN108243153B (zh) 一种在视联网中播放电视节目的方法和装置
JP5474983B2 (ja) Iptvセッションをセットアップするためのネットワーク装置及び方法
CN110121059B (zh) 监控视频处理方法、装置及存储介质
WO2012028022A1 (zh) 一种直播内容分发方法和***
US20180176278A1 (en) Detecting and signaling new initialization segments during manifest-file-free media streaming
KR101821123B1 (ko) 웹브라우저 상에서 미디어 스트림을 재생하는 방법 및 장치
CN108965220B (zh) 一种会议控制权同步的方法及***
CN109379254B (zh) 一种基于视频会议的网络连接的检测方法和***
KR102098723B1 (ko) Mmt 전송 패킷의 설정 방법 및 전송 방법
CN110475131B (zh) 一种终端连接方法、服务器和终端
CN110113558B (zh) 数据处理方法、装置、***及计算机可读存储介质
CN110113564B (zh) 一种数据获取方法和视联网***
CN111614927A (zh) 视频会话建立法、装置、电子设备及存储介质
CN110536178B (zh) 一种直播控制方法和***
CN110769297A (zh) 一种音视频数据的处理方法和***
CN110138729B (zh) 一种数据获取方法和视联网***
CN110086773B (zh) 一种音视频数据的处理方法和***
Andriescu et al. AmbiStream: a middleware for multimedia streaming on heterogeneous mobile devices
CN110753234A (zh) 一种国标ps流转rtmp直播流的实时转换方法
CN114339146B (zh) 音视频监控方法、装置、电子设备及计算机可读存储介质
JP2002152301A (ja) データ通信システム、データ受信装置、データ通信方法、並びにプログラム記憶媒体
CN117527922A (zh) 流媒体多协议的转换方法、流媒体服务器、设备和介质
CN112153022B (zh) 一种rtmp快速发布和订阅方法
CN110113565B (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