CN103634611A - 一种视频服务器数据源处理方法及url映射方法 - Google Patents

Abstract

本发明是关于一种视频服务器数据源处理方法及url映射方法，所述的方法包括：获取数据源所提供的流媒体数据的类型信息；根据所述的流媒体数据的类型信息建立一第一虚基类，使所述的数据源继承所述的第一虚基类；为所述的第一虚基类提供统一的函数接口。本发明实施例提供的视频服务器数据源处理方法及url映射方法使用一种数据源的统一框架处理在视频服务器中遇到的各种数据源，便于对数据源进行统一的操作，使整个架构更清晰稳定，同时便于扩展，使数据源具备高度的可扩展性和可维护性的，简洁易用，同时将url与数据源一一对应的关系进行扩展，使一个数据源可以对应多个url。

Description

一种视频服务器数据源处理方法及url映射方法

技术领域

本发明是关于视频技术领域，尤其是关于视频服务器技术领域，具体来说是关于一种视频服务器数据源处理方法及url映射方法。

背景技术

在视频服务中，数据源主要用于提供相关的媒体数据以及媒体数据的相关属性信息。数据源是通过url（统一资源定位符，Uniform Resource Locator）进行标识的，即url为数据源的唯一标识符，当使用者需要请求某一数据源时是通过url进行匹配的。图1是现有技术提供的视频服务整体结构图，如图1所示，现有的视频服务器系统100包括：会话处理单元101、数据源单元102和媒体数据单元103，其中，数据源单元102从媒体数据单元103获取媒体数据，同时从获取到的媒体数据中解析出媒体数据的相关属性信息，为会话处理单元101提供媒体数据和媒体数据的相关属性信息。

现有技术中，数据源的实现采用的方式主要是对不同的数据源以不同的C++类进行实现，每增加一个数据源就需要增加一个相应的数据源类和数据接收类。图2是现有技术提供的数据源模块类图，如图2所示，数据接收类包括：CRtpProxyReceiver、CPvtFileReceiver、CPvtDecoderReceiver、CPvtNetReceiver和COtherDataReceiver，相对应的数据源类包括：CRtpProxySrc、CPvtFileSrc、CPvtDecoderSrc、CPvtNetSrc和COtherDataSrc，为方便描述，这里统一将数据接收类称为CXxxReceiver，将数据源类称为CXxxSrc。由CXxxReceiver类接收媒体数据并进行解析处理，解析出媒体数据的相关属性信息，然后由CXxxSrc向CSvrSession会话处理类提供其所需的媒体数据的相关属性信息。

在现有技术中，每一个数据源都是由CXxxReceiver类接收处理媒体数据，然后由CXxxSrc类提供CSvrSession会话处理类所需的媒体数据的相关属性信息。对于数据源所提供的媒体数据类型相同的情况下，由于很多处理逻辑是相同的，因此会出现很多冗余代码，并且当某一数据源类的处理逻辑发生变化时，其他数据源类中的处理逻辑也需做相应的变化，从而导致代码的变动牵一发而动全身。

在现有技术中，每一个数据源都是由CXxxSrc类提供CSvrSession会话处理类所需的媒体的相关属性信息。由于会话处理类所操作的是不同的CXxxSrc类，因此会话处理类需要区分不同的数据源而进行不同的处理，从而导致对数据源的管理和操作会变得复杂很多，而且一旦需要增加一个数据源时，会话处理类对于数据源的管理的操作又需要做相应的变动，也就是说数据源的可扩展性低。

现有技术中，数据源与url是一一对应的，即一个url对应一个数据源，当使用者需要请求某一数据源时需要通过指定的url进行匹配。由于数据源与url是一一对应的，体现给使用者的也是一个固定的url，因此使用者无法使用定制的url去匹配相应的数据源。

发明内容

为克服现有技术中存在的冗余代码过多，以及数据源可扩展性和可维护性低的问题，本发明提供一种视频服务器数据源处理方法及url映射方法。

本发明提供一种视频服务器数据源处理方法，所述的方法包括：获取数据源所提供的流媒体数据的类型信息；根据所述的流媒体数据的类型信息建立一第一虚基类，使所述的数据源继承所述的第一虚基类；为所述的第一虚基类提供统一的函数接口。

本发明还提供一种url的映射方法，所述的方法包括：建立请求url和真实url的映射关系；接收使用者的请求，获取请求url；根据所述的请求url，得到与所述的请求url相对应的真实url；根据所述的真实url获取数据源。

本发明实施例提供的视频服务器数据源处理方法及url映射方法使用一种数据源的统一框架处理在视频服务器中遇到的各种数据源，便于对数据源进行统一的操作，使整个架构更清晰稳定，同时便于扩展，使数据源具备高度的可扩展性和可维护性的，简洁易用，同时将url与数据源一一对应的关系进行扩展，使一个数据源可以对应多个url。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1是现有技术提供的视频服务整体结构图。

图2是现有技术提供的数据源模块类图。

图3是本发明实施例提供的一种视频服务器数据源处理方法流程图。

图4是本发明实施例提供的数据源模块类图。

图5是本发明实施例提供的一种视频服务器数据源处理方法流程图。

图6是本发明实施例提供的私有数据接收类图。

图7是本发明实施例提供的一种url的映射方法流程图。

图8所示为请求url与真实url的映射关系图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施方式和附图，对本发明做进一步详细说明。在此，本发明的示意性实施方式及其说明用于解释本发明，但并不作为对本发明的限定。

本发明实施例提供一种视频服务器数据源处理方法及url映射方法，以下结合附图对本发明进行详细说明。

实施例一：

图3是本发明实施例提供的一种视频服务器数据源处理方法流程图，如图3所示，视频服务器数据源处理方法包括：

S301，获取数据源所提供的流媒体数据的类型信息。

在本发明实施例中，将各种数据源根据数据源所提供的媒体数据的类型进行分类，根据现有的需求主要分为以下几种数据源：标准Rtp（Real-time Transport Protocol，实时传输协议）网络数据源、私有格式网络数据源、私有格式编码数据源、私有格式文件数据源以及其它扩展数据源。其中，标准Rtp网络数据源所提供的媒体数据为Rtp数据包，因此将其归纳为Rtp转发数据源。私有格式网络数据源、私有格式编码数据源、私有格式文件数据源所提供的媒体数据为私有格式数据帧，因此将其归纳为私有格式数据源。

S302，根据所述的流媒体数据的类型信息建立一第一虚基类，使所述的数据源继承所述的第一虚基类。

在本发明实施例中，根据步骤S301获取的流媒体数据的类型信息，可以将流媒体数据源可分为以下三类：Rtp转发数据源，私有格式数据源和其它扩展数据源。

Rtp转发数据源为使用者获取Rtp数据包并对数据进行解析，提取出媒体属性信息。最终将媒体属性信息提供给使用者，将Rtp数据包向使用者指定的网络地址进行网络发送。

私有格式数据源为使用者获取私有格式数据帧并对数据进行解析，提取出媒体属性信息。最终将媒体属性信息提供给使用者，将数据帧拆分为Rtp数据包，并向使用者指定的网络地址进行网络发送。

其他扩展数据源为使用者获取其他扩展数据并对其他扩展数据进行解析，提取出媒体信息。最终将媒体属性信息提供给使用者，将其他扩展数据拆分为Rtp数据包，并向使用者指定的网络地址进行网络发送。

对使用者而言，Rtp转发数据源，私有格式数据源和其它扩展数据源，都是为使用者提供媒体属性信息，以及向指定的网络地址发送Rtp数据包。Rtp转发数据源，私有格式数据源和其它扩展数据源都是以C++函数接口的形式为使用者提供以上服务，使用者通过调用数据源对应的C++函数接口以获取媒体属性信息，向指定的网络地址发送Rtp数据包。使用者并不关心数据源类型，即使用者并不关心数据源是Rtp转发数据源，私有格式数据源还是其他扩展数据源。但是使用者如果不知道数据源类型就不知道该调用Rtp转发数据源，私有格式数据源还是其他扩展数据源的C++函数接口。因此引入了一个C++虚基类，该虚基类拥有各类型数据源的C++函数接口，但是没有具体的函数实现，该C++虚基类称为数据源虚基类。Rtp转发数据源，私有格式数据源和其它扩展数据源都继承自数据源虚基类，对于数据源类型的分区的工作交由数据源虚基类处理。有了这个数据源虚基类，使用者就可以在不知道数据源类型的情况下，调用数据源虚基类的C++函数接口以获取媒体属性信息，向指定的网络地址发送Rtp数据包。

图4是本发明实施例提供的数据源模块类图，如图4所示，数据源虚基类为CDataSource，数据源实现类CRtpProxySrc、CPvtDataSrc、和COtherDataSrc继承虚基类CDataSource，数据接收类CRtpProxyReceiver、CPvDataReceive和COtherDataReceiver分别接收Rtp数据包、私有格式数据帧和其他格式数据包并进行解析处理，解析出相对应的相关属性信息，然后由相应的数据源实现类提取出媒体属性信息。使用者通过调用数据源虚基类的C++函数接口以获取媒体属性信息，向指定的网络地址发送Rtp数据包。

S303，为所述的第一虚基类提供统一的函数接口。

在本发明实施例中，对步骤S302中建立的C++虚基类提供统一的对外函数接口。由于使用者使用各类数据源的目的是一致的，都是为了获取媒体属性信息，向指定的网络地址发送Rtp数据包。因此各数据源实现类的C++函数接口可以定义为相同的函数接口，但是使用者还需要区分各数据源实现类才能知道该使用哪个数据源实现类的C++函数接口。数据源虚基类定义了数据源实现类的C++函数接口，各数据源实现类都继承自数据源虚基类。使用者只需要使用数据源虚基类提供的统一C++函数接口，就可以获取媒体属性信息，向指定的网络地址发送Rtp数据包。数据源虚基类提供了统一的C++函数接口，使用者就无需关心数据源类型，使使用者更便捷地使用数据源提供的功能。

在本发明的其他实施例中，当需要增加新的数据源时，可以使新的数据源继承自第一虚基类CDataSource，以使得新的数据源通过继承自第一虚基类CDataSource而实现其相应的功能。新增的数据源类继承自第一虚基类CDataSource，实现第一虚基类CDataSource定义的所有C++函数接口，然后在新增的数据源实现类中完成获取媒体属性信息和向指定的网络地址发送Rtp数据包功能。由于使用者仍然是调用数据源虚基类的C++函数接口，因此新增数据源后，使用者无需做任何变动。

图5是本发明实施例提供的一种视频服务器数据源处理方法流程图，如图5所示，视频服务器数据源处理方法包括：

S501，建立一第二虚基类；

在本发明实施例中，参见上述步骤S301和S302所述，私有格式网络数据源、私有格式编码数据源、私有格式文件数据源所提供的媒体数据均为私有格式数据帧，对于私有媒体数据的接收，不同的数据源对于媒体数据的获取方式不同，而且即使是相同的数据源对于媒体数据的获取方式也可能有多种，但是提供的媒体数据类型却是相同的，都是私有格式数据帧。因此提供一个C++虚基类，图6是本发明实施例提供的私有数据接收类图，如图6所示，第二虚基类为CStreamSource，CStreamSource可以具有多个派生类，派生类可分别对应私有格式网络数据源、私有格式编码数据源、私有格式文件数据源的媒体数据。

S502，为所述的第二虚基类提供统一的函数接口；

在本发明实施例中，为第二虚基类为CStreamSource提供统一的函数接口以用于获取私有格式数据帧，对于私有格式数据帧获取的具体实现由数据源模块外部根据具体需求特性进行相应的实现。第二虚基类CStreamSource的目的就是获取私有格式数据帧，但是私有格式网络数据源、私有格式编码数据源、私有格式文件数据源获取私有格式数据帧的方式并不相同。

对数据源而言，其并不关心私有格式数据帧的具体获取方式，只要调用第二虚基类CStreamSource的C++函数接口能得到私有格式数据帧就行。使用者才知道私有格式网络数据源、私有格式编码数据源、私有格式文件数据源获取私有格式数据帧的具体方法，因此由使用者继承第二虚基类为CStreamSource，对应不同的私用数据帧获取方式实现第二虚基类CStreamSource定义的C++函数接口。

S503，通过所述的第二虚基类获取具有相同类型信息的流媒体数据。

在本发明实施例中，外部继承该C++虚基类CStreamSource，并以相应的方式获取私有格式数据帧。私有格式网络数据源获取到私用格式数据帧，需要使用者从特定的网络地址进行网络接收；私有格式编码数据源获取到私有格式数据帧，需用使用者从特定的编码器上获取；私有格式文件数据源获取私有格式数据帧，需要使用者从特定的文件中读取。

本发明实施例提供的视频服务器数据源处理方法使用一种数据源的统一框架处理在视频服务器中遇到的各种数据源，便于对数据源进行统一的操作，使整个架构更清晰稳定，同时便于扩展，使数据源具备高度的可扩展性和可维护性的，简洁易用。

实施例二：

图7是本发明实施例提供的一种url的映射方法流程图，如图7所示，url的映射方法包括：

S701，建立请求url和真实url的映射关系。

在本发明实施例中，用户可以根据实际情况自定义请求url，请求url与真实url相对应，不与数据源直接对应，一条真实url可以与至少一条请求url相对应，以使得一条真实url可以扩展为多条请求url。在本发明实施例中，用户自定义请求url后建立请求url和真实url的映射关系，图8所示为请求url与真实url的映射关系图，如图8所示，4条不同的请求url可以映射到同一真实url。在本发明的其他实施例中，可以使用任意的请求url通过相应的映射关系将其映射到某一真实url上。

S702，接收使用者的请求，获取请求url。

在本发明实施例中，当使用者通过请求url请求数据源时，首先接收使用者的请求，获取请求url。

S703，根据所述的请求url，得到与所述的请求url相对应的真实url。

在本发明实施例中，获取到请求url之后，通过步骤S701中建立的映射关系，根据请求url映射到相对应的真实url。

S704，根据所述的真实url获取数据源。

在本发明实施例中，真实url与数据源是一一对应的，在步骤S703将请求url映射到真实url之后，根据真实url获取与之对应的数据源。

本发明实施例提供的视频服务器url映射方法将url与数据源一一对应的关系进行扩展，使一个数据源可以对应多个url。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种视频服务器数据源处理方法，其特征在于，所述的方法包括：

获取数据源所提供的流媒体数据的类型信息；

根据所述的流媒体数据的类型信息建立一第一虚基类，使所述的数据源继承所述的第一虚基类；

为所述的第一虚基类提供统一的函数接口。

2.根据权利要求1所述的视频服务器数据源处理方法，其特征在于，所述的方法还包括：

增加新的数据源；

使所述的新的数据源继承所述的第一虚基类。

3.根据权利要求1所述的视频服务器数据源处理方法，其特征在于，所述的数据源包括：标准Rtp网络数据源、私有格式网络数据源、私有格式编码数据源、私有格式文件数据源和其它扩展数据源。

4.根据权利要求3所述的视频服务器数据源处理方法，其特征在于，所述的标准Rtp网络数据源提供的流媒体数据的类型信息为Rtp数据包。

5.根据权利要求3所述的视频服务器数据源处理方法，其特征在于，所述的私有格式网络数据源、私有格式编码数据源和私有格式文件数据源提供的流媒体数据的类型信息为私有格式数据帧。

6.根据权利要求3-5所述的视频服务器数据源处理方法，其特征在于，所述的方法还包括：

建立一第二虚基类；

为所述的第二虚基类提供统一的函数接口；

通过所述的第二虚基类获取具有相同类型信息的流媒体数据。

7.一种url的映射方法，其特征在于，所述的方法包括：

建立请求url和真实url的映射关系；

接收使用者的请求，获取请求url；

根据所述的请求url，得到与所述的请求url相对应的真实url；

根据所述的真实url获取数据源。

8.根据权利要求7所述的url映射方法，其特征在于，所述的数据源与所述的真实url一一对应。

9.根据权利要求7所述的url映射方法，其特征在于，所述的真实url对应至少一条请求url。

Images