MXPA04006449A - Formato de carga de protocolo de transporte en tiempo real (rtp). - Google Patents

Formato de carga de protocolo de transporte en tiempo real (rtp).

Info

Publication number
MXPA04006449A
MXPA04006449A MXPA04006449A MXPA04006449A MXPA04006449A MX PA04006449 A MXPA04006449 A MX PA04006449A MX PA04006449 A MXPA04006449 A MX PA04006449A MX PA04006449 A MXPA04006449 A MX PA04006449A MX PA04006449 A MXPA04006449 A MX PA04006449A
Authority
MX
Mexico
Prior art keywords
load
rtp
media
data
header
Prior art date
Application number
MXPA04006449A
Other languages
English (en)
Inventor
E Klements Anders
Original Assignee
Microsoft Corp
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 Microsoft Corp filed Critical Microsoft Corp
Publication of MXPA04006449A publication Critical patent/MXPA04006449A/es

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R1/00—Details of transducers, loudspeakers or microphones
    • H04R1/20—Arrangements for obtaining desired frequency or directional characteristics
    • H04R1/32—Arrangements for obtaining desired frequency or directional characteristics for obtaining desired directional characteristic only
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0457—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply dynamic encryption, e.g. stream encryption
    • 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/1101—Session protocols
    • 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
    • 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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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/70—Media network packetisation
    • 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/03—Protocol definition or specification 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2347—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving video stream encryption
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • 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/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/4143—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a Personal Computer [PC]
    • 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/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • H04N21/42623—Internal components of the client ; Characteristics thereof for processing the incoming bitstream involving specific decryption arrangements
    • 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/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • 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/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4788—Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
    • 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R1/00—Details of transducers, loudspeakers or microphones
    • H04R1/02—Casings; Cabinets ; Supports therefor; Mountings therein
    • 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R2201/00—Details of transducers, loudspeakers or microphones covered by H04R1/00 but not provided for in any of its subgroups
    • H04R2201/02—Details casings, cabinets or mounting therein for transducers covered by H04R1/02 but not provided for in any of its subgroups

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Acoustics & Sound (AREA)
  • Otolaryngology (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Television Systems (AREA)
  • Communication Control (AREA)

Abstract

Una corriente de datos es cifrada para formar unidades de cifrado que son colocadas en paquetes RTP. Cada paquete RTP incluye un encabezado de paquete RTP, una o mas cargas de una corriente de datos comun y un encabezado de formato de carga RTP para cada carga y que incluye, para las unidades de cifrado correspondientes, un limite para la carga. La carga puede ser una o mas de las unidades de cifrado o un fragmento de una de las unidades de cifrado. Las unidades de cifrado se vuelven a ensamblar usando las cargas en los paquetes RTP y el limite respectivo en el encabezado de formato de carga RTP respectivo. Las unidades de cifrado que se han vuelto a ensamblar son descifradas para presentacion. Cada encabezado de formato de carga RTP puede tener atributos para la carga correspondiente que se pueden usar para presentar la carga. Los paquetes RTP se pueden enviar de servidor a cliente o de igual a igual.

Description

FORMATO DE CARGA DE PROTOCOLO DE TRANSPORTE EN TIEMPO REAL (RTP) Campo de la Invención La presente invención se refiere a Protocolo de Transporte en Tiempo Real (RTP) y más en particular a un formato de cable RTP para transmitir medios (por ejemplo, audio-video) en una red, tal como la Internet. Antecedentes de la Invención La siguiente discusión supone que el elector está familiarizado con la norma 1889 IETF RFC - RTP: Un protocolo de transporte para aplicaciones en tiempo real y con la norma 1890 IETF RFC - Perfil RTP para conferencias de audio y video con un control mínimo. El protocolo de transporte en tiempo real (RTP), como se define en la norma 1889 RFC, provee funciones de transporte de red de extremo a extremo adecuadas para aplicaciones que transmiten datos en tiempo real, tales como datos de audio, video o simulación sobre servicios de red multidifusión o unidifusión. Estas funciones de transporte proveen servicios de entrega de extremo a extremo para datos con características en tiempo real, tales como audio y video interactivos. Tales servicios incluyen identificación del tipo de carga, numeración de secuencia, impresión de la fecha y hora y monitoreo de la entrega. RTP soporta transferencia de datos a múltiples destinos con el uso de distribución multidifusión si es provista por la red subyacente.
La norma 1889 RFC no provee ningún mecanismo para asegurar la entrega oportuna ni provee otras garantías de calidad de servicio, sino que depende de servicios de capa inferior para hacerlo. No garantiza la entrega ni previene la entrega en desorden, así como tampoco supone que la red subyacente es confiable y entrega paquetes en secuencia. Los números de secuencia incluidos en RTP permiten que el receptor vuelva a construir la secuencia de paquete del emisor, pero se pudieran usar también números de secuencia para determinar la ubicación apropiada de un paquete, por ejemplo, en decodificación de video, sin decodificar necesariamente paquetes en secuencia. Una aplicación típica de RTP implica transmitir datos, donde paquetes de datos audiovisuales (AV) en Formato de Sistemas Avanzados (ASF) son enviados en paquetes RTP sobre una red de un servidor a un cliente o de igual a igual. Los datos de audio y video ASF se pueden almacenar juntos en un paquete ASF. Como tal, un paquete RTP puede contener tanto datos de audio como datos de video. RTP, como se define en la norma 1889 RFC, carece de flexibilidad para agrupar múltiples cargas juntas en un solo paquete RTP y dividir una carga en múltiples paquetes RTP. La norma 1889 RFC tampoco define un formato en el cual se pueden entregar metadatos con cada carga en un paquete RTP. Otra deficiencia de la norma 1889 RFC es la falta de un mecanismo para transmitir bloques cifrados de datos en toda una red mientras se mantiene un límite de bloque de cada bloque cifrado de manera tal que el receptor del mismo pueda descifrar los bloques cifrados de datos. Sería un avance en la técnica proveer dicha flexibilidad como una mejora a la transmisión RTP. Por consiguiente, existe la necesidad de métodos mejorados, medio legible por computadora, estructuras de datos, aparato y dispositivos de cómputo que puedan proveer dicha flexibilidad. Sumario de la Invención En una implementación, paquetes de datos audiovisuales (AV) en Formato de Sistemas Avanzados (ASF) se vuelven a colocar en paquetes de Protocolo de Transporte en Tiempo Real (RTP) y se envían sobre una red de un servidor a cliente o por medio de comunicaciones de red de igual a igual en respuesta a una solicitud para transmitir los datos AV. Los datos AV son cifrados para formar unidades de cifrado. El proceso de volver a poner en paquetes incluye poner en paquetes las unidades de cifrado en los paquetes RTP, cada uno de los cuales incluye un encabezado de paquete RTP, una o más cargas de una corriente de datos comunes y un encabezado de formato de carga (PF) RTP para cada carga. El encabezado PF RTP incluye, para las unidades de cifrado correspondientes, un límite para la carga. La carga en el paquete RTP puede ser una o más unidades de cifrado o un fragmento de una unidad de cifrado. Después de que los paquetes RTP son enviados sobre una red, las unidades de cifrado contenidas en los paquetes RTP recibidos se vuelven a ensamblar.
El proceso de volver a ensamblar usa las cargas en los paquetes RTP y el límite respectivo en el encabezado PF RTP respectivo. Las unidades de cifrado reensambladas se pueden descifrar para presentación. Cada encabezado PF RTP puede tener atributos para su carga correspondiente que se pueden usar para presentar la carga. En una variación de la implementación anterior, datos en un formato diferente de ASF se usan para formar los paquetes RTP. En otra variación de la implementación anterior, los paquetes RTP se forman para contener cargas que no están cifradas. En otra implementación, se provee un formato de cable para transmitir bloques cifrados de datos protegidos con Administración de Derechos Digitales de Windows® Media (WM DRM) en toda una red en paquetes RTP (por ejemplo, transmitir contenido protegido con WM DRM). Cada paquete RTP contiene datos de encabezado para mantener límites de bloque de cifrado de manera que cada unidad de cifrado pueda ser descifrada por el receptor de la misma. Al descifrar usando el protocolo WM DRM, los datos por flujo pueden ser presentados por el receptor. Breve Descripción de los Dibujos La figura 1 es una ilustración de un proceso ejemplar, de acuerdo con una modalidad de la invención, para la transformación de dos (2) paquetes de datos audiovisuales (AV) en Formato de Sistemas Avanzados (ASF) en cuatro (4) paquetes RTP, donde los datos de audio y los datos de video son colocados en paquetes por separado en los paquetes RTP resultantes y donde límites de bloque para cada carga se mantienen de manera tal que muestras AV originales que fueron cifradas y colocadas en los dos paquetes ASF se puedan reconstruir por medio de un mecanismo de desciframiento. La figura 2 es una ilustración de procesos ejemplares alternativos, de acuerdo con diferentes modalidades de la invención, para la transformación de dos (2) paquetes de datos de video ASF en un (1) paquete RTP, donde un proceso alternativo mueve las cargas de los paquetes ASF en cargas separadas en el paquete RTP, donde el otro proceso alternativo combina las cargas de los paquetes ASF en una carga combinada en el paquete RTP y donde límites de bloque para cada carga se mantienen de manera tal que una muestra de video original que fue cifrada y colocada en los dos paquetes ASF se pueda reconstruir por medio de un mecanismo de desciframiento. Las figuras 3a-3b son diagramas de estructuras de datos respectivos, de acuerdo con una modalidad de la presente invención, para un encabezado RTP y un encabezado de carga correspondiente. La figura 4 es un diagrama de bloques, de acuerdo con una modalidad de la presente invención, de un sistema de cliente/servidor en red en el cual la transmisión se puede realizar mediante servidor a cliente o de igual a igual. La figura 5 es un diagrama de bloques, de acuerdo con una modalidad de la presente invención, que ¡lustra comunicaciones entre un servidor (o cliente) y un cliente, donde el servidor (o cliente) sirve al cliente una corriente de datos audiovisuales solicitada que el cliente puede presentar. La figura 6 es un diagrama de bloques, de acuerdo con una modalidad de la presente invención, de una computadora en red que se puede usar para implementar ya sea un servidor o un cliente. Descripción Detallada de la Invención Las implementaciones descritas en la presente definen formatos de cable para entrega de corrientes de datos sencillas y mixtas, tales como datos de Windows® media vía Protocolo de Transporte en Tiempo Real (RTP). La entrega puede ser entre servidor y cliente, así como en un contexto de igual a igual (por 1 ejemplo, un ambiente de software de conferencia audiovisual de Windows® Messenger™). Un formato de cable, en diversas implementaciones, mejora la norma 1889 IETF RFC para proporcionar mayor flexibilidad para entrega RTP. Las implementaciones proveen un mecanismo para transmitir datos de audio en paquetes RTP que están separados de datos de video en paquetes RTP. Asimismo, las implementaciones proporcionan un formato de cable en el cual se pueden entregar metadatos con cada carga en un paquete RTP, donde los. metadatos proveen información abundante que describe la carga. Otras implementaciones proveen un mecanismo para transmitir bloques cifrados de datos en toda una red mientras mantiene un límite de bloque de cada bloque cifrado de manera tal que el receptor del mismo pueda descifrar los bloques cifrados de datos. En otra implementación, un formato de cable provee entrega de datos que están protegidos con Administración de Derechos Digitales de Windows® Media (WM DRM) de manera tal que la entrega de los mismos se pueda descifrar para presentación. Diversas implementaciones descritas en la presente vuelven a empaquetar datos en una serie de paquetes de medios que están incluidos en una corriente de bits de capa de sistema. Estos datos son colocados en paquetes RTP que concuerdan con la norma 1889 RFC, pero la mejoran, de manera que la corriente de bits de capa de sistema es correlacionada con RTP. En esta correlación, cada paquete de medios contiene una o más cargas. En algunas corrientes de bits de capa de sistema, puede haber paquetes de medios mixtos que tienen datos tales como datos de audio, datos de video, datos de programa, datos JPEG, datos HTML, datos MIDI, etc. Un paquete de medios mixtos es un paquete de medios donde dos o más de sus cargas pertenecen a diferentes corrientes de medios. Diversas implementaciones aplican a corrientes de bits de capa de sistema donde cada paquete de medios es un solo paquete de medios. En un solo paquete de medios, todas las cargas en el paquete de medios pertenecen a la misma corriente de medios. Otras implementaciones aplican a corrientes de bits de capa de sistema donde cada paquete de medios siempre contiene sólo una (1) carga. En otras implementaciones, el tamaño del "encabezado de carga" en el paquete de medios es cero - lo cual es probable si cada paquete de medios contiene únicamente una sola carga, pero podría pasar también cuando existen múltiples cargas donde el encabezado de paquete de medios contiene información acerca del tamaño de cada carga. Las figuras 1-2 ilustran implementaciones ejemplares en las cuales las corrientes de bits de capa de sistema incluyen una serie de paquetes de Formato de Sistemas Avanzados (ASF), donde cada uno tiene datos en el mismo. Estos datos son colocados en paquetes RTP que concuerdan con la norma 1889 RFC, pero la mejoran. Como tal, las corrientes de bits de capa de sistema incluyen una serie de paquetes de medios que son paquetes ASF y la carga en cada paquete ASF es una carga ASF. Aunque paquetes ASF se usan para ilustración, la creación de paquetes RTP, en otras implementaciones que se describen en la presente, no se limita al uso de datos de formato ASF, sino que puede usar otros formatos en los cuales los datos que se van a transmitir son almacenados. Estos otros formatos, así como el formato ASF, se describen en general en la presente como corrientes de bits de capa de sistema que incluyen una pluralidad de paquetes de medios donde cada uno tiene datos en el mismo, donde estos datos son correlacionados con RTP en varias implementaciones. En la figura 1 se ilustran datos audiovisuales (AV) por flujo ASF 100. Los datos AV por flujo ASF 100, que incluyen datos de audio 102 y datos de video 104, han sido colocados en un paquete ASF A 106 y un paquete ASF B 108. El paquete ASF A 106 incluye un primer encabezado ASF, un encabezado de carga ASF, datos de audio 102, un segundo encabezado ASF y un fragmento de datos de video A de datos de video 104. El paquete ASF B 108 incluye un encabezado ASF, un encabezado de carga ASF y un fragmento de datos de video B de datos de video 104. Los datos AV por flujo ASF 100 como están expresados en el paquete ASF A 106 y paquete ASF B 108, en una ¡mplementación, se pueden colocar en una pluralidad de paquetes RTP. Como se ve en la figura 1, éstos incluyen paquete RTP A 110, paquete RTP 112 (1) al paquete RTP 112 (N) y paquete RTP D 116. Cada paquete RTP, de acuerdo con la norma 1889 RFC, tiene un encabezado de paquete RTP, una carga y un encabezado de formato de carga (PF) RTP. Como se usa en la presente, el encabezado PF RTP en es un encabezado de carga en el paquete RTP. Solamente un (1) tipo de medios se encuentra en el paquete RTP. Dicho de otra manera, el paquete RTP no contiene cargas de medios mixtos. En la implementación ilustrada en la figura 1, los datos de video A del paquete ASF A 106 son demasiado grandes para caber en un solo paquete RTP. Como tales, los datos de video A del paquete ASF A 106 se dividen entre el paquete RTP 112 (1) al paquete RTP 112 (N). El tamaño de paquete RTP puede ser una función de una característica física de una red subyacente sobre la cual los paquetes RTP se van a transmitir, o una política administrativa con respecto al tamaño del paquete puede ser creada por el administrador de la red subyacente, o una evaluación del ancho de banda de transmisión de la red subyacente. Después de la colocación en paquetes RTP que se ilustra en la figura 1, los datos de audio 102 son incluidos en el paquete RTP A 110 y los datos de video B del paquete ASF B 108 son incluidos en el paquete RTP D 116. Cada encabezado PF RTP de cada paquete RTP puede contener información referente a la separación de los datos de audio y video en paquetes RTP respectivamente separados. Por consiguiente, los datos de muestra por flujo A/V 124 se pueden reconstruir a partir de los datos de audio en el paquete RTP A 110, fragmento 1 de datos de video A al fragmento N de datos de video A en paquetes RTP respectivos 112 (1) al 112 (N) y datos de video B en paquete RTP D 116. Una vez que la reconstrucción de datos de muestra por flujo A/V 124 está completa, los datos de muestra de audio 120 y los datos de muestra de video A+B 122 en los mismos se pueden presentar en un contexto por flujo. Dado lo anterior, la figura 1 ilustra un formato de cable en el cual paquetes RTP más pequeños son creados a partir de paquetes ASF más grandes, donde la colocación en paquetes pone una carga de diferentes corrientes de datos en paquetes separados, cada uno con su propio encabezado PF RTP. Igualmente, la figura 1 ilustra una implementación de un formato de cable en el cual límites de bloque para cada carga se mantienen de manera tal que muestras de audio y video originales que fueron cifradas y colocadas en paquetes ASF se puedan reconstruir por medio de un mecanismo de desciframiento que se lleva a cabo en los paquetes RTP. En la figura 2 se ¡lustran datos AV por flujo ASF 200. Los datos AV por flujo ASF 200, los cuales incluyen datos de video 202, han sido colocados en un paquete ASF A 208 y un paquete ASF B 210. El paquete ASF A 208 incluye un encabezado ASF, un encabezado de carga ASF y datos de video A 204. El paquete ASF B 210 incluye un encabezado ASF, un encabezado de carga ASF y datos de video B 206. La figura 2 muestra dos (2) alternativas para poner datos AV por flujo ASF 200 en paquetes RTP que concuerdan con la norma 1889 RFC, pero la mejoran. En la primera alternativa, siguiendo la flecha 250, los datos de video A 204 y los datos de video B 206 son colocados en paquetes en una sola alternativa A de paquete RTP 212 que tiene un encabezado RTP. Cada uno de los datos de video A 204 y los datos de video B 206 está precedido por un encabezado PF RTP. La alternativa A de paquete RTP 212, de acuerdo con la norma 1889 RFC, tiene un encabezado RTP, múltiples cargas y encabezados PF RTP respectivos. En la segunda alternativa, siguiendo también la flecha 250, los datos de video A 204 y los datos de video B 206, de paquetes ASF respectivos, son colocados en paquetes en una alternativa B de paquete RTP 214 que tiene un encabezado RTP. Los datos de video A 204 y los datos de video B 206 son ensamblados de manera contigua como la carga en la alternativa B de paquete RTP 214. La carga está precedida por un encabezado PF RTP. La alternativa B de paquete RTP 214, de acuerdo con la norma 1889 RFC, tiene un encabezado RTP, una carga y un encabezado PF RTP. Después de la colocación en paquetes RTP que se ilustra en la figura 2, los datos de video A y B (204, 206) son incluidos ya sea en la alternativa A de paquete RTP 212 o en la alternativa B de paquete RTP 214. Cada encabezado PF RTP puede contener información referente a la carga correspondiente. Cada uno de los paquetes RTP alternativos 212, 214 contiene suficientes datos para reconstruir el paquete ASF A 208 y el paquete ASF B 210 para obtener en el mismo datos de video A y B (204, 206). Una vez que la reconstrucción está completa, los datos de muestra de video 222 se pueden presentar en un contexto por flujo. Dado lo anterior, la figura 2 ilustra un formato de cable RTP en el cual paquetes RTP más grandes son creados a partir de paquetes ASF pequeños y donde límites de bloque para cada carga se mantienen de manera tal que muestras de video originales que fueron cifradas y colocadas en los dos paquetes ASF se puedan reconstruir por medio de un mecanismo de desciframiento que se lleva a cabo en los paquetes RTP. La figura 3a ilustra un diagrama de estructura de datos para campos en un encabezado RTP. El encabezado RTP se describe en mayor detalle en la norma 1889 RFC. El campo de reloj fechador en el encabezado RTP se debe ajusfar al tiempo de presentación de la muestra contenida en el paquete RTP. En una implementación, la frecuencia de reloj es 1 kHz a menos que se especifique que es diferente a través de medios independientes de RTP. El octavo bit desde el comienzo del encabezado RTP es interpretado como un campo de bit marcador (M). El bit M se ajusta a cero, pero se ajustará a uno ("1") siempre que el paquete RTP correspondiente tenga una carga que no sea un fragmento de una muestra, contenga el fragmento final de una muestra, o sea uno de una pluralidad de muestras completas en el paquete RTP. El bit M puede ser usado por un receptor para detectar la recepción de una muestra completa para decodificación y presentación. Por lo tanto, el bit en el encabezado RTP se puede usar para marcar eventos significativos en una corriente de paquetes (por ejemplo, límites de cuadro de muestra de video). La figura 3b ilustra una implementación de un encabezado de formato de carga (PF) RTP o encabezado de carga. El encabezado PF RTP tiene una porción de longitud fija de dieciséis (16) bits seguida de una porción de longitud variable. Los campos del encabezado PF RTP ilustrado en la figura 3b incluyen una serie de 8 bits indicada por los campos de caracteres "SGLRTDXZ", un campo de longitud/desplazamiento, un campo de reloj fechador relativo, un campo de tiempo de descompresión, un campo de duración y un campo de longitud de Extensión de Carga (P.E.) y un campo de datos P.E. correspondiente, cada uno de los cuales se explica a continuación. El campo S tiene una longitud de un (1) bit y se ajusta a uno ("1") si la carga correspondiente (por ejemplo, muestra, fragmento de una muestra, o combinación de muestras) es una muestra clave, es decir, muestra intracodificada o I-Cuadro. De otra manera se ajusta a cero. El bit S en todos los encabezados PF RTP que preceden fragmentos de la misma muestra se debe ajustar al mismo valor. El campo G tiene una longitud de un (1) bit y se usa para agrupar submuestras en una carga correspondiente que forman una sola muestra. La Administración de Derechos Digitales de Windows® Media (WM DRM) cifra contenido con base en los límites de "Carga ASF". A fin de permitir que este contenido sea descifrado correctamente, los límites de las submuestras en la carga pueden ser comunicados al cliente que va a recibir la carga. Por ejemplo, una unidad de cifrado se puede empaquetar de manera tal que sea dividida en una pluralidad de unidades de transmisión (por ejemplo, colocadas dentro de paquetes separados) que se van a transmitir. Antes de que la pluralidad dividida de unidades de transmisión se pueda descifrar en un cliente receptor, se tienen que volver a ensamblar en la forma cifrada original. Como en otras metodologías y mecanismos de desciframiento, el cliente puede usar los límites para reconstruir de manera apropiada las unidades de cifrado cifradas en preparación para desciframiento del contenido cifrado. Como tal, cada "Carga ASF" debe estar precedida por este encabezado PF RTP. El bit de campo G se debe ajustar a cero ("0") para indicar que una "unidad" cifrada ha sido fragmentada. Si se está usando ASF, la unidad de cifrado será una carga ASF y el bit se ajusta a cero ("0") en todas las cargas ASF fragmentadas, excepto la última carga ASF. En este caso no importa si una muestra ha sido o no fragmentada. Si no se está usando ASF, la unidad de cifrado es una muestra de medios, en cuyo caso el bit G se ajusta a cero ("0") en todas las muestras de medios fragmentadas excepto la última muestra. En cuanto a este último caso, el problema acerca de que si una carga ASF ha sido o no fragmentada no es aplicable, ya que no se usa ASF. El campo L tiene una longitud de un (1) bit y se ajusta a uno ("1") si el campo de longitud/desplazamiento contiene una longitud. De otra manera se ajusta a cero ("0") y el campo de4 longitud/desplazamiento contiene un desplazamiento. El bit L se debe ajustar a uno ("1") en todos los encabezados PF RTP que preceden una muestra completa (sin fragmentar) en la carga correspondiente y se debe ajustar a cero en todos los encabezados PF RTP que preceden una carga de contiene una muestra fragmentada. El campo R tiene una longitud de un (1) bit y se ajusta a uno ("1") si el encabezado PF RTP contiene un reloj fechador relativo. De otra manera se ajusta a cero. El bit R en todos los encabezados que preceden fragmentos de la misma muestra se debe ajustar al mismo valor. El campo T tiene una longitud de un (1) bit y se ajusta a uno ("1") si el encabezado PF RTP contiene un tiempo de descompresión. De otra manera se ajusta a cero. El bit T en todos los encabezados PF RTP que preceden una carga que contiene un fragmento de la misma muestra se debe ajustar al mismo valor. El campo D tiene una longitud de un (1) bit y se ajusta a uno ("1") si el encabezado PF RTP contiene una duración de muestra. De otra manera se ajusta a cero. El bit D en todos los encabezados PF RTP que preceden una carga que contiene fragmentos de la misma muestra se debe ajustar al mismo valor. El campo X tiene una longitud de un (1) bit y es para uso opcional o no especificado. Un transmisor de un paquete RTP debe ajustar este bit a cero y un receptor del mismo puede ignorar este bit. El campo Z tiene una longitud de un (1) bit y se ajusta a uno ("1") si el encabezado PF RTP contiene datos de Extensión de Carga (P.E.), los cuales pueden ser metadatos referentes a la carga correspondiente. De otra manera el campo Z se ajusta a cero. El bit de campo Z podría ser cero para todos los encabezados PF RTP cuyo bit M es cero, pero se debe ajustar para todos los encabezados PF RTP en cuyo bit M se ajuste a uno ("1") si la carga correspondiente tiene datos de P.E. asociados con la misma. El campo de longitud/desplazamiento tiene una longitud de veinticuatro (24) bits y cuantifica la longitud o desplazamiento de una sola muestra que ha sido fragmentada sobre múltiples paquetes RTP. El bit L se ajusta a cero y el campo de longitud/desplazamiento contiene el desplazamiento de byte del primer byte de este fragmento desde el comienzo de la carga correspondiente (por ejemplo, muestra o fragmento de la misma). Si una o más muestras completas están contenidas en el paquete RTP, el bit L se ajusta a uno ("1") en cada encabezado PF RTP y el campo de longitud/desplazamiento de muestra contiene la longitud de la muestra (incluyendo el encabezado PF RTP). El campo de reloj fechador relativo tiene una longitud de treinta y dos (32) bits y está presente solamente si el bit R se ajusta a uno ("1"). Contiene el reloj fechador relativo para la muestra correspondiente con respecto al reloj fechador en el encabezado RTP correspondiente. La escala de tiempo usada es la misma que aquélla usada paran el reloj fechador en el encabezado RTP. El campo de reloj fechador relativo está especificado como un número de 32 bits con signo para considerar desplazamientos negativos del reloj fechador del encabezado RTP. Cuando el campo de reloj fechador relativo está ausente, se puede usar un reloj fechador relativo por omisión de cero. El tiempo de descompresión tiene una longitud de treinta y dos (32) bits y está presente solamente si el bit T se ajusta a uno ("1"). Contiene el tiempo de descompresión con relación al reloj fechador en el encabezado RTP. La escala de tiempo usada es la misma que aquélla usada para el reloj fechador en el encabezado RTP. Este campo está especificado como un número de 32 bits con signo para considerar desplazamientos negativos del reloj fechador en el encabezado RTP. El campo de duración tiene una longitud de treinta y dos (32) bits y está presente solamente si el bit D se ajusta a uno ("1"). Contiene la duración de la muestra correspondiente. La escala de tiempo usada es la misma que aquélla usada para el reloj fechador en el encabezado RTP. El campo de duración, en todos los encabezados PF RTP que preceden fragmentos de la misma muestra, se debe ajustar al mismo valor. Cuando este campo está ausente, la duración por omisión se obtiene de manera implícita o explícita a partir de los datos de muestra. Si esto no es viable, la omisión es la diferencia entre el reloj fechador de esta muestra y el reloj fechador de la siguiente muestra. El campo de longitud de datos de Extensión de Carga (P.E.) tiene una longitud de dieciséis (16) bits y está presente solamente si el bit Z se ajusta a uno ("1"). Contiene el número de bytes de datos de P.E. contenidos después de la parte fija del encabezado PF RTP. Los datos de P.E. son variables en longitud y contienen uno o más atributos que describen la carga correspondiente que precede. El campo de longitud de datos de P.E. sigue inmediatamente la parte fija del encabezado de carga y será un número de bytes que contienen los datos de P.E. reales. La estructura de los datos de P.E. es comunicada entre el cliente y el servidor (o de igual a igual), tal como vía una descripción SDP. En una implementación para contenido protegido con WM DRM, puede haber por lo menos 4 bytes de datos DUE que representan la identificación de carga WM DRM asociada con cada muestra. Aunque las figuras 3a-3b muestran diversos campos en diversos órdenes para un encabezado RTP y encabezado PF RTP, no todos los campos se requieren y el orden de los mismos se puede volver a disponer. Por lo tanto, en algunas implementaciones, los campos y orden requeridos pueden concordar con, y aún extender, la flexibilidad de la norma 1889 RFC. Por ende, aunque se usan paquetes ASF para ilustración de la figura 3a-3b, la creación de paquetes RTP, encabezados PF RTP y cargas, en otras implementaciones descritas en la presente, no se limita al uso de datos de formato ASF, sino que puede usar otros formatos en los cuales los datos que se van a transmitir son almacenados. Estructura de Red General La figura 4 muestra un sistema de red de cliente/servidor 400 y ambiente de acuerdo con la invención. El general, el sistema 400 incluye uno o más servidores multimedia de red (m) 402 y uno o más clientes de red (k) 404. Las computadoras se comunican entre sí sobre una red de comunicaciones de datos, que en la figura 4 incluye una red cableada/inalámbrica 406. La red de comunicaciones de datos 406 pudiera incluir también la Internet o redes de área local y redes de área amplia privada. Los servidores 402 y clientes 404 se comunican entre sí vía cualquiera de una amplia variedad de protocolos conocidos, tal como el Protocolo de Control de Transmisión (TCP) o el Protocolo de Datagrama de Usuario (UDP). Los servidores/clientes multimedia 402/404 tienen acceso a contenido de medios por flujo en forma de diferentes corrientes de medios. Estas corrientes de medios pueden ser corrientes de medios individuales (por ejemplo, audio, video, gráficos, simulación, etcétera), o de manera alternativa corrientes de medios mixtos que incluyen múltiples de dichas corrientes individuales. Algunas corrientes de medios se pudieran almacenar como archivos 408 en una base de datos (por ejemplo, archivos ASF) u otro sistema de almacenamiento de archivos, mientras que otras corrientes de medios 410 podrían ser provistas al servidor 402 o cliente 404 multimedia en una forma "activa" de otros componentes fuente de datos a través de canales de comunicaciones dedicados o a través de la Internet en sí. Las corrientes de medios recibidas de los servidores 402 o de los clientes 404 son presentadas en el cliente 404 como una presentación multimedia, la cual puede incluir corrientes de medios de uno o más de los servidores/clientes 402/404. Estas corrientes de medios diferentes pueden incluir uno o más de los mismos tipos o tipos diferentes de corrientes de medios. Por ejemplo, una presentación multimedia puede incluir dos corrientes de video, una corriente de audio y una corriente de imágenes gráficas. Una interfase de usuario (Ul) en el cliente 404 puede permitir a los usuarios diversos controles, tales como permitir a un usuario ya se incrementar o disminuir la velocidad a la cual se lleva a cabo la presentación de medios. Ambiente Ejemplar de Computadoras En la discusión que aparece más adelante, la invención se describirá en el contexto general de instrucciones ejecutables por computadora, tales como módulos de programa, que son ejecutadas por una o más computadoras personales convencionales. En general, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc. para realizar tareas particulares o implementar tipos de datos abstractos particulares. Más aún, los expertos en la técnica entenderán que la invención se puede poner en práctica con otras configuraciones de sistema de computadora, entre las que se incluyen dispositivos portátiles, sistemas de multiprocesador, productos electrónicos basados en microprocesadores o programables, PCs de red, minicomputadoras, computadoras principales y similares. En un ambiente de computadoras distribuidas, módulos de programa se pueden ubicar en dispositivos de almacenamiento de memoria tanto locales como remotos. De manera alternativa, la invención se podría ¡mplementar en hardware o una combinación de hardware, software y/o accesorios permanentes (firmware). Por ejemplo, uno o más circuitos integrados específicos para aplicaciones (ASICs) se podrían programar para llevar a cabo la invención. Como se muestra en la figura 4, un sistema de red de acuerdo con la invención incluye servidor(es) y cliente de red 402, 404 a partir de los cuales se encuentra disponible una pluralidad de corrientes de medios. En algunos casos, las corrientes de medios son en realidad almacenadas por el servidor(es) y/o cliente 402, 404. En otros casos, el servidor(es) y/o cliente(s) 402, 404 pueden obtener las corrientes de medios de otras fuentes o dispositivos de red. En general, los clientes de red 404 responden a entrada de usuario para solicitar corrientes de medios que corresponden a contenido multimedia seleccionado. En respuesta a una solicitud de una corriente de medios que corresponde a contenido multimedia, el servidor(es) y/o clientes 402, 404 transmiten las corrientes de medios solicitadas al cliente de red 404 que las solicita de acuerdo con un formato de cable RTP. El cliente 404 descifra las cargas en los paquetes RTP respectivos y presenta las corrientes de datos descifradas resultantes para producir el contenido multimedia solicitado. La figura 5 ilustra la entrada y almacenamiento de datos por flujo A/V en un servidor 402 o un cliente 404 (por ejemplo, un semejante). Asimismo, la figura 5 ilustra comunicaciones entre servidor y cliente (402-404) o de igual a igual (404-404) de acuerdo con diversas implementaciones. A manera de visión general, el servidor o cliente 402, 404 recibe entrada de datos por flujo A/V de un dispositivo de entrada 530. El servidor o cliente 402, 404 codifica la entrada mediante el uso de un codificador de un codee. La codificación puede, mas no necesita, ser llevada a cabo en datos de formato ASF. Si se usan datos de formato ASF, la codificación se lleva a cabo en paquetes ASF que incluyen, cada uno, un encabezado ASF y encabezado de carga ASF y una carga AV (audio y/o video). La codificación puede incluir cifrado, tal como donde se usa WM DRM. Los paquetes ASF son almacenados por el servidor/cliente 402, 404 para servir futuras solicitudes de los mismos. Posteriormente, el cliente solicita la corriente de datos AV correspondiente del servidor/cliente. El servidor/cliente recupera y transmite al cliente la corriente AV correspondiente que el servidor/cliente había almacenado previamente. Al recibirla, el cliente decodifica la corriente de datos AV y reconstruye y descifra muestras de corriente de datos AV divididas cifradas con el uso de límites comunicados en los encabezados PF RTP correspondientes. El cliente puede entonces realizar la presentación de los datos AV transmitidos. El flujo de datos se ve en la figura 5 entre y en medio de los bloques 504-530. En el bloque 504, un dispositivo de entrada 502 proporciona al servidor/cliente 402, 404 entrada que incluye datos por flujo A/V. A manera de ejemplo, los datos por flujo A/V pudieran ser provistos al servidor/cliente 402/404 en forma "activa" por medio del dispositivo de entrada 502 a través de canales de comunicaciones dedicados o a través de la Internet. Los datos por flujo A/V son provistos a un codificador en el bloque 504 para colocar los datos en paquetes ASF. En el bloque 506, se emplea cifrado WM DRM opcional y los paquetes ASF son almacenados en el servidor/cliente 402/404. Un resultado del cifrado WM DRM y la colocación en paquetes puede ser que una unidad de cifrado se divida en una pluralidad de paquetes separados. Antes de que la pluralidad dividida de unidades de transmisión pueda ser descifrada en un cliente receptor, se tienen que volver a ensamblar en el cliente en las unidades de cifrado originales. Como tales, los límites de las unidades de transmisión divididas se almacenan en los encabezados de carga ASF en el bloque 506. En el bloque 508, el cliente 404 hace una solicitud de la corriente de datos A/V que es transmitida al servidor/cliente 402/404 como se ve en la fecha 510 en la figura 5. En el bloque 512, el servidor/cliente 402/404 recibe la solicitud. Los paquetes ASF correspondientes que contienen la corriente de datos A/V solicitada son recuperados. En el bloque 514, las cargas de audio y video en los paquetes ASF son separadas lógicamente de manera que se puedan colocar por separado en paquetes RTP. Se identifican los límites para cada carga de audio y video separada lógicamente. Se determina un ancho de banda de la red sobre la cual se van a transmitir los paquetes RTP. Esta determinación se usa para derivar un tamaño de paquete RTP predeterminado. Donde el tamaño de paquete ASF es más pequeño que el tamaño de paquete RTP predeterminado, cargas de tipo similar se pueden combinar en un solo paquete RTP. Donde el tamaño de paquete ASF es más grande que el tamaño de paquete RTP predeterminado, cargas ASF se pueden fragmentar para colocar como una carga en un solo paquete RTP. Se determinan los límites para cada carga RTP con el uso de las cargas de audio y video separadas lógicamente correspondientes de los paquetes ASF. En el paso 516, el encabezado RTP, encabezado PF RTP y carga respectiva son ensamblados para cada paquete RTP. Como tal, se ha formado una pluralidad de paquetes RTP que representa una pluralidad de paquetes ASF, donde los paquetes ASF contienen la corriente de datos A/V que fue solicitada por el cliente 404. Los paquetes RTP son transmitidos para presentar al cliente 404 del servidor/cliente 402/404 vía una función de transmisión en el bloque 518. Una flecha 520 en la figura 5 muestra la transmisión de los paquetes RTP del servidor/cliente 402/404 al cliente 404. En el bloque 522, el cliente 404 recibe los paquetes RTP. En el bloque 524, un decodificador RTP en el cliente 404 decodifica cada paquete RTP recibido, incluyendo el encabezado RTP y encabezado PF RTP. En el bloque 526, un proceso realiza la defragmentación y reconstrucción de los paquetes ASF que contienen la corriente de datos A/V sol icitada . La defragmentación y reconstrucción utilizan l ímites expuestos en el encabezado PF RTP para cada carga correspondiente que contiene, por ejemplo, una muestra o frag mento de la misma. En el bloq ue 528 , los paquetes ASF reconstruidos son descifrados para presentar en el bloque 530. El encabezado PF RTP en un paquete RTP puede contener datos de Extensión de Carga (P E . ) que describen la carga correspondiente. Por consig u iente , los datos de P. E . pueden proporcionar metadatos que se pueden usar durante una presentación de la carga en el paquete RTP correspondiente en el bloque 530. Los bloques 522-530 se repiten para cada paq uete RTP que es recibido en el cl iente 404 , log rando así la transmisión de los datos A/V del servidor/cliente 402/404 para presentación . La figura 6 muestra u n ejemplo general de u na computadora 642 que se puede usar de acuerdo con la invención . La com putadora 642 se muestra como u n ejemplo de una computadora que puede realizar las funciones de cualqu iera de los clientes 402 o servidores 404 de las figuras 4-5. La computadora 642 incluye uno o más procesadores o unidades de procesamiento 644, una memoria de sistema 646 y u n bus del sistema 648 que acopla diversos componentes del sistema entre los q ue se incl uyen la memoria de sistema 646 a procesadores 644. El bus 648 representa uno o más de cualquiera de diversos tipos de estructu ras de bus , incluyendo un bus de memoria o controlador de memoria, un bus periférico, un puerto de gráficos acelerados y un procesador o bus local que usa cualquiera de una variedad de arquitecturas de bus. La memoria de sistema incluye memoria de sólo lectura (ROM) 650 y memoria de acceso aleatorio (RAM) 652. Una caché 675 tiene niveles L 1 , L2 y L3 y puede estar incluida en la RAM 652. Un sistema básico de entrada/salida (BIOS) 654, que contiene las rutinas básicas que ayudan á transferir información entre elementos dentro de la computadora 652, tales como durante el arranque, está almacenado en la ROM 650. La computadora 642 incluye además una unidad de disco duro 656 para leer de y escribir a un disco duro (no se muestra), una unidad de disco magnético 658 para leer de y escribir a un disco magnético removible 660 y una unidad de disco óptico 662 para leer de y escribir a un disco óptico removible 664 tal como un CD ROM u otros medios ópticos. t Cualquiera del disco duro (no se muestra), unidad de disco magnético 658, unidad de disco óptico 662 o disco óptico removible 664 puede ser un medio de información que tenga grabada información en el mismo. El medio de información tiene un área de datos para grabar datos de flujo usando paquetes de flujo, cada uno de los cuales incluye un área de paquete que contiene uno o más paquetes de datos. A manera de ejemplo, cada paquete de datos es codificado y decodificado por un codee de programas de aplicaciones 672 que se ejecutan en la unidad de procesamiento 644. Como tal, el codificador distribuye los datos de flujo a las áreas de paquetes de datos en los paquetes de flujo de manera que los datos de flujo distribuidos sean grabados en las áreas de paquetes de datos usando un algoritmo de codificación. De manera alternativa, la codificación y decodificación de paquetes de datos se puede realizar como una función de sistema operativo 670 que se ejecuta en la unidad de procesamiento 644. La unidad de disco duro 656, unidad de disco magnético 658 y unidad de disco óptico 662 están conectadas al bus del sistema 648 mediante una interfase SCSI 666 o alguna otra interfase apropiada. Las unidades y sus medios legibles por computadora asociados proveen almacenamiento no volátil de instrucciones legibles por computadora, estructuras de datos, módulos de programa y otros datos para la computadora 642. Aunque el ambiente ejemplar que se describe en la presente emplea un disco duro, un disco magnético removible 660 y un disco óptico removible 664, los expertos en la técnica deben entender que otros tipos de medios legibles por computadora que pueden almacenar datos que son accesibles por una computadora, tales como cassettes magnéticos, tarjetas de memoria no volátil relámpago (memoria 'flash'), discos de video digitales, memorias de acceso aleatorio (RAMs), memorias de sólo lectura (ROM) y similares, se pueden usar también en el ambiente de operación ejemplar. Un número de módulos de programa se pueden almacenar en el disco duro, disco magnético 660, disco óptico 664, ROM 650 o RAM 652, incluyendo un sistema operativo 670, uno o más programas de aplicaciones 672 (los cuales pueden incluir el codee), otros módulos de programa 674 y datos de programa 676. Un usuario puede introducir comandos e información en la computadora 642 a través de dispositivos de entrada tales como un teclado 678 y dispositivo de señalamiento 680. Otros dispositivos de entrada (no se muestra) pueden incluir un micrófono, palanca de mando, controles de juego, antena parabólica, escáner o similares. Estos y otros dispositivos de entrada están conectados a la unidad de procesamiento 644 a través de una interfase 682 que está acoplada al bus del sistema. Un monitor 684 u otro tipo de dispositivo de visualización está conectado también al bus de sistema 648 vía una interfase, tal como un adaptador de video 686. Además del monitor, las computadoras personales típicamente incluyen otros dispositivos de salida periféricos (no se muestran) tales como bocinas e impresoras. La computadora 642 opera en un ambiente en red que usa conexiones lógicas a una o más computadoras remotas, tal como una computadora remota 688. La computadora remota 688 puede ser otra computadora personal, un servidor, un ruteador, una PC de red, un dispositivo semejante u otro nodo de red común y típicamente incluye muchos de o todos los elementos descritos anteriormente con relación a la computadora 642, aunque solamente un dispositivo de almacenamiento de memoria 690 ha sido ilustrado en la figura 6. Las conexiones lógicas ilustradas en la figura 6 incluyen una red de área local (LAN) 692 y una red de área amplia (WAN) 694. Tales ambientes de conexión en red son comunes en oficinas, redes de computadoras en toda la empresa, intranets y la Internet. En la modalidad descrita de la invención, la computadora remota 688 ejecuta un programa de navegador de páginas de la red mundial ('web') de Internet tal como el navegador de páginas de la red mundial Internet Explorer® fabricado y distribuido por Microsoft Corporation de Redmond, Washington. Cuando se usa en un ambiente de conexión en red LAN, la computadora 642 es conectada a la red local 692 a través de una ¡nterfase de red o adaptador 696. Cuando se usa en un ambiente de conexión en red WAN, la computadora 642 típicamente incluye un módem 698 u otro medio para establecer comunicaciones sobre la red de área amplia 694, tal como la Internet. El módem 698, el cual puede ser interno o externo, está conectado al bus del sistema 648 vía una interfase de puerto en serie 688. En un ambiente en red, los módulos de programa ilustrados con relación a la computadora personal 642, o porciones de los mismos, se pueden almacenar en el dispositivo de almacenamiento de memoria remoto. Se entenderá que las conexiones de red mostradas son ejemplares y se pueden usar otros medios para establecer un enlace de comunicaciones entre las computadoras. En general, los procesadores de datos de la computadora 642 son programados por medio de instrucciones almacenadas en diferentes tiempos en los diversos medios de almacenamiento legibles por computadora de la computadora. Los programas y sistemas operativos son distribuidos típicamente, por ejemplo, en discos flexibles o CD ROMs. De ahí, son instalados o cargados en la memoria secundaria de una computadora. En la ejecución, son cargados al menos parcialmente en la memoria electrónica primaria de la computadora. La invención descrita en la presente incluye estos y otros diversos tipos de medios de almacenamiento legibles por computadora cuando tales medios contienen instrucciones o programas para implementar los pasos descritos más adelante junto con un microprocesador u otro procesador de datos. Igualmente, la invención incluye la computadora en sí cuando está programada de acuerdo con los métodos y técnicas que se describen más adelante. Además, ciertos subcomponentes de la computadora se pueden programar para realizar las funciones y pasos que se describen más adelante. La invención incluye dichos subcomponentes cuando son programados como se describe. Además, la invención descrita en la presente incluye estructuras de datos, que se describen más adelante, como modalizadas en numerosos tipos de medios de memoria. Para propósitos de ilustración, los programas y otros componentes de programas ejecutables tales como el sistema operativo se ilustran en la presente como bloques discretos, aunque se reconoce que dichos programas y componentes residen en múltiples tiempos en diferentes componentes de almacenamiento de la computadora y son ejecutados por el procesador(es) de datos de la computadora. Conclusión Las ¡mplementaciones que se describen en la presente definen un formato de cable que se puede usar en la entrega de datos multimedia entre servidor y cliente y de igual a igual vía RTP. El formato de cable considera una mayor flexibilidad que las normas 1889 IETF RFC actualmente adoptadas para entrega RTP. Las ¡mplementaciones del formato de cable proveen transmisión de datos cifrados, proveen un mecanismo para entregar por muestra metadatos vía RTP y proveen transmisión de datos que están protegidos con WM DRM. Aunque la invención ha sido descrita en lenguaje específico a características estructurales y/o acciones metodológicas, se debe entender que la invención definida en las reivindicaciones adjuntas no se limita necesariamente a las características o acciones específicas descritas. Más bien, las características y acciones específicas se describen como formas ejemplares de implementar la invención reclamada.

Claims (59)

REIVINDICACIONES
1. Un aparato que comprende: medios para cifrar una corriente de datos con un tamaño de bloque arbitrario para formar una pluralidad de unidades de cifrado; y medios para colocar la pluralidad de unidades de cifrado en una pluralidad de paquetes RTP, cada uno incluye: un encabezado de paquete RTP; una o más cargas de una corriente de datos común y seleccionada del grupo que consiste de: una o más de las unidades de cifrado; un fragmento de una de las unidades de cifrado; y un encabezado de formato de carga RTP para cada una de las cargas e incluyendo, para las unidades de cifrado correspondientes, un límite para el tamaño de bloque arbitrario.
2. El aparato tal y como se describe en la reivindicación 1, caracterizado porque comprende: medios para volver a ensamblar la pluralidad de unidades de cifrado usando: las cargas en la pluralidad de paquetes RTP; y el límite respectivo para el tamaño de bloque arbitrario en el encabezado de formato de carga RTP respectivo; medios para descifrar la pluralidad de unidades de cifrado para formar la corriente de datos.
3. El aparato tal y como se describe en la reivindicación 2, caracterizado porque: cada uno de los encabezados de formato de carga RTP comprende además uno o más atributos de la carga correspondiente; y el aparato comprende además medios para presentar la corriente de datos formada usando los atributos de la carga correspondiente.
4. El aparato tal y como se describe en la reivindicación 2, caracterizado porque los atributos en cada uno de los encabezados de formato de carga RTP se selecciona del grupo que consiste de: información de sincronización; e información de cuadro de compresión de video.
5. El aparato tal y como se describe en la reivindicación 2, caracterizado porque comprende además medios para transmitir la pluralidad de paquetes RTP sobre una red.
6. Un aparato que comprende: medios para separar lógicamente tipos de datos de medios en una corriente de datos incluyendo una pluralidad de los tipos de datos de medios; y medios para formar una pluralidad de paquetes RTP a partir de la corriente de datos, cada uno de los paquetes RTP incluye: solamente uno de los tipos de datos de medios; un encabezado de paquete RTP; uno o más encabezados de formato de carga RTP de longitud variable donde cada uno tiene uno o más atributos; y una carga RTP correspondiente a cada uno de los encabezados de formato de carga RTP y que es descrita por el o los atributos en la misma.
7. El aparato tal y como se describe en la reivindicación 6, caracterizado porque comprende además: medios para extraer las cargas de la pluralidad de paquetes RTP; y medios para presentar cada carga en la pluralidad de paquetes RTP usando el o los atributos en el encabezado de formato de carga RTP correspondiente.
8. El aparato tal y como se describe en la reivindicación 7, caracterizado porque: cada carga comprende datos de video; y los atributos en cada encabezado de formato de carga RTP se seleccionan del grupo que consiste de: información de sincronización; e información de cuadro de compresión de video.
9. El aparato tal y como se describe en la reivindicación 7, caracterizado porque los medios para extraer comprenden además, para cada carga RTP: medios, donde la carga RTP incluye 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 medios en una carga contigua; medios, donde la carga RTP incluye una porción de uno de los tipos de datos de medios, para ensamblar la porción de uno de los tipos de datos de medios en una carga contigua; y medios, donde la carga RTP incluye un fragmento o una porción de uno de los tipos de datos de medios, para ensamblar todos los fragmentos de la porción de uno de los tipos de datos de medios en una carga contigua.
10. El aparato tal y como se describe en la reivindicación 9, caracterizado porque comprende además: medios para ensamblar, en orden cronológico respectivo correspondiente a la pluralidad de tipos de datos de medios del archivo de medios, las cargas contiguas; y medios para presentar simultáneamente las cargas contiguas ordenadas cronológicamente de la pluralidad de tipos de datos de medios del archivo de medios.
11. Una estructura de datos que tiene un formato de cable para transmisión sobre una red, la estructura de datos comprende una pluralidad de paquetes de medios sencillos formados a partir de una pluralidad de paquetes de medios mixtos, caracterizada porque: cada paquete de medios mixto incluye: una carga para cada una de una pluralidad de corrientes de datos, en donde la carga es cifrada y tiene un tamaño de bloque arbitrario; y un encabezado de carga para cada carga e incluyendo un límite para el tamaño de bloque arbitrario; cada paquete de medios sencillo incluye una corriente de datos, corresponde a uno de los paquetes de medios mixtos, e incluye: una carga correspondiente a una de las cargas en un paquete de medios mixto; un encabezado del formato de perfil de carga que corresponde a: la carga; y uno o más encabezados de carga del paquete de medios mixto, en donde el encabezado de formato de perfil de carga tiene un límite que corresponde a: los límites respectivos de el o los encabezados de carga del paquete de medios mixto; y la carga.
12. La estructura de datos tal y como se describe en la reivindicación 11, caracterizada porque cada paquete de medios sencillo comprende además: un encabezado de paquete que corresponde a uno o más encabezados de paquete de la pluralidad de paquetes de medios mixtos; una composición seleccionada del grupo que consiste de: una pluralidad de las cargas de los paquetes de medios mixtos, que es de una corriente de datos similar, cada una tiene un encabezado de formato de perfil de carga correspondiente; y una carga y un encabezado de formato de perfil de carga correspondiente.
13. La estructura de datos tal y como se describe en la reivindicación 11, caracterizada porque cada paquete de medios sencillo es menor a un tamaño predeterminado que es una función seleccionada del grupo que consiste de: una característica física de una red subyacente; una política administrativa con respecto al tamaño de paquete; y una evaluación del ancho de banda de transmisión de la red subyacente.
14. La estructura de datos tal y como se describe en la reivindicación 11, caracterizada porque el límite de carga en el paquete de medios sencillo identifica el orden cronológico de la carga correspondiente en el paquete de medios mixto.
15. La estructura de datos tal y como se describe en la reivindicación 11, caracterizada porque la corriente de datos se selecciona del grupo que consiste de datos de audio, datos de video, datos de programa, datos JPEG, datos HTML y datos MIDI.
16. La estructura de datos tal y como se describe en la reivindicación 11, caracterizada porque: el encabezado de formato de perfil de carga incluye una porción de longitud fija y una porción de longitud variable; y la porción de longitud variable incluye atributos de la carga correspondiente.
17. La estructura de datos tal y como se describe en la reivindicación 11, caracterizada porque: cada paquete de medios mixto incluye una porción de una corriente de datos ASF, un encabezado de paquete ASF y por lo menos un encabezado de carga ASF; y cada paquete de medios sencillo incluye, un encabezado de paquete RTP y un encabezado de formato de carga RTP; una porción de una corriente de datos RTP.
18. Un método que comprende: cifrar una corriente de datos con un tamaño de bloque arbitrario para formar una pluralidad de unidades de cifrado; y colocar la pluralidad de unidades de cifrado en una pluralidad de paquetes RTP en, cada uno incluye: un encabezado de paquete RTP; una o más cargas de una corriente de datos común y seleccionadas del grupo que consiste de: una o más de las unidades de cifrado; y un fragmento de una unidad de cifrado; un encabezado de formato de carga RTP para cada carga y que incluye, para las unidades de cifrado correspondientes, un límite para el tamaño de bloque arbitrario.
19. El método tal y como se describe en la reivindicación 18 que comprende además: volver a ensamblar la pluralidad de unidades de cifrado usando: las cargas en la pluralidad de paquetes RTP; y el límite respectivo para el tamaño de bloque arbitrario en el encabezado de formato de carga RTP respectivo; descifrar la pluralidad de unidades de cifrado para formar la corriente de datos.
20. El método tal y como se describe en la reivindicación 19, caracterizado porque: cada encabezado de formato de carga RTP comprende además uno o más atributos de la carga correspondiente; y el método comprende además presentar la corriente de datos formada usando los atributos de la carga correspondiente.
21. El método tal y como se describe en la reivindicación 19, caracterizado porque los atributos en cada encabezado de formato de carga RTP se seleccionan del grupo que consiste de: información de sincronización; e información de cuadro de compresión de video.
22. El método tal y como se describe en la reivindicación 19, que comprende además, antes de volver a ensamblar, la pluralidad de paquetes RTP sobre una red a un cliente en el cual se lleva a cabo el re-ensamblado.
23. Un medio legible por computadora que comprende instrucciones legibles por máquina que, cuando se ejecutan, llevan a cabo el método tal y como se describe en la reivindicación 18.
24. Un método que comprende formar una pluralidad de paquetes RTP a partir de una corriente de datos que incluye una pluralidad de tipos de datos de medios, cada paquete RTP incluye: solamente uno de los tipos de datos de medios; un encabezado de paquete RTP; uno o más encabezados de formato de carga RTP de longitud variable, cada uno tiene uno o más atributos; y una carga RTP que corresponde a cada encabezado de formato de carga RTP y que es escrita por el o los atributos en la misma.
25. El método tal y como se describe en la reivindicación 24, que comprende además: extraer las cargas de la pluralidad de paquetes RTP; y presentar cada carga en la pluralidad de paquetes RTP usando el o los atributos en el encabezado de formato de carga RTP correspondiente.
26. El método tal y como se describe en la reivindicación 25, caracterizado porque los atributos en cada encabezado de formato de carga RTP se seleccionan del grupo que consiste de: información de sincronización; e información de cuadro de compresión de video.
27. El método tal y como se describe en la reivindicación 25, caracterizado porque la extracción de las cargas de la pluralidad de paquetes RTP comprende además, para cada carga RTP: que incluye una pluralidad de porciones de uno de los tipos de datos de medios, ensamblando la pluralidad de porciones de uno de los tipos de datos de medios en una carga contigua; que incluye una porción de uno de los tipos de datos de medios, ensamblando la porción de uno de los tipos de datos de medios en una carga contigua; y que incluye un fragmento de una porción de uno de los tipos de datos de medios, ensamblando todos los fragmentos de una porción de uno de los tipos de datos de medios en una carga contigua.
28. El método tal y como se describe en la reivindicación 27, que comprende además: ensamblar, en orden cronológico respectivo correspondiente a la pluralidad de tipos de datos de medios del archivo de medios, las cargas contiguas; y presentar de manera simultánea las cargas contiguas ordenadas cronológicamente de la pluralidad de tipos de datos de medios del archivo de medios.
29. Un medio legible por computadora que comprende instrucciones legibles por máquina que, cuando se ejecutan, llevan a cabo el método tal y como se describe en la reivindicación 25.
30. Un método que comprende cambiar una pluralidad de paquetes de medios mixtos en una pluralidad de paquetes de medios sencillos, caracterizado porque: cada paquete de medios mixto incluye: una carga para cada una de una pluralidad de corrientes de datos, en donde la carga es cifrada y tiene un tamaño de bloque arbitrario; un encabezado de carga para cada carga y que incluye un límite para el tamaño de bloque arbitrario; cada paquete de medios sencillo incluye una corriente de datos, corresponde a uno de los paquetes de medios mixtos, e incluye: una carga correspondiente a una de las cargas en el paquete de medios mixto; un encabezado de formato de perfil de carga que corresponde a: la carga; y uno o más encabezados de carga del paquete de medios mixto, en donde el encabezado de formato de perfil de carga tiene un límite que corresponde a: los límites respectivos de el o los encabezados de carga de un paquete de medios mixto; y la carga.
31. El método tal y como se describe en la reivindicación 30, caracterizado porque cada paquete de medios sencillo comprende además: un encabezado de paquete correspondiente a uno o más encabezados de paquete de la pluralidad de paquetes de medios mixtos; una composición seleccionada del grupo que consiste de: una pluralidad de las cargas de los paquetes de medios mixtos, que es de una corriente de datos similar, cada una tiene un encabezado de formato de perfil de carga correspondiente; y una carga y un encabezado de formato de perfil de carga correspondiente.
32. El método tal y como se describe en la reivindicación 30, caracterizado porque cada paquete de medios sencillo es menor a un tamaño predeterminado que es una función seleccionada del grupo que consiste de: una característica física de una red subyacente; una política administrativa con respecto al tamaño de paquete; y una evaluación del ancho de banda de transmisión de una red.
33. El método tal y como se describe en la reivindicación 30, caracterizado porque el límite de carga en el paquete de medios sencillo identifica el orden cronológico de la carga correspondiente en el paquete de medios mixto.
34. El método tal y como se describe en la reivindicación 30, caracterizado porque la corriente de datos se selecciona del grupo que consiste de datos de audio, datos de video, datos de programa, datos JPEG, datos HTML y datos MIDI.
35. El método tal y como se describe en la reivindicación 30, caracterizado porque: el encabezado de formato de perfil de carga incluye una porción de longitud fija y una porción de longitud variable; y la porción de longitud variable incluye atributos de la carga correspondiente.
36. El método tal y como se describe en la reivindicación 30, caracterizado porque: cada paquete de medios mixto incluye una porción de una corriente de datos ASF, un encabezado de paquete ASF y por lo menos un encabezado de carga ASF; y cada paquete de medios sencillo incluye, un encabezado de paquete RTP y un encabezado de formato de carga RTP; una porción de una corriente de datos RTP.
37. Un medio legible por computadora que comprende instrucciones legibles por máquina que, cuando se ejecutan, llevan a cabo el método tal y como se describe en la reivindicación 30.
38. Un método que comprende cambiar una pluralidad de paquetes de medios mixtos en una pluralidad de paquetes de medios sencillos, caracterizado porque: cada paquete de medios mixto incluye: una carga para cada una de una pluralidad de corrientes de datos, en donde la carga es cifrada y tiene un tamaño de bloque arbitrario; un encabezado de paquete; y un encabezado de carga para cada carga y que incluye un límite para el tamaño de bloque arbitrario; cada paquete de medios sencillo corresponde a uno de los paquetes de medios mixtos , e incluye: una carga correspondiente a u na de las cargas en el paquete de medios mixto; u n encabezado de paquete q ue corresponde a uno de los encabezados de paquete del paquete de med ios mixto; u n encabezado de formato de perfil de carga que corresponde a : la carga ; y uno o más enca bezados de carga del paquete de medios mixto; en donde el encabezado de formato de perfil de carga tiene un lím ite de carga que corresponde a: los l ím ites de ca rga respectivos de el o los encabezados de carga del paquete de medios mixto ; y la carga .
39. El método tal y como se describe en la reivindicación 38, caracterizado porque: cada paquete de medios mixto incluye u na porción de una corriente de datos ASF , un enca bezado de paquete ASF y por lo menos un encabezado de carga ASF; y cada paquete de medios sencillo incluye, un encabezado de paquete RTP y un encabezado de formato de carga RTP; una porción de una corriente de datos RTP.
40. El método tal y como se descri be en la reivindicación 38, caracterizado porque: el encabezado de formato de perfil de carga incluye una porción de longitud fija y una porción de longitud variable; y la porción de longitud variable incluye atributos de la carga correspondiente.
41. Un medio legible por computadora que comprende instrucciones legibles por máquina que, cuando se ejecutan, llevan a cabo el método tal y como se describe en la reivindicación 38.
42. Un método que comprende cambiar una pluralidad de paquetes de medios sencillos en un paquete mixto, caracterizado porque: cada paquete de medios sencillo incluye: una carga de una corriente de datos, en donde la carga es cifrada y tiene un tamaño de bloque arbitrario; un encabezado de carga para la carga y que incluye un límite para el tamaño de bloque arbitrario; el paquete mixto corresponde a la pluralidad de paquetes de medios sencillos e incluye: una o más cargas de una corriente de datos similar y que corresponde a las cargas respectivas de la pluralidad de paquetes de medios sencillos; y un encabezado de formato de perfil de carga para cada carga en el paquete mixto y que corresponde a los encabezados de carga de la pluralidad de paquetes de medios sencillos, en donde el encabezado de formato de perfil de carga tiene un límite de carga para una carga respectiva en el paquete mixto que identifica un orden del mismo en la pluralidad de paquetes de medios sencillos.
43. El método tal y como se describe en la reivindicación 42, caracterizado porque el paquete mixto comprende además: un encabezado de paquete que corresponde a encabezados de paquete para cada uno de la pluralidad de paquetes de medios sencillos; una composición seleccionada del grupo que consiste de: una pluralidad de las cargas, cada una tiene un encabezado de formato de perfil de carga correspondiente; y una carga y un encabezado de formato de perfil de carga correspondiente.
44. El método tal y como se describe en la reivindicación 42, caracterizado porque cada paquete de medios sencillo es menor a un tamaño predeterminado que es una función seleccionada del grupo que consiste de: una característica física de una red subyacente; una política administrativa con respecto al tamaño de paquete; y una evaluación del ancho de banda de transmisión de la red subyacente.
45. El método tal y como se describe en la reivindicación 42, caracterizado porque la corriente de datos se selecciona del grupo que consiste de datos de audio, datos de video, datos de programa, datos JPEG, datos HTML y datos MIDI.
46. El método tal y como se describe en la reivindicación 42, caracterizado porque: cada paquete de medios mixto incluye una porción de una corriente de datos ASF, un encabezado de paquete ASF y por lo menos un encabezado de carga ASF; y cada paquete de medios sencillo incluye, un encabezado de paquete RTP y un encabezado de formato de carga RTP; una porción de una corriente de datos RTP.
47. El método tal y como se describe en la reivindicación 42, caracterizado porque: el encabezado de formato de perfil de carga incluye una porción de longitud fija y una porción de longitud variable; y la porción de longitud variable incluye atributos de la carga correspondiente.
48. Un medio legible por computadora que comprende instrucciones legibles por máquina que, cuando se ejecutan, llevan a cabo el método tal y como se describe en la reivindicación 42.
49. Un dispositivo de cómputo de cliente que comprende un procesador para ejecutar lógica configurado para: enviar una solicitud de un archivo de medios que incluye una pluralidad de tipos de datos de medios; recibir medios por flujo en una pluralidad de paquetes RTP que corresponden al archivo de medios y que incluyen: solamente uno de los tipos de datos de medios; un encabezado de paquete RTP; uno o más encabezados de formato de carga RTP, cada uno incluye un límite de carga RTP; y una carga RTP para y que corresponde a cada encabezado de formato de carga RTP, en donde la carga RTP es cifrada y tiene un tamaño de bloque arbitrario que corresponde al límite de carga RTP, cada carga RTP se selecciona del grupo que consiste de: una pluralidad de porciones de uno de los tipos de datos de medios; una porción de uno de los tipos de datos de medios; y un fragmento de una porción de uno de los tipos de datos de medios; para cada carga RTP en los paquetes RTP recibidos: que incluye una pluralidad de porciones de uno de los tipos de datos de medios, ensamblar la pluralidad de porciones de uno de los tipos de datos de medios en una carga contigua usando el límite de carga RTP del encabezado de formato de carga RTP correspondiente; que incluye una porción de uno de los tipos de datos de medios, ensamblar la porción de uno de los tipos de datos de medios en una carga contigua usando el límite de carga RTP del encabezado de formato de carga RTP correspondiente; y que incluye un fragmento de una porción de uno de los tipos de datos de medios, ensamblar todos los fragmentos de la porción de uno de los tipos de datos de medios en una carga contigua usando cada límite de carga RTP de los encabezados de formato de carga RTP correspondientes; ensamblar, en orden cronológ ico respectivo correspondiente a la pluralidad de tipos de datos de medios del archivo de medios, las cargas contiguas; y presentar de manera simultánea las cargas contiguas ordenadas cronológicamente de la plu ral idad de tipos de datos de medios del archivo de medios.
50. El d ispositivo de cómputo de cliente tal y como se describe en la reivi ndicación 49 , caracterizado porque la pluralidad de paq uetes RTP son de tamaño variable y menores a un tamaño predeterminado que es u na fu nción seleccionada del grupo que consiste de: una eva luación del ancho de banda de transmisión de una red subyacente de la cua l se recibió la pluralidad de paquetes RTP; una característica física de la red subyacente ; y una pol ítica adm i nistrativa con respecto al tamaño de paquete.
51 . El d ispositivo de cómputo de cliente tal y como se describe en la reivindicación 49, caracterizado porque cada límite de carga RTP identifica el orden cronológ ico de la carga RTP correspondiente en el ti po de datos de medios del archivo de medios.
52. El d ispositivo de cómputo de cliente tal y como se describe en la reivind icación 49, caracterizado porq ue cada tipo de de datos medios se selecciona del g rupo que consiste de datos de audio, datos de video, datos de programa, datos JPEG, datos HTML y datos MIDI.
53. El dispositivo de cómputo de cliente tal y como se describe en la reivindicación 49, caracterizado porque: cada encabezado de formato de carga RTP incluye una porción de longitud fija y una porción de longitud variable; y la porción de longitud variable incluye atributos de la carga RTP correspondiente.
54. Un dispositivo de cómputo de cliente que comprende un procesador para ejecutar lógica configurado para: enviar una solicitud de un archivo de medios que incluye datos de audio y video; recibir una pluralidad de paquetes RTP que corresponden a una pluralidad de paquetes ASF para el archivo de medios, caracterizado porque: cada paquete ASF incluye: un encabezado de paquete ASF; y uno o más encabezados de carga ASF, cada uno incluye un límite de carga ASF para una carga ASF correspondiente, en donde la carga ASF es cifrada con un tamaño de bloque arbitrario correspondiente al límite de carga ASF; la carga ASF para y que corresponde a cada encabezado de carga ASF se selecciona del grupo que consiste de: algunos de los datos de audio incluyendo una muestra de audio o fragmento del mismo; y algunos de los datos de video incluyendo una muestra de video o fragmento del mismo; cada paquete RTP incluye: ya sea algunos de los datos de audio o algunos de los datos de video; un encabezado de paquete RTP que corresponde a por lo menos uno de los encabezados de paquete ASF; uno o más encabezados de formato de carga RTP que corresponden a por lo menos uno de los encabezados de carga ASF, en donde cada encabezado de formato de carga RTP incluye un límite de carga RTP que corresponde a por lo menos uno de los límites de carga ASF; y una carga RTP para y que corresponde a cada encabezado de formato de carga RTP, cada carga RTP se selecciona del grupo que consiste de: una pluralidad de las cargas ASF; una de las cargas ASF; y un fragmento de una de las cargas ASF; para cada carga RTP en los paquetes RTP recibidos: que incluye una pluralidad de las cargas ASF, ensamblar la pluralidad de las cargas ASF en una carga contigua usando el límite de carga RTP del encabezado de formato de carga RTP correspondiente; que incluye una de las cargas ASF, ensamblar la carga ASF en una carga contigua usando el límite de carga RTP del encabezado de formato de carga RTP correspondiente; y que incluye un fragmento de una de las cargas ASF, ensamblar todos los fragmentos de una de las cargas ASF en una carga contigua usando cada límite de carga RTP de los encabezados de formato de carga RTP correspondientes; ensamblar, en orden cronológico respectivo correspondiente a los datos de audio y video del archivo de medios, las cargas contiguas; y presentar de manera simultánea las cargas contiguas ordenadas cronológicamente tanto de los datos de audio del archivo de medios como los datos de video del archivo de medios.
55. El dispositivo de cómputo de cliente tal y como se describe en la reivindicación 54, caracterizado porque los paquetes RTP son de tamaño variable y menores a un tamaño predeterminado que es una función seleccionada del grupo que consiste de: una evaluación del ancho de banda de transmisión de una red subyacente de la cual se recibió la pluralidad de paquetes RTP; una característica física de la red subyacente; y una política administrativa con respecto al tamaño de paquete; el tamaño de los paquetes ASF que corresponden a la pluralidad de paquetes RTP recibida; y una combinación de lo anterior.
56. El d ispositivo de cómputo de cliente tal y como se describe en la reivindicación 54 , caracterizado porque cada lím ite de carga ASF identifica el orden cronológ ico respectivo de la carga ASF correspondiente en uno de: los datos de audio en el arch ivo de medios; y los datos de video en el archivo de medios.
57. El dispositivo de cóm puto de cliente tal y como se describe en la reivindicación 54, caracterizado porque cada l ímite de carga RTP identifica el orden cronológ ico respectivo de la carga RTP correspondiente en u no de : los datos de audio en el archivo de medios; y los datos de video en el archivo de medios.
58. El d ispositivo de cómputo de cliente tal y como se describe en la reivindicación 54 , caracterizado porque cada límite de carga RTP identifica el orden cronológico respectivo de la carga RTP correspondiente en uno de: u na pl ural idad de las cargas ASF ; y un frag mento de u na de las cargas ASF .
59. El dispositivo de cómputo de cl iente tal y como se descri be en la reivindicación 54, caracterizado porque: cada encabezado de formato de carga RTP incluye una porción de longitud fija y una porción de longitud variable; y la porción de longitud variable incl uye atributos de la carga RTP correspondiente.
MXPA04006449A 2003-07-03 2004-06-30 Formato de carga de protocolo de transporte en tiempo real (rtp). MXPA04006449A (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/612,851 US7483532B2 (en) 2003-07-03 2003-07-03 RTP payload format

Publications (1)

Publication Number Publication Date
MXPA04006449A true MXPA04006449A (es) 2005-03-31

Family

ID=33435466

Family Applications (1)

Application Number Title Priority Date Filing Date
MXPA04006449A MXPA04006449A (es) 2003-07-03 2004-06-30 Formato de carga de protocolo de transporte en tiempo real (rtp).

Country Status (18)

Country Link
US (2) US7483532B2 (es)
EP (1) EP1494425B1 (es)
JP (1) JP4504749B2 (es)
KR (2) KR101026565B1 (es)
CN (1) CN1578311B (es)
AU (1) AU2004202538B2 (es)
BR (1) BRPI0402436A (es)
CA (2) CA2469830C (es)
CO (1) CO5600215A1 (es)
IL (2) IL162304A (es)
MX (1) MXPA04006449A (es)
MY (3) MY146788A (es)
NO (1) NO339940B1 (es)
NZ (2) NZ533297A (es)
RU (1) RU2372646C2 (es)
SG (1) SG129298A1 (es)
TW (1) TWI347106B (es)
ZA (1) ZA200404701B (es)

Families Citing this family (80)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7221660B1 (en) * 2000-08-08 2007-05-22 E.F. Johnson Company System and method for multicast communications using real time transport protocol (RTP)
US8150906B2 (en) 2001-11-12 2012-04-03 Sony Corporation Information delivery system for generating a data stream with a server system based on a content file received from a client device
JP3821086B2 (ja) * 2002-11-01 2006-09-13 ソニー株式会社 ストリーミングシステム及びストリーミング方法、クライアント端末及びデータ復号方法、並びにプログラム
US7581255B2 (en) * 2003-01-21 2009-08-25 Microsoft Corporation Systems and methods for licensing one or more data streams from an encoded digital media file
US7370212B2 (en) * 2003-02-25 2008-05-06 Microsoft Corporation Issuing a publisher use license off-line in a digital rights management (DRM) system
US7483532B2 (en) * 2003-07-03 2009-01-27 Microsoft Corporation RTP payload format
US7619994B2 (en) * 2003-11-26 2009-11-17 Nortel Networks Limited Adapter for use with a tandem-free conference bridge
KR20050054034A (ko) * 2003-12-03 2005-06-10 엘지전자 주식회사 고밀도 광디스크 및 고밀도 광디스크의 파일 관리방법 및재생방법과 기록재생장치
JP4363204B2 (ja) * 2004-02-04 2009-11-11 ヤマハ株式会社 通信端末
US20060184790A1 (en) * 2004-03-26 2006-08-17 Microsoft Corporation Protecting elementary stream content
US20050216752A1 (en) * 2004-03-26 2005-09-29 Microsoft Corporation Common scrambling
US20060036551A1 (en) * 2004-03-26 2006-02-16 Microsoft Corporation Protecting elementary stream content
IL162075A0 (en) * 2004-05-19 2005-11-20 Surf Comm Solutions Ltd Video conferencing over public network
US7656861B2 (en) * 2004-07-09 2010-02-02 Cisco Technology, Inc. Method and apparatus for interleaving text and media in a real-time transport session
US7620071B2 (en) * 2004-11-16 2009-11-17 Intel Corporation Packet coalescing
US7792143B1 (en) 2005-03-25 2010-09-07 Cisco Technology, Inc. Method and apparatus for interworking dissimilar text phone protocols over a packet switched network
US8438645B2 (en) 2005-04-27 2013-05-07 Microsoft Corporation Secure clock with grace periods
JP4716357B2 (ja) * 2005-03-29 2011-07-06 Ｋｄｄｉ株式会社 圧縮データスクランブル配信装置、その再生装置および配信・再生装置
US8725646B2 (en) * 2005-04-15 2014-05-13 Microsoft Corporation Output protection levels
US20060265758A1 (en) * 2005-05-20 2006-11-23 Microsoft Corporation Extensible media rights
US7684566B2 (en) * 2005-05-27 2010-03-23 Microsoft Corporation Encryption scheme for streamed multimedia content protected by rights management system
CN101243675B (zh) * 2005-06-27 2016-05-11 核心无线许可有限公司 用于动态丰富媒体场景的传送机制
US7769880B2 (en) 2005-07-07 2010-08-03 Microsoft Corporation Carrying protected content using a control protocol for streaming and a transport protocol
US7561696B2 (en) * 2005-07-12 2009-07-14 Microsoft Corporation Delivering policy updates for protected content
JP2007041223A (ja) * 2005-08-02 2007-02-15 Mitsubishi Electric Corp データ配信装置及びデータ通信システム
US7681238B2 (en) * 2005-08-11 2010-03-16 Microsoft Corporation Remotely accessing protected files via streaming
US8321690B2 (en) * 2005-08-11 2012-11-27 Microsoft Corporation Protecting digital media of various content types
US7634816B2 (en) 2005-08-11 2009-12-15 Microsoft Corporation Revocation information management
US8918530B2 (en) * 2005-09-09 2014-12-23 Microsoft Corporation Plug and play device redirection for remote systems
US7720096B2 (en) * 2005-10-13 2010-05-18 Microsoft Corporation RTP payload format for VC-1
CN100407726C (zh) * 2005-10-17 2008-07-30 华为技术有限公司 H.264多媒体数据实时传送方法
ATE467299T1 (de) * 2005-12-22 2010-05-15 Microsoft Corp Peer-to-peer-nachrichtenformat
EP1967006A2 (en) * 2005-12-23 2008-09-10 Koninklijke Philips Electronics N.V. Splitting of a data stream
US7782836B2 (en) * 2006-03-24 2010-08-24 Samsung Electronics Co., Ltd. Method and system for transmission of different types of information in wireless communication
US8259647B2 (en) * 2006-06-12 2012-09-04 Samsung Electronics Co., Ltd. System and method for wireless communication of uncompressed video having a link control and bandwidth reservation scheme for control/management message exchanges and asynchronous traffic
JP4267008B2 (ja) * 2006-07-28 2009-05-27 Ｎｅｃインフロンティア株式会社 クライアント・サーバ分散システム、サーバ装置、クライアント装置及びそれらに用いるクライアント間ｒｔｐ暗号方法
US8279784B2 (en) * 2006-11-01 2012-10-02 Sibeam, Inc. Wireless HD AV packet format
US8879448B2 (en) * 2006-12-22 2014-11-04 Samsung Electronics Co., Ltd. Apparatus for controlling power of WiMedia media access control device and method using the same
BRPI0721261A2 (pt) * 2007-03-08 2011-11-01 Thomson Licensing método, aparelho e sistema para fluxo de trabalho de distribuição coordenada de conteúdo
US20080256646A1 (en) * 2007-04-12 2008-10-16 Microsoft Corporation Managing Digital Rights in a Member-Based Domain Architecture
US9805374B2 (en) 2007-04-12 2017-10-31 Microsoft Technology Licensing, Llc Content preview
US8539543B2 (en) * 2007-04-12 2013-09-17 Microsoft Corporation Managing digital rights for multiple assets in an envelope
JP4750759B2 (ja) * 2007-06-25 2011-08-17 パナソニック株式会社 映像音声再生装置
JP5334335B2 (ja) 2007-07-02 2013-11-06 フラウンホファー・ゲゼルシャフト・ツール・フォルデルング・デル・アンゲバンテン・フォルシュング・アインゲトラーゲネル・フェライン メディアデータコンテナおよびメタデータコンテナを有するファイルを記憶および読み出すための装置および方法
US20090028142A1 (en) * 2007-07-25 2009-01-29 Schmidt Brian K Streaming data content in a network
CN101802823A (zh) * 2007-08-20 2010-08-11 诺基亚公司 用于流式多媒体数据的分段的元数据和位标
US8355336B2 (en) * 2008-02-13 2013-01-15 Qualcomm Incorporated Methods and apparatus for formatting headers in a communication frame
US8325800B2 (en) 2008-05-07 2012-12-04 Microsoft Corporation Encoding streaming media as a high bit rate layer, a low bit rate layer, and one or more intermediate bit rate layers
US8379851B2 (en) * 2008-05-12 2013-02-19 Microsoft Corporation Optimized client side rate control and indexed file layout for streaming media
US8625642B2 (en) * 2008-05-23 2014-01-07 Solera Networks, Inc. Method and apparatus of network artifact indentification and extraction
US8521732B2 (en) 2008-05-23 2013-08-27 Solera Networks, Inc. Presentation of an extracted artifact based on an indexing technique
US7925774B2 (en) 2008-05-30 2011-04-12 Microsoft Corporation Media streaming using an index file
US8387150B2 (en) * 2008-06-27 2013-02-26 Microsoft Corporation Segmented media content rights management
US8265140B2 (en) * 2008-09-30 2012-09-11 Microsoft Corporation Fine-grained client-side control of scalable media delivery
US8259572B2 (en) * 2008-12-02 2012-09-04 Kyocera Corporation Communication method and transmitting apparatus utilizing the same
KR101552649B1 (ko) * 2009-10-30 2015-09-18 삼성전자 주식회사 전자 장치로부터 호스트 장치로 보호 문서의 전송을 가능하게 하기 위한 방법 및 시스템
US8806190B1 (en) 2010-04-19 2014-08-12 Amaani Munshi Method of transmission of encrypted documents from an email application
US8630412B2 (en) * 2010-08-25 2014-01-14 Motorola Mobility Llc Transport of partially encrypted media
US9858126B2 (en) 2010-12-16 2018-01-02 Microsoft Technology Licensing, Llc Device redirection for remote systems
KR101670723B1 (ko) * 2011-01-04 2016-11-01 삼성전자주식회사 비디오 및 오디오 통신 시스템에서 가변 길이의 전송 패킷 지원 방법 및 장치
KR20120084237A (ko) 2011-01-19 2012-07-27 삼성전자주식회사 엠엠티(ｍｍｔ)에서 엠엠티 인캡슐레이터를 전송하는 방법
US8666985B2 (en) 2011-03-16 2014-03-04 Solera Networks, Inc. Hardware accelerated application-based pattern matching for real time classification and recording of network traffic
KR20120138604A (ko) * 2011-06-14 2012-12-26 삼성전자주식회사 멀티미디어 시스템에서 복합 미디어 컨텐츠를 송수신하는 방법 및 장치
EP2608558A1 (en) * 2011-12-22 2013-06-26 Thomson Licensing System and method for adaptive streaming in a multipath environment
US8744078B2 (en) * 2012-06-05 2014-06-03 Secure Channels Sa System and method for securing multiple data segments having different lengths using pattern keys having multiple different strengths
US20130329607A1 (en) * 2012-06-07 2013-12-12 Infinet Financial Systems Trading room voice routing solution
KR102056438B1 (ko) 2012-10-12 2019-12-16 삼성전자주식회사 복합 멀티미디어 데이터를 전송하기 위한 데이터 패킷을 송수신하는 방법 및 장치
JP5641090B2 (ja) * 2013-03-14 2014-12-17 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
US9723305B2 (en) 2013-03-29 2017-08-01 Qualcomm Incorporated RTP payload format designs
KR101484843B1 (ko) * 2013-04-19 2015-01-20 삼성전자주식회사 멀티미디어 전송 시스템에서 미디어 전송 패킷 전송 방법 및 장치
US9350781B2 (en) * 2013-05-31 2016-05-24 Qualcomm Incorporated Single network abstraction layer unit packets with decoding order number for video coding
RU2542917C2 (ru) * 2013-07-09 2015-02-27 Общество с ограниченной ответственностью "Завод Навигационного Оборудования" СПОСОБ ОБМЕНА ДАННЫМИ С ИСПОЛЬЗОВАНИЕМ ПРОТОКОЛА stattBIN
TWI489320B (zh) 2013-10-25 2015-06-21 Utechzone Co Ltd 電子文件標記方法及裝置
US9601097B2 (en) * 2014-03-06 2017-03-21 Zivix, Llc Reliable real-time transmission of musical sound control data over wireless networks
US10045186B2 (en) * 2016-04-08 2018-08-07 Orion Labs Low energy audio streaming
US10541005B2 (en) * 2017-05-17 2020-01-21 Cypress Semiconductor Corporation Distributed and synchronized control system for environmental signals in multimedia playback
US10552114B2 (en) * 2017-05-31 2020-02-04 International Business Machines Corporation Auto-mute redundant devices in a conference room
US11546151B2 (en) * 2017-12-20 2023-01-03 Nagravision S.A. System for securing deployed security cameras
US10620904B2 (en) 2018-09-12 2020-04-14 At&T Intellectual Property I, L.P. Network broadcasting for selective presentation of audio content
WO2023022578A1 (ko) * 2021-08-20 2023-02-23 엘지전자 주식회사 영상 신호 처리 방법 및 장치

Family Cites Families (86)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5224166A (en) 1992-08-11 1993-06-29 International Business Machines Corporation System for seamless processing of encrypted and non-encrypted data and instructions
DE69532987T2 (de) 1994-07-28 2005-04-07 Koninklijke Philips Electronics N.V. Verfahren und anordnung zur nachrichtenübertragung
US6473903B2 (en) 1996-12-30 2002-10-29 Koninklijke Philips Electronics N.V. Method and system for implementing interactive broadcast programs and commercials
US6205140B1 (en) * 1997-12-01 2001-03-20 Intel Corporation Communication of dynamic dependencies along media streams
US6134243A (en) * 1998-01-15 2000-10-17 Apple Computer, Inc. Method and apparatus for media data transmission
EP1106008A1 (en) 1998-08-20 2001-06-13 Nokia Corporation Method and apparatus for providing user multiplexing in a real-time protocol
KR100322015B1 (ko) * 1998-12-23 2002-03-08 윤종용 근거리 통신망에서 프레임 구조 가변방법
US7010032B1 (en) * 1999-03-12 2006-03-07 Kabushiki Kaisha Toshiba Moving image coding apparatus and decoding apparatus
US6278478B1 (en) 1999-03-18 2001-08-21 Microsoft Corporation End-to-end network encoding architecture
US6944296B1 (en) 1999-03-24 2005-09-13 Intel Corporation Video bit scrambling
JP3816689B2 (ja) * 1999-03-31 2006-08-30 株式会社東芝 情報配信装置、情報受信装置及び通信方法
DE60031063T2 (de) * 1999-04-20 2007-05-03 Koninklijke Philips Electronics N.V. Vorverarbeitungsverfahren zum anpassen von mpeg-4 datenströmen an das internetnetzwerk
US6918034B1 (en) * 1999-09-29 2005-07-12 Nokia, Corporation Method and apparatus to provide encryption and authentication of a mini-packet in a multiplexed RTP payload
RU2159507C1 (ru) 1999-10-29 2000-11-20 Аликов Сергей Владимирович Узел кодирования и/или декодирования информации, система передачи информации с уплотнением каналов, система передачи информации в телекоммуникационной сети
US6654389B1 (en) 1999-11-23 2003-11-25 International Business Machines Corporation System and method for searching patterns in real-time over a shared media
CN1182479C (zh) 2000-01-07 2004-12-29 国际商业机器公司 有效地收集、整理和访问证书吊销表的系统和方法
US7159235B2 (en) 2000-01-28 2007-01-02 Sedna Patent Services, Llc Method and apparatus for content distribution via non-homogeneous access networks
US6700895B1 (en) * 2000-03-15 2004-03-02 3Com Corporation Method and system for computationally efficient calculation of frame loss rates over an array of virtual buffers
US7257641B1 (en) 2000-03-30 2007-08-14 Microsoft Corporation Multipoint processing unit
AU6985601A (en) 2000-06-16 2002-01-02 Mindport Usa Methods and systems to distribute content via a network utilizing distributed conditional access agents and secure agents, and to perform digital rights management (drm)
US6965646B1 (en) * 2000-06-28 2005-11-15 Cisco Technology, Inc. MPEG file format optimization for streaming
US20060130104A1 (en) 2000-06-28 2006-06-15 Madhukar Budagavi Network video method
US7036011B2 (en) * 2000-06-29 2006-04-25 Cachestream Corporation Digital rights management
US7136577B1 (en) * 2000-06-29 2006-11-14 Tandberg Telecom As RTP-formated media clips
JP2002044135A (ja) * 2000-07-25 2002-02-08 Mitsubishi Electric Corp 暗号装置及び暗号通信システム
US7689510B2 (en) 2000-09-07 2010-03-30 Sonic Solutions Methods and system for use in network management of content
KR20020032803A (ko) * 2000-10-27 2002-05-04 구자홍 스트리밍 서비스를 위한 파일 구조
DE10054940B4 (de) 2000-11-06 2005-06-02 Siemens Ag Verfahren zum Übertragen von Faxdaten über ein Paketübertragungsnetz, zugehörige Einheiten und zugehöriges Programm
EP1348287B1 (en) * 2000-12-18 2006-06-07 Koninklijke Philips Electronics N.V. Pointers to encrypted data in rtp header
EP1356653B1 (en) * 2001-01-24 2011-07-20 Broadcom Corporation Method for processing multiple security policies applied to a data packet structure
JP3819729B2 (ja) * 2001-04-20 2006-09-13 株式会社エヌ・ティ・ティ・ドコモ データ安全化通信装置及びその方法
US20060167985A1 (en) 2001-04-26 2006-07-27 Albanese Michael J Network-distributed data routing
US20030041257A1 (en) 2001-05-04 2003-02-27 Wee Susie J. Systems, methods and storage devices for scalable data streaming
US6983049B2 (en) * 2001-05-04 2006-01-03 Hewlett-Packard Development Company, Lp. Storage devices for secure scalable data streaming
US7145919B2 (en) * 2001-06-01 2006-12-05 Telefonaktienbolaget Lm Ericsson (Publ) Method and apparatus for transporting different classes of data bits in a payload over a radio interface
US6745364B2 (en) * 2001-06-28 2004-06-01 Microsoft Corporation Negotiated/dynamic error correction for streamed media
US7362707B2 (en) 2001-07-23 2008-04-22 Acme Packet, Inc. System and method for determining flow quality statistics for real-time transport protocol data flows
US7260215B2 (en) * 2001-09-04 2007-08-21 Portauthority Technologies Inc. Method for encryption in an un-trusted environment
FI20011871A (fi) * 2001-09-24 2003-03-25 Nokia Corp Multimediadatan prosessointi
JP3719180B2 (ja) 2001-09-27 2005-11-24 ソニー株式会社 通信方法、通信システム及び出力機器
JP2003152544A (ja) * 2001-11-12 2003-05-23 Sony Corp データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
US7243366B2 (en) 2001-11-15 2007-07-10 General Instrument Corporation Key management protocol and authentication system for secure internet protocol rights management architecture
JP2003169090A (ja) 2001-11-30 2003-06-13 Fujitsu Ltd 伝送システム
DE60233822D1 (de) 2001-12-11 2009-11-05 Ericsson Telefon Ab L M Methode des rechtmanagements für strömende media
US7242773B2 (en) 2002-09-09 2007-07-10 Sony Corporation Multiple partial encryption using retuning
JP2003229843A (ja) 2002-01-31 2003-08-15 Sony Corp ストリーミングシステム及びストリーミング方法、クライアント端末及びコンテンツデータ復号方法、ストリームサーバ及びストリーム配信方法、オーサリング装置及びオーサリング方法、並びにプログラム及び記録媒体
US7233587B2 (en) 2002-02-01 2007-06-19 Harris Corporation Method and system for encapsulating time division multiplex data into individual packets of a packet based network
US7080043B2 (en) 2002-03-26 2006-07-18 Microsoft Corporation Content revocation and license modification in a digital rights management (DRM) system on a computing device
WO2003083627A2 (en) 2002-03-28 2003-10-09 Koninklijke Philips Electronics N.V. Revocation of copyrighted content
JP3818504B2 (ja) 2002-04-15 2006-09-06 ソニー株式会社 情報処理装置および方法、並びにプログラム
CN1148931C (zh) * 2002-09-29 2004-05-05 清华大学 基于实时传输协议和传输控制协议的流媒体传输实现方法
US20040249759A1 (en) 2002-09-30 2004-12-09 Akio Higashi Content using apparatus
JP3821086B2 (ja) 2002-11-01 2006-09-13 ソニー株式会社 ストリーミングシステム及びストリーミング方法、クライアント端末及びデータ復号方法、並びにプログラム
GB0230301D0 (en) 2002-12-30 2003-02-05 Nokia Corp Streaming media
US7536418B2 (en) 2003-01-10 2009-05-19 At&T Intellectual Property Ii, Lp Preload library for transparent file transformation
US7383586B2 (en) * 2003-01-17 2008-06-03 Microsoft Corporation File system operation and digital rights management (DRM)
US7136945B2 (en) 2003-03-31 2006-11-14 Sony Corporation Method and apparatus for extending protected content access with peer to peer applications
US7346160B2 (en) 2003-04-23 2008-03-18 Michaelsen David L Randomization-based encryption apparatus and method
CN1781067A (zh) 2003-04-28 2006-05-31 皇家飞利浦电子股份有限公司 存储撤销列表的方法
US20050008240A1 (en) 2003-05-02 2005-01-13 Ashish Banerji Stitching of video for continuous presence multipoint video conferencing
US20050002402A1 (en) 2003-05-19 2005-01-06 Sony Corporation And Sony Electronics Inc. Real-time transport protocol
US7483532B2 (en) 2003-07-03 2009-01-27 Microsoft Corporation RTP payload format
US7852919B2 (en) 2003-09-07 2010-12-14 Microsoft Corporation Field start code for entry point frames with predicted first field
US8582659B2 (en) 2003-09-07 2013-11-12 Microsoft Corporation Determining a decoding time stamp from buffer fullness
JP4114605B2 (ja) 2003-12-24 2008-07-09 ソニー株式会社 情報処理装置、情報記録媒体、および情報処理方法、並びにコンピュータ・プログラム
US7567584B2 (en) 2004-01-15 2009-07-28 Panasonic Corporation Multiplex scheme conversion apparatus
JP2005204001A (ja) 2004-01-15 2005-07-28 Hitachi Ltd データ配信サーバ、ソフトウェア、及びシステム
US7447158B2 (en) * 2004-01-28 2008-11-04 Empirix Inc. System and method for testing signals within digital-network packets
US7522712B2 (en) 2004-01-29 2009-04-21 Comverse Ltd. Method for initiating a session in a store and forward messaging system
CN101099142B (zh) 2004-03-03 2010-10-06 分组视频网络技术方案有限公司 用来从网络节点获取数字多媒体内容的系统和方法
US20060184790A1 (en) 2004-03-26 2006-08-17 Microsoft Corporation Protecting elementary stream content
JP4561146B2 (ja) 2004-03-29 2010-10-13 ソニー株式会社 コンテンツ流通システム、暗号化装置、暗号化方法、情報処理プログラム、及び記憶媒体
US20050254526A1 (en) 2004-05-12 2005-11-17 Nokia Corporation Parameter sets update in streaming applications
US7477749B2 (en) 2004-05-12 2009-01-13 Nokia Corporation Integrity protection of streamed content
KR101148701B1 (ko) 2004-08-31 2012-05-23 파나소닉 주식회사 동화상 부호화 방법 및 장치
US8150232B2 (en) 2004-09-03 2012-04-03 Panasonic Corporation Recording medium, recording device, program, and recording method
US8291448B2 (en) 2004-09-15 2012-10-16 Nokia Corporation Providing zapping streams to broadcast receivers
WO2006038716A1 (en) 2004-10-07 2006-04-13 Matsushita Electric Industrial Co., Ltd. Picture coding apparatus and picture decoding apparatus
US20060104356A1 (en) 2004-11-15 2006-05-18 Microsoft Corporation Timing for decoder buffer examination
CA2593247A1 (en) 2005-01-10 2006-11-16 Quartics, Inc. Integrated architecture for the unified processing of visual media
WO2006085844A1 (en) 2005-01-31 2006-08-17 Thomson Licensing Personal monitoring and information apparatus
US7656835B2 (en) 2005-05-18 2010-02-02 Nokia Corporation Method for informing changed communications capabilities
US7584497B2 (en) 2005-05-24 2009-09-01 Microsoft Corporation Strategies for scheduling bandwidth-consuming media events
US20060291475A1 (en) 2005-06-28 2006-12-28 Noam Cohen Selective forward error correction
US7577258B2 (en) 2005-06-30 2009-08-18 Intel Corporation Apparatus and method for group session key and establishment using a certified migration key
US7725593B2 (en) 2005-07-15 2010-05-25 Sony Corporation Scalable video coding (SVC) file format

Also Published As

Publication number Publication date
IL199658A0 (en) 2010-04-15
US20050002525A1 (en) 2005-01-06
IL162304A (en) 2011-02-28
CA2786809C (en) 2014-12-09
MY146788A (en) 2012-09-28
IL162304A0 (en) 2005-11-20
AU2004202538A1 (en) 2005-01-20
RU2004120267A (ru) 2006-01-10
CO5600215A1 (es) 2006-01-31
EP1494425B1 (en) 2016-11-23
SG129298A1 (en) 2007-02-26
RU2372646C2 (ru) 2009-11-10
NZ543135A (en) 2007-06-29
CA2469830C (en) 2013-12-24
CN1578311A (zh) 2005-02-09
US7483532B2 (en) 2009-01-27
KR101022894B1 (ko) 2011-03-16
US20090135849A1 (en) 2009-05-28
MY144841A (en) 2011-11-30
US7876896B2 (en) 2011-01-25
BRPI0402436A (pt) 2005-05-24
MY152016A (en) 2014-08-15
KR101026565B1 (ko) 2011-03-31
CA2469830A1 (en) 2005-01-03
TW200503485A (en) 2005-01-16
TWI347106B (en) 2011-08-11
KR20110013561A (ko) 2011-02-09
KR20050004128A (ko) 2005-01-12
CA2786809A1 (en) 2005-01-03
CN1578311B (zh) 2011-04-13
NO339940B1 (no) 2017-02-20
ZA200404701B (en) 2005-04-26
EP1494425A1 (en) 2005-01-05
NO20042821L (no) 2005-01-04
JP4504749B2 (ja) 2010-07-14
JP2005027325A (ja) 2005-01-27
AU2004202538B2 (en) 2009-12-03
NZ533297A (en) 2005-12-23
IL199658A (en) 2011-12-29

Similar Documents

Publication Publication Date Title
MXPA04006449A (es) Formato de carga de protocolo de transporte en tiempo real (rtp).
EP1611726B1 (en) Methods and apparatus for secure and adaptive delivery of multimedia content
EP1678586B1 (en) A method and apparatus for ensuring the integrity of data
US7581094B1 (en) Cryptographic checksums enabling data manipulation and transcoding
EP1741035B1 (en) Session description message extensions
US20060184790A1 (en) Protecting elementary stream content
US20060036551A1 (en) Protecting elementary stream content
JP2005513839A (ja) ディジタルコンテンツ配信システム
Downs et al. RFC 6597: RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data

Legal Events

Date Code Title Description
FG Grant or registration