CN111107445B - 一种媒体协议流优化方法及系统 - Google Patents

一种媒体协议流优化方法及系统 Download PDF

Info

Publication number
CN111107445B
CN111107445B CN201811269677.XA CN201811269677A CN111107445B CN 111107445 B CN111107445 B CN 111107445B CN 201811269677 A CN201811269677 A CN 201811269677A CN 111107445 B CN111107445 B CN 111107445B
Authority
CN
China
Prior art keywords
server
client
stream
response
media
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.)
Active
Application number
CN201811269677.XA
Other languages
English (en)
Other versions
CN111107445A (zh
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.)
Zhejiang Uniview Technologies Co Ltd
Original Assignee
Zhejiang Uniview Technologies 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 Zhejiang Uniview Technologies Co Ltd filed Critical Zhejiang Uniview Technologies Co Ltd
Priority to CN201811269677.XA priority Critical patent/CN111107445B/zh
Publication of CN111107445A publication Critical patent/CN111107445A/zh
Application granted granted Critical
Publication of CN111107445B publication Critical patent/CN111107445B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/254—Management at additional data server, e.g. shopping server, rights management server
    • H04N21/2541—Rights Management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25875—Management of end-user data involving end-user authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26606—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for generating or managing entitlement messages, e.g. Entitlement Control Message [ECM] or Entitlement Management Message [EMM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4623—Processing of entitlement messages, e.g. ECM [Entitlement Control Message] or EMM [Entitlement Management Message]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Graphics (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种媒体协议流优化方法及系统，客户端根据业务类型拼接URL信息，所述URL信息中包括序列号，在拼接完成后，携带URL信息向服务端发送启流请求，服务端收到启流请求后，解析URL信息，若满足启流条件则向客户端返回携带媒体数据信息的成功应答，并准备媒体数据发送至客户端；否则向客户端返回失败应答；所述成功应答或失败应答中包含有所述序列号，以便客户端根据应答中携带的序列号判断是否是启流请求对应的应答。本发明减少了启流时所需的时间开销，优化了启流步骤，相比现有技术耗时更短；并在信令交互的同时伴随着数据信息，减少了客户端对网络稳定性以及服务端性能的依赖，增加了整个流程的稳定性。

Description

一种媒体协议流优化方法及系统
技术领域
本发明属于流媒体通信技术领域，具体涉及一种媒体协议流优化方法及系统。
背景技术
RTSP(Real Time Streaming Protocol，实时流传输协议)是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP(实时传输协议)和RTCP(实时传输控制协议)之上，它使用TCP(传输控制协议)或UDP(用户数据报协议)完成数据传输。HTTP(超文本传输协议)与RTSP相比，HTTP请求由客户机发出，服务器作出应答；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。
RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制(Multicast)，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制，除了可以降低服务器端的网络用量，更进而支持多方视讯会议(Video Conference)。因为其与HTTP1.1的运作方式相似，所以代理服务器(Proxy Server)的快取功能(Cache)也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
随着IP监控技术的推广，媒体传输协议，在IPC或NVR等设备上被越来越广泛的使用，其中一种比较常用网络协议就是RTSP协议，它拥有可扩展性，解析性，安全性，独立于传输，适合专业应用等特性，而且其实时性非常高，已经成为了监控系统中不可缺少的一部分。
现有技术中，RTSP协议的启流(开启流量)需要通过URL(统一资源定位符)来进行，该URL由客户端向服务端获取，即在启流前准备URL，如图1所示，客户端向服务端发送GetURL请求，服务端应答该请求后返回URL。
随后开始启流，如图2所示，通常情况下RTSP启流要通过多条信令才能完成启流，主要包括如下：
Step1、DESCRIBE request。
首先由客户端发起，向服务端请求URL指定的媒体流的相关信息，它可能使用同一头部(Accept header)来指出客户端能理解的描述格式，比如视频、音频编码格式，采样率以及对应的Payload协商值，用于后续码流解析识别。服务端以所请求的资源的描述作为回应，DESCRIBE的答复-应答组成媒体RTSP初始阶段。DESCRIBE response必须包含它所描述的资源的所有媒体初始化信息。
Step1.5、鉴权。
服务端向客户端发送Need authentication的鉴权请求，客户端根据该鉴权请求准备相应的鉴权信息authentication，并将其添加至URL后向服务端返回DESCRIBE+authentication的鉴权应答。其中服务端提供的鉴权方式采用的是Digest(摘要算法)和Basic(base64)两种加密方式。
Step2、SETUP request。
客户端向服务端发送SETUP request，让服务端给流分配资源，根据服务端应答的SETUP response启动RTSP会话。
Step3、PLAY request。
客户端向服务端发送PLAY request，根据服务端应答的PLAY response启动客户端与服务端之间SETUP所分配的流的数据传输。
通过上述指信令交互之后，服务端才向客户端发送媒体流数据(Media Data)，完成启流操作。
启流完成后，为了保证流正常，还需要通过信令进行保活，如图3所示，在信令交互过程中，可能存在媒体数据(虚线表示可能存在的与信令交互同时进行的媒体数据)或网络波动的干扰，在这种情况下，客户端必须先保证接收信令后才继续进行其他流程，否则将影响交互的正常进行。
其中信令用途如下：
OPTION：该请求在任何时候都可能产生，例如：当一个客户端准备尝试一个非标准的请求时，该请求就有可能会产生，但它不影响服务端的状态。
由上述RTSP的交互过程可以看出，RTSP存在一定的局限性，首先就是启流的交互过程过多，在网络较为复杂的情况或穿网等情况下影响启流速度；再则就是保活和信令控制过于依赖于对端的应答，导致在网络拥塞的情况下应答较慢。
发明内容
本发明的目的在于提供一种媒体协议流优化方法及系统，优化启流步骤，减少了启流时所需的时间开销，加快启流速度，且减少了客户端对网络稳定性以及服务端性能的依赖。
为实现上述目的，本发明所采取的技术方案如下：
一种媒体协议流优化方法，所述媒体协议流优化方法包括：
客户端根据业务类型拼接URL信息，所述URL信息中包括序列号，在拼接完成后，携带URL信息向服务端发送启流请求；
服务端收到启流请求后，解析URL信息，若满足启流条件则向客户端返回携带媒体数据信息的成功应答，并准备媒体数据发送至客户端；否则向客户端返回失败应答；所述成功应答或失败应答中包含有所述序列号，以便客户端根据应答中携带的序列号判断是否是启流请求对应的应答；
若客户端收到服务端的成功应答，则标记启流成功，解析服务端发送的媒体数据信息，接收媒体数据，完成启流操作；若客户端收到服务端的失败应答，则标记启流失败，结束启流操作。
作为优选，所述服务端收到启流请求后，还包括：
若服务端预设需要鉴权，则服务端在收到启流请求后向客户端返回需要鉴权应答和鉴权依赖内容；
客户端在收到需要鉴权应答和鉴权依赖内容后，在所述URL信息中添加相应的鉴权信息以更新URL信息，并携带更新后的URL信息再次向服务端发送启流请求，服务端对新的启流请求进行应答；若服务端预设不需要鉴权，则直接对原启流请求进行应答。
作为优选，所述客户端申请的业务类型为实况流时，所述URL信息中的字段还包括：服务端的IP地址、服务端的端口、启流关键字、业务类型、设备通道、通道流类型以及支持媒体类型；
所述客户端申请的业务类型为回放流时，所述URL信息中的字段还包括：服务端的IP地址、服务端的端口、启流关键字、业务类型、设备通道、通道流类型、支持媒体类型、播放速度、回放开始及结束时间；
所述媒体数据信息包括以下字段：媒体类型、采样率、帧率以及对应的Payload协商值，所述服务端向客户端返回的成功应答还包括以下字段：成功关键字、流会话号；
所述服务端向客户端返回的失败应答还包括以下字段：失败关键字。
作为优选，所述媒体协议流优化方法还包括在启流成功后，进入媒体流保活操作，所述媒体流保活操作包括：
客户端定时向服务端发送携带流保活关键字和所述流会话号的保活报文，服务端接收到保活报文后进行应答，所述应答携带流会话号，客户端根据服务端返回的应答判断媒体流保活情况，判断方法如下：
客户端发送保活报文后，超时未收到服务端的应答，但仍可收到码流数据，则认为媒体流保活成功；
或，客户端发送保活报文后，收到服务端发送的保活成功应答，则认为媒体流保活成功；
或，客户端发送保活报文后，超时未收到服务端的应答，同时未收到码流数据，则认为媒体流保活失败；
或，客户端发送保活报文后，收到服务端发送的保活失败应答，则认为媒体流保活失败。
作为优选，所述媒体协议流优化方法还包括在启流成功后，进行媒体流控制操作，所述媒体流控制操作包括：
客户端向服务端发送流控报文，所述客户端向服务端发送的流控报文包括以下字段：流控关键字、流会话号、时间设置、播放速度、暂停以及单帧，服务端接收到流控报文后进行应答，所述应答携带所述流会话号，客户端根据服务端返回的应答判断媒体流控制情况，判断方法如下：
客户端发送流控报文后，超时未收到服务端的应答，但可收到码流数据，则认为媒体流控制成功；
或，客户端发送流控报文后，收到服务端发送的控制成功应答，则认为媒体流控制成功；
或，客户端发送流控报文后，超时未收到服务端的应答，同时未收到码流数据，则认为媒体流控制失败；
或，客户端发送流控报文后，收到服务端发送的控制失败应答，则认为媒体流控制失败。本发明还提出了一种媒体协议流优化系统，所述媒体协议流优化系统包括客户端和服务端，其中：
所述客户端根据业务类型拼接URL信息，所述URL信息中包括序列号，在拼接完成后，携带URL信息向服务端发送启流请求；
所述服务端收到启流请求后，解析URL信息，若满足启流条件则向客户端返回携带媒体数据信息的成功应答，并准备媒体数据发送至客户端；否则向客户端返回失败应答；所述成功应答或失败应答中包含有所述序列号，以便客户端根据应答中携带的序列号判断是否是启流请求对应的应答；
若客户端收到服务端的成功应答，则标记启流成功，解析服务端发送的媒体数据信息，接收媒体数据，完成启流操作；若客户端收到服务端的失败应答，则标记启流失败，结束启流操作。
作为优选，所述服务端收到启流请求后，还包括：
若服务端预设需要鉴权，则服务端在收到启流请求后向客户端返回需要鉴权应答和鉴权依赖内容；
客户端在收到需要鉴权应答和鉴权依赖内容后，在所述URL信息中添加相应的鉴权信息以更新URL信息，并携带更新后的URL信息再次向服务端发送启流请求，服务端对新的启流请求进行应答；若服务端预设不需要鉴权，则直接对原启流请求进行应答。
作为优选，所述客户端申请的业务类型为实况流时，所述URL信息中的字段还包括：服务端的IP地址、服务端的端口、启流关键字、业务类型、设备通道、通道流类型以及支持媒体类型；
所述客户端申请的业务类型为回放流时，所述URL信息中的字段还包括：服务端的IP地址、服务端的端口、启流关键字、业务类型、设备通道、通道流类型、支持媒体类型、播放速度、回放开始及结束时间；
所述媒体数据信息包括以下字段：媒体类型、采样率、帧率以及对应的Payload协商值，所述服务端向客户端返回的成功应答还包括以下字段：成功关键字、流会话号；
所述服务端向客户端返回的失败应答还包括以下字段：失败关键字。
作为优选，所述媒体协议流优化系统在启流成功后，还进入媒体流保活操作，其中：
所述客户端定时向服务端发送携带流保活关键字和所述流会话号的保活报文，服务端接收到保活报文后进行应答，所述应答携带流会话号，客户端根据服务端返回的应答判断媒体流保活情况，判断方法如下：
客户端发送保活报文后，超时未收到服务端的应答，但仍可收到码流数据，则认为媒体流保活成功；
或，客户端发送保活报文后，收到服务端发送的保活成功应答，则认为媒体流保活成功；
或，客户端发送保活报文后，超时未收到服务端的应答，同时未收到码流数据，则认为媒体流保活失败；
或，客户端发送保活报文后，收到服务端发送的保活失败应答，则认为媒体流保活失败。
作为优选，所述媒体协议流优化系统还在启流成功后，进行媒体流控制操作，其中：
所述客户端向服务端发送流控报文，所述客户端向服务端发送的流控报文包括以下字段：流控关键字、流会话号、时间设置、播放速度、暂停以及单帧，服务端接收到流控报文后进行应答，所述应答携带所述流会话号，客户端根据服务端返回的应答判断媒体流控制情况，判断方法如下：
客户端发送流控报文后，超时未收到服务端的应答，但可收到码流数据，则认为媒体流控制成功；
或，客户端发送流控报文后，收到服务端发送的控制成功应答，则认为媒体流控制成功；
或，客户端发送流控报文后，超时未收到服务端的应答，同时未收到码流数据，则认为媒体流控制失败；
或，客户端发送流控报文后，收到服务端发送的控制失败应答，则认为媒体流控制失败。
本发明提供的一种媒体协议流优化方法及系统，主要通过客户端自动合成而非通过和服务端的交互获取启流关键信息，从而减少了启流时所需的时间开销；优化了启流步骤，相比现有技术耗时更短；并在信令交互的同时伴随着数据信息，借用数据作为信令应答的另外一种形式，即有数据就代表信令交互成功，避免信令应答不及时或丢失带来的异常失败的现象，减少了客户端对网络稳定性以及服务端性能的依赖，增加了整个流程的稳定性。
附图说明
图1为现有技术中客户端向服务端获取URL的流程图；
图2为现有技术中RTSP启流过程的流程图；
图3为现有技术中启流完成后流保活的流程图；
图4为本发明的媒体协议流优化方法的流程框图；
图5为本发明的媒体协议流优化方法的中确定服务端是否支持启流协议的一种实施例流程图；
图6为本发明的媒体协议流优化方法中启流过程的一种实施例流程图。
具体实施方式
下面结合附图和实施例对本发明技术方案做进一步详细说明，以下实施例不构成对本发明的限定。
本实施例提供了一种媒体协议流优化方法，改善了现有媒体流交互中的缺陷，大大加快了启流速度，且增强了流保活和控制的稳定性。
如图4所示，本发明的媒体协议流优化方法，包括以下步骤：
S1、客户端根据业务类型拼接URL信息，URL信息中包括序列号，并在拼接完成后，携带URL信息向服务端发送启流请求。
在本实施例中，客户端、服务端都需要支持相同的启流协议，如图5所示，客户端在启流前，向服务端发送Server Support网络报文探测服务端是否支持客户端的启流协议。该动作存在以下三种结果：
(1)服务端返回支持应答(Support)，则表示支持该启流协议；
(2)服务端返回无效、错误应答(Error)，则表示不支持该启流协议；
(3)服务端无任何应答，不作应答到信令超时，则表示不支持该启流协议。
若服务端表示支持该启流协议时，客户端才进行下一步的操作；否则，当服务端不支持该启流协议时，则表示当前的客户端与服务端无法进行协议交互，则客户端结束启流操作。
需要说明的是，客户端确定服务端是否支持启流协议的这一操作可以在启流前的任意时间点进行，不必要留在启流环境中，例如可以在客户端进行app登录操作时进行，从而可进一步简化启流步骤，加快启流速度。更进一步地，当服务端与客户端预设为交互协议相支持时，客户端确定服务端是否支持启流协议的这一操作可以省略，以避免重复探测。
当客户端识别到服务端支持启流协议后，才进行启流，若服务端与客户端预设为交互协议相匹配时，则客户端在需要进行启流时直接进行启流。
本实施例中，当客户端申请的业务类型为实况流时，所述URL信息中的字段包括：
(1)服务端的IP地址和服务端的端口，用于建立客户端与服务端的网络连接；
(2)启流关键字，用于服务端识别客户端当前的请求类型，请求类型为启流时，关键字如“OpenStream”；
(3)业务类型，告知服务端当前客户端申请的为实况流或回放流；
(4)设备通道，告知服务端需要启动的具体通道，如第三通道；
(5)通道流类型，告知服务端需要启动的具体通道下的具体流，如第三通道，主流；
(6)支持媒体类型，告知服务端需要通道流中的媒体类型，比如仅视频或视频音频；
(7)序列号，告知服务端并在后续交互中由服务端返回，确保客户端能够匹配到发出的信令。
本实施例中，当客户端申请的业务类型为回放流时，所述URL信息中的字段包括：
(1)服务端的IP地址和服务端的端口，用于建立客户端与服务端的网关连接；
(2)启流关键字，用于服务端识别客户端当前的请求类型，请求类型为启流时，关键字如“OpenStream”；
(3)业务类型，告知服务端当前客户端请求的为实况流或回放流；
(4)设备通道，告知服务端需要启动的具体通道，如第三通道；
(5)通道流类型，告知服务端需要启动的具体通道下的具体流，如第三通道，主流；
(6)支持媒体类型，告知服务端需要通道流中的媒体类型，比如仅视频或视频音频；
(7)序列号，告知服务端并在后续交互中由服务端返回，确保客户端能够匹配到发出的信令；
(8)播放速度，告知服务端回放数据发送倍率，如1倍速或4倍速；
(9)回放开始及结束时间，告知服务端回放数据的开始节点以及结束节点。
本实施例中提供的一种URL格式如下：
URL://<IP>:<端口>/<设备通道>/<通道流类型>/<实况or回放>/<支持媒体类型>，所示的URL消息强调的是格式，而并非URL消息的内容。
S2、服务端收到启流请求后，解析URL信息，若满足启流条件则向客户端返回携带媒体数据信息的成功应答，并准备媒体数据发送至客户端；否则向客户端返回失败应答。其中成功应答或失败应答中包含有序列号，以便客户端根据应答中携带的序列号判断是否是启流请求对应的应答。
S3、若客户端收到服务端的成功应答，则标记启流成功，解析服务端发送的媒体数据信息，接收媒体数据，完成启流操作；若客户端收到服务端的失败应答，则标记启流失败，结束启流操作。
步骤2和步骤3作为本实施例的启流过程，其具体流程如图6所示：
Step1、在客户端完成URL信息的拼接后，携带URL信息向服务端发送启流请求(Open Stream request)，URL信息中携带启流关键字。
Step2、服务端接收到启流请求后，若服务端预设需要鉴权，则向客户端返回需要鉴权应答(Need authentication)和鉴权依赖内容。
Step3、客户端在收到需要鉴权应答和鉴权依赖内容后，在所述URL信息中添加相应的鉴权信息以更新URL信息，并携带更新后的URL信息再次向服务端发送启流请求(OpenStream+authentication)。
Step4、当服务器预设需要鉴权时，则对Step3中新的启流请求应答，即解析更新后的URL信息；若服务端不需要鉴权，则直接对Step1中的原启流请求进行应答，即解析原URL信息。
上述启流过程中的Step2和Step3是否执行取决于服务端预设是否需要鉴权，具体地，若服务端预设需要鉴权，则Step2和Step3执行；若服务端预设不需要鉴权，则Step2和Step3不执行。需要说明的是，服务端预设是否需要鉴权以及具体的鉴权过程不作为本发明的改进重点，在此不再进行赘述。
服务端接收到URL之后(此处不考虑鉴权情况)，解析URL得知具体如下信息：
(1)根据业务类型得知客户端请求的为实况流或回放流；
(2)根据通道流类型得知需要启动的具体流(如主流或辅流或第三流等)；
(3)如果服务端为NVR或一体机设备，还需要根据设备通道得知需要启动的具体通道；
(4)如果客户端请求的是回放流，还需要根据播放速度得知回放数据的发送倍率，以及根据回放开始及结束时间得知回放数据的开始节点以及结束节点。
当上述信息确认后，服务端需要确认自身是否满足启流条件，其确认过程如下：
(1)确认服务端是否存储有URL信息中的媒体流，例如：确认服务端是否存在需要启动的具体通道，确认服务端是否存在需要启动的具体流，确认服务端是否存在回放流的回放数据等；
(2)确认服务端是否有能力支持发流操作。
若上述的两个确认步骤中有一者或两者不满足，则向客户端返回对应的失败应答，表示不满足启流条件，失败应答中携带失败关键字，告知客户端本次服务端对启流请求的应答结果为失败，失败关键字如：OpenStreamFAIL，表示启流失败，通知客户端停止启流协议，结束启流操作。
若上述的两个确认步骤均满足，则服务端向客户端返回成功应答，表示满足启流条件，成功应答中包括以下字段：
(1)成功关键字，用于告知客户端本次服务端对启流请求的应答结果为成功，成功关键字如：OpenStreamOK；
(2)序列号，由客户端在启流请求时发送的序列号，服务端返回至客户端确保客户端能够匹配到发出的信令；
(3)流会话号，告知客户端，并在后续客户端与服务端的交互服务端中必须携带，确保服务端能找到对应流；
(4)媒体数据信息，告知客户端，媒体数据信息包括以下字段：媒体类型、视频或音频编码格式、对应识别字段、采样率、帧率以及对应的Payload协商值等媒体信息，以供客户端做好接收媒体数据的准备。
Step5、在服务端向客户端发送成功应答后，直接准备媒体数据(Media Data)，并通过原先客户端建立的网络连接向客户端发送媒体数据，客户端接收到服务端的成功应答，解析成功应答中携带的媒体数据信息，做好接收媒体数据的准备，并接收服务端发出的媒体数据，完成启流操作。
本实施例URL信息中包含序列号，服务端无论是否启流成功或者是否需要鉴权，都必须返回客户端的序列号，以便客户端根据序列号确定是否是对应的应答，从而进行本发明后续步骤的操作。
通过步骤S1～S3即完成了本实施例的媒体协议流优化方法中的启流过程，上述启流过程中客户端自动合成而非通过和服务端的交互获取启流关键信息，从而减少了启流时所需的时间开销；简化了客户端与服务端的交互过程，相比现有技术耗时更短，且在网络较为复杂的情况或穿网等情况下也不影响启流速度。
在媒体协议流交互过程中，启流完成后，对媒体流的保活操作以及对媒体流的控制操作也是必不可少的，本实施例的媒体协议流优化方法针对本实施例的启流过程对媒体流保活操作以及媒体流控制操作也作了进一步优化，以下通过两个实施例进行具体说明。
实施例1：启流成功后，进行媒体流保活操作。
在启流成功后，客户端定时(如间隔30s)向服务端发送保活报文，服务端接收到保活报文后进行应答，应答携带流会话号，以便客户端根据应答中携带的流会话号判断是否是保活报文对应的应答，客户端根据服务端返回的应答判断流保活情况，判断方法如下：
客户端发送保活报文后，超时未收到服务端的应答，但仍可收到码流数据，则认为媒体流保活成功；
或，客户端发送保活报文后，收到服务端发送的保活成功应答，则认为媒体流保活成功；
或，客户端发送保活报文后，超时未收到服务端的应答，同时未收到码流数据，则认为媒体流保活失败；
或，客户端发送保活报文后，收到服务端发送的保活失败应答，则认为媒体流保活失败。
其中，保活报文中包括以下字段
(1)流保活关键字，用于服务端识别客户端当前的请求类型，流保活关键字如“KeepStreaming”；
(2)流会话号，为服务端在启流请求成功应答中发送至客户端，并在媒体流保活操作中由客户端返回至服务端，确保服务端能找到对应流。
实施例2：启流成功后，进行媒体流控制操作。
在启流成功后，客户端向服务端发送流控报文，服务端接收到流控报文后进行应答，应答携带流会话号，以便客户端根据应答中携带的流会话号判断是否是流控报文对应的应答，客户端根据服务端返回的应答判断媒体流控制情况，媒体流控制情况判断方法如下：
客户端发送流控报文后，超时未收到服务端的应答，但可收到码流数据，则认为媒体流控制成功；
或，客户端发送流控报文后，收到服务端发送的控制成功应答，则认为媒体流控制成功；
或，客户端发送流控报文后，超时未收到服务端的应答，同时未收到码流数据，则认为媒体流控制失败；
或，客户端发送流控报文后，收到服务端发送的控制失败应答，则认为媒体流控制失败。
其中，流控报文包括以下字段：
(1)流控关键字，用于服务端识别客户端当前的请求类型，流控关键字如“ControlStream”；
(2)流会话号，为服务端在启流请求成功应答中发送至客户端，并在媒体流保活操作中由客户端返回至服务端，确保服务端能找到对应流；
(3)时间设置，如果是回放流，支持设置时间功能，客户端向服务端发送相关时间设置字段，如“Time＝xxx”，服务端收到后，停止当前顺序发流过程，寻找对应的时间节点，发送新节点数据；
(4)播放速度，如果是回放流，支持设置播放速度功能，客户端向服务端发送相关的速度设置字段，如“Speed＝xxx”，服务端收到后，按照设置的速率，发送之后的数据；
(5)暂停，如果是回放流，支持暂停功能，客户端向服务端发送相关暂停字段，如“Pause”，服务端收到后，停止当前顺序发流过程；
(6)单帧，如果是回放流，支持请求单帧功能，即客户端请求一帧数据，服务端发送一帧，客户端向服务端发送相关单帧字段如“OneFrame”，服务端收到后，继续发送一帧数据后停止当前顺序发流过程。
需要说明的是，当客户端处于正常的可以收到数据的情况时，如流控报文中提交了设置时间或播放速度等信息，则当客户端发送流控报文后，在未收到服务端的应答，但仍可继续接收到码流数据，则认为媒体流控制成功；当客户端处于正常的不会继续收到数据的情况时，如流控报文中提交了暂停信息，则只有当客户端接收到服务端的控制成功应答，才认为媒体流控制成功，反之则认为媒体流控制失败。
实施例1和实施例2中，在大部分情况下信令交互的同时伴随着数据信息，本实施例借用数据作为信令应答的另外一种形式，即有数据就代表信令交互成功，避免信令应答不及时或丢失带来的异常失败的现象，减少了客户端对网络稳定性以及服务端性能的依赖，增加了整个流程的稳定性。
与上述方法对应的，这里还给出了一种媒体协议流优化系统的实施例，所述媒体协议流优化系统包括客户端和服务端，其中：
所述客户端根据业务类型拼接URL信息，所述URL信息中包括序列号，在拼接完成后，携带URL信息向服务端发送启流请求；
所述服务端收到启流请求后，解析URL信息，若满足启流条件则向客户端返回携带媒体数据信息的成功应答，并准备媒体数据发送至客户端；否则向客户端返回失败应答；所述成功应答或失败应答中包含有所述序列号，以便客户端根据应答中携带的序列号判断是否是启流请求对应的应答；
若客户端收到服务端的成功应答，则标记启流成功，解析服务端发送的媒体数据信息，接收媒体数据，完成启流操作；若客户端收到服务端的失败应答，则标记启流失败，结束启流操作。
关于本实施例系统中客户端和服务端在启流中及启流后的具体操作，在上述方法实施例中已经进行了详细的描述，这里不再赘述。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上实施例仅用以说明本发明的技术方案而非对其进行限制，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (10)

1.一种媒体协议流优化方法，其特征在于，所述媒体协议流优化方法包括：
客户端根据业务类型拼接URL信息，所述URL信息中包括序列号，在拼接完成后，携带URL信息向服务端发送启流请求；
服务端收到启流请求后，解析URL信息，若满足启流条件则向客户端返回携带媒体数据信息的成功应答，并准备媒体数据发送至客户端；否则向客户端返回失败应答；所述成功应答或失败应答中包含有所述序列号，以便客户端根据应答中携带的序列号判断是否是启流请求对应的应答；
若客户端收到服务端的成功应答，则标记启流成功，解析服务端发送的媒体数据信息，接收媒体数据，完成启流操作；若客户端收到服务端的失败应答，则标记启流失败，结束启流操作；其中，所述媒体协议为RTSP。
2.如权利要求1所述的媒体协议流优化方法，其特征在于，所述服务端收到启流请求后，还包括：
若服务端预设需要鉴权，则服务端在收到启流请求后向客户端返回需要鉴权应答和鉴权依赖内容；
客户端在收到需要鉴权应答和鉴权依赖内容后，在所述URL信息中添加相应的鉴权信息以更新URL信息，并携带更新后的URL信息再次向服务端发送启流请求，服务端对新的启流请求进行应答；若服务端预设不需要鉴权，则直接对原启流请求进行应答。
3.如权利要求1所述的媒体协议流优化方法，其特征在于，所述客户端申请的业务类型为实况流时，所述URL信息中的字段还包括：服务端的IP地址、服务端的端口、启流关键字、业务类型、设备通道、通道流类型以及支持媒体类型；
所述客户端申请的业务类型为回放流时，所述URL信息中的字段还包括：服务端的IP地址、服务端的端口、启流关键字、业务类型、设备通道、通道流类型、支持媒体类型、播放速度、回放开始及结束时间；
所述媒体数据信息包括以下字段：媒体类型、采样率、帧率以及对应的Payload协商值，所述服务端向客户端返回的成功应答还包括以下字段：成功关键字、流会话号；
所述服务端向客户端返回的失败应答还包括以下字段：失败关键字。
4.如权利要求3所述的媒体协议流优化方法，其特征在于，所述媒体协议流优化方法还包括在启流成功后，进入媒体流保活操作，所述媒体流保活操作包括：
客户端定时向服务端发送携带流保活关键字和所述流会话号的保活报文，服务端接收到保活报文后进行应答，所述应答携带流会话号，客户端根据服务端返回的应答判断媒体流保活情况，判断方法如下：
客户端发送保活报文后，超时未收到服务端的应答，但仍可收到码流数据，则认为媒体流保活成功；
或，客户端发送保活报文后，收到服务端发送的保活成功应答，则认为媒体流保活成功；
或，客户端发送保活报文后，超时未收到服务端的应答，同时未收到码流数据，则认为媒体流保活失败；
或，客户端发送保活报文后，收到服务端发送的保活失败应答，则认为媒体流保活失败。
5.如权利要求1所述的媒体协议流优化方法，其特征在于，所述媒体协议流优化方法还包括在启流成功后，进行媒体流控制操作，所述媒体流控制操作包括：
客户端向服务端发送流控报文，所述客户端向服务端发送的流控报文包括以下字段：流控关键字、流会话号、时间设置、播放速度、暂停以及单帧，服务端接收到流控报文后进行应答，所述应答携带所述流会话号，客户端根据服务端返回的应答判断媒体流控制情况，判断方法如下：
客户端发送流控报文后，超时未收到服务端的应答，但可收到码流数据，则认为媒体流控制成功；
或，客户端发送流控报文后，收到服务端发送的控制成功应答，则认为媒体流控制成功；
或，客户端发送流控报文后，超时未收到服务端的应答，同时未收到码流数据，则认为媒体流控制失败；
或，客户端发送流控报文后，收到服务端发送的控制失败应答，则认为媒体流控制失败。
6.一种媒体协议流优化系统，其特征在于，所述媒体协议流优化系统包括客户端和服务端，其中：
所述客户端根据业务类型拼接URL信息，所述URL信息中包括序列号，在拼接完成后，携带URL信息向服务端发送启流请求；
所述服务端收到启流请求后，解析URL信息，若满足启流条件则向客户端返回携带媒体数据信息的成功应答，并准备媒体数据发送至客户端；否则向客户端返回失败应答；所述成功应答或失败应答中包含有所述序列号，以便客户端根据应答中携带的序列号判断是否是启流请求对应的应答；
若客户端收到服务端的成功应答，则标记启流成功，解析服务端发送的媒体数据信息，接收媒体数据，完成启流操作；若客户端收到服务端的失败应答，则标记启流失败，结束启流操作；其中，所述媒体协议为RTSP。
7.如权利要求6所述的媒体协议流优化系统，其特征在于，所述服务端收到启流请求后，还包括：
若服务端预设需要鉴权，则服务端在收到启流请求后向客户端返回需要鉴权应答和鉴权依赖内容；
客户端在收到需要鉴权应答和鉴权依赖内容后，在所述URL信息中添加相应的鉴权信息以更新URL信息，并携带更新后的URL信息再次向服务端发送启流请求，服务端对新的启流请求进行应答；若服务端预设不需要鉴权，则直接对原启流请求进行应答。
8.如权利要求6所述的媒体协议流优化系统，其特征在于，所述客户端申请的业务类型为实况流时，所述URL信息中的字段还包括：服务端的IP地址、服务端的端口、启流关键字、业务类型、设备通道、通道流类型以及支持媒体类型；
所述客户端申请的业务类型为回放流时，所述URL信息中的字段还包括：服务端的IP地址、服务端的端口、启流关键字、业务类型、设备通道、通道流类型、支持媒体类型、播放速度、回放开始及结束时间；
所述媒体数据信息包括以下字段：媒体类型、采样率、帧率以及对应的Payload协商值，所述服务端向客户端返回的成功应答还包括以下字段：成功关键字、流会话号；
所述服务端向客户端返回的失败应答还包括以下字段：失败关键字。
9.如权利要求8所述的媒体协议流优化系统，其特征在于，所述媒体协议流优化系统在启流成功后，还进入媒体流保活操作，其中：
所述客户端定时向服务端发送携带流保活关键字和所述流会话号的保活报文，服务端接收到保活报文后进行应答，所述应答携带流会话号，客户端根据服务端返回的应答判断媒体流保活情况，判断方法如下：
客户端发送保活报文后，超时未收到服务端的应答，但仍可收到码流数据，则认为媒体流保活成功；
或，客户端发送保活报文后，收到服务端发送的保活成功应答，则认为媒体流保活成功；
或，客户端发送保活报文后，超时未收到服务端的应答，同时未收到码流数据，则认为媒体流保活失败；
或，客户端发送保活报文后，收到服务端发送的保活失败应答，则认为媒体流保活失败。
10.如权利要求6所述的媒体协议流优化系统，其特征在于，所述媒体协议流优化系统还在启流成功后，进行媒体流控制操作，其中：
所述客户端向服务端发送流控报文，所述客户端向服务端发送的流控报文包括以下字段：流控关键字、流会话号、时间设置、播放速度、暂停以及单帧，服务端接收到流控报文后进行应答，所述应答携带所述流会话号，客户端根据服务端返回的应答判断媒体流控制情况，判断方法如下：
客户端发送流控报文后，超时未收到服务端的应答，但可收到码流数据，则认为媒体流控制成功；
或，客户端发送流控报文后，收到服务端发送的控制成功应答，则认为媒体流控制成功；
或，客户端发送流控报文后，超时未收到服务端的应答，同时未收到码流数据，则认为媒体流控制失败；
或，客户端发送流控报文后，收到服务端发送的控制失败应答，则认为媒体流控制失败。
CN201811269677.XA 2018-10-29 2018-10-29 一种媒体协议流优化方法及系统 Active CN111107445B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811269677.XA CN111107445B (zh) 2018-10-29 2018-10-29 一种媒体协议流优化方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811269677.XA CN111107445B (zh) 2018-10-29 2018-10-29 一种媒体协议流优化方法及系统

Publications (2)

Publication Number Publication Date
CN111107445A CN111107445A (zh) 2020-05-05
CN111107445B true CN111107445B (zh) 2023-04-18

Family

ID=70420246

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811269677.XA Active CN111107445B (zh) 2018-10-29 2018-10-29 一种媒体协议流优化方法及系统

Country Status (1)

Country Link
CN (1) CN111107445B (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111683272A (zh) * 2020-05-22 2020-09-18 海信视像科技股份有限公司 一种流媒体播放方法及显示设备
CN114189504B (zh) * 2020-08-24 2024-03-08 浙江宇视科技有限公司 一种启流url获取方法、装置、电子设备和存储介质
CN115484468B (zh) * 2021-06-15 2024-01-09 北京字节跳动网络技术有限公司 一种连麦系统、方法、装置、设备及存储介质
CN115767192A (zh) * 2022-11-17 2023-03-07 浙江省公众信息产业有限公司 基于ssrc管理调度多路视频流的方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101188601A (zh) * 2006-11-15 2008-05-28 中兴通讯股份有限公司 一种多媒体数据快速发送和接收的方法
CN101378537A (zh) * 2007-08-30 2009-03-04 中兴通讯股份有限公司 一种移动流媒体业务播放时缩短启动时间的方法
CN101442537A (zh) * 2008-11-11 2009-05-27 北京星谷科技有限公司 一种基于rtsp协议的网络流媒体直播的方法及系统
CN101662839A (zh) * 2009-09-09 2010-03-03 深圳市融创天下科技发展有限公司 一种提高无线流媒体系统连接速度的方法
CN101674228A (zh) * 2008-09-08 2010-03-17 华为技术有限公司 实现流媒体通信的方法、装置及系统
CN104618690A (zh) * 2015-01-29 2015-05-13 广东迅通科技股份有限公司 一种高清视频实时点播和历史回放的方法及系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101197832B (zh) * 2007-12-13 2012-01-25 华为技术有限公司 一种实现iptv业务的方法、系统、装置
CN101505239A (zh) * 2008-02-04 2009-08-12 华为技术有限公司 文本电话发送、接收处理装置、通信方法及通信系统
US20130262691A1 (en) * 2012-03-28 2013-10-03 Rovi Corp System and Methods of Media Streaming using RTSP with Reduced Delays
CN103647652B (zh) * 2013-12-20 2017-06-09 北京奇虎科技有限公司 一种实现数据传输的方法、装置和服务器
KR102540459B1 (ko) * 2016-12-22 2023-06-05 한화비전 주식회사 Rtp/rtsp 표준을 따르는 서버와 클라이언트에서 실시간 영상 스트리밍 방법
CN106850595A (zh) * 2017-01-17 2017-06-13 烽火通信科技股份有限公司 一种流媒体传输优化方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101188601A (zh) * 2006-11-15 2008-05-28 中兴通讯股份有限公司 一种多媒体数据快速发送和接收的方法
CN101378537A (zh) * 2007-08-30 2009-03-04 中兴通讯股份有限公司 一种移动流媒体业务播放时缩短启动时间的方法
CN101674228A (zh) * 2008-09-08 2010-03-17 华为技术有限公司 实现流媒体通信的方法、装置及系统
CN101442537A (zh) * 2008-11-11 2009-05-27 北京星谷科技有限公司 一种基于rtsp协议的网络流媒体直播的方法及系统
CN101662839A (zh) * 2009-09-09 2010-03-03 深圳市融创天下科技发展有限公司 一种提高无线流媒体系统连接速度的方法
CN104618690A (zh) * 2015-01-29 2015-05-13 广东迅通科技股份有限公司 一种高清视频实时点播和历史回放的方法及系统

Also Published As

Publication number Publication date
CN111107445A (zh) 2020-05-05

Similar Documents

Publication Publication Date Title
CN111107445B (zh) 一种媒体协议流优化方法及系统
KR100759954B1 (ko) 멀티미디어 스트리밍에서 클라이언트 레이트 능력을시그널링하는 방법
EP2497267B1 (en) Streaming with optional broadcast delivery of data segments
EP2636201B1 (en) Methods and devices for media description delivery
RU2552176C2 (ru) Управление сеансом связи для передачи медиапотока
US8566395B2 (en) Method and apparatus for transmitting hypertext transfer protocol media
US11019367B2 (en) Live video transmission method and system, and apparatus
US9673996B1 (en) Redirection of a streaming media session in an anticipated failover scenario
RU2647654C2 (ru) Система и способ доставки аудиовизуального контента в клиентское устройство
JP3922575B2 (ja) ＳＩＰセッション制御によるＣＤＮにおけるＱｏＳ保証方法とＱｏＳ保証システムおよび端末装置とコンテンツ配信サブシステムとＳＩＰセッション制御サブシステムならびにプログラム
JP2008530835A (ja) パケット交換ネットワーク上のオンデマンドマルチチャネルストリーミングセッション
US8990407B2 (en) Fast setup response prediction
KR20090039682A (ko) 미디어 채널 관리
WO2008101444A1 (fr) Système multimédia en flux, dispositif de transmission de signalisation et procédé d&#39;envoi de multimédia en flux
EP2314048A1 (en) Fast content switching in a communication system
CN113287283A (zh) 用于视听直播内容递送的方法和系统
US12113842B2 (en) Content delivery
WO2008098500A1 (fr) Procédé et appareil pour découvrir un service de flux de données multimédia et appareil pour découvrir un service
WO2009015539A1 (fr) Procédé de commande multidiffusion pour service de demande de contenu multimédia et son système
US20120011266A1 (en) Method and apparatus for providing a real time streaming protocol session
US9451003B1 (en) Method and system for advanced notification of availability of fast content switching
CN101179502A (zh) 一种流媒体数据的转发系统和转发方法
KR101528268B1 (ko) 콘텐츠를 원격 위치들에 스트리밍하기 위한 시스템과 방법

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
GR01 Patent grant
GR01 Patent grant