MX2008002738A - Metodo que indica a dispositivo que no realice sincronizacion y que no incluye retraso de sincronizacion en flujos multimedia. - Google Patents

Metodo que indica a dispositivo que no realice sincronizacion y que no incluye retraso de sincronizacion en flujos multimedia.

Info

Publication number
MX2008002738A
MX2008002738A MX2008002738A MX2008002738A MX2008002738A MX 2008002738 A MX2008002738 A MX 2008002738A MX 2008002738 A MX2008002738 A MX 2008002738A MX 2008002738 A MX2008002738 A MX 2008002738A MX 2008002738 A MX2008002738 A MX 2008002738A
Authority
MX
Mexico
Prior art keywords
multimedia streams
synchronization
receiving device
attribute
multimedia
Prior art date
Application number
MX2008002738A
Other languages
English (en)
Inventor
David Leon
Igor Danilo Diego Curcio
Umesh Chandra
Original Assignee
Nokia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Corp filed Critical Nokia Corp
Publication of MX2008002738A publication Critical patent/MX2008002738A/es

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • 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/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5603—Access techniques

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)

Abstract

Un sistema o metodo mejorado que permiten que un dispositivo electronico de transmision indique, de manera explicita, cuales flujos en un flujo multimedia que esta siendo transmitido no deben ser sincronizados ni deben incluir una cantidad especifica de fluctuacion de sincronizacion. La presente invencion ayuda al dispositivo de recepcion para entender las caracteristicas de flujo. La presente invencion tambien permite que el dispositivo de recepcion tome una decision informada en cuanto a si el valor de la fluctuacion de sincronizacion debe ser utilizado cuando se realice la sincronizacion de dos o mas flujos. Par ciertas aplicaciones, tales como el comportamiento de video unidireccional, o el Poc de video, el dispositivo de emision del flujo puede indicar al dispositivo de recepcion que no realice ninguna sincronizacion ni una sincronizacion limitada para una mejor calidad de los medios.

Description

MÉTODO QUE INDICA A DISPOSITIVO QUE NO REALICE SINCRONIZACIÓN Y QUE NO INCLUYA RETRASO DE SINCRONIZACIÓN EN FLUJOS MULTIMEDIA Campo de la Invención La presente invención se refiere, de manera general, al campo de la comunicación multimedia IP. De manera más particular, la presente invención se refiere a un mecanismo de señalización o indicación que es utilizado en la comunicación multimedia para instruir a un dispositivo de recepción que no realice la sincronización ni que incluya una fluctuación de sincronización entre distintos flujos multimedia.
Antecedentes de la Invención Durante el establecimiento de una llamada multimedia IP, el dispositivo de emisión (es decir, el oferente u originador) de la llamada detalla la información de sesión. La información de sesión comprende los medios y la información relacionada con el transporte. Esta información de sesión es llevada en mensajes de protocolo tales como el Protocolo de Descripción de Sesión (SDP, por sus siglas en inglés) . El SDP es llevado en un protocolo de señalización de alto nivel, tal como el Protocolo de Iniciación de Sesión (SIP) , el Protocolo de Transferencia en Tiempo Real (RTSP) , REF. S190778 etc. El Proyecto Compartido de Tercera Generación (3GPP) ha especificado el protocolo SIP como la elección del protocolo de señalización para el establecimiento de una sesión multimedia para un Subsistema Multimedia IP (IMS) . En el SDP, el dispositivo de emisión y el dispositivo de recepción pueden especificar diferentes direcciones para los flujos de medios ocasionando distintos tipos de aplicaciones. Por ejemplo, si el dispositivo de emisión deseara establecer una sesión multimedia en una dirección (lo que significa que quiere enviar video y espera que el dispositivo de recepción sólo reciba este video) , el dispositivo detalla en el SDP este flujo de medios como a=sendonly. Cuando el dispositivo de recepción admite este mensaje SDP y si quisiera participar en esta sesión, podría especificar el flujo como a=recvonly. Para las llamadas de telefonía de video, el dispositivo de emisión y el dispositivo de recepción especifican las direcciones de los flujos de medios como a=sendrecv. De manera general, en una llamada multimedia IP, existe la necesidad de sincronizar diferentes tipos de medios en el lado del dispositivo de recepción. Por ejemplo, en una llamada de audio/video IP, la sincronización labial necesita ser realizada en el lado del dispositivo de recepción para una buena experiencia del usuario. Otro ejemplo para la sincronización involucra el uso de subtítulos; si el emisor del audio y/o video estuviera hablando en idioma Inglés y, si fuera enviado junto con la conversación un texto de la conversación en un idioma diferente en un flujo diferente de Protocolo de Transporte en Tiempo Real (RTP), entonces, se requeriría que éstos dos flujos sean sincronizados en el dispositivo de recepción. Diferentes flujos de medios (que provienen del lado del dispositivo de emisión) son llevados en distintos flujos de RTP/Protocolo de Datos de Usuario (UDP) /Protocolo de la Internet (IP) . Los relojes fechadores RTP son utilizados por los clientes del dispositivo de recepción para realizar una sincronización entre los medios. La Figura 1 representa un dispositivo de recepción que admite flujos multimedia que provienen de un dispositivo de emisión. El eje horizontal representa el tiempo transcurrido y muestra los paquetes que están siendo recibidos . La memoria intermedia de audio y video mostrada en la Figura 1, mantiene los paquetes RPT a medida que recibe los mismos a partir del dispositivo de emisión. La memoria intermedia realiza una remoción de fluctuación (de la red) y calcula el tiempo terminado para cada paquete para cada medio. El proceso de decodificación es realizado una vez que el paquete haya permanecido en la memoria intermedia durante un período dado de tiempo. Este periodo de tiempo es generalmente variable y parte de este periodo de tiempo es referido como la fluctuación. Una vez que la decodificación sea completada en base al tiempo terminado, los paquetes son proporcionados para su visualización o para su reproducción. Debe observarse que pueden existir dos tipos diferentes de memorias intermedias para la retención de los paquetes de entrada RTP, una para la hilera de fluctuación y otra para la hilera de la decodificación. Con propósitos de claridad y de ejemplo, sólo es mostrada una hilera en la Figura 1, que muestra una fluctuación y una memoria intermedia de decodificación combinada. Después que los paquetes sean decodificados, estos se encuentran preparados para su reproducción o visualización una vez que el tiempo terminado haya transcurrido. Sin embargo, si el dispositivo de recepción estuviera tratando de realizar la sincronización de audio/video, este intentaría retrasar los paquetes que hubieran llegado primero. En el ejemplo mostrado en la Figura 1, el paquete de audio 1 llega en TAI, y el paquete de video llega en TVl, el cual es posterior en tiempo de TAI. Debe observarse que el término "llega" puede referirse al tiempo en el que los paquetes llegan o al tiempo terminado para cada paquete. En el ejemplo de la Figura 1, los paquetes de audio y video, que tienen el mismo tiempo de reproducción, necesitan ser sincronizados debido a que tienen el mismo tiempo de captura de reloj de referencia (en el dispositivo de emisión) , lo que significa que fueron muestreados al mismo tiempo en el dispositivo de emisión. El cálculo del tiempo de captura de reloj de referencia es realizado utilizando el reloj fechador RTP en el paquete RTP y el reloj fechador NTP, el cual es enviado en los paquetes del Reporte de Emisor (SR) RTCP. Es altamente probable que los paquetes de audio y video lleguen al dispositivo de recepción en tiempos distintos, puesto que pueden tomar diferentes trayectorias de red, y el retraso del procesamiento (la codificación, la formación de paquetes, la despaquetización, la decodificación) para cada paquete puede ser diferente. Por lo tanto, en el ejemplo mostrado en la Figura 1, los paquetes de audio tienen que ser retrasados durante un periodo de tiempo de TVl-TAl, el cual es la fluctuación o retraso de sincronización. En el ejemplo mostrado en la Figura 1, si la aplicación (o emisor) no intentara realizar la sincronización A/V, aunque el dispositivo de recepción pretendiera realizar la sincronización (puesto que este es el comportamiento por omisión) , entonces, el dispositivo de recepción sería forzado a retener los paquetes de audio durante un tiempo adicional . Esta acción posiblemente puede sobrecargar o desbordar la memoria intermedia de audio. Además, los paquetes de audio en la parte delantera de la hilera son retrasados cuando sea intentada la sincronización, lo cual puede conducir a una experiencia de usuario o una calidad de medios mala. Si fuera garantizada la Calidad de Servicio (QoS) , entonces, los paquetes de audio y video podrían haber sido bajados en el caso que se hayan retrasado más en la hilera. Por lo tanto, aún cuando el dispositivo de emisión no pudiera desear que los flujos de medios fueran sincronizados, podrían presentarse problemas tales como la pérdida de paquete, los paquetes retrasados y el desperdicio de recursos de computación debido a la carencia de un mecanismo en donde el dispositivo de emisión pudiera indicar al dispositivo de recepción que no es requerida una sincronización o una sincronización retrasada. En la Petición de Comentarios (RFC) No. 3388 del Grupo de Trabajo de Red de la Fuerza de Tarea de Ingeniería de la Internet, es especificado un mecanismo en donde el dispositivo de emisión puede detallar de manera explícita cuáles de los flujos de medios en la sesión no necesitan ser sincronizados. Los nuevos atributos SDP son definidos (por ejemplo, "group", "mid" y la Sincronización Labial (LS) ) los cuales pueden • ayudar al dispositivo de emisión a especificar cuáles flujos de medios en la sesión no necesitan ser de sincronización labial. Asimismo, el comportamiento de implementación por omisión del dispositivo de recepción RTP es para sincronizar los flujos de medios que está recibiendo desde la misma fuente. Además, la especificación no impone que si alguien tuviera que sincronizar los flujos multimedia, entonces, sería requerida la RFC 3388. La petición RFC 3388 sólo especifica un mecanismo que puede permitir que el dispositivo de emisión detalle cuáles flujos necesitan ser sincronizados si éste estuviera enviando dos o más flujos. Existen aplicaciones y casos de uso en donde se requiere que los flujos multimedia no tengan que ser sincronizados. Por ejemplo, en aplicaciones de Compartimiento de Video en Tiempo Real (RTVS) , el usuario comienza una sesión de compartimiento de video unidireccional. Una sesión unidireccional de medios es establecida declarando el flujo de medios en el SDP como a=sendonly o a=recvonly. Existe una sesión de audio bidireccional (o puede ser unidireccional) establecida entre dos partes. Una de las partes en la llamada desea compartir video con la otra parte. El audio y video son establecidos en base al portador IP, aunque es posible que la sesión de audio o video también pueda ser establecida en base al portador conmutado de circuito. El video compartido puede ser a partir de un archivo o a partir de una vista de cámara en vivo . En algunos escenarios en el compartimiento de video unidireccional, el dispositivo de emisión no desea sincronizar el video (que está compartiendo a partir de un archivo) y la conversación o voz. Una razón para este deseo de no realizar la sincronización, podría ser que el dispositivo de emisión prefiriera que el video sea recibido con alta calidad en el dispositivo de recepción, aún cuando éste sea retrasado. En esta situación, el dispositivo de emisión podría preferir que el dispositivo de recepción tuviera una memoria intermedia de retraso más alto y por lo tanto, no quisiera realizar la sincronización. Otro ejemplo de compartimiento unidireccional de video involucra en donde el usuario está tomando video de algún objeto y hablando acerca de éste. En esta situación, una forma más burda de la sincronización debe ser suficiente más que una sincronización perfecta, debido a que la persona no está tomando video de su propia cara, sino que está filmando un objeto diferente. Todavía otro ejemplo involucra la "realidad aumentada", en donde los gráficos son mezclados con audio y video en tiempo real. En este caso, una forma más burda de sincronización sería suficiente. Si el comportamiento por omisión del cliente fuera para sincronizar estos dos flujos, entonces, el cliente del dispositivo de recepción emplearía algoritmos especiales para sincronizar estos flujos. El algoritmo de sincronización en el lado del dispositivo de recepción requeriría una cantidad específica de complejidad de cómputo, y el cliente desperdiciaría algunos recursos, aún cuando el dispositivo de emisión no prefiriera ninguna sincronización. El flujo de audio y de video puede llegar al dispositivo de recepción con distintos retrasos. Si el dispositivo de recepción intentara sincronizar los flujos, esto podría originar la caída de los cuadros de audio y video, reduciendo de esta manera la calidad de los medios recibidos. Desafortunadamente, la petición RFC 3388 no discute un mecanismo en donde pueda identificarse con claridad cuáles flujos no tienen que ser sincronizados. Por ejemplo, si un dispositivo de emisión deseara enviar 3 flujos, 2 flujos de audio (Al y' A2) y 1 flujo de video (Vl) en una sesión, y el dispositivo de emisión quisiera sincronizar (sincronización labial) los flujos Al y Vl, este puede especificarlo utilizando los atributos group, mid-SDP y una etiqueta semántica LS. Esto indicaría al dispositivo de recepción que los flujos Al y Vl necesitan ser sincronizados y que A2 no tiene que ser sincronizado. Aunque para un caso de uso en donde existan dos o más flujos y que no sea necesario que los flujos sean sincronizados, entonces, la petición RFC 3388 falla. Asimismo, para la indicación del rendimiento de la sincronización labial (y en algunos casos en donde RFC 3388 puede utilizarse para especificar que no haya sincronización labial) , la RFC 3388 tendría que ser impuesta. Finalmente, RFC 3388 no ofrece un mecanismo con el cual un dispositivo pueda indicar la fluctuación de sincronización deseada entre distintos medios. Debido a las razones anteriores, no existe mecanismo en la actualidad en donde el dispositivo de emisión pueda indicar al dispositivo de recepción en una llamada multimedia que no realice la sincronización del flujo multimedia que está siendo transmitido por el dispositivo de emisión, ni existe un mecanismo que especifique un retraso o fluctuación de sincronización para el flujo multimedia.
Sumario de la Invención La presente invención proporciona un mecanismo por medio del cual un dispositivo de transmisión o emisión puede indicar de manera explícita cuáles flujos en el flujo multimedia que están siendo enviados no tienen que ser sincronizados ni tienen que incluir una cantidad específica de fluctuación de sincronización. Este mecanismo ayuda a que el dispositivo de recepción entienda las características de flujo y permite que el dispositivo de recepción tome una decisión informada en cuanto a si realiza la sincronización o no, así como también especifica un valor de fluctuación de sincronización. Para ciertas aplicaciones, tales como el compartimiento de video unidireccional o PoC de video, el dispositivo de emisión del flujo puede indicar que el dispositivo de recepción no realice ninguna sincronización para una mejor calidad de los medios. Una modalidad de la presente invención involucra la introducción de un número de nuevos atributos SDP. El dispositivo de emisión declararía estos atributos en el SDP durante la fase de establecimiento de sesión, y los atributos pueden ser llevados en cualquier protocolo de señalización de nivel más alto (por ejemplo, SIP, RTSP, etc.). Sin embargo, estos atributos no están restringidos al uso del protocolo SDP, y estos atributos pueden ser definidos y llevados utilizando cualquier otro protocolo de comunicación en cualquiera de las capas 1-7 del apilamiento de protocolo ISO OSI (por ejemplo, XML, HTTP, UPnP, CC/PP, etc.). La presente invención proporciona beneficios sustanciales con respecto a la estructura convencional RFC 3388 al proporcionar la capacidad para indicar las preferencias del dispositivo de emisión para no realizar la sincronización entre los flujos de medios durante la fase de establecimiento de sesión. Existen casos de uso y aplicaciones en donde el dispositivo de emisión no desea que sean sincronizados los medios que está transmitiendo. Cuando ésta preferencia pueda ser señalizada al dispositivo de recepción, el dispositivo de recepción puede establecer los recursos en consecuencia y no tiene que desperdiciar recursos de cómputo, los cuales pueden ser utilizados para otras tareas o para una mejor calidad de los medios. Como resultado, la presente invención puede originar menores pérdidas de paquete en el dispositivo de recepción, lo cual ocurriría si el dispositivo de recepción intentara realizar la sincronización del flujo de medios.
Además de lo anterior, la presente invención mejora en base a RFC 3388 al proporcionar la capacidad para indicar al dispositivo de emisión las preferencias para la fluctuación de sincronización entre los flujos de medios durante la fase de establecimiento de sesión. Puesto que también existen casos y aplicaciones de uso en donde el dispositivo de emisión desea que los medios que están siendo transmitidos tengan que ser sincronizados con una fluctuación más burda, la capacidad para señalar esta preferencia al dispositivo de recepción permite que el dispositivo de recepción establezca los recursos en consecuencia. Esto también proporciona la oportunidad para conservar los recursos de cómputo. En algunos casos, esto también puede producir un nivel mejorado de calidad de medios. De hecho, en un escenario forzado de sincronización de medios, pueden existir algunas pérdidas de paquete, debido a la eliminación de datos en el dispositivo de recepción o a otras razones, lo cual ocurriría si el dispositivo de recepción intentara realizar la sincronización del flujo de medios. Esto es debido al hecho que los datos de medios pueden llegar al dispositivo de recepción con distintos retrasos, lo cual podría originar algún contenido que llegue demasiado tarde para que sea útil para la reproducción sincronizada completa. Al controlar la fluctuación de sincronización, este problema puede ser aliviado o eliminado.
Estos y otros objetivos, ventajas y características de la invención, junto con la organización y el modo de operación de los mismos, serán aparentes a partir de la siguiente descripción detallada cuando sea tomada en conjunto con las figuras que la acompañan, en donde los mismos elementos tienen los mismos números a través de todas las distintas figuras descritas más adelante.
Breve Descripción de las Figuras La Figura 1 es una representación que muestra la transmisión de una pluralidad de paquetes de audio y video de un dispositivo de emisión a un dispositivo de recepción, en donde la sincronización es realizada a través del dispositivo de recepción aún cuando la sincronización no sea requerida por el dispositivo de emisión; La Figura 2 es una vista en perspectiva de un dispositivo electrónico que puede ser utilizado en la implementación de la presente invención; La Figura 3 es una representación esquemática del conjunto de circuitos del dispositivo electrónico de la Figura 1 ; y La Figura 4 es un diagrama de flujo que muestra la implementación genérica de una modalidad de la presente invención.
Descripción Detallada de la Invención La presente invención proporciona un mecanismo, por medio de lo cual un dispositivo de transmisión o emisión puede indicar, de manera explícita, cuales flujos en el flujo multimedia que están siendo enviados no tienen que ser sincronizados ni deben incluir una cantidad específica de fluctuación de sincronización. Este mecanismo ayuda a que el dispositivo de recepción entienda las características de flujo y permite que el dispositivo de recepción tome una decisión informada en cuanto a si realiza la sincronización o no, así como también especifica el valor de la fluctuación de sincronización. Para el entendimiento de la implementación de la presente invención, la Figura 1 puede ser utilizada en base al entendimiento que el dispositivo de emisión, durante un periodo de establecimiento de sesión, informa al dispositivo de recepción que no quiere que el dispositivo de recepción realice ninguna sincronización ni que efectúe la sincronización con un retraso o fluctuación más burdo de sincronización, utilizando un valor específico (por ejemplo, 500 ms) . En este escenario, cuando el dispositivo de recepción ha completado la decodificación y cuando ha pasado el tiempo terminado para cada paquete de cada flujo de medios, pueden proporcionarse los paquetes respectivos para su presentación. El dispositivo de recepción no tiene que retrasar los paquetes más que el valor especificado. Esto sirve para evitar un problema de exceso de flujo de la memoria intermedia de fluctuación, los paquetes no son retrasados con propósitos de sincronización y la calidad de los medios es mejorada. En este escenario, la recepción debe manejar ambas hileras de medios de manera independiente sin ninguna correlación. En el caso que el dispositivo de emisión espere que el dispositivo de recepción realice alguna sincronización con un valor específico de retraso, entonces, el dispositivo de recepción después de la decodificación, determina la diferencia de los tiempos terminados para los paquetes de audio y video (TVl-TAl) . Si este valor fuera menor que el valor definido en el establecimiento de la sesión para la fluctuación de sincronización, entonces, el dispositivo de recepción no necesitaría mantener los paquetes de audio y video durante un periodo más largo que el que indica el tiempo terminado. Si el valor (TVl-TAl) fuera mayor que la fluctuación de sincronización, entonces, el dispositivo de recepción necesitaría mantener los paquetes durante un periodo corto de tiempo. Por ejemplo, si la fluctuación de sincronización como se especifica durante el establecimiento de la sesión fuera de 500 milisegundos (ms) y TVl-TAl fuera de 350 ms, entonces, el dispositivo de recepción no necesitaría especificar nada. Sin embargo, si TVl-TAl fuera de 600 ms, entonces, el paquete de audio deber ser retrasado en la hilera durante unos 100 ms adicionales. En una primera modalidad de la presente invención, son especificados dos mecanismos, los cuales permiten que el dispositivo de emisión de los flujos multimedia indique que los flujos multimedia no tienen que ser sincronizados. Esta modalidad involucra la introducción de nuevos parámetros SDP que ayuden al dispositivo de emisión de los flujos multimedia para especificar que el dispositivo de recepción no tiene que realizar la sincronización. En el primer mecanismo, un nuevo atributo SDP llamado "NO_SYNC" es introducido. El parámetro "NO_SYNC" indica que los flujos no tienen que ser sincronizados con ningún otro flujo multimedia en la sesión. El atributo NO_SYNC es declarado como a=NO_SYNC. El atributo NO_SYNC puede ser definido en el nivel medio (es decir, después de la línea m en SDP) , o puede ser definido en el nivel de la sesión. Cuando sea definido en el nivel medio, el atributo NO_SYNC significa que el flujo de medios no tiene que ser sincronizado con ningún otro flujo en la sesión. Un ejemplo que utiliza el atributo NO_SYNC es como sigue: v=0 o=NRC 289084412 2890841235 IN IP4 123.124.125.1 s=Demo C=IN IP4 123.124.125.1 m=video 6001 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=NO_SYNC m=video 5001 RTP/AVP 99 a=rtpmap 99 H2.63/90000 m=audio 6001 RTP/AVP 98 a=rtpmap : 98 AMR En el ejemplo anterior, los primeros flujos de video no tienen que ser sincronizados en el dispositivo de recepción. El cliente del dispositivo de recepción, cuando recibe este SDP, sabe que el flujo de video (con el codee MPEG4) no tiene que ser sincronizado con ningún otro flujo. El dispositivo de recepción puede elegir sincronizar o no el flujo restante (audio y video) . El atributo NO_SYNC puede ser declarado en el inicio de la sesión, lo cual implica que todos los flujos en la sesión no tienen que ser sincronizados. Esto se representa como sigue: v=0 o=NRC 289084412 2890841235 IN IP4 123.124.125.1 s=Demo c=IN IP4 123.124.125.1 a=NO_SYNC m=video 6001 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 m=audio 6001 RTP/AVP 98 a=rtpmap:98 AMR En el ejemplo anterior, el dispositivo de emisión indica al dispositivo de recepción que todos los flujos en la sesión no tienen que ser sincronizados. En otro ejemplo de implementación, una extensión a RFC 3388 puede ser definida. Esta extensión puede ser utilizada para especificar cuáles flujos no tienen que ser sincronizados. El siguiente es un ejemplo del sistema convencional RFC 3388 que presenta como es indicada la sincronización en SDP: v=0 o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0 c=IN IP4 224.2.17.12/127 a=group:LS 1 2 m=audio 30000 RTP/AVP 0 a=mid: 1 m=video 30002 RTP/AVP 31 a=mid: 2 m=audio 30004 RTP/AVP 0 i=Este flujo de medios contiene la traducción al idioma Español a=mid:3 En el ejemplo anterior, los flujos con mid 1 y mid 2 serán sincronizados. Esto es indicado con la etiqueta semántica LS en el atributo group. Sin embargo, con la nueva implementación, es utilizada una nueva etiqueta semántica con el atributo group "NLS", el cual tiene las semánticas de no sincronización. El siguiente ejemplo muestra como una indicación puede ser proporcionada de manera que el flujo no tenga que ser sincronizado con ningún otro de los flujos en la sesión: v=0 o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0 c=IN IP4 224.2.17.12/127 a=group:NLS 1 m=audio 30000 RTP/AVP 0 a=mid: 1 m=video 30002 RTP/AVP 31 a=mid: 2 m=audio 30004 RTP/AVP 0 i= Este flujo de medios contiene la traducción al idioma Español a=mid: 3 En el ejemplo anterior, el flujo con MID 1 no es sincronizado con ningún otro flujo en la sesión. Por lo tanto, RFC 3388 puede ser extendida con esta nueva etiqueta semántica, lo cual ayuda a que el dispositivo de emisión indique que ninguna sincronización es requerida para el flujo de medios . La etiqueta semántica LS y NLS puede utilizarse en la misma descripción de sesión para describir cuales flujos necesitan ser sincronizados y cuales flujos no tienen que ser sincronizados. Por ejemplo, en el ejemplo de SDP que se representa más adelante, el flujo 1 no tiene que ser sincronizado con ningún otro flujo en la sesión y los flujos 2 y 3 tienen que ser sincronizados. De este modo, el dispositivo de emisión puede describir de manera explícita cuales flujos deben ser sincronizados y cuales flujos no deben ser sincronizados. v=0 o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0 c=IN IP4 224.2.17.12/127 a=group : NLS 1 a=group:LS 2 3 m=audio 30000 RTP/AVP 0 a=mid: 1 m=video 30002 RTP/AVP 31 a =mid: 2 m=audio 30004 RTP/AVP 0 i= Este flujo de medios contiene la traducción al idioma Español a=mid: 3 En una segunda modalidad de la presente invención, es introducido un mecanismo que permite que el dispositivo de emisión de un flujo multimedia indique un retraso de sincronización o un valor de fluctuación entre los flujos multimedia que desea que sincronice el dispositivo de recepción. En esta modalidad, los nuevos parámetros SDP son utilizados para especificar el valor de la fluctuación. Con estos atributos SDP, el dispositivo de emisión también podría especificar cuáles flujos en la sesión multimedia dada no tienen que ser sincronizados con ningún otro flujo en la misma sesión. En una implementación particular de esta modalidad, es definido un nuevo atributo SDP llamado "sync_jitter" . Este atributo indica el retraso de sincronización entre los flujos multimedia. El atributo sync_jitter SDP es especificado en las unidades de tiempo (por ejemplo, en milisegundos) o cualquier otra unidad adecuada. Un valor de 0 para el atributo sync_jitter significa que ninguna sincronización tiene que ser realizada. Este tributo es declarado en SDP como: a= sync_jitter: valué // valué, el valor es por ejemplo, en milisegundos. El atributo sync_jitter SDP puede ser utilizado en conjunto con los atributos group y mid y la etiqueta semántica LS (como es definido en RFC 3388) . Cuando se utilice con este tributo, sync_jitter especifica la fluctuación de sincronización aceptable entre los flujos que necesitan ser sincronizados como es especificado en la etiqueta semántica LS . El siguiente es un ejemplo de RFC 3388 que describe como la sincronización es indicada de manera convencional en SDP: v=0 o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0 c=IN IP4 224.2.17.12/127 a=group : LS 1 2 m=audio 30000 RTP/AVP 0 a=mid:l m=video 30002 RTP/AVP 31 a=mid: 2 m=audio 30004 RTP/AVP 0 i= Este flujo de medios contiene la traducción al idioma Español a=mid: 3 En el ejemplo anterior, los flujos con mid 1 y mid 2 no serán sincronizados. Esto es indicado con la etiqueta semántica LS en el atributo group. Sin embargo, en este ejemplo no existe modo para indicar la fluctuación de sincronización deseada entre los flujos con mid 1 y 2. En función de las aplicaciones diferentes (tales como el compartimiento de video unidireccional o la telefonía de video de conversación en tiempo real) el valor de la sincronización sería diferente. El ejemplo siguiente extiende el ejemplo anterior con el atributo sync_jitter. Si la descripción anterior de SDP fuera utilizada para la aplicación de compartimiento de video unidireccional, y si una forma más burda de sincronización sería suficiente para una situación particular, el dispositivo de emisión puede utilizar un valor, por ejemplo, de 500 ms, para la fluctuación de sincronización entre los flujos con mid 1 y mid 2. En esta situación, el SDP sería como sigue: v=0 o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0 c=IN IP4 224.2.17.12/127 a=group : S 1 2 a=sync_jitter : 500 m=audio 30000 RTP/AVP 0 a=mid: 1 m=video 30002 RTP/AVP 31 a=mid: 2 m=audio 30004 RTP/AVP 0 i= Este flujo de medios contiene la traducción al idioma Español a=mid:3 El atributo sync_jitter puede ser utilizado con un valor de 0. Un valor de 0 específica en esencia que el dispositivo de emisión no desea que un flujo particular de medios sea sincronizado con ningún otro flujo en la sesión dada. Como se discutió con anterioridad, la implementación por omisión es realizar la sincronización, y si la implementación SDP del dispositivo de emisión no soportara RFC 3388, el dispositivo de emisión puede utilizar el atributo sync_jitter con un valor de 0 para indicar que no desea sincronizar un flujo dado en una sesión con cualquier otro flujo. Un ejemplo de SDP en donde un dispositivo de emisión especifica el valor sync_jitter con 0 es como sigue: v=0 ?=NRC 289084412 2890841235 IN IP4 123.124.125.1 s=Demo c=IN IP4 123.124.125.1 m=video 6001 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=sync_j itter : 0 m=video 5001 RTP/AVP 99 a=rtpmap 99 H2.63/90000 m=audio 6001 RTP/AVP 98 a=rtpmap:98 AMR En el ejemplo anterior, el dispositivo de emisión no desea que sea sincronizado el primer flujo de video (con MPEG-4) con ningún otro flujo en la sesión. El dispositivo de recepción puede elegir si va a sincronizar los restantes dos flujos dados en la sesión. Debe observarse que es posible que un valor adecuado diferente de 0 para sync_jitter pudiera necesitar ser seleccionado para indicar que no es requerida la sincronización, puesto que 0 tendría distintas semánticas. La Figura 4 es un diagrama de flujo genérico que muestra la implementación de una modalidad de la presente invención, en donde el dispositivo de emisión puede designar que no realice la sincronización ni la introducción de un cierto valor de fluctuación de sincronización. En la etapa 300 en la Figura 4, el dispositivo de emisión transmite la información SDP. La información SDP incluyen las instrucciones de los tipos discutidos con anterioridad con relación a la sincronización de los flujos multimedia que están siendo transmitidos. En la etapa 310, el dispositivo de recepción admite la información SDP. En la etapa 320, el dispositivo de recepción realiza la lectura de la información SDP para determinar si existe una instrucción para no sincronizar alguno o la totalidad de los flujos multimedia, si incluye una cierta cantidad de fluctuación de sincronización o si la sincronización completa debe suceder. Si existiera una instrucción para no realizar la sincronización, esta instrucción sería seguida en la etapa 330. Si existiera un valor de fluctuación de sincronización, entonces, la cantidad designada de fluctuación sería introducida en el flujo en la etapa 340. Si no existiera instrucción con respecto a la carencia o falta de sincronización o una cantidad de fluctuación de sincronización, o si existiera una instrucción específica para una sincronización total, entonces, sucedería la sincronización completa o total en la etapa 350. Las Figuras 2 y 3 muestran un dispositivo electrónico representativo 12 dentro del cual podría ser implementada la presente invención. El dispositivo electrónico en las Figuras 2 y 3 comprende un teléfono móvil y puede ser utilizado como un dispositivo de emisión o un dispositivo de recepción. No obstante, debe entenderse que la presente invención no se pretende que sea limitada a un tipo particular de dispositivo electrónico. Por ejemplo, el dispositivo electrónico 12 podría comprender un asistente digital personal (PDA) , una combinación de PDA y teléfono móvil, un dispositivo integrado de mensajería (IMD) , una computadora de escritorio de tipo 'desktop', una computadora portátil de tipo 'notebook' , o una variedad de otros dispositivos.
El dispositivo electrónico 12 de las Figuras 2 y 3 incluye un alojamiento 30, una pantalla 32 en la forma de una pantalla de cristal líquido, un teclado 34, un micrófono 36, un auricular 38, una batería 40, un puerto infrarrojo 42, una antena 44, una tarjeta inteligente 46 en la forma de un UICC de acuerdo con una modalidad de la invención, un lector de tarjeta 48, un conjunto de circuitos de interfaz de radio 52, un conjunto de circuitos de codee 54, un controlador 56 y una memoria 58. Todos los circuitos y elementos individuales son de un tipo bien conocido en la técnica, por ejemplo, en el rango de Nokia de teléfonos móviles. La presente invención es descrita en el contexto general de etapas de método, las cuales podrían ser implementadas en una modalidad a través de un producto de programa que incluye instrucciones susceptibles de ser ejecutadas por computadora, tales como el código de programa ejecutado por las computadoras en entornos de interconexión de redes . De manera general, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc., que realizan tareas particulares o implementan tipos particulares de datos abstractos. Las instrucciones susceptibles de ser ejecutadas por computadora, las estructuras asociadas de datos y los módulos de programa, representan ejemplos de un código de programa para la ejecución de las etapas de los métodos descritos en la presente. La secuencia particular de estas instrucciones susceptibles de ser ejecutadas o las estructuras asociadas de datos representan ejemplos de las etapas correspondientes para la implementación de las funciones descritas en estas etapas . El software y las implementaciones de la Web de la presente invención podrían ser conseguidos con técnicas estándares de programación con una lógica basada en reglas y otra lógica para conseguir las distintas etapas de búsqueda de base de datos, etapas de correlación, etapas de comparación y etapas de decisión. Debe observarse que se pretende que las palabras "componente" y "módulo" como se utilizan en la presente, y en las reivindicaciones, incluyan las implementaciones que utilizan una o más líneas de código de software y/o implementaciones de hardware, y/o el equipo para la recepción de entradas manuales . La descripción anterior de las modalidades de la presente invención ha sido presentada con el propósito de ilustración y de descripción. No se pretende que sea exhaustiva o que limiten la presente invención a la forma precisa descrita, y son posibles modificaciones y variaciones a la luz de las enseñanzas anteriores o podrían ser adquiridas a partir de la práctica de la presente invención. Las modalidades fueron elegidas y descritas con el fin de explicar los principios de la presente invención y su aplicación práctica para permitir que una persona experta en la técnica utilice la presente invención en varias modalidades y con distintas modificaciones según sean adecuadas al uso particular contemplado. Se hace constar que con relación a esta fecha el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.

Claims (35)

  1. Reivindicaciones Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones : 1. Un método que proporciona la información de sincronización para una pluralidad de flujos multimedia, caracterizado porque comprende: transmitir una pluralidad de flujos multimedia a un dispositivo de recepción; y transmitir la información con respecto a la pluralidad de flujos multimedia, la información incluye una instrucción específica para el dispositivo de recepción para no permitir la sincronización ni una cantidad específica de retraso de sincronización al menos entre uno de la pluralidad de flujos multimedia y al menos otro de la pluralidad de flujos multimedia.
  2. 2. El método de conformidad con la reivindicación 1, caracterizado porque la instrucción es incluida como un atributo en la información de sesión transmitida al dispositivo de recepción.
  3. 3. El método de conformidad con la reivindicación 1, caracterizado porque la instrucción incluye un valor aceptable de retraso de sincronización al menos entre dos de los flujos multimedia.
  4. 4. El método de conformidad con la reivindicación 1, caracterizado porque la instrucción comprende un atributo "sync_jitter" .
  5. 5. El método de conformidad con la reivindicación 4, caracterizado porque el atributo "sync_jitter" es acompañado por un valor que indica la no sincronización.
  6. 6. El método de conformidad con la reivindicación 4, caracterizado porque el atributo "sync_jitter" es acompañado por un valor aceptable de retraso de sincronización.
  7. 7. El método de conformidad con la reivindicación 4, caracterizado porque el atributo "sync_jitter" es un atributo SDP.
  8. 8. El método de conformidad con la reivindicación 1, caracterizado porque la instrucción comprende un atributo "NO_SYNC" .
  9. 9. El método de conformidad con la reivindicación 1, caracterizado porque la instrucción comprende una etiqueta semántica "NLS".
  10. 10. El método de conformidad con la reivindicación 1, caracterizado porque la información transmitida instruye al dispositivo de recepción a no sincronizar cualquiera de la pluralidad de flujos multimedia entre sí.
  11. 11. El método de conformidad con la reivindicación 1, caracterizado porque la información transmitida instruye al dispositivo de recepción a no sincronizar uno de la pluralidad de flujos multimedia con cualquier otro de la pluralidad de flujos multimedia.
  12. 12. Un producto de programa de computadora que proporciona la información de sincronización para una pluralidad de flujos multimedia, caracterizado porque comprende : un código de computadora para la transmisión de una pluralidad de flujos multimedia al dispositivo de recepción; y un código de computadora para la transmisión de la información con respecto a la pluralidad de flujos multimedia, la información incluye una instrucción específica para que el dispositivo de recepción no permita la sincronización ni una cantidad específica de retraso de sincronización al menos entre uno de la pluralidad de flujos multimedia y por lo menos otro de la pluralidad de flujos multimedia .
  13. 13. El producto de programa de computadora de conformidad con la reivindicación 12, caracterizado porque la instrucción es incluida como un atributo en la información de sesión transmitida al dispositivo de recepción.
  14. 14. El producto de programa de computadora de conformidad con la reivindicación 12, caracterizado porque la instrucción incluye un valor aceptable de retraso de sincronización al menos entre dos flujos multimedia.
  15. 15. El producto de programa de computadora de conformidad con la reivindicación 12, caracterizado porque la instrucción comprende un atributo "sync_jitter" .
  16. 16. El producto de programa de computadora de conformidad con la reivindicación 15, caracterizado porque el atributo "sync_jitter" es acompañado por un valor aceptable de retraso de sincronización.
  17. 17. El producto de programa de computadora de conformidad con la reivindicación 15, caracterizado porque el atributo "sync_ itter" es un atributo SDP.
  18. 18. El producto de programa de computadora de conformidad con la reivindicación 12, caracterizado porque la información transmitida instruye al dispositivo de recepción a no sincronizar una pluralidad de flujos multimedia con cualquiera otro de la pluralidad de flujos multimedia. .
  19. 19. El producto de programa de computadora de conformidad con la reivindicación 12, caracterizado porque la información transmitida instruye al dispositivo de recepción a no sincronizar cualquiera de la pluralidad de flujos multimedia entre sí.
  20. 20. Un dispositivo electrónico, caracterizado porque comprende : un procesador; y una unidad de memoria conectada en forma operativa con el procesador y que incluye: un código de computadora para la transmisión de una pluralidad de flujos multimedia a un dispositivo de recepción; y un código de computadora para la transmisión de la información con respecto a la pluralidad de flujos multimedia, la información incluye una instrucción específica para que el dispositivo de recepción no permita la sincronización ni una cantidad específica de retraso de sincronización al menos entre uno de la pluralidad de flujos multimedia y por lo menos otro de la pluralidad de flujos multimedia.
  21. 21. El dispositivo electrónico de conformidad con la reivindicación 20, caracterizado porque la instrucción es incluida como un atributo en la información de sesión transmitida al dispositivo de recepción.
  22. 22. El dispositivo electrónico de conformidad con la reivindicación 20, caracterizado porque la instrucción incluye un valor aceptable de retraso de sincronización al menos entre dos de los flujos multimedia.
  23. 23. El dispositivo electrónico de conformidad con la reivindicación 20, caracterizado porque la instrucción comprende un atributo "sync_jitter" .
  24. 24. El dispositivo electrónico de conformidad con la reivindicación 23, caracterizado porque el atributo "sync_jitter" es acompañado por un valor aceptable de retraso de sincronización.
  25. 25. El dispositivo electrónico de conformidad con la reivindicación 23, caracterizado porque el atributo "sync_jitter" es un atributo SDP.
  26. 26. El dispositivo electrónico de conformidad con la reivindicación 20, caracterizado porque la información transmitida instruye al dispositivo de recepción a no sincronizar cualquiera de la pluralidad de flujos multimedia entre sí.
  27. 27. El dispositivo electrónico de conformidad con la reivindicación 20, caracterizado porque la información transmitida instruye al dispositivo de recepción a no sincronizar una pluralidad de flujos multimedia con cualquiera del otro de la pluralidad de flujos multimedia.
  28. 28. El dispositivo electrónico de conformidad con la reivindicación 20, caracterizado porque comprende un dispositivo seleccionado a partir del grupo que consiste de un teléfono móvil, un asistente digital personal, una computadora portátil de tipo 'laptop', una computadora de escritorio de tipo deskto P un dispositivo integrado de mensajería y combinaciones de los mismos.
  29. 29. Un método de procesamiento de contenido multimedia, caracterizado porque comprende: recibir una pluralidad de flujos multimedia a partir de un dispositivo de emisión; recibir la información con respecto a la pluralidad de flujos multimedia que proviene del dispositivo de emisión; y si la información recibida incluyera una instrucción específica para no permitir la sincronización ni una cantidad específica de retraso de sincronización al menos entre uno de la pluralidad de flujos multimedia y por lo menos otro de la pluralidad de flujos multimedia, se presentaría la pluralidad de flujos multimedia de acuerdo con la instrucción específica.
  30. 30. El método de conformidad con la reivindicación 29, caracterizado porque la instrucción incluye un valor aceptable de retraso de sincronización al menos entre dos de los flujos multimedia.
  31. 31. El método de conformidad con la reivindicación 29, caracterizado porque la instrucción comprende un atributo "sync_jitter" .
  32. 32. El método de conformidad con la reivindicación 31, caracterizado porque el atributo "sync_jitter" es acompañado por un valor aceptable de retraso de sincronización.
  33. 33. El método de conformidad con la reivindicación 29, caracterizado porque de acuerdo con la información recibida, ninguno de la pluralidad de flujos multimedia son sincronizados entre sí.
  34. 34. El método de conformidad con la reivindicación 29, caracterizado porque de acuerdo con la información recibida, uno de la pluralidad de flujos multimedia no es sincronizado con cualquiera del otro de la pluralidad de flujos multimedia.
  35. 35. Un dispositivo electrónico, caracterizado porque comprende : un procesador; y una unidad de memoria conectada en forma operativa con el procesador y que incluye: el medio de transmisión de una pluralidad de flujos multimedia al dispositivo de recepción; y el medio de transmisión de la información con respecto a la pluralidad de flujos multimedia, la información incluye una instrucción específica para que el dispositivo de recepción no permita la sincronización ni una cantidad específica de retraso de sincronización al menos entre uno de la pluralidad de flujos multimedia y por lo menos el otro de la pluralidad de flujos multimedia.
MX2008002738A 2005-08-26 2006-08-25 Metodo que indica a dispositivo que no realice sincronizacion y que no incluye retraso de sincronizacion en flujos multimedia. MX2008002738A (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/213,330 US20070047590A1 (en) 2005-08-26 2005-08-26 Method for signaling a device to perform no synchronization or include a synchronization delay on multimedia stream
PCT/IB2006/002325 WO2007023378A2 (en) 2005-08-26 2006-08-25 Method for signaling a device to perform no synchronization or include a syncronization delay on multimedia streams

Publications (1)

Publication Number Publication Date
MX2008002738A true MX2008002738A (es) 2008-03-26

Family

ID=37771989

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2008002738A MX2008002738A (es) 2005-08-26 2006-08-25 Metodo que indica a dispositivo que no realice sincronizacion y que no incluye retraso de sincronizacion en flujos multimedia.

Country Status (10)

Country Link
US (1) US20070047590A1 (es)
EP (1) EP1938498A2 (es)
JP (1) JP2009506611A (es)
KR (1) KR20080038251A (es)
CN (1) CN101288257A (es)
AU (1) AU2006283294A1 (es)
MX (1) MX2008002738A (es)
RU (1) RU2392753C2 (es)
WO (1) WO2007023378A2 (es)
ZA (1) ZA200802531B (es)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7747725B2 (en) 2005-04-22 2010-06-29 Audinate Pty. Limited Method for transporting digital media
CN100477650C (zh) * 2005-09-30 2009-04-08 华为技术有限公司 下一代网络中的ip互通网关及其实现ip域互通的方法
CN100479528C (zh) * 2006-08-30 2009-04-15 华为技术有限公司 一种支持多音轨的方法、系统及流媒体服务器
US20080178243A1 (en) * 2007-01-19 2008-07-24 Suiwu Dong Multimedia client/server system with audio synchronization and methods for use therewith
US8077745B2 (en) * 2007-03-23 2011-12-13 Qualcomm Incorporated Techniques for unidirectional disabling of audio-video synchronization
EP2043323A1 (en) * 2007-09-28 2009-04-01 THOMSON Licensing Communication device able to synchronise the received stream with that sent to another device
CN101340626B (zh) * 2007-11-21 2010-08-11 华为技术有限公司 在sdp协议中标识、获取权限信息的方法及装置
CN100550860C (zh) * 2007-11-27 2009-10-14 华为技术有限公司 媒体资源预留方法及业务包信息获取方法及装置
CN101729532B (zh) * 2009-06-26 2012-09-05 中兴通讯股份有限公司 一种ip多媒体子系统延迟媒体信息传输方法及系统
US8327029B1 (en) * 2010-03-12 2012-12-04 The Mathworks, Inc. Unified software construct representing multiple synchronized hardware systems
US9143539B2 (en) * 2010-11-18 2015-09-22 Interdigital Patent Holdings, Inc. Method and apparatus for inter-user equipment transfer of streaming media
WO2012109422A1 (en) 2011-02-11 2012-08-16 Interdigital Patent Holdings, Inc. Method and apparatus for synchronizing mobile station media flows during a collaborative session
CN103947215B (zh) * 2011-09-23 2018-07-27 韩国电子通信研究院 传送媒体数据的方法和设备、接收媒体数据的设备和方法
EP2592842A1 (en) 2011-11-14 2013-05-15 Accenture Global Services Limited Computer-implemented method, computer system, and computer program product for synchronizing output of media data across a plurality of devices
EP2948949A4 (en) * 2013-01-24 2016-09-21 Telesofia Medical Ltd SYSTEM AND METHOD FOR SOFT VIDEO DESIGN
WO2015002586A1 (en) * 2013-07-04 2015-01-08 Telefonaktiebolaget L M Ericsson (Publ) Audio and video synchronization
KR20150026069A (ko) * 2013-08-30 2015-03-11 삼성전자주식회사 컨텐츠 재생 방법 및 그 방법을 처리하는 전자 장치
US11146611B2 (en) 2017-03-23 2021-10-12 Huawei Technologies Co., Ltd. Lip synchronization of audio and video signals for broadcast transmission
US11392786B2 (en) * 2018-10-23 2022-07-19 Oracle International Corporation Automated analytic resampling process for optimally synchronizing time-series signals

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002504271A (ja) * 1991-09-10 2002-02-05 ハイブリッド・ネットワークス・インコーポレイテッド Ｔｖ放送データ伝送システム用遠隔リンクアダプタ
US5751694A (en) * 1995-05-22 1998-05-12 Sony Corporation Methods and apparatus for synchronizing temporally related data streams
US5737531A (en) * 1995-06-27 1998-04-07 International Business Machines Corporation System for synchronizing by transmitting control packet to omit blocks from transmission, and transmitting second control packet when the timing difference exceeds second predetermined threshold
US5570372A (en) * 1995-11-08 1996-10-29 Siemens Rolm Communications Inc. Multimedia communications with system-dependent adaptive delays
US5953049A (en) * 1996-08-02 1999-09-14 Lucent Technologies Inc. Adaptive audio delay control for multimedia conferencing
US6480902B1 (en) * 1999-05-25 2002-11-12 Institute For Information Industry Intermedia synchronization system for communicating multimedia data in a computer network
US7346698B2 (en) * 2000-12-20 2008-03-18 G. W. Hannaway & Associates Webcasting method and system for time-based synchronization of multiple, independent media streams
WO2004012416A2 (en) * 2002-07-26 2004-02-05 Green Border Technologies, Inc. Transparent configuration authentication of networked devices
JP2004112113A (ja) * 2002-09-13 2004-04-08 Matsushita Electric Ind Co Ltd リアルタイム通信の適応制御方法、受信報告パケットの連続消失に対する対策方法、受信報告パケットの送出間隔の動的決定装置、リアルタイム通信の適応制御装置、データ受信装置およびデータ配信装置
US7231229B1 (en) * 2003-03-16 2007-06-12 Palm, Inc. Communication device interface
US7443849B2 (en) * 2004-12-30 2008-10-28 Cisco Technology, Inc. Mechanisms for detection of non-supporting NAT traversal boxes in the path

Also Published As

Publication number Publication date
AU2006283294A1 (en) 2007-03-01
ZA200802531B (en) 2009-01-28
KR20080038251A (ko) 2008-05-02
US20070047590A1 (en) 2007-03-01
EP1938498A2 (en) 2008-07-02
RU2008107932A (ru) 2009-10-10
WO2007023378A3 (en) 2007-04-26
WO2007023378A2 (en) 2007-03-01
JP2009506611A (ja) 2009-02-12
RU2392753C2 (ru) 2010-06-20
CN101288257A (zh) 2008-10-15

Similar Documents

Publication Publication Date Title
MX2008002738A (es) Metodo que indica a dispositivo que no realice sincronizacion y que no incluye retraso de sincronizacion en flujos multimedia.
US9654537B2 (en) Synchronization and mixing of audio and video streams in network-based video conferencing call systems
US9900553B2 (en) Multi-stream video switching with selective optimized composite
JP5330690B2 (ja) ポータブル通信デバイスのためのデータミキサ
US9143810B2 (en) Method for manually optimizing jitter, delay and synch levels in audio-video transmission
US7280650B2 (en) Method and apparatus to manage a conference
US8571189B2 (en) Efficient transmission of audio and non-audio portions of a communication session for phones
Rudkin et al. Real-time applications on the Internet
CN117176972B (zh) 一个基于WebRTC技术的云会议音视频传输系统及方法
CN113014950A (zh) 一种直播同步的方法、系统和电子设备
WO2023231478A1 (zh) 音视频共享方法、设备及计算机可读存储介质
CA3213247A1 (en) Method and system for integrating video content in a video conference session
Cricri et al. Mobile and Interactive Social Television—A Virtual TV Room
Calvo‐Flores et al. Integrating multimedia streaming from heterogeneous sources to JavaME mobile devices
Yuan et al. A scalable video communication framework based on D-bus
CN115134628A (zh) 流媒体传输方法、装置、终端设备及存储介质
Jang et al. Synchronization quality enhancement in 3G-324M video telephony
Wang et al. Implementation of Mobile Streaming Media Player Based on BREW
Zhong-rong et al. Implementation of Mobile Streaming Media Player Based on BREW
Shirehjini Audio/Video Communication: an overview of the state-of-the-art applications and standards
Igor Bokun et al. The MECCANO Internet Multimedia Conferencing Architecture

Legal Events

Date Code Title Description
FA Abandonment or withdrawal