ES2625512T3 - Procedimiento y aparato de control de datos multimedia - Google Patents

Procedimiento y aparato de control de datos multimedia Download PDF

Info

Publication number
ES2625512T3
ES2625512T3 ES12797017.6T ES12797017T ES2625512T3 ES 2625512 T3 ES2625512 T3 ES 2625512T3 ES 12797017 T ES12797017 T ES 12797017T ES 2625512 T3 ES2625512 T3 ES 2625512T3
Authority
ES
Spain
Prior art keywords
control
secondary flow
request message
terminal
stream
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES12797017.6T
Other languages
English (en)
Inventor
Yuanyuan Zhang
Peiyu Yue
Teng Shi
Yu Hui
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES2625512T3 publication Critical patent/ES2625512T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management e.g. creating a master electronic programme guide from data received from the Internet and a Head-end or controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8352—Generation of protective data, e.g. certificates involving content or source identification data, e.g. Unique Material Identifier [UMID]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un procedimiento de control de datos multimedia realizado por un aparato servidor, caracterizado por que comprende: recibir un mensaje de petición de control enviado por un terminal (E101), en donde el mensaje de petición de control transporta información de identificación de un flujo secundario y un identificador de recursos uniforme URI de un tren de medios al que pertenece el flujo secundario; en donde el mensaje de petición de control es un mensaje de petición PLAY, RTSP, protocolo de transmisión en tiempo real, o un mensaje de petición RTSP PAUSE; obtener la información de identificación del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario (E102); determinar, según la información de identificación del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario, datos multimedia del flujo secundario (E103); y realizar, basado en los datos multimedia, una operación de control solicitada por el terminal, para el flujo secundario (E104); en donde, la operación de control es control reproducción o control pausa; en donde antes de recibir un mensaje de petición de control enviado por un terminal, el procedimiento comprende además: recibir un mensaje de petición de información de descripción enviado por el terminal; y devolver al terminal un mensaje de respuesta que transporta información de declaración del flujo secundario, de manera que el terminal obtiene la información de identificación del flujo secundario según la información de declaración del flujo secundario; o en donde antes de recibir un mensaje de petición de control enviado por el terminal, el procedimiento comprende además: recibir un mensaje de petición RTSP SETUP enviado por el terminal, en donde el mensaje de petición RTSP SETUP transporta una etiqueta de función de control del flujo secundario; obtener la etiqueta de función de control del flujo secundario; y, si la etiqueta de función de control del flujo secundario puede ser identificada correctamente, devolver un mensaje de respuesta que transporta información que indica que el control del flujo secundario es soportado por el terminal, de manera que el terminal inicia el control del flujo secundario; de lo contrario, devolver un mensaje de respuesta que transporta información que indica que el control del flujo secundario no es soportado por el terminal.

Description

5
10
15
20
25
30
35
40
45
50
DESCRIPCION
Procedimiento y aparato de control de datos multimedia.
Campo tecnico
La presente invencion se refiere al campo del procesamiento de datos multimedia y, en particular, a un procedimiento y aparato de control de datos multimedia.
Antecedentes
La NAT (Network Address Translation, traduccion de direcciones de red) es una tecnologfa para traducir una direccion de red privada en una direccion de red publica, para lo cual necesita traducir "una direccion IP privada + un numero de puerto" en "una direccion IP publica + un numero de puerto". La tecnologfa NAT puede resolver bien la escasez de direcciones IP.
En una aplicacion multimedia, un contenido multimedia puede incluir multiples tipos de datos (por ejemplo, audio, video y subtttulos). Durante la transmision, se utiliza generalmente una forma de reutilizacion de las direcciones, es decir, diferentes tipos de datos comparten una direccion IP pero utilizan diferentes puertos UDP para distinguir diferentes tipos de datos. Por lo tanto, durante la comunicacion entre una red privada y una red publica, el numero de "direcciones IP privadas + numeros de puerto" que requieren NAT es el mismo que el numero de tipos de datos incluidos en el contenido multimedia.
Con la aparicion de tecnologfas tales como SVC (Scalable Video Coding, codificacion de video escalable) y MVC (Multi-view Video Coding, codificacion de video multivision), un tipo de datos puede incluir datos de multiples funciones (por ejemplo, en una aplicacion basada en SVC, los mismos datos de video pueden dividirse ademas en datos de video de diferentes funciones en cuanto a diferentes frecuencias de fotogramas, diferentes resoluciones, diferente calidad, etc.). Por lo tanto, es necesario distinguir los datos de diferentes funciones bajo diferentes tipos de datos. Una manera diferenciadora sencilla no deja de ser diferenciar segun numeros de puerto diferentes. Sin embargo, siempre y cuando los numeros de puerto correspondientes a los datos de las diferentes funciones sean diferentes, la NAT debe realizarse, respectivamente, dando como resultado un gran numero de "direcciones IP privadas + numeros de puerto" que requieren NAT, es decir, dando como resultado gran sobrecarga de NAT.
De otra manera, los datos de diferentes funciones bajo un tipo corresponden a la misma direccion IP y numero de puerto UDP, y los datos de diferentes funciones se distinguen por la sintaxis. Esto significa que los datos de diferentes funciones bajo el mismo tipo se transmiten a traves del mismo tren de medios.
Sin embargo, en la tecnica anterior, el control se puede realizar solamente en unidades de trenes de medios. Por lo tanto, cuando los datos de diferentes funciones bajo el mismo tipo se transmiten a traves del mismo tren de medios, si se necesita un control independiente para los datos de diferentes funciones en una aplicacion real, la tecnica anterior no puede aplicar dicho control.
El documento "An Overlay Architecture of Global Inter-Data Center Networking for Fast Content Delivery" (YASUHIRO MIYAO, ICC 2011-2011 IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS-5-9 JUNIO 2011-KYOTO, JAPON, paginas 1-6) describe una arquitectura de superposicion de interconectividad global de centros de datos para una rapida entrega del contenido. Como se describe en este documento, el archivo se segmenta, por adelantado, en bloques, y se envfan de una manera de turno rotatorio sobre multiples conexiones paralelas (vease la seccion V, parte A de dicho documento).
El documento US 7 055 169 B2 describe una metodologfa para permitir la creacion y/o control de contenidos televisivos interactivos empleando directivas de tipo declarativo tales como HTML, lenguajes de programacion u otros lenguajes.
El documento US 7 895 350 B1 describe un procedimiento para procesar un flujo de datos de entrada para identificar flujos secundarios de interes para el procesamiento y enrutamiento adicionales de los flujos secundarios a los destinos correspondientes para el procesamiento adicional.
Compendio
La presente invencion proporciona un procedimiento y un aparato de control de datos multimedia que pueden aplicar un control independiente a datos de diferentes funciones bajo el mismo tipo en el caso en que los datos de funciones diferentes se transmitan a traves de mismo tren de medios.
En un aspecto, la presente invencion proporciona un procedimiento de control de datos multimedia, que incluye: recibir un mensaje de peticion de control enviado por un terminal, donde el mensaje de peticion de control transporta informacion de identificacion de un flujo secundario y un identificador de recursos uniforme, URI, de un tren de medios al que pertenece el flujo secundario, en donde el mensaje de peticion de control es un mensaje de peticion PLAY, RTSP, protocolo de transmision en tiempo real, o un mensaje de peticion RTSP PAUSE; obtener la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario;
5
10
15
20
25
30
35
40
45
50
55
60
determinar, segun la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario, los datos multimedia del flujo secundario; y realizar, basado en los datos multimedia, una operacion de control solicitada por el terminal, para el flujo secundario, en donde la operacion de control es control de reproduccion o control de pausa;
en donde antes de recibir un mensaje de peticion de control enviado por un terminal, el procedimiento comprende ademas: recibir un mensaje de peticion de informacion de descripcion enviado por el terminal; y devolver un mensaje de respuesta que transporta informacion de declaracion del flujo secundario al terminal, de manera que el terminal obtiene la informacion de identificacion del flujo secundario segun la informacion de declaracion del flujo secundario; o
en donde antes de recibir un mensaje de peticion de control enviado por el terminal, el procedimiento comprende ademas: recibir un mensaje de peticion RTSP SETUP enviado por el terminal, en donde el mensaje de peticion RTSP SETUP transporta una etiqueta de funcion de control del flujo secundario; obtener la etiqueta de funcion de control del flujo secundario; y, si la etiqueta de funcion de control del flujo secundario puede ser identificada correctamente, devolver un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario es soportado por el terminal, de manera que el terminal inicia el control del flujo secundario; o de otro modo, devolver un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario no es soportado por el terminal.
En otro aspecto, la presente invencion proporciona un aparato de control de datos multimedia, que incluye: una primera unidad de recepcion de mensajes, configurada para recibir un mensaje de peticion de control enviado por un terminal, donde el mensaje de peticion de control transporta informacion de identificacion de un flujo secundario y un identificador de recursos uniforme, URI, de un tren de medios al que pertenece el flujo secundario, en donde el mensaje de peticion de control es un mensaje de peticion PLAY, RTSP, protocolo de transmision en tiempo real, o un mensaje de peticion RTSP PAUSE; una unidad de obtencion de informacion, configurada para obtener la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario; una unidad de determinacion de datos, configurada para determinar, segun la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario, los datos multimedia del flujo secundario; y una unidad de control multimedia, configurada para realizar, basado en los datos multimedia, una operacion de control solicitada por el terminal, para el flujo secundario, en donde la operacion de control es control de reproduccion o control de pausa;
en donde el aparato comprende ademas: una segunda unidad de recepcion de mensajes, configurada para recibir un mensaje de peticion de informacion de descripcion enviado por el terminal; y una primera unidad de respuesta, configurada para devolver un mensaje de respuesta que transporta informacion de declaracion del flujo secundario al terminal, de manera que el terminal obtiene la informacion de identificacion del flujo secundario segun la informacion de declaracion del flujo secundario; o
en donde el aparato comprende ademas: una segunda unidad de obtencion de etiqueta de funcion de control del flujo secundario, configurada para: recibir un mensaje de peticion RTSP SETUP enviado por el terminal, en donde el mensaje de peticion RTSP SETUP transporta una etiqueta de funcion de control del flujo secundario; y obtener la etiqueta de funcion de control del flujo secundario; y una segunda unidad de control, configurada para: si la etiqueta de funcion de control del flujo secundario puede ser identificada correctamente, devolver un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario es soportado por el terminal, de manera que el terminal inicia el control del flujo secundario; o de otro modo, devolver un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario no es soportado por el terminal.
Segun las realizaciones de la presente invencion, la presente invencion describe los siguientes efectos tecnicos:
En las realizaciones de la presente invencion, un mensaje de peticion de control enviado por un terminal transporta informacion de identificacion de un flujo secundario y un URI de un tren de medios al que pertenece el flujo secundario, de manera que despues de que un servidor recibe el mensaje de peticion de control desde el terminal, el servidor puede obtener las dos piezas de informacion, obtener ademas, segun las dos piezas de informacion, los datos multimedia del flujo secundario solicitados por el terminal, y luego basado en los datos multimedia, realizar una operacion de control correspondiente para el flujo secundario solicitado por el terminal, tales como reproducir y pausar. Por lo tanto, segun las realizaciones de la presente invencion, se puede aplicar un control independiente para datos de diferentes funciones bajo el mismo tipo incluso en el caso donde los datos de funciones diferentes se transmiten a traves del mismo tren de medios.
Breve descripcion de los dibujos
Para ilustrar las soluciones tecnicas en las realizaciones de la presente invencion o en la tecnica anterior mas claramente, a continuacion se presentan brevemente los dibujos adjuntos necesarios para describir las realizaciones. Evidentemente, los dibujos que se adjuntan en las siguientes descripciones muestran simplemente algunas realizaciones de la presente invencion, y un experto en la tecnica puede todavfa derivar otros dibujos de estos dibujos adjuntos sin esfuerzos creativos.
La FIG. 1 es un diagrama de flujo de un procedimiento segun una realizacion de la presente invencion;
La FIG. 2 es un primer diagrama esquematico de un procedimiento segun una realizacion de la presente invencion;
5
10
15
20
25
30
35
40
45
50
La FIG. 3 es un segundo diagrama esquematico de un procedimiento segun una realizacion de la presente invencion;
La FIG. 4 es un tercer diagrama esquematico de un procedimiento segun una realizacion de la presente invencion;
La FIG. 5 es un diagrama esquematico de un aparato segun una realizacion de la presente invencion;
La FIG. 6 es un diagrama de flujo de otro procedimiento segun una realizacion de la presente invencion; y La FIG. 7 es un diagrama esquematico de otro aparato segun una realizacion de la presente invencion.
Descripcion de las realizaciones
A continuacion se describen, clara y completamente, las soluciones tecnicas en las realizaciones de la presente invencion con referencia a los dibujos adjuntos en las realizaciones de la presente invencion. Evidentemente, las realizaciones descritas son simplemente una parte en lugar de ser todas las realizaciones de la presente invencion. Todas las demas realizaciones obtenidas por un experto en la materia basada en las realizaciones de la presente invencion caeran dentro del ambito de proteccion de la presente invencion.
Haciendo referencia a la Fig. 1, un procedimiento de control de datos multimedia proporcionado por una realizacion de la presente invencion incluye las siguientes etapas:
E101. Recibir un mensaje de peticion de control enviado por un terminal, donde el mensaje de peticion de control transporta informacion de identificacion de un flujo secundario y un URI (Uniform Resource Identifier, identificador de recursos uniforme) de un tren de medios al que pertenece el flujo secundario.
Debe observarse que la realizacion de la presente invencion puede utilizarse en combinacion con el protocolo de transmision en tiempo real (RTSP), donde el mensaje de peticion de control puede ser un mensaje de peticion RTSP PLAY o un mensaje de peticion RTSP PAUSE, y asf sucesivamente.
E102. Obtener la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario.
E103. Determinar, segun la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario, los datos multimedia del flujo secundario.
El flujo secundario es una parte del tren de medios, y el flujo secundario se puede decodificar independientemente. Los diferentes flujos secundarios tienen diferentes funciones de los medios (las funciones de los medios se refieren a una frecuencia de trama, una resolucion, una velocidad de bits, o un angulo de vision, etc.) y, por lo tanto, pueden proporcionarse diferentes efectos de visualizacion por un flujo secundario diferente.
Por ejemplo, un video en un contenido multimedia se puede codificar segun SVC. Si se divide desde las perspectivas de tiempo, espacio, calidad, etc., un flujo de bits codificado incluye multiples capas (incluida una capa de base y una capa de mejora, donde solo hay una capa base, pero puede haber multiples capas de mejora). La capa de base se puede decodificar independientemente. El video obtenido por decodificacion de la capa de base puede tener una baja frecuencia de trama, baja resolucion o baja calidad y puede utilizarse en un entorno de aplicacion con ancho de banda limitado o ancho de banda inestable para satisfacer requisitos basicos para la visualizacion. La capa de mejora no puede decodificarse independientemente. La capa de mejora debe ser decodificada conjuntamente con la capa de base y una capa (o capas) de mejora dependiente (la capa (o capas) de mejora dependiente se refiere generalmente a una capa de mejora que sera dependiente durante la codificacion y, en consecuencia, durante la decodificacion es tambien necesario que dependa de la capa (o capas) de mejora dependiente para decodificar) para mejorar un efecto de visualizacion. Espedficamente, el efecto de visualizacion proporcionado por la capa de base puede mejorarse a partir del tiempo, el espacio o la calidad.
Un flujo de bits emitido despues de la codificacion SVC puede transmitirse a traves de un tren de medios, es decir, multiples capas de flujos de bits pueden transmitirse a traves de un tren de medios. Un flujo secundario esta formado por una o mas capas y se puede decodificar independientemente, es decir, un flujo secundario en el tren de medios puede estar formado por una capa de base sola o una combinacion de una capa de base y una o mas capas de mejora. Definitivamente, debe tenerse en cuenta que no todas las capas de mejora se pueden combinar con una capa de base para formar un flujo secundario, y solo una combinacion que se puede decodificar independientemente puede formar un flujo secundario. Por ejemplo, un flujo de bits SVC incluye una capa base, una capa de mejora A y una capa de mejora B. Con respecto a la capa de mejora A y a la capa de mejora B, si la capa de base + la capa de mejora A + la capa de mejora B se puede decodificar independientemente, la combinacion puede formar un flujo secundario; si la capa de base + la capa de mejora B no se puede decodificar independientemente, la combinacion no puede formar un flujo secundario.
Para otro ejemplo, si un video en un contenido multimedia es un video de multiples vistas (el video de multiples vistas hace referencia a multiples videos emitidos por multiples camaras en diferentes posiciones geometricas, donde cada video puede referirse brevemente como una vista, y las camaras en el presente documento pueden ser
5
10
15
20
25
30
35
40
45
50
55
camaras virtuales), se puede usar MVC para codificar el video de multiples vistas para obtener un flujo de bits. En el proceso de codificacion, se puede seleccionar un video en el como una vista de base, y durante la codificacion, la vista de base no requiere prediccion entre vistas y, por lo tanto, se puede decodificar independientemente. Otras vistas se utilizan para proporcionar escalabilidad en angulos de vision. Durante la codificacion, las otras vistas requieren prediccion entre vistas y, por lo tanto, no se pueden decodificar independientemente. Las otras vistas solo se pueden decodificar conjuntamente con la vista de base y las vistas de las que dependen las otras vistas durante la codificacion.
Un flujo de bits emitidos despues de la codificacion MVC puede transmitirse a traves de un tren de medios, es decir, se pueden transmitir multiples vistas a traves de un tren de medios. Un flujo secundario esta formado por una o mas vistas y se puede decodificar independientemente, es decir, un flujo secundario en el tren de medios puede estar formado por una vista de base sola o una combinacion de una vista de base y una u otras vistas mas. Definitivamente, debe tenerse en cuenta que no todas las otras vistas se pueden combinar con una vista de base para formar un flujo secundario. Solo una combinacion que se puede decodificar independientemente puede formar un flujo secundario. Por ejemplo, un flujo de bits MVC incluye una vista de base, otra vista A y otra vista B. Con respecto a otra vista A y otra vista B, si la vista de base + otra vista A + otra vista B se puede decodificar independientemente, la combinacion puede formar un flujo secundario; aunque si la vista de base + otra vista B no se puede decodificar independientemente, la combinacion no puede formar un flujo secundario.
Ademas, MVC soporta escalabilidad temporal, es decir, el flujo de bits de cada vista puede dividirse temporalmente en multiples capas. En este caso, una dependencia de decodificacion introducida por escalabilidad temporal necesita ser considerada para la composicion de un flujo secundario. Es decir, una capa temporal 1 de otra vista debe descodificarse conjuntamente con una vista de base y una vista a un mismo nivel temporal o capa inferior entre las vistas de las que la otra vista depende durante la codificacion.
Independientemente de SVC o MVC, diferentes flujos secundarios proporcionan diferentes efectos de visualizacion, y tambien pueden variar los requisitos del entorno de comunicacion tales como ancho de banda y los requisitos de las capacidades de los terminales. Por lo tanto, si se puede aplicar un control independiente basado en flujos secundarios, un usuario o terminal puede recibir selectivamente un flujo secundario segun una condicion de ancho de banda actual, capacidad del terminal y otros factores que pueden ayudar a conseguir un equilibrio entre el efecto de reproduccion y la uniformidad de la reproduccion.
En la realizacion de la presente invencion, para aplicar un control del flujo secundario, el terminal necesita transportar informacion de identificacion de un flujo secundario y un URI de un tren de medios al que pertenece el flujo secundario en la peticion de control. La informacion de identificacion de un flujo secundario se refiere a informacion que puede identificar de forma unica un flujo secundario, en un tren de medios al que pertenece el flujo secundario. Esto se describira en lo sucesivo.
Por ejemplo, en SVC, se puede usar un dependency_id (D), un temporaljd (T) y un quality_id (Q) para identificar diferentes capas, donde, el dependency_id es un identificador de dependencia, el temporaljd es un identificador temporal, y el quality_id es un identificador de calidad. Por lo tanto, el terminal puede transportar un valor (D, T, Q) espedfico en un mensaje de peticion de control como informacion de identificacion de un flujo secundario. Correspondientemente, despues de encontrar los datos correspondientes al tren de medios segun el URI del tren de medios, el servidor puede encontrar ademas datos correspondientes al flujo secundario segun el valor espedfico (D, T, Q).
En MVC, se puede usar un temporaljd y un view_id en un flujo secundario para identificar diferentes capas temporales de vistas diferentes, donde, el temporaljd es un identificador temporal y el view_id es un identificador de vista. Por lo tanto, el terminal puede transportar valores de temporal-id y de view_id espedficos en un mensaje de peticion de control como informacion de identificacion de un flujo secundario. Correspondientemente, despues de encontrar datos correspondientes al tren de medios segun el URI del tren de medios, el servidor puede encontrar ademas datos correspondientes al flujo secundario segun los valores espedficos de temporal-id y de view_id obtenidos mediante analisis sintactico.
Para concluir, independientemente de SVC o MVC, el terminal puede transportar informacion de identificacion de un flujo secundario y un URI de un tren de medios al que pertenece el flujo secundario en un mensaje de peticion de control, de modo que el servidor sepa que flujo secundario de que tren de medios tiene la intencion de controlar el terminal.
Con respecto a la informacion de identificacion del flujo secundario y del URI del tren de medios al que pertenece el flujo secundario, el terminal puede obtener primero informacion de descripcion de un contenido multimedia y luego obtener la informacion de identificacion y el URI de la informacion de descripcion. El terminal puede obtener la informacion de descripcion del contenido multimedia de multiples maneras. Por ejemplo, el terminal puede iniciar por adelantado una peticion HTTP a traves del protocolo HTTP, para obtener informacion de descripcion multimedia, a un servidor que almacena la informacion de descripcion del contenido multimedia, y obtener la informacion de descripcion del servidor, o recibir por adelantado un correo electronico que transporta la informacion de descripcion del contenido multimedia, y obtener la informacion de descripcion del correo electronico. Definitivamente, el terminal
5
10
15
20
25
30
35
40
45
50
55
60
tambien puede iniciar una peticion RTSP para obtener informacion de descripcion multimedia al servidor, y obtener la informacion de descripcion del servidor. Por ejemplo, antes de iniciar una peticion de control, el terminal puede enviar primero un mensaje de peticion de informacion de descripcion al servidor, donde el mensaje de peticion de informacion de descripcion es un mensaje de peticion RTSP Describe; despues de recibir el mensaje, el servidor puede devolver la informacion de descripcion del contenido multimedia al servidor, donde la informacion de descripcion puede incluir el numero de trenes de medios, el URI de cada tren de medios, un protocolo utilizado para entregar cada tren de medios, un parametro de protocolo de transmision, informacion de codificacion multimedia, y asf sucesivamente. Ademas, puede incluirse informacion de declaracion de todos los flujos secundarios en los trenes de medios. Por lo tanto, al analizar un mensaje de respuesta devuelto por el servidor, el terminal puede obtener el URI de un tren de medios y una informacion de declaracion del flujo secundario del tren de medios y, ademas, obtener informacion de identificacion de cada flujo secundario de la informacion de declaracion del flujo secundario.
En una aplicacion espedfica, la informacion de declaracion del flujo secundario se puede usar como una parte de la informacion de descripcion multimedia, y la informacion de descripcion multimedia se convierte en un archivo SDP. En el archivo SDP, para permitir que el terminal sepa que capas estan incluidas en un flujo de bits SVC, el servidor puede usar parametros en el archivo SDP para declarar el valor (D, T, Q) (o el valor layer_id, donde el layer_id es un identificador de capa) de cada capa en el flujo de bits SVC para el terminal, y especificar que capas pueden combinarse en un flujo secundario. De esta manera, el terminal puede utilizar directamente el valor (D, T, Q) o el valor layer_id de cada capa correspondiente a un flujo secundario deseado como informacion de identificacion del flujo secundario y enviar la informacion de identificacion al servidor, y correspondientemente, el servidor obtiene el valor (D, T, Q) o valor layer_id de cada capa correspondiente al flujo secundario mediante analisis. Despues de obtener el valor (D, T, Q) o el valor layer_id mediante analisis, el servidor obtiene datos correspondientes a cada capa segun el valor (D, T, Q) o el valor layer_id de cada capa.
Ademas, en una aplicacion real, tambien se puede adoptar otra manera de aplicacion, que puede ser espedficamente: usando, entre parametros en un archivo SDP, un parametro sprop-operation-point-info en una lmea de atributo a = fmtp para transportar un grupo de vector de descripcion de punto de operacion, donde un vector de descripcion de punto de operacion se usa para declarar un punto de operacion. El formato de un vector de descripcion de punto de operacion puede ser: <layer-ID, temporal-ID, dependency-ID, quality-ID, profile-level-ID, avg-framerate, width, height, avg-bitrate y max-bitrate>, donde el layer-ID indica un identificador de capa de un punto de operacion, el temporal-ID indica un identificador temporal del punto de operacion, el dependency-ID indica un identificador de dependencia del punto de operacion, el quality-ID indica un Identificador de calidad del punto de operacion, el profile-level-ID indica un identificador de nivel de perfil del punto de operacion, el avg-framerate indica una frecuencia media de fotogramas del punto de operacion, el width indica una anchura de un fotograma de video correspondiente al punto de operacion, el height indica una altura de un fotograma de video correspondiente al punto de operacion, el avg-bitrate indica una frecuencia media de bits del punto de operacion y el max-bitrate indica una velocidad de bits maxima del punto de operacion.
Los valores layer-ID, temporal-ID, dependency-ID, y quality-ID del punto de operacion son respectivamente iguales que los valores de layer-ID, temporal-ID, dependency-ID, quality-ID, de la capa correspondiente al punto de operacion y que tiene una dependencia de decodificacion mas alta. Se puede ver que el punto de operacion puede ser identificado por una combinacion de un dependency_id (D), un temporaljd (T), y un quality_id (Q) o identificado por un layer_id, y un layer_id corresponde a una combinacion de D, T y Q. Un punto de operacion corresponde a una capa y todas las capas dependientes de la capa, es decir, un flujo de bits formado por todos los paquetes NAL (Network Abstraction Layer, capa de abstraccion de red) cuyos valores (D, T, Q) son respectivamente menores que o iguales al valor (D, T, Q) de este punto de operacion. Por lo tanto, un punto de operacion corresponde a un flujo de bits que se puede decodificar independientemente y tiene funciones multimedia espedficas, es decir, un punto de operacion corresponde a un flujo secundario. De esta manera, si el terminal necesita controlar un flujo secundario, el terminal utiliza directamente el valor (D, T, Q) o el valor layer-ID del punto de operacion correspondiente como informacion de identificacion del flujo secundario y envfa la informacion de identificacion al servidor. Correspondientemente, el servidor obtiene el valor (D, T, Q) o el valor layer-ID del punto de operacion mediante analisis. Si el valor (D, T, Q) del punto de operacion se obtiene analizando, el servidor puede utilizar directamente paquetes NAL cuyos valores (D, T, Q) son respectivamente menores que o iguales a los valores (D, T, Q) obtenidos por el servidor mediante analisis, para formar datos del flujo secundario de los medios. Por ejemplo, si el valor (D, T, Q) obtenido por el servidor analizando el mensaje de peticion de control del terminal es (1, 1, 0), el servidor extrae paquetes NAL cuyos valores (D, T, Q) son (1, 1, 0), (1, 0, 0), (0, 1, 0) o (0, 0, 0) para formar datos multimedia del flujo secundario. De forma alternativa, si el servidor obtiene el valor layer-ID del punto de operacion mediante analisis, el servidor puede traducir primero el valor layer-ID en el valor (D, T, Q), y luego usar paquetes NAL cuyos valores (D, T, Q) sean mas pequenos que o iguales al valor (D, T, Q) obtenido por el servidor mediante analisis, para formar los datos multimedia del flujo secundario. El servidor traduce el valor layer-ID al valor (D, T, Q) consultando una correlacion entre el valor layer-ID y el valor (D, T, Q). La correlacion entre el valor layer-ID y el valor (D, T, Q) puede almacenarse previamente en el servidor, por ejemplo, almacenarse en el archivo SDP o almacenarse en un mensaje SEI de informacion de escalabilidad de un flujo de bits SVC.
Con respecto a MVC, para declarar que flujos secundarios son incluidos en un flujo de bits MVC para el terminal, el servidor puede utilizar tambien parametros en el archivo SDP para declarar el valor de view_id de cada vista y el
5
10
15
20
25
30
35
40
45
50
55
60
valor temporal_id de la capa temporal de cada vista que son incluidos en el flujo de bits MVC para el terminal, y especificar que capas temporales de que vistas pueden combinarse en un flujo secundario. De esta manera, el terminal puede utilizar directamente los valores temporaljd y view_id de cada capa temporal de cada vista correspondiente a un flujo secundario deseado como informacion de identificacion del flujo secundario y enviar la informacion de identificacion al servidor y, correspondientemente, el servidor puede obtener datos correspondientes a cada capa temporal de cada vista despues de obtener el temporaljd y el view_id mediante analisis.
En una aplicacion real, los parametros en un archivo SDP tambien pueden usarse para declarar que puntos de operacion se incluyen en un flujo de bits MVC para el terminal. Una manera espedfica puede ser: usar un parametro sprop-mvc-operation-point-info en una lmea de atributo a = fmtp para transporter un grupo de vector de descripcion de punto de operacion, donde se utiliza un vector de descripcion de punto de operacion para declarar un punto de operacion. El formato de un vector de descripcion de punto de operacion puede ser: <operation-point-id, temporal-id, num-target-output-views, 1*target-output-view-id, profile-level-id, avg-framerate, avg-bitrate, max-bitrate>, donde, el operation-point-id indica un identificador de un punto de operacion, el temporal-ID indica un identificador temporal del punto de operacion, el num-target-output-views indica el numero de vistas de salida de destino del punto de operacion, el view-id indica una vista de salida de destino del punto de operacion, el profile-level-id indica un identificador de nivel de perfil del punto de operacion, el avg-framerate indica una frecuencia media de fotogramas del punto de operacion, el width indica una anchura de una trama de video correspondiente al punto de operacion, el height indica una altura de una trama de video correspondiente al punto de operacion, el avg-bitrate indica una velocidad media de bits del punto de operacion y el max-bitrate indica una velocidad maxima de bits del punto de operacion.
El temporal-id y el target-output-view-id del punto de operacion son respectivamente los mismos que el temporaljd de una capa de un nivel temporal mas alto entre todas las capas temporales de todas las vistas que corresponden al punto de operacion y al view_id de una vista de salida de destino correspondiente al punto de operacion. Se puede ver que el punto de operacion puede ser identificado por un temporaljd y un grupo de view_id (view_id de la vista de salida de destino), o identificado por un operation_point_id. Sin embargo, el punto de operacion corresponde a un flujo de bits formado por todos los paquetes NAL cuyos valores temporaljd (correspondientes a las velocidades de fotogramas) son mas pequenos que o iguales al valor temporaljd y cuyo valor view_id es igual a uno cualquiera del grupo de valores view_id o uno cualquiera de los valores de view_id de todas las vistas que una vista cualquiera correspondiente al grupo de valores de view_id depende (directamente dependiente o indirectamente dependiente) durante la decodificacion. Por lo tanto, un punto de operacion corresponde a un flujo de bits que se puede decodificar independientemente y tiene funciones multimedia espedficas, es decir, un punto de operacion corresponde a un flujo secundario. Por lo tanto, el terminal puede transporter tambien el temporaljd del punto de operacion correspondiente al flujo secundario y un grupo de view_id (view_id de las vistas de salida de destino) del punto de operacion correspondiente al flujo secundario, o transporter el operation-point-id del punto de operacion correspondiente al flujo secundario como informacion de identificacion del flujo secundario en un mensaje de peticion de control. Definitivamente, el servidor finalmente necesita encontrar datos espedficos correspondientes al flujo secundario segun los valores espedficos de temporaljd y view_id. Por lo tanto, cuando el terminal utiliza el operation_point_id como informacion de identificacion del flujo secundario, el servidor determina adicionalmente el temporal-id correspondiente al punto de operacion y el view_id de un grupo de vistas de salida de destino correspondiente al punto de operacion segun una correlacion entre el operation_point_id, el temporaljd y el target_output_view_id. Existen multiples procedimientos disponibles para obtener la correlacion. Por ejemplo, la correlacion puede obtenerse a partir de informacion de declaracion del flujo secundario en un archivo SDP correspondiente, u obtenerse de un mensaje SEI de informacion de escalabilidad de vista de un flujo de bits MVC almacenado en el servidor. Para determinar los datos multimedia del flujo secundario, el servidor necesita ademas determinar, segun una dependencia de decodificacion entre vistas, el view_id de vistas que las vistas de salida de destino en el grupo son dependientes (directamente dependientes o indirectamente dependientes) durante la decodificacion. La dependencia de decodificacion se puede obtener segun metadatos en un archivo MVC (un flujo de bits MVC se almacena en el servidor en forma de un archivo, donde el archivo incluye no solo el flujo de bits MVC, sino tambien los metadatos utilizados para describir el archivo MVC), por ejemplo, obtenerse segun ViewldentifierBox. En los recursos multimedia correspondientes, todos los paquetes nAl cuyos valores de temporal_id en las cabeceras de los paquetes son mas pequenos que o iguales al valor temporal_id obtenido y cuyo valor de view_id es igual a un valor en un grupo de valores de view_id obtenidos por el servidor (valores de view_id de las vistas de salida de destino y valores view_id de las que las vistas de salida de destino dependen durante la decodificacion) forman datos multimedia del flujo secundario.
Definitivamente, si la informacion de descripcion no es enviada en un formato de archivo SDP, un campo cabecera que transporta informacion de declaracion del flujo secundario de un tren de medios puede generarse para el servidor y el campo cabecera es transportado en un mensaje de respuesta a un mensaje de peticion de informacion de descripcion. De esta manera, el terminal puede aprender la informacion de declaracion del flujo secundario analizando el campo cabecera transportado en el mensaje de respuesta.
Espedficamente, el mensaje de peticion de informacion de descripcion es un mensaje de peticion RTSP Describe, y el mensaje de respuesta al mensaje de peticion de informacion de descripcion es un mensaje de respuesta de exito RTSP Describe. Cuando el servidor utiliza el campo cabecera en el mensaje de respuesta de exito de Describir RTSP para transporter informacion de declaracion del flujo secundario, para un tren de medios que incluye flujos
5
10
15
20
25
30
35
40
45
50
55
60
65
secundarios, la informacion de declaracion del flujo secundario puede incluir el URI del tren de medios al que los flujos secundarios pertenecen y un grupo de vector de descripcion de punto de operacion (que puede ser coherente con el vector de descripcion del punto de operacion anterior), donde cada vector de descripcion de punto de operacion declara un punto de operacion (cada punto de operacion corresponde a un flujo secundario). Si se incluyen flujos secundarios en multiples trenes de medios, el campo cabecera transporta un grupo de informacion de declaracion del flujo secundario que, respectivamente, corresponde a trenes de medios diferentes. Se utiliza un caracter especial para separar la informacion de declaracion del flujo secundario de diferentes trenes de medios, de manera que el servidor puede distinguir la informacion de declaracion del flujo secundario. Esto puede aplicarse mediante una definicion sintactica. En un estandar de Internet, un ABNF se utiliza generalmente para describir una definicion sintactica. Espedficamente, un ABNF se utiliza para describir la definicion sintactica de un campo cabecera que transporta informacion de declaracion del flujo secundario, como se describe a continuacion. Un "punto y coma" se utiliza para separar la informacion de la declaracion del flujo secundario de diferentes trenes de medios. De esta manera, cuando el terminal analiza el campo cabecera, el terminal puede distinguir la informacion de declaracion del flujo secundario del tren de medios uno a uno segun el "punto y coma".
substream-info = "informacion del flujo secundario" HCOLON [substream-info-spec *SEMI substream-spec)]
substream-info-spec = stream-url substream-type 1*descriptor-vector stream-url = <como se define en draft-ietf-mmusic-rfc2326bis-27> stream-type = "teclear" EQUAL substream-type-value substream-type-value = “SVC” / “MVC” / substream-type-value-ext substream-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 avg_framerate_value COMMA width_value COMMA height_value COMMA avg_bitrate_value COMMA max_bitrate_value LAQUAT / RAQUOT operation_point_id_value COMMA temporal_id_value
COMMA num_target_output_views_value 1 * (COMMA target_output_view_id_value)
COMMA profile_level_id_value COMMA 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 = 1*4DIGIT; 0~1023 target_output_view_id_value = 1*4DIGIT; 0~1024 descriptor-vector-ext = token HCOLON = *(SP / HT)":" SWS SWS = [LWS]; espacio de separacion en blanco LWS = [CRLF] 1*(sP / HT); espacio en blanco de salto de lmea DIGIT =%x30-39; cualquier dfgito US-ASCII "0".."9"
HT =%x09; US-ASCII HT, tabulador horizontal (9)
SP =%x20; US-ASCII SP, espacio (32)
COMMA = SWS "," SWS; coma
EQUAL = SWS "=" SWS; igual
DQ =%x22; codigo US-ASCII de comillas dobles (34)
RAQUOT = ">" SWS; cita con angulo a la derecha LAQUOT = SWS "<"; cita con angulo a la izquierda SEMI = SWS ";" SWS; punto y coma
HEX = DIGIT / "A" / "B" / "C" / "D" /"E" / "F" / "a" / "b" / "c" / "d" / “e” / “f”
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7A / %x7C / %x7E)
; 1*<cualquier CHAR excepto los CTL o tspecial>
5
10
15
20
25
30
35
40
45
50
55
60
Despues de que el terminal recibe un mensaje de respuesta de exito RTSP Describe, el terminal analiza el campo cabecera que transporta la informacion de declaracion del flujo secundario para obtener el URI de un tren de medios que incluye un flujo secundario e informacion de identificacion correspondiente del flujo secundario. Despues de que se obtienen el URI del tren de medios y la informacion de identificacion del flujo secundario, el URI del tren de medios y la informacion de identificacion del flujo secundario pueden ser transportados en un mensaje de peticion de control y enviados al servidor. En una aplicacion espedfica, en diferentes escenarios de aplicacion, las posiciones del URI del tren de medios y la informacion de identificacion del flujo secundario en un mensaje de peticion de control pueden variar. Esto se describira en detalle en lo sucesivo.
En una de las formas de control basadas en trenes de medios existentes, el terminal puede realizar un control independiente basado en un unico tren de medios, por ejemplo, controlar de forma independiente un flujo de video y un flujo de audio de un programa de video. En el caso de un control independiente, los posibles inconvenientes son los siguientes: Se requieren muchas interacciones, y cuando se realiza un control independiente, las peticiones de control llegan al servidor en secuencia, y el servidor puede devolver las respuestas en secuencia. Para garantizar la reproduccion sincronica de un audio y un video, el terminal puede realizar una operacion correspondiente solo despues de que el terminal reciba respuestas de todos los trenes de medios. Por lo tanto, se produce un largo retardo de espera. Por lo tanto, en algunos otros escenarios de aplicacion, se puede realizar un control agregado para multiples trenes de medios (es decir, se utiliza un mensaje de peticion de control para controlar multiples trenes de medios). Cuando el terminal envfa un mensaje de peticion de control, se incluye un campo request-uri en el mensaje. En el caso de un control independiente, el campo transporta un URI de un tren de medios y, en el caso del control agregado, el campo transporta, en general, un URI para el control agregado. Debe tenerse en cuenta que, con respecto al URI de un tren de medios, como se ha mencionado anteriormente, el terminal puede obtenerlo a partir de un mensaje de respuesta devuelto por el servidor en respuesta a un mensaje de peticion de informacion de descripcion. Con respecto al URI para el control agregado, si el servidor soporta control agregado, el servidor puede transportar el URI para control agregado en un archivo SDP cuando el servidor devuelve al terminal un mensaje de respuesta a un mensaje de peticion de informacion de descripcion y la posicion del URI para el control agregado en el archivo SDP es, en general, diferente de las posiciones de los uRi de trenes de medios, por ejemplo, el URI para el control agregado esta situado generalmente en la parte superior entre los URI de todos los trenes de medios. Por lo tanto, el terminal puede obtener, tambien, el URI para el control agregado del archivo SDP.
Por lo tanto, si se realiza un control independiente basado en un tren de medios, todavfa es factible transportar el URI de un tren de medios al que pertenece un flujo secundario en un campo request-uri de un mensaje de peticion de control. Con respecto a la informacion de identificacion del flujo secundario, un campo cabecera que transporta informacion de identificacion del flujo secundario (por ejemplo, un campo cabecera del flujo secundario) se puede generar y transportar en un mensaje de peticion de control. En un estandar de Internet, un ABNF se utiliza generalmente para describir una definicion sintactica. Por lo tanto, se utiliza un ABNF para describir la definicion sintactica de un campo cabecera que transporta informacion de identificacion del flujo secundario. substream = "flujo secundario" HCOLON [substream-spec *(COMMA substream-spec)]
substream-spec = substream-type COMMA substream-id substream-type = "teclear" EQUAL substream-type-value substream-type-value = “SVC” / “MVC” / substream-type-value-ext substream-type-value-ext = token substream_id = layer-id
/ dependency-id temporal -id quality-id / mvc-operation-point-id / temporal-id 1*target-output-view-id / substream-id-ext
layer-id = “layer_id” EQUAL layer_id_value layer_id_value = 1*4DIGIT; 0~2047
dependency-id = “dependency_id” EQUAL dependency_id_value
dependency_id_value = DIGIT; 0~7
temporaljd = “temporaljd” EQUAL temporal_id_value
temporal_id_value = DIGIT; 0~7
quality_id = “quality_id” EQUAL quality_id_value
quality_id_value = 1*2DIGIT; 0~15
mvc-operation-point-id = “operation_point_id” EQUAL operation_point_id value
operation_point_id_value = 1*5DIGlT; 0~65535
target-output-view-id = “view-id” EQUAL view_id_value
view_id_value = 1*4DIGIT; 0~1024
substream-id-ext = token
HCOLON = *(SP / HT) ":" SWS
SWS = [LWS]; especio de separacion en blanco
LWS = [CRLF] 1*(sP / HT); espacio en blanco de salto de lmea
DIGIT = %x30-39; cualquier dfgito US-ASCII de "0".."9"
HT =%x09; US-ASCII HT, tabulador horizontal (9)
5
10
15
20
25
30
35
40
45
50
55
SP = %x20; US-ASCII SP, espacio (32)
COMMA = SWS "," SWS; coma EQUAL = SWS "=" SWS; igual
DQ =%x22; codigo US-ASCII para las comillas dobles (34) token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7A / %x7C / %x7E)
; 1* <cualquier CHAR excepto los CTL o tspecial>
Por ejemplo, un ejemplo es flujo secundario: type = svc; layer_id = 1. Si un mensaje de peticion de control transporta el campo cabecera, es una peticion de control de reproduccion para un flujo secundario cuyo layer_id es 1 en un tren de medios que transporta un flujo de bits SVC. De manera correspondiente, en el caso de un control independiente basado en un tren de medios, despues de que el servidor recibe un mensaje de peticion de control desde el terminal, el servidor puede analizar un campo request-uri del mensaje de peticion de control para obtener el URI de un tren de medios al cual pertenece un flujo secundario, y analizar un campo cabecera del mensaje de peticion de control para obtener informacion de identificacion del flujo secundario.
Definitivamente, en el caso de un control independiente basado en un tren de medios, la informacion de identificacion del flujo secundario puede transportarse tambien en el campo request-uri del mensaje de peticion de control, de modo que el servidor puede analizar el campo request-uri del mensaje de peticion de control para obtener el URI del tren de medios al que pertenece el flujo secundario y la informacion de identificacion del flujo secundario.
Con respecto al control agregado, el servidor todavfa necesita conocer el URI del tren de medios al que pertenece el flujo secundario y la informacion de identificacion del flujo secundario antes de que el servidor pueda determinar datos correspondientes al flujo secundario. En el caso de control agregado basado en multiples trenes de medios, un campo "request-uri" en una lmea de peticion en un mensaje de peticion de control es un RTSP URI para control agregado. Por lo tanto, en el caso del control agregado, un campo cabecera que transporta tanto el URI del tren de medios al que pertenece el flujo secundario como la informacion de identificacion del flujo secundario pueden generarse y transportarse en un mensaje de peticion de control. De esta manera, el servidor puede analizar el campo cabecera del mensaje de peticion de control para obtener el URI del tren de medios al que pertenece el flujo secundario e informacion de identificacion del flujo secundario y determinar ademas los datos correspondientes al flujo secundario.
Debe observarse que, en el caso de control agregado, una peticion de control implica multiples trenes de medios. En una aplicacion espedfica, puede realizarse el control del flujo secundario para cada tren de medios implicado, o el control del flujo secundario se puede realizar para solamente uno o mas trenes de medios. Cuando se requiere en una peticion de control realizar un control del flujo secundario para multiples trenes de medios, y un campo cabecera del mensaje de peticion de control transporta informacion de identificacion de un flujo secundario y el uRi de un tren de medios al que pertenece el flujo secundario, las dos piezas de informacion pueden aparecer en grupos (un tren de medios corresponde a un grupo), y los grupos pueden estar separados por un caracter especial, de modo que el servidor pueda distinguir la informacion. Esto puede aplicarse mediante una definicion sintactica. Por ejemplo, la definicion sintactica de un campo cabecera descrito por un ABNF es la siguiente:
substream = "flujo secundario" HCOLON [stream-uri] [substream-spec*(COMMA substream-spec)] *(SEMI [stream-uri] [substream-spec *(COMMA substream-spec)]) sEmI = SWS ";" SWS; punto y coma
En la SEMI, [stream-url] corresponde al URI de un tren de medios, y [substream-spec*(COMMA substream-spec)] corresponde a la informacion de identificacion de un flujo secundario. Cuando es necesario realizar un control del flujo secundario para dos trenes de medios (streaml y stream2), el campo cabecera puede expresarse de la siguiente manera: [streaml-url] [substream-spec*(COMMA substream-spec)]; [stream2-url][substream- spec*(COMMA substream-spec)]. Se puede ver que los diferentes trenes de medios pueden estar separados por un "punto y coma", de modo que cuando el servidor analiza el campo cabecera, el servidor puede distinguir los trenes de medios uno a uno segun el "punto y coma".
Debe observarse ademas que, en una aplicacion real, los trenes de medios de multiples tipos de codificacion pueden coexistir en el sistema. Por ejemplo, algunos trenes de medios pueden ser codificados por SVC, y algunos trenes de medios pueden ser codificados por MVC. Cuando se utilizan diferentes tipos de codificacion para trenes de medios, la informacion de identificacion de un flujo secundario se indica generalmente de diferentes maneras. Para simplificar el proceso de identificacion del servidor, la informacion del tipo de codificacion del flujo secundario puede ser transportada en el mensaje de peticion de control. En una aplicacion espedfica, se puede anadir un campo "substream_id" en un campo cabecera para transportar la informacion de identificacion del flujo secundario, y en el campo es transportado un valor de tipo espedfico.
E104. Realizar, a partir de los datos multimedia, una operacion de control solicitada por el terminal, para el flujo secundario.
Para datos multimedia tales como un programa de video, el mensaje de peticion de control se denomina generalmente operacion de mensaje de peticion de control. El control puede incluir espedficamente control de
5
10
15
20
25
30
35
40
45
50
55
60
reproduccion, control de pausa, control de avance rapido, control de rebobinado, etc.
En resumen, segun la realizacion de la presente invencion, se puede aplicar un control independiente para datos de diferentes funciones bajo el mismo tipo incluso en el caso de que los datos de funciones diferentes se transmitan a traves del mismo tren de medios.
En una aplicacion real, es posible que la informacion de identificacion de un flujo secundario transportada en un mensaje de peticion de control enviado por un terminal sea incorrecta. Muchas causas pueden conducir a este fenomeno. Por ejemplo, una causa posible es: como se ha mencionado anteriormente, el terminal puede obtener informacion de descripcion de un contenido multimedia de multiples maneras; sin embargo, cuando el terminal obtiene la informacion de descripcion de cierta manera de antemano (por ejemplo, a traves del protocolo HTTP o un correo electronico), y obtiene informacion de identificacion de un flujo secundario desde la informacion de descripcion, porque puede existir un intervalo largo entre el tiempo de obtencion de la informacion de identificacion y el tiempo real de envfo de una peticion de control, si el servidor actualiza la informacion de identificacion del flujo secundario en este penodo y el terminal envfa una peticion segun la informacion previamente obtenida, la informacion transportada puede ser incorrecta.
Para tratar este caso, en la realizacion de la presente invencion, despues de que el servidor obtiene la informacion de identificacion del flujo secundario analizando el mensaje de peticion de control, si la informacion de identificacion del flujo secundario es encontrada incorrecta (por ejemplo, se encuentra que la informacion de identificacion del flujo secundario obtenido mediante analisis no existe en una base de datos del servidor, lo que demuestra que la informacion de identificacion del flujo secundario enviada por el terminal es incorrecta), se puede devolver una respuesta de error al terminal, y la informacion de especificacion correcta de cada flujo puede ser transportada en la respuesta de error (asimismo, puede utilizarse una forma de transportar informacion en un cuerpo de mensaje o campo cabecera de un mensaje de respuesta; la manera espedfica puede ser similar a la de transportar informacion tal como informacion de identificacion de un flujo secundario en un mensaje de peticion de control, y no se describe adicionalmente en el presente documento). De esta manera, el terminal puede analizar el mensaje de respuesta para obtener informacion de declaracion del flujo secundario correcta, obtener informacion de identificacion de un flujo secundario que requiere un control del flujo secundario, y luego reenviar un mensaje de peticion de control, donde el mensaje de peticion de control transporta la informacion de identificacion correcta del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario.
Ademas, en una aplicacion real, es posible que algunos servidores no soporten el control multimedia basado en flujos secundarios. Si un mensaje de peticion de control que transporta informacion de identificacion de un flujo secundario es enviado a esos servidores, dichos servidores no pueden identificar un campo cabecera que transporte la informacion de identificacion del flujo secundario y, en consecuencia, el control finalmente se convierte en control basado en todo el tren de medios (porque el mensaje de peticion de control tambien transporta tal informacion como el URI de un tren de medios).
Para evitar el caso anterior, la realizacion de la presente invencion proporciona ademas una solucion correspondiente. Por ejemplo, en una manera de aplicacion, cuando el terminal envfa un mensaje de peticion de control, una etiqueta de funcion de control del flujo secundario puede ser transportada en el mensaje de peticion de control, y el servidor puede obtener la etiqueta de funcion de control del flujo secundario desde el mensaje de peticion de control. Despues de que el servidor obtiene la etiqueta de funcion de control del flujo secundario, si el servidor soporta el control del flujo secundario, el servidor puede identificar correctamente el campo cabecera reden generado (un campo cabecera que transporta informacion de identificacion de un flujo secundario) en el mensaje de peticion de control, y realizar un control multimedia basado en flujos secundarios segun el procedimiento anterior. Definitivamente, si el propio servidor no soporta el control del flujo secundario, despues de obtener la etiqueta de la funcion de control del flujo secundario, el servidor no puede identificar la etiqueta correctamente. Por lo tanto, el servidor puede rechazar la peticion de control del terminal, y devolver un mensaje de respuesta al terminal, donde el mensaje de respuesta transporta informacion que indica que no se soporta el control del flujo secundario, en lugar de realizar el control basado en todo el tren de medios.
En una aplicacion espedfica, la etiqueta de funcion de control del flujo secundario se puede transportar en un campo cabecera requerir de un mensaje de peticion de control. El campo cabecera requerir es un campo cabecera definido en un protocolo existente. Todos los servidores, ya soporten el control del flujo secundario o no, pueden analizar el campo cabecera. Al analizar el campo cabecera, el servidor puede obtener la etiqueta de funcion de control del flujo secundario. Si el servidor soporta el control del flujo secundario, el servidor puede identificar correctamente la etiqueta de funcion de control del flujo secundario transportada en el mismo y ademas puede analizar un campo que transporta informacion tal como una informacion de identificacion de un flujo secundario para obtener la informacion de identificacion tal como el identificador del flujo secundario, y realizar un control multimedia basado en flujo secundario segun el procedimiento anterior. Si el servidor no soporta el control del flujo secundario, el servidor no puede obtener correctamente la etiqueta de funcion de control del flujo secundario mediante analisis sintactico, y ademas puede rechazar la peticion de control del terminal, y devolver un mensaje de respuesta al terminal, donde el mensaje de respuesta incluye un campo cabecera no soportado que transporta la etiqueta de funcion de control del flujo secundario que no puede ser identificada por el servidor. Despues de recibir el mensaje de respuesta, el terminal analiza el campo cabecera no soportado en el mismo, y obtiene la etiqueta de funcion de control del flujo
5
10
15
20
25
30
35
40
45
50
55
60
secundario, de manera que se comprueba que el servidor no soporta el control del flujo secundario. Definitivamente, la etiqueta de funcion de control del flujo secundario tambien se puede transportar en otros campos cabecera definidos.
En otra forma de aplicacion, antes de que el terminal envfe un mensaje de peticion de control, el terminal generalmente necesita enviar un mensaje de peticion RTSP SETUP al servidor, solicitando determinar un mecanismo de transmision para que un flujo secundario sea controlado o configurar una sesion RTSP o anadir un tren de medios a una sesion de RTSP existente; y el terminal puede realizar una operacion de control posterior solamente despues de recibir un mensaje de respuesta de exito RTSP SETUP. Por lo tanto, en la realizacion de la presente invencion, se puede transportar una etiqueta de funcion de control del flujo secundario en un mensaje de peticion RTSP SETUP, de modo que despues de que el servidor recibe la peticion RTSP SETUP del terminal, el servidor pueda obtener la etiqueta de funcion de control del flujo secundario mediante el analisis sintactico del mensaje de peticion RTSP SETUP. Despues, si el servidor soporta el control del flujo secundario, el servidor puede enviar un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario es soportado por el terminal. De esta manera, el terminal puede ser notificado de que el servidor soporta el control del flujo secundario, y el terminal puede enviar posteriormente una peticion de control del flujo secundario al servidor. Definitivamente, si el servidor no soporta el control del flujo secundario, despues de que el servidor obtiene la etiqueta de funcion de control del flujo secundario, el servidor puede devolver un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario no es soportado por el terminal, de modo que el terminal no inicia una peticion de control del flujo secundario al iniciar una peticion de control al servidor.
En esta manera de transportar una etiqueta de funcion de control del flujo secundario en un mensaje de peticion RTSP SETUP, en una aplicacion espedfica, la etiqueta de funcion de control del flujo secundario puede transportarse en un campo cabecera de soporte de una peticion RTSP SETUP. El campo cabecera de soporte es un campo cabecera definido en un protocolo existente y puede ser analizado por el servidor. Utilizar el campo cabecera para transportar la etiqueta de funcion de control del flujo secundario puede garantizar que el servidor pueda obtener la etiqueta de funcion de control del flujo secundario. De esta manera, el servidor puede obtener la etiqueta de funcion de control del flujo secundario analizando el campo cabecera. Si el servidor soporta el control del flujo secundario, el servidor puede identificar correctamente la etiqueta de funcion de control del flujo secundario transportada en el mismo, y ademas, un mensaje de respuesta a una peticion RTSP SETUP puede incluir tambien un campo cabecera de soporte que transporta una etiqueta de funcion de control del flujo secundario, que notifica el terminal que el servidor soporta el control del flujo secundario. Si el servidor no soporta el control del flujo secundario, el servidor no puede identificar correctamente la etiqueta de funcion de control del flujo secundario obtenida mediante analisis, y ademas, un mensaje de respuesta a una peticion RTSP SETUP puede incluir un campo cabecera no soportado, el cual transporta la etiqueta de funcion de control del flujo secundario que no puede ser identificada por el servidor. Despues de recibir el mensaje de respuesta, el terminal analiza el campo cabecera no soportado en el mismo, y obtiene la etiqueta de funcion de control del flujo secundario, de manera que se compruebe que el servidor no soporta el control del flujo secundario. Definitivamente, la etiqueta de funcion de control del flujo secundario tambien se puede transportar en otros campos de cabecera definidos.
El procedimiento de control de datos multimedia proporcionado por la realizacion de la presente invencion se ha descrito anteriormente. Debe observarse que la realizacion de la presente invencion no solo es aplicable al control del flujo secundario en SVC y MVC, sino que tambien es aplicable a otras aplicaciones que implican el control del flujo secundario. Por ejemplo, cuando se incluyen multiples flujos secundarios en los datos multimedia, y los formatos de carga de diferentes flujos secundarios son diferentes, se puede usar un formato de carga como informacion de identificacion de un flujo secundario. Para otro ejemplo, cuando se incluyen multiples flujos secundarios en los datos multimedia, y SSRC (Synchronization Source, fuente de sincronizacion) de diferentes flujos secundarios son diferentes, se puede usar una SSRC fuente como informacion de identificacion de un flujo secundario. Para una mejor comprension de la realizacion de la presente invencion, a continuacion se utiliza un ejemplo para describir en detalle el procedimiento de control de datos multimedia proporcionado por la realizacion de la presente invencion.
En primer lugar, debe observarse que, en este ejemplo, suponiendo que un contenido multimedia es un programa de video, y ademas de un mensaje de peticion de control, suponiendo que el control se realiza basado en un unico tren de medios, que hace referencia a la Fig. 2, el procedimiento puede incluir los siguientes pasos:
E201. Un terminal envfa un mensaje de peticion de informacion describir (Describe) a un servidor, solicitando obtener informacion de descripcion de un contenido multimedia desde el servidor. Un campo request-uri en el mensaje de peticion Describe es un URI del contenido multimedia.
E202. El servidor envfa al terminal un mensaje de respuesta 200 OK, donde el mensaje de respuesta incluye la informacion de descripcion del contenido multimedia. La informacion de descripcion del contenido multimedia puede incluir: el numero de trenes de medios, un RTSP URI de cada tren de medios, un protocolo utilizado para enviar cada tren de medios, un parametro de protocolo de transmision, informacion de codificacion multimedia, etc.
Si la informacion de descripcion se envfa en un formato de archivo SDP, la informacion de declaracion del flujo secundario de los trenes de medios tambien se puede incluir directamente en el archivo. De lo contrario, puede
5
10
15
20
25
30
35
40
45
50
55
generarse un nuevo campo cabecera para el mensaje de respuesta, y la informacion de declaracion del flujo secundario se puede transportar en el campo cabecera. Ademas, el terminal puede obtener la informacion de descripcion del contenido multimedia de otras maneras.
E203. El terminal envfa al servidor un mensaje de peticion RTSP SETUP segun la informacion de descripcion del contenido multimedia, solicitando determinar un mecanismo de transmision para un tren de medios y configurar una sesion de RTSP. El campo request-uri del mensaje de peticion RTSP SETUP indica que se ha configurado y controlado el RTSP URI del tren de medios. El mensaje de peticion RTSP SETUP incluye ademas un parametro de transmision del tren de medios.
E204. El servidor determina si esta disponible un recurso multimedia que corresponde al RTSP URI en el mensaje de peticion RTSP SETUP, si el parametro de transmision es aceptable, etc. El servidor configura una sesion de RTSP, genera un identificador de sesion de RTSP y envfa un mensaje de respuesta 200 OK al terminal, donde el mensaje de respuesta 200 OK incluye el identificador de sesion.
E205. El terminal envfa al servidor un mensaje de peticion de control. El mensaje de peticion de control incluye un campo cabecera que transporta informacion de identificacion de un flujo secundario. La informacion de identificacion del flujo secundario se utiliza para determinar los datos multimedia del flujo secundario. En diferentes escenarios, la informacion de identificacion de un flujo secundario puede variar. Por ejemplo, si un tren de medios transporta un flujo de bits SVC, la informacion de identificacion de un flujo secundario puede ser un layer-id, o una combinacion de un dependency-id, temporal-id y un quality-id. Si un tren de medios transporta un flujo de bits MVC, la informacion de identificacion de un flujo secundario puede ser un operation-point-id o una combinacion de un temporal-id y un view- id. La request-uri en el mensaje de peticion de control indica el RTSP URI del tren de medios al que pertenece el flujo secundario que requiere control de reproduccion. Ademas, el mensaje de peticion de control transporta ademas el identificador de sesion obtenido en E204, donde el identificador de sesion se utiliza para identificar la sesion RTSP para la que se utiliza la peticion. El mensaje de peticion de control puede ser un mensaje de peticion de reproduccion (RTSP PLAY) o un mensaje de peticion de pausa (RTSP PAUSE) y asf sucesivamente.
E206. El servidor procesa el mensaje de peticion de control, analiza el request-uri en el mensaje de peticion de control para obtener el RTSP URI del tren de medios y analiza el campo cabecera que transporta la informacion de identificacion del flujo secundario para obtener la informacion de identificacion del flujo secundario.
E207. Si el servidor acepta la peticion de control de reproduccion del flujo secundario, el servidor envfa un mensaje de respuesta 200 OK al terminal. El servidor determina el recurso multimedia segun el RTSP URI del tren de medios obtenido en E206, determina los datos multimedia del flujo secundario en el recurso multimedia segun la informacion de identificacion del flujo secundario y realiza una operacion de control de reproduccion solicitada para los datos multimedia del flujo secundario. Por ejemplo, si la peticion de control de reproduccion es un mensaje de peticion RTSP PLAY, el servidor envfa los datos multimedia del flujo secundario al terminal; y si la peticion de control de reproduccion es un mensaje de peticion RTSP PAUSE, el servidor deja de enviar los datos multimedia del flujo secundario al terminal.
E208. Si el servidor no acepta la peticion de control de reproduccion del flujo secundario, el servidor envfa un mensaje de respuesta de error al terminal.
Con respecto al caso del control agregado, en la siguiente aplicacion se utiliza un ejemplo para proporcionar una descripcion detallada. En general, el control agregado difiere del control basado en un unico tren de medios en que, en el caso del control agregado, un campo cabecera del flujo secundario en un mensaje de peticion de control no solo transporta informacion de identificacion de un flujo secundario, sino que tambien transporta un RTSP URI de un tren de medios al que pertenece el flujo secundario. Espedficamente, segun las diferentes maneras de configurar una sesion de RTSP, el procedimiento de control del flujo secundario en el control agregado puede variar. En una manera de configurar una sesion RTSP, haciendo referencia a la FIG. 3, el procedimiento puede incluir principalmente los siguientes pasos (un programa de video se usa todavfa como ejemplo):
E301. Un terminal envfa a un servidor un mensaje de peticion Describe, solicitando obtener informacion de descripcion de un contenido multimedia del servidor. Un request-uri en el mensaje de peticion Describe es un URI del contenido multimedia.
E302. El servidor envfa al terminal un mensaje de respuesta 200 OK, donde el mensaje de respuesta incluye la informacion de descripcion del contenido multimedia. La informacion de descripcion del contenido multimedia incluye: un URI para control agregado, el numero de trenes de medios, un RTSP URI de cada tren de medios, un protocolo utilizado para enviar cada tren de medios, un parametro de protocolo de transmision, informacion de codificacion multimedia, etc. Ademas, tambien se puede incluir la informacion de declaracion del flujo secundario de los trenes de medios.
E303. El terminal envfa al servidor un mensaje de peticion RTSP SETUP segun la informacion de descripcion del contenido multimedia, solicitando determinar un mecanismo de transmision para el tren 1 de medios y configurar una sesion de RTSP. El campo request-uri del mensaje de peticion RTSP SETUP indica el RTSP uRi del tren 1 de medios. El mensaje de peticion RTSP SETUP incluye ademas un parametro de transmision del tren de medios.
5
10
15
20
25
30
35
40
45
50
55
E304. El servidor determina si esta disponible un recurso multimedia que corresponda al campo RTSP URI del mensaje de peticion RTSP SETUP, si el parametro de transmision es aceptable, etc. El servidor configura una sesion de RTSP, genera un identificador de sesion de RTSP y envfa un mensaje de respuesta 200 OK al terminal, donde el mensaje de respuesta 200 OK incluye el identificador de sesion.
E305. El terminal envfa un mensaje de peticion RTSP SETUP al servidor segun la informacion de descripcion del contenido multimedia, solicitando determinar un mecanismo de transmision para el tren 2 de medios. El campo request-uri del mensaje de peticion RTSP SETUP indica el RTSP URI del tren 2 de medios. El mensaje de peticion RTSP SETUP incluye ademas un parametro de transmision del tren de medios. El mensaje de peticion RTSP SETUP incluye el identificador de sesion obtenido en E304, que indica que el tren 2 de medios se anadira a una sesion agregada, y que el tren 2 de medios y un tren de medios existente (tren 1 de medios) en la sesion seran controlados conjuntamente.
E306. El servidor determina si esta disponible un recurso multimedia que corresponde al campo RTSP URI del mensaje de peticion RTSP SETUP, si el parametro de transmision es aceptable, etc. El servidor anade el tren de medios correspondiente a la sesion agregada y envfa un mensaje de respuesta 200 OK al terminal.
Si el contenido multimedia incluye ademas otros trenes de medios, se repiten E305 y E306, hasta que se procesen todos los trenes de medios, donde, el request-uri se reemplaza con el RTSP URI de otro tren de medios, y el parametro de transmision correspondiente se reemplaza con el parametro de transmision del tren de medios.
E307. El terminal envfa un mensaje de peticion de control al servidor. El request-uri en el mensaje de peticion de control es el URI para el control agregado. El mensaje de peticion de control incluye un campo cabecera que transporta un URI de un tren de medios al que pertenece un flujo secundario e informacion de identificacion del flujo secundario. El identificador de sesion obtenido en E304 tambien se incluye y se utiliza para identificar la sesion del RTSP para la que se utiliza la peticion. El mensaje de peticion de control puede ser un mensaje de peticion PLAY o un mensaje de peticion PAUSE.
E308. El servidor procesa el mensaje de peticion de control y analiza el campo cabecera que transporta el URI del tren de medios al que pertenece el flujo secundario y la informacion de identificacion del flujo secundario para obtener el RTSP URI del tren de medios y la informacion de identificacion del flujo secundario.
E309. Si el servidor acepta la peticion de control de reproduccion del flujo secundario, el servidor envfa al terminal un mensaje de respuesta 200 OK. El servidor determina el recurso multimedia segun el RTSP URI del tren de medios obtenido en E308, determina los datos multimedia del flujo secundario en el recurso multimedia segun la informacion de identificacion del flujo secundario y realiza una operacion de control de reproduccion solicitada para los datos multimedia del flujo secundario. Si la peticion de control de reproduccion es un mensaje de peticion PLAY, el servidor envfa los datos multimedia del flujo secundario al terminal; y si la peticion de control de reproduccion es un mensaje de peticion de PAUSE, el servidor deja de enviar los datos multimedia del flujo secundario al terminal.
E310. Si el servidor no acepta la peticion de control de reproduccion del flujo secundario, el servidor envfa al terminal un mensaje de respuesta de error.
En otra forma de configurar una sesion de RTSP, el servidor procesa una peticion RTSP SETUP de una manera diferente. Correspondientemente, el procedimiento de control del flujo secundario es tambien ligeramente diferente. Haciendo referencia a la Fig. 4, el procedimiento puede incluir principalmente los siguientes pasos:
E401. Un terminal envfa un mensaje de peticion Describe a un servidor, solicitando obtener informacion de descripcion de un contenido multimedia desde el servidor. Un request-uri en el mensaje de peticion Describe es un URI de un contenido multimedia de interes.
E402. El servidor envfa un mensaje de respuesta 200 OK al terminal, donde el mensaje de respuesta incluye la informacion de descripcion del contenido multimedia. La informacion de descripcion del contenido multimedia incluye: un URI para control agregado, el numero de trenes de medios, un RTSP URI de cada tren de medios, un protocolo utilizado para enviar cada tren de medios, un parametro de protocolo de transmision, informacion de codificacion multimedia, etc. Tambien se puede incluir la informacion de declaracion del flujo secundario de los trenes de medios.
E403. El terminal envfa un mensaje de peticion RTSP SETUP al servidor segun la informacion de descripcion del contenido multimedia, solicitando determinar un mecanismo de transmision para el tren 1 de medios y configurar una sesion de RTSP. El campo request-uri RTSP SETUP indica el RTSP uRi del tren 1 de medios. El mensaje de peticion RTSP SETUP incluye ademas un parametro de transmision del tren de medios y un campo cabecera pipelined-requests, en donde el campo cabecera se utiliza para transportar e indicar unicamente un grupo de mensajes de peticiones en lmea. Los mensajes de peticiones en lmea se refieren a que todos los mensajes de peticiones pueden enviarse en secuencia, sin esperar una respuesta a un mensaje de peticion previo antes de que se envfe un mensaje de peticion posterior.
E404. El terminal envfa al servidor un mensaje de peticion RTSP SETUP segun la informacion de descripcion del
5
10
15
20
25
30
35
40
45
50
55
60
contenido multimedia, solicitando determinar un mecanismo de transmision para el tren 2 de medios. El campo request-uri del mensaje de peticion RTSP SETUP indica el RTSP URI del tren 2 de medios. El mensaje de peticion RTSP SETUP incluye ademas un parametro de transmision del tren de medios. El mensaje de peticion RTSP SETUP incluye ademas un campo de pipelined-requests, cuyo valor es el mismo que el valor del campo cabecera pipelined-requests en E403.
Si el contenido multimedia incluye ademas otros trenes de medios, se repite E404, hasta que se procesen todos los trenes de medios, donde, el request-uri se reemplaza con el RTSP URI de otro tren de medios y el parametro de transmision correspondiente se reemplaza con el parametro de transmision del tren de medios. Tambien se incluye un campo pipelined-requests, cuyo valor es el mismo que el valor del campo cabecera pipelined-requests en E403.
E405. El terminal envfa al servidor un mensaje de peticion de control. El request-uri en el mensaje de peticion de control es el URI para el control agregado. El mensaje de peticion de control incluye un campo cabecera que transporta un URI de un tren de medios al que pertenece un flujo secundario e informacion de identificacion del flujo secundario. El identificador de sesion obtenido en E404 tambien se incluye y se utiliza para identificar la sesion de RTSP para la que se utiliza la peticion. El mensaje de peticion de control puede ser un mensaje de peticion RTSP PLAY o un mensaje de peticion RTSP PAUSE. El mensaje de peticion de control incluye ademas un campo de pipelined-requests, cuyo valor es el mismo que el valor del campo cabecera pipelined-requests en E403.
E406. El servidor determina si esta disponible un recurso multimedia que corresponde a un RTSP URI en un primer mensaje de peticion RTSP SETUP en el grupo de mensajes de peticion en lmea, si el parametro de transmision es aceptable, etc. El servidor configura una sesion de RTSP y genera un identificador de sesion de RTSP. El servidor determina si esta disponible un recurso multimedia que corresponde a un RTSP URI en un segundo mensaje de peticion RTSP SETUP en el grupo de mensajes de peticion en lmea, si el parametro de transmision es aceptable, etc. A continuacion, el servidor anade el tren de medios correspondiente a la sesion agregada. Si el contenido multimedia incluye ademas otros trenes de medios, es decir, el grupo de mensajes de peticion en lmea incluye ademas otros mensajes de peticion RTSP SETUP, el servidor determina si los recursos multimedia correspondientes a los RTSP URI en los otros mensajes de peticion RTSP SETUP estan disponibles, si los parametros de transmision son aceptables, etc. A continuacion, el servidor anade los trenes de medios correspondientes a la sesion agregada. El paso se repite hasta que se procesan todos los trenes de medios, es decir, se procesan todos los mensajes de peticion RTSP SETUP en el grupo de mensajes de peticion en lmea.
E407. El servidor procesa el mensaje de peticion de control y analiza el campo cabecera que transporta el URI del tren de medios al que pertenece el flujo secundario y la informacion de identificacion del flujo secundario para obtener el RTSP URI del tren de medios y la informacion de identificacion del flujo secundario.
E408. Si el servidor acepta la peticion de control de reproduccion del flujo secundario, el servidor envfa un mensaje de respuesta 200 OK correspondiente a cada mensaje de peticion RTSP SETUP en el grupo de mensajes de peticion en lmea al terminal en secuencia, donde el mensaje de respuesta incluye el identificador de sesion generado en E406. El servidor envfa al terminal un mensaje de respuesta 200 OK correspondiente a cada mensaje de peticion de control en el grupo de mensajes de peticion en lmea. El servidor determina el recurso multimedia segun el RTSP URI del tren de medios obtenido en E407, determina los datos multimedia del flujo secundario en el recurso multimedia segun la informacion de identificacion del flujo secundario, y realiza una operacion de control de reproduccion solicitada para los datos multimedia del flujo secundario. Si la peticion de control de reproduccion es un mensaje de peticion RTSP PLAY, el servidor envfa los datos multimedia del flujo secundario al terminal; y si la peticion de control de reproduccion es un mensaje de peticion RTSP PAUSE, el servidor deja de enviar los datos multimedia del flujo secundario al terminal.
E409. Si el servidor no acepta la peticion de control de reproduccion del flujo secundario, el servidor envfa un mensaje de respuesta 200 OK correspondiente a cada mensaje de peticion RTSp SETUP en el grupo de mensajes de peticion en lmea al terminal en secuencia, donde el mensaje de respuesta incluye el identificador de sesion generado en el paso 406. El servidor envfa al terminal un mensaje de respuesta de error correspondiente a cada mensaje de peticion de control en el grupo de mensajes de peticion en lmea.
Correspondiente al procedimiento de control de datos multimedia proporcionado por la realizacion de la presente invencion, una realizacion de la presente invencion proporciona ademas un aparato de control de datos multimedia. El aparato esta situado en el lado del servidor. Haciendo referencia a la Fig. 5, el aparato incluye: una primera unidad 501 de recepcion de mensajes, configurada para recibir un mensaje de peticion de control enviado por un terminal, donde el mensaje de peticion de control transporta informacion de identificacion de un flujo secundario y un identificador de recursos uniforme URI de un tren de medios al que pertenece el flujo secundario, donde, el mensaje de peticion de control incluye un mensaje de peticion RTSP PlaY de protocolo de transmision en tiempo real o un mensaje de peticion RTSP PAUSE;
una unidad 502 de obtencion de informacion, configurada para obtener la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario;
una unidad 503 de determinacion de datos, configurada para determinar, segun la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario, datos multimedia del flujo secundario; y
5
10
15
20
25
30
35
40
45
50
55
una unidad 504 de control multimedia, configurada para realizar, basado en los datos multimedia, una operacion de control solicitada por el terminal, para el flujo secundario.
Cuando el mensaje de peticion de control es un mensaje de peticion de control independiente basado en un unico tren de medios, la informacion de identificacion del flujo secundario es transportada por un campo cabecera del mensaje de peticion de control y el URI del tren de medios al que pertenece el flujo secundario es transportado por un campo request-uri del mensaje de peticion de control; en este caso, la unidad 502 de obtencion de informacion puede analizar espedficamente el campo cabecera del mensaje de peticion de control para obtener la informacion de identificacion del flujo secundario, y analizar el campo request-uri del mensaje de peticion de control para obtener el URI del tren de medios al que pertenece el flujo secundario.
Alternativamente, cuando el mensaje de peticion de control es un mensaje de peticion de control independiente basado en un solo tren de medios, tanto la informacion de identificacion del flujo secundario como el URI del tren de medios al que pertenece el flujo secundario pueden ser transportadas por un campo request-uri del mensaje de peticion de control; en este caso, la unidad 502 de obtencion de informacion puede analizar espedficamente el campo request-uri del mensaje de peticion de control para obtener la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario.
Cuando el mensaje de peticion de control es un mensaje de peticion de control agregado basado en multiples trenes de medios, tanto la informacion de identificacion del flujo secundario como el URI del tren de medios al que pertenece el flujo secundario pueden ser transportadas por un campo cabecera del mensaje de peticion de control; en este caso, la unidad 502 de obtencion de informacion puede analizar espedficamente el campo cabecera del mensaje de peticion de control para obtener la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario.
Para permitir que el terminal obtenga la informacion de identificacion del flujo secundario, despues de que se reciba un mensaje de peticion de informacion de descripcion enviado por el terminal, cuando se devuelve un mensaje de respuesta, se puede transportar informacion de declaracion del flujo secundario en el mensaje de respuesta. En este caso, el aparato puede incluir ademas:
una segunda unidad de recepcion de mensajes, configurada para recibir un mensaje de peticion de informacion de descripcion enviado por el terminal; y
una primera unidad de respuesta, configurada para devolver al terminal un mensaje de respuesta que transporta informacion de declaracion del flujo secundario, de manera que el terminal obtiene la informacion de identificacion del flujo secundario segun la informacion de declaracion del flujo secundario.
La informacion de declaracion del flujo secundario puede ser transportada en un cuerpo de mensaje o campo cabecera del mensaje de respuesta. Es decir, la informacion de declaracion del flujo secundario puede usarse como parte de la informacion de descripcion multimedia, y la informacion de descripcion multimedia se convierte en un archivo SDP. Alternativamente, puede generarse un campo cabecera para el mensaje de respuesta, y la informacion de declaracion del flujo secundario puede ser transportada en el campo cabecera.
Cuando el terminal envfa un mensaje de peticion de control, la informacion de identificacion del flujo secundario transportada en el mismo puede ser incorrecta. Por lo tanto, para garantizar que el control del flujo secundario se puede realizar normalmente, el aparato puede incluir ademas:
una unidad de control de errores, configurada para determinar que la informacion de identificacion del flujo secundario transportada en el mensaje de peticion de control es incorrecta y devolver al terminal un mensaje de respuesta que transporta informacion de declaracion del flujo secundario, de modo que el terminal obtiene de nuevo informacion de identificacion del flujo secundario segun la informacion de declaracion del flujo secundario transportada en el mensaje de respuesta y reenvfa un mensaje de peticion de control.
En una aplicacion real, es posible que algunos servidores no soporten el control del flujo secundario. Para aplicar correctamente el control del flujo secundario, de una manera, el mensaje de peticion de control puede transportar ademas una etiqueta de funcion de control del flujo secundario. En este caso, el aparato puede incluir ademas: una primera unidad de obtencion de etiqueta de funcion de control del flujo secundario, configurada para obtener la etiqueta de funcion de control del flujo secundario; y
una primera unidad de control, configurada para: si se puede identificar correctamente la etiqueta de funcion de control del flujo secundario, activar la unidad de analisis de mensajes para continuar la realizacion de la operacion de obtencion de informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario y subsiguientes, o de lo contrario, rechazar la peticion de control, y devolver un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario no es soportado por el terminal.
La etiqueta de funcion de control del flujo secundario puede transportarse en un campo cabecera requerir del mensaje de peticion de control.
Correspondientemente, la primera unidad de obtencion de etiqueta de funcion de control del flujo secundario puede configurarse espedficamente para analizar el campo cabecera requerir del mensaje de peticion de control para obtener la etiqueta de funcion de control del flujo secundario.
5
10
15
20
25
30
35
40
45
50
55
En otra forma de aplicacion, la etiqueta de funcion de control del flujo secundario puede transportarse tambien en un mensaje de peticion RTSP SETUP, y el aparato puede incluir ademas:
una segunda unidad de obtencion de etiqueta de funcion de control del flujo secundario, configurada para: recibir un mensaje de peticion RTSP SETUP enviado por el terminal, en donde el mensaje de peticion RTSP SETUP transporta una etiqueta de funcion de control del flujo secundario; y obtener la etiqueta de funcion de control del flujo secundario; y
una segunda unidad de control, configurada para: si la etiqueta de funcion de control del flujo secundario se puede identificar correctamente, devolver un mensaje de respuesta que transporte informacion que indica que el control del flujo secundario es soportado por el terminal, de manera que el terminal inicie el control del flujo secundario; o de otro modo, devolver un mensaje de respuesta que transporte la informacion que indique que el control del flujo secundario no esta soportado por el terminal.
En una aplicacion espedfica, la etiqueta de funcion de control del flujo secundario es transportada en un campo cabecera de soporte del mensaje de peticion RTSP SETUP.
Correspondientemente, la segunda unidad de obtencion de etiqueta de funcion de control del flujo secundario puede configurarse espedficamente para analizar el campo cabecera de soporte del mensaje RTSP SETUP para obtener la etiqueta de funcion de control del flujo secundario.
En el caso en donde coexisten multiples tipos de codificacion, para simplificar el proceso de identificacion del servidor, el terminal puede transportar ademas informacion de tipo de codificacion del flujo secundario al enviar el mensaje de peticion de control. En este caso, el aparato puede incluir ademas:
una unidad de obtencion de tipo de codificacion, configurada para obtener un tipo de codificacion del flujo secundario segun la informacion del tipo de codificacion del flujo secundario, para determinar el flujo secundario correspondiente a la informacion de identificacion del flujo secundario segun el tipo de codificacion. La realizacion del aparato se describe sobre la base de las realizaciones del procedimiento precedente. Para lo que no se detalla, se puede hacer referencia a la descripcion de las realizaciones del procedimiento, y en el presente documento no se proporciona ninguna descripcion repetida.
Es comprensible para una persona de experiencia normal en la tecnica que todos o parte de los pasos en las realizaciones del procedimiento anterior pueden ser aplicados por un hardware pertinente instructor de un programa. El programa puede almacenarse en un medio de almacenamiento legible por ordenador. Cuando se ejecuta el programa, se incluyen los siguientes pasos: recibir un mensaje de peticion de control enviado por un terminal, donde el mensaje de peticion de control transporta informacion de identificacion de un flujo secundario y un identificador de recursos uniforme URI de un tren de medios al que pertenece el flujo secundario; obtener la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario; determinar, segun la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario, datos multimedia del flujo secundario; y realizar, basado en los datos multimedia, una operacion de control solicitada por el terminal, para el flujo secundario. El medio de almacenamiento puede ser ROM/RAM, un disco magnetico, un CD-ROM, etc.
La realizacion de la presente invencion se ha descrito anteriormente principalmente desde la perspectiva de un servidor. A continuacion se describe un procedimiento de control multimedia proporcionado por una realizacion de la presente invencion desde la perspectiva de un terminal. Haciendo referencia a la Fig. 6, el procedimiento incluye los siguientes pasos:
E601. Obtener informacion de identificacion de un flujo secundario y un identificador de recursos uniforme URI de un tren de medios al que pertenece el flujo secundario.
E602. Enviar un mensaje de peticion de control que transporta a un servidor la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario.
E603. Despues de recibir un mensaje de respuesta devuelto por el servidor, realizar una operacion de control correspondiente para el flujo secundario.
Cuando el mensaje de peticion de control es un mensaje de peticion de control independiente basado en un unico tren de medios, la informacion de identificacion del flujo secundario es transportada por un campo cabecera del mensaje de peticion de control, y el URI del tren de medios al que pertenece el flujo secundario es transportado por un campo request-uri del mensaje de peticion de control; o cuando el mensaje de peticion de control es un mensaje de peticion de control independiente basado en un unico tren de medios, tanto la informacion de identificacion del flujo secundario como el URI del tren de medios al que pertenece el flujo secundario son transportados por un campo request-uri del mensaje de peticion de control; o cuando el mensaje de peticion de control es un mensaje de peticion de control agregado basado en multiples trenes de medios, tanto la informacion de identificacion del flujo secundario como el URI del tren de medios al que pertenece el flujo secundario son transportados por un campo cabecera del mensaje de peticion de control.
Espedficamente, cuando es necesario obtener informacion de identificacion de un flujo secundario y un URI de un tren de medios al que pertenece el flujo secundario, puede enviarse al servidor un mensaje de peticion de
5
10
15
20
25
30
35
40
45
50
55
60
informacion de la descripcion, y la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario puede obtenerse a partir de un mensaje de respuesta que es devuelto por el servidor y transporta informacion de declaracion del flujo secundario. La informacion de declaracion del flujo secundario puede ser transportada en un cuerpo de mensaje o campo cabecera del mensaje de respuesta. Por lo tanto, el terminal puede analizar el cuerpo del mensaje o el campo cabecera del mensaje de respuesta para obtener la informacion de la declaracion del flujo secundario.
En una aplicacion real, debido a que el terminal puede obtener informacion de identificacion de un flujo secundario de otras maneras, la informacion de identificacion de un flujo secundario transportado en el mensaje de peticion de control enviado puede ser incorrecta; despues de que el servidor detecta el error, el servidor puede devolver al terminal un mensaje de respuesta que transporta la informacion de identificacion correcta de todos los flujos secundarios. Por lo tanto, despues de que el terminal envfa el mensaje de peticion de control, si el terminal recibe un mensaje de respuesta que es devuelto por el servidor y transporta informacion de declaracion del flujo secundario, el terminal puede obtener de nuevo informacion de identificacion del flujo secundario segun la informacion de declaracion del flujo secundario y reenviar un mensaje de peticion de control.
Ademas, en una aplicacion real, es posible que algunos servidores no soporten el control del flujo secundario. Por lo tanto, si no se realiza ningun procesamiento, despues de que el servidor reciba un mensaje de peticion de control desde el terminal, el procesamiento se puede realizar basado en el tren de medios completo incluso si informacion tal como la informacion de identificacion de un flujo secundario es transportada en el mensaje de peticion de control. Para evitar este fenomeno, en la realizacion de la presente invencion, cuando el terminal envfa un mensaje de peticion de control, el mensaje de peticion de control puede transportar ademas una etiqueta de funcion de control del flujo secundario, de manera que despues de que el servidor reciba el mensaje de peticion de control, si el control del flujo secundario no es soportado, el servidor no puede identificar correctamente la etiqueta de funcion de control del flujo secundario y, entonces, puede devolver, ademas, un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario no es soportado por el terminal, en lugar de realizar el control basado en el tren de medios completo.
En otra forma de aplicacion, cuando se envfa al servidor un mensaje de peticion RTSP SETUP, el mensaje de peticion RTSP SETUP puede transportar una etiqueta de funcion de control del flujo secundario, de manera que cuando el servidor no soporta el control del flujo secundario, el servidor devuelve un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario no esta soportado por el terminal; definitivamente, si se soporta el control del flujo secundario, el servidor puede devolver un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario es soportado por el terminal. Correspondientemente, si el terminal sabe, analizando el mensaje de respuesta del servidor, que el servidor soporta el control del flujo secundario, el terminal puede iniciar una peticion de control de flujo secundario al servidor; de lo contrario, si el terminal sabe que el servidor no soporta el control del flujo secundario, el terminal no inicia una peticion de control del flujo secundario al servidor.
En el caso donde coexisten multiples tipos de codificacion, para simplificar el proceso de identificacion del servidor, el terminal puede transportar ademas informacion de tipo de codificacion del flujo secundario en el mensaje de peticion de control, de manera que el servidor obtiene el tipo de codificacion del flujo secundario segun la informacion de tipo de codificacion del flujo secundario y determina el flujo secundario correspondiente a la informacion de identificacion del flujo secundario segun el tipo de codificacion.
Correspondiendo al procedimiento anterior, una realizacion de la presente invencion proporciona ademas un aparato de control de datos multimedia. Haciendo referencia a la Fig. 7, el aparato incluye:
una unidad 701 de obtencion de informacion de flujo secundario, configurada para obtener informacion de identificacion de un flujo secundario y un identificador de recursos uniforme URI de un tren de medios al que pertenece el flujo secundario;
una unidad 702 de envfo de mensajes, configurada para enviar a un servidor un mensaje de peticion de control que transporta la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario; y
una unidad 703 de realizacion de la operacion, configurada para realizar una operacion de control correspondiente para el flujo secundario despues de que se reciba un mensaje de respuesta devuelto por el servidor.
Cuando el mensaje de peticion de control es un mensaje de peticion de control independiente basado en un unico tren de medios, la informacion de identificacion del flujo secundario es transportada por un campo cabecera del mensaje de peticion de control y el URI del tren de medios al que pertenece el flujo secundario es transportado por un campo request-uri del mensaje de peticion de control; o cuando el mensaje de peticion de control es un mensaje de peticion de control independiente basado en un unico tren de medios, tanto la informacion de identificacion del flujo secundario como el URI del tren de medios al que pertenece el flujo secundario son transportados por un campo request-uri del mensaje de peticion de control; o cuando el mensaje de peticion de control es un mensaje de peticion de control agregado basado en multiples trenes de medios, tanto la informacion de identificacion del flujo secundario como el URI del tren de medios al que pertenece el flujo secundario son transportadas por un campo cabecera del mensaje de peticion de control.
5
10
15
20
25
30
35
40
45
50
55
En una forma de aplicacion, la unidad 701 de obtencion de informacion del flujo secundario puede incluir:
una subunidad de envfo de mensajes de peticion de informacion de descripcion, configurada para enviar al servidor
un mensaje de peticion de informacion de descripcion; y
una subunidad de obtencion, configurada para obtener la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario, a partir de un mensaje de respuesta que es devuelto por el servidor y que transporta informacion de declaracion del flujo secundario.
Debido a que el terminal puede obtener informacion de identificacion de un flujo secundario de otras maneras, la informacion de identificacion de un flujo secundario transportada en el mensaje de peticion de control enviado puede ser incorrecta; despues de que el servidor detecta el error, el servidor puede devolver un mensaje de respuesta que transporte al terminal la informacion de identificacion correcta de todos los flujos secundarios. Correspondientemente, el aparato puede incluir ademas:
una unidad de reenvfo, configurada para: si un mensaje de respuesta que es devuelto por el servidor y que transporta informacion de declaracion del flujo secundario es recibido despues de que se envfa el mensaje de peticion de control, obtener de nuevo informacion de identificacion del flujo secundario segun la informacion de declaracion del flujo secundario y reenviar un mensaje de peticion de control.
Ademas, en una aplicacion real, es posible que algunos servidores no soporten el control del flujo secundario. Por lo tanto, si no se realiza ningun procesamiento, despues de que el servidor reciba un mensaje de peticion de control desde el terminal, el procesamiento se puede realizar basado en el tren de medios completo incluso si informacion tal como la informacion de identificacion de un flujo secundario es transportada en el mensaje de peticion de control. Para evitar este fenomeno, el mensaje de peticion de control transporta ademas una etiqueta de funcion de control del flujo secundario, de manera que cuando el servidor no soporta el control del flujo secundario, el servidor devuelve un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario no es soportado por el terminal.
Alternativamente, el aparato puede incluir ademas:
una unidad de envfo de mensaje de peticion RTSP SETUP, configurada para enviar al servidor un mensaje de peticion RTSP SETUP, donde el mensaje de peticion RTSP SETUP transporta una etiqueta de funcion de control del flujo secundario, de manera que cuando el servidor no soporta el control del flujo secundario, el servidor devuelve un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario no es soportado por el terminal.
En el caso donde coexisten multiples tipos de codificacion, para simplificar el proceso de identificacion del servidor, la informacion de tipo de codificacion del flujo secundario puede ser transportada ademas en el mensaje de peticion de control, de modo que el servidor obtenga el tipo de codificacion del flujo secundario segun la informacion del tipo de codificacion del flujo secundario y determine el flujo secundario correspondiente a la informacion de identificacion del flujo secundario segun el tipo de codificacion.
Debe observarse que el procedimiento y aparato de control de datos multimedia descritos desde la perspectiva del terminal corresponden al procedimiento y aparato de control de datos multimedia anteriores descrito desde la perspectiva del servidor. Por lo tanto, para lo que no se detalla, se puede hacer referencia a la descripcion anterior, y no se proporciona ninguna descripcion repetida en el presente documento.
Es comprensible para una persona de experiencia normal en la tecnica que todo o una parte de los pasos en las realizaciones del procedimiento anterior puede ser aplicado por un hardware pertinente instructor de un programa. El programa puede almacenarse en un medio de almacenamiento legible por ordenador. Cuando se ejecuta el programa, se incluyen los siguientes pasos: obtener informacion de identificacion de un flujo secundario y un identificador de recurso uniforme, URI, de un tren de medios al que pertenece el flujo secundario; enviar un mensaje de peticion de control que transporta la informacion de identificacion del flujo secundario y el URI del tren de medios para el que el flujo secundario pertenece a un servidor; y despues de recibir un mensaje de respuesta devuelto por el servidor, realizar una operacion de control correspondiente para el flujo secundario. El medio de almacenamiento puede ser una ROM/RAM, un disco magnetico, un CD-ROM, etc.
Debe observarse que el terminal en las realizaciones de la presente invencion puede ser un telefono movil, una PDA, un ordenador portatil, un ordenador de sobremesa, etc., y que el servidor puede ser una estacion base, un servidor multimedia, etc. Ademas, los pasos de todas las realizaciones anteriores pueden ser ejecutados por un procesador del servidor o terminal.
El procedimiento y aparato de control de datos multimedia proporcionados por la presente invencion se describen en detalle anteriormente. Aunque el principio y los modos de aplicacion de la presente invencion se describen con referencia a las realizaciones de ejemplo, las realizaciones solo pretenden ayudar a comprender el procedimiento y la idea central de la presente invencion. Ademas, con respecto a las formas de aplicacion espedficas y al alcance de las aplicaciones, pueden hacerse modificaciones y variaciones por un experto normal en la tecnica segun las reivindicaciones de la presente invencion. Por lo tanto, la memoria descriptiva no se interpretara como una limitacion de la presente invencion.

Claims (5)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    REIVINDICACIONES
    1. Un procedimiento de control de datos multimedia realizado por un aparato servidor, caracterizado por que comprende:
    recibir un mensaje de peticion de control enviado por un terminal (E101), en donde el mensaje de peticion de control transporta informacion de identificacion de un flujo secundario y un identificador de recursos uniforme URI de un tren de medios al que pertenece el flujo secundario; en donde el mensaje de peticion de control es un mensaje de peticion PLAY, RTSP, protocolo de transmision en tiempo real, o un mensaje de peticion RTSP PAUSE; obtener la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario (E102);
    determinar, segun la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario, datos multimedia del flujo secundario (E103); y
    realizar, basado en los datos multimedia, una operacion de control solicitada por el terminal, para el flujo secundario (E104);
    en donde, la operacion de control es control reproduccion o control pausa;
    en donde antes de recibir un mensaje de peticion de control enviado por un terminal, el procedimiento comprende ademas: recibir un mensaje de peticion de informacion de descripcion enviado por el terminal; y devolver al terminal un mensaje de respuesta que transporta informacion de declaracion del flujo secundario, de manera que el terminal obtiene la informacion de identificacion del flujo secundario segun la informacion de declaracion del flujo secundario; o
    en donde antes de recibir un mensaje de peticion de control enviado por el terminal, el procedimiento comprende ademas: recibir un mensaje de peticion RTSP SETUP enviado por el terminal, en donde el mensaje de peticion RTSP SETUP transporta una etiqueta de funcion de control del flujo secundario; obtener la etiqueta de funcion de control del flujo secundario; y, si la etiqueta de funcion de control del flujo secundario puede ser identificada correctamente, devolver un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario es soportado por el terminal, de manera que el terminal inicia el control del flujo secundario; de lo contrario, devolver un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario no es soportado por el terminal.
  2. 2. El procedimiento segun la reivindicacion 1, en donde: cuando el mensaje de peticion de control es un mensaje de peticion de control independiente basado en un unico tren de medios, la informacion de identificacion del flujo secundario es transportada por un campo cabecera del mensaje de peticion de control, y el URI del tren de medios al que pertenece el flujo secundario es transportado por un campo request-uri del mensaje de peticion de control; o cuando el mensaje de peticion de control es un mensaje de peticion de control independiente basado en un unico tren de medios, tanto la informacion de identificacion del flujo secundario como el URI del tren de medios al que pertenece el flujo secundario son transportados por un campo request-uri del mensaje de peticion de control; o cuando el mensaje de peticion de control es un mensaje de peticion de control agregado basado en multiples trenes de medios, tanto la informacion de identificacion del flujo secundario como el URI del tren de medios al que pertenece el flujo secundario son transportados por un campo cabecera del mensaje de peticion de control.
  3. 3. El procedimiento segun la reivindicacion 1 o 2, en donde el mensaje de peticion de control transporta ademas una etiqueta de funcion de control del flujo secundario y el procedimiento comprende ademas: obtener la etiqueta de funcion de control del flujo secundario; y si la etiqueta de funcion de control del flujo secundario puede ser identificada correctamente, continuar realizando la operacion de obtener la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario y operaciones subsiguientes o, si no, rechazar la peticion de control, y devolver un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario no es soportado por el terminal; o
    en donde el mensaje de peticion de control transporta ademas informacion de tipo de codificacion del flujo secundario, y el procedimiento comprende ademas: obtener un tipo de codificacion del flujo secundario segun la informacion de tipo de codificacion del flujo secundario, y determinar el flujo secundario correspondiente a la informacion de identificacion del flujo secundario segun el tipo de codificacion.
  4. 4. Un aparato de control de datos multimedia, caracterizado por que comprende:
    una primera unidad (501) de recepcion de mensajes, configurada para recibir un mensaje de peticion de control enviado por un terminal, en donde el mensaje de peticion de control transporta informacion de identificacion de un flujo secundario y un identificador de recursos uniforme URI de un tren de medios al que pertenece el flujo secundario; en donde el mensaje de peticion de control es un mensaje de peticion de RTSP PLAY, RTSP, protocolo de transmision en tiempo real, o un mensaje de peticion de RTSP PAUSE;
    una unidad (502) de obtencion de informacion, configurada para obtener la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario;
    una unidad (503) de determinacion de datos, configurada para determinar datos multimedia del flujo secundario, segun la informacion de identificacion del flujo secundario y el URI del tren de medios al que pertenece el flujo secundario; y
    una unidad (504) de control multimedia, configurada para realizar, basada en los datos multimedia, una operacion de control solicitada por el terminal, para el flujo secundario; en donde, la operacion de control es control de reproduccion o control de pausa;
    en donde el aparato comprende ademas: una segunda unidad de recepcion de mensajes, configurada para recibir
    un mensaje de peticion de informacion de descripcion enviado por el terminal; y una primera unidad de respuesta, configurada para devolver un mensaje de respuesta que transporta al terminal informacion de declaracion del flujo secundario, de manera que el terminal obtiene la informacion de identificacion del flujo secundario segun la informacion de declaracion del flujo secundario; o
    5 en donde el aparato comprende ademas: una segunda unidad de obtencion de etiqueta de funcion de control del flujo secundario, configurada para: recibir un mensaje de peticion RTSP SETUP enviado por el terminal, en donde el mensaje de peticion RTSP SETUP transporta una etiqueta de funcion de control del flujo secundario; y obtener la etiqueta de funcion de control del flujo secundario; y una segunda unidad de control, configurada para: si la etiqueta de funcion de control del flujo secundario puede ser identificada correctamente, devolver un mensaje de respuesta 10 que transporta informacion que indica que el control del flujo secundario es soportado por el terminal, de manera que el terminal inicia el control del flujo secundario; de lo contrario, devuelve un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario no es soportado por el terminal.
  5. 5. El aparato segun la reivindicacion 4, en donde el mensaje de peticion de control transporta ademas una etiqueta de funcion de control del flujo secundario y el aparato comprende ademas:
    15 una primera unidad de obtencion de etiqueta de funcion de control del flujo secundario, configurada para obtener la etiqueta de funcion de control del flujo secundario; y
    una primera unidad de control, configurada para: si la etiqueta de funcion de control del flujo secundario puede ser identificada correctamente, activar la unidad de analisis de mensajes para continuar realizando la operacion de obtener la informacion de identificacion del flujo secundario y el uRl del tren de medios al que pertenece el flujo 20 secundario y las operaciones subsiguientes, o si no, rechazar la peticion de control, y devolver un mensaje de respuesta que transporta informacion que indica que el control del flujo secundario no es soportado por el terminal.
ES12797017.6T 2011-06-30 2012-03-13 Procedimiento y aparato de control de datos multimedia Active ES2625512T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201110182112 2011-06-30
CN201110182112.XA CN102857478B (zh) 2011-06-30 2011-06-30 媒体数据控制方法及装置
PCT/CN2012/072229 WO2012167638A1 (zh) 2011-06-30 2012-03-13 媒体数据控制方法及装置

Publications (1)

Publication Number Publication Date
ES2625512T3 true ES2625512T3 (es) 2017-07-19

Family

ID=47295446

Family Applications (1)

Application Number Title Priority Date Filing Date
ES12797017.6T Active ES2625512T3 (es) 2011-06-30 2012-03-13 Procedimiento y aparato de control de datos multimedia

Country Status (5)

Country Link
US (1) US20140115650A1 (es)
EP (1) EP2717537B1 (es)
CN (1) CN102857478B (es)
ES (1) ES2625512T3 (es)
WO (1) WO2012167638A1 (es)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7515710B2 (en) 2006-03-14 2009-04-07 Divx, Inc. Federated digital rights management scheme including trusted systems
CN102549557B (zh) 2009-01-07 2015-09-09 索尼克Ip股份有限公司 针对在线内容的媒体指南的特定化、集中式、自动化创建
JP5723888B2 (ja) 2009-12-04 2015-05-27 ソニック アイピー， インコーポレイテッド 基本ビットストリーム暗号材料伝送システムおよび方法
US8914534B2 (en) 2011-01-05 2014-12-16 Sonic Ip, Inc. Systems and methods for adaptive bitrate streaming of media stored in matroska container files using hypertext transfer protocol
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
US8909922B2 (en) 2011-09-01 2014-12-09 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US8964977B2 (en) 2011-09-01 2015-02-24 Sonic Ip, Inc. Systems and methods for saving encoded media streamed using adaptive bitrate streaming
US9313510B2 (en) 2012-12-31 2016-04-12 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
US9191457B2 (en) 2012-12-31 2015-11-17 Sonic Ip, Inc. Systems, methods, and media for controlling delivery of content
US9906785B2 (en) 2013-03-15 2018-02-27 Sonic Ip, Inc. Systems, methods, and media for transcoding video data according to encoding parameters indicated by received metadata
US9094737B2 (en) 2013-05-30 2015-07-28 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
US9967305B2 (en) * 2013-06-28 2018-05-08 Divx, Llc Systems, methods, and media for streaming media content
US10205954B2 (en) * 2013-10-23 2019-02-12 Qualcomm Incorporated Carriage of video coding standard extension bitstream data using MPEG-2 systems
US9866878B2 (en) 2014-04-05 2018-01-09 Sonic Ip, Inc. Systems and methods for encoding and playing back video at different frame rates using enhancement layers
JP2017084038A (ja) * 2015-10-27 2017-05-18 船井電機株式会社 コンテンツ配信装置およびクライアント機器
CN107231662B (zh) 2016-03-25 2020-11-10 华为技术有限公司 一种sdn网络中多流传输的方法和设备
US10649655B2 (en) * 2016-09-30 2020-05-12 Western Digital Technologies, Inc. Data storage system with multimedia assets
US11876840B2 (en) * 2018-09-12 2024-01-16 Samsung Electronics Co., Ltd. Method and apparatus for controlling streaming of multimedia data in a network
CN110233716A (zh) * 2019-05-31 2019-09-13 北京文香信息技术有限公司 一种通信交互方法、装置、存储介质、终端设备及服务器
CN113873343B (zh) * 2020-06-30 2023-02-24 北京开广信息技术有限公司 媒体流的自适应实时递送方法及服务器

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW522379B (en) * 2000-05-26 2003-03-01 Cyberlink Corp DVD playback system for displaying two types of captions and the playback method
US7191242B1 (en) * 2000-06-22 2007-03-13 Apple, Inc. Methods and apparatuses for transferring data
US7895350B1 (en) * 2001-07-05 2011-02-22 Motive, Inc. N-way data stream splitter
US7055169B2 (en) * 2002-04-19 2006-05-30 Opentv, Inc. Supporting common interactive television functionality through presentation engine syntax
US7480915B2 (en) * 2002-10-03 2009-01-20 Nokia Corporation WV-IMS relay and interoperability methods
JP4550044B2 (ja) * 2003-02-21 2010-09-22 パナソニック株式会社 オーディオビジュアル再生システムとオーディオビジュアル再生方法
WO2004100549A1 (ja) * 2003-05-08 2004-11-18 Sony Corporation 情報アクセスシステム，情報提供装置，情報アクセス装置，情報提供方法，および情報アクセス方法
CN101473654B (zh) * 2006-06-19 2011-08-03 艾利森电话股份有限公司 媒体频道管理
CN101399684B (zh) * 2007-09-26 2011-09-28 电信科学技术研究院 一种多媒体广播/组播业务分层传输方法及系统
CN101236567A (zh) * 2008-02-04 2008-08-06 上海升岳电子科技有限公司 一种实现在线网络多媒体应用的方法和终端设备
US20110138022A1 (en) * 2008-08-12 2011-06-09 Telefonaktiebolaget Lm Ericsson (Publ) Fast Content Switching in a Communication System
US8233026B2 (en) * 2008-12-23 2012-07-31 Apple Inc. Scalable video encoding in a multi-view camera system
WO2011125051A1 (en) * 2010-04-09 2011-10-13 Canon Kabushiki Kaisha Method for accessing a spatio-temporal part of a compressed video sequence
FR2959636B1 (fr) * 2010-04-28 2012-07-13 Canon Kk Procede d'acces a une partie spatio-temporelle d'une sequence video d'images
CN101951412B (zh) * 2010-10-15 2013-11-13 上海交通大学 基于http协议的多子流流媒体传输系统及其传输方法

Also Published As

Publication number Publication date
US20140115650A1 (en) 2014-04-24
WO2012167638A1 (zh) 2012-12-13
CN102857478A (zh) 2013-01-02
EP2717537B1 (en) 2017-03-01
EP2717537A1 (en) 2014-04-09
EP2717537A4 (en) 2014-12-10
CN102857478B (zh) 2016-09-28

Similar Documents

Publication Publication Date Title
ES2625512T3 (es) Procedimiento y aparato de control de datos multimedia
KR102580982B1 (ko) 미디어 데이터 스트리밍을 위한 선취 지원을 위한 데이터 시그널링
TWI714602B (zh) 超級本文傳輸協定(http)上動態自適應串流(dash)客戶經驗品質度量之中間軟體傳遞
Thomas et al. Enhancing MPEG DASH performance via server and network assistance
CN107925797B (zh) 用于获取音频数据的方法和设备
CN112106382B (zh) 检索媒体数据的方法、设备、存储介质
JP5930429B2 (ja) ファイル配信方式を使用したｉｐブロードキャストストリーミングサービスの配信
CN101924944B (zh) 可伸缩视频编码操作点选择方法、信息提供方法及设备
KR102045073B1 (ko) 유연한 ｍｍｔ 애셋 송수신 방법 및 그 장치
US20160337424A1 (en) Transferring media data using a websocket subprotocol
US20120173748A1 (en) Hybrid transport-layer protocol media streaming
US9369508B2 (en) Method for transmitting a scalable HTTP stream for natural reproduction upon the occurrence of expression-switching during HTTP streaming
TW202037177A (zh) 用於串流媒體資料之服務描述
US20180176278A1 (en) Detecting and signaling new initialization segments during manifest-file-free media streaming
TW201729601A (zh) 用於媒體資料之串流之期限發信
US10499094B2 (en) Transmission apparatus, transmitting method, reception apparatus, and receiving method
JP2017010537A (ja) コンテンツセントリックネットワークにおける柔軟なコマンドおよび制御
MX2015002628A (es) Sistema y metodo para entregar un contenido audio-visual a un dispositivo de un cliente.
JP2019525677A (ja) メディアデータストリーミングのためのｓｅｉトラックのシステムレベルシグナリング
TW202515175A (zh) 用於傳送ｗｅｂｒｔｃ媒體資料的ｐｄｕ集合和叢發結束標記的信令使用
KR20250168216A (ko) 대역내 지연 측정을 위한 실시간 전송 프로토콜 헤더 확장
CN101860537B (zh) 一种媒体播放业务的实现方法及媒体服务器
CN110870323A (zh) 使用全向媒体格式处理媒体数据
Mohamed Streaming MPEG-4 over IP and Broadcast Networks: DMIF based architectures
Haghighi et al. Realizing MPEG-4 streaming over the Internet: a client/server architecture using DMIF