CN114501049B - 直播连接的建立方法、装置及系统 - Google Patents

直播连接的建立方法、装置及系统 Download PDF

Info

Publication number
CN114501049B
CN114501049B CN202210055165.3A CN202210055165A CN114501049B CN 114501049 B CN114501049 B CN 114501049B CN 202210055165 A CN202210055165 A CN 202210055165A CN 114501049 B CN114501049 B CN 114501049B
Authority
CN
China
Prior art keywords
connection establishment
live
live broadcast
client
message
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
CN202210055165.3A
Other languages
English (en)
Other versions
CN114501049A (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.)
Shanghai Bilibili Technology Co Ltd
Original Assignee
Shanghai Bilibili 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 Shanghai Bilibili Technology Co Ltd filed Critical Shanghai Bilibili Technology Co Ltd
Priority to CN202210055165.3A priority Critical patent/CN114501049B/zh
Publication of CN114501049A publication Critical patent/CN114501049A/zh
Application granted granted Critical
Publication of CN114501049B publication Critical patent/CN114501049B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • 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/60—Network 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/63—Control 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/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请公开了一种直播连接的建立方法、装置及系统，该方法应用于服务端，该方法包括：获取握手请求消息，其中，握手请求消息用于客户端请求与服务端建立直播连接，握手请求消息包括消息解析参数和序列化结构数据；根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数；根据直播建连参数建立与客户端之间的直播连接，并向客户端返回连接建立确认消息。本申请根据一次握手交互中包括消息解析参数和序列化结构数据的握手请求消息就能够实现直播连接的建立，有效缩短了直播连接的建立所需时间，从而加快了直播首开速度，提升了用户的直播体验。

Description

直播连接的建立方法、装置及系统
技术领域
本申请涉及互联网技术领域，具体涉及一种直播连接的建立方法、装置及系统。
背景技术
随着互联网技术的发展，用户越来越多地使用网络平台来观看直播视频或者发布直播视频。观看直播视频的用户称为订阅者，发布直播视频的用户称为主播，无论是订阅者还是主播，在观看直播或发布直播时，都需要利用客户端与服务端之间建立直播连接，然而，目前现有技术中直播建立主要经历如下阶段：握手阶段(Handshake阶段)、连接阶段(Connect阶段)、Publish/Play阶段(发布阶段/订阅阶段)，进而导致直播连接的建立所需时间较长，直播首开较慢，影响用户直播体验。
发明内容
本申请的目的是提供一种直播连接的建立方法、装置及系统，以解决现有技术存在的直播连接的建立所需时间较长，直播首开较慢，影响用户直播体验等问题。
根据本申请实施例的一个方面，提供了一种直播连接的建立方法，该方法应用于服务端，包括：
获取握手请求消息，其中，握手请求消息用于客户端请求与服务端建立直播连接，握手请求消息包括消息解析参数和序列化结构数据；
根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数；
根据直播建连参数建立与客户端之间的直播连接，并向客户端返回连接建立确认消息。
进一步地，握手请求消息中以预设数据结构写入有消息解析参数和序列化结构数据。
进一步地，消息解析参数包含：数据序列化格式解析参数、数据长度。
进一步地，根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数进一步包括：
若消息解析参数包含Protobuf格式解析参数，则根据Protobuf格式的解码规则对预设数据长度的序列化结构数据进行解码，得到用于直播连接建立的直播建连参数。
进一步地，根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数进一步包括：
若消息解析参数包含Json格式解析参数，则根据预设参数关键字，从预设数据长度的序列化结构数据中提取用于直播连接建立的直播建连参数。
进一步地，向客户端返回连接建立确认消息进一步包括：
若客户端为订阅端，则向订阅端返回携带有直播数据分块大小的连接建立确认消息。
进一步地，若客户端为发布端，序列化结构数据包括：应用标识、流标识、推流传输方法、直播数据分块大小、窗口大小。
进一步地，若客户端为订阅端，序列化结构数据包括：应用标识、流标识、拉流传输方法、窗口大小。
进一步地，握手请求消息具体为基于RTMP协议的握手请求消息。
根据本申请实施例的另一方面，提供了一种直播连接的建立方法，该方法应用于客户端，包括：
向服务端发送握手请求消息，以供服务端根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数，根据直播建连参数建立与客户端之间的直播连接，并向客户端返回连接建立确认消息，其中，握手请求消息用于客户端请求与服务端建立直播连接，握手请求消息包括消息解析参数和序列化结构数据；
接收服务端返回的连接建立确认消息，以根据连接建立确认消息向服务端发送数据。
进一步地，客户端包括订阅端或发布端。
进一步地，接收服务端返回的连接建立确认消息进一步包括：
若客户端为订阅端，则接收服务端返回的携带有直播数据分块大小的连接建立确认消息。
进一步地，握手请求消息中以预设数据结构写入有消息解析参数和序列化结构数据。
进一步地，消息解析参数包含：数据序列化格式解析参数、数据长度。
进一步地，数据序列化格式解析参数包括Protobuf格式解析参数或Json格式解析参数。
进一步地，在向服务端发送握手请求消息之前，方法还包括：若消息解析参数包含Protobuf格式解析参数，则根据Protobuf格式的编码规则对直播建连参数进行编码，得到预设数据长度的序列化结构数据。
进一步地，若客户端为发布端，序列化结构数据包括：应用标识、流标识、推流传输方法、直播数据分块大小、窗口大小。
进一步地，若客户端为订阅端，序列化结构数据包括：应用标识、流标识、拉流传输方法、窗口大小。
根据本申请实施例的另一方面，提供了一种直播连接的建立装置，该装置应用于服务端，包括：
获取模块，适于获取握手请求消息，其中，握手请求消息用于客户端请求与服务端建立直播连接，握手请求消息包括消息解析参数和序列化结构数据；
解析模块，适于根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数；
建立模块，适于根据直播建连参数建立与客户端之间的直播连接；
发送模块，适于向客户端返回连接建立确认消息。
根据本申请实施例的另一方面，提供了一种直播连接的建立装置，该装置应用于客户端，包括：
发送模块，适于向服务端发送握手请求消息，以供服务端根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数，根据直播建连参数建立与客户端之间的直播连接，并向客户端返回连接建立确认消息，其中，握手请求消息用于客户端请求与服务端建立直播连接，握手请求消息包括消息解析参数和序列化结构数据；
接收模块，适于接收服务端返回的连接建立确认消息，以根据连接建立确认消息向服务端发送数据。
根据本申请实施例的另一方面，提供了一种直播连接的建立系统，包括：上述直播连接的建立装置。
根据本申请实施例的又一方面，提供了一种计算设备，包括：处理器、存储器、通信接口和通信总线，处理器、存储器和通信接口通过通信总线完成相互间的通信；
存储器用于存放至少一可执行指令，可执行指令使处理器执行上述直播连接的建立方法对应的操作。
根据本申请实施例的再一方面，提供了一种计算机存储介质，存储介质中存储有至少一可执行指令，可执行指令使处理器执行如上述直播连接的建立方法对应的操作。
根据本申请实施例提供的方案，根据一次握手交互中包括消息解析参数和序列化结构数据的握手请求消息就能够实现直播连接的建立，有效缩短了直播连接的建立所需时间，从而加快了直播首开速度，提升了用户的直播体验。
上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1示出了现有技术中直播连接的建立方法的时序图；
图2示出了根据本申请实施例直播连接的建立方法的时序图；
图3示出了根据本申请一个实施例的直播连接的建立方法的流程示意图；
图4示出了根据本申请另一个实施例的直播连接的建立方法的流程示意图；
图5示出了根据本申请一个实施例的直播连接的建立方法的流程示意图；
图6示出了根据本申请另一个实施例的直播连接的建立方法的流程示意图；
图7示出了根据本申请一个实施例的直播连接的建立装置的结构示意图；
图8示出了根据本申请一个实施例的直播连接的建立装置的结构示意图；
图9示出了根据本申请一个实施例的计算设备的结构示意图。
具体实施方式
下面将参照附图更详细地描述本申请的示例性实施例。虽然附图中显示了本申请的示例性实施例，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。
图1示出了现有技术中直播连接的建立方法的时序图。如图1所示，现有技术在进行直播连接的建立时，主要分为三个阶段，握手阶段(Handshake阶段)、连接阶段(Connect阶段)、Publish/Play阶段(发布阶段/订阅阶段)，其中，在Handshake阶段，主要经历类似TCP的三次握手，负载数据是版本号+时间戳+随机数据，这部分需要耗时1.5RTT，其中，RTT(round trip time),是指网络端到端的往返时间；
在Connect阶段，主要是开始要创建会话和流，具体对应图中的连接及创建流，主要是告知需要创建的应用信息和流信息，这部分需要耗时2个RTT；
在Publish/Play阶段，这部分会区分具体的行为，例如，发布或订阅，同时会告知一些参数信息，比如直播数据分块大小、是否包含音视频等，这部分需要耗时1.5个RTT；
由此可以确定，直播连接的建立时需要交互的信息有版本号、时间戳、应用信息、流信息、发布/订阅，而整体交互需要耗时5RTT，直播连接的建立耗时较长，从而导致直播首开较慢。
为了能够有效减少直播连接的建立所需时间，加快直播首开时间，减少延迟，发明人通过付出创造性劳动提出了一种直播连接的建立方案。
图2示出了根据本申请实施例直播连接的建立方法的时序图。如图2所示，本申请实施例是通过一次握手来实现直播连接的建立。
具体地，发布端或订阅端通过向服务端发送以包括消息解析参数和序列化结构数据的握手请求消息，服务端通过解析得到直播建连参数，并根据直播建连参数来建立直播连接，在完成直播连接的建立后，向发布端或订阅端返回连接建立确认消息，以通知发布端或订阅端直播连接已建立。
图3示出了根据本申请一个实施例的直播连接的建立方法的流程示意图。该方法应用于服务端，如图3所示，该方法包括以下步骤：
步骤S301，获取握手请求消息，其中，握手请求消息用于客户端请求与服务端建立直播连接，握手请求消息包括消息解析参数和序列化结构数据。
本实施例提供的直播连接的建立方法的执行主体为服务端，具体地，客户端可以通过握手交互的方式与服务端来建立直播连接，例如，客户端向服务端发送握手请求消息，服务端获取客户端发送的握手请求消息，其中，该握手请求消息用于客户端请求与服务端建立直播连接，该握手请求消息包括消息解析参数和序列化结构数据。消息解析参数定义了解析序列化结构数据对应的参数，序列化结构数据是经过序列化处理的数据。
其中，客户端可以为位于终端的应用，可以理解的是，应用可以是安装在终端上的本地程序(nativeApp)，或者还可以是终端上的浏览器的一个网页程序(webApp)，本实施例对此不进行特别限定。终端可以包括但不限于手机、平板电脑、个人电脑(PersonalComputer，PC)等。
在本申请实施例中，服务端具体为服务器，其中，服务器可以是单独的服务器，也可以是服务器集群，可以是本地服务器，也可以是云端服务器，具体的服务器类型在本申请实施例中可以不作为限定。
步骤S302，根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数。
在获取到握手请求消息后，可以根据握手请求消息中的消息解析参数来对序列化结构数据进行解析，通过解析能够得到用于直播连接建立的直播建连参数，其中，直播建连参数是建立直播连接时所需要的参数。
步骤S303，根据直播建连参数建立与客户端之间的直播连接，并向客户端返回连接建立确认消息。
在根据步骤S302得到直播建连参数之后，可以根据该直播建连参数来建立与客户端之间的直播连接，在完成直播连接的建立后，向客户端返回连接建立确认消息，该连接建立确认消息用于通知客户端直播连接已建立，从而使得客户端通过连接建立确认消息能够及时获知其与服务端之间的直播连接已建立，其可以开始向服务端发送数据，这里的数据可以是元信息、视频数据、音频数据，避免客户端在未建立直播连接的情况下过早发送数据而影响直播连接的建立。
本申请实施例提供的方法，根据一次握手交互中包括消息解析参数和序列化结构数据的握手请求消息就能够实现直播连接的建立，有效缩短了直播连接的建立所需时间，从而加快了直播首开速度，提升了用户的直播体验。
图4示出了根据本申请另一个实施例的直播连接的建立方法的流程示意图。该方法应用于服务端，如图4所示，该方法包括以下步骤：
步骤S401，获取握手请求消息，其中，握手请求消息用于客户端请求与服务端建立直播连接，握手请求消息中以预设数据结构写入有消息解析参数和序列化结构数据。
具体地，客户端可以通过握手交互的方式与服务端来建立直播连接，例如，客户端向服务端发送握手请求消息，服务端获取客户端发送的握手请求消息，其中，该握手请求消息中以预设数据结构写入有消息解析参数和序列化结构数据。预设数据结构预先定义了握手请求消息中写入的消息解析参数和序列化结构数据所对应的数据结构，消息解析参数定义了解析序列化结构数据对应的参数，例如，消息解析参数包含：数据序列化格式解析参数、数据长度，序列化结构数据是经过序列化处理的数据。
预设数据结构具体为数据序列化格式解析参数：数据长度：序列化结构数据，例如，可以表示为：type(数据序列化格式解析参数):len(数据长度):value(序列化结构数据)，其中，数据序列化格式解析参数根据数据序列化方式不同，包含Protobuf格式解析参数、Json格式解析参数，JSON是一种轻量级的数据交换格式。Protobuf(GoogleProtocolBuffer)是由google公司用于数据交换的序列结构化数据格式。数据长度定义了序列化结构数据的长度，便于服务端确定对哪部分序列化结构数据进行解析。
其中，握手请求消息具体为基于RTMP协议的握手请求消息。RTMP协议(Real TimeMedia Protocol协议)是一种流媒体协议，是广泛用在互联网直播场景的一种实时音视频传输协议，能够方便传输FLV格式的视频内容。
步骤S402，若消息解析参数包含Protobuf格式解析参数，则根据Protobuf格式的解码规则对预设数据长度的序列化结构数据进行解码，得到用于直播连接建立的直播建连参数。
Protobuf格式是一种编码压缩格式，其压缩比例高，相同内容字符长度的数据经过Protobuf格式编码处理后会小很多，同时编码后不是明文，相对安全一些，因此，若消息解析参数包含Protobuf格式解析参数，则可以根据Protobuf格式的解码规则对预设数据长度的序列化结构数据进行解码，通过解码可以得到用于直播连接建立的直播建连参数。例如，针对Protobuf格式，预先设定了包含解码规则和编码规则的Proto文件，在确定了消息解析参数包含Protobuf格式解析参数，可以根据Proto文件中记录解码规则预设数据长度的序列化结构数据进行解码，得到用于直播连接建立的直播建连参数。
下面示意性列举了Protobuf格式的序列化结构数据：
上述序列化结构数据并无法直接获得app、stream、method、parameter(chunk_size、window_acknowledge_size)，因此，需要根据Protobuf格式的解码规则对上述序列化结构数据进行解码，通过解码得到app、stream、method、parameter(chunk_size、window_acknowledge_size)对应的具体信息。
步骤S403，若消息解析参数包含Json格式解析参数，则根据预设参数关键字，从预设数据长度的序列化结构数据中提取用于直播连接建立的直播建连参数。
Json格式具有简单、可读性强等特点，因此，若消息解析参数包含Json格式解析参数，则根据预设参数关键字，从预设数据长度的序列化结构数据中提取用于直播连接建立的直播建连参数。其中，预设参数关键字是直播建连参数的参数表示，例如，预设参数关键字为app、stream、method、parameter(chunk_size、window_acknowledge_size)等。
下面示意性列举了Json格式的序列化结构数据：{"app":"bilibili","stream":"live_0001","method":"publish","parameter":{"chunk_size":1280,"window_acknowledge_size":32000}}
例如，预设参数关键字可以是app、stream、method、parameter(chunk_size、window_acknowledge_size)，通过上述预设参数关键字能够提取到直播建连参数，比如，提取到的直播建连参数具体为：app:bilibili、stream:live_0001、method:publish、parameter:chunk_size:1280、window_acknowledge_size:32000。
步骤S402或步骤S403是通过对一次握手交互的握手请求消息中的序列化结构数据进行解析，一次性得到直播连接所需的直播建连参数，无需进行多次交互，从而缩短了直播连接的建立所需时间，提升了直播连接的连接效率。
步骤S404，根据直播建连参数建立与客户端之间的直播连接，并向客户端返回连接建立确认消息。
在根据步骤S402或步骤S403得到直播建连参数之后，可以根据该直播建连参数来建立与客户端之间的直播连接，在完成直播连接的建立后，向客户端返回连接建立确认消息，该连接建立确认消息用于通知客户端直播连接已建立，从而使得客户端通过连接建立确认消息能够及时获知其与服务端之间的直播连接已建立，其可以开始向服务端发送数据，这里的数据可以是元信息、视频数据、音频数据，避免客户端在未建立直播连接的情况下过早发送数据而影响直播连接的建立。
本实施例中的客户端可以是发布端或订阅端，其中，发布端是发布直播的客户端，订阅端是订阅直播的客户端，针对于不同的客户端，序列化结构数据不同，若客户端为发布端，序列化结构数据包括：应用标识、流标识、推流传输方法、直播数据分块大小、窗口大小；若客户端为订阅端，序列化结构数据包括：应用标识、流标识、拉流传输方法、窗口大小。其中，应用标识用于唯一标识某个应用，用于确定建立直播连接的应用具体是什么，流标识用于标识具体的某条流，其中，同一应用下流标识是唯一的，即，同一应用下各个流的流标识均不相同，不同应用下的流标识可以重复，而应用标识与流标识组合能够唯一标识某个流。
直播数据分块大小定义了传输的直播数据的大小，推流传输方法是指发布端将直播数据传输到服务端的过程；拉流传输方法指订阅端从服务端拉取直播数据的过程。
优选地，若客户端为订阅端，向客户端返回连接建立确认消息进一步包括：向订阅端返回携带有直播数据分块大小的连接建立确认消息，通过在连接建立确认消息中携带直播数据分块大小，能够使得订阅端准确获知发布端传输的直播数据的大小，避免订阅端拉取的直播数据与发布端发布的直播数据不对应。
若解析得到的直播建连参数为应用标识、流标识、推流传输方法、直播数据分块大小、窗口大小，服务端通过直播建连参数中的推流传输方法可以识别确定是发布端要建立直播连接，通过直播建连参数中的应用标识和流标识来确定具体是哪个发布端来请求直播连接，通过直播数据分块大小能够确定该发布端后续推送的直播数据的大小，窗口大小限定了当发布端尚未收到服务端返回的ACK消息时所允许发送的最大字节数，通过上述直播建连参数实现与发布端之间的直播连接。
举例说明，直播建连参数具体为：app:bilibili、stream:live_0001、method:publish、parameter:chunk_size:1280、window_acknowledge_size:32000，服务端通过method:publish可以确定是发布端来进行推流，通过app:bilibili、stream:live_0001可以确定是bilibili、live_0001对应的主播来请求建连直播连接，通过chunk_size:1280可以确定发布端后续发送的直播数据的大小为1280，通过window_acknowledge_size:32000可以确定发布端尚未收到服务端返回的ACK消息时所允许发送的最大字节数为32000。
若解析得到的直播建连参数为应用标识、流标识、拉流传输方法、窗口大小，服务端通过直播建连参数中的拉流传输方法可以识别确定是订阅端要建立直播连接，通过直播建连参数中的应用标识和流标识来确定具体是订阅端订阅的是哪个发布端，窗口大小限定了当服务端尚未收到订阅端返回的ACK消息时所允许发送的最大字节数，通过上述直播建连参数实现与订阅端之间的直播连接。
举例说明，直播建连参数具体为：app:bilibili、stream:live_0001、method:publish、parameter:window_acknowledge_size:32000，服务端通过method:publish可以确定是订阅端来进行拉流，通过app:bilibili、stream:live_0001可以确定是订阅者订阅的是bilibili、live_0001，通过window_acknowledge_size:32000可以确定服务端尚未收到订阅端返回的ACK消息时所允许发送的最大字节数为32000。
可选地，本实施例可以将以预设数据结构写入有消息解析参数和序列化结构数据的握手请求消息放在C0中与服务端进行交互。
本申请实施例提供的方法，根据一次握手交互中以预设数据结构写入有消息解析参数和序列化结构数据的握手请求消息就能够实现直播连接的建立，本次直播连接的建立需要1个RTT即可完成，相较于现有技术需要5个RTT才能够建立连接，有效缩短了直播连接的建立所需时间，从而加快了直播首开速度，提升了用户的直播体验，针对不同消息解析参数进行不同的处理，Protobuf格式具有压缩比例高，相同内容字符长度的数据经过Protobuf格式编码处理后会小很多，同时编码后不是明文，相对安全一些，而Json格式具有简单、可读性强等特点。
图5示出了根据本申请一个实施例的直播连接的建立方法的流程示意图。该方法应用于客户端，如图5所示，该方法包括以下步骤：
步骤S501，向服务端发送握手请求消息，以供服务端根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数，根据直播建连参数建立与客户端之间的直播连接，并向客户端返回连接建立确认消息，其中，握手请求消息用于客户端请求与服务端建立直播连接，握手请求消息包括消息解析参数和序列化结构数据。
本实施例提供的直播连接的建立方法的执行主体为客户端，具体地，客户端通过握手交互的方式与服务端来建立直播连接，例如，客户端向服务端发送握手请求消息，服务端获取客户端发送的握手请求消息，根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数，根据直播建连参数建立与客户端之间的直播连接，并向客户端返回连接建立确认消息，其中，握手请求消息用于客户端请求与服务端建立直播连接，握手请求消息包括消息解析参数和序列化结构数据。其中，服务端具体地处理流程可以参见图3或图4所示实施例，这里不再详细赘述。
其中，客户端可以为位于终端的应用，可以理解的是，应用可以是安装在终端上的本地程序(nativeApp)，或者还可以是终端上的浏览器的一个网页程序(webApp)，本实施例对此不进行特别限定。终端可以包括但不限于手机、平板电脑、个人电脑(PersonalComputer，PC)等。
步骤S502，接收服务端返回的连接建立确认消息，以根据连接建立确认消息向服务端发送数据。
在完成直播连接的建立后，服务端向客户端返回连接建立确认消息，客户端接收服务端返回的连接建立确认消息，客户端通过该连接建立确认消息可以及时确定客户端与服务端之间的直播连接已建立，其可以开始向服务端发送数据，这里的数据可以是元信息、视频数据、音频数据，避免客户端在未建立直播连接的情况下过早发送数据而影响直播连接的建立。
本申请实施例提供的方法，根据一次握手交互中包括消息解析参数和序列化结构数据的握手请求消息就能够实现直播连接的建立，有效缩短了直播连接的建立所需时间，从而加快了直播首开速度，提升了用户的直播体验。
图6示出了根据本申请另一个实施例的直播连接的建立方法的流程示意图。该方法应用于客户端，如图6所示，该方法包括以下步骤：
步骤S601，若消息解析参数包含Protobuf格式解析参数，则根据Protobuf格式的编码规则对直播建连参数进行编码，得到预设数据长度的序列化结构数据。
Protobuf(Google ProtocolBuffer)是由google公司用于数据交换的序列结构化数据格式。Protobuf格式是一种编码压缩格式，其压缩比例高，相同内容字符长度的数据经过Protobuf格式编码处理后会小很多，同时编码后不是明文，相对安全一些，针对Protobuf格式，预先设定了包含解码规则和编码规则的Proto文件，在确定了消息解析参数包含Protobuf格式解析参数，可以根据Proto文件中记录编码规则对直播建连参数进行编码，得到预设数据长度的序列化结构数据。
直播建连参数是建立直播连接时所需要的参数，本实施例中的客户端包括订阅端或发布端，例如，若客户端为发布端，直播建连参数包括：应用标识、流标识、推流传输方法、直播数据分块大小、窗口大小。若客户端为订阅端，直播建连参数包括：应用标识、流标识、拉流传输方法、窗口大小。
步骤S602，向服务端发送握手请求消息，以供服务端根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数，根据直播建连参数建立与客户端之间的直播连接，并向客户端返回连接建立确认消息，其中，握手请求消息用于客户端请求与服务端建立直播连接，握手请求消息中以预设数据结构写入有消息解析参数和序列化结构数据。
其中，消息解析参数包含：数据序列化格式解析参数、数据长度。数据序列化格式解析参数包括Protobuf格式解析参数或Json格式解析参数。
若客户端为发布端，序列化结构数据包括：应用标识、流标识、推流传输方法、直播数据分块大小、窗口大小。若客户端为订阅端，序列化结构数据包括：应用标识、流标识、拉流传输方法、窗口大小。
步骤S603，接收服务端返回的连接建立确认消息，以根据连接建立确认消息向服务端发送数据。
步骤S602-步骤S603具体实现方式与图5中的步骤S501-步骤S502类似，这里不再赘述。
优选地，若客户端为订阅端，接收服务端返回的连接建立确认消息进一步包括：接收服务端返回的携带有直播数据分块大小的连接建立确认消息，通过在连接建立确认消息中携带直播数据分块大小，能够使得订阅端准确获知发布端传输的直播数据的大小，避免订阅端拉取的直播数据与发布端发布的直播数据不对应。
本申请实施例提供的方法，根据一次握手交互中以预设数据结构写入有消息解析参数和序列化结构数据的握手请求消息就能够实现直播连接的建立，本次直播连接的建立需要1个RTT即可完成，相较于现有技术需要5个RTT才能够建立连接，有效缩短了直播连接的建立所需时间，从而加快了直播首开速度，提升了用户的直播体验，针对不同消息解析参数进行不同的处理，Protobuf格式具有压缩比例高，相同内容字符长度的数据经过Protobuf格式编码处理后会小很多，同时编码后不是明文，相对安全一些。
图7示出了根据本申请一个实施例的直播连接的建立装置的结构示意图。该装置应用于服务端，如图7所示，该装置包括：获取模块701、解析模块702、建立模块703、发送模块704。
获取模块701，适于获取握手请求消息，其中，握手请求消息用于客户端请求与服务端建立直播连接，握手请求消息包括消息解析参数和序列化结构数据；
解析模块702，适于根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数；
建立模块703，适于根据直播建连参数建立与客户端之间的直播连接；
发送模块704，适于向客户端返回连接建立确认消息。
可选地，握手请求消息中以预设数据结构写入有消息解析参数和序列化结构数据。
可选地，消息解析参数包含：数据序列化格式解析参数、数据长度。
可选地，解析模块进一步适于：若消息解析参数包含Protobuf格式解析参数，则根据Protobuf格式的解码规则对预设数据长度的序列化结构数据进行解码，得到用于直播连接建立的直播建连参数。
可选地，解析模块进一步适于：若消息解析参数包含Json格式解析参数，则根据预设参数关键字，从预设数据长度的序列化结构数据中提取用于直播连接建立的直播建连参数。
可选地，发送模块进一步适于：若客户端为订阅端，则向订阅端返回携带有直播数据分块大小的连接建立确认消息。
可选地，若客户端为发布端，序列化结构数据包括：应用标识、流标识、推流传输方法、直播数据分块大小、窗口大小。
可选地，若客户端为订阅端，序列化结构数据包括：应用标识、流标识、拉流传输方法、窗口大小。
可选地，握手请求消息具体为基于RTMP协议的握手请求消息。
本申请实施例提供的装置，根据一次握手交互中包括消息解析参数和序列化结构数据的握手请求消息就能够实现直播连接的建立，有效缩短了直播连接的建立所需时间，从而加快了直播首开速度，提升了用户的直播体验。
图8示出了根据本申请一个实施例的直播连接的建立装置的结构示意图。该装置应用于客户端，如图8所示，该装置包括：发送模块801、接收模块802。
发送模块801，适于向服务端发送握手请求消息，以供服务端根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数，根据直播建连参数建立与客户端之间的直播连接，并向客户端返回连接建立确认消息，其中，握手请求消息用于客户端请求与服务端建立直播连接，握手请求消息包括消息解析参数和序列化结构数据；
接收模块802，适于接收服务端返回的连接建立确认消息，以根据连接建立确认消息向服务端发送数据。
可选地，客户端包括订阅端或发布端。
可选地，接收模块进一步适于：若客户端为订阅端，则接收服务端返回的携带有直播数据分块大小的连接建立确认消息。
可选地，握手请求消息中以预设数据结构写入有消息解析参数和序列化结构数据。
可选地，消息解析参数包含：数据序列化格式解析参数、数据长度。
可选地，数据序列化格式解析参数包括Protobuf格式解析参数或Json格式解析参数。
可选地，该装置还包括：编码模块，适于若消息解析参数包含Protobuf格式解析参数，则根据Protobuf格式的编码规则对直播建连参数进行编码，得到预设数据长度的序列化结构数据。
可选地，若客户端为发布端，序列化结构数据包括：应用标识、流标识、推流传输方法、直播数据分块大小、窗口大小。
可选地，若客户端为订阅端，序列化结构数据包括：应用标识、流标识、拉流传输方法、窗口大小。
本申请实施例提供的方法，根据一次握手交互中以预设数据结构写入有消息解析参数和序列化结构数据的握手请求消息就能够实现直播连接的建立，本次直播连接的建立需要1个RTT即可完成，相较于现有技术需要5个RTT才能够建立连接，有效缩短了直播连接的建立所需时间，从而加快了直播首开速度，提升了用户的直播体验，针对不同消息解析参数进行不同的处理，Protobuf格式具有压缩比例高，相同内容字符长度的数据经过Protobuf格式编码处理后会小很多，同时编码后不是明文，相对安全一些。
本申请实施例还提供了一种直播连接的建立系统，包括：图7所示的直播连接的建立装置和图8所示的直播连接的建立装置。
本申请实施例还提供了一种非易失性计算机存储介质，所述计算机存储介质存储有至少一可执行指令，该计算机可执行指令可执行上述任意方法实施例中的直播连接的建立方法。
图9示出了根据本申请中的一个实施例的计算设备的结构示意图，本申请具体实施例并不对计算设备的具体实现做限定。
如图9所示，该计算设备可以包括：处理器(processor)902、通信接口(Communications Interface)904、存储器(memory)906、以及通信总线908。
其中：
处理器902、通信接口904、以及存储器906通过通信总线908完成相互间的通信。
通信接口904，用于与其它设备比如客户端或其它服务器等的网元通信。
处理器902，用于执行程序910，具体可以执行上述直播连接的建立方法实施例中的相关步骤。
具体地，程序910可以包括程序代码，该程序代码包括计算机操作指令。
处理器902可能是中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。计算设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。
存储器906，用于存放程序910。存储器906可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。
程序910具体可以用于使得处理器902执行上述任意方法实施例中的直播连接的建立方法。程序910中各步骤的具体实现可以参见上述直播连接的建立实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。
在此提供的算法或显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本申请实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本申请的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本申请实施例的一些或者全部部件的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
应该注意的是上述实施例对本申请进行说明而不是对本申请进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。上述实施例中的步骤，除有特殊说明外，不应理解为对执行顺序的限定。

Claims (18)

1.一种直播连接的建立方法，所述方法应用于服务端，包括：
获取握手请求消息，其中，所述握手请求消息用于客户端请求与所述服务端建立直播连接，所述握手请求消息包括消息解析参数和序列化结构数据，所述消息解析参数包含：数据序列化格式解析参数、数据长度；
根据所述消息解析参数对所述序列化结构数据进行解析，得到用于直播连接建立的直播建连参数；其中，若所述消息解析参数包含Protobuf格式解析参数，则根据Protobuf格式的解码规则对预设数据长度的序列化结构数据进行解码，得到用于直播连接建立的直播建连参数；若所述消息解析参数包含Json格式解析参数，则根据预设参数关键字，从预设数据长度的序列化结构数据中提取用于直播连接建立的直播建连参数；
根据所述直播建连参数建立与所述客户端之间的直播连接，并向所述客户端返回连接建立确认消息，其中，若所述客户端为订阅端，则向订阅端返回携带有直播数据分块大小的连接建立确认消息。
2.根据权利要求1所述的方法，其中，所述握手请求消息中以预设数据结构写入有消息解析参数和序列化结构数据。
3.根据权利要求1或2所述的方法，其中，若所述客户端为发布端，所述序列化结构数据包括：应用标识、流标识、推流传输方法、直播数据分块大小、窗口大小。
4.根据权利要求1或2所述的方法，其中，若所述客户端为订阅端，所述序列化结构数据包括：应用标识、流标识、拉流传输方法、窗口大小。
5.根据权利要求1或2所述的方法，其中，所述握手请求消息具体为基于RTMP协议的握手请求消息。
6.一种直播连接的建立方法，所述方法应用于客户端，包括：
向服务端发送握手请求消息，以供服务端根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数，根据所述直播建连参数建立与所述客户端之间的直播连接，并向所述客户端返回连接建立确认消息，其中，所述握手请求消息用于所述客户端请求与所述服务端建立直播连接，所述握手请求消息包括消息解析参数和序列化结构数据，所述消息解析参数包含：数据序列化格式解析参数、数据长度；其中，若所述消息解析参数包含Protobuf格式解析参数，则根据Protobuf格式的解码规则对预设数据长度的序列化结构数据进行解码，得到用于直播连接建立的直播建连参数；若所述消息解析参数包含Json格式解析参数，则根据预设参数关键字，从预设数据长度的序列化结构数据中提取用于直播连接建立的直播建连参数，若所述客户端为订阅端，则向订阅端返回携带有直播数据分块大小的连接建立确认消息；
接收所述服务端返回的连接建立确认消息，以根据所述连接建立确认消息向所述服务端发送数据。
7.根据权利要求6所述的方法，其中，所述客户端包括订阅端或发布端。
8.根据权利要求7所述的方法，其中，所述接收服务端返回的连接建立确认消息进一步包括：
若所述客户端为订阅端，则接收服务端返回的携带有直播数据分块大小的连接建立确认消息。
9.根据权利要求6-8中任一项所述的方法，其中，所述握手请求消息中以预设数据结构写入有消息解析参数和序列化结构数据。
10.根据权利要求6所述的方法，其中，所述数据序列化格式解析参数包括Protobuf格式解析参数或Json格式解析参数。
11.根据权利要求10所述的方法，其中，在向服务端发送握手请求消息之前，所述方法还包括：若所述消息解析参数包含Protobuf格式解析参数，则根据Protobuf格式的编码规则对直播建连参数进行编码，得到预设数据长度的序列化结构数据。
12.根据权利要求6-8中任一项所述的方法，其中，若所述客户端为发布端，所述序列化结构数据包括：应用标识、流标识、推流传输方法、直播数据分块大小、窗口大小。
13.根据权利要求6-8中任一项所述的方法，其中，若所述客户端为订阅端，所述序列化结构数据包括：应用标识、流标识、拉流传输方法、窗口大小。
14.一种直播连接的建立装置，所述装置应用于服务端，包括：
获取模块，适于获取握手请求消息，其中，所述握手请求消息用于客户端请求与所述服务端建立直播连接，所述握手请求消息包括消息解析参数和序列化结构数据，所述消息解析参数包含：数据序列化格式解析参数、数据长度；
解析模块，适于根据所述消息解析参数对所述序列化结构数据进行解析，得到用于直播连接建立的直播建连参数；其中，若所述消息解析参数包含Protobuf格式解析参数，则根据Protobuf格式的解码规则对预设数据长度的序列化结构数据进行解码，得到用于直播连接建立的直播建连参数；若所述消息解析参数包含Json格式解析参数，则根据预设参数关键字，从预设数据长度的序列化结构数据中提取用于直播连接建立的直播建连参数；
建立模块，适于根据所述直播建连参数建立与所述客户端之间的直播连接；
发送模块，适于向所述客户端返回连接建立确认消息，其中，若所述客户端为订阅端，则向订阅端返回携带有直播数据分块大小的连接建立确认消息。
15.一种直播连接的建立装置，所述装置应用于客户端，包括：
发送模块，适于向服务端发送握手请求消息，以供服务端根据消息解析参数对序列化结构数据进行解析，得到用于直播连接建立的直播建连参数，根据所述直播建连参数建立与所述客户端之间的直播连接，并向所述客户端返回连接建立确认消息，其中，所述握手请求消息用于所述客户端请求与所述服务端建立直播连接，所述握手请求消息包括消息解析参数和序列化结构数据，所述消息解析参数包含：数据序列化格式解析参数、数据长度；其中，若所述消息解析参数包含Protobuf格式解析参数，则根据Protobuf格式的解码规则对预设数据长度的序列化结构数据进行解码，得到用于直播连接建立的直播建连参数；若所述消息解析参数包含Json格式解析参数，则根据预设参数关键字，从预设数据长度的序列化结构数据中提取用于直播连接建立的直播建连参数，若所述客户端为订阅端，则向订阅端返回携带有直播数据分块大小的连接建立确认消息；
接收模块，适于接收所述服务端返回的连接建立确认消息，以根据所述连接建立确认消息向所述服务端发送数据。
16.一种直播连接的建立系统，包括：权利要求14所述的直播连接的建立装置和权利要求15所述的直播连接的建立装置。
17.一种计算设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；
所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-5中任一项所述的直播连接的建立方法或权利要求6-13中任一项所述的直播连接的建立方法对应的操作。
18.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-5中任一项所述的直播连接的建立方法或权利要求6-13中任一项所述的直播连接的建立方法对应的操作。
CN202210055165.3A 2022-01-18 2022-01-18 直播连接的建立方法、装置及系统 Active CN114501049B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210055165.3A CN114501049B (zh) 2022-01-18 2022-01-18 直播连接的建立方法、装置及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210055165.3A CN114501049B (zh) 2022-01-18 2022-01-18 直播连接的建立方法、装置及系统

Publications (2)

Publication Number Publication Date
CN114501049A CN114501049A (zh) 2022-05-13
CN114501049B true CN114501049B (zh) 2023-10-27

Family

ID=81511508

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210055165.3A Active CN114501049B (zh) 2022-01-18 2022-01-18 直播连接的建立方法、装置及系统

Country Status (1)

Country Link
CN (1) CN114501049B (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107105339A (zh) * 2017-03-31 2017-08-29 广州酷狗计算机科技有限公司 一种播放直播视频的方法、装置和系统
CN108696772A (zh) * 2017-04-11 2018-10-23 上海谦问万答吧云计算科技有限公司 一种实时视频的传输方法及装置
CN110830460A (zh) * 2019-10-25 2020-02-21 香港乐蜜有限公司 一种连接建立方法、装置、电子设备及存储介质
CN111064976A (zh) * 2018-10-17 2020-04-24 武汉斗鱼网络科技有限公司 一种直播信息的发送方法及服务器
CN111107293A (zh) * 2019-12-16 2020-05-05 咪咕文化科技有限公司 360度视频录制方法、装置、电子设备及存储介质
CN112153022A (zh) * 2020-09-11 2020-12-29 上海七牛信息技术有限公司 一种rtmp快速发布和订阅方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107105339A (zh) * 2017-03-31 2017-08-29 广州酷狗计算机科技有限公司 一种播放直播视频的方法、装置和系统
CN108696772A (zh) * 2017-04-11 2018-10-23 上海谦问万答吧云计算科技有限公司 一种实时视频的传输方法及装置
CN111064976A (zh) * 2018-10-17 2020-04-24 武汉斗鱼网络科技有限公司 一种直播信息的发送方法及服务器
CN110830460A (zh) * 2019-10-25 2020-02-21 香港乐蜜有限公司 一种连接建立方法、装置、电子设备及存储介质
CN111107293A (zh) * 2019-12-16 2020-05-05 咪咕文化科技有限公司 360度视频录制方法、装置、电子设备及存储介质
CN112153022A (zh) * 2020-09-11 2020-12-29 上海七牛信息技术有限公司 一种rtmp快速发布和订阅方法

Also Published As

Publication number Publication date
CN114501049A (zh) 2022-05-13

Similar Documents

Publication Publication Date Title
CN108848060B (zh) 一种多媒体文件处理方法、处理系统及计算机可读存储介质
JP4363847B2 (ja) インタラクティブ・テレビ用のデジタル・テレビ・アプリケーション・プロトコル
CN108337528A (zh) 一种预览视频的方法及设备
WO2019227427A1 (zh) 文件下载方法、装置及设备/终端/服务器
CN110139165B (zh) 流媒体反向代理服务实现一个端口承载多个流协议的方法
US20150207904A1 (en) System and method for single kvm client accommodating multiple different video compression technologies
TW201517572A (zh) 一種數據處理方法、裝置及系統
CN110769009B (zh) 用户身份认证方法及系统
Lei et al. Design and implementation of streaming media processing software based on RTMP
CN110545472B (zh) 视频数据的处理方法、装置、电子设备及计算机可读介质
US20120242841A1 (en) System and method for transmitting real-time images
CN114157607A (zh) 媒体流传输方法和系统
CN103546829A (zh) 一种视频业务处理方法及设备
CN113079386B (zh) 一种视频在线播放方法、装置、电子设备及存储介质
CN112995347B (zh) 实现端对端实时数据展示的方法、装置、设备及存储介质
CN108512889B (zh) 一种基于http的应用响应推送方法及代理服务器
CN103873443A (zh) 信息处理方法、本地代理服务器和网络代理服务器
EP2566177A1 (en) Electronic apparatus and method for transferring contents on cloud system to device connected to DLNA
CN108712434A (zh) 一种基于高清视频直播录播会议会诊的实现方法
CN114501049B (zh) 直播连接的建立方法、装置及系统
CN116261021A (zh) 一种视频流播放方法、装置、电子设备及存储介质
CN108259576B (zh) 一种软硬件实时信息传输系统和方法
CN112965750B (zh) Ip化多媒体资源的显示与控制系统及方法
WO2020039239A1 (zh) 一种基于分享的多任务执行方法、装置和设备/终端/服务器
CN113132480B (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
GR01 Patent grant
GR01 Patent grant