视频数据流的发送方法、终端及系统

1.一种视频数据流的发送方法，其特征在于，包括：
视频数据流发送终端获得本地多媒体装置的状态信息；所述多媒体装置为语音接收设备，则所述多媒体装置的状态信息包括持续接收语音信号和未持续接收语音信号；或者，所述多媒体装置为视频图像显示设备，则所述多媒体装置的状态信息包括显示关于视频会议的视频图像和没有显示关于视频会议的视频图像；
根据所述状态信息，确定视频数据流的发送规则；并
根据所述发送规则，向接收方设备发送视频数据流；
其中，所述多媒体装置为语音接收设备；以及根据所述状态信息确定视频数据流的发送规则，具体包括：
当所述语音接收设备的状态信息为持续接收语音信号时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流和扩展层视频数据流；
当所述语音接收设备的状态信息为未持续接收语音信号时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流；
其中，所述多媒体装置为视频图像显示设备；以及根据所述状态信息确定视频数据流的发送规则，具体包括：
当所述视频图像显示设备的状态信息为显示关于视频会议的视频图像时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流和扩展层视频数据流；
当所述视频图像显示设备的状态信息为没有显示关于视频会议的视频图像时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流。
2.如权利要求1所述的方法，其特征在于，还包括：
视频数据流发送终端根据所述状态信息，确定针对通过本地视频图像获取设备获取的视频图像的显示规则；以及
根据确定的显示规则，显示所述获取的视频图像。
3.如权利要求2所述的方法，其特征在于，所述多媒体装置为语音接收设备；以及视频数据流发送终端根据所述状态信息，确定所述获取的视频图像的显示规则，具体包括：
当所述语音接收设备的状态信息为持续接收语音信号时，确定在视频数据流发送终端上运行的浏览器的第一窗口中显示所述获取的视频图像；
当所述语音接收设备的状态信息为未持续接收语音信号时，确定在视频数据流发送终端上运行的浏览器的第二窗口中显示所述获取的视频图像；
其中，所述第一窗口的面积大于第二窗口的面积。
4.如权利要求2～3任一所述的方法，其特征在于，还包括：
视频数据流发送终端接收其他视频数据流发送终端发送的视频数据流；
根据接收到的视频数据流的层次信息，确定对接收的视频数据流解码得到的视频图像的显示规则。
5.如权利要求1所述的方法，其特征在于，根据所述发送规则，向接收方设备发送视频数据流，具体包括：
根据所述发送规则，基于分层视频编解码技术对获得的视频图像进行编码；以及向接收方设备发送编码得到的视频数据流。
6.如权利要求1所述的方法，其特征在于，视频数据流发送终端获得本地多媒体装置的状态信息，具体包括：
运行在视频数据流发送终端中的浏览器通过视频数据流发送终端的操作系统的应用程序编程接口API，确定本地语音接收设备是否被设置为静默状态；或
所述浏览器根据所述浏览器自身的编解码输出/媒体数据输入接口所传输的针对视频会议的数据包的信息，确定本地语音接收设备是否被设置为静默状态；
所述浏览器确定所述浏览器自身针对视频会议状态的状态维护信息，并根据该状态维护信息确定本地语音接收设备是否处于暂停传输语音信号的状态。
7.如权利要求1所述的方法，其特征在于，根据所述状态信息，确定视频数据流的发送规则，具体包括：
运行在视频数据流发送终端中的浏览器根据所述状态信息确定所述发送规则；或运行在视频数据流发送终端中的浏览器通过API，将所述状态信息提供给视频数据流发送终端中由脚本程序实现的发送规则确定单元；以及
发送规则确定单元根据所述状态信息确定所述发送规则。
8.一种终端，其特征在于，包括：
状态信息获得单元，用于获得用于接收本地视频会议数据的多媒体装置的状态信息；
所述多媒体装置为语音接收设备，则所述多媒体装置的状态信息包括持续接收语音信号和未持续接收语音信号；或者，所述多媒体装置为视频图像显示设备，则所述多媒体装置的状态信息包括显示关于视频会议的视频图像和没有显示关于视频会议的视频图像；
发送规则确定单元，用于根据状态信息获得单元获得的状态信息，确定视频数据流的发送规则；
发送单元，用于根据发送规则确定单元确定的发送规则，向接收方设备发送视频数据流；
其中，所述多媒体装置为语音接收设备；以及所述发送规则确定单元具体用于：
当所述语音接收设备的状态信息为持续接收语音信号时，确定向接收方设备发送基于分层视频编解码技术对获得的视频图像进行编码得到的基本层视频数据流和扩展层视频数据流；
当所述语音接收设备的状态信息为未持续接收语音信号时，确定向接收方设备发送基于分层视频编解码技术对获得的视频图像进行编码得到的基本层视频数据流；
其中，所述多媒体装置为视频图像显示设备；以及所述发送规则确定单元具体用于：
当所述视频图像显示设备的状态信息为显示关于视频会议的视频图像时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流和扩展层视频数据流；
当所述视频图像显示设备的状态信息为没有显示关于视频会议的视频图像时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流。
9.如权利要求8所述的终端，其特征在于，还包括：
第一显示规则确定单元，用于视频数据流发送终端根据状态信息获得单元获得的状态信息，确定针对通过本地视频图像获取设备获取的视频图像的显示规则；
显示单元，用于根据第一显示规则确定单元确定的显示规则，显示所述获取的视频图像。
10.如权利要求9所述的终端，其特征在于，所述多媒体装置为语音接收设备；以及所述第一显示规则确定单元具体用于：
当所述语音接收设备的状态信息为持续接收语音信号时，确定在视频数据流发送终端上运行的浏览器的第一窗口中显示所述获取的视频图像；
当所述语音接收设备的状态信息为未持续接收语音信号时，确定在视频数据流发送终端上运行的浏览器的第二窗口中显示所述获取的视频图像；
其中，所述第一窗口的面积大于第二窗口的面积。
11.如权利要求8～10任一所述的终端，其特征在于，还包括：
接收单元，用于接收其他视频数据流发送终端发送的视频数据流；
层次信息确定单元，用于确定接收单元接收到的视频数据流的层次信息；
第二显示规则确定单元，用于根据层次信息确定单元确定的层次信息，确定对接收单元接收的视频数据流解码得到的视频图像的显示规则。
12.如权利要求8所述的终端，其特征在于，所述发送单元具体包括：
编码子单元，用于根据所述发送规则，基于分层视频编解码技术对获得的视频图像进行编码；
发送子单元，用于向接收方设备发送编码子单元编码得到的视频数据流。
13.如权利要求8所述的终端，其特征在于，所述状态信息获得单元具体包括：
运行在所述终端中的浏览器，用于通过视频数据流发送终端的操作系统的应用程序编程接口API，确定本地语音接收设备是否被设置为静默状态；或用于根据浏览器自身的编解码输出/媒体数据输入接口所传输的针对视频会议的数据包的信息，确定本地语音接收设备是否被设置为静默状态；或用于确定浏览器自身针对视频会议状态的状态维护信息，并根据该状态维护信息确定本地语音接收设备是否处于暂停传输语音信号的状态。
14.如权利要求8所述的终端，其特征在于，所述发送规则确定单元为运行在所述终端中的浏览器。
15.如权利要求8所述的终端，其特征在于，所述发送规则确定单元具体包括：运行在所述终端中的浏览器和由脚本程序实现的发送规则确定子单元，其中：
所述浏览器，用于通过API，将所述状态信息提供给所述发送规则确定子单元；
所述发送规则确定子单元，用于根据所述浏览器提供的所述状态信息，确定所述发送规则。
16.一种视频数据流的传输系统，包括视频数据流发送终端和接收方设备，其特征在于：
视频数据流发送终端，用于获得本地多媒体装置的状态信息；并根据所述状态信息，确定视频数据流的发送规则；以及根据所述发送规则，向接收方设备发送视频数据流；所述多媒体装置为语音接收设备，则所述多媒体装置的状态信息包括持续接收语音信号和未持续接收语音信号；或者，所述多媒体装置为视频图像显示设备，则所述多媒体装置的状态信息包括显示关于视频会议的视频图像和没有显示关于视频会议的视频图像；
接收方设备，用于接收视频数据流发送终端发送的视频数据流；
其中，所述多媒体装置为语音接收设备；以及视频数据流发送终端具体用于：
当所述语音接收设备的状态信息为持续接收语音信号时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流和扩展层视频数据流；
当所述语音接收设备的状态信息为未持续接收语音信号时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流；
其中，所述多媒体装置为视频图像显示设备；以及视频数据流发送终端具体用于：
当所述视频图像显示设备的状态信息为显示关于视频会议的视频图像时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流和扩展层视频数据流；
当所述视频图像显示设备的状态信息为没有显示关于视频会议的视频图像时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流。
17.如权利要求16所述的系统，其特征在于，视频数据流发送终端还用于：根据所述状态信息，确定针对通过本地视频图像获取设备获取的视频图像的显示规则；以及根据确定的显示规则，显示所述获取的视频图像。
18.如权利要求17所述的系统，其特征在于，所述多媒体装置为语音接收设备；以及视频数据流发送终端具体用于：
当所述语音接收设备的状态信息为持续接收语音信号时，确定在视频数据流发送终端上运行的浏览器的第一窗口中显示所述获取的视频图像；
当所述语音接收设备的状态信息为未持续接收语音信号时，确定在视频数据流发送终端上运行的浏览器的第二窗口中显示所述获取的视频图像；
其中，所述第一窗口的面积大于第二窗口的面积。
19.如权利要求16～18任一所述的系统，其特征在于，视频数据流发送终端还用于：接收其他视频数据流发送终端发送的视频数据流；并根据接收到的视频数据流的层次信息，确定对接收的视频数据流解码得到的视频图像的显示规则。
20.如权利要求16所述的系统，其特征在于，视频数据流发送终端具体用于：根据所述发送规则，基于分层视频编解码技术对获得的视频图像进行编码；以及向接收方设备发送编码得到的视频数据流。
21.如权利要求16所述的系统，其特征在于，视频数据流发送终端具体用于：
调用运行在视频数据流发送终端中的浏览器通过视频数据流发送终端的操作系统的应用程序编程接口API，确定本地语音接收设备是否被设置为静默状态；或调用所述浏览器根据所述浏览器自身的编解码输出/媒体数据输入接口所传输的针对视频会议的数据包的信息，确定本地语音接收设备是否被设置为静默状态；
调用所述浏览器确定所述浏览器自身针对视频会议状态的状态维护信息，并根据该状态维护信息确定本地语音接收设备是否处于暂停传输语音信号的状态。
22.如权利要求16所述的系统，其特征在于，视频数据流发送终端具体用于：
调用运行在视频数据流发送终端中的浏览器根据所述状态信息确定所述发送规则。
23.如权利要求16所述的系统，其特征在于，视频数据流发送终端具体用于：
调用运行在视频数据流发送终端中的浏览器通过API，将所述状态信息提供给视频数据流发送终端中由脚本程序实现的发送规则确定单元；以及调用发送规则确定单元根据所述状态信息确定所述发送规则。

视频数据流的发送方法、终端及系统\n技术领域\n[0001] 本发明涉及数据业务领域，尤其涉及一种视频数据流的发送方法、终端及视频数据流的传输系统。\n背景技术\n[0002] 基于浏览器的实时通信（RTCWeb，Real-Time Communications Web）是一种运行在浏览器上的Web应用，其通过调用浏览器提供的应用程序编程接口（API，Application Programming Interface），可以实现在不同终端之间建立实时通信连接，从而进行媒体流（包括音频数据流和/或视频数据流）的传输。\n[0003] 相对于传统的VoIP应用而言，RTCWeb的特点是：媒体面和终端的本地控制由运行在终端上的浏览器实现，而信令面则由嵌入Web页面的脚本程序（例如Java脚本程序）实现。\n具体地，基于浏览器和脚本程序实现在不同终端之间建立媒体流传输信道的过程具体为：\n运行在终端上的浏览器根据用户输入的RTCWeb服务网站URL，从相应的服务器上下载页面数据（该页面数据包含脚本程序）并将相应的页面呈现给用户；在终端登录到服务器后，若脚本程序捕获到用户通过脚本程序呈现的拨号界面输入的指示信息（即用于表示终端呼叫另一个在线终端的指示信息），则脚本程序通过浏览器将该指示信息发送给服务器；服务器根据该指示信息，向相应的在线终端发送呼叫信令，从而在该在线终端成功接收该呼叫信令后，两端的终端建立起端到端的媒体流传输信道。针对终端在上述过程中所起的作用，可以按照由底层至上层的划分方式，将实现RTCWeb的终端的系统架构划分为处于不同层面的结构，包括：底层硬件（包括麦克等语音输入设备）、操作系统、浏览器、脚本程序（或者是由脚本程序实现的功能单元）。位于上层的结构可以通过层间API调用下层的结构以实现上层的结构的业务逻辑功能。\n[0004] 以RTCWeb为基础，可以实现基于网页的视频会议。与视频会议相关的数据包括视频数据和音频数据。针对视频数据，其处理过程主要包括视频数据的采集、编解码、加密、图像处理、显示、网络传输与流控等；而针对音频数据，其处理过程主要包括音频数据的采集、编解码、加密、声音处理、声音输出、音量频同步、网络传输与流控等。\n[0005] 基于RTCWeb实现的视频会议中常用到分层视频编解码（SVC，Scaled Video Coding）技术。其是一种能将一个视频数据流分割为多个具备不同分辨率、视频质量和帧速率的不同层次的视频数据流（包括基本层视频数据流和扩展层视频数据流）的技术，以先进视频编解码器标准（H.264AVC）为基础，并对H.264视频编解码标准进行扩展。具体地，视频数据流被分割为基本层视频数据流和扩展层视频数据流的示意图如图1所示，图1中的菱形方框代表视频数据流中的数据。在视频会议中，视频会议终端可以基于SVC技术来接收或者发送由一个基本层视频数据流和一个（或多个）扩展层视频数据流。其中，基本层视频数据流可以单独被解码，其适应于最低的网络带宽，可保证视频会议终端对图像进行显示时所要求的最基本的图像质量；扩展层视频数据流可视为基本层视频数据流的补充，对不同扩展层视频数据流进行解码得到的附加信息可分别用于提高基本层视频数据流的分辨率、帧速率或图像质量。\n[0006] 基于以上介绍的RTCWeb和SVC技术，可以为一个团队建立一个多方视频会议并且使得会议参与方能够实现点对点直连，即每个会议参与方所使用的视频会议终端均能发送媒体流给其他会议参与方所使用的视频会议终端。当会议参与方所使用的视频会议终端收到其他视频会议终端发送的媒体流后，可以把针对发言人的高清视频图像呈现在视频会议终端所运行的浏览器的大窗口中；同时把针对其他非发言人的会议参与方的非高清视频图像呈现在浏览器的小窗口中。随着会议的进行，发言人会不断发生变化，视频会议终端可以随着发言人的变换，对浏览器的大窗口和小窗口所显示的视频图像分别进行调整。\n[0007] 为了实现采用不同方式分别呈现针对发言人、非发言人的视频图像，现有技术中提出了如下三种解决方案。\n[0008] 方案一：发送方视频会议终端基于SVC技术向接收方视频会议终端发送基本层视频数据流和扩展层视频数据流。接收方视频会议终端对于针对发言人的基本层视频数据流和扩展层视频数据流，会选择对这两部分视频数据流都进行解码，并利用解码得到的视频图像合成高清视频图像；而对于针对非发言人的基本层视频数据流和扩展视频数据流，接收方视频会议终端会选择只对基本层视频数据流进行解码，并呈现相应的视频图像。\n[0009] 方案二：发送方视频会议终端不采用SVC技术发送不同层的视频数据流，而是向接收方视频会议终端发送两个版本的视频数据流，即对高清视频图像和非高清视频图像分别进行编码而得到的视频数据流。接收方视频会议终端可以择一进行接收、解码，并呈现相应的视频图像。\n[0010] 方案三：发送方视频会议终端仅发送对高清视频图像进行编码得到的视频数据流。接收方视频会议终端接收到该视频数据流后，可以根据自身需求，直接对该视频数据流进行解码，并呈现相应的高清视频图像，也可以执行对该视频数据流的转码操作后，对解码得到的非高清视频图像进行呈现。\n[0011] 上述方案的缺陷在于，当接收方视频会议终端仅需求非高清视频图像时，发送方视频会议终端仍然会发送基本层视频数据流和扩展层视频数据流，或发送两个版本的视频数据流，或发送对高清视频图像编码得到的视频数据流，从而会产生不必要的传输开销。\n发明内容\n[0012] 本发明实施例提供一种视频数据流的发送方法、终端及系统，用以解决现有的视频数据流发送方案会产生不必要的传输开销的问题。\n[0013] 本发明实施例采用以下技术方案：\n[0014] 一种视频数据流的发送方法，包括：\n[0015] 视频数据流发送终端获得本地多媒体装置的状态信息；根据所述状态信息，确定视频数据流的发送规则；并根据所述发送规则，向接收方设备发送视频数据流。\n[0016] 一种终端，包括：状态信息获得单元，用于获得用于接收视频会议数据的多媒体装置的状态信息；发送规则确定单元，用于根据状态信息获得单元获得的状态信息，确定视频数据流的发送规则；发送单元，用于根据发送规则确定单元确定的发送规则，向接收方设备发送视频数据流。\n[0017] 一种视频数据流的传输系统，包括视频数据流发送终端和接收方设备，其中，视频数据流发送终端，用于获得本地多媒体装置的状态信息；并根据所述状态信息，确定视频数据流的发送规则；以及根据所述发送规则，向接收方设备发送视频数据流；接收方设备，用于接收视频数据流发送终端发送的视频数据流。\n[0018] 本发明实施例的有益效果如下：\n[0019] 通过采用上述技术方案，实现了视频数据流发送终端以能够体现视频会议当前发言人信息的本地多媒体装置的状态信息作为视频数据流的发送依据，从而对于视频数据流的发送不再有盲目性，而是按照接收方设备的需求来进行发送，因此避免了不必要的传输开销。\n附图说明\n[0020] 图1为视频数据流的分层示意图；\n[0021] 图2为本发明实施例提供的一种视频数据流的发送方法的具体流程示意图；\n[0022] 图3为本发明实施例提供的视频数据流的发送方法在实际中的应用流程示意图；\n[0023] 图4为本发明实施例提供的一种终端的具体结构示意图。\n具体实施方式\n[0024] 为了解决采用现有技术提供的视频数据流传输方案会产生不必要的传输开销的问题，发明人对现有技术中的三种视频数据流传输方案进行了深入研究。经研究发现：\n[0025] 针对方案二，无论一个会议参与方是否为当前的会议发言人，其使用的视频会议终端都需要向其他视频会议终端发送两个版本的视频数据流，从而相比于方案一、三，方案二会产生最大的传输开销。\n[0026] 针对方案三，类似地，无论一个会议参与方是否为当前的会议发言人，其使用的视频会议终端都会向其他视频会议终端发送对高清视频图像编码得到的视频数据流。这对于基于点对点的视频数据流交互方式参与N方视频会议的视频会议终端而言，意味着一个视频会议终端所产生的视频数据流传输开销=[2(N-1)×针对一个接收方视频会议终端的视频数据流单向传输开销]，这无疑是一个非常大的传输开销。\n[0027] 针对方案一，发送方视频会议终端在发送基本层视频数据流和扩展层视频数据流时，也没有考虑到接收方视频会议终端对于视频数据流的实际需求，从而即使接收方视频会议终端仅需要解码基本层视频数据流，发送方视频会议终端也会将基本层视频数据流和扩展层视频数据流都发送给接收方视频会议终端，从而导致扩展层视频数据流也产生了不必要的传输开销。\n[0028] 通过上述研究发现，方案一 三之所以会产生较大的传输开销，主要是没有考虑到~\n视频会议的特点，即——视频会议终端一般只会针对会议发言人呈现相应的高清视频图像，而针对非会议发言人则呈现相应的非高清视频图像。基于视频会议的该特点和上述方案一，本发明实施例提供了一种新颖的视频数据流的发送方法，通过以可以反映视频会议当前发言人信息的多媒体装置的状态信息作为确定视频数据流的发送规则的依据，从而克服了视频会议终端对于发送视频数据流的盲目性，使得视频会议终端可以按照接收方的需求来发送视频数据流，因此避免了不必要的传输开销。\n[0029] 以下结合附图，对本发明实施例提供的视频数据流传输方案进行详细说明。\n[0030] 首先，本发明实施例提供一种如图2所示的视频数据流传输方法，包括下述步骤：\n[0031] 步骤21，视频数据流发送终端获得多媒体装置的状态信息。\n[0032] 其中，该多媒体装置可以是用于接收、采集或者处理视频会议中产生的一些音频数据和/或视频数据等的装置。\n[0033] 具体地，其可以是视频数据流发送终端自身所包含的多媒体装置，如视频数据流发送终端的语音信号接收设备（如麦克风、摄像头等）和视频图像显示设备（如具备确定外形的显示器等实体设备，或者浏览器等主要由软件程序完成其功能的虚拟设备）等与用于接收视频会议数据的多媒体装置，也可以是与视频会议终端相连接但并非归属于视频会议终端的外围多媒体装置，如独立与视频会议终端外但与之相连接的语音信号接收设备和视频图像显示设备等。本发明实施例中，视频数据流发送终端自身包含的多媒体装置和上述外围多媒体装置都可称为该视频数据流发送终端的本地多媒体装置。\n[0034] 此外，上述视频数据流发送终端可以是前文所述的视频会议终端，也可以是其他的具备视频数据流发送功能的终端设备。\n[0035] 本发明实施例中，视频数据流发送终端可以通过对上述多媒体装置的监控来确定其状态信息，或者也可以通过对上述多媒体装置进行改进使之具备自我监控的能力后，由其主动向该视频数据流发送终端发送通过自我监控得到的状态信息。\n[0036] 步骤22，视频数据流发送终端根据确定的多媒体装置的状态信息，确定视频数据流的发送规则。\n[0037] 由于上述多媒体装置的多样性，使得步骤22的具体实现方式也可以有多种。比如，当该多媒体装置为语音接收设备时，若该语音接收设备的状态信息为持续接收语音信号，则可以确定使用视频数据流发送终端的用户为当前的会议发言人。从而进一步确定相应的视频数据流的发送规则可以为：向接收方设备发送基于分层视频编解码技术，对本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流和扩展层视频数据流，即发送通过分层视频编解码技术解码可以得到高清视频图像的视频数据流。而若该语音接收设备的状态信息为未持续接收语音信号，则可以确定使用视频数据流发送终端的用户并非当前的会议发言人。从而进一步确定相应的视频数据流发送规则为：向接收方设备发送基于分层视频编解码技术，对本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流。\n[0038] 又比如，当该多媒体装置为视频数据流发送终端的时，若该视频图像显示设备的状态信息为显示关于视频会议的视频图像，则可以确定相应的视频数据流的发送规则可以为：向接收方设备发送基于分层视频编解码技术，对本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流和扩展层视频数据流。而若该视频图像显示设备的状态信息为没有显示关于视频会议的视频图像，则可以确定相应的视频数据流的发送规则可以为：向接收方设备发送基于分层视频编解码技术，对本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流。\n[0039] 由上述确定发送规则的方式可知，上述多媒体装置的状态信息实际上可以体现视频会议当前发言人的一些信息。比如，当前发言人所使用的视频数据流发送终端是可以确定相应的语音接收设备是持续接收到语音信号的，而非发言人由于没有发言，因此其使用的视频数据流发送终端确定的状态信息则为：语音接收设备当前没有持续接收到语音信号。由此可见，上述步骤22在实际应用中是可行的。\n[0040] 可选的，本发明实施例中，可以在视频数据流发送终端中预先设置并存储多媒体装置的状态信息与视频数据流发送规则的对应关系，这样视频数据流发送终端根据确定的状态信息就可以很方便地定位到相应的视频数据流发送规则。\n[0041] 步骤23，视频数据流发送终端根据确定的发送规则，向接收方设备发送视频数据流。\n[0042] 这里的视频流数据可以是指：对视频数据流发送终端利用自身的图像采集设备采集到的视频图像编码后得到的视频流数据。具体编码方法可以有下述情况：\n[0043] 比如，视频数据流发送终端可以根据确定的发送规则，基于SVC技术对获得的视频图像进行编码后，再向接收方设备发送编码得到的视频数据流。针对该情况，以多媒体装置为语音接收设备为例，当其状态信息为持续接收语音信号时，可以确定相应的发送规则为：\n向接收方设备发送基本层视频数据流。从而可以采用SVC技术，将获得的视频图像编码为基本层视频数据流后发送。\n[0044] 又比如，视频数据发送终端也可以根据确定的发送规则，通过与接收方设备的协商，来选取与发送规则匹配的编解码算法后，再采用选取的编解码算法对视频图像进行编码，并向接收方设备编码得到的视频数据流。针对该情况，以多媒体装置为浏览器为例，当其状态信息为：当前所展示的焦点窗口为视频会议的视频图像呈现窗口时，可以确定相应的发送规则为：向接收方设备发送数据帧传输率较高的视频数据流。从而视频数据发送终端可以通过与接收方设备的协商，在确定出相应的编解码算法后，对获得的视频图像进行编码并发送给接收方设备。\n[0045] 又如，视频数据发送终端还可以根据确定的发送规则，选取与发送规则匹配的图像分辨率，并根据该图像分辨率，对获得的视频图像的分辨率进行调整后，再对其进行编码并发送。针对该情况，以多媒体装置为语音接收设备为例，当其状态信息为未持续接收语音信号时，可以确定相应的发送规则为：向接收方设备发送对分辨率较低的视频图像编码得到的视频数据流。从而可以通过与接收方设备的协商，在确定出相应的图像分辨率后，根据该图像分辨率对获得的视频图像进行编码并发送给接收方设备。\n[0046] 其中，这里的接收方设备可以是其他的视频数据流发送终端，也可以是用于统一对各个视频数据流发送终端发送的视频数据流进行接收与呈现的其他设备。\n[0047] 通过上述视频数据流发送方法，由于其以能够体现视频会议当前发言人信息的状态信息作为视频数据流的发送依据，从而视频数据流发送终端对于视频数据流的发送不再有盲目性，而是按照接收方设备的需求来进行发送，因此避免了不必要的传输开销。\n[0048] 可选的，视频数据流发送终端根据其确定的状态信息，还可以进一步确定针对通过本地视频图像获取设备获取的视频图像的显示规则，从而根据确定的显示规则，显示获取的该视频图像。比如，当多媒体装置为语音接收设备时，若语音接收设备的状态信息为持续接收语音信号，则可以确定在视频数据流发送终端上运行的浏览器的第一窗口中显示获取的视频图像；而当语音接收设备的状态信息为未持续接收语音信号，则可以确定在视频数据流发送终端上运行的浏览器的第二窗口中显示获取的视频图像。其中，第一窗口的面积大于第二窗口的面积。这样就可以在使用该视频数据流发送终端的用户为当前发言人时，实现将关于该用户的视频图像显示在大窗口中。\n[0049] 可选的，如视频数据流发送终端还需要对其他视频数据流发送终端发送的视频数据流进行解码显示，则上述方法还可以进一步包括步骤：视频数据流发送终端接收其他视频数据流发送终端发送的视频数据流；并根据接收到的视频数据流的层次信息，确定对接收的视频数据流解码得到的视频图像的显示规则。其中，这里所述的层次信息具体是指视频数据流是由哪些层的视频数据流（比如基本层数据流和/或扩展层数据流）构成。\n[0050] 需要特别说明的是，本发明实施例中，视频数据流发送终端获得本地多媒体装置的状态信息具体可以采用下述方式之一：\n[0051] 1、由运行在视频数据流发送终端中的浏览器通过视频数据流发送终端的操作系统的API，确定本地语音接收设备是否被设置为静默状态；这里所述的静默状态一般就是指不接收语音信号的状态。\n[0052] 2、由上述浏览器根据浏览器自身的编解码输出/媒体数据输入接口所传输的针对视频会议的数据包的信息，确定本地语音接收设备是否被设置为静默状态；\n[0053] 3、由上述浏览器确定浏览器自身针对视频会议状态的状态维护信息，并根据该状态维护信息确定本地语音接收设备是否处于暂停传输语音信号的状态。\n[0054] 而根据获得的状态信息，确定视频数据流的发送规则，则具体可以采用下述方式之一：\n[0055] 1、运行在视频数据流发送终端中的浏览器根据获得的状态信息，确定视频数据流的发送规则；\n[0056] 2、运行在视频数据流发送终端中的浏览器通过API，将获得的状态信息提供给视频数据流发送终端中由脚本程序实现的发送规则确定单元；从而由该发送规则确定单元根据该状态信息确定视频数据流的发送规则。\n[0057] 以下以本发明实施例提供的上述视频数据流的发送方法在视频会议中的应用为例，详细说明该方法的实现过程。\n[0058] 在视频会议中应用上述方法的基本思想在于：首先，发送方视频会议终端与接收方视频会议终端之间建立连接，为进行点对点的媒体流传输提供传输通道；发送方视频会议终端对自身的语音接收设备进行监测，监测该语音接收设备是否持续接收到语音信号；\n根据监测结果，发送方视频会议终端确定视频数据流的发送规则。具体确定方式为：如果监测到语音接收设备持续接收到语音信号，则说明使用发送方视频会议终端的用户是当前的会议发言人，因此确定视频数据流的发送规则为：发送基本层视频数据流和扩展层视频数据流；如果监测到语音接收设备没有持续接收到语音信号，则说明使用发送方视频会议终端的用户不是当前的会议发言人，从而确定视频数据流发送规则为：仅发送基本层视频数据流。\n[0059] 基于上述基本思想，以A、B、C三方参与的多方视频会议会话过程为例，采用本发明实施例提供的方法实现视频数据流发送的具体流程包括如图3所示的以下步骤：\n[0060] 步骤31，会议参与方Ａ、B、C分别使用的视频会议终端（以下分别简称终端A、终端B、终端C）之间建立起点对点的视频数据流传输通道。\n[0061] 步骤32，视频会议终端之间的点对点视频数据流传输通道建立成功后，终端A、终端B、终端C在通过自身的摄像头（或连接到自身、并提供针对视频会议的视频图像的摄像头）获取视频图像的同时，分别监测自身是否持续接收到语音信号。\n[0062] 视频会议终端可以通过对自身的语音接收设备进行监控，或对连接到自身、并提供针对视频会议的语音信号的语音接收设备与自身的数据接口进行监控，以确定自身是否持续接收到语音信号。或者，视频会议终端还可以对语音编解码层面的DTX语音端点检测模块所发送的数据包进行监测，并根据数据包类型（分为静默数据包与语音数据包），确定视频会议终端是否持续接收到语音信号。\n[0063] 步骤33，终端Ａ监测到自身持续接收到语音信号，终端B、C均监测到自身没有持续接收到语音信号（即用户为静默状态）。\n[0064] 视频会议终端对语音信号的监测可以是周期性的，也可以是持续性的。\n[0065] 本发明实施例中，可以规定：若在预定时间长度内，视频会议终端未监测到其接收到通过语音接收设备输入的语音信号，则确定自身未持续接收到语音信号；反之，则视频会议终端可以确定自身持续接收到语音信号。其中，预定时间长度可以按经验进行设置，比如可以设置为1分钟，或者30秒等等。\n[0066] 步骤34，终端A根据自身持续接收到语音信号的这一监测结果，基于SVC技术，将通过摄像头获取到的视频图像编码为第一基本层视频数据流和第一扩展层视频数据流，并分别发送给终端B、终端C；而终端B根据自身未持续接收到语音信号这一监测结果，基于SVC技术，将通过摄像头获取到的视频图像编码成第二基本层视频数据流，并分别发送给终端A和终端C；终端C根据自身未持续接收到语音信号这一监测结果，基于SVC技术，将通过摄像头获取到的视频图像编码成第三基本层视频数据流，并分别发送给终端A和终端B；\n[0067] 步骤35，终端A接收终端B发送的第二基本层视频数据流，并接收终端C发送的第三基本层视频数据流；\n[0068] 终端B接收终端A发送的第一基本层视频数据流和第一扩展层视频数据流，并接收终端C发送的第三基本层视频数据流；\n[0069] 终端C接收终端A发送的第一基本层视频数据流和第一扩展层视频数据流，并接收终端B发送的第二基本层视频数据流。\n[0070] 终端A采用SVC技术解码接收到的第二、第三基本层视频数据流，并将解码得到的视频图像呈现在终端A上运行的浏览器的窗口中。同时，终端A还可以根据自身持续接收到语音信号这一监测结果，以高清方式在该浏览器窗口中呈现其通过摄像头获得的视频图像。可选的，上述解码得到的视频图像可以呈现在浏览器的较小的窗口中，而通过摄像头获得的视频图像则可以呈现在浏览器的较大的窗口中。采用该呈现方式的优点在于，较大的窗口呈现的是会议发言人的视频图像，较小的窗口呈现的是非会议发言人的视频图像，从而相当于实现通过浏览器窗口的大小体现会议参与方的重要程度。\n[0071] 对于终端B而言，其可以采用SVC技术解码接收到的第一、第三基本层视频数据流以及第一扩展层视频数据流，并将解码得到的对应于第一基本层视频数据流的视频图像和对应于第一扩展层视频数据流的视频图像合成为高清视频图像后，呈现在浏览器窗口中，同时将解码得到的对应于第三基本层视频数据流的视频图像呈现在浏览器窗口中。可选的，终端B还可以在浏览器窗口中呈现自身通过摄像头获得的视频图像。可选的，终端B可以将合成的高清视频图像呈现在较大的浏览器窗口中，而将对应于第三基本层视频数据流的视频图像呈现在较小的浏览器窗口中。可选的，终端B根据自身未持续接收到语音信号这一监测结果，可以将自身通过摄像头获得的视频图像呈现在较小的浏览器窗口中。\n[0072] 类似地，对于终端C而言，其采用SVC技术解码接收到的第一、第二基本层视频数据流以及第一扩展层视频数据流，并将解码得到的对应于第一基本层视频数据流的视频图像和对应于第一扩展层视频数据流的视频图像合成为高清视频图像后，呈现在浏览器窗口中，同时将解码得到的对应于第二基本层视频数据流的视频图像呈现在浏览器窗口中。可选的，终端C还可以在浏览器窗口中呈现自身通过摄像头获得的视频图像。可选的，终端C可以将合成的高清视频图像呈现在较大的浏览器窗口中，而将对应于第三基本层视频数据流的视频图像呈现在较小的浏览器窗口中。可选的，终端C根据自身未持续接收到语音信号这一监测结果，可以将自身通过摄像头获得的视频图像呈现在较小的浏览器窗口中。\n[0073] 步骤36，当终端A监测到其未持续接收到语音信号时，仍然会将第一基本层视频数据流发送给终端B、终端C，但同时会停止发送第一扩展层视频数据流；\n[0074] 当终端B监测到其持续接收到语音信号时，会将其通过摄像头获取到的视频图像编码为第二基本层视频数据流和第二扩展层视频数据流，并发送给终端A和终端C。\n[0075] 由于终端C监测到其仍然未持续接收到语音信号，从而向终端A和终端B发送第三基本层视频数据流。\n[0076] 具体地，视频会议终端可用通过调整自身的驱动工作模式、调整视频数据流的编解码算法或调整自身包含的用于发送视频数据流的模块等手段，实现从发送基本层视频数据流切换为发送基本层视频数据流和扩展层视频数据流（也可能是从发送送基本层视频数据流和扩展层视频数据流切换为发送基本层视频数据流）。\n[0077] 步骤37，终端B采用SVC技术解码接收到的第一、第三基本层视频数据流，并将解码得到的视频图像呈现在终端B上运行的浏览器窗口中。同时，终端B还可以根据自身持续接收到语音信号这一监测结果，以高清方式在该浏览器窗口中呈现其通过摄像头获得的视频图像。可选的，上述解码得到的视频图像可以呈现在较小的浏览器窗口中，而通过摄像头获得的视频图像则可以呈现在较大的浏览器窗口中。\n[0078] 对于终端A而言，在步骤37中，其采用SVC技术解码接收到的第二、第三基本层视频数据流以及第二扩展层视频数据流，并将解码得到的对应于第二基本层视频数据流的视频图像和对应于第二扩展层视频数据流的视频图像合成为高清视频图像后，呈现在浏览器窗口，同时将解码得到的对应于第三基本层视频数据流的视频图像呈现在浏览器窗口中。可选的，终端A还可以在浏览器窗口中呈现自身通过摄像头获得的视频图像。可选的，终端A可以将合成的高清视频图像呈现在较大的浏览器窗口中，而将对第三基本层视频数据流解码得到的视频图像和自身通过摄像头获得的视频图像呈现在较小的浏览器窗口中。\n[0079] 类似地，对于终端C而言，在步骤37中，其采用SVC解码技术解码接收到的第一、第二基本层视频数据流以及第二扩展层视频数据流，并将对第二基本层视频数据流解码得到的视频图像和对第二扩展层视频数据流解码得到的视频图像合成为高清视频图像后，呈现在浏览器窗口，同时将解码得到的对应于第一基本层视频数据流的视频图像呈现在浏览器窗口中。可选的，终端C还可以在浏览器窗口中呈现自身通过摄像头获得的视频图像。可选的，终端C可以将合成的高清视频图像呈现在较大的浏览器窗口中，而将对应于第一基本层视频数据流的视频图像呈现在较小的浏览器窗口中。可选的，终端C根据自身未持续接收到语音信号这一监测结果，可以将自身通过摄像头获得的视频图像呈现在较小的浏览器窗口中。\n[0080] 以上介绍的流程主要针对的是会议发言人变化一次的场景。本领域技术人员根据上述流程，可以确定当会议发言人多次变化时，可以采用与上述流程类似的方案。\n[0081] 通过本发明实施例提供的方案在实际中的上述应用，可以实现视频会议终端根据用于体现会议状态的信息来自适应调整其发送的视频数据流，从而在保证用户体验不受到影响的前提下，大大减少了发送方视频会议终端针对视频数据流的传输开销。\n[0082] 本发明实施例提供的方案不仅适用于完全分布式混频会议场景，还适用于基于混频服务器的会议场景。前者具体是指各个会议参与方使用的视频会议终端均参与视频数据流的混合调制。在该场景下，采用本发明实施例提供的方案能够显著降低发送方视频会议终端对于视频数据流的传输开销，同时降低接收方视频会议终端对于视频数据流的调制处理开销。而后者具体是指媒体面除存在视频会议终端外，还存在一个专用的混频服务器，其负责接收全部或视频会议的视频会议终端所发送的视频数据流（包括基本层视频数据流和/或扩展层视频数据流），并对接收到的视频数据流进行统一解码与呈现，以及对视频数据流进行下发。该混频服务器可以看做是一个集中式的发送方视频会议终端，同时也可以看做是一个集中式的接收方视频会议终端。在该场景下，采用本发明实施例提供的方案，可以显著降低发送方视频会议终端对于视频数据流的传输开销，同时还可以降低混频服务器对于视频数据流的调制处理开销。\n[0083] 本发明实施例中，视频会议终端可以但不限于采用下述软、硬件结构之一来实现上述流程：\n[0084] 能够实现VoIP功能的软件；运行在视频会议终端上的，且支持实时通信的浏览器；\n依托于本地浏览器API，支持实时通信的网页程序（例如，页面内嵌的java脚本）；依托于视频会议平台API，为视频会议上层应用提供支持的中间件软件；为视频会议终端定制，且能够实现上述流程的固化硬件设备。\n[0085] 在实际应用中，如图3所示的流程还可以进行下述扩展：\n[0086] 实施例1：\n[0087] 视频数据流发送规则的选取依据除了可以是如上所述的“视频会议终端是否监测到其持续接收到语音信号”，还可以是视频会议终端是否接收到用户输入的用于指示视频会议终端将麦克风设置为静音的指示消息、视频会议终端是否连接有音频信号采集设备，或视频会议的视频图像呈现窗口是否为视频会议终端当前所展示的的焦点窗口等。\n[0088] 实施例2：\n[0089] 视频会议终端在发送视频数据流时，可以自主调整视频数据流的编码层数，即调整发送的扩展层视频数据流的数量。\n[0090] 此外，视频会议终端还可用对视频数据流的发送速率进行调整。比如，对于支持自适应速率视频编解码算法的视频会议终端，可通过调整视频图像帧传输速率、视频图像的采样率、量化步长等参数来实现对扩展层视频数据流的发送速率的调整；\n[0091] 对于支持多种不同速率视频编解码算法的视频会议终端，当发送方视频会议终端由发送基本层视频数据流和扩展层视频数据流切换为只发送基本层视频数据流时，可与接收方视频会议终端进行重新协商后，采用较低速率的视频编解码算法将视频图编码为基本层视频数据流后进行发送。反之，当发送方视频会议终端由发送基本层视频数据流切换为发送基本层视频数据流和扩展层视频数据流切换时，可与接收方视频会议终端进行重新协商后，采用较高速率的视频编解码算法将视频图编码为基本层视频数据流和扩展层视频数据流后进行发送。\n[0092] 对应于本发明实施例提供的视频数据流的发送方法，本发明实施例还提供一种终端，其具体结构示意图如图4所示，包括以下功能单元：\n[0093] 状态信息获得单元41，用于获得本地多媒体装置的状态信息；\n[0094] 可选的，该状态信息获得单元41具体可以包括运行在该终端中的浏览器。该浏览器的主要作用在于：通过视频数据流发送终端的操作系统的应用程序编程接口API，确定本地语音接收设备是否被设置为静默状态；或根据浏览器自身的编解码输出/媒体数据输入接口所传输的针对视频会议的数据包的信息，确定本地语音接收设备是否被设置为静默状态；或确定浏览器自身针对视频会议状态的状态维护信息，并根据该状态维护信息确定本地语音接收设备是否处于暂停传输语音信号的状态等。\n[0095] 发送规则确定单元42，用于根据状态信息获得单元41获得的状态信息，确定视频数据流的发送规则；\n[0096] 可选的，该发送规则确定单元42可以为运行在终端中的浏览器。\n[0097] 可选的，该发送规则确定单元42具体可以包括运行在终端中的浏览器和由脚本程序实现的发送规则确定子单元。其中，浏览器用于通过API，将状态信息提供给发送规则确定子单元；而发送规则确定子单元用于根据浏览器提供的状态信息，确定视频数据流的发送规则。\n[0098] 发送单元43，用于根据发送规则确定单元42确定的发送规则，向接收方设备发送视频数据流。\n[0099] 可选的，当上述多媒体装置为语音接收设备时，发送规则确定单元42具体可以用于：\n[0100] 当语音接收设备的状态信息为持续接收语音信号时，确定向接收方设备发送基于分层视频编解码技术对获得的视频图像进行编码得到的基本层视频数据流和扩展层视频数据流；当语音接收设备的状态信息为未持续接收语音信号时，确定向接收方设备发送基于分层视频编解码技术对获得的视频图像进行编码得到的基本层视频数据流。\n[0101] 可选的，本发明实施例提供的上述终端还可以进一步包括下述单元，以实现根据状态信息对获取的视频图像进行显示：\n[0102] 第一显示规则确定单元，用于视频数据流发送终端根据状态信息获得单元41获得的状态信息，确定针对通过本地视频图像获取设备获取的视频图像的显示规则；\n[0103] 显示单元，用于根据第一显示规则确定单元确定的显示规则，显示通过本地视频图像获取设备获取的视频图像。\n[0104] 可选的，当上述多媒体装置为语音接收设备时，第一显示规则确定单元具体可以用于：当语音接收设备的状态信息为持续接收语音信号时，确定在视频数据流发送终端上运行的浏览器的第一窗口中显示获取的视频图像；当语音接收设备的状态信息为未持续接收语音信号时，确定在视频数据流发送终端上运行的浏览器的第二窗口中显示获取的视频图像；其中，第一窗口的面积大于第二窗口的面积。\n[0105] 可选的，为了实现对该终端接收到的视频数据流进行显示，该终端还可以进一步包括下述功能单元：\n[0106] 接收单元，用于接收其他视频数据流发送终端发送的视频数据流；层次信息确定单元，用于确定接收单元接收到的视频数据流的层次信息；第二显示规则确定单元，用于根据层次信息确定单元确定的层次信息，确定对接收单元接收的视频数据流解码得到的视频图像的显示规则。\n[0107] 可选的，上述发送单元43还可以进一步划分为以下功能子单元，包括：\n[0108] 编码子单元，用于根据所述发送规则，基于分层视频编解码技术对获得的视频图像进行编码；\n[0109] 发送子单元，用于向接收方设备发送编码子单元编码得到的视频数据流。\n[0110] 为了解决现有的视频数据流发送方案会产生不必要的传输开销的问题，本发明实施例还提供一种视频数据流的传输系统。该系统包括视频数据流发送终端和接收方设备，其具体功能如下：\n[0111] 视频数据流发送终端，用于获得本地多媒体装置的状态信息；并根据该状态信息，确定视频数据流的发送规则；以及根据该发送规则，向接收方设备发送视频数据流。\n[0112] 接收方设备，则用于接收视频数据流发送终端发送的视频数据流。\n[0113] 可选的，当上述多媒体装置为语音接收设备时，视频数据流发送终端具体用于：\n[0114] 当语音接收设备的状态信息为持续接收语音信号时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流和扩展层视频数据流；当语音接收设备的状态信息为未持续接收语音信号时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流。\n[0115] 可选的，当上述多媒体装置为视频图像显示设备时，视频数据流发送终端具体用于：\n[0116] 当视频图像显示设备的状态信息为显示关于视频会议的视频图像时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流和扩展层视频数据流；当视频图像显示设备的状态信息为没有显示关于视频会议的视频图像时，确定向接收方设备发送基于分层视频编解码技术，对通过本地视频图像获取设备获得的视频图像进行编码得到的基本层视频数据流。\n[0117] 可选的，为了确定对本地视频图像获取设备获取的视频图像的显示规则，视频数据流发送终端具体还可以用于：根据状态信息，确定针对通过本地视频图像获取设备获取的视频图像的显示规则；然后，再根据确定的显示规则，显示该获取的视频图像。比如，当多媒体装置为语音接收设备时，视频数据流发送终端具体可以用于：当语音接收设备的状态信息为持续接收语音信号时，确定在视频数据流发送终端上运行的浏览器的第一窗口中显示所述获取的视频图像；当语音接收设备的状态信息为未持续接收语音信号时，确定在视频数据流发送终端上运行的浏览器的第二窗口中显示所述获取的视频图像；其中，第一窗口的面积大于第二窗口的面积。\n[0118] 可选的，视频数据流发送终端还用于接收其他视频数据流发送终端发送的视频数据流。即视频数据流发送终端不仅仅可以发送视频数据流，也可以接收其他视频数据流发送终端发送来的视频数据流，从而也具备接收方设备的身份。本发明实施例中，视频数据流发送终端在接收到视频数据流后，根据该视频数据流的层次信息，就可以确定对接收的视频数据流解码得到的视频图像的显示规则。\n[0119] 可选的，视频数据流发送终端具体可以用于：调用运行在视频数据流发送终端中的浏览器通过视频数据流发送终端的操作系统的API，确定本地语音接收设备是否被设置为静默状态；或调用该浏览器根据浏览器自身的编解码输出/媒体数据输入接口所传输的针对视频会议的数据包的信息，确定本地语音接收设备是否被设置为静默状态；或调用该浏览器确定浏览器自身针对视频会议状态的状态维护信息，并根据该状态维护信息确定本地语音接收设备是否处于暂停传输语音信号的状态。\n[0120] 可选的，视频数据流发送终端具体可以用于：调用运行在视频数据流发送终端中的浏览器根据获得的状态信息，确定视频数据流的发送规则。\n[0121] 可选的，视频数据流发送终端具体还可以用于：调用运行在视频数据流发送终端中的浏览器通过API，将获得的状态信息提供给视频数据流发送终端中由脚本程序实现的发送规则确定单元；并调用发送规则确定单元根据该状态信息确定视频数据流的发送规则。\n[0122] 本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。\n[0123] 本发明是参照根据本发明实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。\n[0124] 这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。\n[0125] 这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。\n[0126] 尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。\n[0127] 显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。