CN103841453B - Iptv非智能机顶盒实现ott播放的方法 - Google Patents

Abstract

本发明公开了一种IPTV非智能机顶盒实现OTT播放的方法，包括以下步骤：在非智能机顶盒上创建2个网络设备；通过所述2个网络设备分别获取互联网网络逻辑平面和IPTV网络逻辑平面的IP地址，然后根据网络规划重新设置策略路由表；不同应用根据所述策略路由表操作各自所需网络逻辑平面对应的网络设备，实现IPTV播放、OTT播放或二者之间的切换。本发明，在传统非智能IPTV机顶盒上增添OTT互联网播放服务，能够使IPTV机顶盒在家庭中提供更丰富的媒体资源，给用户更多更好的体验和享受，而且本发明基于传统非智能Linux机顶盒通过软件升级即可实现功能，可以较大程度的减少运营商和用户的成本投入。

Description

IPTV非智能机顶盒实现OTT播放的方法

技术领域

本发明涉及IPTV，具体涉及IPTV非智能机顶盒实现OTT播放的方法及装置。

背景技术

IPTV，即交互式网络电视，是一种利用宽带有线电视网,集互联网、多媒体、通讯等多种技术于一体，向家庭用户提供包括数字电视在内的多种交互式服务的技术。网络机顶盒+普通电视机的方式可以使用户在家中享受IPTV服务。它能够很好地适应当今网络飞速发展的趋势，充分有效地利用网络资源。IPTV既不同于传统的模拟式有线电视，也不同于经典的数字电视。因为,传统的和经典的数字电视都具有频分制、定时、单向广播等特点，尽管经典的数字电视相对于模拟电视有许多技术革新，但只是信号形式的改变;而没有触及媒体内容的传播方式。IPTV能够给用户提供点播、时移等更多的播放方式，同时也支持图片浏览、音视频播放等多种能力。目前也是电信主推的宽带电信业务之一。IPTV机顶盒经过了多年的发展，已经步入智能化时代，配备了安卓操作系统的IPTV智能机顶盒已经占据了高端领域，而中低端领域，目前仍以配备嵌入式Linux系统的非智能IPTV机顶盒为主流。

OTT，是通信行业非常流行的一个词汇，这个词汇来源于篮球等体育运动，是“过顶传球”之意，指的是球类运动员(player)在他们头之上来回传送而达到目的地。即互联网公司越过运营商，发展基于开放互联网的各种视频及数据服务业务，强调服务与物理网络的无关性。随着广电总局181文件出台后，中国式OTT合法化，促进了新媒体和互联网电视机顶盒等电 子消费品的紧密结合，为互联网电视机顶盒盒产业发展又提供新引擎。互联网将成为IPTV和VOD现有内容的有力补充，不仅丰富业务，同时也是更好满足用户对于娱乐文化需求的矛盾，从而让进一步提高IPTV和VOD在用户中的业务粘稠性和提升ARPU值。

电信运营商的IPTV和有线网络运营商的数字电视都属于传统电视服务的范围，两者都是视频内容的传输渠道，提供电视直播和点播，其共同面临的挑战是来自互联网上视频服务，也即在线视频服务，通过公共互联网向电视机屏幕、电脑屏幕、手机屏幕以及各种尺寸的PAD屏幕提供的视频服务。多屏分发的在线视频服务实现了看电视以人为中心，实现随时随地看电视，通过社交网络看自己想看的电视。VOD和IPTV运营商在OTT上实现跨越才是真正的三网融合视频业务。但是，非智能IPTV机顶盒在对接OTT服务商的过程中，主要遇到了以下三个方面的难点：

a）IPTV服务网络为保障服务质量，虽然采用的是IP传输技术，但在组网上与互联网采用了技术手段进行分隔，分为了多个逻辑平面，要支持OTT服务，就要求机顶盒增加跨网络平面的能力。

b）IPTV业务流媒体的编码和传输，由遵循运营商定制标准的媒体服务器提供，多为rtsp或igmp协议协商。而OTT播放服务商标准目前还不统一，媒体编码和封装格式种类繁多，流媒体保障较弱，协商几乎均基于采用HTTP协议。要支持OTT服务，就要求机顶盒增加HTTP网络播放多种编码、多种封装码流的能力。

c）非智能IPTV机顶盒多数基于嵌入式Linux系统，系统本身不提供媒体播放框架支持，所有播放控制都由程序调用底层驱动直接实现。要与OTT服务融合，实现业务的整合与平滑切换，如何规避硬件资源冲突问题是难点。

由此可见，现有的非智能IPTV机顶盒实现OTT播放存在许多困难。

发明内容

本发明所要解决的是非智能IPTV机顶盒实现OTT播放存在困难的技术问题。

为了解决上述技术问题，本发明所采用的技术方案是提供一种IPTV非智能机顶盒实现OTT播放的方法，包括以下步骤：

在非智能机顶盒上创建2个网络设备；

通过所述2个网络设备分别获取互联网网络逻辑平面和IPTV网络逻辑平面的IP地址，然后根据网络规划重新设置策略路由表；

不同应用根据所述策略路由表操作各自所需网络逻辑平面对应的网络设备，实现IPTV播放、OTT播放或二者之间的切换。

在上述方法中，创建2个网络设备通过以下两种方法之一实现：

同时使用有线和无线双接入创建；

通过设定vlan，在同一个硬件网络设备上虚拟出所述两个网络设备。

在上述方法中，所述网络设备通过DHCP、PPPOE或LAN三种接入方式获取互联网网络逻辑平面和IPTV网络逻辑平面的IP地址，如果通过DHCP或PPPOE等动态获取IP地址的方式接入，则根据策略路由表获取2次IP地址，分别分配给2个所述网络设备，获取地址来源对应互联网网络平面和IPTV网络平面；如果选择LAN方式，则由用户设定对应互联网平面和IPTV平面的IP地址。

在上述方法中，在非智能机顶盒的驱动层上增加统一适配层，利用所述统一适配层对原有的驱动API接口进行封装，同时所述统一适配层作为server模块提供统一的服务，非智能机顶盒上涉及播放操作的模块均作为client，server和client采用消息通信机制实现播放操作，杜绝直接操作原有的驱动API接口。

在上述方法中，每条消息由3部分组成：播放实例序号、操作指令和指令参数体；

播放实例序号由0开始编号，序号上限根据硬件能同时处理播放实例总数决定；

操作指令和对应参数，包含：

资源申请指令，对应参数：媒体信息；

正常播放指令，对应参数：媒体数据；

暂停指令，无参数；

倍速播放指令，对应参数：媒体数据，播放速率；

停止指令，无参数；

资源释放指令，无参数。

在上述方法中，统一适配层实现播放操作的流程如下：

server模块随系统核心进程，在系统启动阶段自动启动，并进入待命状态；

client模块根据业务需要启动，并向server模块发送消息；

server模块收到client发来的消息后，进行排队处理，处理到该消息时，根据消息中的实例序号，操作相应的独立播放实例，若该播放实例处于未创建状态，则创建播放实例。

在上述方法中，基于标准HTTP协议栈和开源FFmpeg库实现播放功能，FFmpeg使用中涉及的libavformat 和libavcodec，libavformat用来处理解析视频文件并将包含在其中的流分离出来，libavcodec处理原始音频和视频流的解码。

在上述方法中，FFmpeg库支持HLS的版本，以支持OTT使用HLS的.m3u8索引文件。

本发明，在传统非智能IPTV机顶盒上增添OTT互联网播放服务，能够使IPTV机顶盒在家庭中提供更丰富的媒体资源，给用户更多更好的体验和享受，而且本发明基于传统非智能Linux机顶盒通过软件升级即可实现功能，可以较大程度的减少运营商和用户的成本投入。

附图说明

图1为本发明提供的方法应用场景示意图；

图2为本发明中获取网络地址的流程图；

图3为本发明中统一的适配层的工作流程图；

图4为本发明中统一的适配层的状态机制示意图。

具体实施方式

下面结合附图对本发明做出详细的说明。

如图1、图2所示，本发明提供的IPTV非智能机顶盒实现OTT播放的方法，包括以下步骤：

步骤S10：在非智能机顶盒上的网络接入部分增加策略路由机制，该策略路由机制作用于2个网络设备，即在非智能机顶盒上创建2个网络设备，以实现策略路由机制。

该步骤需要在接入前完成，创建2个网络设备有两种实现方法：

（1）同时使用有线方式和无线方式，采用双接入的方式实现；

（2）通过设定vlan，在同一个硬件网络设备上虚拟出2个网络设备。

步骤S20：IPTV机顶盒通过上述2个网络设备分别获取互联网网络逻辑平面和IPTV网络逻辑平面的IP地址，即IPTV机顶盒获取接入地址。

IPTV机顶盒支持DHCP、PPPOE、LAN三种接入方式，接入过程中，如果通过DHCP或PPPOE等动态获取IP地址的方式接入，需要根据策略获取2次地址，分别分配给2个设备，获取地址来源对应互联网网络平面和IPTV网络平面；如果选择LAN方式，需要由用户设定对应互联网平面和IPTV平面的IP地址。

步骤S30：获取相应的IP地址后，根据网络规划情况，从运营商网管更新获取最新的策略路由表，若无更新则使用内置策略原始路由表，清除获取地址过程中的路由设置，重新设置策略路由表。

步骤S40：不同应用根据策略路由表操作各自所需网络平面对应的网络设备访问资源。

上述方法中，为解决硬件资源冲突问题，在IPTV机顶盒的驱动（媒体驱动软件）上增加统一的适配层（模块），该统一适配层同时作用于互联网端和IPTV端，用于对原有的驱动API接口进行封装，并作为server模块提供统一的服务。其余涉及播放操作的模块均作为client通过向server发送消息实现播放操作，杜绝直接操作原有的驱动API接口。

server和client采用消息通信机制，每条消息由3部分组成：播放实例序号、操作指令、指令参数体。播放实例序号由0开始编号，序号上限根据硬件能同时处理播放实例总数决定。操作指令和对应参数，包含：

资源申请指令，参数：媒体信息；

正常播放指令，参数：媒体数据；

暂停指令，无参数；

倍速播放指令，参数：媒体数据，播放速率；

停止指令，无参数；

资源释放指令，无参数。

server端采用队列接收一个或多个client发来的消息，消息处理策略是先来先服务。对于每个实例，server端要为其维护单独的状态，根据状态来保障硬件资源不会冲突。

如图3所示，本发明中，统一适配层的工作流程如下：

S41、server模块随系统核心进程，在系统启动阶段自动启动，并进入待命状态。

S42、client模块根据业务需要启动，并向server模块发送消息。

S43、server模块收到client发来的消息后，排队处理。如图4所示，处理细节如下：

根据消息中的实例序号，操作对应的独立的播放实例，此播放实例为 逻辑对象。

收到资源申请指令后，若该播放实例处于未创建状态，则创建播放实例，若已经创建则返回此播放实例。

收到资源释放指令后，若该播放实例已经创建，则先确认播放实例状态，若非停止状态，优先默认执行停止操作。实例在停止状态下后，释放播放实例。若该播放实例未创建，则直接返回。

播放实例创建后，对应消息的处理按照播放状态机进行处理，状态包含：停止状态、播放状态、暂停状态，初始创建状态为停止状态。停止状态，只响应正常播放指令，播放后切换到播放状态。播放状态，响应暂停指令，执行后跳转到暂停状态；响应倍速播放指令，执行后状态不变；响应停止指令。执行后跳转到停止状态。暂停状态，响应正常播放、倍速播放指令，执行后跳转到播放状态；响应停止指令，执行后跳转到停止状态。

最后，添加HTTP播放功能。此部分在本发明中是利用标准HTTP协议栈和开源FFmpeg库，并基于此实现播放功能，使用的方式遵循GPL(GeneralPublicLicense)。FFmpeg使用中涉及的是libavformat和libavcodec，libavformat用来处理解析视频文件并将包含在其中的流分离出来，libavcodec则处理原始音频和视频流的解码。HTTP协议栈部分是由IPTV机顶盒原有浏览器兼任。本发明中实现方式与FFmpeg播放网络文件调用方式类似，涉及修改是替换H.264视频解码，AAC和MP3音频解码，采用机顶盒硬件芯片解码方式，禁用libavcodec默认包含的对应解码方式。这里需要指出的是FFmpeg库，需要选用支持HLS（HTTP Live Stream）的版本，以支持OTT使用HLS的.m3u8索引文件。

下面以在IPTV非智能机顶盒上，由IPTV组播频道切换到OTT，并通过HTTP播放H.264、MP3编码m3u8文件为例，说明本发明的工作过程。

一、启动过程。

此过程需配合现网部署环境。本实施例针对嵌入式Linux启动流程进 行改造，内核支持无线驱动或支持vlan，采用的是同时使用有线和无线的双接入方式，使用有线网络连接原有IPTV网络，使用无线连接OTT网络。

具体执行过程如下：

（1）Linux内核启动，初始化网络硬件。随着Linux内核的启动加载相关驱动，接着检测有线网络连接是否正常，检测无线网络是否有链接。如果没有则提示错误，则要求用户输入搜索无线连接点并输入密码。

（2）获取访问IPTV和OTT所需的网络IP地址。

首先通过无线方式接入互联网平面，接入OTT网络，此过程采用DHCP或静态IP方式完成，完成后设置无线网络设备ra0的IP、子网掩码，同时配置到无线网关GW1的默认路由。

接着接入IPTV网络，沿用IPTV原有的接入方式PPPOE、DHCP或静态IP。三种方式流程不同，但最终都会获取访问IPTV网络平面的IP及有线网关GW2，设置有线网络设备eth0的IP、子网掩码。

（3）重置路由为策略路由。

首先记录上一步中配置到无线网关GW1的默认路由信息，然后清空路由表，配置默认路由指向有线网关GW2，并绑定有线网络。

接着启动IPTV网管程序，从运营商网管更新获取最新的策略路由；若无更新，则沿用设备出厂默认策略路由。

最后再次清空路由表，依据策略路由逐条设置指向IPTV网络的路由条目，默认路由还原为无线网关GW1的默认路由。

（4）启动IPTV播放功能和OTT播放功能，并进入待命状态。

IPTV播放功能保持原有功能不变。

OTT播放功能启动阶段，需要初始化FFmpeg，注册可解析文件类型，注册音视频解码所需的动态链接库。这些解码库中，除IPTV硬件支持的MPEG2、H.264、MP3、AAC等之外其余均沿用FFmpeg指定软解码库，IPTV硬件支持解码的使用硬件SDK提供的响应库进行注册。

（5）不同应用根据策略路由表操作各自所需网络平面对应的网络设备访问资源。

二、播放过程。

由IPTV组播频道切换到OTT为例，此过程涉及原有IPTV播放功能，以及本发明中播放控制方面在驱动之上增加统一的适配层的使用，和HTTP播放功能。

具体执行过程如下：

（1）原有IPTV组播频道退出。

向IPTV平台发Leave Group消息，同时关闭网络数据接收通道，清空播放器应用层缓冲的媒体数据。IPTV播放功能模块作为统一的适配层中的client之一，停止向播放实例发送媒体数据，接着通知server模块将实例切换到停止状态。

（2）进入OTT播放功能。

通过复用原有IPTV中的浏览器功能，采用HTTP方式获取播放m3u8文件的URL，并将此URL传递给内嵌FFmpeg的OTT播放模块。由于策略路由已经设定，此时OTT会自动的访问互联网获取相关内容。

（3）调用FFmpeg。

进入libavformat库，调用注册的HLS处理接口，并继续使用HTTP协议访问URL，获取m3u8列表。

（4）响应数据，先给出m3u8主列表，然后需继续访问具体指示ts流文件的m3u8列表。

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2000000

0.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=3000000

1.m3u8

#EXTM3U

#EXT-X-VERSION:1

#EXT-X-TARGETDURATION:10

#EXT-X-MEDIA-SEQUENCE:0

#EXTINF:10,

0-0-0.hls.ts?HW_PERF=0.ts-300-1.ts,300,0,2206368

#EXTINF:10,

10-0-1.hls.ts?HW_PERF=0.ts-300-1.ts,300,2206368,2738596

…….

#EXT-X-ENDLIST

（5）在FFmpeg注册的HLS处理接口hls.c中，对所得到的m3u8列表进行解析，进一步得到要播放的ts流分片信息。

（6）获得分片信息后，通过HTTP向服务器请求ts分片流。

（7）媒体平台响应数据段，给出具体的ts流数据内容。通过媒体分析工具解析能看到类似如下内容：

Reassembled TCP Segments(8308703bytes):#28005(1448),#28006(1448),……

[Frame:28005,payload:0-1447(1448bytes)]

……

[Frame:35779,payload:8308308-8308702(395bytes)]

（8）获取ts流分片数据，调用libavcodec进行解析。

在解析出视频H.264编码、音频MP3编码后，启动OTT播放部分的client模块，通过与server模块交互，通过IPTV硬件进行解码。具体操作是OTT播放部分，作为client向server模块发送资源申请指令，请求播放实例。音视频PID，设定音视频解码作为参数传递给server模块。 server模块根据自身逻辑协调，反馈可用的播放实例给OTT播放部分。

（9）播放实例获取后，OTT播放部分不停的从码流中提取数据，通过server模块提供的正常播放指令不断的投送，最后硬件解码器根据设置不断的将媒体数据解码输出。

本发明不局限于上述最佳实施方式，任何人应该得知在本发明的启示下作出的结构变化，凡是与本发明具有相同或相近的技术方案，均落入本发明的保护范围之内。

Claims (8)

1.IPTV非智能机顶盒实现OTT播放的方法，其特征在于，包括以下步骤：

在非智能机顶盒上创建2个网络设备；

通过所述2个网络设备分别获取互联网网络逻辑平面和IPTV网络逻辑平面的IP地址，然后根据网络规划重新设置策略路由表；

不同应用根据所述策略路由表操作各自所需网络逻辑平面对应的网络设备，实现IPTV播放、OTT播放或二者之间的切换。

2.如权利要求1所述的方法，其特征在于，创建2个网络设备通过以下两种方法之一实现：

同时使用有线和无线双接入创建；

通过设定vlan，在同一个硬件网络设备上虚拟出所述2个网络设备。

3.如权利要求1所述的方法，其特征在于，所述网络设备通过DHCP、PPPOE或LAN三种接入方式获取互联网网络逻辑平面和IPTV网络逻辑平面的IP地址，如果通过DHCP或PPPOE动态获取IP地址的方式接入，则根据策略路由表获取2次IP地址，分别分配给2个所述网络设备，获取地址来源对应互联网网络平面和IPTV网络平面；如果选择LAN方式，则由用户设定对应互联网平面和IPTV平面的IP地址。

4.如权利要求1所述的方法，其特征在于，在非智能机顶盒的驱动层上增加统一适配层，利用所述统一适配层对原有的驱动API接口进行封装，同时所述统一适配层作为server模块提供统一的服务，非智能机顶盒上涉及播放操作的模块均作为client，server和client采用消息通信机制实现播放操作，杜绝直接操作原有的驱动API接口。

5.如权利要求4所述的方法，其特征在于，每条消息由3部分组成：播放实例序号、操作指令和指令参数体；

播放实例序号由0开始编号，序号上限根据硬件能同时处理播放实例 总数决定；

操作指令和对应参数，包含：

资源申请指令，对应参数：媒体信息；

正常播放指令，对应参数：媒体数据；

暂停指令，无参数；

倍速播放指令，对应参数：媒体数据，播放速率；

停止指令，无参数；

资源释放指令，无参数。

6.如权利要求5所述的方法，其特征在于，统一适配层实现播放操作的流程如下：

server模块随系统核心进程，在系统启动阶段自动启动，并进入待命状态；

client模块根据业务需要启动，并向server模块发送消息；

server模块收到client发来的消息后，进行排队处理，处理到该消息时，根据消息中的实例序号，操作相应的独立播放实例，若该播放实例处于未创建状态，则创建播放实例。

7.如权利要求1所述的方法，其特征在于，基于标准HTTP协议栈和开源FFmpeg库实现播放功能，FFmpeg使用中涉及的libavformat和libavcodec，libavformat用来处理解析视频文件并将包含在其中的流分离出来，libavcodec处理原始音频和视频流的解码。

8.如权利要求7所述的方法，其特征在于，FFmpeg库支持HLS的版本，以支持OTT使用HLS的.m3u8索引文件。