媒体数据控制方法及装置的利记博彩app

专利名称：媒体数据控制方法及装置的利记博彩app
技术领域：
本发 明涉及多媒体数据处理领域，特别是涉及媒体数据控制方法及装置。
背景技术：
NAT (Network Address Translation,网络地址转换)是一种将私网地址转换成公网地址的技术，需要将“私网IP地址+端口号”转换成“公网IP地址+端口号”。通过NAT技术，能够很好地解决IP地址不足的问题。在多媒体应用中，一个媒体内容可能包含多种数据类型(例如音频、视频及字幕等等)，传输时，通常采用地址复用的方式，即不同类型的数据公用一个I P地址，但是使用不同的UDP端口，以此来区分不同的数据类型。这样，当在私网与公网之间进行通信时，需要进行NAT转换的“私网IP地址+端口号”的数目，就与媒体内容中包含的数据类型的数目相同。随着SVC (Scalable Video Coding,可扩展视频编码)及 MVC(Multi_view VideoCoding，多视视频编码)等技术的出现，一种数据类型下又可能包含多种特性的数据(例如，在基于SVC的应用中，同样是视频数据，可能从不同帧率、不同分辨率、不同质量等方面又分为不同特性的视频数据，等等)。这就需要对各种数据类型的各种特性的数据进行区分。一种简单的区分方式仍然可以通过不同的端口号进行区分，但是，只要各种不同特性的数据对应的端口号不同，就要分别进行NAT转换，因此会造成需要进行NAT转换的“私网IP地址+端口号”数目会非常多，也即NAT的开销会比较大。因此，在另一种方式下，是一种类型下的不同特性的数据对应相同的I P地址及UDP端口号，从语法表示上对不同特性的数据加以区分。这就意味着，同一种类型下不同特性的数据通过同一个媒体流进行传输。然而，现有技术中，只能实现以媒体流为单位的控制。因此，在将同一种类型下不同特性的数据通过同一个媒体流进行传输的情况下，如果在实际应用中需要对不同特性数据进行独立控制，则现有技术无法实现。

发明内容
本发明提供媒体数据控制方法及装置，能够在将同一种类型下不同特性的数据通过同一个媒体流进行传输的情况下，实现对不同特性数据的独立控制。本发明一方面提供了一种媒体数据控制方法，包括接收终端发送的控制请求消息，所述控制请求消息中携带有子流的标识信息，以及所述子流所属媒体流的统一资源标识符URI ;获取所述子流的标识信息以及所述子流所属媒体流的URI ;根据所述子流的标识信息以及所述子流所属媒体流的URI，确定所述子流对应的媒体数据；基于所述媒体数据，对所述子流执行终端请求的控制操作。本发明另一方面提供了一种媒体数据控制装置，包括第一消息接收单元，用于接收终端发送的控制请求消息，所述控制请求消息中携带有子流的标识信息，以及所述子流所属媒体流的统一资源标识符URI ;信息获取单元，用于获取所述子流的标识信息以及所述子流所属媒体流的URI ;数据确定单元，用于根据所述子流的标识信息以及所述子流所属媒体流的URI，确定所述子流对应的媒体数据；媒体控制单元，用于基于所述媒体数据，对所述子流执行终端请求的控制操作。本发明再一方面提供了一种媒体数据控制方法，包括获取子流的标识信息以及所述子流所属媒体流的统一资源标识符URI ；向服务器发送携带有所述子流的标识信息，以及所述子流所属媒体流的URI的控制请求消息；接收到服务器返回的响应消息后，对所述子流进行相应的控制操作。
本发明又一方面提供了一种媒体数据控制装置，包括子流信息获取单元，用于获取子流的标识信息以及所述子流所属媒体流的统一资源标识符URI ;消息发送单元，用于向服务器发送携带有所述子流的标识信息，以及所述子流所属媒体流的URI的控制请求消息；操作执行单元，用于接收到服务器返回的响应消息后，对所述子流进行相应的控制操作。根据本发明提供的具体实施例，本发明公开了以下技术效果本发明实施例中，通过在终端发送的控制请求消息中携带子流的标识信息以及子流所属媒体流的URI，使得服务器在收到终端的控制请求消息时，能够获取到这两个信息，进而就可以根据这两个信息获取到终端请求的子流对应的媒体数据，然后就可以基于该媒体数据，对终端请求的子流进行相应的控制操作，例如，包括播放、暂停等等。因此，通过本发明实施例，可以使得即使在将同一种类型下不同特性的数据通过同一个媒体流进行传输的情况下，也能够实现对不同特性数据的独立控制。


为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图I是本发明实施例提供的方法的流程图；图2是本发明实施例提供的方法的第一示意图；图3是本发明实施例提供的方法的第二示意图；图4是本发明实施例提供的方法的第三示意图；图5是本发明实施例提供的装置的示意图；图6是本发明实施例提供的另一方法的流程图；图7是本发明实施例提供的另一装置的示意图。
具体实施例方式下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。
参见图1，本发明实施例提供的媒体控制方法包括以下步骤SlOl :接收终端发送的控制请求消息，所述控制请求消息中携带有子流的标识信息，以及所述子流所属媒体流的URI (Uniform Resource Identif ier,统一资源标识符)；需要说明的是，本发明实施例可以与RTSP协议相结合使用，其中的控制请求消息可以是RTSP PLAY请求消息或RTSP PAUSE请求消息等等。S102 :获取所述子流的标识信息以及所述子流所属媒体流的URI ；S103 :根据所述子 流的标识信息以及所述子流所属媒体流的URI，确定所述子流对应的媒体数据；子流是媒体流的一部分，并且子流可以独立解码。不同子流具备不同的媒体特征(媒体特征指帧率、分辨率、码率、或者视角等)，因此可以提供不同的观看效果。例如，媒体内容中的视频可以采用SVC进行编码。从时间、空间、质量等角度上进行划分，编码后的码流包含多层(分为基本层和增强层，基本层只有一个，增强层可以是多个)。其中，基本层可以独立解码，解码后获得的视频可能帧率较低、分辨率较低、或者质量较低，可以用于在带宽受限或者带宽不稳定的应用环境中，满足基本的观看需求。增强层不能独立解码，必须与和基本层及它之前的增强层(之前的增强层通常是指编码时依赖的层，相应的，解码时也需要依赖该层才能进行解码)联合在一起解码，用于提高观看效果，具体可以是从时间、空间、或者质量上对基本层提供的观看效果进行提高。SVC编码后输出的码流可以通过一个媒体流传输，即通过一个媒体流传输多层码流。其中，子流由一个或者多个层组成并且可以独立解码，即单独的基本层，或者基本层与一个或多个增强层的组合，都可以构成该媒体流中的子流。当然，需要说明的是，基本层并不是与任意的增强层组合都可以构成一个子流，只有能够独立解码的组合才可以构成子流。例如，SVC码流包括基本层、增强层A和增强层B，对于增强层A和增强层B，基本层+增强层A+增强层B能够独立解码，则该组合可以构成一个子流；而基本层+增强层B不能够独立解码，则该组合不可以构成一个子流。又如，如果媒体内容中的视频是多视视频(多视视频是指由所处几何位置不同的多个摄像机输出的多路视频，每一路视频简称为一个视，这里的摄像机可以是虚拟的摄像机)，可以采用MVC对多视视频进行编码得到码流，编码过程中可以选择其中一路视频作为基本视，对基本视编码时不需要进行视间预测，因此可以独立解码。其它视用于提供视角上的可扩展性，编码时需要进行视间预测，因此不能独立解码，只能和基本视及它编码时所依赖的视联合在一起解码。MVC编码后输出的码流可以通过一个媒体流传输，即通过一个媒体流传输多视。其中，子流由一个或者多个视组成并且可以独立解码，即单独的基本视，或者基本视与其他视中的一个或多个的组合，都可以构成该媒体流中的子流。当然，需要说明的是，基本视并不是与任意的其他视组合都可以构成子流，只有能够独立解码的组合才可以构成子流。例如，MVC码流包括基本视、其他视A和其他视B。对于其他视A和其他视B，基本视+其他视A+其他视B能够独立解码，则该组合可以构成一个子流；而基本视+其他视B不能够独立解码，则该组合不可以构成一个子流。另外，MVC还支持时间可伸缩性，即还可以从时间角度上进行划分，将每个视的码流分为多层。此时子流的构成还需要考虑时间可伸缩性引入的解码依赖关系。即某个其它视的某个时间级别的层(简称时间层)，要和基本视及它编码时所依赖的视中时间级别相同或者更低的层联合在一起解码。无论是SVC还是MVC，不同的子流提供不同的观看效果，同时，对带宽等通信环境的要求、对终端能力的要求也会不同。因此，如果能够实现基于子流的单独控制，则用户或者终端可以根据当前的带宽条件、终端能力等因素选择性地接收子流，从而有利于在播放效果与播放流畅度之间达到均衡。在本发明实施例中，为了实现基于子流的控制，需要终端在该控制请求中携带子流的标识信息，以及所述子流所属媒体流的URI。其中，子流的标识信息是指，在子流对应的媒体流中能够唯一标识一个子流的信息，下面对此进行介绍。例如，在SVC 中，可以米用 dependency_id (D)、temporal_id (T)、quality_id (Q)来标识不同的层。其中，dependency_id为依赖标识，temporal _id为时间标识，quality_id为质量标识。因此，终端就可以在控制请求消息中携带具体的(D，T，Q)的值作为子流的标识信息，相应的，服务器在根据媒体流URI找到媒体流对应的数据之后，就可以进一步根据具体的(D，T，Q)的值，找到子流对应的数据。在MVC中，子流可以采用temporal_id、view_id标识不同视的不同时间层。其中，temporal_id为时间标识，view_id为视标识。因此，终端就可以在控制请求消息中携带具体的temporal-id和view_id的值作为子流的标识信息,相应的,服务器在根据媒体流URI找到媒体流对应的数据之后，就可以进一步根据解析出的temporal-id和view_id的值,找到子流对应的数据。总之，无论在SVC还是MVC下，终端都可以通过在控制消息中携带子流的标识信息及子流所属媒体流的URI，以便使得服务器获知终端想要控制的是哪个媒体流的哪个子流。其中，关于子流的标识信息及子流所属的媒体流的URI，终端可以首先获取媒体内容的描述信息，从描述信息中获取。其中，终端获取媒体内容的描述信息的途径可以有多种。例如，可以预先通过HTTP协议向存储有媒体内容的描述信息的服务器发起获取媒体描述信息的HTTP请求，从服务器获取该描述信息、或者预先接收携带有媒体内容的描述信息的电子邮件，从电子邮件中获取该描述信息，当然，还可以向服务器发起获取媒体描述信息的RTSP请求，从服务器获取该描述信息。例如，在终端发起控制请求之前，可以首先向服务器发送描述信息请求消息，所述描述信息请求消息为RTSP Describe请求消息，服务器在收到该消息之后，就可以向终端返回媒体内容的描述信息，该描述信息中就可以包括媒体流的个数、各媒体流的URI、各媒体流递送采用的协议、传输协议参数、媒体编码信息等等，此外还可以包括媒体流中所有子流的声明信息。因此，通过解析该服务器返回的该响应消息，终端就可以获取到媒体流的URI，以及媒体流的子流的声明信息，进而从子流的声明信息中就可以获取到各子流的标识信息。具体实现时，可以将子流的声明信息作为媒体描述信息的一部分，并将媒体描述信息制作成SDP文件。在SDP文件中，为了让终端知道SVC码流中包含哪些层，服务器可以通过SDP文件中的参数向终端声明SVC码流中各个层的(D，T，Q)值(或者layer_id值，layer_id为层标识)，并指明哪些层可以组合为子流，这样终端就可以直接将需要的子流对应的各个层的(D，T，Q)值或者layer_id值作为子流标识信息发送给服务器，相应的，月艮务器解析出的子流对应的各个层的(D，T，Q)值或者layer_id值。在解析出(D，T，Q)值或者layer_id值之后，服务器分别按照各层的(D，T，Q)值或者layer_id值去获取各层对应的数据即可。此外，在实际应用中，还可以采用另一种方式实现，具体可以是在SDP文件中的参数中，通过属性行a = fmtp中的参数sprop-operat ion-point-info携带一组操作点描述矢量，一个操作点描述矢量用来声明一个操作点。操作点描述矢量的格式可以为<layer-ID, temporal-ID, dependency-ID, quality-ID, profiIe-level-ID,avg-framerate, width, height, avg-bitrate, max_bitrate>0 其中 layer-ID 为操作点的层标识，temporal-ID为操作点的时间标识，dependency-ID为操作点的依赖标识，quality-ID为操作点的质量标识，profile-level-ID为操作点的层级标识，avg-framerate为操作点的平均巾贞率,width为操作点对应的视频巾贞的宽度,height为操作点对应的视频巾贞的高度，avg-bitrate为操作点的平均码率,max-bitrate为操作点的最大码率。
其中，操作点的layer_ID、t emporal-ID>dependency-ID>quality-ID 的值分别等于操作点对应的解码依赖性最高的层的layer_id、temporal_id、dependency_id、quality_id 的值。可见，操作点既可以用 dependency_id(D)、temporal_id(T)、quality_id(Q)的组合进行标识，也可以用layer_id进行标识，并且，一个layer_id对应着一个D、T、Q的组合。操作点对应的是相应的层和它之前的所有层，也即所有(D，T，Q)的值分别小于等于该操作点的(D,T,Q)的值的NAL(Network Abstraction Layer,网络提取层)包组成的码流。因此，一个操作点对应着一个能够独立解码并且具备特定媒体特征的码流，也就是说，一个操作点对应着一个子流。这样，如果终端需要对某子流进行控制，则直接将对应的操作点的(D，T，Q)值或者layer-ID值作为子流的标识信息发送给服务器即可。相应的，服务器解析出的是操作点的(D，T，Q)值或者I ayer-ID值。其中，如果解析出的是操作点的(D，T，Q)值，则服务器就可以直接将(D，T，Q)的取值分别小于等于服务器解析出的(D，T，Q)的取值的NAL包构成子流对应的媒体数据；例如，服务器从终端的控制请求消息中解析出的(D，T，Q)值是(1，1，0)，则服务器可以将(D，T，Q)值为(1，1，0)、(1,0,0), (0,1,0), (0,0,0)的NAL包取出，构成子流的媒体数据。或者，如果服务器解析出的是操作点的Iayer-ID值，则可以首先将I ayer-ID的取值转换为(D，T，Q)值，然后再将(D，T，Q)的取值小于等于服务器解析出的(D，T，Q)的取值的NAL包构成子流对应的媒体数据。服务器通过查询Iayer-ID与(D，T，Q)之间的对应关系，将Iayer-ID的取值转换为(D，T，Q)值。该Iayer-ID与(D，T，Q)的对应关系可以是预先存储在服务器上的，例如，可以存放在上述SDP文件中，也可以存放在 SVC 码流的 scalability information SEI message 中。对于MVC而言，为了向终端声明MVC码流中包含哪些子流，服务器同样可以通过SDP文件中的参数向终端声明MVC码流中包含的视的view_id值以及每个视的时间层的temporaljd值，并指明哪些视的哪些时间层可以组合为子流。这样终端就可以直接将需要的子流对应的各个视的各个时间层的temporal_id和view_id值作为子流标识信息发送给服务器，相应的，服务器也可以在解析出temporal_id和view_id之后,分别去获取各视的各个时间层对应的数据即可。在实际应用中，也可以通过SDP文件中的参数向终端声明MVC码流中包含哪些操作点。具体方式可以是通过属性行a = fmt p中的参数sprop-mvc-operation-point-info携带一组操作点描述矢量，一个操作点描述矢量用来声明一个操作点。操作点描述矢量的格式为〈operation-point_id, temporal-id, num-target-output-views,l*target-output-view-id, profile—level_id, avg-framerate, avg-bitrate,max-bitrate>。其中operation-point-id为操作点的标识，temporal-ID为操作点的时间标识，num-target-output-views为操作点的目标输出视的个数，view-id为操作点的目标输出视的标识，profile-level-ID为操作点的层级标识，avg-framerate为操作点的平均帧率，width为操作点对应的视频帧的宽度，height为操作点对应的视频帧的高度，avg-bitrate为操作点的平均码率，max-bitrate为操作点的最大码率。其中，操作点的temporal-id、target-output-view-id分别等于该操作点对应的所有视的所有时间层中时间级别最高的层的temporaljd、该操作点对应的目标输出视的 view_id。可见，操作点既可以用 temporal_id 和一组 view_id(target output view的view_id)进行标识,也可以用operation_point_id进行标识。但操作点对应的是所有temporal_id的取值(对应着巾贞率)小于等于该temporal_id值 ,并且view_id的取值等于该组view_id值中的任一个,或者该组view_id值对应的任一 view解码所依赖(直接依赖或者间接依赖)的所有view的view_id值中的任一个的NAL包组成的码流，因此,一个操作点对应着一个能够独立解码并且具备特定媒体特征的码流，也就是说，一个操作点对应的一个子流，因此，终端也可以将子流对应的操作点的temporal_id和一组view_id(targetoutput view的view_id)或者operation-point-id作为子流标识信息携带在控制请求消息中。当然，由于服务器最终还是要根据具体的temporal-id及view_id值来查找子流对应的具体数据，因此，当终端将operation_point_id作为子流标识信息时,服务器进一步根据 operation_point_id 与 temporal_id 和 target_output_view_id 组合的对应关系确定操作点对应的temporal_id与一组target output view的view_id。这种对应关系可以有多种获取方法。如，可以从对应的SDP文件中的子流声明信息中获取，也可以通过服务器上存放的MVC码流中的view scalability info SEI message中获取。为了确定子流对应的媒体数据，服务器还需要进一步根据view之间的解码依赖关系,确定该组target outputviews解码依赖(直接依赖或者间接依赖)的view的view_id。解码依赖关系可以根据MVC文件中的元数据(MVC码流以文件的形式存放在服务器上，文件中除了 MVC码流外，还有用于描述MVC文件的元数据)获取,如根据ViewIdentifierBox获取。相应媒体资源中所有包头中的temporal_id的取值小于等于获得的temporal_id的值,且view_id的取值等于服务器获得的一组 view_id 的值(target output view 的 view_id 的值、target outputview解码依赖的view的view_id的值)中的某个取值的NAL包构成子流对应的媒体数据。当然，如果不是以SDP文件格式发送描述信息，则可以为服务器生成一个携带媒体流中的子流声明信息的头域，并在对描述信息请求消息的响应消息中携带该头域，这样，终端可以通过解析该响应消息的头域，获知子流声明信息。具体的，所述描述信息请求消息为RTSP Describe请求消息，所述对描述信息请求消息的响应消息为RTSP Describe的成功响应消息。服务器通过RTSPDescribe的成功响应消息中的头域携带子流声明信息时，对于一个包含子流的媒体流，其子流声明信息由可以包括子流所属的媒体流的URI和一组操作点描述矢量(可以与前文所述的操作点描述矢量一致)，每个操作点描述矢量都声明一个操作点(每个操作点对应一个子流)。若有多个媒体流中包含子流时，该头域中携带的是一组子流声明信息，分别对应不同的媒体流。不同媒体流的子流声明信息之间采用特殊字符进行分隔，以便于服务器区分，这可以通过语法上的定义来实现。在互联网标准中通常采用ABNF来描述语法定义，具体通过ABNF描述携带子流声明信息的头域的语法定义如下所述。其中，通过“分号”分隔不同媒体流的子流声明信息，这样，当终端解析该头域时，可以根据“分号”来区分出一个个的媒体流对应的子流声明信息。
substream-info = “substream-info，，HCOLON [substream-info-spec
*{semi substream-spec)]substream-info-spec = stream-url substream-type I * descriptor-vectorstream-url = <as defined in draft-ietf-mmusic-rfc2326bis-27>substream-type = “type” EQUAL substream-type-value substream-type-value =“SVC” / “MVC” / substream-type-value-extsubstream-type-value-ext = token
descriptor-vector = RAQUOT layer—id—value COMMA temporal—id—value
COMMA dependency—id—value COMMA quality—id—value COMMA profile—level—id—value COMMA avgframeratevalue
COMMA width—value COMMA height—value COMMAavg—bitrate—value COMMA max—bitrate—value LAQUAT/ RAQUOT operation_point_id_value COMMAtemporal—id—value
COMMA num—target—output—views—value
I* (COMMA target—output—view—id—value)
COMMA profile—level—id—valueCOMMA avg framerate value
COMMA avg—bitrate—value COMMA max—bitrate—value LAQUAT
/ descriptor-vector-ext layer—id—value = 1*4DIGIT; 0-2047 dependency—id—value = DIGIT ; 0 7 temporal—id—value = DIGIT ; 0 7 quality—id—value = 1*2DIGIT; 0~15 profile—level—id—value = *HEX avg—frame—rate—vale = * DIGIT width—value = * DIGIT height—value = *DIGIT avg—bitrate—value = * DIGIT max—bitrate—value = * DIGIT operation_point—id—value = 1*5DIGIT; 0-65535 num—target—output—views—value = P4DIGIT; 0-1023 target—output—view—id—value = 1*4DIGIT; 0-1024 descriptor-vector-ext = token HCOLON = *(SP/HT)":M SWS SWS = [LWS] ; Separating White Space LWS = [CRLF] 1*( SP / HT ); Line-breaking White Space
权利要求
1.一种媒体数据控制方法，其特征在于，包括 接收终端发送的控制请求消息，所述控制请求消息中携带有子流的标识信息，以及所述子流所属媒体流的统一资源标识符URI ;获取所述子流的标识信息以及所述子流所属媒体流的URI ； 根据所述子流的标识信息以及所述子流所属媒体流的URI，确定所述子流对应的媒体数据； 基于所述媒体数据，对所述子流执行终端请求的控制操作。
2.根据权利要求I所述的方法，其特征在于，当所述控制请求消息为基于单个媒体流的单独控制请求消息时，所述子流的标识信息通过所述控制请求消息的头域携带，所述子流所属媒体流的URI通过所述控制请求消息的request-uri字段携带；或当所述控制请求消息为基于单个媒体流的单独控制请求消息时，所述子流的标识信息及所述子流所属媒体流的URI均通过所述控制请求消息的request-uri字段携带；或当所述控制请求消息为基于多个媒体流的合控制请求消息时，所述子流的标识信息及所述子流所属媒体流的URI均通过所述控制请求消息的头域携带。
3.根据权利要求I或2所述的方法，其特征在于，所述接收终端发送的控制请求消息之前还包括 接收终端发送的描述信息请求消息； 向所述终端返回携带有子流声明信息的响应消息，以便所述终端通过所述子流声明信息获取所述子流的标识信息。
4.根据权利要求I或2所述的方法，其特征在于，所述获取所述子流的标识信息之后，该方法还包括 确定所述控制请求消息中携带的子流的标识信息错误，向所述终端返回携带有子流声明信息的响应消息，以便所述终端根据所述响应消息中携带的子流声明信息重新获取子流的标识信息，并重新发送控制请求消息。
5.根据权利要求I或2所述的方法，其特征在于，所述控制请求消息中还携带有子流控制特征标签，所述方法还包括 获取所述子流控制特征标签； 如果能正确识别所述子流控制特征标签，则继续执行所述获取所述子流的标识信息以及所述子流所属媒体流的URI及后续操作，否则拒绝所述控制请求，向终端返回携带有不支持子流控制的信息的响应消息。
6.根据权利要求I或2所述的方法，其特征在于，所述接收所述终端发送的控制请求消息之前还包括 接收所述终端发送的RTSP SETUP请求消息，所述RTSP SETUP请求消息中携带有子流控制特征标签； 获取所述子流控制特征标签； 如果能正确识别所述子流控制特征标签，则向终端返回携带有支持子流控制的信息的响应消息，以便所述终端发起子流控制；否则，向终端返回携带有不支持子流控制的信息的响应消息。
7.根据权利要求I或2所述的方法，其特征在于，所述控制请求消息中还携带有子流的编码类型信息，还包括 根据所述子流的编码类型信息获取所述子流的编码类型并根据所述编码类型确定所述子流标识信息对应的子流。
8.一种媒体数据控制装置，其特征在于，包括 第一消息接收单元，用于接收终端发送的控制请求消息，所述控制请求消息中携带有子流的标识信息，以及所述子流所属媒体流的统一资源标识符URI ;信息获取单元，用于获取所述子流的标识信息以及所述子流所属媒体流的URI ； 数据确定单元，用于根据所述子流的标识信息以及所述子流所属媒体流的URI，确定所述子流对应的媒体数据； 媒体控制单元，用于基于所述媒体数据，对所述子流执行终端请求的控制操作。
9.根据权利要求8所述的装置，其特征在于，还包括 第二消息接收单元，用于接收终端发送的描述信息请求消息； 第一响应单元，用于向所述终端返回携带有子流声明信息的响应消息，以便所述终端通过所述子流声明信息获取所述子流的标识信息。
10.根据权利要求8所述的装置，其特征在于，还包括 错误控制单元，用于确定所述控制请求消息中携带的子流的标识信息错误，向所述终端返回携带有子流声明信息的响应消息，以便所述终端根据所述响应消息中携带的子流声明信息重新获取子流的标识信息，并重新发送控制请求消息。
11.根据权利要求8所述的装置，其特征在于，所述控制请求消息中还携带有子流控制特征标签；所述装置还包括 第一子流控制特征标签获取单元，用于获取所述子流控制特征标签； 第一控制单元，用于如果能正确识别所述子流控制特征标签，，则触发所述消息解析单元继续执行所述获取所述子流的标识信息以及所述子流所属媒体流的URI及后续操作，否则拒绝所述控制请求，向终端返回携带有不支持子流控制的信息的响应消息。
12.根据权利要求8所述的装置，其特征在于，所述装置还包括 第二子流控制特征标签获取单元，用于接收所述终端发送的RTSP SETUP请求消息，所述RTSP SETUP请求消息中携带有子流控制特征标签；获取所述子流控制特征标签； 第二控制单元，用于如果能正确识别所述子流控制特征标签，则向终端返回携带有支持子流控制的信息的响应消息，以便所述终端发起子流控制；否则，向终端返回携带有不支持子流控制的信息的响应消息。
13.根据权利要求8所述的装置，其特征在于，所述控制请求消息中还携带有子流的编码类型信息，还包括 编码类型获取单元，用于根据所述子流的编码类型信息获取所述子流的编码类型，以便根据所述编码类型确定所述子流标识信息对应的子流。
14.一种媒体数据控制方法，其特征在于，包括 获取子流的标识信息以及所述子流所属媒体流的统一资源标识符URI ； 向服务器发送携带有所述子流的标识信息，以及所述子流所属媒体流的URI的控制请求消息； 接收到服务器返回的响应消息后，对所述子流进行相应的控制操作。
15.根据权利要求14所述的方法，其特征在于，当所述控制请求消息为基于单个媒体流的单独控制请求消息时，所述子流的标识信息通过所述控制请求消息的头域携带，所述子流所属媒体流的URI通过所述控制请求消息的request-uri字段携带；或当所述控制请求消息为基于单个媒体流的单独控制请求消息时，所述子流的标识信息及所述子流所属媒体流的URI均通过所述控制请求消息的request-uri字段携带；或当所述控制请求消息为基于多个媒体流的合控制请求消息时，所述子流的标识信息及所述子流所属媒体流的URI均通过所述控制请求消息的头域携带。
16.根据权利要求14或15所述的方法，其特征在于，所述获取子流的标识信息以及所述子流所属媒体流的URI包括 向所述服务器发送描述信息请求消息； 从所述服务器返回的携带有子流声明信息的响应消息中，获取所述子流的标识信息以及所述子流所属媒体流的URI。
17.根据权利要求14或15所述的方法，其特征在于，还包括 如果在发送所述控制请求消息之后，接收到服务器返回的携带有子流声明信息的响应消息，则根据所述响应消息中携带的子流声明信息重新获取子流的标识信息，并重新发送控制请求消息。
18.根据权利要求14或15所述的方法，其特征在于，所述控制请求消息中还携带有子流控制特征标签，以便当所述服务器不支持子流控制时，向终端返回携带有不支持子流控制的信息的响应消息。
19.根据权利要求14或15所述的方法，其特征在于，向服务器发送携带有所述子流的标识信息，以及所述子流所属媒体流的URI的控制请求消息之前，还包括 向所述服务器发送RTSP SETUP请求消息，并在所述RTSP SETUP请求消息中携带子流控制特征标签，以便当所述服务器不支持子流控制时，向终端返回携带有不支持子流控制的信息的响应消息。
20.根据权利要求14或15所述的方法，其特征在于，所述控制请求消息中还携带有子流的编码类型信息，以便所述服务器根据所述子流的编码类型信息获取所述子流的编码类型，根据所述编码类型确定所述子流标识信息对应的子流。
21.一种媒体数据控制装置，其特征在于，包括 子流信息获取单元，用于获取子流的标识信息以及所述子流所属媒体流的统一资源标识符URI ； 消息发送单元，用于向服务器发送携带有所述子流的标识信息，以及所述子流所属媒体流的URI的控制请求消息； 操作执行单元，用于接收到服务器返回的响应消息后，对所述子流进行相应的控制操作。
22.根据权利要求21所述的装置，其特征在于，当所述控制请求消息为基于单个媒体流的单独控制请求消息时，所述子流的标识信息通过所述控制请求消息的头域携带，所述子流所属媒体流的URI通过所述控制请求消息的request-uri字段携带；或当所述控制请求消息为基于单个媒体流的单独控制请求消息时，所述子流的标识信息及所述子流所属媒体流的URI均通过所述控制请求消息的request-uri字段携带；或当所述控制请求消息为基于多个媒体流的合控制请求消息时，所述子流的标识信息及所述子流所属媒体流的URI均通过所述控制请求消息的头域携带。
23.根据权利要求21或22所述的装置，其特征在于，所述子流信息获取单元包括 描述信息请求消息发送子单元，用于向所述服务器发送描述信息请求消息； 获取子单元，用于从所述服务器返回的携带有子流声明信息的响应消息中，获取所述子流的标识信息以及所述子流所属媒体流的URI。
24.根据权利要求21或22所述的装置，其特征在于，还包括 重新发送单元，用于如果在发送所述控制请求消息之后，接收到服务器返回的携带有子流声明信息的响应消息，则根据所述响应消息中携带的子流声明信息重新获取子流的标识信息，并重新发送控制请求消息。
25.根据权利要求21或22所述的装置，其特征在于，所述控制请求消息中还携带有子流控制特征标签，以便当所述服务器不支持子流控制时，向终端返回携带有不支持子流控制的信息的响应消息。
26.根据权利要求21或22所述的装置，其特征在于，还包括 RTSP SETUP请求消息发送单元，用于向所述服务器发送RTSP SETUP请求消息，并在所述RTSP SETUP请求消息中携带子流控制特征标签，以便当所述服务器不支持子流控制时，向终端返回携带有不支持子流控制的信息的响应消息。
27.根据权利要求21或22所述的装置，其特征在于，所述控制请求消息中还携带有子流的编码类型信息，以便所述服务器根据所述子流的编码类型信息获取所述子流的编码类型，根据所述编码类型确定所述子流标识信息对应的子流。
全文摘要
本发明公开了媒体数据控制方法及装置，其中一种方法包括接收终端发送的控制请求消息，所述控制请求消息中携带有子流的标识信息，以及所述子流所属媒体流的统一资源标识符URI；获取所述子流的标识信息以及所述子流所属媒体流的URI；根据所述子流的标识信息以及所述子流所属媒体流的URI，确定所述子流对应的媒体数据；基于所述媒体数据，对所述子流执行终端请求的控制操作。通过本发明，能够在将同一种类型下不同特性的数据通过同一个媒体流进行传输的情况下，实现对不同特性数据的独立控制。
文档编号H04L29/06GK102857478SQ20111018211
公开日2013年1月2日 申请日期2011年6月30日 优先权日2011年6月30日
发明者张园园, 乐培玉, 石腾, 惠宇 申请人:华为技术有限公司