具体实施方式

为便于对申请的技术方案进行解释，以下首先在对本申请所涉及到的一些概念进行说明。

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

需要说明的是，本申请中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本申请的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。

本申请中说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似或同类的对象或实体，而不必然意味着限定特定的顺序或先后次序，除非另外注明。应该理解这样使用的用语在适当情况下可以互换。

术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的所有组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。

术语“模块”是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件或/和软件代码的组合，能够执行与该元件相关的功能。

图1为根据实施例中机顶盒的使用场景的示意图。如图1所示，机顶盒100，是一个连接显示设备200与服务器400的设备。它可以将压缩的数字信号转成电视内容，并在显示装置上显示出来。

显示设备200与服务器400进行数据通信，用户可通过智能设备300或控制装置500操作显示设备200。

在一些实施例中，控制装置500可以是遥控器，遥控器和显示设备的通信包括红外协议通信或蓝牙协议通信，及其他短距离通信方式中的至少一种，通过无线或有线方式来控制显示设备200。用户可以通过遥控器上按键、语音输入、控制面板输入等至少一种输入用户指令，来控制显示设备200。

在一些实施例中，智能设备300可以包括移动终端、平板电脑、计算机、笔记本电脑，AR/VR设备等中的任意一种。

在一些实施例中，也可以使用智能设备300以控制显示设备200。例如，使用在智能设备上运行的应用程序java层控制显示设备200。

在一些实施例中，也可以使用智能设备300和显示设备进行数据的通信。

在一些实施例中，显示设备200还可以采用除了控制装置500和智能设备300之外的方式进行控制，例如，可以通过显示设备200设备内部配置的获取语音指令的模块直接接收用户的语音指令控制，也可以通过显示设备200设备外部设置的语音控制装置来接收用户的语音指令控制。

在一些实施例中，机顶盒还与服务器400进行数据通信。可允许机顶盒100通过局域网(LAN)、无线局域网(WLAN)和其他网络进行通信连接。服务器400可以向机顶盒100提供各种内容和互动。服务器400可以是一个集群，也可以是多个集群，可以包括一类或多类服务器。

在一些实施例中，一个步骤执行主体执行的软件步骤可以随需求迁移到与之进行数据通信的另一步骤执行主体上进行执行。示例性的，服务器执行的软件步骤可以随需求迁移到与之数据通信的显示设备上执行，反之亦然。

控制装置500还可与机顶盒100通信连接，通常控制装置与机顶盒通过红外协议通信，机顶盒接收控制装置的通信信号，完成用户遥控操作。

机顶盒100可以是外设置于显示设备壳体外侧，可也内置于显示设备内部。

为了播放随机推送视频，机顶盒IPTV应用程序与播放器约定好加载接口，当外部网管推送播放视频时，IPTV应用程序通过加载接口把视频url传递给播放器播放，不需要通过浏览器内核加载。

IPTV应用程序接收外部网管推送的视频，再通过加载接口把视频url传递给播放器播放的过程中，因视频接口与IPTV规范中的视频加载接口不一致，容易导致播放器调用接口出错。

为解决以上问题，机顶盒包括：第一通信接口，用于接收推送视频地址信息。第二通信接口，与遥控设备连接，用于接收用户指令。

处理器，被配置为：根据推送视频地址信息和用户指令，形成播放网页信息。

第三通信接口，与显示设备连接，向显示设备传输处理后的播放网页信息。

处理器进一步被配置为：

网管应用，接收第一通信接口的推送视频地址，将视频地址传递至IPTV应用；

IPTV应用，根据推送视频地址生成播放网页，并加载播放网页，生成播放器实例。

播放器，用于播放播放器实例。

图2为本申请实施例示出的一种机顶盒软件层示意图，如图中所示，本申请实施例示出了一种机顶盒，设置有网管应用、IPTV应用和播放器，网管应用接收外部服务器推送的视频地址，将视频地址传递至IPTV应用。IPTV应用的生成播放网页，并加载播放网页。播放器用于播放加载的播放网页。

在本申请的一些实施例中，IPTV应用设置有应用程序java层和浏览器内核，应用程序java层根据接收到的视频地址生成页面，并向浏览器内核发送调用信息，浏览器内核加载生成的播放网页，生成播放器实例。在本申请实施例中，播放网页的加载接口与IPTV规范中的视频加载接口一致，不需要播放器再另外添加接口，统一了播放器加载接口，降低出错概率。同时将视频地址转换成了浏览器内核加载网页，没有打断浏览器内核操作，也不影响浏览器内核后续操作。将原来的视频播放过程改成了浏览器内核加载网页，在网页中对于播放的操作更容易实现，且逻辑更清楚独立。

图3为本申请实施例提供的一种机顶盒响应推送视频流程的框架图。如图3所示，在本申请的一些实施例中，外部服务器推送视频地址至网管应用。视频地址以数据形式进行传递。网管应用接收到视频地址后，将视频地址通过广播的方式传递至应用程序java层。应用程序java层发送使能信号至浏览器内核，生成视频地址对应的播放网页，应用程序java层控制浏览器内核加载播放网页。浏览器内核加载播放网页，生成播放器实例。在本申请中，浏览器内核生成的播放器实例的加载接口与IPTV规范中的视频加载接口一致，不需要播放器另外添加接口，统一播放器接口，有利于降低播放出错率。播放器根据播放网页调用的接口开始播放视频。

在本申请实施例中，为提高用户体验度，还包括：接收用户的返回信号，退出当前播放网页，返回前一次的播放网页。

在本申请实施例中，还包括，当前视频播放完成后，返回播放视频之前的页面。

图4为本申请实施例提供的一种播放随机推送视频的信令流程图，如图4所示，为了能够及时准确地播放外部服务器推送的视频，本申请提供了一种播放随机推送视频的方法，包括：

接收推送的视频地址信息，生成播放网页。在本申请的一些实施例中，外部网管平台向机顶盒推送视频地址，机顶盒网管应用接收视频地址，并将视频地址传递至应用程序java层。机顶盒网管应用将视频地址通过广播的方式传递给应用程序java层。

应用程序java层接收网管应用推送的含视频地址的广播，生成视频地址对应的播放网页，应用程序java层控制浏览器内核加载播放网页。本申请中将视频地址对应的播放网页称为第二播放网页。

生成视频地址对应的播放网页的过程包括：

播放器实例的创建，播放器的初始化、以及离开页面的播放器销毁等有关加载接口的操作；

通过PlayParams.getConfig获取视频地址；

通过PlayParams.updateConfig更新视频地址；

对播放器返回的播放状态事件响应，如对播放结束事件的响应；

对按键的响应，比如对返回键的响应。

在本申请实施例中，如果接收到推送的视频地址时，浏览器内核正在播放视频，IPTV应用程序java层自动生成推送的视频地址对应的播放网页，终止之前的视频播放，通过PlayParams.setConfig把推送的视频地址传递给页面。本申请中在接收到推送的视频地址时，浏览器内核正在播放视频的播放网页，称之为第一播放网页。

浏览器内核加载生成的播放网页，生成播放器实例。通过PlayParams.getConfig获取视频地址，并把视频地址通过播放器接口传递给播放器。

播放器根据播放网页调用的接口，开始播放视频。

视频播放结束后，播放器发送视频播放结束信息至浏览器内核。

浏览器内核接收视频播放结束信息后，返回播放之前的页面，即返回第一页面。浏览器内核接收视频播放结束信息后，根据页面逻辑返回到播放之前的页面。

在本申请实施例中，为提高用户体验度，还包括：接收用户的返回信号，退出当前播放网页，返回第一页面。

在本申请提供的一些实施例中，还包括：当前推送视频未播放完成是，收到第二推送视频，后推送的视频优先级高于之前推送的视频，应用程序java层通过PlayParams.updateConfig更新视频地址，播放后推送的视频。

图5为本申请实施例提供的另一种播放随机推送视频信令流程图，本申请提供的播放随机推送视频的方法包括：

IPTV应用程序java层接收第一推送视频地址信息，生成第二播放网页。浏览器内核加载第二播放网页，第二播放网页为第一推送视频地址对应生成的播放网页。

浏览器内核加载第二播放网页，生成第二播放器实例。播放器通过调用第二播放器实例的接口，开始播放第一推送视频。

在第一推送视频播放完成之前，IPTV应用程序java层接收第二推送视频地址信息，更新视频地址，生成第三播放网页。浏览器内核加载第三播放网页，第三播放网页为第二推送视频地址对应生成的播放网页。浏览器内核加载第三播放网页，生成第三播放器实例。播放器通过调用第三播放器实例的接口，开始播放第二推送视频。

第二推送视频播放完成后，播放器发送播放结束的消息给浏览器内核。浏览器内核接收当前页面完成播放的信息或接收到用户返回信息，返回第二播放网页，继续播放第一推送视频。

或接收到用户返回控制信息，返回第二播放网页，继续播放第一推送视频。

第一推送视频播放完成后，播放器发送播放结束的消息给浏览器内核。浏览器内核接收当前页面完成播放的信息或接收到用户返回信息，返回第一播放网页，继续播放接收第一推送视频之前的页面。

在本申请实施例中，还提供了一种外部服务器，用于向机顶盒发送推送视频地址信息。外部服务器设有网管平台，用于向机顶盒发送推送视频地址。

图6为本申请实施例提供的第三种播放随机推送视频信令流程图，根据实际使用场景，为避免多个推荐视频的连续播放，影响用户体验度，本申请提供的另一种播放随机推送视频的方法包括：

IPTV应用程序java层接收第一推送视频地址信息，生成第二播放网页。浏览器内核加载第二播放网页，第二播放网页为第一推送视频地址对应生成的播放网页。

浏览器内核加载第二播放网页，生成第二播放器实例。播放器通过调用第二播放器实例的接口，开始播放第一推送视频。

在第一推送视频播放完成之前，IPTV应用程序java层接收第二推送视频地址信息，通过PlayParams.getConfig获取第二推送视频地址，并把第二推送视频地址通过播放器接口传递给播放器。浏览器内核重新加载第二播放网页，此时的第二播放网页中包含为第二推送视频地址信息。浏览器内核加载当前播放网页，生成第三播放器实例。播放器通过调用第三播放器实例的接口，开始播放第二推送视频。

第二推送视频播放完成后，播放器发送播放结束的消息给浏览器内核。浏览器内核接收当前页面完成播放的信息或接收到用户返回信息，返回第一播放网页。

在本申请中IPTV应用可以为IPTV apk。

本申请公开了一种适用于机顶盒的播放随机推送视频的方法和机顶盒，该方法包括：网管应用接收第一推送视频地址，并将所述第一推送视频地址推送至应用程序java层；所述应用程序java层根据所述第一推送视频地址生成第二播放网页；所述浏览器内核加载所述第二播放网页，生成第二播放实例，获取所述第一推送视频地址。所述浏览器内核将所述第一推送视频地址通过加载接口传递至播放器；所述加载接口IPTV规范接口一致。所述播放器根据所述加载接口开始播放第一推送视频，所述第一推送视频为所述第一推送视频地址对应的视频。本申请中播放网页的加载接口与IPTV规范中的视频加载接口一致，不需要播放器再另外添加接口，统一了播放器加载接口，降低出错概率。同时将视频地址转换成了浏览器内核加载页面，没有打断浏览器内核操作，也不影响浏览器内核后续操作。将原来的视频播放过程改成了浏览器内核加载页面，在页面中对于播放的操作更容易实现，且逻辑更清楚独立。

由于以上实施方式均是在其他方式之上引用结合进行说明，不同实施例之间均具有相同的部分，本说明书中各个实施例之间相同、相似的部分互相参见即可。在此不再详细阐述。

需要说明的是，在本说明书中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或暗示这些实体或操作之间存在任何这种实际的关系或顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的电路结构、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种电路结构、物品或者设备所固有的要素。在没有更多限制的情况下，有语句“包括一个……”限定的要素，并不排除在包括所述要素的电路结构、物品或者设备中还存在另外的相同要素。

本领域技术人员在考虑说明书及实践本申请的公开后，将容易想到本申请的其他实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由权利要求的内容指出。

以上所述的本申请实施方式并不构成对本申请保护范围的限定。