CO5600215A1

RTP Payload Format

Abstract

An apparatus comprising: Means for encrypting a data stream transmission with an arbitrary block size to form a plurality of encryption units; y Means for packaging the plurality of encryption units into a plurality of RTP packets each including: An RTP packet header; One or more data from a common data stream transmission and selected from the group consisting of: One or more of said encryption units; and fragments of one of said encryption units; yA header of RTP data formats for each of said data and that includes, for the corresponding encryption units, a limit for the arbitrary block size. The apparatus as defined in claim 1, further comprising: Means for reassembling the plurality of encryption units using: The data in the plurality of RTP packets, and the respective limits for the arbitrary block size in the RTP data format header respective; Means for decrypting the plurality of encryption units to form the data stream transmission. The apparatus as defined in the. claim 2, wherein: Each of said RTP data format headers further comprises one or more attributes of the corresponding data; yThe apparatus further comprises means for representing the data flow transmission formed using the attributes of the corresponding data.

CO5600215A1, drawing sheet 1 — Sheet 1 of 45

Term

No projected expiry on record.

56 claims: 24 independent, 32 dependent

1
An apparatus that understands. 1. Un aparato que comprende. Means for encrypting a data stream transmission with an arbitrary block size to form a plurality of encryption units; and Medios para encriptar una transmisión de' flujo de datos con un tamaño de bloque arbitrario para formar una pluralidad de unidades de encriptación; y Means for packaging the plurality of encryption units in a plurality of RTP packets each including:Medios para empaquetar la pluralidad de unidades de encriptación en una pluralidad de paquetes RTP que incluye cada uno: An RTP packet header;Un encabezado de paquete RTP;One or more data from a common data stream transmission and selected from the group consisting of: Uno o más datos de una transmisión de flujo de datos común y seleccionado del grupo que consiste de: One or more of said encryption units;Una o más de dichas unidades de encriptación;Fragmentos de una de dichas unidades de encriptación;y Fragments of one of said encryption units;and A header of RTP data formats for each of said data and that includes, for the corresponding encryption units, a limit for the arbitrary block size. Un encabezado de formatos de datos RTP para cada uno de dichos datos y que Incluye, para las unidades de encriptación correspondiente, un límite para el tamaño de bloque arbitrario.
2
El aparato como definió en la reivindicación 1, que comprende además:two. The apparatus as defined in claim 1, further comprising: Means for reassembling the plurality of encryption units using: Medios para reensamblar la pluralidad de unidades de encriptación utilizando: Loa datos en la pluralidad de paquetes RTP, y The data in the plurality of RTP packets, and Los límites respectivos para el tamaño de bloque arbitrario en el encabezado de formato de datos The respective limits for the arbitrary block size in the data format header RTP respectivo;Respective RTP;Means for decrypting the plurality of encryption units to form the transmission of data flow. Medios para desencriptar la pluralidad de unidades de encriptación para forma la transmisión de flujo de datos.
3
The apparatus as defined in claim 2,. 3. El aparato como definió en la reivindicación 2, . en donde:where: Cada uno de dichos encabezamientos de formato de datos RTP comprende además uno o más atributos de los dato correspondientes;y Each of said RTP data format headers further comprises one or more attributes of the corresponding data;and El aparato comprende además medios para representar la transmisión de flujo de datos formada utilizando los atributos de los datos correspondientes. The apparatus further comprises means to represent the data stream transmission formed using the attributes of the corresponding data.
4
El aparato como definió en la reivindicación 2, en donde los atributos en cada uno de los encabezamientos de formatos de datos RTP son seleccionados del grupo que consiste:Four. The apparatus as defined in claim 2, wherein the attributes in each of the RTP data format headers are selected from the group consisting of: Información de tiempo;y Time information;and Información de cuadro de compresión de video. Video compression chart information.
5
The apparatus as defined in claim 2, further comprising means for transmitting the plurality of RTP packet over a network. 5. El aparato como definió en la reivindicación 2, que comprende además medios para transmitir la pluralidad de paquetea RTP sobre una red.
6
An apparatus comprising means for logically separating data types from media in a data stream transmission that includes a plurality of said media data types; 6. Un aparato que comprende medios para separar lógicamente los tipos de datos de los medios en una transmisión de flujos de datos que incluye una pluralidad de dichos tipos datos de medios; and y Means for forming a plurality of RTP packets of the data stream transmission, each of said RTP packets includes:Medios para formar una pluralidad de paquetes de RTP de la transmisión de flujo de datos, cada uno de dichos paquetes RTP incluye: Only one of these types of media data;Solo uno de dichos tipos de datos de medios;An RTP packet header;Un encabezado de paquete RTP;One of the headings of more variable length RTP data formats that each have one or more attributes;and Uno de los encabezamientos de formatos de datos RTP de longitud más variables que tienen cada uno uno o más atributos;y RTP data corresponding to each of said RTP data format headers and which are described by one or more attributes there. Unos datos RTP que corresponde a cada uno de dichos encabezamientos de formato de datos RTP y que son descritos por uno o más atributos allí.
7
The apparatus as defined in claim 6, further comprising:7. El aparato como definió en la reivindicación 6, que comprende además.: Means for extracting data from the plurality of RTP packets;and Medios para extraer los datos de la pluralidad de paquetes RTP;y Means for representing each data in the plurality of RTP packets that use the one or more attributes in the corresponding RTP data format header. Medios para representar cada dato en la pluralidad de paquetes RTP que utiliza los unos o más atributos en el correspondiente encabezado de formato de datos RTP. Θ The apparatus as defined in claim 7, wherein: Θ. El aparato como definió en la reivindicación 7, en donde: Cada uno de dichos datos comprende datos de video;y Each of said data comprises video data;and Los atributos en cada uno de dichos encabezamientos de formado de datos RTP son seleccionados del grupo que consiste de: The attributes in each of said RTP data formation headers are selected from the group consisting of: P · P· Información de tiempo, y Time information, and Información de cuadro de compresión de video. Video compression chart information.
8
9. The apparatus as defined in claim 7, wherein the means for extracting further comprises, for each of said RTP data:9. El aparato como definió en la reivindicación 7, en donde los medios para extraer comprende además, para cada uno de dichos datos RTP: Media, where the RTP data includes a plurality of portions of one of the media data types, to assemble the plurality of portions of one of the media data types into a contiguous data;Medios, donde los datos RTP incluyen una pluralidad de porciones de uno de los tipos de datos de medios, para ensamblar la pluralidad de porciones de uno de los tipos de datos de medio en un dato contiguo;Media, where the RTF data includes a portion of one of the media data types, to assemble a portion of one of the media data types into contiguous data;and Medios, donde el dato RTF incluye una porción de uno de los tipos de datos de medio, para ensamblar una porción de uno de los tipos de datos de medio en unos datos contiguos;y Media, where the RTF data includes a fragment of a portion of one of the media data types, to assemble all the fragments of the portion of one of the media data types into a contiguous data. Medios, donde los datos RTF incluyen un fragmento de una porción de uno de los tipos de datos de medio, para ensamblar todos los fragmentos de la una porción de uno de los tipos de datos de medio en un dato contiguo.
9
10. The apparatus as defined in claim 9, further comprising:10. El aparato como definió en la reivindicación 9, que comprende además: Means for assembling, in respective chronological order corresponding to the plurality of media data types of the media file, the contiguous data;and Medios para ensamblar, en orden cronológico respectivo que corresponde a la pluralidad de tipos de datos de medio del archivo de medios, los datos contiguos;y Means for simultaneously representing chronologically ordered contiguous data of the plurality of media data types of the media file. Medios para representar simultáneamente los datos contiguos cronológicamente ordenados de la pluralidad de tipos de datos de medio del archivo de medios.
10
11. Una estructura de datos que tiene un formato de hilo para transmisión sobre una red, la estructura de datos que comprende una pluralidad de paquetes de medios simple formada de la pluralidad de paquetes de medios mezclados, en donde:eleven. A data structure having a thread format for transmission over a network, the data structure comprising a plurality of simple media packets formed from the plurality of mixed media packets, wherein: Cada paquete de medio mezclado incluye: Each package of mixed media includes: A data for each of a plurality of data stream transmission, where the data is encrypted and has an arbitrary block size;and Un dato para cada uno de una pluralidad de transmisión de flujo de datos, en donde los datos son encriptados y tienen un tamaño de bloque arbitrario;y A data header for each data and that includes a limit for the arbitrary block size;Un encabezado de dato para cada dato y que incluye un limite para el tamaño de bloque arbitrario;Cada uno de los paquetes de medios simple incluye una transmisión de flujo de datos, que corresponde a uno de los paquetes de medios mezclados, e incluye: Each of the simple media packets includes a data stream transmission, which corresponds to one of the mixed media packets, and includes: A data corresponding to one of the data of one of the mixed media packages;Un dato que corresponde a uno de los datos de uno.de los paquetes de medios mezclados;A data profile format header that corresponds to: Un encabezado de formato de perfil de datos que corresponde a: El un dato;y The one fact;and One of the headers of more data of one of the headers of more data of the mixed media package, where the data profile format header has a limit that corresponds to: Uno de los encabezamientos de más datos del uno de los encabezamientos de más datos de el un paquete de medios mezclado, en donde el encabezado de formato de perfil de datos tiene un limite que corresponde a: Los limites respectivos de el uno de los encabezamientos de más datos de el un paquete de medios mezclados;y The respective limits of the one of the headers of more data of the one package of mixed media;and El un dato. The one fact.
17
18. A method comprising:18. Un método que comprende: Encriptar una transmisión de flujo de datos con un tamaño de bloque arbitrario para formar una pluralidad de unidades de encriptación;y Encrypt a data stream transmission with an arbitrary block size to form a plurality of encryption units;and Empaquetar la pluralidad de unidades de encriptación en una pluralidad de paquetes RTP que incluye cada uno: Package the plurality of encryption units in a plurality of RTP packets that each includes: An RTP packet header;Un encabezado de paquete RTP;r r One or more data from a common data stream transmission and selected from the group consisting of: Uno o más datos de una transmisión de flujo de datos común y seleccionado del grupo que consiste de: One or more of said encryption units;and Una o más de dichas unidades de encriptación;y A fragment of one of said encryption units;Un fragmento de una de dichas unidades de encriptación;An RTP data format header for each of said data and that includes, for the corresponding encryption units, a limit for the size of the arbitrary block. ün encabezado de formato de datos RTP para cada una de dichos datos y que incluye, para las unidades de encriptación correspondientes, un límite para el tamaño del bloque arbitrario. f \ 19 · The method as defined in claim f\ 19· El método como se definió en la reivindicación 18, que comprende además: 18, which also includes: Reassemble the plurality of encryption units using: Reensamblar la pluralidad de unidades de encriptación utilizando: Los datos en la pluralidad de paquetes RTP;y The data in the plurality of RTP packets;and El límite respectivo del tamaño de bloque c The respective block size limit c arbitrario en el encabezado de formato de datos arbitrary in the data format header RTP respectivo;Respective RTP;Decrypt the plurality of encryption units to form the data stream transmission. Desencriptar la pluralidad de unidades de encriptación para formar la transmisión de flujo de datos. 20. El método como se definió en la reivindicación twenty. The method as defined in the claim
18
19, en donde:19, where: Cada uno de dichos encabezamientos en formato de datos RTP comprende además uno o más atributos de los datos correspondientes;y Each of said headers in RTP data format further comprises one or more attributes of the corresponding data;and El método comprende además representar la transmisión de flujo de datos formada utilizando los atributos de los datos correspondientes. The method further comprises representing the data stream transmission formed using the attributes of the corresponding data.
19
21. El método como se definió en la reivindicación twenty-one. The method as defined in the claim 19, en donde los atributos en cada uno de dichos encabezamientos de formatos de datos RTP son seleccionados del grupo que consiste de:19, wherein the attributes in each of said RTP data format headers are selected from the group consisting of: Información de tiempo;y Time information;and Información de compresión de video de cuadro. Video frame compression information.
20
22 The method as defined in the claim 22. El método como se definió en la reivindicación 19, que comprende además, antes de reensamblar, la pluralidad de paquetea RTP sobre una red a un cliente en el cual se preforma el reensamblaje. 19, which further comprises, before reassembly, the plurality of RTP packet over a network to a client in which reassembly is preformed.
22
24. A method comprising forming a plurality of RTP packets of the data stream transmission that includes a plurality of media data types, each of said RTP packets includes:24. Un método que comprende forma una pluralidad de paquetes RTP de la transmisión de flujo de datos que incluye una pluralidad de tipos de datos de medio, cada uno de dichos paquetes RTP incluye: One such type of media data;Uno de dichos tipos datos de medio;An RTP packet header. Un encabezado de paquete RTP. One of the RTP data format headers of more variable lengths that each has one or more attributes;and Uno de los encabezamientos de formato de datos RTP de longitudes más variables que tiene cada uno uno o más atributos;y An RTP data that corresponds to each of said RTP data format headers and that is being described by the one or more attributes there. Un dato RTP que corresponde a cada uno de dichos encabezamientos de formato de datos RTP y que está siendo descrito por el uno o más atributos allí.
23
25. The methods as defined in claim 24, further comprising:25. Los métodos como se definieron en la reivindicación 24, que comprende además: Extract the data from the plurality of RTP packets;and Extraer los datos de la pluralidad de paquetes RTP;y Represent each data in the plurality of RTP packets using the one or more attributes in the corresponding RTP data format header. Representar cada dato en la pluralidad de los paquetes RTP utilizando el uno o más atributos en el correspondiente encabezado de formato de datos RTP.
24
26. The method as defined in the claim 26. El método como se definió en ia reivindicación 25, en donde los atributos en cada uno de los encabezamientos de formato de datos RTP son seleccionados del grupo que consiste de:25, wherein the attributes in each of the RTP data format headers are selected from the group consisting of: Información de tiempo;y Time information;and Información de compresión de video de cuadro. Video frame compression information.
25
27. The method as defined in the claim 27. El método como se definió en la reivindicación 25, en donde la extracción de los datos de la pluralidad de los paquetes RTP comprende además, para cada uno de dichos datos RTP:25, wherein the extraction of data from the plurality of RTP packets further comprises, for each of said RTP data: Que incluye uno pluralidad de porciones de uno de los tipos de datos de medio, ensamblando al pluralidad de porciones de uno de los tipos de datos de medio en unos datos contiguos;That includes one plurality of portions of one of the media data types, assembling the plurality of portions of one of the media data types in contiguous data;Que incluye una porción de uno de los tipos de datos de medio, ensamblando una porción de uno de los tipos de datos de medio en un dato contiguo;y That includes a portion of one of the media data types, assembling a portion of one of the media data types in a contiguous data;and Que incluye un fragmento de una porción de uno de los tipos de datos de medio, ensamblando todos los fragmentos de la una porción de uno de los tipos de datos de medio en un dato contiguo. That includes a fragment of a portion of one of the media data types, assembling all the fragments of the portion of one of the media data types in a contiguous data.
26
28. The method as defined in the claim 28. El método como se definió en la reivindicación 27, que comprende además:27, which also includes: Assemble, in respective chronological order corresponding to the plurality of media data types of the media file, the contiguous data;and Ensamblar, en orden cronológico respectivo que corresponde a la pluralidad de tipos de datos de medio del archivo de medios, los datos contiguos;y Representar simultáneamente los datos contiguos cronológicamente ordenados de la pluralidad de tipos de datos de medio del archivo de medios. Simultaneously represent the chronologically ordered contiguous data of the plurality of media data types in the media file.
28
30 A method comprising changing a plurality of mixed media packages into a plurality of simple media packages where:30. Un método que comprende cambiar una pluralidad de paquetes de medios mezclados en una pluralidad de paquetes de medios simple en donde: Cada uno de los paquetes de medios mezclados incluye: Each of the mixed media packages includes: A data for each of a plurality of data stream transmission, wherein the data is encrypted and has an arbitrary block size;Un dato para cada una de una pluralidad de transmisión de flujo de datos, en donde el dato es encriptado y tiene un tamaño de bloque arbitrario;A data header for each of the data and that includes a limit for the arbitrary block size;Un encabezado de datos para cada uno de los datos y que incluye un limite para el tamaño de bloque arbitrario;Cada paquete de medio simple incluye una transmisión de flujo de datos, que corresponde al uno de los paquetes de medios mezclados, e incluye: Each single media package includes a data stream transmission, which corresponds to one of the mixed media packages, and includes: A data corresponding to one of the data of one of the mixed media packages;Un dato que corresponde al uno de los datos del uno de los paquetes de medios mezclados;A data profile format header that corresponds to: Un encabezado de formato de perfil de dato que corresponde a: El un dato;y The one fact;and One of more data headers of a mixed media package, where the data profile format header has a limit that corresponds to: Uno de más encabezamientos de datos de un paquete de medios mezclado, en donde el encabezado de formato de perfil de datos tiene un limite que corresponde a: Los limites respectivos del uno o más encabezamientos de datos de el un paquete de medios mezclados;y The respective limits of the one or more data headers of the one mixed media package;and El un dato. The one fact.
36
38. A method comprising changing a plurality of mixed media packages into a plurality of simple media packages, wherein:38. Un método que comprende cambiar una pluralidad de paquetes de medios mezclados en una pluralidad de paquetes de medios simple, en donde: Cada uno de los paquetes de medios mezclados incluyen: Each of the mixed media packages includes: A data for each of a plurality of data stream transmission, wherein the data is encrypted and has a. arbitrary block size;Un dato para cada una de una pluralidad de transmisión de flujo de datos, en donde el dato ea encriptado y tiene un. tamaño de bloque arbitrario;A package header;and Un encabezado de paquete;y A data header for each of the data and includes a limit for the arbitrary block size;Un encabezado de dato para cada uno de los datos e incluye un limite para el tamaño de bloque arbitrario;Cada uno de los paquetes de medios simple corresponde al uno de los paquetes de medio mezclado e incluye: Each of the simple media packages corresponds to one of the mixed media packages and includes: A data corresponding to one of the data of one of the mixed media packages;Un dato que corresponde al uno de los datos del uno de los paquetes de medios mezclados;A package header that corresponds to one of the package headers of one of the mixed media packages;Un encabezado de paquete que corresponde al uno de los encabezamientos de paquete del uno de los paquetes de medios mezclados;A data profile format header that corresponds to: Un encabezado de formato de perfil de datos que corresponde a: El un dato;y The one fact;and One of more data headers of the one mixed media package;Uno de más encabezamientos de datos de el un paquete de medios mezclados;En donde el encabezado de formato de perfil de datos tiene un limite de datos que corresponde a: Where the data profile format header has a data limit that corresponds to: Los limites de datos respectivos del uno de los más encabezamientos de datos de el un paquete de medios mezclados;y The respective data limits of one of the most data headers of the one mixed media package;and El un dato. The one fact. ϊ ϊ I I
40
42 A method comprising changing a plurality of simple medium packages into a composite package, wherein:42 Un método que comprende cambiar una pluralidad de paquetes de medio simple en un paquete compuesto, en donde: Cada uno de lo paquetes de medio simple incluye: Each of the simple media packages includes: A data of a data stream transmission, wherein the data is taped and has an arbitrary block size;Un dato de una transmisión de flujo de datos, en donde el dato es encintado y tiene un tamaño de bloque arbitrario;A data header for the data and includes a limit for the arbitrary block size;Un encabezado de dato para el dato e incluye un limite para el tamaño de bloque arbitrario;El paquete compuesto corresponde a la pluralidad de paquetes de medio simple e incluye: The composite package corresponds to the plurality of simple medium packages and includes: One or more data of a similar data stream transmission corresponding to the respective data of the plurality of the simple medium packets;and Uno o más datos de una transmisión de flujo de datos similar que corresponde a los datos respectivo de la pluralidad de los paquetes de medio simple;y A data profile format header for each of said data in the composite package and corresponding to the data headers of the plurality of simple medium packets, Un encabezado de formato de perfil de dato para cada uno de dichos datos en el paquete compuesto y que corresponde a los encabezamientos de datos de la pluralidad de los paquetes de medio simple, En donde el encabezado de formato de perfil de datos tiene un limite de datos para uno de dichos respectivos datos en el paquete compuesto que identifica un orden de este en la pluralidad de los paquetes de medio simple. Where the data profile format header has a data limit for one of said respective data in the composite package that identifies an order of this in the plurality of simple medium packages.
47
49. A client computing device comprising a processor to execute logics configured to:49. Un dispositivo de cómputo de cliente que comprende un procesador para ejecutar lógicos configurados para: Enviar una solicitud para un archivo de medios que incluye una pluralidad de tipos de datos de medio;Send a request for a media file that includes a plurality of media data types;Receive streaming media in a plurality of RTP packets that correspond to the media file and includes: Recibir medios de transmisión de flujo en una pluralidad de paquetes RTP que corresponden al archivo de medios e incluye: Only one of said types of media data;Únicamente uno de dichos tipos de datos de medio;An RTP packet header;Un encabezado de paquete RTP;One of the most RTP data format headers that includes an RTP data limit;and Uno de los más encabezamientos de formato de datos RTP que incluye un limite de dato RTP;y Dato RTP para y que corresponde a cada uno de dichos encabezamientos de formato de datos RTP, en donde el dato RTP es encriptado y tiene un tamaño de bloque arbitrario que corresponde al limite de datos RTP, cada uno de dichos datos RTP siendo seleccionado de grupo gue consiste de: RTP data for and corresponding to each of said RTP data format headers, where the RTP data is encrypted and has an arbitrary block size corresponding to the RTP data limit, each of said RTP data being selected from the group It consists of: A plurality of portions of one of the media data types;Una pluralidad de porciones del uno de los tipos de datos de medio;A portion of one of the types of media data;and Una porción del uno de los tipos de dato de medio;y A fragment of the one portion of one of the media data types;Un fragmento de la una porción del uno de los tipos de datos de medio;For each of said RTP data in the RTP packets received: Para cada uno de dichos datos RTP en los paquetes RTP recibidos: Que incluye una pluralidad de porciones del uno de los tipos de datos de medio, ensamblar la pluralidad de porciones del uno de los tipos de datos de medio en un dato contiguo utilizando un límite de dato RTP del correspondiente encabezado de formato de dato RTP;That includes a plurality of portions of one of the media data types, assemble the plurality of portions of one of the media data types into an adjacent data using an RTP data limit of the corresponding RTP data format header;Que incluye una porción del uno de los tipos de datos de medio, ensamblarla a una porción del uno de los tipos de datos de medio en un dato contiguo utilizando el limite de datos RTP del encabezado de formato de datos RTP correspondiente;y That includes a portion of one of the media data types, assemble it to a portion of the one of the media data types in a contiguous data using the RTP data limit of the corresponding RTP data format header;and Que incluye un fragmento de una porción del uno de los tipos de datos de medio, ensamblar todos los fragmentos de la una porción del uno de los tipos de datos de medio en un dato contiguo utilizando cada uno de dichos limites de datos rtp de los encabezado de formato de datos RTP correspondiente;That includes a fragment of a portion of the one of the media data types, assemble all the fragments of the one portion of the one of the media data types into a contiguous data using each of said rtp data limits of the headers corresponding RTP data format;Assemble, in respective chronological order corresponding to plurality of the media data types of the media file, the contiguous data;and Ensamblar, en orden cronológico respectivo correspondiente a pluralidad d los tipos de datos de medio del archivo de medios, los datos contiguos;y Representar simultáneamente los datos contiguos cronológicamente ordenados de la pluralidad de los tipos de datos de medio del archivo de medios. Simultaneously represent the chronologically ordered contiguous data of the plurality of the media data types of the media file.
52
54 A client computing device comprising a processor to execute logics configured to:54. Un dispositivo de cómputo de cliente que comprende un procesador para ejecutar lógicos configurados para: Enviar una solicitud a un archivo de medios que incluye datos de audio y video;Send a request to a media file that includes audio and video data;Receive a plurality of RTP packets corresponding to a plurality of ASF packets for the media file, where: Recibir una pluralidad de paquetes RTP que corresponde a una pluralidad de paquetes ASF para el archivo de medios, en donde: Cada uno de dichos paquetes ASF incluye: Each of these ASF packages includes: An ASF package header;and Un encabezado'de paquete ASF;y One of more ASF data headers that each includes an ASF data limit for a corresponding ASF data, where the ASF data is encrypted with an arbitrary block size corresponding to the ASF data limit;Uno de más encabezamientos de datos ASF que incluye cada uno un limite de dato ASF para un correspondiente dato ASF, en donde el dato ASF es encriptado con un tamaño de bloque arbitrario que corresponde al limite de dato ASF;El dato ASF para y que corresponde a cada uno de dichos encabezamientos de datos ASF se seleccionan del grupo que consiste de: The ASF data for and corresponding to each of said ASF data headers are selected from the group consisting of: Algunos de los datos de audio incluyendo una muestra de audio o fragmento de este;y Some of the audio data including an audio sample or fragment thereof;and Alguno de los datos de video incluyendo una muestra de video o fragmento de este;Some of the video data including a video sample or fragment thereof;Cada uno de dichos paquetes RTP incluye: Each of these RTP packages includes: Alguno de los datos de audio o alguno de los datos de video;Some of the audio data or some of the video data;An RTP packet header that corresponds to at least one of the packet headers Un encabezado de paquete RTP que corresponde a al menos uno de los encabezamientos de paquetes ASF;ASF;One of more RTP data format headers corresponding to at least one of the ASF data headers, where each of said data format headers Uno de más encabezado de formato de dato RTP que corresponde a al menos uno de los encabezamientos de datos ASF, en donde cada uno de dichos encabezamientos de formato de datos RTP includes an RTP data limit that corresponds to at least one of the ASF data limits;and RTP incluye un limite de datos RTP que corresponde a al menos uno de los limites de datos ASF;y An RTP data for and corresponding to each of said RTP data format headers, each of said data being selected from the group consisting of: Un dato RTP para y que corresponde a cada uno de dichos encabezamientos de formato de dato RTP, cada uno de dichos datos siendo seleccionados del grupo que consiste de: A plurality of ASF data;Una pluralidad de los datos ASF;One of the ASF data;and Uno de los datos ASF;y A fragment of one of the ASF data;Un fragmento de uno de los datos ASF;For each of said RTP data in the RTP packets received: Para cada uno de dichos datos RTP en los paquetes RTP recibidos: Que incluye una pluralidad de los datos ASF, ensamblar la pluralidad de los datos ASF en un dato contiguo utilizando el limite de datos RTP del correspondiente encabezado de formato de datos RTP;That includes a plurality of ASF data, assemble the plurality of ASF data into an adjacent data using the RTP data limit of the corresponding RTP data format header;Que incluye uno de los datos ASF, ensamblar el uno de dichos datos ASF en un dato contiguo utilizando el limite de datos RTP del correspondiente encabezado de formato de datos That includes one of the ASF data, assemble the one of said ASF data into an adjacent data using the RTP data limit of the corresponding data format header RTP;and RTP;y Que incluye un fragmento del uno los datos ASF, ensamblar todos loa fragmentos del uno de los datos ASF en un dato contiguo utilizando cada uno de dichos limites de datos RTP de los correspondientes encabezamientos de formato de datos RTP;That includes a fragment of the ASF data one, assemble all the fragments of the one of the ASF data in an adjacent data using each of said RTP data limits of the corresponding RTP data format headers;Assemble, in respective chronological order that corresponds to the audio and video data of the media file, and the contiguous data;and Ensamblar, en orden cronológico respectivo que corresponde a los datos de audio y de video del archivo de medios, y los datos contiguos;y Representar simultáneamente los datos contiguos cronológicamente ordenados de ambos los datos de audio de los archivoe de medios y los datos de video de los archivos de medios. Simultaneously represent the chronologically ordered contiguous data of both the audio data of the media files and the video data of the media files. group selection consisting of: selección de grupo que consiste de: An evaluation of the transmission bandwidth of an underlying network from which the plurality of RTP packets are received;Una evaluación del ancho de banda de transmisión de una red subyacente de la cual la pluralidad de los paquetes RTP son recibidos;A physical characteristic of the underlying network;Una característica física de la red subyacente;An administrative policy regarding package size;Una política administrativa con respecto al tamaño del paquete;A size of the ASF packets corresponding to the plurality received from the RTP packets;and Un tamaño de los paquetes ASF que corresponde a la pluralidad recibida de ios paquetes RTP;y A combination of the above. Una combinación de los anteriores.

Independent claims24

159 paragraphs in 8 sections, as filed

RPT DATA FORMAT

TECHNICAL FIELD

The present invention relates to a real-time transport protocol (RTP) and more particularly to an RTF thread format for streaming media (eg audio-video) over a network, such as the Internet.

BACKGROUND OF THE INVENTION

The following discussion assumes that the reader is familiar with the IETF RFC 1889 RTP standard: A transport protocol for real-time applications and with the IETF RFC 1890-RTF profile standard for audio and video conferences with minimal control.

The real-time transport (RTP) protocol, as defined in RFC 1889, provides point-to-point network transport functions suitable for applications that transmit real-time data, such as audio, video or simulation data, over multicast or uridiffusion network services. These functions of

Transportation provides point-to-point delivery services for data with real-time features, such as interactive audio and video. Such services include identification of data types, sequential numbering, time stamp insertion and supply monitoring. The RTP supports data transfer to multiple destinations using multicast distribution if it is supplied by the underlying network.

The RFC 1889 standard does not provide any mechanism to ensure timely delivery or provide other guarantees of quality of service, but relies on lower layer services to do so. This does not guarantee or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers the packets in sequence. Sequence numbers included in the RTP allow the receiver to reconstruct the sender's packet sequence, but the sequence numbers could also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding the loa packages in sequence.

A typical RTF application involves data stream transmission, where the Visual Audio Data (AV) packets of the Advanced System Format (ASF) are sent in RTP packets over a network from a server to a client or egalitarian. ASF data and audio and video can be stored together in an ASF package. As such, the RTP package can contain both audio and video data.

The RTP, as defined in the RFC 1889 standard, lacks the flexibility to group multiple data together into a single RTP packet, and divide some data across multiple RTP packets. And the RFC 1889 standard defines a format in whose metadata each of the data can be supplied in an RTP packet. Another deficiency of the RFC 1889 standard is the lack of a mechanism for transmitting encrypted blocks or data through a network while maintaining a limit of each encrypted block so that the receiver can decrypt the encrypted blocks of data. It would be of the art to provide such flexibility as an improvement for the flow of. RTP data Consequently, there is a need for improved methods, computer readable media, data structure,

devices, and computing devices that can provide such flexibility.

BESUMEN

In one implementation, the audiovisual data (AV) packets of the Advances Sysitem Format (ASF) are repackaged in real-time transport protocol (RTF) packets and sent over a network from a server to a client through egalitarian network communications in response to a request to transmit AV data streams. AV data is encrypted to form encryption units. The repacking process includes packing the encryption units in the RTF packets each of which includes an RTP packet header, one or more data from a common data stream transmission, and an RTP data format (FF) header. For each data. The FF RTP header includes, for the corresponding encryption units, a limit for the data. The data in the RTP packet may be one or more encryption units or a fragment of an encryption unit. After the RTP packets are sent over a network, the encryption units contained in the received RTP packets are

reassembled. The reassembly process uses the data in the RTP packets and the respective limit in the respective PF RTP header. Reassembled encryption units can be decrypted for representation. Each PF RTP header can have attributes for its corresponding data that can be used to represent the data.

In a variation of the previous implementation, data in a format other than ASF is used to form RTP packets. In still a further variation of the previous implementation, RTP packets are formed in order to contain data that is not encrypted.

In yet another implementation, a thread format is provided for stream transmission of encrypted blocks of data protected with Windows6 Media Digital Rights

Management (WM DRM) over a network in RTP packets (for example transmission of protected content stream HM DRM). Each RTP packet contains header data to maintain the limits of the encryption block so that each encryption unit can be decrypted by its receiver. After decryption using the HM DRM protocol, the

Data stream transmission can be represented by the receiver.

BBBVB DESCRIPTION OF THE DRAWINGS

Figure 1 is an illustration of an example process, according to an embodiment of the invention, for the transmission of two (2) packets of the Advanced System Format (ASF) audiovisual data (AV) in four (4) packets. RTF, where audio data and video data are packed separately in the resulting RTP packets, and where the block limits for each of the data are preserved in such a way that the original AV specimens that were encrypted and packaged in two ASF packets can be reconstructed using an decryption mechanism.

Figure 2 is an illustration of an alternative example process, according to different embodiments of the invention, for the transmission of two (2) ASF video data packets in one (1) RTP packet, where an alternative process moves the ASF packet data into separate data in the RTP package, where the other alternative processes combine the data from the $ packages

ASF in a combined data in the RTF package, and where the block limits for each data are preserved in such a way that an original video sample that was encrypted and packed in the two ASF packages can be reconstructed by means of the decryption mechanism.

Figures 3a-3b are respective data structure designs, according to an embodiment of the present invention, for an RTP header and a corresponding data header.

Figure 14 in a block diagram, according to an embodiment of the present invention, of a network client / server system in which the flow transmission can be carried out by a server to a client or equally.

Figure 5 is a block diagram, according to an embodiment of the present invention, illustrating the communications between a server (or client) and a client, wherein the server (or client) serves the client a stream transmission. of requested audio-visual data that the client can represent.

Figure 6 is a block diagram, according to an embodiment of the present invention, of a networked computer that can be used to implement a server or a client.

DETAILED DESCRIPTION

The implementations described here define thread formats to provide simple and mixed data stream transmission, such as Windows® media data via the real-time transport protocol (RTF). The supply can be between the server and the client, as well as an egalitarian context (for example, a Windows® Messenger ™ visual audio conferencing software environment.

A thread format, in several implementations, improves the IETF RFC 1889 standard to provide greater flexibility for RTP delivery. The implementations provide a mechanism for streaming audio data stream in RTP packets that are separated from video data in RTP packets. The implementations also provide a thread format in which the metadata can be delivered with each of the data in you and

an RTP package, where metadatas provide rich information that is descriptive of the data. Still other implementations provide a mechanism for transmitting block flow of encrypted data through a network while maintaining a block limit for each of the encrypted data so that the receiver of these can decrypt the encrypted blocks of data. In another implementation, a thread format provides the delivery of data that is protected with Windows® Media Digital Rights Management (WM DRM, so that the delivery of these can be decrypted for representation.

Several implementations described herein repackage data in a series of media packets that are included in a system layer bit stream transmission. This data is packaged in RTP packet consistent with, still improving the RFC 1889 standard so that the transmission of layer layer bit stream is mapped to the RTP. In this mapping, each media package contains one or more data. In some system layer bitstream streams, there may be mixed media packets that have data such as audio data, video data, program data, TPEG data,

HTML data, MIDI data, etc. A mixed media package is a media package where two or more of your data belong to different media stream transmissions.

Several implementations apply to system layer bitstream streams where each media packet is a simple media packet. In a simple media package all data in the media package belongs to the same media stream transmission. Other implementations apply to system layer bitstream streams where each media packet always contains only one (1, data. In still further implementations, the size of the “data header in the media package is zero — which is likely if each media package contains only a single data, but could also happen when there is multiple data where the media package header Contains information about the size of each data.

Figure 1-2 describes example implementations in which the system layer bitstream transmission includes a series of Advanced System Format (ASF) packets that each have data there. These data are

packaged in RTP packets consistent with, still improving the RFC 1889 standard. As such, the system layer bitstream transmission includes a series of media packets that are ASF packets, and the data in each ASF packet is an ASF data . Although ASF packages are being used for illustration, the creation of RTP packages, in other implementations described here, is not limited to the use of ASF format data if you cannot instead use other formats in which the data to be Streams are stored. These other formats, as well as the ASF format, are generally described herein as system layer bit streams that include a plurality of media packets each having data there, where this data is mapped to RTP in various implementations.

The ASF 100 stream transmission audio-visual (AV) data is described in Figure 1. The ASF 100 stream transmission AV data, which includes audio data 102 and video data 104, has been packaged in an ASF A 106 package. and an ASF B 108 package. The ASF A 106 package includes a first ASF header) an ASF data header, audio data 102, a second ASF header, and a

video data fragment A of video data 104. The ASF B 108 package includes an ASF header, an ASF data header, and a video data fragment

B of the video data 104.

The AV data of the ASF 100 stream transmission as expressed in the ASF A 106 packet and the ASF B 108 packet, in one implementation, can be packaged a plurality of RTP packets. As seen in Figure 1, these include an RTP A 110 packet, an RTP packet 112 (1) up to the RTP packet 112 (N), and the RTP packet of 116. Each RTP packet according to RFC 1889 standard, It has an RTP packet header, some data, and an RTP data format (PF) header. As used herein, the RTP PF header is a data header in the RTP package. Only one (1) type of media is in the RTP package. In other words, the RTP packet does not contain mixed media data. In the implementation described in Figure 1, the video data A of the ASF A 106 packet is too large to fit within a simple RTP packet. As such, the video data A of the ASF A 106 packet is divided between the RTP packet 112 (1) to the RTP packet (N). The size of the RTP packet can be a function of a physical characteristic of a network

underlying on which the RTP packets must be transmitted, or an administrative policy regarding the size of the packet as it can be done by the underlying network administrator, or an evaluation of the transmission bandwidth of the underlying network.

After the RTP packaging described in Figure 1, the audio data 102 is included in the RTP package A 110 and the video data B of the ASF package B 108 is included in the RTP package 116. Each RTP PF header of each package RTP may contain information that relates to the separation of audio and video data into separate RTP packets respectively. Thus, the sample data in the A / V stream transmission 124 can be reconstructed from the audio data in the RTP packet A 110, in video data fragment A 1 to the video fragment video AN in the RTP packets 112 (1) to 112 (N), the video data B in the RTP packet of 116. Once the reconstruction of the sample data of the A / V stream transmission is completed, the data of the audio sample 120 and the data of the video sample A + B 122 there can be represented in a context of flow transmission Given the above, the

Figure 1 illustrates a thread format in which the

Smaller RTP packets are created from larger ASF packets, where the packaging puts different data stream data into separate packets each with its own RTP PF header. Figure 1 also illustrates an implementation of a thread format in which the limits of the block for each data are preserved in such a way that the original audio and video samples that were encrypted and packed in ASF packets can be reconstructed using a mechanism of decryption that is developed even in RTP packets.

The AV data of the ASF 200 stream transmission is described in Figure 2. The AV data of the ASF 200 stream transmission that includes video data 202, has been packaged in an ASF A 208 package and in an ASF B 210 package The ASF A 208 package includes an ASF header, an ASF data header and A 204 video data. The ASF B 210 package includes an ASF header, an ASF data header, and one B 206 video data. Figure 2 shows two (2) alternatives to package ASF 200 stream transmission AV data in RTP packets consistent with, still improving, the RFC 1889 standard.

In the first alternative, following arrow 250, video data A 204 and video data B 206 are packaged in a simple RTP packet alternative A 212 having an RTP header. Each of the A 204 video data and the B 206 video data is preceded by an RTP PF header. The RTP A 212 packet alternative according to the RFC 1889 standard has an RTP header, multiple data, and respective RTP PF headers.

In the second alternative, also following arrow 250, the video data A 204 and the video data B 206, of the respective ASF packets, are packaged in an alternative RTP packet B 214 having an RTP header. The video data A 204 and the video data B 206 are contiguously assembled as the data in the RTP B 214 packet alternative. The data is preceded by an RTP PF header. The RTP B 214 packet alternative, according to the RFC 1889 standard, has an RTP header, some data, and an RTP header

Pf.

After the RTP packaging described in Figure 2, video data A and B (204, 206) are included in any RTP packet alternative A 212 or in the

RTP B 214 packet alternative. Each RTP PF header may contain information that relates to the corresponding data. Each of the alternative RTP packets 212, 214 contain sufficient data to reconstruct the ASF A 208 packages and the ASF B 210 packages in order to obtain data there from vide A and B (204, 206). Once the reconstruction is complete, the video sample data 222 can be represented in a stream transmission context. Given the above, the

Figure 2 illustrates an RTP thread format in which the larger RTP packets are created from small ASF packets, and where the block limits for each data are preserved in such a way that the original video samples that were encrypted and packaged in both ASF packages can be rebuilt using an decryption mechanism that is developed in the packages

RTP

Figure 3a describes the data structure design for the fields in an RTP header. The RTP header is more fully described in the RFC 1889 standard. The time stamp insertion field in the header

RTP must be adjusted to the presentation time of the sample contained in the RTP package. In a

implementation, the clock frequency ea 1 kHz unless specified differently through independent means of RTP.

The 8th bit of the RTP header start is interpreted as a bit field marker (M). Bit M is set to zero, but will be set to one (1) as long as the corresponding RTP packet has data that is not a fragment of a sample, contains the final fragment of a sample, that is one of a plurality of samples complete in the RTP package. The M bit can be used by a receiver to detect the receipt of a complete sample to decode and present. Thus, the M bit in the RTP header can be used to mark significant events in a packet stream transmission (eg video sample frame limits).

Figure 3b describes an implementation of an RTP data format (PF) header or a data header. The RTP PF header has a fixed length portion of sixteen bits (16) followed by a portion of variable length. The RTP PF header fields described in Figure 3b include an 8-bit string indicated by the SGLRTDXZ character fields, a length / equivalence field, a relative time stamp insertion field, a decompression time field, a duration field, and a data extension length field (PE) and a corresponding PE data field, each of which is explained below.

The S field is one (1) bit in length and is set to one (1) if the corresponding data (for example, sample, fragment of a sample, or combination of samples) is a key sample, that is, an intracoded sample or I-Box. Otherwise this is set to zero. The S bit in all preceding fragments of PTP RTP header of the same sample must be set to the same value.

The G field is one (1) bit long and is used to group subsamples into a corresponding data that forms a simple sample. Windows® Media Digital Rights Management (HM DRM) encrypts content based on the limits of ASF data. In order to allow this content to be properly decrypted, the limits of the subsamples in the data can be communicated to the client that will receive the data. By

For example, an encryption unit can be packaged so that it is broken into a plurality of transmission units (for example located within separate packets) to be transmitted. Before the plurality of transmission units is broken it can be decrypted in<sup>1</sup>a receiving client they have to be reassembled in the original encrypted form. As in other methodologies and decryption mechanisms, the client can use the limits to properly reconstruct the encrypted units of encryption in preparation for decryption of the encrypted content. As such, each of the ASF data must be preceded by this RTP PF header.

The field bit G must be set to zero (0) to indicate that an encrypted unit has been fragmented. If the ASF is being used, the encryption unit will be an ASF data and the bit is set to zero (0) on all fragmented ASF data, except the last ASF data. In this case, if the sample has been fragmented or not does not matter. If the ASF is not being used, the encryption unit is an average sample. In which case the G bit is set to zero (0) in all fragment media samples except the last sample. As in this

In the latter case, the concern about whether ASF data has been fragmented or not is not applicable, because the ASF is not used.

The L field is one (1) bit in length and is set to one (1) if the length / equivalence field contains a length. Otherwise this is set to zero (0) and the length / equivalence field contains an equivalence. If the L bit must be set to one (1) in all RTP PF headers that precede a complete sample (not fragmented) in the corresponding data and must be set to zero in the RTP PF headers that precede a data containing a sample fragmented.

The R field is one (1) bit in length and is set to one (1) if the RTP PF header contains a relative time stamp insert. Otherwise this is set to zero. The R bit in all headers that precede the fragments of the same sample must be set to the same value.

The T field is one (1) bit in length and is set to one (1) if the RTP PF header contains a decompression time. Otherwise this is set to zero. He

T bit in all RTP PF headers that precede a data that contains a fragment of the same sample must be set to the same value.

Field D is one (1) bit in length and is set to one (1) if the RTP PF header contains a sample duration. Otherwise this ae adjusts to zero. The D bit in all RTP PF headers that precede a data that contains a fragment of the same sample must be set to the same value.

The X field is one (1) bit long and is for optional and unspecified use. A transmitter of an RTP packet must set this bit to zero and a receiver from it can ignore this bit.

The Z field is one (1) bit in length and is set to one (1) if the RTP PF header contains data extension data (PE) that can be metadata relative to the corresponding data. Otherwise the Z field is set to zero. The Z field bit could be zero for all RTP PF headers whose M bit is zero, but must be set for all RTP PF headers whose M bit

they conform to one (1) if the corresponding data have PE data associated with it.

The length / displacement is twenty-four (24) bits in length and quantifies the length or displacement of a single sample that has been fragmented over multiple RTP packets. The L bit is set to zero and the length / offset field contains the byte offset of the first byte of this fragment from the start of the corresponding data (for example the sample fragment of this). If one or more complete samples are contained in the RTP packet, the L bit is set to one (1) in each RTP PF header, and the sample length / offset field contains the sample length (including the RTP PF header .

The relative time stamp insertion field is thirty-two (32) bits in length and is present only if the R bit is set to one (1). This contains a relative time stamp insert for the corresponding sample with respect to the relative mark insert in the corresponding RTP header. The time scale used is the same as that used for inserting the time stamp in the RTP header.

The relative time stamp insertion field is specified as a 32-bit designated number to allow negative shifts from the time stamp insertion of the * RTP header. When the relative time stamp insertion field is absent, the default relative time stamp insertion of zero can be used.

The decompression time is thirty-two (32) bits in length and is present only if the T bit is set to one (“1). This contains the decompression time relative to the insertion of time in the RTP header. The time scale used is the same as that used for inserting the time stamp in the RTP header. The field is specified as a 32-bit designated number to allow negative offsets from time stamp insertion in the RTP header.

The duration field is thirty-two (32) bits in length and is present only if bit D is set to one (1). This contains the corresponding sample duration. The time scale used is the same as that used for brand insertion

temporary in the RTP header. The duration field, in all preceding fragments of the PTP RTP header of the same sample, must be set to the same value. When this field is absent, the default duration is implicitly or explicitly obtained from the sample data. If these are not practical, the defect is the difference between extra insertion of the time stamp of the sample and the following insertion of the time mark of the sample.

The length field of the data extension data (PE) is sixteen (16) bits in length and is present only if the Z bit is set to one (1). This contains a number of bytes of the pE data contained after the fixed part of the RTP PF header. PE data are variable in length and contain one or more descriptive attributes of the corresponding data that precedes it. The PE data length field immediately follow the fixed part of the data header and it will be a number of bytes containing the data

PE current. The structure of the PE data communicates between the client and the service (or equally), such as by way of a description

SDP In an implementation for WM protected content

DRM, there could be at least 4 bytes of DUE data representing the WM DRM data ID associated with each sample.

Although Figures 3a-3b show several fields in several orders for an RTP header and an RTP PF header, not all fields are required and their order can be rearranged. In some implementations, the required fields and the order for these may be consistent with, still extended, the flexibility of the RFC standard

1889 Although A5F packets are being used for illustration in Figure 3a-3b, the creation of RTP packets, RTP PF headers and data accordingly, in other implementations described herein are not limited to the use of ASF format data if not that they could instead use other formats in which the data that is to be transmitted in flow is stored.

General Network Structure

Figure 4 shows a client / server network system 400 and an environment according to the invention. In general, system 400 includes one or more servers

network multimedia (m) 402 and one or more network clients (k) 404. Computers communicate with each other over the data communications network, in which Figure 4 includes a wired / wireless network 406. The Data communications network 406 could also influence Internet or local area networks and private wide area networks. Servers 402 and clients 404 communicate with each other via a wide variety of known protocols, such as the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP).

The 402/404 multimedia servers / clients have access to the content of the streaming media in the form of different streaming media streams. These media stream transmissions can be individual media stream streams (eg audio, video, graphic, simulation, etc.), or alternatively composite stream streams that include multiple such as individual stream streams. Some media stream transmissions could be stored as 408 files in the database (for example ASF file) or other file storage system, although other transmissions of

Media stream 410 could be supplied to multimedia server 402 or client 404 on a live basis from other data source components through dedicated communication channels or through the Internet itself.

Media data stream transmission received from servers 402 or clients 404 are represented on client 404 as a multimedia presentation that may include streaming media stream from one or more servers / clients.

402/404. These different media stream transmissions may include one or more of the same or different types of media stream transmissions. For example, a multimedia presentation may include two video stream streams, an audio stream stream, and a graphic stream stream. A user interface (Ul) on the client 404 may allow users various controls, such as allowing a user to increase or decrease the speed at which the presentation of media is reduced.

Computer Environment. Example

In the following discussion, the invention will be described in the general context of computer executable instructions, such as program modules, being executed by one or more conventional personal computers. Generally, the program modules include routine programs, objects, components, data structures, etc. develop particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention could be practiced with other computer system configurations including manual devices, multiprocessor systems, consumer electronic elements based on microprocessor or programmable, network PCD microcomputers, giant computers, and Similar. In a distributed computer environment, program modules can be located on both local and remote memory storage devices. Alternatively, the invention can be implemented in a hardware or in a combination of hardware, software and / or Firmware. For example, one or more application specific integrated circuits (ASICs) could be programmed to carry out the invention.

YES

As shown in Figure 4, the network system according to the invention includes network server (s) and client 402, 404 from which a plurality of media stream transmissions are available. In some cases, media stream transmissions are in fact stored by the server (s) and / or the client 402, 404. In other cases, the server or servers and / or the clients 402, 404 can obtain the transmission of media streams from other sources or network devices in general, the network clients 402 respond to the user input to request media stream streams that correspond to the selected multimedia content. In response to a request for a media stream transmission that corresponds to the multimedia content, the server (s) and / or clients 402, 404 of the media stream transmissions requested to the requesting network client 404 in accordance with the format of RTP thread The 404 client decrypts the data in the respective RTP packets and represents the encrypted data stream transmission to produce the requested multimedia content.

Figure 5 illustrates the entry and storage of A / V stream transmission data on a server 402 or

on a 404 client (for example a counterpart). Figure 5 also illustrates communications between server and client (402-404) or egalitarian (404-404) according to various implementations. By way of review, the server or client 402, 404 receives inputs of an A / v stream transmission data from an input device

530 The server or client 402, 404 encodes the input using an encoder or codeo. Coding can, but not necessarily, be developed on ASF format data. If the ASF format data is used, Lugo coding is developed from the ASF packets that each includes an ASF header, and an ASF data header and some AV (audio and / or video) data. The encoding may include encryption, such as where WM DRM is used. The ASF packages are stored by the server / client 402, 404 to serve future requests by it.

Subsequently, the client requests the corresponding transmission of AV data flow from the server / client. The server / client retrieves and transmits to the client the corresponding AV stream transmission that the server / client has previously stored. After receipt, the customer decodes the stream transmission of

AV data and reconstructs and decrypts the transmission samples of separate AV data stream encrypted using limits reported in the corresponding RTP PF headers. The customer can then develop the presentation of the AV data transmitted in flow.

The data flow is seen in Figure 5 between blocks 504-530. In block 504, an input device 502 provides a server / client 402/404 with inputs that include A / V stream transmission data. for example, the A / V stream transmission data could be supplied to the server / client 402/404 on a live basis by means of the input device

502 through dedicated communication channels or through the Internet. The data of the A / V stream transmission is supplied to an encoder in block 504 to locate the data in ASF packets. In block 506, optional WM DRM encryption and packets are used

ASFs are stored on server / client 402/404. A result of WM DRM encryption and packaging may be that an encryption unit is divided into a plurality of separate packets. Before the divided plurality of transmission unit can be decrypted in a receiving client they have to be reassembled in the client in the original encryption units.

As such the limits of the divided transmission units are stored in the data headings.

ASF of block 506.

In block 508, client 404 makes a request for the transmission of A / V data stream that is transmitted to server / client 402/404 as seen in arrow 510 in Figure 5. Block 512, server / Client 402/404 receives the request. The corresponding ASF packets containing the requested A / V data stream transmission are retrieved. In block 514, the audio and video data in the ASF packets are logically separated so that they can be packed separately in RTP packets. The limits for each logically separated audio and video data are identified.

A bandwidth of the network over which RTP packets must be transmitted is determined. This determination is used to derive a default RTP packet size. When the size of the ASF package is smaller than the size of the RTP package

By default, similar class data can be combined in a simple RTP package. When the size of the ASF package is larger than the size of the default RTP package, the ASF data can be fragmented to locate data in a simple RTP package. The limits for each RTP data are determined using the corresponding audio and video data logically separated from the ASF packets.

In step 516, the RTP PF header and the respective data are assembled for each of the RTP packets. At most, a plurality of RTP packets have been formed which represent a plurality of ASF packets, where the ASF packets contain the A / V data stream transmission that was requested by a client 404. The RTP packets are transmitted in stream to represent client 404 of server / client 402/404 via a transmission function in block 51Θ.

An arrow 520 in Figure 5 shows the transmission of RTP packets from server / client 402/404 to client 404. In block 522, client 404 receives the RTP packets. In block 524, an RTP decoder on client 404 decodes each of the RTP packets received,

including the RTP header, and the RTP PF header. In block 526, a process develops defragmentation and reconstruction of ASF packets that contain the requested A / V stream transmission. Defragmentation and reconstruction use the limits established in the RTP PF header for each of the corresponding data containing, for example, a sample or fragment thereof.

In block 528, the reconstructed ASF packets are decrypted to represent it in block 530. The RTP PF header in an RTP packet may contain data extension data (EP) that are descriptive of the corresponding data. The PE data can thus provide metadata that can be used during the representation of the corresponding RTP packet data in block 530. Blocks 522-530 are repeated for each of the RTP packets that are received in the 404 client, thus managing to represent the flow transmission of the A / V data of the server / client 402/404.

Figure 6 shows a general example of a 642 computer that can be used in accordance with the invention. He

Computer 642 is shown as an example of a computer that can perform the functions of either client 402 or servers 404 in Figures 4-5. Computer 642 includes one or more processes or processing units 644, a system memory 646, a system bus 648 that couples several system components including system memory 646 to processors 644.

Bus 648 represents one or more of any of several types of bus structures, including a memory bus or a memory controller, a peripheral bus, an accelerated graphics port, a processor or a local bus that uses any of A variety of bus architecture. The system memory includes a read-only memory (ROM) 650 and a random access memory (RAM) 652. A cache 675 has levels LI, L2, and L3 can be included in RAM 652. A basic input / output system (BIOS) 654, which contains the basic routines that help transfer information between the elements inside the computer

642, as during startup is stored in ROM

650. The 642 computer also includes a 656 hard drive for reading and writing to a hard drive (not

shown) a magnetic disk drive 658 for reading and writing to a removable magnetic disk 660, and an optical disk drive 662 for reading or writing to a removable optical disk 664 such as a CD-ROM or other optical media.

Either of the hard disk (not shown), the magnetic disk drive 658, the optical disk drive 662, or the removable optical disk 664, may be an information medium having information recorded therein. The information medium has a data area to record the data of the flow transmission using flow transmission packets each of which includes a packet area containing one or more data packets. By way of example, each data packet is encoded and decoded by an application program codec 672 that is executed in the processing unit 644. As such, the encoder distributes the data of the stream transmission to the packet areas of data in the stream transmission packets such that distributed stream transmission data is recorded in the areas of data packets that use an encoding algorithm. Alternatively, the coding and decoding of the

Data packets can be developed as a function of the 670 operating system that runs on the 644 processing unit.

The hard disk drive 656, the magnetic disk drive 658 and the optical disk drive 662 are connected to the system bus 648 via a SCSI interface 666 or some other appropriate interface. The units and their associated computer readable media provide nonvolatile storage of the computer readable instructions, data structures, program modules and other data for the 642 computer. Although the example environment described here employs a hard disk, a removable magnetic disk 660 and a removable optical disk 664, it should be appreciated for those skilled in the art that other types of computer-readable media that can store data that are accessible c

by a computer, such as a magnetic cartridge, flash memory cards, digital video disc, random access memories (RAM) read-only memory (ROM), and the like, can also be used in the example operating environments.

qt>

A number of program modules can be stored on the hard disk, the magnetic disk 660, the optical disk 664, the ROM 650, a RAM 652, including an operating system 670, one or more application programs 672 (which may include the codec), other program modules 674, and program data 676. A user can enter commands and information into computer 642 through input devices such as a keyboard 678 or a pointing device 680. Other input devices (not shown) may include a microphone, joystick, a gaming device, a satellite disk, a browser, or the like. These and other input devices are connected to the processing unit 644 through an interface 682 that is coupled to the system bus. A monitor 684 or other type of display device is also connected to the system bus 648 via an interface, such as a video adapter 686. In addition r

of the monitor, personal computers typically include other peripheral output devices (not shown) such as speakers and printers.

Computer 642 operates in a network environment that uses logical connections to one or more remote computers, such as remote computer 688. Remote computer 688

it can be another personal computer, a server, a router, a debed PC, a homologous device or another common network node, and typically influences many or all of the elements described above in relation to the computer 642, although only one device has been illustrated. Memory storage 690 in Figure 6. The logical connections described in Figure 6. The logical connections described in Figure 6 include a local area network (LAN) 692 of a wide area network (WAN) 694. Such network environments are common places in offices, corporate wide computer networks, intranets, and the internet. In the described embodiment of the invention, the remote computer 688 executes an Internet network scanning program such as the Internet Explorer® network browser developed and distributed by Microsoft Corporation of Redmond, Washington.

When used in a LAN network environment, computer 642 is connected to local network 692 through a network interface or adapter 696. When used in a WAN network environment computer 642 typically includes a 698 modem or other means for establishing communications over a wide area 694 network, such as the Internet. The modem 698, which can be internal or external, is connected to the system bus 648 via a serial port interface 668. In a network environment, the program modes described in relation to personal computer 642, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown in examples and other means of establishing a communication link between computers can be used.

In general, the data processors of the computer 642 are programmed by means of instructions stored at different times in various readable storage media of the computer. Programs and operating systems are typically distributed, for example, floppy discs or CD-ROMs. From there, they are installed or placed in a memory

Or secondary of a computer. In execution, they are at least partially loaded into the primary electronic memory of the computer. The invention described herein includes these and several other types of computer-readable storage media when such means contain program instructions for implementing the steps described below in conjunction with a micro ¢ 3 processor or other data processors. The invention also includes the computer itself when programmed according to the methods and techniques described below. Additionally, certain computer subcomponents can be programmed to perform the functions and stages described above. The inventions include such subcomponents when they are programmed as described. In addition, the invention described herein includes data structures, described below, as modalities in various types of memory media.

For purposes of illustration, programs and other executable program components such as the operating system are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various times in different computer storage components, and are executed by the processor or computer data processors.

conclusion

The implementations described here define a thread format that can be used in the provision of multimedia data between the server and the client.

equally via RTP. The thread format allows greater flexibility than the standards and IETF RFC 1889 commonly adopted for the RTP supply. Thread format implementations provide encrypted data stream transmission, provide a mechanism to deliver metadata per sample via RTP, and provide data stream transmission that is protected with WM DRM.

Although the invention has been described in specific language to structural features and / or methodological acts, it should be understood that the invention defined in the final claims is not necessarily limited to the specific features or acts described. Instead, specific features and acts are described as exemplary ways to implement the claimed invention.

Contents8

4 priority claims, no other members on record

This recordMember, by publication datePriority claim

Priority claims4

Priority claims
Document	Office	Kind	Date
61285103	United States of America	A	2003-07-03
61285103	United States of America	A	2003-07-03
10612851	–	–	–
US20030612851	–	–	–