一种嵌入式环境下音视频解码的方法及装置制造方法
【专利摘要】本申请公开了一种嵌入式环境下音视频解码的方法，包括：A.从外界获取音视频流数据；B.对所述音视频流数据进行解码；所述解码包括：若所述音视频流数据中存在硬件接口解码不支持的视频容器，对所述视频容器进行软件转码为硬件接口支持的视频容器；若所述音视频流数据中存在硬件接口解码不支持的音频编码，对所述音频编码进行软件转码为硬件接口能支持播放的编码格式；C.将软解码后的音视频内容推送给硬件接口进行音视频播放。本申请还公开了嵌入式环境下音视频解码的装置。本申请技术方案在保留原有硬件接口优点上，支持更多的视频容器和音频编码。
【专利说明】—种嵌入式环境下音视频解码的方法及装置
【技术领域】
[0001]本申请涉及音视频编解码【技术领域】，尤其涉及一种嵌入式环境下视频软解码的方法及装置。
【背景技术】
[0002]在现有技术中，基于底层芯片的视频播放有俩套机制，分别通过playback接口和playpump接口这两种硬件接口实现。
[0003]通过playpump接口进行视频播放，使用较为方便，其优点是播放视频时可以以视频缓存为载体进行播放，而不需要完整的视频文件，使用灵活；其缺点是对于支持视频容器支持较少，对于视频播放过程异常错误处理薄弱的问题，从而导致播放视频的过程程序卡死和崩溃。playback接口针对上述playpump接口的缺点加以改进。playback接口在playpump接口的基础上增加了很多功能，比如找I巾贞，播放MP4视频文件等。但是playback播放视频时以文件作为载体，对于流媒体支持较为薄弱，从而不利于针对应用进行二次开发。
[0004]此外,playback接口和playpump接口基于硬件解码,都存在一些比较流行的视频容器和音频编码不支持的情况。而且，现有的播放过程都是基于单线程处理，如果网络状况不佳会出现卡顿现象，严重影响用户体验。
【发明内容】
[0005]本申请提供了一种嵌入式环境下视频软解码的方法及装置，在保留硬件接口优点上，支持更多的视频容器和音频编码。
[0006]本申请实施例提供的一种嵌入式环境下音视频转码的方法，其特征在于，包括以下步骤:
[0007]获取音视频流数据，对所述音视频流数据进行转码；所述转码包括:若所述音视频流数据中存在硬件接口解码不支持的视频容器，对所述视频容器进行软件转码为硬件接口支持的视频容器；若所述音视频流数据中存在硬件接口解码不支持的音频编码，对所述音频编码进行软件转码为硬件接口能支持播放的编码格式。
[0008]本申请实施例还提供一种嵌入式环境下音视频解码的方法，包括:
[0009]A、从外界获取音视频流数据；
[0010]B、对所述音视频流数据进行软解码；所述软解码包括:若所述音视频流数据中存在硬件接口解码不支持的视频容器，对所述视频容器进行软件转码为硬件接口支持的视频容器；若所述音视频流数据中存在硬件接口解码不支持的音频编码，对所述音频编码进行软件转码为硬件接口能支持播放的编码格式；
[0011]C、将软解码后的音视频内容推送给硬件接口进行音视频播放。
[0012]较佳地，步骤C进一步包括:
[0013]C1、在第一预设时长内，获取软解码后的音视频内容中的显示时间戳；若所述显示时间戳在第一预设时长内未发生变化，停止音视频播放；
[0014]C2、获取软件解码得出视频理论播放时间T1以及硬件解码视频实际播放时间T2 ；将T1时间和T2对比，若两者之差的绝对值大于预先设定的阈值，标记该音视频流数据为错误视频，否则，标记该音视频流数据为可以正常播放视频。
[0015]较佳地，步骤C进一步包括:软解码后的音视频文件推送到硬件接口的播放通道缓存之后，若在第二预设时长内这段缓存空间未被消耗掉，则清空播放通道缓存中的内容。
[0016]较佳地，所述第一预设时长为500毫秒至1秒。
[0017]较佳地，所述步骤A、步骤B和步骤C分别通过一个独立的线程实现，且所述三个线程并行运行。
[0018]较佳地，所述步骤A采用接收线程实现，所述步骤A包括:
[0019]步骤201:检测是否存在视频文件的url地址解析，若是，执行步骤202，否则转至步骤205 ；
[0020]步骤202:确定视频文件的协议，并判断视频文件是否读取到末尾，若是，返回步骤201，否则，执行步骤203 ；
[0021]步骤203:读取视频文件数据到文件缓冲区中；
[0022]步骤204:判断文件缓冲区可写容量是否大于临时视频文件长度，若是，执行步骤206，否则执行步骤205 ；
[0023]步骤205:接收线程休眠；当文件还未读完，且文件缓冲区可写容量是否大于临时视频文件长度，接收线程唤醒，转至步骤201 ；
[0024]步骤206:读取等于临时视频文件长度的视频文件数据，将其写入到文件缓冲区中；采用软解技术，对所读取的视频文件数据中的视频流和音频流信息进行分析和检测，得出视频流和音频流的编号和具体的编码信息；
[0025]步骤207:将文件缓冲区可写容量减去临时视频文件长度，作为更新后的文件缓冲区可写容量，然后返回步骤201。
[0026]较佳地，所述步骤B采用转码线程实现，步骤B包括:
[0027]步骤301:判断转码缓冲区可写容量是否大于临时转码长度，若是，执行步骤302，否则执行步骤303 ;临时转码长度为一固定的值，小于等于文件输入缓冲区可读容量并且同时小于转码缓冲区可写容量取值；
[0028]步骤302:判断文件缓冲区是否为空，若是执行步骤303，否则执行步骤204 ；
[0029]步骤303:转码线程休眠；如果转码缓冲区可写容量大于临时转码长度，则唤醒该线程返回步骤301 ；
[0030]步骤304:从文件缓冲区读取小于临时转码长度的视频文件数据包含的音视频数据编码；
[0031]步骤305:对所读取的音视频数据编码进行软件解码，如果成功，执行步骤306，否则转至步骤307 ；
[0032]步骤306:将转码后的数据写入转码缓冲区，同时将转码缓冲区可写容量减去转码后的文件长度，作为更新后的转码缓冲区可写容量；
[0033]步骤307:文件缓冲区清除被读取的临时转码长度的数据，同时增加文件缓冲区可写容量，增加幅度等于临时转码长度。然后返回步骤301。
[0034]较佳地，所述步骤C采用播放线程实现，步骤C包括:
[0035]步骤401:判断转码缓冲区是否为空，若是执行步骤402，否则执行步骤403 ；
[0036]步骤402:将播放线程休眠，如果判断转码缓冲区是否为空则唤醒该线程返回步骤 401 ；
[0037]步骤403:从转码缓冲区读取播放长度的转码数据推送到底层播放器；所述播放长度小于转码后缓冲区已有数据长度，同时小于底层所能容纳数据；
[0038]步骤404:底层芯片对收到的转码数据进行音视频播放；
[0039]步骤405:转码缓冲区可用容量增加,增加幅度为播放长度,然后返回步骤401。
[0040]本申请实施例还提供了一种嵌入式环境下音视频解码的装置，包括接收模块、转码模块、和播放模块；
[0041]所述接收模块用于从外界获取音视频流数据；
[0042]转码模块所述转码模块用于对所述音视频流数据进行解码；所述解码包括:若所述音视频流数据中存在硬件接口解码不支持的视频容器，对所述视频容器进行软件转码为硬件接口支持的视频容器；若所述音视频流数据中存在硬件接口解码不支持的音频编码，对所述音频编码进行软件转码为硬件接口能支持播放的编码格式；
[0043]所述播放模块用于将软解码后的音视频内容推送给硬件接口进行音视频播放。
[0044]较佳地，所述播放模块进一步包括:
[0045]第一判断单元，用于在第一预设时长内，获取软解码后的音视频文件内容中的显示时间戳；若所述显示时间戳在第一预设时长内未发生变化，停止音视频播放；
[0046]第二判断单元，用于在停止音视频播放后，获取软件解码得出视频理论播放时间T1以及硬件解码视频实际播放时间T2 ;将T1时间和T2对比，若两者之差的绝对值大于预先设定的阈值，标记该音视频流数据为错误视频，否则，标记该音视频流数据为可以正常播放视频。
[0047]较佳地，所述播放模块进一步包括:
[0048]清空处理单元，用于软解码后的音视频文件推送到硬件接口的播放通道缓存之后，若在第二预设时长内这段缓存空间未被消耗掉，则清空播放通道缓存中的内容。
[0049]较佳地，所述第一预设时长为500毫秒至1秒。
[0050]较佳地，所述接收模块，转码模块和播放模块分别通过一个独立的线程实现，且所述三个线程并行运行。
[0051]较佳地，所述接收模块采用接收线程实现，所述接收模块的运行流程包括:
[0052]步骤201:检测是否存在视频文件的url地址解析，若是，执行步骤202，否则转至步骤205 ；
[0053]步骤202:确定视频文件的协议，并判断视频文件是否读取到末尾，若是，返回步骤201，否则，执行步骤203 ；
[0054]步骤203:读取视频文件数据到文件缓冲区中；
[0055]步骤204:判断文件缓冲区可写容量是否大于临时视频文件长度，若是，执行步骤206，否则执行步骤205 ；
[0056]步骤205:接收线程休眠；当文件还未读完，且文件缓冲区可写容量是否大于临时视频文件长度，接收线程唤醒，转至步骤201 ；
[0057]步骤206:读取等于临时视频文件长度的视频文件数据，将其写入到文件缓冲区中；采用软解技术，对所读取的视频文件数据中的视频流和音频流信息进行分析和检测，得出视频流和音频流的编号和具体的编码信息；
[0058]步骤207:将文件缓冲区可写容量减去临时视频文件长度，作为更新后的文件缓冲区可写容量，然后返回步骤201。
[0059]较佳地，所述转码模块采用转码线程实现，转码模块的运行流程包括:
[0060]步骤301:判断转码缓冲区可写容量是否大于临时转码长度，若是，执行步骤302，否则执行步骤303 ;临时转码长度为一固定的值，小于等于文件输入缓冲区可读容量并且同时小于转码缓冲区可写容量取值；
[0061]步骤302:判断文件缓冲区是否为空，若是执行步骤303，否则执行步骤204 ；
[0062]步骤303:转码线程休眠；如果转码缓冲区可写容量大于临时转码长度，则唤醒转码线程返回步骤301 ；
[0063]步骤304:从文件缓冲区读取小于临时转码长度的视频文件数据包含的音视频数据编码；
[0064]步骤305:对所读取的音视频数据编码进行软件解码，如果成功，执行步骤306，否则转至步骤307 ；
[0065]步骤306:将转码后的数据写入转码缓冲区，同时将转码缓冲区可写容量减去转码后的文件长度，作为更新后的转码缓冲区可写容量；
[0066]步骤307:文件缓冲区清除被读取的临时转码长度的数据，同时增加文件缓冲区可写容量，增加幅度等于临时转码长度。然后返回步骤301。
[0067]较佳地，所述播放模块采用播放线程实现，
[0068]所述播放模块的运行流程包括:
[0069]步骤401:判断转码缓冲区是否为空，若是执行步骤402，否则执行步骤403 ；
[0070]步骤402:将播放线程休眠，如果判断转码缓冲区是否为空则唤醒播放线程返回步骤401 ；
[0071]步骤403:从转码缓冲区读取播放长度的转码数据推送到底层播放器；所述播放长度小于转码后缓冲区已有数据长度，同时小于底层所能容纳数据；
[0072]步骤404:底层芯片对收到的转码数据进行音视频播放；
[0073]步骤405:转码缓冲区可用容量增加，增加幅度为播放长度，然后返回步骤401。
[0074]从以上技术方案可以看出，本申请方案第一步对音视频文件软解，这样做的好处是:将硬件接口不支持的视频容器进行软件解复用为硬件接口支持的视频容器，以及将硬件接口不支持的音频编码进行软件转码为硬件接口能支持播放的编码格式；第二步将经过第一步软件解码后的视频内容推送给硬件接口播放音视频。本申请方案还通过视频播放错误检测恢复机制，对错误音视频可以一定程度的纠错，让音视频继续播放。即使音视频内容在软解无法纠错的情况，也能使程序恢复过来，继续播放下一个视频。本申请方案可以很好地扩展流媒体协议(所述流媒体协议包括但不限于http, udp, rtsp协议等)。此外，本申请实施例采用多线程方式实现，可以使播放视频的过程中更加流畅和稳定。本申请方案可以在保留硬件接口优点上，支持更多的视频容器和音频编码，同时采用视频播放的自动纠错机制和恢复机制，提高播放视频播放流畅性和健壮性。
【专利附图】
【附图说明】
[0075]图1为本申请实施例提供的嵌入式环境下视频软解码的装置的结构示意图；
[0076]图2为本申请实施例给出的接收模块101采用接收线程的运行流程示意图；
[0077]图3为本申请实施例中转码模块103采用转码线程的运行流程示意图；
[0078]图4为本申请实施例中播放模块105采用播放线程的运行流程示意图；
[0079]图5为播放模块105进行错误检测和恢复的处理流程示意图；
[0080]图6为本申请实施例提供的一种嵌入式环境下音视频解码的方法流程示意图。
【具体实施方式】
[0081]针对现有技术中存在的问题，本申请提出了一种视频软解码的解决方案，其中包括了:软解+硬件接口视频播放机制+视频播放错误检测恢复机制。以下实施例以P1 aypump接口为例进行详细阐述。
[0082]本申请实施例提供的嵌入式环境下视频软解码的装置的结构如图1所示，接收模块101用于实现多媒体协议(多种协议)，从外界获取音视频流文件数据并将所述音视频文件数据缓存到文件缓冲区102中。转码模块103从文件缓冲区102中读取音视频文件数据，对硬件接口解码不支持的视频容器进行软件解复用，对硬件接口解码不支持的音频编码进行软件转码，同时将软解后的音视频文件内容推送转码缓冲区104中。播放模块105用于从转码缓冲区105中读取转码后的音视频文件内容，然后再将数据推送给硬件接口进行视频播放。播放模块105还用于在播放视频文件的过程中进行错误检测和并对错误进行恢复。
[0083]为了使播放视频的过程中更加流畅和稳定，本申请另一实施例采用多线程协同工作的方式来实现接收模块101，转码模块103和播放模块105。具体地，用接收(read)线程实现接收模块101,转码(transcoder)线程实现转码模块103,播放(pushdata)_线程实现播放模块105，线程具体协同工作的流程如图2、图3和图4所示。
[0084]图2为本申请实施例给出的接收模块101采用read线程实现流媒体协议接收视频文件内容。所述流媒体协议包括但不限于超文本传输协议(HTTP)，用户数据报协议(UDP, User Datagram Protocol),实时流传输协议(RTSP, Real Time StreamingProtocol)。此外，本申请实施例还支持本地存储音视频。
[0085]本申请实施例中接收模块101采用接收线程的运行流程如图2所示，包括如下步骤:
[0086]步骤201:检测是否存在视频文件的url地址解析，若是，执行步骤202，否则转至步骤205。
[0087]步骤202:确定视频文件的协议，并判断视频文件是否读取到末尾，若是，返回步骤201，否则，执行步骤203。
[0088]步骤203:读取视频文件数据到文件缓冲区中。
[0089]步骤204:判断文件缓冲区可写容量是否大于临时视频文件长度(fileTempSize)，若是，执行步骤206，否则执行步骤205。fileTemSize为一固定的值。
[0090]步骤205:read线程休眠。当文件还未读完，且文件缓冲区可写容量是否大于临时视频文件长度，read线程唤醒，转至步骤201。
[0091]步骤206:读取等于临时视频文件长度的视频文件数据，将其写入到文件缓冲区中。采用(ffmpeg)软解技术，对所读取的视频文件数据中的视频流和音频流信息进行分析和检测，得出视频流和音频流的编号和具体的编码信息。
[0092]步骤207:将文件缓冲区可写容量减去临时视频文件长度，作为更新后的文件缓冲区可写容量，然后返回步骤201。
[0093]本申请实施例中转码模块103采用转码线程的运行流程如图3所示，包括如下步骤:
[0094]步骤301:判断转码缓冲区可写容量是否大于临时转码长度(transTempSize),若是，执行步骤302，否则执行步骤303。transTempSize为一固定的值，小于等于文件输入缓冲区可读容量并且同时小于转码缓冲区可写容量取值。
[0095]步骤302:判断文件缓冲区是否为空，若是执行步骤303，否则执行步骤204。
[0096]步骤303:转码线程休眠。如果转码缓冲区可写容量大于临时转码长度，则唤醒该线程返回步骤301。
[0097]步骤304:从文件缓冲区读取小于临时转码长度的视频文件数据包含的音视频数据编码。
[0098]步骤305:对所读取的音视频数据编码进行软件解码。如果成功，执行步骤306，否则转至步骤307。
[0099]在转码过程中，如果底层芯片硬解码直接支持视频文件所属的视频容器、视频编码以及音频编码，对视频内容进行解复用。如果视频文件的格式或者音频编码不支持的，对音视频文件进行转封装，音频进行转码成硬解码支持的编码格式，同时将视频文件进行转封装，而且将转码后的视频文件进行推送到转码缓冲区中。
[0100]步骤306:将转码后的数据写入转码缓冲区，同时将转码缓冲区可写容量减去转码后的文件长度，作为更新后的转码缓冲区可写容量。
[0101]步骤307:文件缓冲区清除被读取的临时转码长度的数据，同时增加文件缓冲区可写容量，增加幅度等于临时转码长度。然后返回步骤301。
[0102]在转码过程中，对视频进行解复用和对不支持的音频进行解码和编码。这样做可以支持大部分主流的视频格式和编码。在软件解码的过程中可以进一步包括:检测和丢弃视频文件内容的坏帧，同时调整音视频的同步信息，这样可以检测解码错误，以及对视频进行一定程度的纠错。在解码的过程中，如果发生不能读取视频流和音频流数据包等不可恢复的错误，则停止播放视频，并将状态置为等待下一个视频播放的状态。
[0103]本申请实施例中，播放模块105获取软件处理后的视频文件的内容，推送到芯片底层进行播放。播放模块105采用播放线程的运行流程如图4所示，包括如下步骤:
[0104]步骤401:判断转码缓冲区是否为空，若是执行步骤402，否则执行步骤403。
[0105]步骤402:将播放线程休眠。如果判断转码缓冲区是否为空则唤醒该线程返回步骤 401。
[0106]步骤403:从转码缓冲区读取播放长度的转码数据推送到底层播放器。
[0107]播放长度(playsize)为一固定值,playsize小于转码后缓冲区已有数据长度，同时playSize小于底层所能容纳数据。
[0108]步骤404:底层芯片对收到的转码数据进行音视频播放。
[0109]步骤405:转码缓冲区可用容量增加，增加幅度为播放长度。然后返回步骤401。
[0110]本申请实施例中，播放模块105还具备在播放视频文件过程中进行错误检测和恢复机制。经过软解，得到了视频文件中音频和视频的具体信息，根据视频具体组成部分，采用如图5所示流程进行错误检测和恢复，具体包括如下步骤:
[0111]步骤501:在对视频文件进行软解获得音视频文件数据后，推送给硬件接口进行播放，判断播放时长是否小于预设时长(PTS_WAIT_TIME)，其值范围为500毫秒到1秒，若是，执行步骤502，否则执行步骤510。
[0112]步骤502:判断该音视频文件的组成，若包含视频流，执行步骤503，若只包含音频流，执行步骤504。
[0113]步骤503:获取视频流播放的显示时间戳(pts)，然后执行步骤505。
[0114]步骤504:获取音频流播放的pts，然后执行步骤505。
[0115]步骤505:判断pts是否发生了变化，若是，说明在预设时长(PTS_WAIT_HME)内，视频流播放正常，无需进行纠错处理，返回步骤501，否则，执行步骤506。
[0116]步骤506:音视频停止播放。
[0117]步骤507:获取软件解码得出视频理论播放时间T1，硬件解码视频实际播放时间T2。将T1时间和T2对比，若两者之差的绝对值大于预先设定的阈值(Max)，执行步骤508，否则执行步骤509。
[0118]步骤508:标记该视频为错误视频，并结束本流程。
[0119]步骤509:标记该视频为可以正常播放视频，并结束本流程。
[0120]步骤510:音视频文件推送到底层芯片播放通道缓存以后，判断在一定时间(FAILED_TIME)内，这段缓存空间是否被消耗掉，若是，执行步骤501 ;否则，执行步骤511。
[0121]步骤511:清空播放通道缓存中的内容。这样做是为了自动屏蔽视频文件中存在不可恢复坏帧内容，继续播放接下去的视频内容。
[0122]步骤512:统计获取底层芯片播放通道缓存的大小连续为0的计数值。如果视频文件推送成功，COUNT清0。
[0123]步骤513:判断所述计数值是否大于预先设定的阈值(FAILED_C0UNT)，若是，返回步骤502 ;否则，软解下一段视频流并执行上述流程。
[0124]这样做的好处是可以在视频文件内容通过软件解码后视频播放的过程中，硬件接口异常不能播放情况下，能及时检测错误发生的情况。
[0125]本申请实施例还提供了一种嵌入式环境下音视频转码的方法，包括以下步骤:
[0126]获取音视频流数据，对所述音视频流数据进行转码；所述转码包括:若所述音视频流数据中存在硬件接口解码不支持的视频容器，对所述视频容器进行软件转码为硬件接口支持的视频容器；若所述音视频流数据中存在硬件接口解码不支持的音频编码，对所述音频编码进行软件转码为硬件接口能支持播放的编码格式。
[0127]本申请实施例还提供了一种嵌入式环境下音视频解码的方法，如图6所示，包括:
[0128]步骤601:从外界获取音视频流数据；
[0129]步骤602:对所述音视频流数据进行软解码；所述软解码包括:若所述音视频流数据中存在硬件接口解码不支持的视频容器，对所述视频容器进行软件转码为硬件接口支持的视频容器；若所述音视频流数据中存在硬件接口解码不支持的音频编码，对所述音频编码进行软件转码为硬件接口能支持播放的编码格式；
[0130]步骤603:将软解码后的音视频内容推送给硬件接口进行音视频播放。
[0131]根据本申请另一实施例，步骤C进一步包括:
[0132]C1、在第一预设时长内，获取软解码后的音视频内容中的显示时间戳；若所述显示时间戳在第一预设时长内未发生变化，停止音视频播放；
[0133]C2、获取软件解码得出视频理论播放时间T1以及硬件解码视频实际播放时间T2 ；将T1时间和T2对比，若两者之差的绝对值大于预先设定的阈值，标记该音视频流数据为错误视频，否则，标记该音视频流数据为可以正常播放视频。
[0134]根据本申请另一实施例，步骤C进一步包括:软解码后的音视频文件推送到硬件接口的播放通道缓存之后，若在第二预设时长内这段缓存空间未被消耗掉，则清空播放通道缓存中的内容。
[0135]根据本申请另一实施例，所述第一预设时长为500毫秒至1秒。
[0136]根据本申请另一实施例，所述步骤A、步骤B和步骤C分别通过一个独立的线程实现，且所述三个线程并行运行。
[0137]根据本申请另一实施例，所述步骤A采用接收线程实现，如图2所示，所述步骤A包括:
[0138]步骤201:检测是否存在视频文件的url地址解析，若是，执行步骤202，否则转至步骤205 ；
[0139]步骤202:确定视频文件的协议，并判断视频文件是否读取到末尾，若是，返回步骤201，否则，执行步骤203 ；
[0140]步骤203:读取视频文件数据到文件缓冲区中；
[0141]步骤204:判断文件缓冲区可写容量是否大于临时视频文件长度，若是，执行步骤206，否则执行步骤205 ；
[0142]步骤205:接收线程休眠；当文件还未读完，且文件缓冲区可写容量是否大于临时视频文件长度，接收线程唤醒，转至步骤201 ；
[0143]步骤206:读取等于临时视频文件长度的视频文件数据，将其写入到文件缓冲区中；采用软解技术，对所读取的视频文件数据中的视频流和音频流信息进行分析和检测，得出视频流和音频流的编号和具体的编码信息；
[0144]步骤207:将文件缓冲区可写容量减去临时视频文件长度，作为更新后的文件缓冲区可写容量，然后返回步骤201。
[0145]根据本申请另一实施例，所述步骤B采用转码线程实现，如图3所示，步骤B包括:
[0146]步骤301:判断转码缓冲区可写容量是否大于临时转码长度，若是，执行步骤302，否则执行步骤303 ;临时转码长度为一固定的值，小于等于文件输入缓冲区可读容量并且同时小于转码缓冲区可写容量取值；
[0147]步骤302:判断文件缓冲区是否为空，若是执行步骤303，否则执行步骤204 ；
[0148]步骤303:转码线程休眠；如果转码缓冲区可写容量大于临时转码长度，则唤醒该线程返回步骤301 ；
[0149]步骤304:从文件缓冲区读取小于临时转码长度的视频文件数据包含的音视频数据编码；
[0150]步骤305:对所读取的音视频数据编码进行软件解码，如果成功，执行步骤306，否则转至步骤307 ；
[0151]步骤306:将转码后的数据写入转码缓冲区，同时将转码缓冲区可写容量减去转码后的文件长度，作为更新后的转码缓冲区可写容量；
[0152]步骤307:文件缓冲区清除被读取的临时转码长度的数据，同时增加文件缓冲区可写容量，增加幅度等于临时转码长度。然后返回步骤301。
[0153]根据本申请另一实施例，所述步骤C采用播放线程实现。如图4所示，所述步骤C包括:
[0154]步骤401:判断转码缓冲区是否为空，若是执行步骤402，否则执行步骤403 ；
[0155]步骤402:将播放线程休眠，如果判断转码缓冲区是否为空则唤醒该线程返回步骤 401 ；
[0156]步骤403:从转码缓冲区读取播放长度的转码数据推送到底层播放器；所述播放长度小于转码后缓冲区已有数据长度，同时小于底层所能容纳数据；
[0157]步骤404:底层芯片对收到的转码数据进行音视频播放；
[0158]步骤405:转码缓冲区可用容量增加,增加幅度为播放长度,然后返回步骤401。
[0159]以上所述仅为本申请的较佳实施例而已，并不用以限制本申请的保护范围，凡在本申请技术方案的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。
【权利要求】
1.一种嵌入式环境下音视频转码的方法，其特征在于，包括以下步骤: 获取音视频流数据，对所述音视频流数据进行转码；所述转码包括:若所述音视频流数据中存在硬件接口解码不支持的视频容器，对所述视频容器进行软件转码为硬件接口支持的视频容器；若所述音视频流数据中存在硬件接口解码不支持的音频编码，对所述音频编码进行软件转码为硬件接口能支持播放的编码格式。
2.一种嵌入式环境下音视频解码的方法，其特征在于，包括: A、从外界获取音视频流数据； B、对所述音视频流数据进行软解码；所述软解码包括:若所述音视频流数据中存在硬件接口解码不支持的视频容器，对所述视频容器进行软件转码为硬件接口支持的视频容器；若所述音视频流数据中存在硬件接口解码不支持的音频编码，对所述音频编码进行软件转码为硬件接口能支持播放的编码格式； C、将软解码后的音视频内容推送给硬件接口进行音视频播放。
3.根据权利要求2所述的方法，其特征在于，步骤C进一步包括: Cl、在第一预设时长内，获取软解码后的音视频内容中的显示时间戳；若所述显示时间戳在第一预设时长内未发生变化，停止音视频播放； C2、获取软件解码得出视频理论播放时间Tl以及硬件解码视频实际播放时间T2 ;将11时间和T2对比，若两者之差的绝对值大于预先设定的阈值，标记该音视频流数据为错误视频，否则，标记该音视频流数据为可以正常播放视频。
4.根据权利要求3所述的方法，其特征在于，步骤C进一步包括:软解码后的音视频文件推送到硬件接口的播放通道缓存之后，若在第二预设时长内这段缓存空间未被消耗掉，则清空播放通道缓存中的内容。
5.根据权利要求2所述的方法，其特征在于，所述第一预设时长为500毫秒至I秒。
6.根据权利要求2至5任一项所述的方法，其特征在于，所述步骤A、步骤B和步骤C分别通过一个独立的线程实现，且所述三个线程并行运行。
7.根据权利要求6所述的方法，其特征在于，所述步骤A采用接收线程实现，所述步骤A包括: 步骤201:检测是否存在视频文件的url地址解析，若是，执行步骤202，否则转至步骤205 ； 步骤202:确定视频文件的协议，并判断视频文件是否读取到末尾，若是，返回步骤201，否则，执行步骤203 ； 步骤203:读取视频文件数据到文件缓冲区中； 步骤204:判断文件缓冲区可写容量是否大于临时视频文件长度，若是，执行步骤206，否则执行步骤205 ； 步骤205:接收线程休眠；当文件还未读完，且文件缓冲区可写容量是否大于临时视频文件长度，接收线程唤醒，转至步骤201 ； 步骤206:读取等于临时视频文件长度的视频文件数据，将其写入到文件缓冲区中；采用软解技术，对所读取的视频文件数据中的视频流和音频流信息进行分析和检测，得出视频流和音频流的编号和具体的编码信息； 步骤207:将文件缓冲区可写容量减去临时视频文件长度，作为更新后的文件缓冲区可写容量，然后返回步骤201。
8.根据权利要求6所述的方法，其特征在于，所述步骤B采用转码线程实现，步骤B包括: 步骤301:判断转码缓冲区可写容量是否大于临时转码长度，若是，执行步骤302，否则执行步骤303 ;临时转码长度为一固定的值，小于等于文件输入缓冲区可读容量并且同时小于转码缓冲区可写容量取值； 步骤302:判断文件缓冲区是否为空，若是执行步骤303，否则执行步骤204 ； 步骤303:转码线程休眠；如果转码缓冲区可写容量大于临时转码长度，则唤醒该线程返回步骤301 ； 步骤304:从文件缓冲区读取小于临时转码长度的视频文件数据包含的音视频数据编码； 步骤305:对所读取的音视频数据编码进行软件解码，如果成功，执行步骤306，否则转至步骤307 ； 步骤306:将转码后的数据写入转码缓冲区，同时将转码缓冲区可写容量减去转码后的文件长度，作为更新后的转码缓冲区可写容量； 步骤307:文件缓冲区清除被读取的临时转码长度的数据，同时增加文件缓冲区可写容量，增加幅度等于临时转码长度。然后返回步骤301。
9.根据权利要求6所述的方法，其特征在于，所述步骤C采用播放线程实现，步骤C包括: 步骤401:判断转码缓冲区是否为空，若是执行步骤402，否则执行步骤403 ； 步骤402:将播放线程休眠，如果判断转码缓冲区是否为空则唤醒该线程返回步骤401 ； 步骤403:从转码缓冲区读取播放长度的转码数据推送到底层播放器；所述播放长度小于转码后缓冲区已有数据长度，同时小于底层所能容纳数据； 步骤404:底层芯片对收到的转码数据进行音视频播放； 步骤405:转码缓冲区可用容量增加，增加幅度为播放长度，然后返回步骤401。
10.一种嵌入式环境下音视频解码的装置，其特征在于，包括接收模块、转码模块、和播放模块； 所述接收模块用于从外界获取音视频流数据； 转码模块所述转码模块用于对所述音视频流数据进行解码；所述解码包括:若所述音视频流数据中存在硬件接口解码不支持的视频容器，对所述视频容器进行软件转码为硬件接口支持的视频容器；若所述音视频流数据中存在硬件接口解码不支持的音频编码，对所述音频编码进行软件转码为硬件接口能支持播放的编码格式； 所述播放模块用于将软解码后的音视频内容推送给硬件接口进行音视频播放。
11.根据权利要求10所述的装置，其特征在于，所述播放模块进一步包括: 第一判断单元，用于在第一预设时长内，获取软解码后的音视频文件内容中的显示时间戳；若所述显示时间戳在第一预设时长内未发生变化，停止音视频播放； 第二判断单元，用于在停止音视频播放后，获取软件解码得出视频理论播放时间Tl以及硬件解码视频实际播放时间T2 ;将Tl时间和T2对比，若两者之差的绝对值大于预先设定的阈值，标记该音视频流数据为错误视频，否则，标记该音视频流数据为可以正常播放视频。
12.根据权利要求11所述的装置，其特征在于，所述播放模块进一步包括: 清空处理单元，用于软解码后的音视频文件推送到硬件接口的播放通道缓存之后，若在第二预设时长内这段缓存空间未被消耗掉，则清空播放通道缓存中的内容。
13.根据权利要求11所述的方法，其特征在于，所述第一预设时长为500毫秒至I秒。
14.根据权利要求10至13任一项所述的装置，其特征在于，所述接收模块，转码模块和播放模块分别通过一个独立的线程实现，且所述三个线程并行运行。
15.根据权利要求14所述的装置，其特征在于，所述接收模块采用接收线程实现，所述接收模块的运行流程包括: 步骤201:检测是否存在视频文件的url地址解析，若是，执行步骤202，否则转至步骤205 ； 步骤202:确定视频文件的协议，并判断视频文件是否读取到末尾，若是，返回步骤201，否则，执行步骤203 ； 步骤203:读取视频文件数据到文件缓冲区中； 步骤204:判断文件缓冲区可写容量是否大于临时视频文件长度，若是，执行步骤206，否则执行步骤205 ； 步骤205:接收线程休眠；当文件还未读完，且文件缓冲区可写容量是否大于临时视频文件长度，接收线程唤醒，转至步骤201 ； 步骤206:读取等于临时视频文件长度的视频文件数据，将其写入到文件缓冲区中；采用软解技术，对所读取的视频文件数据中的视频流和音频流信息进行分析和检测，得出视频流和音频流的编号和具体的编码信息； 步骤207:将文件缓冲区可写容量减去临时视频文件长度，作为更新后的文件缓冲区可写容量，然后返回步骤201。
16.根据权利要求14所述的装置，其特征在于，所述转码模块采用转码线程实现，转码模块的运行流程包括: 步骤301:判断转码缓冲区可写容量是否大于临时转码长度，若是，执行步骤302，否则执行步骤303 ;临时转码长度为一固定的值，小于等于文件输入缓冲区可读容量并且同时小于转码缓冲区可写容量取值； 步骤302:判断文件缓冲区是否为空，若是执行步骤303，否则执行步骤204 ； 步骤303:转码线程休眠；如果转码缓冲区可写容量大于临时转码长度，则唤醒转码线程返回步骤301 ； 步骤304:从文件缓冲区读取小于临时转码长度的视频文件数据包含的音视频数据编码； 步骤305:对所读取的音视频数据编码进行软件解码，如果成功，执行步骤306，否则转至步骤307 ； 步骤306:将转码后的数据写入转码缓冲区，同时将转码缓冲区可写容量减去转码后的文件长度，作为更新后的转码缓冲区可写容量； 步骤307:文件缓冲区清除被读取的临时转码长度的数据，同时增加文件缓冲区可写容量，增加幅度等于临时转码长度。然后返回步骤301。
17.根据权利要求14所述的装置，其特征在于，所述播放模块采用播放线程实现， 所述播放模块的运行流程包括: 步骤401:判断转码缓冲区是否为空，若是执行步骤402，否则执行步骤403 ； 步骤402:将播放线程休眠，如果判断转码缓冲区是否为空则唤醒播放线程返回步骤.401 ； 步骤403:从转码缓冲区读取播放长度的转码数据推送到底层播放器；所述播放长度小于转码后缓冲区已有数据长度，同时小于底层所能容纳数据； 步骤404:底层芯片对收到的转码数据进行音视频播放； 步骤405:转码缓冲区可用容量增加，增加幅度为播放长度，然后返回步骤401。
【文档编号】H04N21/8547GK104394456SQ201410668321
【公开日】2015年3月4日 申请日期:2014年11月20日 优先权日:2014年11月20日
【发明者】袁嘉晟, 梁文森, 陈旭孟 申请人:福建星网视易信息系统有限公司