具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请中的术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”、“第三”的特征可以明示或者隐含地包括至少一个该特征。本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，在不冲突的情况下，本文所描述的实施例可以与其它实施例相结合。

现有的播放窗口切换方法的主要工作原理是：获取播放数据；利用第一播放窗口对播放数据进行渲染播放；若有切换到第二播放窗口渲染播放的需要，则需要将原来在第一播放窗口渲染播放的播放数据，切换到第二播放窗口继续进行渲染播放。

现有的播放窗口切换方法所需耗费时间长，且会出现跳播/黑屏现象，其原因在于：对播放数据进行渲染播放所利用的播放窗口是与播放数据的内存地址绑定的。而现有的播放窗口切换方法下，获取到的播放数据的内存地址与播放窗口的绑定关系是固定不变的。这也就意味着，在用户有切换到第二播放窗口的需求时，会先释放掉第一播放窗口的内存地址与第一播放窗口的绑定关系，然后重新为播放数据创建一个新的内存地址，并将新的内存地址与第二播放窗口绑定，从而实现将第一播放窗口切换为第二播放窗口。因此在切换播放窗口的过程中存在较长的时间消耗，导致切换前后的画面内容出现跳跃，出现跳播/黑屏的现象。

图1是本申请播放窗口切换方法实施例一的流程示意图。需注意的是，若有实质上相同的结果，本实施例并不以图1所示的流程顺序为限。

如图1所示，本实施例可以包括：

S11：获取播放数据。

其中，播放数据的内存地址与第一播放窗口绑定。

本实施例的执行主体可以为用户所在的终端(用户端)。本申请的应用场景包括但不限于娱乐场景和监控场景，因此播放数据可以但不限于为监控视频(如室内监控视频、室内监控视频)、娱乐视频(如影片、游戏视频)。其中，播放数据可以是实时的，也可以是非实时的。

可以理解的是，播放数据的内存地址与第一播放窗口绑定，则意味着用于渲染播放该播放数据的播放窗口为第一播放窗口。

S12：利用第一播放窗口对播放数据进行渲染播放。

S13：判断是否接收到切换播放窗口的请求。

其中，切换播放窗口的请求指向第二播放窗口。

用户可以在用户端界面上选择播放窗口(第二播放窗口)，以触发用户端生成切换窗口的请求。其中，第一播放窗口和第二播放窗口可以为同一页面上的不同播放窗口，也可以为不同页面上的播放窗口。

若是，则执行S14。

S14：解除播放数据的内存地址与第一播放窗口的绑定关系。

此外，在其他实施例中，解除播放数据的内存地址与第一播放窗口的绑定关系之后，还可以删除第一播放窗口的缓存，从而第一播放窗口不需要一直缓存在内存中，降低了内存溢出的可能性。

S15：将播放数据的内存地址与第二播放窗口绑定，以利用第二播放窗口对播放数据进行渲染播放。

通过本实施例的实施，本申请在用户需要切换播放窗口时，只需要改变播放数据的内存地址与播放窗口的绑定关系，也即将与播放句柄绑定的播放窗口从原本的第一播放窗口替换为第二播放窗口，即可实现播放窗口的切换。相比于现有的方式，本申请提供的播放窗口切换方法能够实现播放窗口的无缝切换，因此所需时间较少，且不会出现黑屏/跳播现象。

图2是本申请播放窗口切换方法实施二的流程示意图。需注意的是，若有实质上相同的结果，本实施例并不以图2所示的流程顺序为限。本实施例是对S11的进一步扩展，如图2所示，本实施例可以包括：

S111：向目标设备端发送拉流请求。

目标设备端可以为能够提供播放数据的终端。用户可在需求时通过语音、按键、触摸等方式触发用户端向目标设备端发送拉流请求。下面进行举例说明：

在娱乐场景下，用户端上可以运行有视频播放应用，目标设备端可以为视频播放应用对接的终端。用户可以在视频播放应用界面上选择想要观看的视频，视频播放应用可以生成拉流请求并发送至与视频播放应用对接的终端。

在监控场景下可以获取候选设备端列表，也即可以在用户端界面上显示候选设备端列表，候选设备端列表可以包括布置在各个监控区域的摄像设备；从候选设备端列表中选出目标设备端。在一具体实施方式中，可以由用户从候选设备端列表中选出目标设备端；在另一具体实施方式中，也可以按照特定算法从候选设备中选出目标设备端，以触发用户端生成拉流请求并发送至目标设备端。

在其他实施例中，S111之前还可以包括：确定播放数据的内存地址和码流的内存地址。换句话说，可以在向目标设备端发送拉流请求之前，预先为目标设备端发送的码流分配存储空间，以及预先为对码流解码得到的播放数据分配存储空间。

S112：接收目标设备端响应拉流请求发送的码流。

目标设备可以在接收到拉流请求之后，将拉流请求指向的播放数据压缩成码流并发送至用户端。

S113：对码流进行解码得到播放数据。

可以根据压缩方式选择相应地解码方式，以对码流进行解码得到播放数据。

图3是本申请播放窗口切换方法实施例三的流程示意图。需注意的是，若有实质上相同的结果，本实施例并不以图3所示的流程顺序为限。本实施例是对实施例一的进一步扩展，如图3所示，本实施例可以包括：

S21：判断播放数据的内存地址是否有效。

可以理解的是，播放数据的内存地址有效，意味着当前对播放数据的渲染播放操作在正常进行/没有停止。在此情况下，才存在播放窗口的切换，执行S22-S23以实现播放窗口的切换才有意义。

其中，可以用播放句柄来标识播放数据的内存地址，从而可以根据播放句柄的状态来判断播放数据的内存地址是否有效。

若有效，则执行S22-S23(对应上述S14-S15)；若无效，则执行S24-S25。

S22：解除播放数据的内存地址与第一播放窗口的绑定关系。

S23：将播放数据的内存地址与第二播放窗口绑定，以利用第二播放窗口对播放数据进行渲染播放。

S24：重新获取播放数据。

其中，重新获取到的播放数据的内存地址与第二播放窗口绑定。

S25：利用第二播放窗口对播放数据进行渲染播放。

本实施例其他步骤的详细说明请参见前面的实施例，在此不再重复。

图4是本申请播放窗口切换方法实施例四的流程示意图。需注意的是，若有实质上相同的结果，本实施例并不以图4所示的流程顺序为限。本实施例是对实施例三的进一步扩展，播放数据为实时的视频。如图4所示，本实施例可以包括：

S31：判断码流的内存地址是否有效。

可以理解的是，在播放数据为实时的视频的情况下，码流的内存地址有效，意味着当前用户端从目标设备端的拉流操作未被中断，进而当前对播放数据的渲染播放操作才可能在正常进行/没有停止。因此，在码流的内存地址有效的情况下执行S32才有意义。

其中，可以用流源句柄来标识码流的内存地址，因此可以根据流源句柄的状态来判断码流的内存地址是否有效。

若有效，则执行S32(对应上述21)；若无效，则执行S33-S34(对应上述S24-S25)。

S32：判断播放数据的内存地址是否有效。

S33：重新获取播放数据。

其中，重新获取到的播放数据的内存地址与第二播放窗口绑定。

S34：利用第二播放窗口对播放数据进行渲染播放。

本实施例其他步骤的详细说明请参见前面的实施例，在此不再重复。

区别于上述实施例三和实施例四，其他实施例中可以同时判断播放数据的内存地址和码流的内存地址是否有效，在两者均有效的情况下，才执行S22-S23/S14-S15。

下面结合图5，以一个例子的形式对本申请提供的播放窗口切换方法进行详细说明。

预先为码流分配内存地址和为播放数据分配内存地址，并将播放数据的内存地址与第一播放窗口绑定；

向目标设备端(摄像头1)发送拉流请求；

接收目标设备端发送的码流，并对码流进行解码得到播放数据；

利用播放窗口1对播放数据渲染播放，其中，图5的左侧所示为播放窗口1及其所在页面1的示意图；

接收到用户对在页面1的播放窗口1的点击操作，以指示用户端切换至播放窗口2；

响应用户的点击操作，判断播放数据的内存地址是否有效；

若有效，则将与播放数据的内存地址绑定的第一播放窗口替换为第二播放窗口，利用第二播放窗口对播放数据进行渲染播放，其中，图5的右侧所示为播放窗口2及其所在页面2的示意图；

若无效，则重新为码流分配内存地址和为播放数据分配内存地址，并将重新为播放数据分配的内存地址与第二播放窗口绑定，重新向目标设备端发送拉流请求，以重新获取播放数据，利用第二播放窗口对播放数据进行渲染播放。

图6是本申请电子设备一实施例的结构示意图。如图6所示，该电子设备包括处理器41、与处理器41耦接的存储器42。

其中，存储器42存储有用于实现上述任一实施例的方法的程序指令；处理器41用于执行存储器42存储的程序指令以实现上述方法实施例的步骤。其中，处理器41还可以称为CPU(Central Processing Unit，中央处理单元)。处理器41可能是一种集成电路芯片，具有信号的处理能力。处理器41还可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器41也可以是任何常规的处理器等。

图7是本申请存储介质一实施例的结构示意图。如图7所示，本申请实施例的计算机可读存储介质50存储有程序指令51，该程序指令51被执行时实现本申请上述实施例提供的方法。其中，该程序指令51可以形成程序文件以软件产品的形式存储在上述计算机可读存储介质50中，以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施方式方法的全部或部分步骤。而前述的计算机可读存储介质50包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质，或者是计算机、服务器、手机、平板等终端设备。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。以上仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。