ES2801698T3 - Sincronización de flujo modificado - Google Patents

Sincronización de flujo modificado Download PDF

Info

Publication number
ES2801698T3
ES2801698T3 ES10708572T ES10708572T ES2801698T3 ES 2801698 T3 ES2801698 T3 ES 2801698T3 ES 10708572 T ES10708572 T ES 10708572T ES 10708572 T ES10708572 T ES 10708572T ES 2801698 T3 ES2801698 T3 ES 2801698T3
Authority
ES
Spain
Prior art keywords
stream
synchronization
information
timing
multimedia
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES10708572T
Other languages
English (en)
Inventor
Hans Maarten Stokking
Fabian Arthur Walraven
Deventer Mattijs Oskar Van
Omar Aziz Niamut
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.)
Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO
Koninklijke KPN NV
Original Assignee
Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO
Koninklijke KPN NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO, Koninklijke KPN NV filed Critical Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO
Application granted granted Critical
Publication of ES2801698T3 publication Critical patent/ES2801698T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
    • 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/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/24—Systems for the transmission of television signals using pulse code modulation
    • 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
    • H04L7/00—Arrangements for synchronising receiver with transmitter
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234309—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by transcoding between formats or standards, e.g. from MPEG-2 to MPEG-4 or from Quicktime to Realvideo
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234318—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into objects, e.g. MPEG-4 objects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23608—Remultiplexing multiplex streams, e.g. involving modifying time stamps or remapping the packet identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2368—Multiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/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/4302—Content synchronisation processes, e.g. decoder synchronisation
    • 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/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43072—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of multiple content streams on the same device
    • 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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4341—Demultiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content

Abstract

Método para permitir la sincronización entre destinos de al menos un primer y al menos un segundo flujo, estando asociado dicho segundo flujo con el flujo de salida de una unidad de modificación de flujo multimedia utilizando dicho primer flujo como un flujo de entrada, con dicha unidad de modificación de flujo multimedia modificando la información de temporización de dicho primer flujo, cuyo método comprende las etapas de: - proporcionar la primera información de hora de llegada de un paquete en el primer flujo que llega a un primer punto de sincronización y la segunda información de hora de llegada de un paquete en el segundo flujo que llega a un segundo punto de sincronización a una unidad de sincronización para sincronizar dichos puntos de sincronización, estando dicha unidad de sincronización conectada a dicho primer y dicho segundo punto de sincronización, en donde dicha información de hora de llegada comprende una información de hora de llegada e información de temporización del paquete; - proporcionar, por la unidad de modificación del flujo multimedia, información de correlación de sincronización sobre la relación de sincronismo entre dicho flujo de entrada y dicho flujo de salida a dicha unidad de sincronización; - calculando dicha unidad de sincronización la información de retardo sobre la base de la primera y segunda información de hora de llegada y la información de correlación de sincronización; - dicha unidad de sincronización proporciona al menos dicho primer o segundo punto de sincronización con dicha información de retardo, permitiendo que al menos dicho primer o segundo punto de sincronización retarde la salida de un flujo de manera que el primer y segundo flujos emitidos por el primer y segundo punto de sincronización, respectivamente, están sincronizados.

Description

DESCRIPCIÓN
Sincronización de flujo modificado
CAMPO DE LA INVENCIÓN
La invención se refiere a un método y un sistema para la sincronización entre destinos de flujos relacionados. La invención se refiere, además, a una unidad de sincronización, un punto de sincronización, un módulo de ajuste de información de hora de llegada y una estructura de datos para utilizar en dicho sistema y a un producto de programa informático que utiliza dicho método.
ANTECEDENTES DE LA INVENCIÓN
Las nuevas técnicas multimedia tales como la Voz sobre IP (VoIP) y la Televisión de Protocolo de Internet (IPTV) abren toda una gama de nuevos servicios multimedia. Un tipo de estos servicios permite a un grupo de usuarios ver por separado el mismo canal de televisión y comunicarse entre sí mediante texto, audio y/o vídeo. Otro tipo de estos servicios proporciona experiencias de televisión interactivas, tales como un cuestionario televisivo en donde los televidentes en el hogar pueden introducir respuestas a las preguntas transmitidas y participar en el programa. Dichos servicios requieren que la señal de salida de los terminales se transmita al mismo tiempo a todos los usuarios del grupo. Dicho de otro modo, las salidas de la pantalla o dispositivos de reproducción en el grupo, por ejemplo, los televisores, PDAs, dispositivos móviles, PCs o una de sus combinaciones, que corresponden a diferentes destinos, deben sincronizarse.
En un sistema de IPTV, la señal del canal de TV se suele transmitir como uno o más flujos en paquetes a través de una red IP de alto ancho de banda de un operador a través de nodos de red tales como cabeceras, enrutadores de borde y nodos de acceso a los terminales de los abonados a dichos servicios. Durante la transmisión de los flujos, los paquetes están sujetos a retardos desconocidos en la red, tales como retardos de transmisión, diferencias en las rutas de red y diferencias en los retardos de codificación y de decodificación. Como consecuencia, la relación temporal entre los paquetes de flujos de audio y vídeo recibidos en un primer terminal (un primer destino) y los recibidos en otro segundo terminal (un segundo destino) se verá afectada.
Para transmitir el contenido de IPTV a los terminales, por lo general se utiliza el Protocolo de Transporte en Tiempo Real (RTP). El protocolo RTP proporciona numeración de secuencia y genera marcas de tiempo. Utilizando el protocolo RTP, la relación temporal en un flujo (sincronización dentro del flujo), entre los flujos asociados que terminan en el mismo terminal (sincronización entre flujos) o entre los flujos asociados que terminan en diferentes terminales (sincronización de grupo o sincronización entre destinos) puede ser restablecido. El documento de OSKAR VAN DEVENTER ET AL: "Los servicios avanzados de televisión interactiva requieren sincronización de contenido", 15a Conferencia Internacional sobre Sistemas, Señales y Procesamiento de Imágenes, 25 de junio de 2008, XP031310397 proporciona métodos arquitectónicos para la sincronización de contenido entre destinos para la tecnología IPTV basada en IMS. El artículo "Grupo multimedia y técnicas de sincronización entre flujos: un estudio comparativo" de F. Boronat et al. (Elsevier Information Systems 34 (2009) págs. 108-131) proporciona una descripción completa de las técnicas de sincronización entre destinos conocidos, que pueden subdividirse en tres categorías principales.
En el "Sistema Maestro de Sincronización" (SMS), un sistema maestro de sincronización central recoge información de temporización desde todos los terminales del grupo y ajusta la temporización de salida distribuyendo paquetes de control a los terminales. En el "Sistema de receptor maestro-esclavo" (MSRS), los receptores (terminales) se clasifican en un receptor maestro y receptores esclavos. El receptor maestro transmite su temporización de salida a los receptores esclavos, que ajustan su temporización de salida de los paquetes en consecuencia. En el "Sistema de Control Distribuido" (DCS), cada terminal (receptor) multidifunde toda la información de temporización a todos los demás terminales del grupo y el terminal está configurado para calcular la temporización de salida adecuada. Estos sistemas tienen en común que la sincronización se lleva a cabo en el origen o en el extremo receptor de un flujo multimedia.
La mayoría de las técnicas de sincronización entre destinos a las que se hace referencia utilizan información de temporización (por ejemplo, una marca de tiempo RTP, el número de secuencia RTP del flujo multimedia RTP recibido en una instancia específica en el tiempo, o uno o más parámetros equivalentes en un flujo de transporte) en recepción de flujo multimedia en los terminales. Al comparar la información de temporización de diferentes receptores, se pueden calcular los ajustes de flujo apropiados. Un ajuste, a modo de ejemplo, puede ser un retardo del tiempo de reproducción del flujo recibido mediante el uso de una memoria intermedia en el extremo del receptor.
Un problema relacionado con estos sistemas de sincronización conocidos es que estos sistemas no están diseñados para gestionar situaciones en donde el flujo entre el origen y el receptor se modifica para fines de preparación de contenidos y/o para la regeneración de contenidos.
La modificación de un flujo puede ser necesaria y/o ventajosa en una gran cantidad de situaciones. Por ejemplo, para preparar un flujo multimedia para una entrega eficiente, los flujos multimedia pueden ajustarse para los requisitos específicos de los receptores de flujo o de las líneas de acceso, tales como un cambio en la resolución (por ejemplo, cuando se convierte de HD a SD o se convierte a una tasa binaria inferior). En dicha situación, se puede colocar una unidad de modificación de flujo, denominada traductor o transcodificador, en la ruta del flujo. El flujo de salida del transcodificador modificado puede comprender diferentes marcas de tiempo, números de secuencia u otra información de temporización en comparación con el flujo de entrada original (sin modificar).
Los flujos multimedia también se pueden personalizar para requisitos específicos del cliente. Puede ser necesario añadir voces en off, subtítulos, Picture in Picture, al flujo de contenido principal. Esta operación se suele realizar por una unidad de modificación de flujo denominada mezclador. Además, es posible que se deba volver a generar un flujo al cruzar dominios de red utilizando una unidad de regeneración. Todos estos sistemas de preparación y regeneración de contenido pueden cambiar la información de temporización en el flujo, haciendo que los sistemas de sincronización entre destinos conocidos sean poco fiables o incluso imposibles de utilizar. Por lo tanto, existe la necesidad en la técnica anterior de métodos y sistemas que permitan la sincronización entre destinos entre flujos modificados y no modificados o entre dos flujos modificados de manera diferente.
SUMARIO DE LA INVENCIÓN
Es un objeto de la invención reducir o eliminar al menos uno de los inconvenientes de los sistemas de sincronización conocidos en la técnica anterior y proporcionar un método para la sincronización entre destinos de al menos un primer y un segundo flujo en donde dicho segundo flujo es el flujo de salida de una unidad de modificación de flujo multimedia que utiliza el primer flujo como flujo de entrada.
La invención está definida por las reivindicaciones independientes 1, 11, 14, 15 y 16.
Al proporcionar información de correlación de sincronización, los flujos relacionados dirigidos a un conjunto heterogéneo de espectadores, utilizando diferentes terminales, y con diferentes requisitos de servicio, aún pueden sincronizarse. Así, la invención permite que grupos de espectadores en una red heterogénea vean un flujo multimedia de forma sincronizada.
La hora de llegada en este contexto suele ser el tiempo en que un punto de sincronización recibe una parte particular de un flujo multimedia. En el contexto de esta invención, cualquier experto en esta técnica comprenderá que no es necesario utilizar aquí la hora exacta de llegada del paquete. El tiempo real utilizado como información de hora de llegada puede variar ligeramente, dependiendo del punto preciso que utilice un punto de sincronización para determinar la hora de llegada. Lo que antecede puede, por ejemplo, producirse directamente a la llegada, antes de colocar un paquete en una memoria intermedia de fluctuaciones. Pero también puede estar en un punto posterior en el proceso de gestión de los paquetes multimedia, por ejemplo, justo antes del proceso de decodificación o justo antes de un proceso de traducción. Un punto de sincronización puede incluso tener conocimiento del tiempo necesario para procesar un paquete multimedia hasta la presentación real de esa parte particular del contenido multimedia, y utilizar el tiempo de presentación real como información de hora de llegada.
La invención se ilustrará de manera adicional haciendo referencia a los dibujos adjuntos, que muestran de manera esquemática en formas de realización de conformidad con la invención. Se entenderá que la invención no está restringida de ninguna manera a estas formas de realización específicas.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La Figura 1 representa una forma de realización, a modo de ejemplo, de una topología de red heterogénea, que comprende múltiples unidades de modificación de flujo, y capaces de entregar flujos relacionados a diferentes ubicaciones.
La Figura 2 representa un sistema de conformidad con una forma de realización de la invención.
La Figura 3 representa un diagrama de flujo asociado con un sistema de conformidad con la invención.
La Figura 4 representa un sistema de conformidad con otra forma de realización de la invención.
La Figura 5 representa una puesta en práctica del sistema de sincronización entre destinos según una forma de realización de la invención.
La Figura 6 representa un informe extendido RTCP, a modo de ejemplo, de conformidad con una forma de realización de la invención.
La Figura 7 representa el uso de mensajes RTCP para sincronizar el flujo multimedia de conformidad con otra forma de realización de la invención.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN
La Figura 1 representa una forma de realización, a modo de ejemplo, de un sistema de entrega multimedia 100 para entregar contenido a equipos de usuario a través de una red. La red tiene una topología heterogénea, que comprende múltiples módulos de modificación de flujo y es capaz de entregar flujos relacionados a diferentes ubicaciones. En esta forma de realización, un flujo multimedia que comprende paquetes se entrega a múltiples equipos de usuario en los que el flujo multimedia se adapta de manera diferente para diferentes equipos de usuario.
Un paquete en el contexto de esta solicitud de patente es un elemento (es decir, una unidad) de un flujo multimedia que está asociado con información de temporización, por ejemplo, marcas de tiempo. Un ejemplo de dichos paquetes es un paquete RTP que comprende una o más marcas de tiempo. Otro ejemplo es un paquete de tipo MPEG, tal como un paquete Flujo de Transporte (TS) que comprende una o más marcas de tiempo de presentación.
Un experto en esta técnica comprenderá que cualquier formato de paquete multimedia que comprenda información de temporización puede utilizarse para fines de sincronización. La información de temporización puede ser parte del contenedor de transporte (el protocolo de transporte), que se utiliza para transportar el contenido, ya sea normalizado o propietario. De manera alternativa o, además, también puede ser parte del contenido real, por ejemplo, información de temporización utilizada en el sistema de codificación para codificar el contenido.
El sistema de entrega multimedia en la Figura 1 comprende un origen de flujo multimedia 101, por ejemplo, un servidor capaz de entregar flujos multimedia a través de una o más redes, por ejemplo, una red IP, a diferentes equipos de usuario (UE) 106-109. Un equipo UE o un terminal pueden relacionar un dispositivo de reproducción o un dispositivo conectado a otro (por ejemplo, un decodificador). Dichos dispositivos pueden incluir, por ejemplo, un teléfono móvil, un aparato de televisión, un teléfono IP, una consola de juegos, un dispositivo de medición inteligente, etc., pero también puede ser cualquier otra acción automatizada en respuesta a un flujo sincronizado, tal como la medición automatizada de múltiples dispositivos de medición en respuesta a una señal sincronizada.
El sistema de entrega multimedia puede comprender varios elementos de red, que realizan ciertas acciones en un flujo multimedia para que se modifique la información de temporización en el flujo. Dicho elemento de red, de aquí en adelante, se suele referir como una unidad de modificación de flujo. En la forma de realización de la Figura 1, el sistema comprende varias unidades de modificación de flujo, por ejemplo, un primer transcodificador 102, un segundo transcodificador 103 y un mezclador 104. Un servidor 105 puede entregar flujos elementales alternativos y/o adicionales 105 al mezclador. Este servidor 105 puede, por ejemplo, entregar audio alternativo (diferentes idiomas, comentarios del director o sonido envolvente), subtítulos alternativos o vídeo alternativo (por ejemplo, un firmante que traduce el lenguaje hablado al lenguaje de signos).
El flujo multimedia original 110 entregado por el servidor multimedia 101 puede ser un flujo de vídeo bajo demanda (VoD) con codificación MPEG4 transportada a través de la red utilizando RTP sobre UDP sobre IP. Este flujo multimedia original 110 es modificado (es decir, transcodificado) por el primer transcodificador 102 que transcodifica el flujo codificado MPEG4 original en un flujo codificado MPEG2 para el beneficio de UE2 107, que solamente admite codificación MPEG2. El flujo multimedia transcodificado 112 se transporta, además, al UE2 utilizando RTP sobre UDP sobre IP.
El segundo transcodificador 103 puede transcodificar el flujo multimedia original 110 a un flujo multimedia modificado que tenga un formato de contenedor diferente del formato de contenedor utilizado por el flujo multimedia original por el cual el sistema de codificación real no se cambia. El segundo transcodificador 103 puede, por ejemplo, entregar el flujo multimedia codificado en MPEG4 a través de la red al UE3 108 utilizando un flujo de transporte MPEG transportado directamente sobre UDP. Además, el mezclador 104 puede añadir uno o más flujos elementales adicionales al flujo multimedia original o puede sustituir uno o más flujos multimedia elementales en el flujo multimedia original con uno o más flujos elementales alternativas. Estos flujos elementales adicionales o alternativos se entregan por el servidor 105 utilizando RTP sobre UDP sobre IP. El mezclador 104 entrega con posterioridad el flujo multimedia mezclado 114 a UE4 utilizando MPEG4 sobre RTP sobre UDP sobre IP.
En el sistema de entrega multimedia tal como se representa en la Figura 1, el flujo multimedia original 110 puede utilizar un protocolo de transporte que comprende información de temporización. En una forma de realización, el protocolo RTP puede utilizarse como un mecanismo de transporte. El protocolo RTP utiliza marcas de tiempo RTP que pueden utilizarse como información de temporización para sincronizar flujos multimedia.
El primer transcodificador 102 puede decodificar el flujo original 110 y volver a codificar los medios (por ejemplo, desde MPEG4 a MPEG2). Por lo tanto, enviará un flujo multimedia modificado utilizando una marca de tiempo RTP aleatoria para indicar el inicio de su transmisión a UE2 107. La marca de tiempo del flujo multimedia saliente difiere de la del flujo multimedia entrante aun cuando se utilicen los mismos protocolos de transporte (RTP sobre UDP sobre IP).
El segundo transcodificador 103 no decodifica el flujo original 110, sino que envía el flujo multimedia 113 al UE3 108 utilizando un contenedor de transporte diferente. Por ejemplo, se utiliza un flujo de transporte MPEG (TS) sobre UDP para enviar el contenido a UE3. Estos paquetes MPEG TS pueden contener información de temporización en forma de las denominadas de Tiempo de Presentación (PTS) para indicar la instancia en donde se debe presentar un paquete para su visualización. Estas marcas PTS son diferentes de las marcas de tiempo RTP del flujo multimedia original 110, aun cuando la codificación real entre los medios de flujo multimedia entrantes y salientes permanece sin cambios.
El mezclador 104 puede mezclar uno o más flujos elementales en el flujo multimedia 111 con el flujo multimedia original 110. Con posterioridad, puede enviar el flujo multimedia mezclado 114 a través de la red al UE4 109. A medida que el mezclador genera un nuevo flujo multimedia, utilizará una nueva marca de tiempo RTP generada de manera aleatoria como el tiempo de inicio para transmitir este flujo a UE4, por lo que los sistemas de codificación y transporte utilizados para el flujo de entrada 110 y el flujo de salida mezclado 114 son los mismos.
Sin ninguna otra medida, la sincronización de la reproducción en los UEs no es posible porque las unidades de modificación de contenido en la red cambian la información de temporización en los flujos para que las marcas de tiempo en el origen y los UEs no se correlacionen entre sí. La razón es que el servidor multimedia 101, los transcodificadores 102 y 103 y el mezclador 104 eligen, cada uno, una marca de tiempo aleatoria como un tiempo de inicio. Este mismo problema existe para el mezclador: recibe flujos multimedia tanto del servidor multimedia original 101 como de otro origen, es decir, el servidor multimedia que contiene flujos elementales adicionales y alternativos 105. Tal como se describió con anterioridad, las marcas de tiempo en estos flujos multimedia no estarán correlacionados.
La Figura 2 ilustra una representación esquemática de un sistema de entrega multimedia 200 que comprende un primer punto de sincronización 205 y un segundo punto de sincronización 208 para sincronizar un flujo multimedia. Un punto de sincronización es un punto (lógico o físico) en la ruta del flujo para el cual se determina la información de sincronización (por ejemplo, la información de la hora de llegada). Un punto de sincronización puede estar comprendido en cualquier dispositivo físico conectado o incorporado en una red. Por ejemplo, puede relacionarse con un nodo de red, tal como un nodo de acceso (por ejemplo, un multiplexor de acceso de línea de abonado digital (DSLAM), un sistema de terminación de módem de cable (CMTS)), un nodo de acceso óptico o un enrutador de borde o una cabecera. De manera alternativa, un punto de sincronización puede configurarse como un decodificador conectado a un televisor, un ordenador personal, un ordenador portátil, un netbook, un asistente digital personal o cualquier otro dispositivo capaz de gestionar el flujo multimedia.
El sistema de entrega multimedia puede contener un origen de flujo multimedia 201, por ejemplo, un servidor multimedia, entregando, por ejemplo, un flujo de vídeo bajo demanda o una transmisión de televisión multidifusión en directo. Este origen multimedia 201 puede transmitir un primer flujo multimedia original 212 a través de la red 211 a los puntos de sincronización. El primer punto de sincronización 205 puede recibir el flujo multimedia original 212 sin ninguna modificación. Sin embargo, el segundo punto de sincronización 208 puede recibir un flujo que comprende el mismo contenido, pero, por ejemplo, en un formato diferente. Por lo tanto, el segundo punto de sincronización 208 recibe un segundo flujo multimedia modificado 213 generado por una unidad de modificación del flujo multimedia 202, que recibe el flujo multimedia original 212 y genera el flujo multimedia modificado 213.
Los puntos de sincronización de flujo primero y segundo 205, 208 pueden configurarse para proporcionar sincronización entre destinos (o sincronización de grupo) entre el primer y el segundo flujo multimedia 212, 213, respectivamente. Para ello, los puntos de sincronización del flujo multimedia están conectados a una unidad de sincronización multimedia 204, por ejemplo, un servidor de aplicaciones de sincronización multimedia (MSAS). Los puntos de sincronización de flujo primero y segundo 205, 208 pueden comprender clientes de sincronización primero y segundo 207, 210 y unidades de retardo variable primera y segunda que comprenden cada una, por ejemplo, una memoria intermedia de retardo variable 206, 209, respectivamente. El primer y segundo clientes de sincronización 207, 210 están configurados para intercambiar información de sincronización con el MSAS 204 tal como se explica con más detalle a continuación.
La unidad de modificación del flujo multimedia 202 puede comprender, además, un tercer cliente de sincronización SC’ 203 asociado con la unidad de modificación del flujo multimedia. Los clientes de sincronización 207, 210, 203 intercambian mensajes con el MSAS 204 utilizando, por ejemplo, rutas de señalización 214. Estos mensajes de señalización pueden transportarse a través de la misma red 211 utilizada en la distribución multimedia. De manera alternativa, los mensajes también pueden transportarse a través de otras redes. Para la explicación siguiente, las rutas de señalización 214 se denominan puntos de referencia de sincronización.
En este ejemplo, el flujo multimedia original 212 puede relacionarse, por ejemplo, con un flujo de vídeo transportado en RTP a través de una red IP utilizando el protocolo UDP. En ese caso, los paquetes RTP en el flujo multimedia 212 original pueden contener una marca de tiempo RTP generada por el origen del flujo multimedia 201 y un identificador de fuente de sincronización (SSRC) tal como se define en el protocolo RTP.
El flujo modificado 213 puede contener el mismo contenido que el flujo multimedia original 212 pero es modificado por la unidad de modificación del flujo multimedia 202. La modificación puede ser una operación de modificación tal como se describió con anterioridad haciendo referencia a la Figura 1, por ejemplo, el flujo original puede ser un flujo de alta definición (HD) de alto ancho de banda y el flujo modificado puede ser flujo de definición estándar (SD) de bajo ancho de banda. Otra modificación puede, por ejemplo, ser la aplicación de un sistema de encriptación asociado con un sistema de Gestión de Derechos Digitales (DRM) soportado por uno o más puntos de sincronización de flujo en la red. La modificación también puede relacionarse con la re-originación. Se puede proporcionar la re-originación cuando los flujos multimedia cruzan los límites de la red, por ejemplo, cuando un proveedor de IPTV desea ofrecer flujos multimedia disponibles en Internet también a una o más de sus redes privadas de IPTV. Otras modificaciones pueden incluir modificaciones basadas en la mezcla, por ejemplo, incluida una persona que realiza lenguaje de signos en el flujo de vídeo o reenvía los flujos en un contenedor multimedia diferente, por ejemplo, utilizando un Flujo de Transporte (TS) de MPEG en lugar de utilizar RTP.
Los paquetes RTP en el flujo multimedia modificado 213 pueden contener un identificador SSRC diferente y marcas de tiempo RTP diferentes en comparación con los del flujo multimedia original 212. Según el RFC 3550 de IETF, el identificador SSRC y la marca de tiempo RTP son campos de cabecera de 32 bits en un paquete RTP. Para cada flujo multimedia, la hora de inicio de una marca de tiempo RTP debe elegirse al azar. Además, el SSRC es un valor elegido al azar, que debe ser único a nivel global. En los sistemas de sincronización entre destinos conocidos, la sincronización puede lograrse señalizando información de marca de tiempo a cada punto de sincronización de flujo. Sin embargo, como las marcas de tiempo RTP en los primero y segundo flujos 212, 213 son diferentes, no es posible la sincronización directa de los flujos multimedia en el primer y segundo punto de sincronización.
En el sistema de entrega multimedia, el primer y el segundo puntos de sincronización de flujo 205, 208 pueden enviar la denominada información de estado de sincronización al MSAS 204. Esta información de estado de sincronización puede contener la información de identificación asociada con el flujo multimedia (por ejemplo, un Identificador SSRC) y la información de temporización (por ejemplo, una marca de tiempo RTP y una marca de tiempo NTP asociadas con el tiempo de reproducción de un paquete).
La marca de tiempo RTP refleja el instante de muestreo del primer byte en el paquete de datos RTP. El valor inicial de la marca de tiempo es un valor aleatorio. La marca de tiempo RTP cuenta los períodos de muestreo, por lo que, si un segundo paquete RTP inicia 160 muestras después de un primer paquete RTP, entonces la segunda marca de tiempo RTP es 160 más alta que la primera.
La marca de tiempo NTP es una hora absoluta de "reloj de pared". NTP es un contador de 64 bits que comenzó el 1 de enero de 1900 tal como se define en IETF RFC 1305. Las marcas de tiempo de 64 bits utilizadas por NTP consisten en una segunda parte de 32 bits y una segunda parte fraccional de 32 bits. Representa el tiempo absoluto en que el primer byte, identificado por la marca de tiempo RTP, pasa un punto específico, es decir, un punto de sincronización.
Este punto específico puede ser el punto de reproducción del equipo de usuario (UE) que contiene el SC en donde la marca de tiempo NTP representa el tiempo que el byte especificado se reproduce para el usuario. De manera alternativa, puede ser el punto de entrada, en donde un SC recibe primero un byte especificado. De manera similar, para una sincronización SC’, este punto específico puede ser un punto de salida o un punto de entrada.
El primer punto de sincronización del flujo puede enviar el siguiente primer mensaje de información de estado de sincronización al MSAS:
Identificador SSRC = 12345678
Marca de tiempo RTP = 1556688423
Marca de tiempo NTP = 13: 42: 21.000
De manera similar, el segundo punto de sincronización del flujo multimedia puede enviar el siguiente mensaje de información de estado de sincronización al MSAS:
Identificador SSRC = 90ABCDEF
Marca de tiempo RTP = 1684654845
Marca de tiempo NTP = 13: 42: 21.000
En este ejemplo, la información desde los primero y segundo puntos de sincronización de flujo está asociada con el mismo tiempo de reproducción NTP: 13: 42: 21.000. En este ejemplo, se supone que ambos puntos de sincronización de flujo multimedia están sincronizados con NTP, es decir, sus relojes están sincronizados utilizando el protocolo de tiempo de red o algunos otros medios.
Tal como se explicó con anterioridad, aunque el flujo multimedia modificado lleva el mismo contenido, la sincronización puede no ser posible debido a que la unidad de modificación del flujo multimedia 202 modifica la información de temporización en el flujo de salida modificado 213. Con el fin de permitir la sincronización, el cliente de sincronización SC’ asociado con la unidad de modificación del flujo multimedia 202 puede enviar un mensaje de información de correlación de sincronización sobre la relación de sincronismo entre un flujo multimedia entrante 212, recibido por la unidad de modificación del flujo multimedia, y el flujo multimedia saliente 213, transmitido por la unidad de modificación del flujo multimedia al segundo punto de sincronización de flujo multimedia. Por lo tanto, la relación de sincronismo se relaciona con la primera información de temporización en un primer paquete y la segunda información de temporización en un segundo paquete, en donde el primer y el segundo paquete comprenden el mismo contenido o una parte del mismo y en donde dicho segundo paquete es parte de un flujo modificado por la unidad de modificación del flujo multimedia y en donde dicho primer paquete es parte de un flujo multimedia antes de dicha modificación.
En una forma de realización, la unidad de modificación del flujo multimedia puede enviar la siguiente información al MSAS:
Entrante:
Identificador SSRC = 12345678
Marca de tiempo RTP = 1556688423
Saliente:
Identificador SSRC = 90ABCDEF
Marca de tiempo RTP = 1684657845
Esta información contiene tanto un par de marcas de tiempo RTP/identificador de SSRC entrante y un par de marcas de tiempo RTP/identificador de SSRC saliente. Por lo tanto, el mensaje de información de correlación de sincronización puede permitir la correlación de uno o más flujos recibidos a la entrada de la unidad de modificación de flujo con uno o más flujos transmitidos a la salida de una unidad de modificación de flujo utilizando el SSRC y/o las marcas de tiempo RTP señalizadas en el MSAS.
En una forma de realización, la información de correlación de sincronización puede enviarse en un solo mensaje al MSAS. En otra forma de realización, puede enviarse en dos mensajes separados. El uso de mensajes separados puede ser ventajoso si los parámetros de sincronización de los flujos entrantes o salientes no varían mucho con el tiempo, por lo que la señalización de la información de sincronización asociada con estos flujos se requiere con menos frecuencia. Más detalles sobre la señalización de la información de sincronización se describen a continuación con referencia a la Figura 5-7.
El servidor MSAS 204 recibe los mensajes de información de estado de sincronización primero y segundo desde ambos puntos de sincronización del flujo multimedia y el mensaje de información de correlación de sincronización que contiene la relación de sincronismo desde la unidad de modificación del flujo multimedia. Con posterioridad, utiliza esta información para calcular la información de temporización para el primer y segundo punto de sincronización de flujo multimedia.
Este cálculo puede implicar dos etapas de cálculo. La primera etapa se relaciona con un cálculo para ajustar toda la información del estado de sincronización a una sola línea de tiempo (base de tiempos). En la segunda etapa, se calcula la información de retardo real. En el siguiente ejemplo, se supone que ambas marcas de tiempo RTP representan una escala de milisegundos. Si este no es el caso, los cálculos deben ajustarse para reflejar esta circunstancia. A continuación, en una primera etapa, toda la información del estado de sincronización se ajusta a una línea de tiempo común, por ejemplo, a la línea de tiempo asociada con las marcas de tiempo RTP del flujo multimedia original 212. Esta etapa se conoce como la etapa de conversión de información de estado.
A las 13: 42: 21.000, el primer punto de sincronización de flujo multimedia 205 está en la marca de tiempo 1556688423. En este ejemplo, que la marca de tiempo proporcionada por el segundo punto de sincronización de flujo multimedia 208 se ajustará a la línea de tiempo asociada con el flujo multimedia original 212. En otras variantes, también puede ser posible ajustar la información del estado de sincronización sobre la base de una línea de tiempo asociada con el flujo modificado o ajustar las líneas de tiempo de ambos flujos a una nueva (tercera) línea de tiempo. Un ejemplo de una tercera línea de tiempo puede relacionarse con una situación en donde cada flujo multimedia comienza en la marca de tiempo 0, de modo que la primera marca de tiempo elegida al azar de cada flujo requiere un ajuste a 0.
Para ajustar la información del estado de sincronización recibida desde el segundo punto de sincronización multimedia 208, se utiliza la siguiente información:
- Marca de tiempo RTP en la información del estado de sincronización del flujo modificado que tiene un valor 1684654845;y
- El valor de marca de tiempo RTP 1684657845 asociado con el flujo modificado se correlaciona con el valor de marca de tiempo RTP 1556688423 asociado con el flujo original.
El cálculo para ajustar la marca de tiempo puede relacionarse con una transformación lineal simple: marca de tiempo ajustada = conv_timestamp_org_flujo conv_timestamp_mod_flujo - timestamp_mod_flujo_current. Por lo tanto, a las 13: 42: 21,000, el segundo punto de sincronización del flujo multimedia 208 puede estar asociado con la marca de tiempo ajustada 1556688423 1684654845 - 1684657845 = 1556685423. De esa manera, la información del estado de sincronización recibida desde el segundo punto de sincronización del flujo multimedia 208 puede ajustarse a la línea de tiempo asociada con la información del estado de sincronización recibida desde el primer punto 205 de sincronización de flujo multimedia.
A partir de entonces, el cálculo de la información de retardo puede realizarse de conformidad con sistemas conocidos. Por ejemplo, la información de retardo puede determinarse en función del cliente que está más retrasado en la reproducción del flujo multimedia. Puesto que ambas marcas de tiempo en el ejemplo descrito con anterioridad se informan a la misma hora de reloj 13:42: 21.000, el cálculo puede implicar una simple sustracción de la información del estado de sincronización de ambos puntos de sincronización del flujo multimedia: 1556685423 - 1556688423 = -3000. Este resultado indica que el flujo multimedia en el segundo punto 208 de sincronización de flujo multimedia está 3 segundos atrás en el flujo multimedia en el primer punto 205 de sincronización de flujo multimedia. Este retardo puede atribuirse a un proceso de transcodificación ejecutado en la unidad de modificación de flujo multimedia 202. Si la hora de reloj informada (es decir, el tiempo de NTP) difiere en los diferentes mensajes de información de estado de sincronización recibidos por el MSAS, esta diferencia de hora de reloj debe tenerse en cuenta en el cálculo para determinar el retardo.
De lo que antecede se deduce que el flujo modificado está 3 segundos atrás (tal como se muestra en el cuarto dígito desde la derecha en la marca de tiempo). En otra forma de realización, se puede utilizar la línea de tiempo del flujo multimedia ajustado: 1684657845 ms - 1684654845 ms = 3000 ms. Por lo tanto, para sincronizar los flujos multimedia en ambos puntos de sincronización de flujo multimedia, el MSAS puede enviar instrucciones de ajuste de sincronización al primer punto de sincronización 205 para retardar la reproducción en 3 segundos.
La Figura 3 representa el intercambio de información en un diagrama de flujo de mensajes 300 para el ejemplo descrito con anterioridad con referencia a la Figura 2. En una primera etapa 302, el primer punto de sincronización recibe el flujo multimedia original desde el origen del flujo multimedia y el segundo punto de sincronización recibe un flujo multimedia modificado desde la salida de la unidad de modificación del flujo multimedia, en donde la unidad de modificación del flujo multimedia utiliza el flujo multimedia original desde el origen del flujo multimedia como su señal de entrada.
En una segunda y tercera etapa 304, 306, los puntos de sincronización primero y segundo envían cada uno un mensaje de información de estado de sincronización primero y segundo, respectivamente, al servidor de aplicaciones de sincronización multimedia (MSAS). Con posterioridad, en una cuarta etapa 308, la unidad de modificación del flujo multimedia envía un mensaje de información de correlación sobre la relación de sincronismo entre el flujo multimedia entrante y el flujo multimedia saliente al MSAS. El servidor MSAS puede calcular con posterioridad en una quinta etapa 310 instrucciones de configuración de sincronización y enviar estas instrucciones a los destinos, es decir, primer y segundo punto de sincronización.
El ejemplo no limitativo descrito con referencia a la Figura 2 y la Figura 3 ilustra un sistema de sincronización entre destinos utilizando una unidad de modificación de flujo multimedia y dos puntos de sincronización. En variantes adicionales, dicho sistema puede utilizarse con dos o más unidades de modificación de flujo y/o con dos o más puntos de sincronización multimedia. Se pueden utilizar diferentes protocolos para transportar los mensajes de señalización (por ejemplo, los mensajes de información de estado de sincronización, los mensajes que contienen la información que correlaciona las diferentes marcas de tiempo, las instrucciones de configuración de sincronización) a través de la red. Estos mensajes pueden, por ejemplo, transmitirse en formato XML utilizando SOAP sobre HTTP (recomendación W3C), en formato XML o en texto sin formato en un cuerpo de mensaje MIME en un mensaje SIP (IETF RFC 3261) o en mensajes RTCP.
En el ejemplo descrito con referencia a las Figuras 2 y 3, la unidad de retardo variable y la unidad de sincronización se ponen en práctica en un modelo de tipo cliente-servidor en donde la funcionalidad de la unidad de retardo variable en un punto de sincronización puede ponerse en práctica como parte de un cliente de sincronización (SC) y en donde la unidad de sincronización puede ponerse en práctica como un servidor de sincronización (SYNCHS o Servidor de aplicaciones de sincronización multimedia (MSAS)). El cliente de sincronización puede tener una conexión de protocolo que permite enviar información de estado de sincronización utilizando un protocolo adecuado al servidor de sincronización (unidad de sincronización) e instrucciones de configuración de sincronización que se recibirán desde el servidor de sincronización.
La información del estado de sincronización puede incluir información de temporización en la recepción del flujo (es decir, la hora de llegada de un paquete en un flujo que llega a un primer punto de sincronización) y puede incluir los ajustes de retardo actuales. Por lo tanto, la información del estado de sincronización puede comprender información con respecto a un punto en el tiempo en donde un paquete en el flujo fue recibido por el punto de sincronización. Las instrucciones de configuración de sincronización pueden incluir instrucciones sobre cómo configurar la memoria intermedia de retardo variable utilizando, por ejemplo, el retardo calculado real.
Los términos de instrucciones de configuración de sincronización e instrucciones de retardo son términos utilizados de manera equivalente para el objeto de esta invención y pueden comprender el tiempo de retardo real de un cierto flujo multimedia. Preferiblemente, estas instrucciones de retardo pueden contener un valor de tiempo positivo asociado con el retardo de un flujo multimedia durante una duración predeterminada. De manera alternativa, las instrucciones de retardo pueden contener un valor de tiempo negativo asociado con la aceleración de la reproducción o salida de un flujo multimedia. Este puede ser el caso, cuando cierto punto de sincronización contiene una gran memoria intermedia y permite acortar el retardo al disminuir el tiempo de memorización intermedia utilizando medidas conocidas.
La Figura 4 representa un sistema de entrega de contenido, a modo de ejemplo, de conformidad con la invención puesto en práctica como un sistema 400 de IPTV basado en IMS tal como se especifica en ETSI TS 182027 versión 2.0.0. El sistema 400 de IPTV comprende una función multimedia de IPTV (MF) 401, que contiene una función de control multimedia (MCF) 402 y una función de entrega multimedia (MDF) 403. Además, comprende funciones de transporte (TF) 404, equipos de usuario (UE) 405, una función de control de servicio de IPTV (SCF) 406, un servidor de aplicaciones separado (AS) 407 y una red IMS central (Core) 408. Un cliente de sincronización (SC) 409 puede ser parte de un equipo UE 405 o ser parte de las funciones de transporte 404. Si un equipo de usuario es capaz de memorizar en memoria intermedia un flujo como parte del método de sincronización, el SC puede ponerse en práctica en el equipo de usuario. Los SC también pueden ponerse en práctica en la red de transporte, por ejemplo, cuando el equipo de usuario no admite una función de almacenamiento en memoria intermedia.
El cliente SC está asociado con al menos una memoria intermedia de retardo variable, por lo tanto, cuando se ponen en práctica un SC en un UE, también puede comprender uno o más memorias intermedias de retardo variable asociadas 410. Del mismo modo, si el cliente SC se pone en práctica como parte de la función de transporte, el elemento que comprende la función de transporte también puede comprender una o más memorias intermedias de retardo variable 410. La funcionalidad del MSAS 411 puede incluirse en una función de control de servicio IPTV estándar 406, como parte de la función de transporte o de la función multimedia o, de manera alternativa, puede ponerse en práctica en un servidor de aplicaciones autónomo 407. Una unidad de modificación de flujo multimedia (MSMU) 413 puede ser parte de la función multimedia IPTV 401. La función MDF 403 puede realizar la transcodificación real, mientras que el MCF 402 puede contener el cliente de sincronización (SC’) 412.
La Figura 5 representa una puesta en práctica del sistema 500 de sincronización entre destinos según una forma de realización de la invención en donde el protocolo de control RTCP RTP (RTCP) se utiliza para transmitir información de sincronización entre elementos en un sistema de distribución multimedia. El sistema consta de dos clientes de sincronización SCa, SCb 502, 504. Los clientes de sincronización están configurados para señalizar información de estado de sincronización asociada con un primer y segundo flujo multimedia 512, 514 a un MSAS 508. Los dos clientes de sincronización residen en dos Equipos de Usuario (UE) (no ilustrados) que reciben los dos flujos multimedia RTP diferentes, que pueden tener diferentes tasas de muestreo. Un primer flujo multimedia 512 recibido por SCa, puede ser un flujo multimedia original asociado con un origen de flujo multimedia (es decir, un servidor multimedia) y un segundo flujo multimedia 514 recibido por SCb, puede ser un flujo multimedia modificado. Una unidad de modificación de flujo multimedia (transcodificador) 502, que modifica el primer flujo multimedia en el segundo flujo multimedia, comprende un cliente de sincronización especial SC’ 510 que informa de la relación de sincronización entre el primer y el segundo flujo multimedia al MSAS.
El sistema puede utilizar SIP para configurar sesiones multimedia entre los equipos UEs, la unidad de modificación de flujo multimedia y un origen de flujo multimedia. El Protocolo de Descripción de Sesión (SDP) llevado por la señalización SIP puede utilizarse para describir y negociar los componentes multimedia en cada sesión. Durante la configuración, los equipos UEs (y la unidad de modificación del flujo multimedia) pueden asociarse con un SyncGroupId, que identifica el grupo de sincronización al que pertenece el equipo UE específico.
Un grupo de sincronización es un grupo de equipos UEs que requieren ser sincronizados con respecto a uno o más flujos multimedia designados. Un ejemplo de dicho grupo puede ser dos equipos UEs pertenecientes a dos usuarios diferentes en dos ubicaciones diferentes que solicitan ver el mismo contenido bajo demanda (película) conjuntamente de manera sincronizada.
Además, los equipos UEs y la unidad de modificación de flujo multimedia, en particular los clientes de sincronización ubicados en la misma, pueden utilizar el Protocolo de Control RTP (RTCP) para transmitir información de sincronización a la dirección IP y número de puerto asociado con el MSAS y recibir informes del RTCP desde el servidor MSAS en un puerto receptor RTCP asociado con un equipo UE. En una forma de realización, el cliente de sincronización puede incluir información de estado de sincronización en sus informes de receptor RTCP (RTCP RR) utilizando informes extendidos de RTCP (RTCP XR) y enviar esta información en uno o más mensajes RTCP al MSAS.
En particular, un cliente de sincronización puede generar un informe extendido de RTCP especialmente formateado (RTCP XR) 516, 518 que comprende información de estado de sincronización. Esta información puede estar en la forma de marcas de tiempo RTP combinadas con marcas de tiempo NTP. El RTCP XR puede comprender, además, el SSRC de origen, la marca de tiempo NTP de paquete recibido, la marca de tiempo RTP de paquete recibido (marca de tiempo de recepción RTP) y, de manera opcional, un parámetro SyncGroupId. Además, puede comprender la marca de tiempo de NTP de paquete presentado (marca de tiempo de presentación de NTP) en el XR.
El parámetro SyncGroupId puede ponerse en práctica como un atributo de nivel de sesión del protocolo de descripción de sesión (SDP), por ejemplo, a = RTCP-xr: sync-group = <valor> o, por ejemplo, en forma de elementos SDES PRIV de conformidad con IETF RFC 3550. En una forma de realización adicional, se puede utilizar el campo de atributo RTCP-xr conocido a partir de IETF RFC 3611.
El cliente de sincronización asociado con la unidad de modificación de flujo multimedia SC’ comunica la información de correlación de sincronización al MSAS. A diferencia de los clientes de sincronización asociados con los UEs, SC’ transmite RTCP XR asociados con uno o más flujos multimedia en la entrada del transcodificador y RTCP XR asociados con uno o más flujos multimedia en la salida del transcodificador. Por lo general, la información de correlación de sincronización 520 está formada por dos RTCP XR, un primer RTCP XR 522 asociado con un flujo de entrada y un segundo RTCP XR 524 asociado con un flujo de salida (es decir, el flujo de entrada modificado). Por lo tanto, la información de correlación de sincronización puede comprender dos conjuntos de marcas de tiempo (RTP1, NTP1) y (RTP2, NTP2), una asociada con un flujo de entrada y otra asociada con un flujo de salida.
El MSAS puede enviar, además, XR RTCP que comprenden instrucciones de configuración de sincronización a los clientes de sincronización SCa, SCb. Estos RTCP XR pueden incluir el SSRC de origen, la marca de tiempo NTP de paquete recibido de referencia y la marca de tiempo de recepción de marca de tiempo RTP de paquete recibido de referencia. Puede comprender, además, una marca de tiempo NTP de paquete presentado de referencia. Estos XRs de RTCP se pueden añadir a los informes de remitente (SR) de RTCP o un equipo UE puede recibirlos por separado.
En una forma de realización, un cliente de sincronización puede ubicarse conjuntamente con el MSAS. En ese caso, el intercambio de información de estado de sincronización e instrucciones de configuración de sincronización es interno a una o más entidades funcionales del MSAS en donde residen.
En otra forma de realización, la sincronización puede relacionar la sincronización de uno o más flujos de difusión. En ese caso, el MSAS puede funcionar como un objetivo de retroalimentación tal como se describe con más detalle en RFC 3550. Antes de reenviar los informes del receptor RTCP, el MSAS puede leer y eliminar los informes extendidos RTCP que contienen información de estado de sincronización. Con posterioridad, el MSAS puede enviar instrucciones de configuración de sincronización al cliente de sincronización mediante informes extendidos RTCP.
En caso de sincronización de contenido bajo demanda u otros flujos de unidifusión, el MSAS puede reenviar informes de receptor RTCP asociados con uno o más equipos UEs a la función multimedia apropiada MF. Antes de reenviar los informes del receptor RTCP, el MSAS puede leer y analizar el RTCP XR y eliminar esos informes extendidos RTCP que contienen información del estado de sincronización. Con posterioridad, el MSAS puede reenviar informes de remitente RTCP a los clientes de sincronización apropiados, añadiendo instrucciones de configuración de sincronización al SC mediante el informe extendido RTCP. El MSAS puede enviar instrucciones de configuración de sincronización a los clientes de sincronización utilizando un RTCP XR separado.
La Figura 6 representa un ejemplo de informe extendido RTCP para comunicar información de sincronización en un flujo multimedia RTP de conformidad con una forma de realización de la invención. Los siguientes campos en la sincronización RTCP XR pueden utilizarse en el sistema de sincronización de conformidad con la invención:
- Un SSRC del remitente del paquete que identifica al remitente del paquete RTCP específico.
- Un campo de tipo de bloque (BT) que comprende 8 bits para identificar el formato de bloque.
- Un campo tipo de remitente del paquete de sincronización (SPST) que comprende 4 bits para identificar la función del remitente del paquete para este informe extendido específico.
- Un indicador de marca de tiempo NTP de paquete presentado (P) que se puede establecer en 1 si la marca de tiempo NTP de paquete presentado contiene un valor. Si este indicador se pone a cero, la marca de tiempo NTP de paquete presentado no se inspeccionará.
- Un campo de tipo de carga útil (PT) que comprende 7 bits para identificar el formato de la carga útil multimedia.
La carga útil multimedia puede estar asociada con una frecuencia de reloj de marca de tiempo RTP, que proporciona la base de tiempo para el contador de marca de tiempo RTP.
- Un identificador de correlación de flujo multimedia (32 bits) para utilizar en la correlación de flujos multimedia sincronizados. Si el remitente de paquetes RTCP es un SC o un MSAS (SPST = 1 o SPST = 2), el identificador de correlación de flujo multimedia se asigna en el parámetro SyncGroupId. Si el remitente de paquetes RTCP es un SC’ (SPST = 3 o SPST = 4), los flujos multimedia entrantes y salientes relacionados pueden tener el mismo identificador de correlación de flujo multimedia.
- Un SSRC de fuente multimedia (32 bits) puede establecerse en el valor del identificador SSRC transportado en la cabecera RTP del paquete RTP con el que se relaciona el XR.
- Una marca de tiempo NTP de paquete recibido (64 bits) puede representar la hora de llegada del primer byte del paquete RTP con el que se relaciona el XR.
- Una marca de tiempo RTP de paquete recibido (32 bits) está asociada con el valor de la marca de tiempo RTP incluida en la cabecera RTP del paquete RTP con el que se relaciona el XR.
- Una marca de tiempo NTP de paquete presentado (32 bits) refleja el tiempo NTP cuando los datos contenidos en el primer byte del paquete RTP asociado pueden presentarse al usuario. Comprende los 16 bits menos significativos de la segunda parte de NTP y los 16 bits más significativos de la segunda parte fraccional NTP. Si este campo está vacío, puede establecerse en 0 y el indicador de marca de tiempo NTP de paquete presentado (P) puede establecerse en 0.
La Tabla 1 ilustra los valores asociados con el campo de tipo de remitente del paquete de sincronización (SPST):
Tabla 1.
Figure imgf000011_0001
Utilizando los informes extendidos RTCP especialmente formateados tal como se describe con referencia a la Figura 6, la información de sincronización puede señalizarse de manera eficiente entre clientes en la red o uno o más equipos UEs y el MSAS. Por ejemplo, en el sistema representado en la Figura 5, los clientes de sincronización SCa, SCb 504, 506 asociados con los equipos UEs y el cliente de sincronización SC’ 510 asociado con la unidad de modificación del flujo multimedia pueden utilizar el RTCP XR para comunicar información de sincronización (es decir, información de estado de sincronización o información de correlación de sincronización) al MSAS. La Tabla 2 proporciona un ejemplo de esta información:
Tabla 2
Figure imgf000011_0002
Los flujos multimedia pueden identificarse por su fuente de sincronización (identificador SSRC): SSRCa = SSRC1 y SSRCb = SSRC2. De esta manera, el MSAS puede deducir que SCa recibe el primer flujo multimedia y que SCb recibe el segundo flujo multimedia. Además, cada flujo multimedia puede estar asociado con una frecuencia de reloj específica, que puede expresarse en Hz (es decir, latidos de reloj por segundo): CRa = CR1 y CRb = CR2. Las frecuencias de reloj típicas están dentro del margen entre 8000 y 96000 muestras por segundo para audio y 90,000 muestras por segundo para vídeo.
En una forma de realización, la frecuencia de reloj puede señalizarse al MSAS. En otras formas de realización, las frecuencias son constantes. En otra forma de realización adicional, el tipo de carga útil en lugar de la frecuencia de reloj puede señalizarse al MSAS. El tipo de carga útil se puede asignar a una frecuencia de reloj utilizando, por ejemplo, sistemas descritos en IETF RFC 3551. La información notificada al MSAS puede incluir, además, marcas de tiempo RTP y marcas de tiempo NTP.
El SC’ informa de dos conjuntos de marcas de tiempo (RTP1, NTP1) y (RTP2, NTP2), una para cada flujo multimedia, al MSAS. NTP1 representa el tiempo que el byte identificado por RTP1 ha pasado el punto específico en el SC’ y NTP2 representa el tiempo en que el byte identificado por RTP2 ha pasado el punto específico en el SC'. Estos suelen ser bytes diferentes debido a la transcodificación y al cambio de la frecuencia del reloj. El SC’ tiene que hacer un cálculo para determinar NTP1 y NTP2, con el fin de determinar cuándo el punto en el contenido, representado por el byte identificado, pasa el punto específico.
El MSAS puede utilizar el algoritmo: Playout SCa - Playout SCb = (NTPa -(RTPa/CRa) -(NTPb -(RTPb/CRb) -(NTP1 - (RTP1/CR1) (NTP2 - (RTP2/CR2)) para determinar la diferencia entre la reproducción de SCa y SCb en milisegundos. El resultado puede utilizarse para indicar a SCa o SCb que retarden su reproducción en la magnitud especificada, con el fin de que sus reproducciones estén suficientemente sincronizadas.
El uso de los parámetros del ejemplo en la tabla 3 da como resultado un retardo (Playout SCa - Playout SCb) de -5,493 segundos, lo que indica que SCb se reproduce 5,493 segundos más tarde que SCa. Por lo tanto, sobre la base de este cálculo, el MSAS puede indicar a SCa que retarde su salida en 5.493 segundos para sincronizarse de manera sustancial.
Tabla 3
Figure imgf000012_0001
La Figura 7 representa el uso de mensajes RTCP XR para sincronizar el flujo multimedia según otra forma de realización de la invención. En este ejemplo, un único dispositivo de codificación 702 puede contener múltiples unidades de modificación de flujo multimedia. El dispositivo de codificación puede estar asociado con múltiples flujos multimedia entrantes 708, 710 y flujos multimedia salientes 712-716, que pueden ser sincronizados por un único cliente de sincronización SC’ 704.
Para cada flujo multimedia entrante A1, B4, ... y para cada flujo multimedia saliente A2, A3, B5, ... el cliente de sincronización SC’ puede enviar un RTCP XR 718-724 al MSAS 706. Por lo tanto, en esta forma de realización, la información de correlación de sincronización se envía en dos RTCP XRs al MSAS: un primer RTCP XR 724, 726 asociado con el flujo multimedia entrante 708, 710 y un segundo RTCP XR 718-722 asociado con el flujo multimedia saliente 712-716.
Este sistema de señalización tiene la ventaja de que los RTCP XRs pueden enviarse independientemente en diferentes momentos y a diferentes velocidades al MSAS. Si un flujo multimedia tiene una referencia de tiempo más constante, entonces su información de correlación de sincronización puede actualizarse con menos frecuencia, lo que ahorra tiempo de procesamiento y ancho de banda. Además, si un flujo multimedia entrante se transcodifica en múltiples flujos multimedia salientes diferentes, entonces la parte de la información de correlación de sincronización relacionada con el flujo multimedia entrante debe medirse y enviarse solamente una vez, lo que ahorra tiempo de procesamiento y ancho de banda.
Sin embargo, enviar las diferentes partes (RTCP XR) de la información de correlación de sincronización de forma independiente puede plantear un problema puesto que el MSAS no tiene conocimiento de qué partes de la información de correlación de sincronización están relacionadas. En ese caso, el MSAS no puede determinar qué partes de la información de correlación de sincronización pertenecen conjuntamente.
Por esa razón, el cliente de sincronización SC’ genera un identificador de correlación de flujo multimedia (MSCI) con el fin de permitir que el MSAS correlacione los diferentes flujos multimedia a la entrada y salida del dispositivo de transcodificación y obtenga la información de correlación de sincronización correcta a partir de los diferentes RTCP XRs recibidos por el MSAS. Por ejemplo, en la Figura 7, el MSAS puede utilizar MSCIA para correlacionar RTCP XR 726 asociado con el flujo multimedia 710 con el primer RTCP XR 718 asociado con el flujo multimedia 712 (modificado) y el segundo RTCP XR 720 asociado con el flujo multimedia 714 modificado. De este modo, la sincronización eficiente de múltiples flujos multimedia modificados puede conseguirse. Conviene señalar que la sincronización entre diferentes flujos relacionados puede no solamente ser ventajosa para diferentes usuarios que utilizan diferentes dispositivos de reproducción con diferentes capacidades y que desean experimentar la misma difusión en el mismo momento, sino que también puede ser beneficioso para un usuario único que conmuta entre dos o más redes que transportan diferentes flujos relacionados. Esta conmutación puede producirse, por ejemplo, cuando un usuario utiliza una red móvil con cobertura deficiente. Si un usuario pierde su conexión a esa red, es posible que desee conmutarse a otra red, por ejemplo, otra red móvil con cobertura mejorada. Un ejemplo de dicha conmutación de red puede ser la conmutación entre una red DVB-H (Digital Vídeo Broadcast - Handheld) y una red UMTS. La conmutación también puede ocurrir entre una red móvil y una red fija, por ejemplo, cuando un usuario que mira una transmisión de vídeo a través de una red móvil, llega a casa y quiere seguir viendo en su televisor de pantalla grande conectado a una red fija. La cancelación de retardos entre diferentes flujos relacionados puede proporcionar transiciones de red sin interrupciones y una mejor experiencia del usuario.
Cualquier característica descrita en relación con cualquier forma de realización puede utilizarse sola, o en combinación con otras características descritas, y también puede utilizarse en combinación con una o más características de cualquier otra de las formas de realización, o cualquier combinación de cualquier otra de las formas de realización. Además, los equivalentes y modificaciones no descritos con anterioridad también pueden emplearse sin desviarse por ello del alcance de la invención, que se define en las reivindicaciones adjuntas.
Por ejemplo, el método de sincronización según la invención puede ponerse en práctica como un proceso continuo que funciona, por ejemplo, en una red completa o partes de la misma, u operando en todos los flujos que se desplazan a través de la red o ciertos flujos solamente. Además, la operación continua puede afectar a todos los puntos de sincronización o solamente a ciertos puntos de sincronización. El método puede ponerse en práctica configurando el sistema para funcionar en este modo continuo.
Como alternativa, el método puede ponerse en práctica como un proceso de sincronización de tipo sesión utilizando, por ejemplo, un modelo de tipo cliente-servidor. Las sesiones de sincronización pueden, por ejemplo, iniciarse o finalizarse a través de ciertos dispositivos accionadores dentro de la red. Los activadores para iniciar o finalizar una sesión de sincronización pueden proporcionarse, por ejemplo, mediante puntos de sincronización o mediante otros elementos dentro de la red o sistema.
En una forma de realización, el servidor de sincronización y el cliente de sincronización pueden configurarse para iniciar y finalizar sesiones de sincronización. Se puede iniciar una sesión de sincronización cuando un cliente de sincronización envía un mensaje de invitación al servidor de sincronización, o viceversa. Durante una sesión de sincronización, el servidor de sincronización y el cliente de sincronización pueden intercambiar información de estado de sincronización e instrucciones de configuración de sincronización. Una sesión de sincronización puede finalizar cuando el cliente de sincronización envía un mensaje de terminación al servidor de sincronización, o viceversa. Un servidor de sincronización y un cliente de sincronización pueden enviar mensajes de retorno para aceptar la invitación o para confirmar la finalización de una sesión de sincronización.

Claims (16)

REIVINDICACIONES
1. Método para permitir la sincronización entre destinos de al menos un primer y al menos un segundo flujo, estando asociado dicho segundo flujo con el flujo de salida de una unidad de modificación de flujo multimedia utilizando dicho primer flujo como un flujo de entrada, con dicha unidad de modificación de flujo multimedia modificando la información de temporización de dicho primer flujo, cuyo método comprende las etapas de:
- proporcionar la primera información de hora de llegada de un paquete en el primer flujo que llega a un primer punto de sincronización y la segunda información de hora de llegada de un paquete en el segundo flujo que llega a un segundo punto de sincronización a una unidad de sincronización para sincronizar dichos puntos de sincronización, estando dicha unidad de sincronización conectada a dicho primer y dicho segundo punto de sincronización, en donde dicha información de hora de llegada comprende una información de hora de llegada e información de temporización del paquete;
- proporcionar, por la unidad de modificación del flujo multimedia, información de correlación de sincronización sobre la relación de sincronismo entre dicho flujo de entrada y dicho flujo de salida a dicha unidad de sincronización;
- calculando dicha unidad de sincronización la información de retardo sobre la base de la primera y segunda información de hora de llegada y la información de correlación de sincronización;
- dicha unidad de sincronización proporciona al menos dicho primer o segundo punto de sincronización con dicha información de retardo, permitiendo que al menos dicho primer o segundo punto de sincronización retarde la salida de un flujo de manera que el primer y segundo flujos emitidos por el primer y segundo punto de sincronización, respectivamente, están sincronizados.
2. Método según la reivindicación 1, en donde dicha información de temporización del paquete es una marca de tiempo.
3. Método según las reivindicaciones 1 o 2, en donde la etapa de información de retardo de cálculo comprende, además, una etapa de ajuste para ajustar la primera y/o segunda información de hora de llegada para lograr una línea de tiempo común entre la primera información de hora de llegada y la segunda información de hora de llegada, estando dicha etapa de ajuste basada en al menos parte de la información de correlación de sincronización.
4. Método según la reivindicación 3, en donde la etapa de ajuste es ejecutada por un módulo de ajuste de información de hora de llegada, siendo dicho módulo parte de la unidad de sincronización, estando dicha unidad de sincronización provista de al menos parte de la información de correlación de sincronización.
5. Método según la reivindicación 3, en donde la etapa de ajuste es ejecutada por al menos uno de los puntos de sincronización, comprendiendo el al menos uno de los puntos de sincronización un módulo de ajuste de información de hora de llegada, estando dicho módulo de ajuste de información de hora de llegada provisto de al menos parte de la información de correlación de sincronización y estando la unidad de sincronización provista de una primera y/o segunda información de hora de llegada ajustada.
6. Método según la reivindicación 3, en donde la etapa de ajuste se ejecuta en un elemento de red, estando el elemento de red configurado para recibir información de hora de llegada, comprendiendo dicho elemento de red, además, un módulo de ajuste de información de hora de llegada, estando el módulo de ajuste de información de hora de llegada provisto de al menos parte de la información de correlación de sincronización y estando la unidad de sincronización provista de la segunda información de hora de llegada ajustada.
7. Método según cualquiera de las reivindicaciones anteriores, en donde el punto de sincronización es un terminal, un nodo de red o un nodo de acceso.
8. Método según cualquiera de las reivindicaciones anteriores, en donde la unidad de sincronización está comprendida en un punto de sincronización o un nodo de red, preferiblemente un servidor de sincronización.
9. Método según cualquiera de las reivindicaciones anteriores, en donde dicha información de hora de llegada, dicha información de correlación de sincronización y/o dicha información de retardo se señalizan en uno o más mensajes RTCP, preferiblemente uno o más informes extendidos RTCP.
10. Método según la reivindicación 9, en donde al menos uno de dichos mensajes RTCP comprende al menos un identificador que identifica al remitente del paquete, una marca de tiempo RTP, una marca de tiempo NTP, un valor de frecuencia de reloj y/o un identificador de correlación de flujo multimedia.
11. Una unidad de sincronización para sincronizar la salida de al menos un primer punto de sincronización que recibe un primer flujo multimedia y un segundo punto de sincronización que recibe un segundo flujo multimedia, siendo dicho segundo flujo multimedia el flujo de salida de una unidad de modificación de flujo multimedia utilizando el primer flujo multimedia como un flujo de entrada, comprendiendo la unidad de sincronización:
- una primera entrada para recibir la primera información de hora de llegada asociada con un paquete en el primer flujo multimedia, estando asociado dicho primer flujo multimedia con un primer punto de sincronización y la segunda información de hora de llegada de un paquete en el segundo flujo multimedia que llega a un segundo punto de sincronización, en donde dicha información de hora de llegada comprende una información de hora de llegada y temporización del paquete;
- una segunda entrada para recibir información de correlación de sincronización sobre la relación de sincronismo entre dicho flujo de entrada y dicho flujo de salida, siendo dicha información de correlación de sincronización proporcionada por la unidad de modificación del flujo; y
- un procesador para calcular la información de retardo sobre la base de la primera y segunda información de hora de llegada y la información de correlación de sincronización;
- una salida para enviar al menos uno de los puntos de sincronización primero y segundo con la información de retardo que permite que una o más unidades de retardo variables en el primer y segundo punto de sincronización retarden el tiempo de salida de los flujos recibidos de modo que estén sincronizados.
12. Unidad de sincronización según la reivindicación 11, en donde la información de temporización del paquete es una marca de tiempo.
13. Una unidad de sincronización según las reivindicaciones 11 o 12, en donde dicha información de hora de llegada, dicha información de correlación de sincronización y/o dicha información de retardo se señalizan en uno o más mensajes RTCP, preferiblemente uno o más informes extendidos RTCP.
14. Sistema para permitir la sincronización entre destinos de la salida de al menos un primer y un segundo punto de sincronización, comprendiendo el sistema:
- un servidor de entrega de contenido para entregar un flujo multimedia;
- al menos una unidad de sincronización de conformidad con una cualquiera de las reivindicaciones 11-13;
- una unidad de modificación de flujo configurada para modificar la información de temporización de un flujo multimedia de entrada en un flujo multimedia de salida modificado que comprende información de temporización modificada, y estando configurada para proporcionar información de correlación de sincronización sobre la relación de sincronismo entre dicho flujo de entrada y dicho flujo de salida a dicha unidad de sincronización.
15. Una unidad de modificación de flujo multimedia para utilizar en un sistema según la reivindicación 14, comprendiendo la unidad de modificación de flujo multimedia:
- medios para recibir un primer flujo multimedia;
- medios para modificar el primer flujo multimedia en un segundo flujo multimedia, sirviendo dichos medios para modificar el primer flujo multimedia también adaptado para modificar la información de temporización del primer flujo;
- medios para emitir dicho segundo flujo multimedia; en donde la unidad de modificación del flujo multimedia comprende, además, medios para proporcionar información de correlación de sincronización asociada con la relación de sincronismo entre el primer flujo multimedia y el segundo flujo multimedia.
16. Un producto de programa informático que comprende partes de código de software configuradas para, cuando se ejecuta en la memoria de un ordenador, ejecutar las etapas del método tal como se define en cualquiera de las reivindicaciones 1-10.
ES10708572T 2009-03-16 2010-03-16 Sincronización de flujo modificado Active ES2801698T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP09003751 2009-03-16
EP09015266 2009-12-09
PCT/EP2010/053407 WO2010106075A1 (en) 2009-03-16 2010-03-16 Modified stream synchronization

Publications (1)

Publication Number Publication Date
ES2801698T3 true ES2801698T3 (es) 2021-01-12

Family

ID=42045454

Family Applications (1)

Application Number Title Priority Date Filing Date
ES10708572T Active ES2801698T3 (es) 2009-03-16 2010-03-16 Sincronización de flujo modificado

Country Status (7)

Country Link
US (1) US20120036277A1 (es)
EP (1) EP2409432B1 (es)
JP (1) JP5284534B2 (es)
KR (1) KR101291990B1 (es)
CN (1) CN102356619B (es)
ES (1) ES2801698T3 (es)
WO (1) WO2010106075A1 (es)

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8218452B2 (en) * 2009-06-30 2012-07-10 Alcatel Lucent Network detection of real-time applications using incremental linear regression
US8458362B2 (en) 2010-09-30 2013-06-04 Comcast Cable Communications, Llc Delivering content in multiple formats
US9143539B2 (en) * 2010-11-18 2015-09-22 Interdigital Patent Holdings, Inc. Method and apparatus for inter-user equipment transfer of streaming media
CN102137275B (zh) * 2010-12-20 2012-12-19 华为技术有限公司 快速频道切换中快速推送单播流的方法和装置
US9582239B2 (en) 2011-01-21 2017-02-28 Qualcomm Incorporated User input back channel for wireless displays
US10135900B2 (en) * 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
US9413803B2 (en) 2011-01-21 2016-08-09 Qualcomm Incorporated User input back channel for wireless displays
US8677029B2 (en) 2011-01-21 2014-03-18 Qualcomm Incorporated User input back channel for wireless displays
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
ES2827183T3 (es) * 2011-04-28 2021-05-20 Voipfuture Gmbh Correlación del plano de medios y del plano de señalización de servicios de medios en una red con conmutación de paquetes
KR101405276B1 (ko) * 2011-08-10 2014-07-15 한국전자통신연구원 고정 및 이동 융합형 ３ｄｔｖ에서 좌／우 스트림을 동기화하는 컨텐츠 제공 장치 및 방법, 그리고, 컨텐츠 재생 장치 및 방법
US9380327B2 (en) * 2011-12-15 2016-06-28 Comcast Cable Communications, Llc System and method for synchronizing timing across multiple streams
JP5903924B2 (ja) * 2012-02-17 2016-04-13 ソニー株式会社 受信装置および字幕処理方法
KR101917174B1 (ko) * 2012-02-24 2018-11-09 삼성전자주식회사 전자 장치 사이의 스트림 전송 방법 및 그 방법을 처리하는 전자 장치
EP2850840A1 (en) * 2012-05-18 2015-03-25 Google Technology Holdings LLC Array of transcoder instances with internet protocol (ip) processing capabilities
US9055346B2 (en) 2012-05-18 2015-06-09 Google Technology Holdings LLC Array of transcoder instances with internet protocol (IP) processing capabilities
US9246692B2 (en) 2012-05-18 2016-01-26 Google Technology Holdings LLC Synchronizing multiple transcoding devices utilizing simultaneity of receipt of multicast packets
EP2670157B1 (en) 2012-06-01 2019-10-02 Koninklijke KPN N.V. Fingerprint-based inter-destination media synchronization
US9883361B2 (en) 2012-07-27 2018-01-30 Qualcomm Incorporated Delivering time synchronized arbitrary data in an RTP session
US9226011B2 (en) 2012-09-11 2015-12-29 Comcast Cable Communications, Llc Synchronizing program presentation
US10356143B2 (en) 2012-10-10 2019-07-16 Samsung Electronics Co., Ltd. Method and apparatus for media data delivery control
CN103139608B (zh) * 2013-01-21 2016-03-30 北京酷云互动科技有限公司 远程媒体播放信号时延的检测方法及检测系统
JP2014230154A (ja) * 2013-05-23 2014-12-08 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
EP2814259A1 (en) * 2013-06-11 2014-12-17 Koninklijke KPN N.V. Method, system, capturing device and synchronization server for enabling synchronization of rendering of multiple content parts, using a reference rendering timeline
EP3020204B1 (en) * 2013-07-09 2022-04-27 Koninklijke KPN N.V. Synchronized data processing between receivers
CN105723723B (zh) 2013-09-20 2019-01-08 皇家Kpn公司 在媒体流之间使时间线信息相互关联
EP3047652B1 (en) * 2013-09-20 2020-05-06 Koninklijke KPN N.V. Correlating timeline information between media streams
JP6349977B2 (ja) 2013-10-21 2018-07-04 ソニー株式会社 情報処理装置および方法、並びにプログラム
CN110891188B (zh) * 2013-12-11 2021-11-05 瑞典爱立信有限公司 用于同步媒体流的方法和系统
JP2017511014A (ja) 2014-01-02 2017-04-13 エルジー エレクトロニクス インコーポレイティド 放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法
CN104811824B (zh) * 2014-01-29 2018-05-04 上海数字电视国家工程研究中心有限公司 多媒体传输网络系统
JP6454683B2 (ja) * 2014-02-28 2019-01-16 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 音声通信端末、中間ノード、処理装置、接続方法およびプログラム
US9794313B2 (en) * 2014-05-09 2017-10-17 Cisco Technology, Inc. Methods and systems to facilitate synchronization of multiple media streams
US9774687B2 (en) * 2014-07-07 2017-09-26 Twilio, Inc. System and method for managing media and signaling in a communication platform
CN105554044B (zh) 2014-10-28 2019-01-15 国际商业机器公司 在本地对象存储节点中同步对象的方法及装置
US9295018B1 (en) * 2014-12-17 2016-03-22 Telefonaktiebolaget L M Ericsson (Publ) Communication network nodes and methods performed therein
EP3238456A1 (en) * 2014-12-22 2017-11-01 Koninklijke KPN N.V. Quality of media synchronization
US10484447B2 (en) 2014-12-24 2019-11-19 Ribbon Communications Operating Company, Inc. Methods and apparatus for communicating delay information and minimizing delays
US20150326636A1 (en) * 2015-05-08 2015-11-12 Bandwidth.Com, Inc. Optimal use of multiple concurrent internet protocol (ip) data streams for voice communications
US11212333B1 (en) * 2015-05-29 2021-12-28 Ribbon Communications Operating Company, Inc. Methods and apparatus for synchronizing transcoded and/or transrated RTP packets
KR101656871B1 (ko) * 2015-08-18 2016-09-13 광운대학교 산학협력단 미디어 데이터 스트림을 동기화시키기 위한 방법, 동기화 서버 및 컴퓨터 판독 가능한 기록매체
CN109690674B (zh) * 2016-09-08 2021-05-11 索尼公司 信息处理装置、信息处理方法和程序
US20180146222A1 (en) * 2016-11-23 2018-05-24 Akamai Technologies, Inc. Systems and methods for demultiplexing and multiplexing multimedia streams that have spurious elementary streams
JP2018164294A (ja) * 2018-06-20 2018-10-18 マクセル株式会社 放送番組の視聴予約および映像デコードの制御方法
US11032367B2 (en) * 2018-07-16 2021-06-08 Microsoft Technology Licensing, Llc Long upload time detection and management
KR20210097285A (ko) * 2020-01-30 2021-08-09 삼성전자주식회사 이동통신 네트워크의 미디어 처리 및 전송에 대한 지연을 할당하기 위한 장치와 방법
US11316912B2 (en) * 2020-05-26 2022-04-26 Grass Valley Canada System and method for synchronizing transmission of media content using timestamps
CN113473162B (zh) * 2021-04-06 2023-11-03 北京沃东天骏信息技术有限公司 一种媒体流的播放方法、装置、设备和计算机存储介质
CN117676219A (zh) * 2022-08-29 2024-03-08 华为技术有限公司 一种数据传输方法及装置

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6360271B1 (en) * 1999-02-02 2002-03-19 3Com Corporation System for dynamic jitter buffer management based on synchronized clocks
US6493872B1 (en) * 1998-09-16 2002-12-10 Innovatv Method and apparatus for synchronous presentation of video and audio transmissions and their interactive enhancement streams for TV and internet environments
US7200857B1 (en) * 2000-06-09 2007-04-03 Scientific-Atlanta, Inc. Synchronized video-on-demand supplemental commentary
US6724825B1 (en) * 2000-09-22 2004-04-20 General Instrument Corporation Regeneration of program clock reference data for MPEG transport streams
US7269338B2 (en) * 2001-12-11 2007-09-11 Koninklijke Philips Electronics N.V. Apparatus and method for synchronizing presentation from bit streams based on their content
US7114173B2 (en) * 2002-05-03 2006-09-26 Aol Time Warner Interactive Video Group, Inc. Technique for synchronizing deliveries of information and entertainment in a communications network
US7084898B1 (en) * 2003-11-18 2006-08-01 Cisco Technology, Inc. System and method for providing video conferencing synchronization
JP2005244605A (ja) * 2004-02-26 2005-09-08 Nippon Telegr & Teleph Corp <Ntt> ストリーミングコンテンツ配信制御システム、プログラム及び該プログラムを格納した記録媒体
US8606949B2 (en) * 2005-04-20 2013-12-10 Jupiter Systems Interconnection mechanism for multiple data streams
DE102005039366B4 (de) * 2005-06-24 2008-10-09 Infineon Technologies Ag Telekommunikations-Endgerät, Telekommunikationssystem, Telekommunikationssitzungs-Servereinheit, Verfahren zum Erzeugen und Senden einer Telekommunikationssitzungs-Nachricht, Verfahren zum Verwalten einer Telekommunikationssitzungs-Nachricht, Computerlesbare Speichermedien und Computerprogrammelemente
CN100442858C (zh) * 2005-10-11 2008-12-10 华为技术有限公司 分组网络中多媒体实时传输的唇同步方法及其装置
US20100169786A1 (en) * 2006-03-29 2010-07-01 O'brien Christopher J system, method, and apparatus for visual browsing, deep tagging, and synchronized commenting
CN101179484A (zh) * 2006-11-09 2008-05-14 华为技术有限公司 一种不同媒体流间的同步方法及系统
US7953118B2 (en) * 2006-12-08 2011-05-31 Microsoft Corporation Synchronizing media streams across multiple devices
US8301790B2 (en) * 2007-05-30 2012-10-30 Randy Morrison Synchronization of audio and video signals from remote sources over the internet
US20080320545A1 (en) * 2007-06-22 2008-12-25 Schwartz Richard T System and method for providing audio-visual programming with alternative content
US20080317439A1 (en) * 2007-06-22 2008-12-25 Microsoft Corporation Social network based recording
US7936790B2 (en) * 2007-08-30 2011-05-03 Silicon Image, Inc. Synchronizing related data streams in interconnection networks
JP5241846B2 (ja) * 2007-10-23 2013-07-17 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ 終端端末のグループの同期方法およびシステム
CN102017652B (zh) * 2008-02-29 2015-05-13 奥迪耐特有限公司 用于在媒体网络中使用的网络设备、方法和/或系统
US20090257455A1 (en) * 2008-04-15 2009-10-15 Tellabs Operations, Inc. Method and apparatus for synchronizing timing of signal packets
US8141115B2 (en) * 2008-12-17 2012-03-20 At&T Labs, Inc. Systems and methods for multiple media coordination
US8606953B2 (en) * 2010-10-04 2013-12-10 Dialogic Corporation Adjusting audio and video synchronization of 3G TDM streams

Also Published As

Publication number Publication date
CN102356619A (zh) 2012-02-15
EP2409432A1 (en) 2012-01-25
KR101291990B1 (ko) 2013-08-09
JP5284534B2 (ja) 2013-09-11
US20120036277A1 (en) 2012-02-09
EP2409432B1 (en) 2020-05-06
KR20110125674A (ko) 2011-11-21
CN102356619B (zh) 2016-11-09
JP2012520648A (ja) 2012-09-06
WO2010106075A1 (en) 2010-09-23

Similar Documents

Publication Publication Date Title
ES2801698T3 (es) Sincronización de flujo modificado
US9237179B2 (en) Method and system for synchronizing the output of terminals
JP5635626B2 (ja) メディア・ストリームの同期のための方法、システム及び装置
US11758209B2 (en) Video distribution synchronization
EP2832109B1 (en) Marker-based inter-destination media synchronization
ES2796873T3 (es) Correlacionar información de línea de tiempo entre flujos de medios
JP5363473B2 (ja) 改善されたメディア・セッション管理の方法と装置
Stokking et al. IPTV inter-destination synchronization: A network-based approach
EP2479984A1 (en) Device and method for synchronizing content received from different sources
KR102271686B1 (ko) 이종 네트워크 기반의 멀티미디어 자원 동기화 푸시 방법
Stokking et al. Standardization of inter-destination media synchronization
EP2068528A1 (en) Method and system for synchronizing the output of end-terminals