CN115314738A

CN115314738A - 对hook的数据添加标签处理拉流的方法及装置

Info

Publication number: CN115314738A
Application number: CN202210976678.8A
Authority: CN
Inventors: 李圣权; 高博文; 任通; 彭大蒙; 叶海斌
Original assignee: CCI China Co Ltd
Current assignee: CCI China Co Ltd
Priority date: 2022-08-15
Filing date: 2022-08-15
Publication date: 2022-11-08
Anticipated expiration: 2042-08-15
Also published as: CN115314738B

Abstract

本申请提出了一种对hook的数据添加标签处理拉流的方法及装置，特定客户端触发流媒体进行拉流，获取特定客户端返回的hook参数并添加标签，其中所述标签至少包括唯一地标识使用所述特定客户端的唯一用户的身份标签以及媒体流标签；流媒体推流带有所述标签的视频流给特定客户端；带有所述标签的所述视频流回流至处理平台进行存储和复制；所述处理平台以串流的方式将带有所述标签的所述视频流推流给其他具有相同标签的客户端。本方案通过添加标签的方式对媒体流进行分类管理，其可利用处理平台来分担媒体流的负荷和压力。

Description

对hook的数据添加标签处理拉流的方法及装置

技术领域

本申请涉及流媒体领域，特别是涉及对hook的数据添加标签处理拉流的方法及装置。

背景技术

流媒体(Streaming Media)技术是指将一连串的媒体数据压缩后，以流的方式在网络中分段传送，实现在网络上实时传输影音以供观赏的一种。技术实现流式传输主要有两种方式:顺序流式传输(progressive streaming)和实时流式传输(real timestreaming)。

随着网络时代的普及，流媒体技术变得越来越强大，不仅仅体现在画面的还原上，同时也体现在了技术运用上，为了能使用户有更好的体验，在流媒体的传输上已经有了不少的技术性突破，针对流媒体传输技术的内容，也有了非常多的研究成果。然而，即便已经有了较多理论的研究与支持，在实际传输的过程，依然存在着一些不可避免的问题。

目前，对于流媒体拉流过多的情况会导致网络拥塞和带宽增加的现象屡见不鲜，为了满足用户的需求，不得不增加流媒体数量以及增加带宽，但是这样的代价就是付出昂贵的价钱以及人力，不仅方法单一，而且效果不明显。因此，针对流媒体拉流这块的处理方案，需要提供一种有效且简单的方式来缓解客户端对流媒体拉流所产生的的负荷以及网络拥塞的问题。

发明内容

本申请实施例提供了一种对hook的数据添加标签处理拉流的方法及装置，通过对hook的数据添加标签的方式，使得流媒体能够对带标签的视频流进行复制以串流的方式主动地推流至同样进行拉流操作的客户端，以达到分担流媒体的压力、减轻流媒体负荷的效果，且可根据客户端的断流现象并及时进行处理。

第一方面，本申请实施例提供了一种一种对hook的数据添加标签处理拉流的方法，包括以下步骤：

特定客户端触发流媒体进行拉流，获取特定客户端返回的hook参数并添加标签，其中所述标签唯一地标识使用所述特定客户端的唯一用户；

流媒体推流带有所述标签的视频流给特定客户端；

带有所述标签的所述视频流回流至处理平台进行存储和复制；

所述处理平台以串流的方式将带有所述标签的所述视频流推流给其他具有相同标签的客户端。

第二方面，本申请实施例提供了一种对hook的数据添加标签处理拉流的方法，包括以下步骤：

获取特定客户端的拉流请求调用拉流请求对应的媒体流，对所述媒体流返回的hook参数添加标签，其中所述标签唯一地表示使用所述特定客户端的唯一用户；

推送带有所述标签的视频流给特定客户端，其中所述特定客户端将带有所述标签的所述视频流回流至处理平台进行存储和复制；

获取其他客户端的拉流请求，触发所述处理平台以串流的方式将带有所述标签的所述视频流推流给其他具有相同标签的客户端。

第三方面，本申请实施例提供了一种对hook的数据添加标签处理拉流的方法，包括以下步骤：

特定客户端向媒体流发送拉流请求，获取带有标签的媒体流；其中所述媒体流返回的hook参数添加标签，其中所述标签唯一地表示使用所述特定客户端的唯一用户；

所述特定客户端将带有所述标签的所述视频流回流至处理平台进行存储和复制；

其他客户端向所述媒体流发送拉流请求，每一所述客户端以串流的方式获取处理平台的带有所述标签的所述视频流。

第四方面，本申请实施例提供了一种对hook的数据添加标签处理拉流的方法，包括以下步骤：

获取特定客户端回流的带有标签的媒体流，其中所述标签为针对特定客户端的媒体流返回的hook参数添加得到，其中所述标签唯一地标识使用所述特定客户端的唯一用户；

存储和复制带有所述标签的媒体流；

当获取其他客户端的拉流请求时，判断其他客户端是否含有同于所述媒体流的相同标签，若有的话以串流的方式将带有所述标签的所述视频流推流给其他具有相同标签的客户端。

第五方面，本申请实施例提供了一种对hook的数据添加标签处理拉流的装置，包括：

多个客户端、流媒体以及处理平台；其中特定客户端触发流媒体进行拉流，流媒体获取特定客户端返回的hook参数并添加标签，其中所述标签唯一地标识使用所述特定客户端的唯一用户；流媒体推流带有所述标签的视频流给特定客户端；带有所述标签的所述视频流回流至处理平台进行存储和复制；所述处理平台以串流的方式将带有所述标签的所述视频流推流给其他具有相同标签的客户端。

第六方面，本申请实施例提供了一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述的对hook的数据添加标签处理拉流的方法。

第七方面，本申请实施例提供了一种可读存储介质，所述可读存储介质中存储有计算机程序，所述计算机程序包括用于控制过程以执行过程的程序代码，所述过程包括根据所述的对hook的数据添加标签处理拉流的方法。

本发明的主要贡献和创新点如下：

本申请实施例通过对媒体流添加标签的方式以区分不同的媒体流，同时增加存储和复制媒体流的处理平台，针对对相同媒体流进行拉流的客户端，处理平台可以串流的方式推送媒体流，以减少流媒体的压力和负载，减轻带宽；另外，本方案将拉流状态与设备状态绑定，通过设备状态判断拉流不稳定的情况，并通过主动推流的方式弥补了数据丢失的问题。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请一种实施例的对hook的数据添加标签处理拉流的方法的实现逻辑图；

图2是对hook的数据添加标签的示意图；

图3是处理平台进行多客户端推流和回流的示意图；

图4-7是本申请实施例的对hook的数据添加标签处理拉流的逻辑示意图；

图8是根据本申请实施例的电子装置的硬件结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

实施例一

如图4所示，本方案提供了一种对hook的数据添加标签处理拉流的方法，包括以下步骤：

特定客户端触发流媒体进行拉流，获取特定客户端返回的hook参数并添加标签，其中所述标签至少包括唯一地标识使用所述特定客户端的唯一用户的身份标签以及媒体流标签；

流媒体推流带有所述标签的视频流给特定客户端；

本方案应用于多个客户端向流媒体拉流的应用场景，在传统的方式中，当多个客户端同时向流媒体拉流时会存在流媒体的负荷过大以及网络拥堵的问题；本方案对其中一个客户端反馈的Hook参数添加对应唯一用户的身份标签以及对应唯一媒体流的媒体流标签，并将该带有标签的媒体流存储在处理平台中，在该处理平台上复制媒体流后以串流的方式主动推流给具有标签的进行拉流操作的客户端，以达到分担流媒体的压力和负荷。

需要说明的是，其他具有相同标签的客户端仅需要具有身份标签或媒体流标签的一种；当其他具有相同标签的客户端为具有身份标签的客户端时，此时处理平台将媒体流推送至登录不同客户端的相同用户；当其他具有相同标签的客户端为具有媒体流标签的客户端时，此时处理平台将媒体流推送至不同客户端的有相同媒体流情况的用户。也就是说，本方案的适用场景不仅限于同一个用户在不同客户端拉流的场景，还可用于不同用户拉取相同媒体流的场景

如图1所示，图1是本方案的对hook的数据添加标签处理拉流的方法的实现逻辑图。多个客户端向流媒体进行拉流，流媒体也赋予其中一个客户端的媒体流以标签，该选定的客户端将带有标签的媒体流回推给处理平台，由处理平台将带有标签的媒体流再推流给其他具有相同标签的客户端，标签包括身份标签和媒体流标签的至少一种。

在“特定客户端触发流媒体进行拉流，获取特定客户端返回的hook参数并添加标签，其中所述标签至少包括唯一地标识使用所述特定客户端的唯一用户的身份标签以及媒体流标签”步骤中，特定客户端的选择并不做限制，从多个客户端中选择一个特定客户端即可。

流媒体获取特定客户端的拉流请求后，调取所述拉流请求对应的媒体流并在所述媒体流返回的hook参数中添加标签。

所述hook参数记录特定媒体流的信息，以用于唯一地表示所述媒体流。所述hook参数至少包括：应用名、唯一标识、请求源、媒体服务id、参数、端口、协议、流id以及主机名。示例性的，针对一特定的媒体流的hook参数为：应用名：rtp；请求源：127.0.0.1；媒体服务id:DuB5D3dD20EhQIGZ；参数：yhb＝1；端口：12121；协议：rtmp；流id：340200000013200000031_340200000013200000032；主机名为：_defaultVhost。

本方案对返回的hook参数人工添加标签，标签包括身份标签和媒体流标签，其中媒体流标签为每一媒体流的唯一标识，身份标签为每一用户的唯一标识，之后可以根据相同身份标签的用户来复制该用户所需要的视频流协议，也可以根据相同媒体流标签来复制相同的媒体流，媒体流本身自带流ID，该流ID作为媒体流标签，身份标签主要标识的对象是用户。本方案的身份标签唯一标识用户，示例性，标签为：#34020000001320000031小明。

在“流媒体推流带有所述标签的视频流给特定客户端”步骤中，由于媒体流本身自带流ID,故带上标签的媒体流的标记可以组成为：身份标签、媒体流标签以及hook参数名称的组合。示例性，如图2所示，特定客户端从流媒体中拉取的媒体流的标记为：#34020000001320000031小明10.10.77.118数学课。

如图3所示，本方案独创一个用于存储和复制媒体流的处理平台，该处理平台可以分担流媒体本身的负载和压力。在“带有所述标签的所述视频流回流至处理平台进行存储和复制”步骤中，特定客户端将带有所述标签的所述视频流回流至所述处理平台中。

在本方案中用户可自主确定需要进行分担的媒体流来缓解流媒体转码的压力和负载，标签标识的是流媒体本身存在的返回的hook参数对应的媒体流协议，而不是媒体流内容本身。

在“所述处理平台以串流的方式将带有所述标签的所述视频流推流给其他具有相同标签的客户端”步骤中，其他客户端请求向流媒体发送拉流请求，所述处理平台判断所述客户端是否带有和存储的媒体流相同的标签，若存在相同标签，所述处理平台以串流的方式向其他客户端推流带有所述标签的媒体流。其他客户端可以是带有媒体流标签也可以是带有身份标签。

在一些实施例中，所述处理平台和所述流媒体互通，当所述流媒体获取拉请请求时，所述处理平台也被触发。

值得一提的是，所述处理平台内可存储对应不同标签的媒体流，以满足不同标签的用户的拉流需求。且由于本方案的客户端的拉流对象是流媒体，推流对象是处理平台，故可以实现同一个客户端同时具有拉流和推流的状态。

另外，本方案通过将录像设备的设备状态和客户端的拉流状态绑定，以监控客户端的拉流状态，当客户端的拉流状态出现拉流断流的情况时，处理平台将具有相同标签的媒体流主动推送给所述客户端。

也就是说，本方案根据录像设备的设备状态判断是否存在拉流断流现象，若存在的话可利用处理平台主动推流的方式解决断流产生的数据包丢失问题。这样的好处在于：当流媒体发生网络堵塞时，客户端的拉流过程中断且数据包会存在丢失，而处理平台可以通过主动推送的方式来弥补断流造成的数据丢失的问题。

具体的，本方案针对客户端的拉流关联录像设备，其中所述录像设备的设备状态同步每一客户端的拉流状态，基于所述录像设备回调的设备状态判断客户端是否出现拉流断流，若存在的话，所述处理平台将具有相同标签的媒体流推送至存在拉流断流状态的客户端。

在一些实施例中，在“所述录像设备同步记录客户端的拉流状态”中，当客户端开始拉流时录像设备开启录制功能，当客户端终止拉流时录像设备停止录制功能，录像设备的录制功能的开启和关闭均产生对应的设备状态，基于所述设备状态可以实时地判断客户端是否出现拉流断流的情况。

进一步的，本方案还可区分客户端主动停止拉流和被动停止拉流的情况。在一些实施例中，获取所述录像设备的设备状态，当所述录像设备的设备状态满足被动停止拉流条件时，判断所述客户端处于被动停止拉流状态；当所述录像设备的设备状态满足主动停止拉流条件时，判断所述客户端处于主动停止拉流，不需要对客户端进行主动推流。

值得一提的是，在一些实施例中，当录像设备的录像功能开启时间超过设定的时间阈值时，对客户端的拉流状态进行判断。

具体的，主动停止拉流条件为：

当所述录像设备的设备状态中的on_stream_none_reader的地址为请求源的on_stream_none_reader时，判断当前客户端处于主动停止拉流的状态。此时录像设备的设备状态对应的是无人观看该媒体流的事件，通过该事件可以判断关闭无人查看的媒体流。示例性的，录像设备的设备状态如下所示：

On_stream_none_reader＝https://127.0.0.1/index/hook/on_stream_none_reader。

被动停止拉流条件为：

当所述录像设备的设备状态中的on_record_mp4的地址为请求源的on_stream_none_reader，且on_play的地址为请求源的on_play时，判断当前客户端处于被动停止拉流的状态。此时录像设备的设备状态对应的是录制mp4切片完成事件以及播放鉴权事件。

示例性的，录像设备的设备状态如下所示：

on_record_mp4＝https://127.0.0.1/index/hook/on_record_mp4；

on_play＝https://127.0.0.1/index/hook/on_play。

而在一些实施例中，当所述录像设备的设备状态同时满足被动停止拉流条件和主动停止拉流条件时，判断当前客户端对流媒体发送拉流请求但是拉流状态为无人读取的状态，此时所述当前客户端处于拉流中断状态。此时，处理平台可对所述客户端推送具有相同标签的媒体流，以防止断流出现。

本方案提供的对hook的数据添加标签处理拉流的方法，可以减少流媒体的负荷和压力，以防止网络拥堵情况下出现拉流断流进而导致数据包丢失的情况，确保在拉流断流的情况下依旧可以将具有相同标签的媒体流主动推送给客户端，以保证客户端可以顺畅地读取媒体流。

另外，本方案可对相同标签的客户端进行分类管理，建立合理管理集群；当管理集群中的客户端的拉流状态出现异常时，根据设备状态调用相同的媒体流进行推送，以进行媒体流补流解决拉流状态不稳定的问题。

实施例二

基于相同的构思，本申请还提出了一种对hook的数据添加标签处理拉流的装置，包括：

多个客户端、流媒体以及处理平台；其中特定客户端触发流媒体进行拉流，流媒体获取特定客户端返回的hook参数并添加标签，其中所述标签至少包括唯一地标识使用所述特定客户端的唯一用户的身份标签以及媒体流标签；流媒体推流带有所述标签的视频流给特定客户端；带有所述标签的所述视频流回流至处理平台进行存储和复制；所述处理平台以串流的方式将带有所述标签的所述视频流推流给其他具有相同标签的客户端。

关于该实施例二中同于实施例一部分的内容在此不进行累赘的说明。

实施例三

基于相同的构思，如图5所示，本方案提供了一种对hook的数据添加标签处理拉流的方法，包括以下步骤：

获取特定客户端的拉流请求调用拉流请求对应的媒体流，对所述媒体流返回的hook参数添加标签，其中所述标签至少包括唯一地标识使用所述特定客户端的唯一用户的身份标签以及媒体流标签；

在一些实施例中，当与任一所述客户端出现拉流断流状态时，处理平台推送具有相同标签的媒体流给所述客户端。关于客户端的拉流断流状态的判断方法如下：

客户端的拉流状态同步于录像设备的设备状态，处理平台获取所述录像设备的设备状态，基于所述录像设备回调的设备状态判断客户端是否出现拉流断流，若存在的话处理平台以主动推流的方式将所述媒体流推送给所述客户端。

该实施例三描述的是媒体流如何对hook的数据添加标签以处理拉流的方案，关于该实施例三中与实施例一相同的技术内容参见实施例一的部分。

实施例四

基于相同的构思，如图6所示，本方案提供了一种对hook的数据添加标签处理拉流的方法，包括以下步骤：

特定客户端向媒体流发送拉流请求，获取带有标签的媒体流；其中所述媒体流返回的hook参数添加标签，其中所述标签至少包括唯一地标识使用所述特定客户端的唯一用户的身份标签以及媒体流标签；

在一些实施例中，当任一客户端与所述媒体流之间出现拉流断流状态时，获取所述处理平台主动推流的带有所述标签的所述视频流。关于客户端和媒体流之间的拉流断流状态的判断方式如下：

该实施例四描述的是客户端如何从媒体流或者处理平台中拉流的方案，关于该实施例四中与实施例一相同的技术内容参见实施例一的部分。

实施例五

基于相同的构思，如图7所示，本方案提供了一种对hook的数据添加标签处理拉流的方法，包括以下步骤：

获取特定客户端回流的带有标签的媒体流，其中所述标签为针对特定客户端的媒体流返回的hook参数添加得到，其中所述标签至少包括唯一地标识使用所述特定客户端的唯一用户的身份标签以及媒体流标签；

存储和复制带有所述标签的媒体流；

在一些实施例中，获取同步于所述客户端的录像设备的设备状态，基于所述路设备的设备状态判断是否出现拉流断流状态，若任一所述客户端出现拉流断流状态，主动推送具有相同标签的媒体流至所述客户端。

该实施例五描述的是客户端如何从媒体流或者处理平台中拉流的方案，关于该实施例四中与实施例一相同的技术内容参见实施例一的部分。

实施例六

本实施例还提供了一种电子装置，参考图8，包括存储器404和处理器402，该存储器404中存储有计算机程序，该处理器402被设置为运行计算机程序以执行上述任一项对hook的数据添加标签处理拉流的方法的实施例中的步骤。

具体地，上述处理器402可以包括中央处理器(CPU)，或者特定集成电路(ApplicationSpecificIntegratedCircuit，简称为ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

其中，存储器404可以包括用于数据或指令的大容量存储器404。举例来说而非限制，存储器404可包括硬盘驱动器(HardDiskDrive，简称为HDD)、软盘驱动器、固态驱动器(SolidStateDrive，简称为SSD)、闪存、光盘、磁光盘、磁带或通用串行总线(UniversalSerialBus，简称为USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器404可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器404可在数据处理装置的内部或外部。在特定实施例中，存储器404是非易失性(Non-Volatile)存储器。在特定实施例中，存储器404包括只读存储器(Read-OnlyMemory，简称为ROM)和随机存取存储器(RandomAccessMemory，简称为RAM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(ProgrammableRead-OnlyMemory，简称为PROM)、可擦除PROM(ErasableProgrammableRead-OnlyMemory，简称为EPROM)、电可擦除PROM(ElectricallyErasableProgrammableRead-OnlyMemory，简称为EEPROM)、电可改写ROM(ElectricallyAlterableRead-OnlyMemory，简称为EAROM)或闪存(FLASH)或者两个或更多个以上这些的组合。在合适的情况下，该RAM可以是静态随机存取存储器(StaticRandom-AccessMemory，简称为SRAM)或动态随机存取存储器(DynamicRandomAccessMemory，简称为DRAM)，其中，DRAM可以是快速页模式动态随机存取存储器404(FastPageModeDynamicRandomAccessMemory，简称为FPMDRAM)、扩展数据输出动态随机存取存储器(ExtendedDateOutDynamicRandomAccessMemory，简称为EDODRAM)、同步动态随机存取内存(SynchronousDynamicRandom-AccessMemory，简称SDRAM)等。

存储器404可以用来存储或者缓存需要处理和/或通信使用的各种数据文件，以及处理器402所执行的可能的计算机程序指令。

处理器402通过读取并执行存储器404中存储的计算机程序指令，以实现上述实施例中的任意一种对hook的数据添加标签处理拉流的方法。

可选地，上述电子装置还可以包括传输设备406以及输入输出设备408，其中，该传输设备406和上述处理器402连接，该输入输出设备408和上述处理器402连接。

传输设备406可以用来经由一个网络接收或者发送数据。上述的网络具体实例可包括电子装置的通信供应商提供的有线或无线网络。在一个实例中，传输设备包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输设备406可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。

输入输出设备408用于输入或输出信息。在本实施例中，输入的信息可以是拉流请求等，输出的信息可以是带有标签的媒体流等。

可选地，在本实施例中，上述处理器402可以被设置为通过计算机程序执行以下步骤：

流媒体推流带有所述标签的视频流给特定客户端；

需要说明的是，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

通常，各种实施例可以以硬件或专用电路、软件、逻辑或其任何组合来实现。本发明的一些方面可以以硬件来实现，而其他方面可以以可以由控制器、微处理器或其他计算设备执行的固件或软件来实现，但是本发明不限于此。尽管本发明的各个方面可以被示出和描述为框图、流程图或使用一些其他图形表示，但是应当理解，作为非限制性示例，本文中描述的这些框、装置、系统、技术或方法可以以硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其他计算设备或其某种组合来实现。

本发明的实施例可以由计算机软件来实现，该计算机软件由移动设备的数据处理器诸如在处理器实体中可执行，或者由硬件来实现，或者由软件和硬件的组合来实现。包括软件例程、小程序和/或宏的计算机软件或程序(也称为程序产品)可以存储在任何装置可读数据存储介质中，并且它们包括用于执行特定任务的程序指令。计算机程序产品可以包括当程序运行时被配置为执行实施例的一个或多个计算机可执行组件。一个或多个计算机可执行组件可以是至少一个软件代码或其一部分。另外，在这一点上，应当注意，如图中的逻辑流程的任何框可以表示程序步骤、或者互连的逻辑电路、框和功能、或者程序步骤和逻辑电路、框和功能的组合。软件可以存储在诸如存储器芯片或在处理器内实现的存储块等物理介质、诸如硬盘或软盘等磁性介质、以及诸如例如DVD及其数据变体、CD等光学介质上。物理介质是非瞬态介质。

本领域的技术人员应该明白，以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims

1.一种对hook的数据添加标签处理拉流的方法，其特征在于，包括以下步骤：

流媒体推流带有所述标签的视频流给特定客户端；

2.根据权利要求1所述的对hook的数据添加标签处理拉流的方法，其特征在于，在“所述处理平台以串流的方式将带有所述标签的所述视频流推流给其他具有相同标签的客户端”步骤中，其他客户端请求向流媒体发送拉流请求，所述处理平台判断所述客户端是否带有和存储的媒体流相同的标签，若存在相同标签，所述处理平台以串流的方式向其他客户端推流带有所述标签的媒体流。

3.根据权利要求1所述的对hook的数据添加标签处理拉流的方法，其特征在于，录像设备的设备状态同步每一客户端的拉流状态，基于所述录像设备回调的设备状态判断客户端是否出现拉流断流状态，若存在的话，所述处理平台将具有相同标签的媒体流推送至存在拉流断流状态的客户端。

4.根据权利要求3所述的对hook的数据添加标签处理拉流的方法，其特征在于，获取所述录像设备的设备状态，当所述录像设备的设备状态同时满足被动停止拉流条件和主动停止拉流条件时，所述当前客户端处于拉流中断状态。

5.一种对hook的数据添加标签处理拉流的方法，其特征在于，包括以下步骤：

6.一种对hook的数据添加标签处理拉流的方法，其特征在于包括以下步骤：

7.一种对hook的数据添加标签处理拉流的方法，其特征在于，包括以下步骤：

存储和复制带有所述标签的媒体流；

8.一种对hook的数据添加标签处理拉流的装置，其特征在于，包括：

9.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行权利要求1到7任一所述的对hook的数据添加标签处理拉流的方法。

10.一种可读存储介质，其特征在于，所述可读存储介质中存储有计算机程序，所述计算机程序包括用于控制过程以执行过程的程序代码，所述过程包括根据权利要求1到7任一所述的对hook的数据添加标签处理拉流的方法。