CN103327417A - 一种实时远程音视频的直播方法及其装置 - Google Patents

Abstract

本申请实施例公开了一种实时远程音视频的直播方法。该方法包括：通过浏览器上设置的插件调用音视频采集程序采集音视频数据；将音视频数据进行编码后发送到流媒体服务器；播放器从流媒体服务器上获取音视频数据进行直播。本申请实施例还公开了一种实时远程音视频的直播装置。本申请实施例可以避免安全沙箱的问题。

Description

一种实时远程音视频的直播方法及其装置

技术领域

本申请涉及信息处理技术领域，特别涉及一种实时远程视音频的直播方法及其对应的装置。

背景技术

随着互联网技术和音视频编码技术的发展，实时远程音视频直播得到极大推广。Adobe依托flashplayer技术，推出了其自己的实时远程视音频直播技术：RTMP直播技术。该直播技术在Adobe依托的flashplayer技术基础上，先通过摄像头和麦克风采集音视频数据，然后进行H264编码和AAC编码，再通过RTMP协议将视频和音频数据的封装体发送到流媒体服务器，供本地播放器下载播放。这种直播技术虽然将实时远程音视频直播技术推向一个新的水平，但是，由于flashplayer技术运行在虚拟机上，其存在远程安全沙箱和本地安全沙箱的限制，远程安全沙箱限制使flashplayer在没有配置跨域安全策略的情况下，不能进行跨域访问，本地安全沙箱使flashplayer在本地运行时本地资源和端口等策略受到访问限制，从而导致实时远程音视频的直播受到应用场景的束缚，无法满足用户的需求。此外，flashplayer技术由于还采取阻塞方式的单线程模式运行，使flashplayer不能进行连续的大数据量运算，这限制了实时远程音视频直播功能的拓展。

发明内容

为解决上述技术问题，本申请实施例提供了一种实时远程音视频的直播方法及其对应的装置，以使实时远程音视频的直播摆脱应用场景的限制。

本申请实施例提供的实时远程音视频的直播方法包括：

通过浏览器上设置的插件调用音视频采集程序采集音视频数据；

将音视频数据进行编码后发送到流媒体服务器；

播放器从流媒体服务器上获取音视频数据进行直播。

优选地，在浏览器上注册插件，当插件受到触发时，插件通过Directshow启动采集音视频数据。

进一步优选地，所述插件通过Directshow启动采集音视频数据具体包括：插件通过Directshow的SampleGrabberCB接口启动SampleGrabber采集音视频数据。

优选地，所述将音视频数据进行编码后发送到流媒体服务器具体包括：

采用一个线程对音频数据进行编码，采用一个线程对视频数据进行编码，将编码后的音频数据和视频数据封装后发送到流媒体服务器。

进一步优选地，所述将音视频数据进行编码后发送到流媒体服务器具体为：初始化音频编码器，在AudioEncoderThread线程控制下循环调用DSVideoGraph从SampleGrabber中取出音频帧进行音频编码；初始化视频编码器，在VideoEncoderThread线程控制下循环调用DSAudioGraph从SampleGrabber中取出视频帧进行视频编码，将编码后的音频数据和视频数据通过RtmpThread线程进行循环封装后通过Rtmp协议发送到流媒体服务器。

优选地，所述调用音视频采集程序采集音视频数据具体包括：调用音视频采集程序按照预设采样率采集音频数据，按照预设帧率采集视频数据；

所述将音视频数据进行编码具体包括：采用H264编码器对视频数据进行编码，在对视频数据进行编码之前根据适应预设帧率的原则修改H264编码库；采用AAC编码器对音频数据进行编码，在对音频数据进行编码之前根据适应预设采样率的原则修改AAC编码库。

本申请还提供了一种实时远程音视频的直播装置。该装置包括：采集程序调用单元、音视频数据编码单元和直播单元，其中：

采集程序调用单元，用于通过浏览器上设置的插件调用音视频采集程序采集音视频数据；

音视频数据编码单元，用于对音视频数据进行编码；

直播单元，用于从流媒体服务器上获取音视频数据进行直播。

优选地，所述装置还包括注册单元，用于在浏览器上注册插件；

当插件受到触发时，采集程序调用单元通过插件的Directshow启动采集音视频数据。

进一步优选地，所述采集程序调用单元通过插件的Directshow的SampleGrabberCB接口启动SampleGrabber采集音视频数据。

进一步优选地，所述音视频编码单元包括音频编码子单元、视频编码子单元和音视频数据封装子单元，其中：

所述音频编码子单元采用一个线程对音频数据进行编码；

所述视频编码子单元采用一个线程对视频数据编码；

所述音视频数据封装子单元，用于将编码后的音频数据和视频数据封装后发送到流媒体服务器。

优选地，所述音频编码单元包括H264编码库修改单元和H264编码器、ACC编码库修改单元和ACC编码器以及音视频数据封装单元，其中：

所述H264编码库修改单元，用于在对视频数据进行编码之前根据适应预设帧率的原则修改H264编码库；

所述H264编码器，用于对视频数据进行编码；

所述ACC编码库修改单元，用于在对音频数据进行编码之前根据适应预设采样率的原则修改AAC编码库；

所述ACC编码器，用于对音频数据进行编码；

所述音视频数据封装单元，用于将编码后的音频数据和视频数据封装后发送到流媒体服务器。

本申请实施例通过浏览器上设置的插件调用音视频采集程序采集音视频数据，然后对采集的音视频数据进行编码后发送到流媒体服务器供下载播放。与现有技术相比，本申请在浏览器上设置插件，以插件方式启动音视频数据的采集以及相应操作，而插件运行于操作系统之上，不再如RTMP直播技术那样依赖于运行于虚拟机之上的flashplayer技术，从而使安全沙箱的问题得以避免，解除了应用场景的束缚，满足了用户需求。此外，本申请实施例采用多线程的处理方式进行音视频编码，可以进行大数据量的运算，有利于实时远程音线频直播功能的扩展。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请的实时远程音视频的直播方法实施例的流程图；

图2为本申请的实时远程音视频的直播方法实施例的信号流向示意图；

图3为本申请实施例的采集与编码处理过程的示意图；

图4为本申请的实时远程音视频的直播装置的实施例的结构框图。

具体实施方式

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

参见图1和图2，其中：图1示出了本申请的实时远程音视频的直播方法的一个实施例的流程，图2示出了该实施例的信号流向示意图。该实施例包括：

步骤S101：通过浏览器上设置的插件调用音视频采集程序采集音视频数；

插件是具有可执行能力的代码集合，它是遵循一定规范的应用程序接口编写出来的程序。插件的运行在程序规定的系统平台下，通过调用系统平台提供的函数库或有关数据实现特定的功能。插件的功能根据需要千差外别，在本申请实施例中插件可以衔接浏览器平台和音视频采集程序，设置于浏览器上的插件受到触发后，执行插件包含的程序功能，调用采集程序采集音视频数据。

本实施例中的插件设置于浏览器之上可以体现为在浏览器上安装并注册插件，注册后的插件可以在满足一定条件下受到触发，满足一定条件下触发可以是自动式触发，也可以是在接收到来自某个确定的点击信息后的被动式触发，前者如通过收集用户操作网络系统的行为数据，自动分析识别出用户需要进行实时远程音视频的直播，然后触发插件启动采集程序；后者如在浏览器的页面中添加插件的标签引用，当该标签受到点击或调用时通过该标签触发插件。除了这种自动式触发和被动式触发两种方式外，实际应用过程中还可以将两种方式结合起来，即在自动式触发基础上通过接收用户的指示信息触发插件，比如，先通过自动的方式收集用户操作网络系统的行为数据，然后在分析这些数据后，弹出对话框请用户确认是否需要进行实时远程音视频的直播，当接收到确认消息后，触发插件动作。本实施例中的插件受到触发启动音视频采集程序可以体现为插件通过DirectShow启动采集音视频数据，Directshow的基本思想是实现SampleGrabberCB接口，通过回调来保存每一个buffer，即插件通过Directshow的SampleGrabberCB接口启动SampleGrabber采集音视频数据。

本实施例中的音视频采集程序采集音视频数据可以以整体的方式进行，即通过一个采集程序同时采集视频数据及其对应的音频数据，也可以以独立的方式分别进行音频数据的采集和视频数据的采集，比如，使用操作系统内置的摄像头采集视频数据，使用操作系统内置的麦克风采集音频数据。在后一种情况下，后续编码等步骤也可以采取同样的方式各自独立，在进行播放时同时加载这两类资源即可，当然，为避免存储或加载上的麻烦，可以在采集之后或者编码之后将音频数据和视频数据封装为完整的对应于一个独立的音视频文件。

步骤S102：将音视频数据进行编码后发送到流媒体服务器；

通过前述步骤采集到音视频数据后，需要将音视频数据进行编码后发送到流媒体服务器。具体的编码形式可根据实际需要进行选择，比如，对于音视频数据而言，可以采用H264、MPEG-4、WebM/VP8、Theora等编码格式，对于音频数据而言，可以采用Speex、AAC、Ogg/Vorbis等。如前所述，在编码时可以对音频数据和视频数据分别进行编码，本申请实施例优选采用一个线程对音频数据进行编码，采用另一个线程对视频数据进行编码。具体地，在前述的采用Directshow的SampleGrabberCB接口启动SampleGrabber采集音视频数据的情况下，可以采用AudioEncoderThread线程控制音频数据的编码，采用VideoEncoderThread线程控制视频数据的编码，下面结合图2进行详细说明：

对于音频编码而言，首先初始化编码器（比如ACC编码器），在AudioEncoderThread线程控制下循环调用DSAudioGraph从SampleGrabber中取出音频帧进行音频编码。为便于实现，下面给出音频编码过程中的主要程序代码：

采用ACC编码器进行编码时，需要注意如下的faac.h文件中的相关接口定义，不然容易使最后播放出来的音频数据不正常。

“faacEncHandle FAACAPI faacEncOpen(unsigned long sampleRate,unsigned intnumChannels,unsigned long*inputSamples,unsigned long*maxOutputBytes);

int FAACAPI faacEncEncode(faacEncHandle hEncoder,int32_t*inputBuffer,unsigned int samplesInput，unsigned char*outputBuffer,unsigned int bufferSize);”

在上述代码中faacEncEncode的第三个参数指的是传入sample的个数，这个值要与调用faacEncOpen返回的inputSamples相等。要做到这点，就要在dshow中设置好buffsize，公式如下：

BufferSize=aac_frame_len*channels*wBytesPerSample//aac_frame_len=1024

对于视频数据的编码而言，首先初始化编码器（比如H264编码器），在VideoEncoderThread线程控制下循环调用DSVideoGraph从SampleGrabber中取出视频帧进行视频编码。为便于实现，下面给出视频编码过程中的主要程序代码：

在上述程序中设置有IsBufferAvailaber（）的检测过程，其原因在于：音频的采样频率比较高，几乎是不断地在采集音频数据，为避免对CPU资源的过度占用，通常需要设置检测程序予以避免。

前述通过AudioEncoderThread线程和VideoEncoderThread线程对音视频数据分别编码后，将编码后的数据封装后发送到流媒体服务器时，本申请实施例优选采用另一个线程RtmpThread线程来完成工作，即在两个编码线程实时编码音视频数据后，将数据交与RtmpThread线程，由RtmpThread线程循环封装为Rtmp Packet，然后发送到流媒体服务器。如图2所示，线程之间的数据交换可以通过一个队列DataBufferQueue来实现。RtmpThread的主要工作就是发送音频数据流的解码信息头和视频数据流的解码信息头，并不断从DataBufferQueue中取出数据，封装为RTMP Packet，发送到流媒体服务器。此外，在AudioEncoderThread和VideoEncoderThread把数据指针post到DataBufferQueue之后，本申请实施例优选立即返回，这样可避免因为发送Rtmp报文的而影响到编码线程的正常执行时间。为便于实现，下面给出将音视频编码数据发送到流媒体服务器的主要程序代码：

（注：上述代码中的process_buf_queue_即是图2中的DataBufferQueue）

步骤S103：播放器从流媒体服务器上获取音视频数据进行直播；

流媒体是以流方式在网络中传送音频、视频和多媒体文件的媒体形式，这种媒体形式相对于传统的下载后观看的网络播放形式而言，其典型特征是把连续的音频和视频信息压缩后放到网络服务器上，用户边下载边观看，而不必等待整个文件下载完毕。流媒体服务器的主要功能是以流式协议（比如，RTP/RTSP、MMS、RTMP等）将视频文件传输到客户端，供用户在线观看。根据不同的标准，可对流媒体服务器作不同的分类，通常的流媒体服务器包括：大并发视频服务器、直播时移服务器、P2P直播服务器、视频交互应用服务器视频应用管理：媒体内容管理系统、H.264/MPEG-4编码工具、机顶盒终端管理系统、节目导航与发布系统等。典型的流媒体服务器产品有微软的Windows Media Service（WMS），它采用MMS协议接收、传输视频，采用Windows Media Player（WMP）作为前端播放器；RealNetworks公司的HelixServer，采用RTP/RTSP协议接收、传输视频，采用Real Player作为播放前端；Adobe公司的Flash Media Server,采用RTMP（RTMPT/RTMPE/RTMPS）协议接收、传输视频。本申请实施例可以采用播放器从流媒体服务器上下载音视频资源进行播放。

本实施例通过浏览器上设置的插件调用音视频采集程序采集音视频数据，然后对采集的音视频数据进行编码后发送到流媒体服务器供下载播放。与现有技术相比，本实施例在浏览器上设置插件，以插件方式启动音视频数据的采集以及相应操作，而插件运行于操作系统（的浏览器）之上，不再如RTMP直播技术那样依赖于运行于虚拟机之上的flashplayer技术，从而使安全沙箱的问题得以避免，解除了应用场景的束缚，满足了用户需求。此外，本申请实施例采用多线程的处理方式进行音视频编码，可以进行大数据量的运算，有利于实时远程音线频直播功能的扩展。

上述实施例在实际应用过程中还可以根据需要进行进一步改进。比如，在现有的采用flashplayer技术实现RTMP直播的方式，由于采用flashplayer直播，其在提高画面质量时，需要更大的采集频率或采样率，以便提供更多的音视频数据，但在这种情况下，带宽占用也非常惊人，导致带宽资源的浪费。为解决该问题，本申请实施例优选采取两方面的措施：一是在实现调用音视频采集程序采集音视频数据的过程中，调用音视频采集程序按照预设采样率采集音频数据，按照预设帧率采集视频数据；二是在实现将音视频数据进行编码的过程中，采用H264编码器对视频数据进行编码，在对视频数据进行编码之前根据适应预设帧率的原则修改H264编码库；采用AAC编码器对音频数据进行编码，在对音频数据进行编码之前根据适应预设采样率的原则修改AAC编码库。本申请实施例采用的这两方面的措施平衡了数据量的多少与画面质量高低，使画面质量尽可能高但相对于现有技术的数据量尽可能少，从而减少了对带宽的占用，满足了高端客户的要求。需要特别说明的是：现有的flashplayer技术是不能进行上述两方面的措施的，因为flashplayer技术属于第三方程序，在已经固化于操作系统后，其需要的采样率或帧率基本上就固定了，不能进行修改后，而本申请由于采用设置在浏览器上的插件形式触发采集程序，插件的实现过程可以根据需要进行程序上的修改，因此，可以按照预定的帧率或者采样率进行采样，在进行编码时也可以根据需要（与前述的帧率或采样率相适应的方式）修改编码库。此外，本申请实施例的方式不仅能够减少带宽，而且提高了直播技术的拓展性。

上述内容详细叙述了本申请的实时远程音视频的直播方法的实施例，相应地，本申请还提供了一种实时远程音视频的直播装置的实施例。参见图4，该图示出了本申请的实时远程音视频的直播装置实施例的结构框图。该实施例装置包括：采集程序调用单元401、音视频数据编码单元402和直播单元403，其中：

采集程序调用单元401，用于通过浏览器上设置的插件调用音视频采集程序采集音视频数据；

音视频数据编码单元402，用于对音视频数据进行编码；

直播单元403，用于从流媒体服务器上获取音视频数据进行直播。

本装置实施例的工作过程是：先由采集程序调用单元401通过浏览器上设置的插件调用音视频采集程序采集音视频数据，再由音视频数据编码单元402对音视频数据进行编码，最后直播单元403从流媒体服务器上获取音视频数据进行直播。

本装置实施例通过浏览器上设置的插件调用音视频采集程序采集音视频数据，然后对采集的音视频数据进行编码后发送到流媒体服务器供下载播放。与现有技术相比，本装置实施例在浏览器上设置插件，以插件方式启动音视频数据的采集以及相应操作，而插件运行于操作系统（的浏览器）之上，不再如RTMP直播技术那样依赖于运行于虚拟机之上的flashplayer技术，从而使安全沙箱的问题得以避免，解除了应用场景的束缚，满足了用户需求。此外，本申请实施例采用多线程的处理方式进行音视频编码，可以进行大数据量的运算，有利于实时远程音线频直播功能的扩展。

上述装置实施例浏览器中设置的插件可以通过在装置实施例中增加注册单元404来实现，由注册单元404在浏览器上注册包含Directshow技术的插件；这样，在插件受到触发时，采集程序调用单元通过插件的Directshow启动采集音视频数据。更为具体地，采集程序调用单元通过插件的Directshow的SampleGrabberCB接口启动SampleGrabber采集音视频数据。

上述装置实施例在进行音视频数据编码时可以采用一体化编码，也可以将音视频数据分开进行编码。在这种情况下，上述音视频编码单元402包括音频编码子单元4021、视频编码子单元4022和音视频数据封装子单元4023，其中：音频编码子单元4021采用一个线程对音频数据进行编码；视频编码子单元4022采用一个线程对视频数据编码；音视频数据封装子单元4023，用于将编码后的音频数据和视频数据封装后发送到流媒体服务器。此外，为了减少带宽的浪费，上述装置实施例中的音视频编码单元402还可以按照如下的方式构成：音视频编码单元包括H264编码库修改单元和H264编码器、ACC编码库修改单元和ACC编码器以及音视频数据封装单元，其中：所述H264编码库修改单元，用于在对视频数据进行编码之前根据适应预设帧率的原则修改H264编码库；所述H264编码器，用于对视频数据进行编码；所述ACC编码库修改单元，用于在对音频数据进行编码之前根据适应预设采样率的原则修改AAC编码库；所述ACC编码器，用于对音频数据进行编码；所述音视频数据封装单元，用于将编码后的音频数据和视频数据封装后发送到流媒体服务器。

需要说明的是：为了叙述的简便，本说明书的上述实施例以及实施例的各种变形方式重点说明的都是与其他实施例或变形方式的不同之处，各个情形之间相同相似的部分互相参见即可。尤其，对于装置实施例的几个改进方式而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例的各单元可以是或者也可以不是物理上分开的，既可以位于一个地方，或者也可以分布到多个网络环境下。在实际应用过程中，可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的，本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (12)

1.一种实时远程音视频的直播方法，其特征在于，所述方法包括：

通过浏览器上设置的插件调用音视频采集程序采集音视频数据；

将音视频数据进行编码后发送到流媒体服务器；

播放器从流媒体服务器上获取音视频数据进行直播。

2.根据权利要求1所述的方法，其特征在于，在浏览器上注册包含Directshow技术的插件，当插件受到触发时，插件通过Directshow启动采集音视频数据。

3.根据权利要求2所述的方法，其特征在于，所述插件通过Directshow启动采集音视频数据具体包括：插件通过Directshow的SampleGrabberCB接口启动SampleGrabber采集音视频数据。

4.根据权利要求3所述的方法，其特征在于，所述将音视频数据进行编码后发送到流媒体服务器具体包括：

采用一个线程对音频数据进行编码，采用一个线程对视频数据进行编码，将编码后的音频数据和视频数据封装后发送到流媒体服务器。

5.根据权利要求4所述的方法，其特征在于，所述将音视频数据进行编码后发送到流媒体服务器具体为：

初始化音频编码器，在AudioEncoderThread线程控制下循环调用DSAudioGraph从SampleGrabber中取出音频帧进行音频编码；初始化视频编码器，在VideoEncoderThread线程控制下循环调用DSVideoGraph从SampleGrabber中取出视频帧进行视频编码，将编码后的音频数据和视频数据通过RtmpThread线程进行循环封装后通过Rtmp协议发送到流媒体服务器。

6.根据权利要求1所述的方法，其特征在于，所述调用音视频采集程序采集音视频数据具体包括：调用音视频采集程序按照预设采样率采集音频数据，按照预设帧率采集视频数据。

7.根据权利要求6所述的方法，其特征在于，所述将音视频数据进行编码具体包括：采用H264编码器对视频数据进行编码，在对视频数据进行编码之前根据适应预设帧率的原则修改H264编码库；采用AAC编码器对音频数据进行编码，在对音频数据进行编码之前根据适应预设采样率的原则修改AAC编码库。

8.一种实时远程音视频的直播装置，其特征在于，该装置包括：采集程序调用单元、音视频数据编码单元和直播单元，其中：

所述采集程序调用单元，用于通过浏览器上设置的插件调用音视频采集程序采集音视频数据；

所述音视频数据编码单元，用于对音视频数据进行编码；

所述直播单元，用于从流媒体服务器上获取音视频数据进行直播。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括注册单元，用于在浏览器上注册包含Directshow技术的插件；

当插件受到触发时，采集程序调用单元通过插件的Directshow启动采集音视频数据。

10.根据权利要求9所述的装置，其特征在于，所述采集程序调用单元通过插件的Directshow的SampleGrabberCB接口启动SampleGrabber采集音视频数据。

11.根据权利要求10所述的装置，其特征在于，所述音视频编码单元包括音频编码子单元、视频编码子单元和音视频数据封装子单元，其中：

所述音频编码子单元，用于采用一个线程对音频数据进行编码；

所述视频编码子单元，用于采用一个线程对视频数据编码；

所述音视频数据封装子单元，用于将编码后的音频数据和视频数据封装后发送到流媒体服务器。

12.根据权利要求8所述的装置，其特征在于，所述音视频编码单元包括H264编码库修改单元和H264编码器、ACC编码库修改单元和ACC编码器以及音视频数据封装单元，其中：

所述H264编码库修改单元，用于在对视频数据进行编码之前根据适应预设帧率的原则修改H264编码库；

所述H264编码器，用于对视频数据进行编码；

所述ACC编码库修改单元，用于在对音频数据进行编码之前根据适应预设采样率的原则修改AAC编码库；

所述ACC编码器，用于对音频数据进行编码；

所述音视频数据封装单元，用于将编码后的音频数据和视频数据封装后发送到流媒体服务器。

Images