本申请涉及视频播放技术领域，尤其涉及一种播放ts流的方法及装置。
背景技术：
在视频播放、直播类app中，视频处理方式包括硬解码和软解码，其中，软解码是一种通过软件让cpu来对视频进行解码处理，就是通过cpu来运行视频编解码代码的方式；硬解码是一种将原来全部交由cpu来处理的视频数据的一部分交由gpu来做的方式，而gpu的并行运算能力要远远高于cpu，这样可以大大的降低对cpu的负载，cpu的占用率较低了之后就可以同时运行一些其他的程序了。因此，视频硬解与软解相比，具有更流畅、更省电的优势。
nativemedia是目前常用的一种硬解码方式，然而它的稳定性问题一直困扰着大家，其主要表现在在使用过程，突然出现本机崩溃，并且其只能解码h.264+aac这种常见且标准的格式的视音频类型组合，而对于其它的解码格式，比如mpeg2或ac3等格式就无能为力，而且，播放注入流数据时，针对h.264的码流来说，必须分析到sps和pps数据标识块时，即常说的关键i帧数据时才可以开始注入，否则解码出视频画面需要等很久。因此，这些问题极大地影响影响到了用户体验，需要提供一种新的方式解决这些问题。
技术实现要素：
有鉴于此，本申请提供了一种播放ts流的方法及装置，以克服现有技术中视频硬解容易出现本机崩溃，且适用范围窄，解码过程复杂、速度慢，影响用户体验的问题。
为实现上述目的，本申请提供了以下技术方案：
一种播放ts流的方法，该方法包括：
接收待播放的ts流；
解析所述ts流对应的url参数，得到节目信息；
将所述节目信息以及所述ts流通过sdkapi接口导入demux硬件中，以进行音视频分离处理；
将进行音视频分离处理后的信息导入decode硬件中进行音视频解码处理；
将进行音视频解码处理后的信息进行播放。
优选的，所述接收待播放的ts流包括：
解析所述ts流对应的url参数，以确定组播请求类型并创建组播接收通道；
创建双向域名套接字，并将所述双向域名套接字的写入端加入到第一io多路复用器；
待所述ts流到达时，将所述ts流缓存至所述双向域名套接字分配的共享缓冲区。
优选的，所述将所述节目信息以及所述ts流通过sdkapi接口导入demux硬件中之前，还包括：
将所述双向域名套接字的读取端加入到第二io多路复用器，以监控所述ts流的到达。
优选的，所述解析所述ts流对应的url参数，以确定组播请求类型并创建组播接收通道包括：
根据所述url参数的前缀确定组播请求类型，根据所述url参数的组播地址和端口创建组播接收通道。
优选的，还包括：当发生故障时，停止对解码后的信息的播放，并释放播放资源。
一种播放ts流的装置，该装置包括：
接收单元，用于接收待播放的ts流；
解析单元，用于解析所述ts流对应的url参数，得到节目信息；
分离单元，用于将所述节目信息以及所述ts流通过sdkapi接口导入demux硬件中，以进行音视频分离处理；
解码单元，用于将进行音视频分离处理后的信息导入decode硬件中进行音视频解码处理；
播放单元，用于将进行音视频解码处理后的信息进行播放。
优选的，所述接收单元包括：
子解析单元，用于解析所述ts流对应的url参数，以确定组播请求类型并创建组播接收通道；
创建单元，用于创建双向域名套接字，并将所述双向域名套接字的写入端加入到第一io多路复用器；
缓存单元，用于待所述ts流到达时，将所述ts流缓存至所述双向域名套接字分配的共享缓冲区。
优选的，还包括：
监控单元，用于将所述双向域名套接字的读取端加入到第二io多路复用器，以监控所述ts流的到达。
优选的，所述子解析单元具体用于根据所述url参数的前缀确定组播请求类型，根据所述url参数的组播地址和端口创建组播接收通道。
优选的，还包括：
释放单元，用于当发生故障时，停止对解码后的信息的播放，并释放播放资源。
由以上技术方案可知，本申请提供的该播放ts流的方法，解析ts流对应的url参数，得到节目信息，直接通过url传递完整的节目信息，避免了通过解析ts流得到节目信息，从而了节省时间；利用sdkapi接口直接在应用中实现ts流的注入并播放，充分利用接口高效率及能够支持较多的解码类型、高稳定性等便利性特点，从而快速解码多种媒体格式并成功播放出图像。本申请提供的该方案能够实现快速的组播流数据播放，快速的播放显示出音视频画面，且能够解码多种媒体格式，提高了用户体验。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本申请实施例一提供的一种播放ts流的方法的流程图；
图2为本申请实施例二提供的一种播放ts流的方法的流程图；
图3为本申请实施例二提供的一种接收待播放的ts流的方法的流程图；
图4为本申请实施例三提供的一种播放ts流的装置的结构示意图；
图5为本申请实施例四提供的一种播放ts流的装置的结构示意图；
图6为本申请实施例四提供的一种接收单元的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
为克服现有技术中视频硬解容易出现本机崩溃，且适用范围窄，解码过程复杂、速度慢，影响用户体验的问题，本申请提供了一种快速播放ts流的方法及装置，具体方案如下所述：
实施例一
本申请实施例一提供了一种播放ts流的方法，如图1所示，图1为本申请实施例一提供的一种播放ts流的方法的流程图，该方法包括：
s101：接收待播放的ts流；
s102：解析ts流对应的url参数，得到节目信息；
具体的，在本申请中，根据待播放的ts流所对应的url(uniformresourcelocator，统一资源定位符)参数，解析出音视频参数，格式如下："program://19？audio_stream_pid＝257&audio_stream_type＝audio_aac&video_stream_pid＝256&video_stream_type＝video_h264&pcr_stream_pid＝256"，根据格式解析出来的就是当前节目的音视频处。
本申请直接通过url传递完整的节目信息，避免了通过解析ts流得到节目信息，从而了节省时间。
s103：将节目信息以及ts流通过sdkapi接口导入demux硬件中，以进行音视频分离处理；
利用sdkapi接口直接在应用中实现ts流的注入并播放，充分利用接口高效率及能够支持较多的解码类型、高稳定性等便利性特点，从而快速解码多种媒体格式并成功播放出图像。
s104：将进行音视频分离处理后的信息导入decode硬件中进行音视频解码处理；
s105：将进行音视频解码处理后的信息进行播放。
由以上技术方案可知，本申请实施例一提供的该播放ts流的方法，解析ts流对应的url参数，得到节目信息，直接通过url传递完整的节目信息，避免了通过解析ts流得到节目信息，从而了节省时间；利用sdkapi接口直接在应用中实现ts流的注入并播放，充分利用接口高效率及能够支持较多的解码类型、高稳定性等便利性特点，从而快速解码多种媒体格式并成功播放出图像。本申请提供的该方案能够实现快速的组播流数据播放，快速的播放显示出音视频画面，且能够解码多种媒体格式，提供了用户体验。
实施例二
在实施例一的基础上，本申请实施例二提供了一种更具体的播放ts流的方法，如图2所示，图2为本申请实施例二提供的一种播放ts流的方法的流程图，该方法包括：
s101：接收待播放的ts流；
具体的，如图3所示，图3为本申请实施例二提供的一种接收待播放的ts流的方法的流程图，该方法包括：
s1011：解析ts流对应的url参数，以确定组播请求类型并创建组播接收通道；
该步骤具体可包括：根据url参数的前缀确定组播请求类型，根据url参数的组播地址和端口创建组播接收通道。
具体的，在本申请中，根据播放的url参数，如udp://224.0.0.1:8000/media/play/1.ts？，首先分析其前缀“udp://”确认这是一个组播请求类型。然后根据组播地址(例如上述参数中的“224.0.0.1”)和端口(例如上述参数中组播地址后的“8000”)创建组播接收通道。问号？号的内容传递到播放模块中。
需要说明的是，在本申请中，根据组播地址和端口创建组播接收通道的过程包括：首先建立一个sock_dgram类型的套接字，然后根据指定的端口绑定本地接收网卡的地址，再将组播地址加入到组播组中，循环接收组播数据。
s1012：创建双向域名套接字，并将双向域名套接字的写入端加入到第一io多路复用器；
本申请中，双向的域名套接字是用于与播放模块进行数据交互的通道。具体的，创建过程可利用socketpiar创建的一对相互连接的socket，任意一段既可以做发送，也可以做接受端。所有每个socket描述符中应该有两个buf。一个为发送buf，一个为接受buf。
创建该双向域名套接字的优势包括：可以利用套接字的特有属性，类似一个循环缓冲区，并可以调整发送和接收的缓冲区大小；套接字是一个文件句柄，可以加入io多路复用器，这里将写入端加入到io多路复用，从而实现“等待消息准备好”的被动唤醒，避免主动轮询浪费cpu时间；数据接收模块获取套接字写入端的文件句柄、播放模块获取套接字读取端。通过套接字的监控，数据接收模块和播放模块这两个模块可以完全独立、减小模块间的耦合。
s1013：待ts流到达时，将ts流缓存至双向域名套接字分配的共享缓冲区。
需要说明的是，本申请中，步骤s101及其相关附属步骤都是由数据接收模块完成，后续步骤由播放模块完成。
s102：解析ts流对应的url参数，得到节目信息；
具体的，根据ts流对应的uri参数，解析出音视频参数，格式如下："program://19？audio_stream_pid＝257&audio_stream_type＝audio_aac&video_stream_pid＝256&video_stream_type＝video_h264&pcr_stream_pid＝256"、根据格式解析出来的就是当前节目的音视频处。
本申请直接通过url传递完整的节目信息，避免了通过解析ts流得到节目信息，从而了节省时间。
根据获取的节目信息启动播放模块中的播放器，该播放器可为基于应用app内开发、利用java实现播放呈现及控制的视图，并实现组播数据接收与发送、最后通过c语言编程实现的一个ts流的播放器，以下简称tsplayer。
tsplayer直接调用机顶盒的sdkapi接口实现，一般机顶盒上软件可划分为三层：应用层指安装的各种应用软件，框架层即将资源的管理及功能逻辑封装成给方便应用层调用的接口层，sdk层指硬件机顶盒厂家实现的一层，用于实现驱动、方便给框架层调用的接口层，这一层接口一般称作sdkapi层。本申请充分利用sdkapi接口的便利性特点，封装了一套播放的基本接口，如创建、开始、数据注入、音量调整、视频大小设置、停止、销毁等。
在本实施例中，还可以包括，但非必须包括步骤s103：将双向域名套接字的读取端加入到第二io多路复用器，以监控ts流的到达；
具体的，将套接字的读取端加入到io多路复用中，监控等待数据的到达通知其读取数据，从而实现“等待消息准备好”的被动唤醒，避免主动轮询浪费cpu时间。
s104：将节目信息以及ts流通过sdkapi接口导入demux硬件中，以进行音视频分离处理；
检测出数据到达则唤醒数据读取处理流程，利用sdkapi接口直接在应用中实现ts流的注入并播放，充分利用接口高效率及能够支持较多的解码类型、高稳定性等便利性特点，从而快速解码多种媒体格式并成功播放出图像。
s105：将进行音视频分离处理后的信息导入decode硬件中进行音视频解码处理；
s106：将进行音视频解码处理后的信息进行播放；
s107：当发生故障时，停止对解码后的信息的播放，并释放播放资源。
本申请实施例二提供的该播放ts流的方法，利用平台sdkapi支持的丰富音视频解码格式、快速并且稳定的实现了一套高效率的组播源的ts流数据播放功能。直接通过url传递完整的节目信息，避免了通过解析ts流得到节目信息，从而了节省时间；利用sdkapi接口直接在应用中实现ts流的注入并播放，充分利用接口高效率及能够支持较多的解码类型、高稳定性等便利性特点，从而快速解码多种媒体格式并成功播放出图像。本申请提供的该方案能够实现快速的组播流数据播放，快速的播放显示出音视频画面，且能够解码多种媒体格式，提高了用户体验。
实施例三
在实施例一的基础上，本申请实施例三提供了一种播放ts流的装置，如图4所示，图4为本申请实施例三提供的一种播放ts流的装置的结构示意图。该装置包括：
接收单元201，用于接收待播放的ts流；
解析单元202，用于解析ts流对应的url参数，得到节目信息；
分离单元203，用于将节目信息以及ts流通过sdkapi接口导入demux硬件中，以进行音视频分离处理；
解码单元204，用于将进行音视频分离处理后的信息导入decode硬件中进行音视频解码处理；
播放单元205，用于将进行音视频解码处理后的信息进行播放。
由以上技术方案可知，本申请实施例三提供的该播放ts流的装置，接通过url传递完整的节目信息，避免了通过解析ts流得到节目信息，从而了节省时间；利用sdkapi接口直接在应用中实现ts流的注入并播放，充分利用接口高效率及能够支持较多的解码类型、高稳定性等便利性特点，从而快速解码多种媒体格式并成功播放出图像。本申请提供的该方案能够实现快速的组播流数据播放，快速的播放显示出音视频画面，且能够解码多种媒体格式，提高了用户体验。
实施例四
本申请实施例四提供了一种更具体的播放ts流的装置，如图5所示，图5为本申请实施例四提供的一种播放ts流的装置的结构示意图。该装置包括：
接收单元201，用于接收待播放的ts流；
如图6所示，图6为本申请实施例四提供的一种接收单元的结构示意图。该接收单元包括：
子解析单元2011，用于解析ts流对应的url参数，以确定组播请求类型并创建组播接收通道；
该子解析单元具体用于根据url参数的前缀确定组播请求类型，根据url参数的组播地址和端口创建组播接收通道。
创建单元2012，用于创建双向域名套接字，并将双向域名套接字的写入端加入到第一io多路复用器；
将写入端加入到io多路复用，从而实现“等待消息准备好”的被动唤醒，避免主动轮询浪费cpu时间。
缓存单元2013，用于待ts流到达时，将ts流缓存至双向域名套接字分配的共享缓冲区。
需要说明的是，接收单元以及附属的几个子单元均属于数据接收模块，即用于完成数据接收的功能。
解析单元202，用于解析ts流对应的url参数，得到节目信息；
本申请直接通过url传递完整的节目信息，避免了通过解析ts流得到节目信息，从而了节省时间。
在本实施中，还可以包括，但非必须包括：监控单元203，用于将双向域名套接字的读取端加入到第二io多路复用器，以监控ts流的到达。
具体的，将套接字的读取端加入到io多路复用中，监控等待数据的到达通知其读取数据，从而实现“等待消息准备好”的被动唤醒，避免主动轮询浪费cpu时间。
分离单元204，用于将节目信息以及ts流通过sdkapi接口导入demux硬件中，以进行音视频分离处理；
解码单元205，用于将进行音视频分离处理后的信息导入decode硬件中进行音视频解码处理；
播放单元206，用于将进行音视频解码处理后的信息进行播放。
释放单元207，用于当发生故障时，停止对解码后的信息的播放，并释放播放资源。
由以上技术方案可知，本申请实施例四提供的该播放ts流的装置，利用平台sdkapi支持的丰富音视频解码格式、快速并且稳定的实现了一套高效率的组播源的ts流数据播放功能。直接通过url传递完整的节目信息，避免了通过解析ts流得到节目信息，从而了节省时间；利用sdkapi接口直接在应用中实现ts流的注入并播放，充分利用接口高效率及能够支持较多的解码类型、高稳定性等便利性特点，从而快速解码多种媒体格式并成功播放出图像。本申请提供的该方案能够实现快速的组播流数据播放，快速的播放显示出音视频画面，且能够解码多种媒体格式，提高了用户体验。
需要说明的是，本申请各实施例之间相同或相似的部分可相互参考，在本申请中不再赘述。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。