ES2342357T3 - Transmision y recepcion de material de audio y/o video. - Google Patents

Transmision y recepcion de material de audio y/o video. Download PDF

Info

Publication number
ES2342357T3
ES2342357T3 ES01271007T ES01271007T ES2342357T3 ES 2342357 T3 ES2342357 T3 ES 2342357T3 ES 01271007 T ES01271007 T ES 01271007T ES 01271007 T ES01271007 T ES 01271007T ES 2342357 T3 ES2342357 T3 ES 2342357T3
Authority
ES
Spain
Prior art keywords
file
files
request
station
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES01271007T
Other languages
English (en)
Inventor
Anthony Richard Leaning
Richard James Whiting
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
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
Priority claimed from GBGB0030706.6A external-priority patent/GB0030706D0/en
Priority claimed from GB0108094A external-priority patent/GB0108094D0/en
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Application granted granted Critical
Publication of ES2342357T3 publication Critical patent/ES2342357T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • 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
    • H04L65/1106—Call signalling protocols; H.323 and related
    • 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/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • 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/23424—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for inserting or substituting an advertisement
    • 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/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • 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/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234354—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering signal-to-noise ratio parameters, e.g. requantization
    • 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/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/439—Processing of audio elementary streams
    • H04N21/4392—Processing of audio elementary streams involving audio buffer management
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44016—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for substituting a video clip
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440227—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by decomposing into layers, e.g. base layer and one or more enhancement layers
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless 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/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/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/637—Control signals issued by the client directed to the server or network components
    • H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • 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/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8106—Monomedia components thereof involving special audio data, e.g. different tracks for different languages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Human Computer Interaction (AREA)
  • Computer Graphics (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Cosmetics (AREA)
  • Compositions Of Macromolecular Compounds (AREA)

Abstract

Terminal (3) para reproducir material de audio o vídeo que está almacenado en un servidor remoto en forma de un conjunto de archivos que representan porciones temporales sucesivas de dicho material, comprendiendo el terminal (3): una interfaz (35) de telecomunicaciones para la comunicación con el servidor (1); una memoria intermedia (39) para recibir los archivos de la interfaz de telecomunicaciones; unos medios (30) para reproducir el contenido de la memoria intermedia; y unos medios (30) de control que se pueden hacer funcionar para determinar las direcciones de archivos adicionales que se deben solicitar y que se pueden hacer funcionar en respuesta al estado de compleción de la memoria intermedia con el fin de generar mensajes de solicitud para archivos adicionales para rellenar la memoria intermedia, conteniendo dichos mensajes de solicitud dichas direcciones; caracterizado porque a los archivos se les asignan dichas direcciones según un algoritmo predeterminado y el terminal incluye unos medios que se pueden hacer funcionar para calcular, según dicho algoritmo y con respecto a cada uno de una pluralidad de dichos mensajes de solicitud para archivos adicionales, una dirección para su inclusión en cada uno de dichos mensajes de solicitud.

Description

Transmisión y recepción de material de audio y/o vídeo.
La presente invención se refiere a la distribución, a través de un enlace de telecomunicaciones, de material codificado digitalmente para su presentación a un usuario.
En sistemas conocidos de este tipo, un servidor especial - al que con frecuencia se le denomina "transmisor de flujo continuo" (en inglés "streamer"), controla la distribución de material a un terminal de usuario. Frecuentemente, en el servidor, un elemento de material a transmitir se almacena en forma de un único archivo; no obstante, el documento US-A-5 610 841 describe un servidor de vídeo que almacena el material segmentado en "archivos de segmentos de medios". Se describe otro sistema de este tipo en la solicitud de patente europea publicada EP-A-669 587, en la que se produce una adaptación a la congestión de la red mediante la monitorización, por parte del terminal, del contenido de su memoria intermedia de recepción y, cuando procede, solicitando al servidor que ajuste su velocidad de datos de vídeo.
El documento US-A-5.610.841 describe un servidor mediante el cual flujos continuos de vídeo se dividen en un conjunto de archivos. Se almacena un conjunto de archivos que forman un programa, junto con datos (punteros) utilizados para convertir dicho conjunto de archivos en los datos de vídeo de un programa. El servidor tiene también intermediarios de control de secuencias, que son responsables de la transmisión de solicitudes de programa y de punteros, y de la recepción del conjunto de archivos. Los intermediarios de control de secuencias están en conexión con el terminal del abonado.
El documento WO-A-9934291 divide también un flujo continuo de vídeo en un conjunto de archivos, almacenados de una manera distribuida en varios servidores: un cliente consulta un catálogo para determinar las direcciones de los archivos que necesita.
Según un aspecto de la invención, se proporciona un terminal para reproducir material de audio o vídeo, tal como se define en la reivindicación 1.
En otro aspecto, la invención proporciona un método de transmisión de material de audio o vídeo codificado digitalmente, tal como se define en la reivindicación 14.
En las reivindicaciones subordinadas se exponen otros aspectos, opcionales, de la invención.
A continuación, se describirán algunas formas de realización de la presente invención, haciendo referencia a los dibujos adjuntos, en los cuales;
la Figura 1 es un diagrama que ilustra la arquitectura global de los sistemas a describir;
la Figura 2 es un diagrama de bloques de un terminal para ser utilizado en un sistema de este tipo;
la Figura 3 muestra el contenido de un archivo de índice típico;
la Figura 4 es un diagrama de temporización que ilustra un método modificado de generación de archivos secundarios; y
la Figura 5 es un diagrama que ilustra una arquitectura modificada.
El sistema mostrado en la Figura 1 tiene como objetivo la distribución, a un usuario, de señales de audio codificadas digitalmente (por ejemplo, de música o voz grabada) a través de una red de telecomunicaciones hacia un terminal de usuario en el que los sonidos correspondientes se reproducirán para el usuario. No obstante, tal como se describirá de forma más detallada posteriormente, el sistema se puede utilizar para transportar señales de vídeo en lugar, o además, de señales de audio. En este ejemplo, la red es internet u otra red por paquetes que funcione según el Protocolo de Transferencia de Hipertexto (véanse las RFCs 1945/2068 para obtener detalles), aunque, en principio, se pueden utilizar otros enlaces o redes digitales. Se supone también que las señales de audio se han grabado de forma comprimida usando la norma ISO MPEG-1 Capa III (la "norma MP3"); no obstante, la utilización de este formato en particular no es esencial. De hecho, tampoco es necesario que se haga uso de la compresión, aunque naturalmente la misma es altamente deseable, especialmente si la velocidad de bits disponible está restringida o el espacio de almacenamiento está limitado. En la Figura 1, un servidor 1 está conectado a través de internet 2 a terminales 3 de usuario, mostrándose únicamente uno de ellos. La función del servidor 1 es almacenar archivos de datos, para recibir desde un terminal de usuario una solicitud de distribución de un archivo de datos deseado y, en respuesta a dicha solicitud, transmitir el archivo al terminal de usuario a través de la red. Habitualmente, una solicitud de este tipo adopta la forma de una primera parte que indica al mecanismo de distribución de red (por ejemplo, http:// o archivo:// para el protocolo de transferencia de hipertexto o el protocolo de transferencia de archivos respectivamente) seguido por la dirección de red del servidor (por ejemplo, www.servidor1.com) a lo cual se le añade como sufijo el nombre del archivo que se está solicitando. Obsérvese que, en los ejemplos proporcionados, dichos nombres se muestran, por razones tipográficas, con el "//" sustituido por el "\\".
En estos ejemplos, se supone la utilización del protocolo de transferencia de hipertexto; esto no es esencial, aunque resulta ventajoso al permitir la utilización de las características de autenticación y seguridad (tales como la Capa de Conexión Seguridad) proporcionadas por ese protocolo.
Convencionalmente, un servidor para la distribución de archivos MP3 adopta la forma de un denominado transmisor de flujo continuo, que incluye disposiciones de procesado para el control dinámico de la velocidad a la que se transmiten datos dependiendo de los requisitos de reproducción en el terminal de usuario, para el enmascaramiento de errores debidos a la pérdida de paquetes y, si se permite interacción del usuario, el control del flujo de datos entre el servidor y el cliente; no obstante, en este caso no es necesario que el servidor 1 contenga dicha prestación. De este modo, el mismo es simplemente un "servidor web" común.
A continuación, se explicará la manera en la que se almacenan los archivos de datos en el servidor 1. Supóngase que se ha creado un archivo de formato MP3 y que el mismo se va a almacenar en el servidor. Supóngase que el mismo es una grabación de la Tocata y Fuga en Re menor de J. S. Bach (BWV565), que típicamente tiene un tiempo de reproducción de 9 minutos. Originalmente, dicha grabación se habría creado como un único archivo de datos, y en un transmisor de flujo continuo convencional se almacenaría en forma de este archivo único. No obstante, en este caso, el archivo se divide en archivos más pequeños antes de almacenarlo en el servidor 1. Se prefiere que cada uno de estos archivos más pequeños tenga un tamaño correspondiente a un tiempo de reproducción fijo, quizás cuatro segundos. Con un formato comprimido tal como el MP3, esto puede significar que los archivos tendrán tamaños diferentes en términos del número de bits que realmente contienen. De este modo, el archivo de Bach de 9 minutos de duración se dividiría en 135 archivos más pequeños que representarían cada uno de ellos un tiempo de reproducción de cuatro segundos. En este ejemplo, a los mismos se les asignan nombres de archivo que incluyen un número de serie indicativo de su secuencia en el archivo original, por ejemplo:
000000.bin
000001.bin
000002.bin
000003.bin
000134.bin
\vskip1.000000\baselineskip
La partición del archivo en estos archivos secundarios más pequeños puede ser realizada típicamente por la persona que prepara el archivo para su carga en el servidor web 1. (La expresión "archivos secundarios" se usa en el presente documento para diferenciarla con respecto al archivo original que contiene la grabación completa: no obstante, debería resaltarse que, por lo que al servidor se refiere, cada "archivo secundario" es simplemente un archivo como cualquier otro). La manera precisa de su creación se describirá de forma más detallada posteriormente. Una vez creados, estos archivos secundarios se cargan en el servidor de una manera convencional exactamente igual que cualquier otro archivo que se cargue a un servidor web. Evidentemente, el nombre de archivo también podría contener caracteres que identifiquen la grabación particular (el archivo secundario también se podría "etiquetar" con información adicional - cuando se reproduce un archivo MP3 se obtiene información sobre el autor, derechos de autor, etcétera), aunque, en este ejemplo, los archivos secundarios se almacenan en el servidor en un directorio o carpeta específicos de la grabación en particular - por ejemplo, mp3_bwv565. De este modo, cuando se requiera, un archivo secundario se puede solicitar en la forma:
http:\\www.servidor1.com/mp3_bwv565/000003.bin
en donde "www.servidor1.com" es el URL del servidor 1.
\vskip1.000000\baselineskip
Es también conveniente que la persona que prepara los archivos secundarios para su carga en el servidor cree, para cada grabación, una página de enlace (típicamente en formato html) que se almacena también en el servidor (tal vez con el nombre de archivo mp3_bwv565/enlace.htm), cuyas estructura y finalidad se describirán posteriormente.
Es también conveniente que el servidor web almacene una o más páginas (html) de menú (por ejemplo, menú.htm) que contengan una lista de grabaciones disponibles, con hiperenlaces a las páginas de enlace correspondientes.
Volviendo a continuación al terminal, el mismo puede adoptar típicamente la forma de un ordenador de sobremesa convencional, aunque con software adicional para gestionar la recepción de los archivos de audio descritos. Si se desea, el terminal podría adoptar la forma de un ordenador portátil, o incluso podría incorporarse a un teléfono móvil. De este modo, la Figura 2 muestra un terminal de este tipo con un procesador central 30, una memoria 31, unos medios 32 de almacenamiento de disco, un teclado 33, una pantalla 34 de vídeo, una interfaz 35 de comunicaciones, y una interfaz 36 de audio ("tarjeta de sonido"). Para la distribución de vídeo, en lugar, o además, de la tarjeta 36 se montaría una tarjeta de vídeo. En los medios de almacenamiento de disco hay programas que se pueden recuperar hacia la memoria 31 para su ejecución por parte del procesador 30, según la manera habitual. Estos programas incluyen un programa 37 de comunicaciones para acceder a y visualizar páginas html - es decir, un programa "navegador web" tal como el Navigator de Netscape o el Explorer de Microsoft, y un programa adicional 38 al que se hará referencia en el presente documento como "programa reproductor", que proporciona la funcionalidad necesaria para la reproducción de archivos de audio según esta forma de realización de la invención. Se muestra también una zona 39 de la memoria 31, que se asigna como memoria intermedia. La misma es una memoria intermedia de audio decodificado que contiene datos a la espera de ser reproducidos (típicamente, el tiempo de reproducción de la memoria intermedia podría ser 10 segundos). La interfaz de audio o tarjeta 36 de sonido puede ser una tarjeta convencional y simplemente sirve para recibir audio PCM y convertirlo en una señal de audio analógica, por ejemplo, para su reproducción a través de un altavoz. En primer lugar, se ofrecerá una breve visión general del funcionamiento del terminal para la recuperación y reproducción de la grabación deseada cuando se usa el HTTP y un cliente integrado o "enchufable".
1.
El usuario utiliza el navegador para recuperar y visualizar la página de menú menú.htm del servidor 1.
2.
El usuario selecciona uno de los hiperenlaces dentro de la página de menú lo cual provoca que el navegador recupere del servidor, y visualice, la página de enlace para la grabación deseada - en este ejemplo, el archivo mp3_bwv565_enlace.htm. La visualización concreta de esta página no es importante (excepto que la misma tal vez puede contener un mensaje para garantizarle al usuario que el sistema está funcionando correctamente). Lo que es importante sobre esta página es que contiene una orden (o "etiqueta integrada") para invocar en el procesador 30 un proceso secundario en el que se ejecuta el programa reproductor 37. La invocación de un proceso secundario de esta manera es una práctica bien conocida (dicho proceso se conoce en los sistemas de Netscape como "enchufable" y en los sistemas de Microsoft como "ActiveX"). Dichas órdenes también pueden contener parámetros que se trasladarán al proceso secundario y, en el sistema de la Figura 1, la orden contiene el URL del servidor de la grabación, que, para la pieza de Bach, sería http:\\www.servidor1.com/mp3_bwv565.
3.
El programa reproductor 37 incluye un decodificador de MP3, cuyo funcionamiento en sí mismo es convencional. En el presente contexto tienen más interés las funciones de control del programa, que son las siguientes.
4.
El programa reproductor, tras haber recibido el URL, añade al mismo el nombre de archivo del primer archivo secundario, para producir una dirección completa para el archivo secundario - es decir, \underbar{www.servidor1.com/mp3\_bwv565/000000.bin}. Se observará que este sistema se organiza basándose en que los archivos secundarios se nombren de la manera antes indicada, de manera que no es necesario informar al terminal sobre los nombres de archivo. El programa construye un mensaje de solicitud para el archivo que tiene este URL y lo transmite hacia el servidor 1 a través de la interfaz 35 de comunicaciones e internet 2. (Los procesos para traducir el URL en una dirección IP y para la comunicación de errores por URLs no válidos, incompletos o no disponibles son convencionales y por lo tanto no serán descritos). Se prevé que el programa reproductor envíe las solicitudes directamente a la interfaz de comunicaciones, en lugar de a través del navegador. El servidor responde transmitiendo el archivo secundario requerido.
5.
El programa reproductor determina, a partir del archivo, la codificación de audio utilizada en este archivo secundario y decodifica el archivo nuevamente a valores PCM sin procesar según la normativa pertinente (en este ejemplo MP3), tomando nota del tiempo de reproducción de este archivo secundario. En general, un archivo de audio contiene un identificador en el comienzo del archivo, el cual menciona la codificación utilizada. A continuación, los datos de audio decodificados se almacenan en la memoria intermedia 38 de audio.
6.
El programa reproductor tiene un parámetro denominado tiempo de reproducción T_{p}. En este ejemplo, el mismo se fija a 10 segundos (si se desea, se podría hacer que fuera seleccionable por el usuario). El mismo determina el grado de almacenamiento en memoria intermedia que realiza el terminal.
7.
El programa reproductor incrementa el nombre de archivo a 000001.bin y solicita, recibe, decodifica y almacena este segundo archivo secundario tal como se describe anteriormente en (4) y (5). Repite este proceso hasta que el contenido de la memoria intermedia alcanza o supera el tiempo de reproducción T_{p}. Obsérvese que en realidad no es esencial que la decodificación se produzca antes de la memoria intermedia aunque esto simplifica las cosas ya que, como el audio se decodifica nuevamente a PCM sin procesar, entonces la duración del material almacenado en memoria intermedia se conoce por lo tanto de forma explícita. El control de la memoria intermedia de audio se simplifica si cada uno de los archivos secundarios tiene el mismo tamaño de reproducción de audio.
8.
Tras haber alcanzado el umbral de reproducción T_{P}, los datos decodificados se envían desde la memoria intermedia a la interfaz 36 de audio, que reproduce el sonido a través de un altavoz (no mostrado).
9.
Mientras reproduce los sonidos tal como en el punto (8) anterior, el programa reproductor monitoriza continuamente el estado de compleción de la memoria intermedia y cada vez que el mismo cae por debajo de T_{p}, incrementa nuevamente el nombre de archivo y obtiene otro archivo secundario del servidor. Este proceso se repite hasta que se devuelve un "error de archivo no encontrado".
10.
Si, durante este proceso, la memoria intermedia se vacía, el programa reproductor simplemente deja de reproducir hasta que llegan otros datos.
\vskip1.000000\baselineskip
Se prefiere la convención para nombrar archivos secundarios utilizada en el presente documento, con una secuencia simple de números de longitud fija que comienzan con cero, ya que la misma es sencilla de implementar, aunque se puede utilizar cualquier convención para nombrarlos siempre que o bien el programa reproductor contenga (o se le envíe) el nombre del primer archivo secundario y un algoritmo que permita calcular los sucesivos, o bien, alternativamente, al programa reproductor se le envíe una lista de los nombres de archivo.
Se observará que el sistema antes descrito no le ofrece al usuario ninguna oportunidad de intervenir en el proceso de retransmisión. Tampoco ofrece ningún remedio para la posibilidad de subdesbordamiento de la memoria intermedia (debido, por ejemplo, a una congestión de la red). Por lo tanto, una segunda forma de realización, más sofisticada, de la invención, que se describirá a continuación, ofrece las siguientes características adicionales:
a)
el servidor almacena dos o más versiones de la grabación, grabadas con tasas de compresión diferentes (por ejemplo, con compresiones correspondientes a velocidades de datos (continuas) de 8, 16, 24 y 32 kbit/s respectivamente) y el programa reproductor puede conmutar automáticamente entre ellas.
b)
el programa reproductor visualiza para el usuario un panel de control con el cual el usuario puede iniciar la reproducción, hacer una pausa en la misma, reiniciarla (desde el comienzo, o desde el punto en el que se hizo la pausa), o saltar a un punto diferente de la grabación (hacia atrás o hacia delante).
\vskip1.000000\baselineskip
Obsérvese que estas características no son interdependientes, ya que se podría proporcionar un control de usuario sin conmutación de velocidad, o viceversa.
Para proporcionar conmutación de velocidad, la persona que prepara el archivo para cargarlo en el servidor prepara varios archivos fuente - codificando el mismo archivo PCM varias veces a velocidades diferentes. A continuación, realiza una partición de cada archivo fuente en archivos secundarios, tal como anteriormente. Los mismos se pueden cargar en el servidor en directorios independientes, correspondientes a la velocidad diferente, tal como la siguiente estructura de ejemplo, en la que "008k", "024k" en el nombre del directorio indica una velocidad de 8 kbit/s ó 24 kbit/s y así sucesivamente.
También crea un archivo de índice (por ejemplo, índice.htm) cuya finalidad principal es proporcionar una lista de las velocidades de datos que están disponibles.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Tabla pasa a página siguiente)
1 
\vskip1.000000\baselineskip
Obsérvese que, debido a que la longitud de un archivo secundario se corresponde, tal como se ha explicado anteriormente, con una longitud fija de tiempo, el número de archivos secundarios es el mismo para cada directorio. Los nombres de los subdirectorios comprenden la velocidad de datos en kbit/s (tres dígitos) más la letra ("k"); en este ejemplo, se añaden indicaciones de la velocidad de muestreo del audio (11,025 kHz) y una bandera de mono-estéreo, con fines relacionados con la verificación.
De este modo, el archivo de índice contendría una sentencia de la forma:
<!-Audio="024k_11_s 032k_11_s 018k_11_s 016k_11_m 008_11_m"- ->
\vskip1.000000\baselineskip
(El <!- -...- -> simplemente indica que la sentencia está integrada como un comentario en un archivo html (o se podría utilizar un simple archivo de texto)). En la Figura 3 se muestra un archivo de índice típico, en el que se incluye otra información: LFI es el número de archivo secundario más alto (es decir, hay 45 archivos secundarios) y SL es el tiempo de reproducción total (178 segundos). "Modo" indica "grabado" (como en el presente caso) o "en directo" (que se describirá posteriormente). Las otras entradas son de explicación evidente, u órdenes html normali-
zadas.
\newpage
Inicialmente, el programa reproductor comenzará solicitando, del directorio especificado en el archivo de enlace, el archivo de índice, y almacena localmente una lista de velocidades de datos disponibles para una referencia futura. (Puede solicitar explícitamente este archivo o simplemente especificar el directorio: la mayoría de servidores seleccionan por defecto índice.htm si no se especifica ningún nombre de archivo). A continuación, comienza a solicitar los archivos secundarios de audio tal como se ha descrito anteriormente, del directorio de "velocidades" mencionado en primer lugar en el archivo de índice - es decir, 024k_11_s (o el terminal podría omitir esto modificándolo a una velocidad por defecto fijada localmente para ese terminal). A partir de entonces, el proceso consiste en que el programa reproductor mide la velocidad de datos real que se está recibiendo desde el servidor, promediada durante un periodo de tiempo (por ejemplo, 30 segundos). Realiza esto temporizando cada solicitud de URL; se determina la velocidad de transferencia lograda (número de bits por segundo) entre el cliente y el servidor. La precisión de esta cifra mejora a medida que sube el número de solicitudes. El reproductor mantiene dos parámetros almacenados, que indican, respectivamente, la velocidad actual, y la velocidad medida.
Se activa el inicio de un cambio de velocidad:
a)
si la memoria intermedia se vacía en cualquier momento Y la velocidad medida es menor que la velocidad actual Y el Porcentaje Bajo de la Memoria Intermedia medido supera un Umbral de Reducción de Nivel (tal como se describe posteriormente), se reduce la velocidad actual; (la realización del cambio en un momento en el que la memoria intermedia ya está vacía resulta ventajosa ya que la tarjeta de sonido no está reproduciendo nada y puede que sea necesario reconfigurarla si ha cambiado la velocidad de muestreo del audio, la fijación de estéreo-mono o el ancho de bits (numero de bits por muestra)).
b)
si la velocidad medida supera no solamente la velocidad actual sino también la siguiente velocidad más alta durante un periodo de tiempo predeterminado (por ejemplo, 120 segundos: si se desea, este valor se podría hacer que fuese ajustable por el usuario) se aumenta la velocidad actual.
\vskip1.000000\baselineskip
El Porcentaje Bajo de la Memoria Intermedia es el porcentaje del tiempo en el que el contenido de la memoria intermedia representa menos que el 25% del tiempo de reproducción (es decir, la memoria intermedia está cerca de quedar vacía). Si el Umbral de Reducción de Nivel se fija a 0%, entonces cuando la memoria intermedia se vacía el sistema siempre se reduce de nivel cuando se cumplen las otras condiciones. La fijación del Umbral de Reducción de Nivel al 5% (este es nuestro valor por defecto preferido) significa que si la memoria intermedia se vacía pero el Porcentaje Bajo de la Memoria Intermedia medido es mayor que el 5%, el mismo no reducirá de nivel. Vaciados adicionales de la memoria intermedia provocarán evidentemente el aumento de esta velocidad medida y finalmente vaciarán de nuevo la memoria intermedia con un valor del Porcentaje Bajo de la Memoria Intermedia que supere el 5% si no se puede mantener la velocidad. La fijación del valor del 100% significa que el cliente nunca reducirá el nivel.
El cambio de velocidad real se efectúa simplemente por medio del programa reproductor que cambia la parte relevante de la dirección del archivo secundario, por ejemplo, cambiando de "008k" a "024k" para incrementar la velocidad de datos desde 8 a 24 kbit/s, y cambiando el parámetro de velocidad actual de manera que coincida. Como consecuencia, la nueva solicitud para el servidor se convierte en una solicitud de la velocidad mayor (o menor), y el archivo secundario del directorio nuevo es recibido, decodificado e introducido en la memoria intermedia. El proceso que se acaba de describir se resume en el siguiente diagrama de flujo:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Tabla pasa a página siguiente)
2
3
4
5 
\vskip1.000000\baselineskip
El control de usuario se implementa ofreciéndole al usuario en la pantalla las siguientes opciones que el mismo puede seleccionar usando el teclado u otro dispositivo de entrada tal como un ratón:
a)
Inicio: implementación de las etapas numeradas antes proporcionadas, a partir de la etapa 4. Cuando se selecciona por primera vez una grabación, el hecho de que la misma comience a reproducirse automáticamente, o que requiera una instrucción Inicio del usuario es opcional; de hecho, si se desea, la elección se puede realizar por medio de un parámetro adicional de "autorreproducción" en el archivo de enlace.
b)
Pausa: implementación mediante una instrucción para que el decodificador de MP3 suspenda la lectura de datos de la memoria intermedia;
c)
Reanudación: implementación mediante una instrucción de que el decodificador de MP3 reanude la lectura de datos de la memoria intermedia;
d)
Salto: implementación mediante la indicación, por parte del usuario, de a qué parte de la grabación desea saltar - por ejemplo, moviendo un cursor a un punto deseado en una barra visualizada que representa la duración total de la grabación; a continuación, el reproductor determina que este punto es el x % a lo largo de la barra y calcula el número del siguiente archivo secundario necesario, el cual se usa a continuación para la siguiente solicitud. En este caso, en el ejemplo de Bach con 125 archivos secundarios, una solicitud de reproducción desde un punto del 20% en la grabación daría como resultado una solicitud del archivo secundario 26º - es decir, 000025.bin. Resultará evidente que este cálculo se simplifica considerablemente si cada archivo secundario se corresponde con la misma duración fija. En el caso del salto, se prefiere suspender la decodificación y borrar la memoria intermedia de manera que la solicitud nueva se envía inmediatamente, aunque esto en realidad no es esencial.
\vskip1.000000\baselineskip
Alternativamente, al usuario se le puede presentar una lista de etiquetas o índices de texto que pueden ser seleccionados (por ejemplo, por medio de un ratón) para iniciar un salto. Esto se podría implementar de la manera siguiente:
El archivo.htm mantenido por el terminal, en memoria, contiene líneas de la forma (suponiendo que esta información está integrada en forma de comentarios dentro del documento.
<- -!Odbits: Índice ="0:01:44 Inalámbrico" - ->
siendo "Odbit:" una palabra clave que le indica al programa reproductor que el siguiente texto va a ser procesado por un programa, "Índice" indica la función que va a realizar el programa reproductor, y el texto dentro de las comillas consiste en el instante de tiempo (horas:minutos:segundos) desde el comienzo de la grabación en el que se va a iniciar la reproducción.
\vskip1.000000\baselineskip
El programa reproductor lee el archivo índice.htm y si reconoce una orden de índice, genera un mensaje ("un acontecimiento") para la página de enlace.htm que contiene órdenes (típicamente escritas en Javascript) de manera que gestione dicho acontecimiento visualizando las etiquetas en un lugar deseado sobre la página visualizada y responde a la selección de esas órdenes generando un salto (que contiene el instante de tiempo correspondiente) para el programa reproductor.
Resulta interesante describir adicionalmente el proceso de partición del archivo original en archivos secundarios. En primer lugar, debería indicarse que si (tal como en la primera versión antes descrita) no hay expectativas de que a un archivo secundario le siga otro archivo secundario que no sea aquel que viene a continuación inmediatamente en la secuencia original, entonces importa poco dónde están situados los límites entre los archivos secundarios. En ese caso, el tamaño del archivo secundario puede ser un número fijo de bits, o una longitud fija de tiempo de reproducción (o ninguno de estos valores) - la única decisión real es qué tamaño deberían tener los archivos secundarios. Cuando se prevén saltos (en el tiempo, o entre velocidades de datos diferentes) existen otras consideraciones. Cuando, tal como ocurre con muchos tipos de codificación de voz o audio (incluyendo el MP3), la señal está codificada en tramas, un archivo secundario debería contener un número completo de tramas. En el caso de la conmutación de velocidad, es altamente deseable, cuando no realmente esencial, que los límites entre archivos secundarios sean los mismos para cada velocidad, de manera que el primer archivo secundario recibido para una velocidad nueva continúe a partir del mismo punto de la grabación en el que finalizaba el último archivo secundario a la velocidad antigua. El disponer que cada archivo secundario deba representar el mismo periodo fijo de tiempo (por ejemplo, 4 segundos antes mencionados) no es la única manera de lograr esto, pero ciertamente es la más adecuada. No obstante, obsérvese que, dependiendo del sistema de codificación que se esté usando, el requisito de que un archivo secundario deba contener un número completo de tramas puede significar que la duración de reproducción de los archivos secundarios varíe ligeramente. Cabe destacar que en esta forma de realización de la invención, las velocidades de datos disponibles, aunque usan grados diferentes de cuantificación, y difieren en cuanto a si las mismas realizan la codificación en mono o estéreo, utilizan todas ellas la misma velocidad de muestreo de audio y, en consecuencia, el mismo tamaño de trama. Posteriormente se describen cuestiones que es necesario afrontar cuando se usan tamaños de trama diferentes.
En cuanto a la longitud real del archivo secundario, preferentemente se deberían evitar archivos secundarios excesivamente cortos ya que (a) crean un tráfico adicional en la red en forma de más solicitudes, y (b) en ciertos tipos de redes por paquetes - incluyendo las redes IP - resultan poco económicos por cuanto deben ser transportados mediante paquetes más pequeños de manera que la tara representada por el proceso solicitante y el encabezamiento de los paquetes es proporcionalmente mayor. Por otro lado, los archivos secundarios excesivamente grandes presentan desventajas ya que requieren una memoria intermedia mayor y provocan un retardo adicional cuando se inicia la reproducción y/o cuando se invocan saltos o cambios de velocidad. Se observa que resulta satisfactorio un tamaño de archivo secundario de entre el 30% y el 130% del tiempo de reproducción, o preferentemente en torno a la mitad del tiempo de reproducción (tal como en los ejemplos proporcionados anteriormente).
El proceso real de convertir los archivos secundarios se puede implementar por medio de un ordenador programado según los criterios descritos. Probablemente, resultará conveniente realizar esto en un ordenador independiente, desde el cual se puedan cargar hacia el servidor los archivos secundarios.
Otro perfeccionamiento que se puede agregar es realizar una sustitución por una convención más compleja para poner nombres a los archivos secundarios de manera que se incremente la seguridad consiguiendo que resulte más difícil que una persona no autorizada copie los archivos secundarios y los ofrezca en otro servidor. Un ejemplo es la generación de los nombres de archivo usando un generador de secuencias seudoaleatorias, por ejemplo, produciendo nombres de archivo de la forma:
01302546134643677534543134.bin
94543452345434533452134565.bin
\vskip1.000000\baselineskip
En este caso, el programa reproductor incluiría un generador idéntico de secuencias seudoaleatorias. El servidor envía el primer nombre de archivo, o un "valor semilla" de quizás cuatro dígitos, y a continuación el generador en el reproductor puede sincronizar su generador y generar los nombres requeridos de los archivos secundarios en la secuencia correcta.
En el ejemplo anterior de conmutación de velocidad, todas las velocidades de datos utilizadas presentaban el mismo tamaño de trama, específicamente usaban una codificación MP3 de audio PCM muestreado a 11,025 KHz y un tamaño de trama (PCM) de 1.152 muestras. Si se desea lograr una conmutación de velocidad entre grabaciones MP3 (u otras) que presentan tamaños de trama diferentes, surgen problemas debido al requisito de que un archivo secundario debería contener un número completo de tramas, ya que entonces los límites entre tramas no coinciden. Este problema se puede resolver mediante el siguiente procedimiento modificado, para crear los archivos secundarios. Debería indicarse particularmente que este procedimiento se puede utilizar en cualquier situación en la que se requiera una conmutación de velocidad, y no se limita al método particular de distribución antes descrito.
La Figura 4 muestra esquemáticamente una secuencia de muestras de audio, sobre la cual se definen segmentos sucesivos de cuatro segundos mediante marcas de límite (en la figura) B1, B2, etcétera. A 11,025 KHz, existen 44.100 muestras en cada segmento.
1.
Se codifica el audio, comenzando en el límite B1, trama a trama, para crear un archivo secundario MP3, continuando hasta que se haya codificado un número completo de tramas que tengan una duración total de por lo menos cuatro segundos. Con un tamaño de trama de 1.152 muestras, cuatro segundos se corresponden con 38,3 tramas, de modo que se codificará realmente un archivo secundario S1 que representa 39 tramas, lo cual representa una duración total de 4,075 segundos.
2.
Se codifica el audio, de la misma manera, comenzando en el límite B2.
3.
Se repite, comenzando cada vez en un límite de 4 segundos, de manera que así se genera un conjunto de archivos secundarios superpuestos para la secuencia completa de audio a codificar. Evidentemente, el último segmento (que puede ser tranquilamente menor que cuatro segundos) no tiene nada tras él, y se rellena con ceros (es decir, silencio).
\vskip1.000000\baselineskip
La codificación de las otras velocidades de datos que usan tamaños de trama diferentes se produce de la misma manera.
En el terminal, los mecanismos de control no se cambian, pero el proceso de decodificación y almacenamiento en memoria intermedia se modifica:
1.
Se recibe el archivo secundario S 1;
2.
Se decodifica el archivo secundario S1;
3.
Se escriben en la memoria intermedia únicamente los primeros cuatro segundos de las muestras de audio decodificadas (se descarta el resto);
4.
Se recibe el archivo secundario S2;
5.
Se decodifica el archivo secundario S2;
6.
Se escriben en la memoria intermedia únicamente los primeros cuatro segundos de las muestras de audio decodificadas;
7.
Se continúa con el archivo secundario S3, etcétera.
\vskip1.000000\baselineskip
De esta manera, se garantiza que los conjuntos de archivos secundarios para todas las velocidades tienen límites entre archivos secundarios, que se corresponden en los mismos puntos de la secuencia original de muestras
PCM.
De este modo, cada periodo de cuatro segundos excepto el último se "rellena", antes de la codificación, con muestras de audio del siguiente periodo de cuatro segundos para subir el tamaño del archivo secundario hasta un número completo de tramas MP3. Si se desea, las muestras de relleno se podrían tomar a partir del final del periodo de cuatro segundos anterior en lugar (o así como) del comienzo del siguiente.
Obsérvese que la norma MP3 permite (mediante un esquema conocido como "reserva de bits") que cierta información sea transferida de una trama de audio a otra. En el presente contexto, aunque esto es aceptable dentro de un archivo secundario, no es aceptable entre archivos secundarios. No obstante, como naturalmente la norma no permite dicha transferencia al final o comienzo de una grabación, este problema se resuelve fácilmente codificando cada archivo secundario por separado, como si fuera una única grabación.
Los cambios de velocidad de muestreo (y, de hecho, conmutación entre funcionamiento mono y estéreo) tienen algunas implicaciones prácticas para el funcionamiento de la interfaz 36 de audio. Muchas tarjetas de sonido convencionales, aunque son capaces de funcionar en un intervalo de valores diferentes de configuración, requieren una reconfiguración para cambiar la velocidad de muestreo, y esto provoca necesariamente una interrupción en su salida de audio. De este modo, en una modificación adicional, se propone que la tarjeta de sonido se podría hacer funcionar continuamente a la velocidad de muestreo más alta prevista. Cuando el programa reproductor está suministrando, a la memoria intermedia, datos a una velocidad de muestreo inferior, estos datos se sobremuestrean entonces a esta velocidad más alta antes o después de la memoria intermedia. De modo similar, si la tarjeta se hace funcionar siempre en modo estéreo, se pueden alimentar señales mono decodificadas en paralelo para alimentar los canales tanto izquierdo como derecho de la entrada de la tarjeta de sonido. Nuevamente, si el número de bits por muestra de la señal decodificada es menor que el esperado por la tarjeta, el número de bits se puede incrementar mediante un relleno con ceros.
Recordando que los criterios descritos anteriormente para la conmutación automática de velocidad de datos hacia abajo preveían una reducción de la velocidad únicamente en los casos de subdesbordamiento de la memoria intermedia (lo cual implica por lo tanto interrupciones en la salida), se hace observar que, con esta modificación, se puede evitar dicha interrupción, y, por lo tanto, es preferible utilizar un criterio que se anticipe al subdesbordamiento y lo evite en la mayoría de los casos. En este caso, se omitiría la primera de las tres condiciones Y antes mencionadas (a saber, que la memoria intermedia esté vacía).
Otra característica que se puede proporcionar en el contexto del sistema descrito es la presentación de información visual tal como subtítulos, o imágenes fijas (en la naturaleza de una presentación continuada de imágenes (en inglés "slide show")) para acompañar al sonido.
Esto se podría implementar de la manera siguiente:
(a)
el documento (enlace.htm) que se está visualizando contiene información de formato que especifica la posición en la que va a aparecer la información visual en la página;
\newpage
(b)
el archivo índice.htm contiene líneas de la forma (suponiendo que esta información está integrada como comentarios con el documento.
<!- -Odbits: Subtítulo = "0:1:01 Texto de subtítulo" - ->
<!- -Odbits: Imagen = "0:2:04 http://...../imagenjpg" - ->
en donde "Odbits:" es una palabra clave que le indica al programa reproductor que el siguiente texto va a ser procesado por un programa, "Subtítulo" o "Imagen" indica la función que va a realizar el programa reproductor, y el texto entre comillas consiste en el instante de tiempo (horas:minutos:segundos) a partir del comienzo de la grabación, en el que se va a iniciar la visualización correspondiente, seguido por el subtítulo real o el URL de la imagen deseada, según sea el caso.
(c)
el programa reproductor calcula el tiempo real, que es el producto del índice del archivo secundario actual y la longitud del archivo secundario, incrementado con el tiempo que se ha estado reproduciendo el archivo secundario actual.
(d)
el programa reproductor compara el tiempo real con los tiempos integrados en el archivo índice.htm y, en el caso de coincidencia, devuelve un mensaje a la página de enlace.htm (que invocó originalmente al reproductor). A un mensaje de este tipo se le hace referencia como "acontecimiento". La manera en la que la página de enlace.htm gestiona el acontecimiento queda a discreción de la persona que escribe la página de enlace.htm.
\vskip1.000000\baselineskip
Típicamente
(e)
para un subtítulo, la página de enlace.htm contiene órdenes ejecutables (típicamente escritas en JavaScript) que responden al acontecimiento mediante la lectura del texto del subtítulo del archivo índice.htm y la visualización del mismo en el lugar deseado.
(f)
para una imagen, la página de enlace.htm contiene órdenes tales que responden al acontecimiento mediante la lectura del URL de la imagen a partir del archivo índice.htm, la generación de un mensaje de solicitud para descargar el archivo de imagen que tiene ese URL y la visualización del mismo en el lugar deseado en la página. Esta descarga se podría producir en el momento que se requiera la imagen; alternativamente, al usuario se le podría ofrecer la opción de disponer de los archivos de imagen cargados previamente. Si el mismo acepta esta opción, entonces el programa reproductor, antes de cualquier reproducción de audio, descargaría todos los archivos de imagen enumerados y los almacenaría en una memoria caché local.
\vskip1.000000\baselineskip
Se puede aplicar el mismo principio a la distribución de grabaciones de vídeo, o evidentemente, grabaciones de vídeo con una pista de sonido adjunta. En la versión más sencilla, en la que existe solamente una grabación, el sistema difiere con respecto a la versión de audio solamente en que el archivo es un archivo de vídeo (por ejemplo, en formato H.261 ó MPEG) y el programa reproductor incorpora un decodificador de vídeo. La manera en la que se realiza la partición del archivo en archivos secundarios no cambia.
Tal como en el caso del audio, puede haber dos o más grabaciones que se correspondan con velocidades de datos diferentes, seleccionadas por el mecanismo de control ya descrito. Además se pueden proporcionar grabaciones adicionales correspondientes a modos de reproducción diferentes, tales como avance rápido o retroceso rápido, que pueden ser seleccionados mediante una ampliación de las capacidades de control de usuario ya descritas. Nuevamente, se puede seguir una convención sistemática para poner nombres a archivos y directorios de manera que el programa repro-
ductor puede responder -por ejemplo- a una orden de avance rápido corrigiendo la dirección del archivo secundario.
No obstante, la distribución de grabaciones de vídeo sí que presenta otras implicaciones para la partición de archivos en el caso de que se permitan la conmutación o saltos. En el caso de grabaciones en las que cada cuadro de una imagen se codifica de forma independiente, es suficiente con que un archivo secundario contenga un número completo de cuadros de una imagen. No obstante, si se está usando una compresión que conlleva técnicas de tipo intercuadro, la situación es más compleja. Algunos de estos sistemas (por ejemplo, las normas MPEG) generan una mezcla de cuadros codificados independientemente ("intracuadros") y cuadros codificados de forma predictiva; en este caso, cada archivo secundario debería comenzar preferentemente con un intracuadro.
En el caso de sistemas de codificación intercuadro tales como la norma ITU H.261, que no prevén la inclusión frecuente, regular, de intracuadros, esto no es posible. Esto es debido a que - tomando la conmutación de velocidad como ejemplo, si se fuera a solicitar el archivo secundario n de una grabación de velocidad de bits mayor seguido por el archivo secundario n+1 de una grabación de velocidad de bits menor, el primer cuadro del archivo secundario de velocidad de bits menor se habría codificado basándose en un esquema intercuadro usando el último cuadro decodificado del archivo secundario n de la grabación de velocidad menor, el cual, evidentemente, no está a disposición del terminal - tiene el último cuadro decodificado del archivo secundario n de la grabación de velocidad mayor. De este modo, se produciría un error importante de seguimiento del decodificador.
En el caso de la conmutación entre el modo de reproducción normal y de reproducción rápida, la situación en la práctica es ligeramente diferente. En la reproducción de avance rápido a, por ejemplo, cinco veces la velocidad normal, se realiza la codificación solamente cada 5º cuadro. En consecuencia, la correlación intercuadro se reduce mucho y la codificación intercuadro no resulta atractiva, de modo que en general se preferiría codificar una secuencia de reproducción rápida como intracuadros. La conmutación de normal a rápido no presenta entonces ningún problema, ya que los intracuadros se pueden decodificar sin dificultades. No obstante, cuando se vuelve a la reproducción normal, se produce nuevamente el problema de error de seguimiento ya que al terminal se le presenta entonces un cuadro codificado de forma predictiva para el cual no dispone del cuadro anterior.
En cualquiera de los casos, el problema se puede resolver usando el principio descrito en nuestra solicitud de patente internacional WO-A-9826604 (publicada en USA como patente US-A-6002440). Esto implica la codificación de una secuencia intermedia de cuadros que puentea la separación entre el último cuadro de la secuencia anterior y el primer cuadro de la secuencia nueva.
A continuación se describirá el funcionamiento de lo anterior en el contexto de una operación de avance rápido (siendo similar el retroceso rápido pero a la inversa). En este ejemplo, se supone que una secuencia de vídeo de 9 minutos se ha codificado a 96 kbit/s según la norma H.261, y nuevamente a 5 veces la velocidad normal completamente con intracuadros H.261, y que los archivos resultantes se han dividido cada uno de ellos en archivos secundarios de cuatro segundos. En este caso, cuatro segundos hace referencia a la duración de la señal de vídeo original, no al tiempo de reproducción en avance rápido. Siguiendo una convención para poner nombres similar a la utilizada anteriormente, los archivos secundarios podrían ser:
6
siendo "nombre" un nombre para identificar la grabación particular, "x1" indica velocidad normal y "x5" indica cinco veces la velocidad normal - es decir, avance rápido.
\vskip1.000000\baselineskip
Para conmutar de reproducción normal a avance rápido es solamente necesario que el programa reproductor modifique la dirección del archivo secundario de manera que apunte a la secuencia de avance rápido - por ejemplo,
Solicitar mpg_nombre/096k_x1/000055.bin
viene seguido por
Solicitar mpg_nombre/096K_x5/000056.bin
\vskip1.000000\baselineskip
Con el fin de construir las secuencias puente para conmutar de vuelta a la reproducción normal es necesario construir un archivo secundario puente para cada transición posible. Tal como se describe en nuestra solicitud de patente internacional antes mencionada, para el puente es suficiente en general con una secuencia de tres o cuatro cuadros, de modo que un método sencillo de implementación consiste en construir archivos secundarios puente de solamente 4 cuadros de duración - por ejemplo,
7
De modo que la conmutación se logra mediante una serie de solicitudes tales como:
Solicitar mpg_nombre/096k_x5/000099.bin
Solicitar mpg_nombre/096k_5>1/000099.bin
Solicitar mpg_nombre/096k_x1/000100.bin
\vskip1.000000\baselineskip
El archivo secundario puente se genera de la manera siguiente:
\bullet
Se decodifica la secuencia de avance rápido para obtener una versión decodificada del último cuadro del archivo secundario 99, (a 25 cuadros por segundo, el mismo será el cuadro 100.000 de la señal de vídeo original).
\bullet
Se decodifica la secuencia normal para obtener una versión decodificada del primer cuadro del archivo secundario 100 (es decir, el cuadro 100.001). Se vuelve a decodificar este cuadro cuatro veces usando la codificación intercuadro H.261 basándose en el cuadro decodificado 100.000 como cuadro de referencia inicial.
\bullet
De este modo, cuando el decodificador ha decodificado el archivo secundario de avance rápido, seguido por el archivo secundario puente, habrá reconstruido correctamente el cuadro 100.000 y estará preparado para decodificar los cuadros normales (x1). En relación con esto, la razón de codificar el mismo cuadro varias veces en este procedimiento es que si se hiciera simplemente una vez, esto produciría una calidad de imagen deficiente debido a las características de cuantificación del H.261.
\vskip1.000000\baselineskip
Se podría utilizar exactamente el mismo proceso para la conmutación de velocidad (aunque en este caso se requieren archivos secundarios puente en ambas direcciones). No obstante, se observará que, tal como se ha descrito, el archivo secundario puente da como resultado una congelación de la imagen durante un periodo de cuatro cuadros - es decir, (a 25 cuadros por segundo) 160 ms. En la conmutación de la reproducción rápida a la normal esto es aceptable - de hecho, probablemente, se seleccionaría el borrado de la memoria intermedia en este momento. En la conmutación de velocidad, esto puede ser o no subjetivamente aceptable. Por lo tanto, una alternativa sería construir una secuencia puente de cuatro segundos. La serie de solicitudes presentaría entonces el siguiente aspecto:
mpg_nombre/096k_x1/000099.bin
mpg_nombre/096/128_x1/000100.bin
mpg_nombre/128k_x1/000101.bin
\vskip1.000000\baselineskip
El archivo secundario puente se construiría en ese caso o bien volviendo a codificar el quinto cuadro decodificado de la secuencia decodificada de 128 kbit/s cuatro veces comenzando con el cuadro 100.000 decodificado de 96 kbit/s como cuadro de referencia, o bien codificando los primeros cuatro cuadros de la secuencia decodificada de 128 kbit/s comenzando con el cuadro 100.000 decodificado de 96 kbit/s como cuadro de referencia. En ambos casos, los restantes 96 cuadros del archivo secundario puente serían una copia del archivo secundario de 128 kbit/s.
A los archivos a distribuir se les ha hecho referencia como "grabaciones". No obstante, no es necesario que la secuencia completa de audio o vídeo deba haberse codificado -o que ni siquiera exista- antes de comenzar la distribución. De este modo, se podría proporcionar un ordenador para recibir una señal en directo, para codificarla usando el esquema de codificación seleccionado, y generar los archivos secundarios "sobre la marcha" y cargarlos al servidor, de manera que, una vez que en el servidor haya presentes unos pocos archivos secundarios, puede dar comienzo la distribución.
Una aplicación de este sistema de distribución sería para un sistema de mensajería de voz, tal como se ilustra en la Figura 5, en la que se muestran nuevamente el servidor 1, la red 2 y el terminal 3. Una interfaz 4 de mensajería de voz sirve para recibir llamadas telefónicas, por ejemplo, a través de la red pública telefónica conmutada (PSTN) 5, para grabar un mensaje, codificarlo, realizar una partición del mismo en archivos secundarios, y cargarlos al servidor 1, en el que se puede acceder a los mismos según la manera descrita anteriormente. Alternativamente, se podría proporcionar una segunda interfaz 6, que funcionase de una manera similar al terminal 3 aunque controlada de forma remota a través de la PSTN mediante un teléfono remoto 5, al cual se envían entonces las señales de audio reproducidas.
El mismo sistema se puede utilizar para una señal de audio (o vídeo) en directo. La misma sigue estando en cierto sentido "grabada" - siendo la diferencia principalmente que la distribución y la reproducción comienzan antes de que haya acabado la grabación, aunque naturalmente existe un retardo inherente ya que se debe esperar hasta que se haya grabado y cargado por lo menos un archivo secundario en el servidor 1.
El sistema puede proceder tal como se ha descrito anteriormente, y resultaría bastante satisfactorio excepto por el hecho de que la reproducción se iniciaría en el comienzo mientras que lo que deseará más probablemente el usuario es que la misma comience ya - es decir, con el archivo secundario creado más recientemente.
Con una secuencia de audio prolongada se puede seleccionar el borrar los archivos secundarios más antiguos para ahorrar espacio de almacenamiento: con una señal continua (es decir, 24 horas al día) esto será inevitable y, por otra parte, se necesitaría volver a utilizar los nombres de archivo secundario (en el prototipo de nuestro sistema utilizamos 000000.bin a 009768.bin y, a continuación, comenzamos nuevamente en 000000.bin), de manera que los archivos secundarios más antiguos se sobrescriben constantemente con los nuevos. Un método sencillo de garantizar que la distribución comience con el archivo secundario más reciente sería incluir en el archivo de índice una orden adicional que diese instrucciones al programa reproductor para comenzar solicitando el archivo secundario apropiado. No obstante, esto tiene la desventaja de que el archivo de índice se debe modificar muy frecuentemente - idealmente, cada vez que se crea un archivo secundario nuevo. Por lo tanto, se propone un método con el cual el programa reproductor explora el servidor para hallar el archivo secundario inicial, de la manera siguiente. En el archivo de índice, el parámetro Modo se fija a "en directo" con el fin de activar el programa reproductor para que invoque este método. LFI se fija para que indique el número máximo de archivos secundarios que se puede almacenar - por ejemplo, 9.768. El método conlleva las siguientes etapas y presupone (tal como es convencional) que se han determinado el tiempo y la fecha "de la última modificación" de cada archivo secundario. Cuando se usa el protocolo HTTP, esto se puede lograr usando una solicitud de CABECERA, que da como resultado no una distribución del archivo secundario solicitado sino solamente de información de encabezamiento que indica el tiempo en el que el archivo secundario se escribió en el servidor, o cero si el archivo secundario no existe. Este tiempo se representa a continuación como GetURL (ÍndiceDirecto) en donde ÍndiceDirecto es el número de secuencia del archivo secundario en cuestión. Los comentarios vienen procedidos por "//".
8
Tras haber hallado el ÍndiceDirecto es prudente hacer retroceder el Tp (tiempo de reproducción) y comenzar a realizar las solicitudes para llenar la memoria intermedia de audio a partir de ese punto. La reproducción puede comenzar de la manera normal.
Una vez que se ha finalizado realmente la grabación, si se desea el archivo de índice se puede modificar para fijar Modo a "grabado", y cualquier parámetro de longitud.
Si se desea, el programa reproductor podría realizar una comprobación periódicamente para ver si el archivo de índice ha cambiado de modo "en directo" a "grabado" y, en caso afirmativo, conmutar a la reproducción en modo "grabado".
A continuación, se describirá un método más sencillo y mucho más rápido de la identificación del "último" archivo secundario, suponiendo, en primer lugar, una única secuencia de numeración continua de archivos secundarios.
1.
El terminal emite una solicitud de CABECERA para el primer archivo secundario (por ejemplo, 000000.bin).
2.
El servidor responde enviando el encabezamiento de este archivo e incluye la fecha y el tiempo en el que se modificó por última vez el archivo (TIEMPOMOD) y la fecha y el tiempo en los que se envió esta respuesta (TIEMPORESPUESTA) (ambos son campos http. normalizados).
3.
El terminal calcula el tiempo transcurrido (TIEMPOTRANS) restando los dos (TIEMPOTRANS = TIEMPORESPUESTA - TIEMPOMOD), y divide el mismo por la duración de reproducción de un archivo secundario (en estos ejemplos 4 segundos) para obtener ÍNDICEDIRECTO = TIEMPOTRANS/4.
4.
El terminal calcula el nombre de archivo del archivo secundario que tiene este índice.
5.
El terminal emite una solicitud de CABECERA con este nombre de archivo y, si fuera necesario, cada nombre de archivo subsiguiente hasta que recibe un cero (archivo no encontrado) tras lo cual considera el último archivo secundario que se ha encontrado como el "Archivo secundario actual".
6.
El terminal comienza a solicitar archivos, empezando en el punto J1: del diagrama de flujo ofrecido anteriormente.
\vskip1.000000\baselineskip
Este método es considerablemente más rápido que el descrito anteriormente para los archivos secundarios numerados cíclicamente. Obsérvese que se pueden seguir borrando archivos secundarios más antiguos, para reducir requisitos de almacenamiento, siempre que se mantenga el archivo secundario inicial. No obstante, el método se puede modificar para aceptar la reutilización de nombres de archivo (direcciones cíclicas), aunque requeriría:
(i)
Que el nombre del archivo secundario inicial (por ejemplo, 000000.bin) no se reutilice de manera que esté siempre disponible para suministrar la información de encabezamiento en la Etapa 2. De este modo, con un reinicio de ciclo en 009768.bin, al archivo secundario 009768.bin le seguiría el archivo secundario 000001.bin.
(ii)
El ÍNDICEDIRECTO calculado en la Etapa 3 se toma como Módulo 9768 (es decir, el resto cuando TIEMPOTRANS/4 se divide por 9768).
(iii)
El borrado de archivos secundarios siempre conduce a la creación de archivos secundarios nuevos de manera que entre el archivo secundario más nuevo y el archivo secundario no borrado más antiguo faltan unos pocos nombres de archivo, de modo que en la Etapa 5 se produzca la respuesta esperada de "archivo no encontrado".
\vskip1.000000\baselineskip
Puede existir peligro de que la operación de reproducción se ejecute ligeramente más rápida o más lenta que la operación de grabación. Para protegerse contra lo primero, se puede disponer que el programa reproductor compruebe cada archivo secundario que recibe para averiguar si el mismo está marcado con un tiempo posterior que el previo: en caso negativo, el archivo secundario se descarta y se realizan solicitudes repetidas (quizás tres veces) seguidas por una comprobación del archivo de índice si estas solicitudes no son exitosas.
Si la reproducción va por detrás del proceso de grabación, esto puede ser identificado por el programa reproductor que comprueba ocasionalmente el servidor en relación con la existencia de un número significativo de archivos secundarios más recientes que aquellos que se están solicitando actualmente, y si dichos archivos secundarios existen, inicia un proceso de "igualación" - por ejemplo, descartando regularmente una pequeña cantidad de datos.

Claims (32)

1. Terminal (3) para reproducir material de audio o vídeo que está almacenado en un servidor remoto en forma de un conjunto de archivos que representan porciones temporales sucesivas de dicho material, comprendiendo el terminal (3):
una interfaz (35) de telecomunicaciones para la comunicación con el servidor (1);
una memoria intermedia (39) para recibir los archivos de la interfaz de telecomunicaciones;
unos medios (30) para reproducir el contenido de la memoria intermedia; y
unos medios (30) de control que se pueden hacer funcionar para determinar las direcciones de archivos adicionales que se deben solicitar y que se pueden hacer funcionar en respuesta al estado de compleción de la memoria intermedia con el fin de generar mensajes de solicitud para archivos adicionales para rellenar la memoria intermedia, conteniendo dichos mensajes de solicitud dichas direcciones; caracterizado porque a los archivos se les asignan dichas direcciones según un algoritmo predeterminado y el terminal incluye unos medios que se pueden hacer funcionar para calcular, según dicho algoritmo y con respecto a cada uno de una pluralidad de dichos mensajes de solicitud para archivos adicionales, una dirección para su inclusión en cada uno de dichos mensajes de solicitud.
\vskip1.000000\baselineskip
2. Terminal según la reivindicación 1, en el que cada una de las direcciones incluye un número de serie indicativo de su secuencia en el material original y el algoritmo predeterminado consiste en que el número de serie se incrementa para obtener la dirección del siguiente archivo.
3. Terminal según la reivindicación 1, en el que el algoritmo genera las direcciones de acuerdo con una clave, incluyendo la etapa de transmitir la clave hacia dicho terminal para su utilización en el cálculo de las direcciones.
4. Terminal según la reivindicación 3, en el que el algoritmo genera las direcciones de acuerdo con una secuencia seudoaleatoria.
5. Terminal según la reivindicación 4, en el que el algoritmo genera las direcciones de acuerdo con una secuencia seudoaleatoria y la clave es un valor semilla para fijar el punto inicial de la secuencia seudoaleatoria.
6. Terminal según cualquiera de las reivindicaciones anteriores, que incluye unos medios que se pueden hacer funcionar para generar una solicitud de prueba para un primer archivo, recibir del servidor una respuesta que incluye datos que representan el tiempo original del primer archivo y el tiempo de dicha respuesta, y estimar a partir de estos datos una identidad estimada del archivo más reciente en dicho servidor remoto.
7. Terminal según cualquiera de las reivindicaciones anteriores, que incluye unos medios que se pueden hacer funcionar para generar una serie de solicitudes de prueba para identificar el archivo más reciente y para iniciar la decodificación comenzando con el archivo identificado más reciente.
8. Terminal según cualquiera de las reivindicaciones anteriores, en el que dicho servidor (1) está almacenando una pluralidad de conjuntos de archivos, correspondiéndose dichos conjuntos con modos de distribución diferentes respectivos, incluyendo el terminal:
unos medios de conmutación de modo que se pueden hacer funcionar para efectuar una conmutación de modo disponiendo que mensajes de solicitud subsiguientes soliciten archivos de un conjunto diferente con respecto al conjunto con el que está relacionada la solicitud inmediatamente anterior.
\vskip1.000000\baselineskip
9. Terminal según la reivindicación 8, en el que en dicho servidor (1) por lo menos algunos de dichos conjuntos de archivos se corresponden con velocidades de datos diferentes respectivas, y
el terminal incluye unos medios para monitorizar la velocidad de datos recibida; y en el que
los medios de conmutación de modo se pueden hacer funcionar, en el caso de que la velocidad medida esté por debajo de la necesaria para el conjunto al que pertenece el archivo solicitado actualmente, para disponer que dichos mensajes de solicitud subsiguientes soliciten archivos de un conjunto correspondiente a una velocidad de datos inferior.
\newpage
10. Terminal según la reivindicación 8 ó 9, en el que, en dicho servidor (1), por lo menos algunos de dichos conjuntos de archivos se corresponden con unas velocidades de datos diferentes respectivas, y
el terminal incluye unos medios para monitorizar la velocidad de datos recibida; y en el que
los medios de conmutación de modo se pueden hacer funcionar, en el caso de que la velocidad medida sea suficiente para soportar la distribución de archivos de una velocidad de datos mayor que la del conjunto al que pertenece el archivo solicitado actualmente, para disponer que dichos mensajes de solicitud subsiguientes soliciten archivos de un conjunto correspondiente a una velocidad de datos mayor.
\vskip1.000000\baselineskip
11. Terminal según la reivindicación 8, 9 ó 10, en el que, en dicho servidor (1), por lo menos algunos de dichos conjuntos de archivos se corresponden con modos de reproducción diferentes respectivos, y
el terminal (3) incluye unos medios para recibir órdenes de un usuario del terminal para realizar dicha conmutación de modo desde un modo de reproducción actual a un modo de reproducción deseado correspondiente a esa orden; y
los medios de conmutación de modo se pueden hacer funcionar, al producirse la recepción de la orden, para disponer que dichos mensajes de solicitud subsiguientes soliciten archivos de un conjunto correspondiente a dicho modo de reproducción deseado.
\vskip1.000000\baselineskip
12. Terminal según cualquiera de las reivindicaciones 8 a 11, en el que dicho servidor (1) está almacenando dicho material en forma de grabaciones de vídeo, habiéndose codificado por lo menos algunos de dichos archivos con la utilización de, para por lo menos algunos cuadros de los mismos, una codificación intercuadro, y el terminal (3) se puede hacer funcionar, antes de generar el mensaje de solicitud para un archivo de un conjunto diferente, para generar un mensaje de solicitud para un archivo para la corrección del seguimiento del decodificador.
13. Terminal según cualquiera de las reivindicaciones anteriores para su utilización en un método según cualquiera de las reivindicaciones 24 a 27, en el que el terminal (3) se puede hacer funcionar, al producirse la recepción de un archivo, para decodificarlo y descartar la parte del material decodificado que se corresponde con la parte inicial de la siguiente porción.
14. Método de transmisión de material de audio o vídeo codificado digitalmente, que comprende:
realizar una partición del material en una pluralidad de archivos discretos que representan cada uno de ellos porciones temporales sucesivas de dicho material;
almacenar los archivos en una primera estación (1); y
en una segunda estación (3) que transmite hacia la primera estación solicitudes de archivos sucesivos de dicha pluralidad de archivos discretos; recibir cada archivo; almacenarlo en una memoria intermedia y decodificarlo para la reproducción del material;
en el que la segunda estación (3) determina las direcciones de archivos que se deben solicitar; transmite un mensaje de solicitud para cada archivo que se debe reproducir; monitoriza la compleción de la memoria intermedia y cuando la compleción de la memoria intermedia cae por debajo de un nivel predeterminado, genera mensajes de solicitud para otros de dichos archivos, conteniendo dichos mensajes de solicitud dichas direcciones;
caracterizado porque a los archivos se les asignan direcciones según un algoritmo predeterminado, incluyendo el método calcular, en la segunda estación, de acuerdo con dicho algoritmo y con respecto a cada uno de una pluralidad de dichos mensajes de solicitud para archivos adicionales, una dirección para su inclusión en dichos mensajes de solicitud para archivos adicionales.
\vskip1.000000\baselineskip
15. Método según la reivindicación 14, en el que cada una de las direcciones incluye un número de serie indicativo de su secuencia en el material original y el algoritmo predeterminado consiste en que el número de serie se incrementa para obtener la dirección del siguiente archivo.
16. Método según la reivindicación 14, en el que el algoritmo genera las direcciones de acuerdo con una clave, incluyendo la etapa de transmitir la clave hacia la segunda estación para su utilización en el cálculo de las direcciones.
17. Método según la reivindicación 16, en el que el algoritmo genera las direcciones de acuerdo con una secuencia seudoaleatoria.
18. Método según la reivindicación 17, en el que el algoritmo genera las direcciones de acuerdo con una secuencia seudoaleatoria y la clave es un valor semilla para fijar el punto inicial de la secuencia seudoaleatoria.
19. Método según cualquiera de las reivindicaciones 14 a 18, que incluye, en la segunda estación (3), generar una solicitud de prueba para un primer archivo, recibir de la primera estación (1) una respuesta que incluye datos que representan el tiempo original del primer archivo y el tiempo de dicha respuesta, y estimar a partir de estos datos una identidad estimada del archivo más reciente en la primera estación.
20. Método según cualquiera de las reivindicaciones 14 a 19, que incluye generar, en la segunda estación (3), una serie de solicitudes de prueba para identificar el archivo más reciente en la primera estación (1) e iniciar dicha decodificación comenzando con el archivo identificado más reciente.
21. Método según cualquiera de las reivindicaciones 14 a 20, que incluye almacenar una pluralidad de conjuntos de archivos, correspondiéndose dichos conjuntos con modos de distribución diferentes respectivos, e incluye, en la segunda estación (3), efectuar una conmutación de modo disponiendo que mensajes de solicitud subsiguientes soliciten archivos de un conjunto diferente con respecto al conjunto con el que está relacionada la solicitud inmediatamente anterior.
22. Método según la reivindicación 21, en el que por lo menos algunos de dichos conjuntos de archivos se corresponden con velocidades de datos diferentes respectivas, que incluye:
monitorizar la velocidad de datos recibidos en la segunda estación (3); y
en el caso de que la velocidad medida esté por debajo de la necesaria para el conjunto al cual pertenece el archivo solicitado actualmente, realizar una conmutación de modo para disponer que dichos mensajes de solicitud subsiguientes soliciten archivos de un conjunto correspondiente a una velocidad de datos inferior.
\vskip1.000000\baselineskip
23. Método según la reivindicación 21 ó 22, en el que por lo menos algunos de dichos conjuntos de archivos se corresponden con velocidades de datos diferentes respectivas, que incluye:
monitorizar la velocidad de datos recibidos en la segunda estación (3); y
en el caso de que la velocidad medida sea suficiente para soportar la distribución de archivos de una velocidad de datos mayor que la del conjunto al cual pertenece el archivo solicitado actualmente, realizar una conmutación de modo para disponer que dichos mensajes de solicitud subsiguientes soliciten archivos de un conjunto correspondiente a una velocidad de datos mayor.
\vskip1.000000\baselineskip
24. Método según la reivindicación 21, 22 ó 23, en el que por lo menos algunos de dichos conjuntos de archivos se corresponden con modos de reproducción diferentes respectivos, que incluye, en
la segunda estación (3), las etapas de recibir órdenes de un usuario de la segunda estación para realizar dicha conmutación de modo desde un modo de reproducción actual a un modo de reproducción deseado correspondiente a esa orden; y de influir en la conmutación de modo, al producirse la recepción de la orden, para disponer que dichos mensajes de solicitud subsiguientes soliciten archivos de un conjunto correspondiente a dicho modo de reproducción deseado.
\vskip1.000000\baselineskip
25. Método según cualquiera de las reivindicaciones 14 a 24, en el que dicho material es material de audio, en el que:
a)
los archivos están codificados utilizando un método de codificación de audio que presenta una estructura de tramas;
b)
la etapa de realizar la partición del material en una pluralidad de archivos discretos comprende dividir conceptualmente el material en una pluralidad de porciones temporales y generar cada uno de dichos archivos, que no sea el último, codificando una porción temporal respectiva y una parte inicial de la siguiente porción de tal manera que las porciones conjuntamente representen un número completo de tramas;
c)
después de la decodificación, se descarta la parte del material decodificado que se corresponde con dicha parte inicial de la siguiente porción.
\vskip1.000000\baselineskip
26. Método según cualquiera de las reivindicaciones 14 a 24, en el que dicho material es material de audio, en el que:
a)
los archivos se codifican usando un método de codificación de audio que tiene una estructura de tramas;
\newpage
b)
la etapa de realizar la partición del material en una pluralidad de archivos discretos comprende dividir conceptualmente el material en una pluralidad de porciones temporales y generar por lo menos algunos de dichos archivos codificando una porción temporal respectiva y una cantidad tal del final de la porción temporal inmediatamente anterior y/o el comienzo de la porción temporal inmediatamente siguiente como para constituir, con dicha una porción temporal respectiva, un número completo de tramas de dicha estructura de tramas; y
c)
después de la decodificación, se descarta la parte del material decodificado que se corresponde con dicho final de la porción temporal inmediatamente anterior y/o el comienzo de la porción temporal inmediatamente siguiente.
\vskip1.000000\baselineskip
27. Método según la reivindicación 25 ó 26, en el que dichos conjuntos comprenden un primer conjunto y un segundo conjunto para los cuales la longitud de trama para codificar el primer conjunto es diferente a la utilizada para codificar el segundo conjunto, y la división en porciones temporales es la misma para ambos conjuntos.
28. Método según la reivindicación 21 ó según cualquiera de las reivindicaciones 22 a 27, cuando están subordinadas a la reivindicación 21, en el que dicho material está en forma de grabaciones de vídeo, habiéndose codificado por lo menos algunos de dichos archivos con la utilización de, para por lo menos algunas tramas de los mismos, una codificación intercuadro, y que incluye, en la segunda estación, antes de generar el mensaje de solicitud para un archivo de un conjunto diferente, generar un mensaje de solicitud para un archivo para la corrección del seguimiento del decodificador.
29. Método según cualquiera de las reivindicaciones 14 a 28, que incluye, en la segunda estación, las etapas siguientes:
(a)
recibir de la primera estación una lista que contiene tiempos y datos que definen acciones que se deben realizar en esos tiempos;
(b)
calcular un tiempo, con respecto al comienzo del material, representado por el punto de reproducción actual;
(c)
comparar el tiempo calculado con los tiempos de la lista y, en el caso de una coincidencia generar una orden que contiene los datos respectivos para el inicio de la acción.
\vskip1.000000\baselineskip
30. Método según la reivindicación 29, en el que las acciones incluyen la visualización de un subtítulo.
31. Método según la reivindicación 29 ó 30, en el que las acciones incluyen la visualización de una imagen.
32. Método según la reivindicación 31, que incluye transmitir hacia la primera estación (1) una solicitud de imágenes identificadas por dichos datos, y almacenar las imágenes en la segunda estación (3) hasta que se requieran para su visualización.
ES01271007T 2000-12-15 2001-12-14 Transmision y recepcion de material de audio y/o video. Expired - Lifetime ES2342357T3 (es)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
GB0030706 2000-12-15
GBGB0030706.6A GB0030706D0 (en) 2000-12-15 2000-12-15 Delivery of audio and or video material
GB0108094 2001-03-30
GB0108094A GB0108094D0 (en) 2001-03-30 2001-03-30 Delivery of audio and or video material
WOGB01/05090 2001-11-19
PCT/GB2001/005090 WO2002049342A1 (en) 2000-12-15 2001-11-19 Delivery of audio and/or video material

Publications (1)

Publication Number Publication Date
ES2342357T3 true ES2342357T3 (es) 2010-07-06

Family

ID=32031868

Family Applications (1)

Application Number Title Priority Date Filing Date
ES01271007T Expired - Lifetime ES2342357T3 (es) 2000-12-15 2001-12-14 Transmision y recepcion de material de audio y/o video.

Country Status (7)

Country Link
US (1) US7447791B2 (es)
EP (1) EP2071827A3 (es)
KR (1) KR100908954B1 (es)
CN (1) CN1243442C (es)
AT (1) ATE464740T1 (es)
DE (1) DE60141850D1 (es)
ES (1) ES2342357T3 (es)

Families Citing this family (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US7085845B2 (en) * 2001-05-09 2006-08-01 Gene Fein Method, apparatus and computer program product for identifying a playing media file and tracking associated user preferences
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
EP2348640B1 (en) 2002-10-05 2020-07-15 QUALCOMM Incorporated Systematic encoding of chain reaction codes
US7536725B2 (en) * 2003-07-28 2009-05-19 Limelight Networks, Inc. Authentication of content download
US8805966B2 (en) 2003-07-28 2014-08-12 Limelight Networks, Inc. Rich content download
US7779035B2 (en) * 2003-07-28 2010-08-17 Limelight Networks, Inc. Consistent browser file download
US8122100B2 (en) * 2003-07-28 2012-02-21 Limelight Networks, Inc. Multiple object download
RU2345403C2 (ru) * 2003-10-03 2009-01-27 Лаймлайт Нетворкс, Инк. Расширенная загрузка контента
CN1954501B (zh) 2003-10-06 2010-06-16 数字方敦股份有限公司 通过通信信道接收从源发射的数据的方法
US9323571B2 (en) * 2004-02-06 2016-04-26 Intel Corporation Methods for reducing energy consumption of buffered applications using simultaneous multi-threading processor
US7418651B2 (en) 2004-05-07 2008-08-26 Digital Fountain, Inc. File download and streaming system
US20050275566A1 (en) * 2004-06-14 2005-12-15 Nokia Corporation System and method for transferring content
US7962854B2 (en) * 2004-10-19 2011-06-14 Sony Ericsson Mobile Communications Ab Systems, methods and computer program products for displaying content on multiple display screens using handheld wireless communicators
US20060083194A1 (en) * 2004-10-19 2006-04-20 Ardian Dhrimaj System and method rendering audio/image data on remote devices
US20060140162A1 (en) * 2004-12-23 2006-06-29 Yojak Vasa Alternate-location content delivery apparatus, methods and computer program products
WO2006076516A2 (en) * 2005-01-12 2006-07-20 Howard Friedman Customizable delivery of audio information
US8589508B2 (en) * 2005-04-07 2013-11-19 Opanga Networks, Inc. System and method for flow control in an adaptive file delivery system
US7738768B1 (en) 2005-12-16 2010-06-15 The Directv Group, Inc. Method and apparatus for increasing the quality of service for digital video services for mobile reception
JP5550834B2 (ja) 2006-02-13 2014-07-16 デジタル ファウンテン， インコーポレイテッド 可変ｆｅｃオーバヘッド及び保護期間を利用したストリーミング及びバッファリング
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
WO2007134196A2 (en) 2006-05-10 2007-11-22 Digital Fountain, Inc. Code generator and decoder using hybrid codes
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9386064B2 (en) * 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US9419749B2 (en) 2009-08-19 2016-08-16 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US20080062322A1 (en) * 2006-08-28 2008-03-13 Ortiva Wireless Digital video content customization
US8606966B2 (en) * 2006-08-28 2013-12-10 Allot Communications Ltd. Network adaptation of digital content
US7743161B2 (en) * 2006-10-10 2010-06-22 Ortiva Wireless, Inc. Digital content buffer for adaptive streaming
US20080120371A1 (en) * 2006-11-16 2008-05-22 Rajat Gopal Relational framework for non-real-time audio/video collaboration
US8520852B2 (en) * 2006-12-22 2013-08-27 Ibiquity Digital Corporation Method and apparatus for store and replay functions in a digital radio broadcasting receiver
AU2008298602A1 (en) 2007-09-12 2009-03-19 Digital Fountain, Inc. Generating and communicating source identification information to enable reliable communications
WO2009054907A2 (en) * 2007-10-19 2009-04-30 Swarmcast, Inc. Media playback point seeking using data range requests
US8543720B2 (en) * 2007-12-05 2013-09-24 Google Inc. Dynamic bit rate scaling
US20090150259A1 (en) * 2007-12-09 2009-06-11 Arjun Yetukuri Collection of Magazine Articles
US7979557B2 (en) * 2008-04-11 2011-07-12 Mobitv, Inc. Fast setup response prediction
US7979570B2 (en) 2008-05-12 2011-07-12 Swarmcast, Inc. Live media delivery over a packet-based computer network
WO2009155356A1 (en) 2008-06-18 2009-12-23 Onion Networks, KK Traffic and cost containment for internet access by adapting the coding rate when distributing- media content
JP5517532B2 (ja) * 2008-10-15 2014-06-11 キヤノン株式会社 画像処理装置、その制御方法、記憶媒体及びプログラム
US8996547B2 (en) * 2008-10-31 2015-03-31 Microsoft Technology Licensing, Llc Dynamic fragmentation of digital media
WO2010065757A1 (en) * 2008-12-04 2010-06-10 Swarmcast, Inc. Adaptive playback rate with look-ahead
MX2011005943A (es) 2008-12-05 2011-06-27 Abbott Lab Derivados de tieno[3,2-c]piridina como inhibidores de cinasa para utilizarse en el tratamiento de cancer.
US8474001B2 (en) * 2009-02-10 2013-06-25 Cisco Technology, Inc. Near real time delivery of variable bit rate media streams
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
WO2010141460A1 (en) * 2009-06-01 2010-12-09 Swarmcast, Inc. Data retrieval based on bandwidth cost and delay
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
CN102473159A (zh) * 2009-11-04 2012-05-23 华为技术有限公司 媒体内容流播的***和方法
BR112012001150B1 (pt) 2009-11-09 2021-06-29 Snaptrack, Inc Método para implementar serviço de transmissão baseado em http
CN102055773B (zh) * 2009-11-09 2013-10-09 华为技术有限公司 实现基于http的流媒体业务的方法、***和网络设备
CN102055789B (zh) * 2009-11-09 2013-10-09 华为技术有限公司 实现基于http的流媒体业务的方法、***和网络设备
KR101786050B1 (ko) * 2009-11-13 2017-10-16 삼성전자 주식회사 데이터 전송 방법 및 장치
KR101777347B1 (ko) * 2009-11-13 2017-09-11 삼성전자주식회사 부분화에 기초한 적응적인 스트리밍 방법 및 장치
KR101750049B1 (ko) * 2009-11-13 2017-06-22 삼성전자주식회사 적응적인 스트리밍 방법 및 장치
KR101750048B1 (ko) * 2009-11-13 2017-07-03 삼성전자주식회사 변속 재생 서비스 제공 방법 및 장치
KR101786051B1 (ko) 2009-11-13 2017-10-16 삼성전자 주식회사 데이터 제공 방법 및 장치와 데이터 수신 방법 및 장치
KR101737084B1 (ko) * 2009-12-07 2017-05-17 삼성전자주식회사 메인 콘텐트에 다른 콘텐트를 삽입하여 스트리밍하는 방법 및 장치
JP4904564B2 (ja) * 2009-12-15 2012-03-28 シャープ株式会社 コンテンツ配信システム、コンテンツ配信装置、コンテンツ再生端末およびコンテンツ配信方法
KR101777348B1 (ko) * 2010-02-23 2017-09-11 삼성전자주식회사 데이터 전송 방법 및 장치와 데이터 수신 방법 및 장치
KR20110105710A (ko) * 2010-03-19 2011-09-27 삼성전자주식회사 복수의 챕터를 포함하는 콘텐트를 적응적으로 스트리밍하는 방법 및 장치
US9225961B2 (en) 2010-05-13 2015-12-29 Qualcomm Incorporated Frame packing for asymmetric stereo video
KR101837687B1 (ko) * 2010-06-04 2018-03-12 삼성전자주식회사 콘텐트의 품질을 결정하는 복수의 인자에 기초한 적응적인 스트리밍 방법 및 장치
US9049497B2 (en) 2010-06-29 2015-06-02 Qualcomm Incorporated Signaling random access points for streaming video data
US8918533B2 (en) 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US9185439B2 (en) 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
EP2410743A1 (en) * 2010-07-23 2012-01-25 Alcatel Lucent Method for transferring video chunks, server entity, client entity and intermediate network entity realizing such a method
CN103026680A (zh) 2010-08-10 2013-04-03 瑞典爱立信有限公司 用于媒体流传输的会话控制
US8806050B2 (en) 2010-08-10 2014-08-12 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
EP2621168A4 (en) * 2010-09-20 2014-07-09 Humax Co Ltd METHOD OF PROCESSING TO BE IMPLEMENTED IN THE PRESENCE OF AN EXPRESSION SWITCH DURING CONTINUOUS HTTP TRANSMISSION
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
US8958375B2 (en) 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
US8953752B2 (en) * 2011-02-17 2015-02-10 Sonus Networks, Inc. Systems and methods for playing recorded announcements
JP2013031151A (ja) 2011-06-20 2013-02-07 Renesas Electronics Corp 暗号通信システムおよび暗号通信方法
US8436179B2 (en) 2011-07-20 2013-05-07 Abbvie Inc. Kinase inhibitor with improved solubility profile
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
US20130227106A1 (en) * 2012-02-23 2013-08-29 Edward Grinshpun Method and apparatus for video session management
KR101904053B1 (ko) 2012-03-13 2018-11-30 삼성전자 주식회사 단말장치의 멀티미디어 처리장치 및 방법
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
US9386308B2 (en) * 2013-07-16 2016-07-05 Cisco Technology, Inc. Quality optimization with buffer and horizon constraints in adaptive streaming
CN106471574B (zh) * 2014-06-30 2021-10-12 索尼公司 信息处理装置和信息处理方法
US11076187B2 (en) 2015-05-11 2021-07-27 Mediamelon, Inc. Systems and methods for performing quality based streaming
US10298985B2 (en) 2015-05-11 2019-05-21 Mediamelon, Inc. Systems and methods for performing quality based streaming
KR102321859B1 (ko) * 2016-07-21 2021-11-03 한화테크윈 주식회사 자바 스크립트를 이용한 실시간 미디어 스트리밍 방법 및 그 장치
CN106658176A (zh) * 2016-11-07 2017-05-10 广州视源电子科技股份有限公司 远程视频显示方法及***
CN111164900B (zh) * 2017-09-28 2021-08-31 英国电讯有限公司 控制关于局域网的通信的方法、设备、网关装置和存储介质
WO2019072546A1 (en) 2017-10-10 2019-04-18 British Telecommunications Public Limited Company IDENTIFICATION OF INTERFERING LINKS IN LOCAL NETWORKS
CN109862193B (zh) * 2019-04-12 2020-10-02 珠海天燕科技有限公司 一种终端中来电视频的控制方法及装置

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US595716A (en) * 1897-12-21 Process of printing on two-color lithographic presses
US5701582A (en) * 1989-08-23 1997-12-23 Delta Beta Pty. Ltd. Method and apparatus for efficient transmissions of programs
US5610841A (en) * 1993-09-30 1997-03-11 Matsushita Electric Industrial Co., Ltd. Video server
CA2140850C (en) 1994-02-24 1999-09-21 Howard Paul Katseff Networked system for display of multimedia presentations
US5608450A (en) * 1994-09-07 1997-03-04 Intel Corporation Video conferencing system with fast packet loss recovery
US6181867B1 (en) 1995-06-07 2001-01-30 Intervu, Inc. Video storage and retrieval system
US5835495A (en) * 1995-10-11 1998-11-10 Microsoft Corporation System and method for scaleable streamed audio transmission over a network
KR19990072122A (ko) 1995-12-12 1999-09-27 바자니 크레이그 에스 실시간 영상 전송 방법 및 장치
CA2196622C (en) * 1996-02-06 2001-10-16 Hiroshi Jinzenji Network data distribution system
US6065050A (en) * 1996-06-05 2000-05-16 Sun Microsystems, Inc. System and method for indexing between trick play and normal play video streams in a video delivery system
US6118790A (en) * 1996-06-19 2000-09-12 Microsoft Corporation Audio server system for an unreliable network
US5732216A (en) * 1996-10-02 1998-03-24 Internet Angles, Inc. Audio message exchange system
EP0945023B1 (en) 1996-12-10 2002-09-18 BRITISH TELECOMMUNICATIONS public limited company Video coding
US6029194A (en) * 1997-06-10 2000-02-22 Tektronix, Inc. Audio/video media server for distributed editing over networks
WO1999022563A2 (en) 1997-10-30 1999-05-14 Koninklijke Philips Electronics N.V. Method for coding a presentation
JP3407287B2 (ja) 1997-12-22 2003-05-19 日本電気株式会社 符号化復号システム
US6374336B1 (en) * 1997-12-24 2002-04-16 Avid Technology, Inc. Computer system and process for transferring multiple high bandwidth streams of data between multiple storage units and multiple applications in a scalable and reliable manner
EP1040419B1 (en) 1997-12-24 2002-08-07 Avid Technology, Inc. Computer system for transferring multiple high bandwidth streams of data between multiple storage units and multiple applications in a scalable and reliable manner
US6515976B1 (en) 1998-04-06 2003-02-04 Ericsson Inc. Demodulation method and apparatus in high-speed time division multiplexed packet data transmission
US6591305B2 (en) * 1998-06-30 2003-07-08 Sun Microsystems, Inc. Method and system for delivering data from a server object to a client object using a non-proprietary data transfer protocol
JP2000059755A (ja) * 1998-08-07 2000-02-25 Matsushita Electric Ind Co Ltd データサーバシステム、データ受信装置およびデータ送信装置
US6016166A (en) * 1998-08-31 2000-01-18 Lucent Technologies Inc. Method and apparatus for adaptive synchronization of digital video and audio playback in a multimedia playback system
WO2000042773A1 (en) 1999-01-19 2000-07-20 Sony Electronics Inc. System and method for implementing interactive video
US6993788B1 (en) * 1999-08-20 2006-01-31 Mediaone Group, Inc. Method and system for manipulating broadcast signals
DE60105998D1 (de) * 2000-04-08 2004-11-04 Sun Microsystems Inc Wiedersynchronisierung von medien während strömung
US7103668B1 (en) * 2000-08-29 2006-09-05 Inetcam, Inc. Method and apparatus for distributing multimedia to remote clients

Also Published As

Publication number Publication date
DE60141850D1 (de) 2010-05-27
CN1243442C (zh) 2006-02-22
CN1481643A (zh) 2004-03-10
EP2071827A3 (en) 2010-08-25
US20040064573A1 (en) 2004-04-01
ATE464740T1 (de) 2010-04-15
EP2071827A2 (en) 2009-06-17
KR20030061853A (ko) 2003-07-22
KR100908954B1 (ko) 2009-07-22
US7447791B2 (en) 2008-11-04

Similar Documents

Publication Publication Date Title
ES2342357T3 (es) Transmision y recepcion de material de audio y/o video.
JP4087706B2 (ja) オーディオおよび、またはビデオマテリアルの送信および受信
ES2277954T3 (es) Codificacion de señales de audio.
AU2002215122A1 (en) Encoding audio signals
JP4598627B2 (ja) コンテンツ編集装置及びその再生装置
KR20030003063A (ko) 데이터 재생 장치 및 데이터 재생 방법
JP4315914B2 (ja) 画像再生装置及び画像再生方法
JP4882441B2 (ja) 配信サーバ装置、クライアント装置、及びそれらに用いるプログラム
JPH09509036A (ja) エンコーダシステムのレベルバッファ管理
WO2002049342A1 (en) Delivery of audio and/or video material
JP2007243824A (ja) 多重化装置、多重化方法、及び多重化プログラム
JP5144771B2 (ja) 画像処理装置、画像再生装置、画像記録装置、画像処理方法、画像再生方法、及び画像記録方法
JP3894362B2 (ja) 複数動画像の閲覧装置および記録媒体
JP2000152236A (ja) 動画像符号化装置および多重化方法とその装置および記録再生装置
JP2006074759A (ja) 複数動画像の閲覧装置および配信装置
JP2003087786A (ja) データ再生装置、及びデータ再生方法
CN116016981A (zh) 视角增强视频的传输方法、装置以及介质
KR101656102B1 (ko) 컨텐츠 파일 생성/제공 장치 및 방법
JP2003173622A (ja) 符号化音声データ復号化装置及び符号化音声データ復号化方法
KR20070054269A (ko) 영상 재생장치에서 영상 프레임의 재생 방법 및 장치
JP2006139535A (ja) 移動通信端末装置
JPH03262222A (ja) Ｆｍ多重信号送出装置
JP2004364048A (ja) データ記録装置、データ再生装置、データ記録方法、データ再生方法及びデータ記録媒体