RU2392753C2 - Способ подачи устройству команды не выполнять синхронизацию или ввести задержку синхронизации для мультимедийных потоков - Google Patents

Способ подачи устройству команды не выполнять синхронизацию или ввести задержку синхронизации для мультимедийных потоков Download PDF

Info

Publication number
RU2392753C2
RU2392753C2 RU2008107932/09A RU2008107932A RU2392753C2 RU 2392753 C2 RU2392753 C2 RU 2392753C2 RU 2008107932/09 A RU2008107932/09 A RU 2008107932/09A RU 2008107932 A RU2008107932 A RU 2008107932A RU 2392753 C2 RU2392753 C2 RU 2392753C2
Authority
RU
Russia
Prior art keywords
specified
multimedia streams
synchronization
delay
stream
Prior art date
Application number
RU2008107932/09A
Other languages
English (en)
Other versions
RU2008107932A (ru
Inventor
Игорь Данило Диего КУРЧИО (FI)
Игорь Данило Диего КУРЧИО
Умеш ЧАНДРА (US)
Умеш ЧАНДРА
Дэйвид ЛЕОН (US)
Дэйвид ЛЕОН
Original Assignee
Нокиа Корпорейшн
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 Нокиа Корпорейшн filed Critical Нокиа Корпорейшн
Publication of RU2008107932A publication Critical patent/RU2008107932A/ru
Application granted granted Critical
Publication of RU2392753C2 publication Critical patent/RU2392753C2/ru

Links

Images

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
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L7/00—Arrangements for synchronising receiver with transmitter
    • 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

Изобретение относится к области мультимедийных коммуникаций по протоколу IP, в частности к сигнальному механизму, который используется в мультимедийных коммуникациях для указания приемному устройству не выполнять синхронизацию или ввести дрожание синхронизации между различными мультимедийными потоками. Технический результат - повышение качества мультимедийного сигнала. Усовершенствованная система и способ дают возможность передающему электронному устройству явно указывать, какие потоки в передаваемом мультимедийном потоке не должны синхронизироваться или должны включать заданную величину дрожания синхронизации. Настоящее изобретение помогает приемному устройству понять характеристики потоков. Настоящее изобретение также позволяет приемному устройству принимать обоснованное решение о том, должно ли использоваться значение дрожания синхронизации при синхронизации двух или более потоков. Для некоторых приложений, таких как однонаправленное распределение видеоданных или видео РоС, передающее устройство может указать приемному устройству, чтобы оно не выполняло синхронизацию или выполняло ограниченную синхронизацию для обеспечения лучшего качества мультимедийного сигнала. 6 н. и 30 з.п. ф-лы, 4 ил.

Description

ОБЛАСТЬ ТЕХНИКИ
[0001] Настоящее изобретение в основном относится к области мультимедийных коммуникаций по протоколу IP. В частности, настоящее изобретение относится к сигнальному механизму, который используется в мультимедийных коммуникациях для указания приемному устройству не выполнять синхронизацию или ввести дрожание синхронизации между различными мультимедийными потоками.
ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ
[0002] В ходе установления мультимедийного IP-вызова, передающее устройство (т.е. оферент или инициатор) указывает информацию о сеансе. В информацию о сеансе входит информация, относящаяся к мультимедиа и транспорту. Информация о сеансе передается в сообщениях протокола, такого как протокол описания сеанса (Session Description Protocol, SDP). SDP передается в протоколе сигнализации высокого уровня, таком как протокол инициации сеанса (Session Initiation Protocol, SIP), протокол передачи потока в реальном времени (Real Time Streaming Protocol, RTSP) и т.д. Проект партнерства третьего поколения (Third Generation Partnership Project, 3GPP) выбрал SIP в качестве протокола сигнализации для установления мультимедийных сеансов для подсистемы передачи данных по мультимедийным сетям (IP Multimedia Subsystem, IMS),
[0003] В SDP передающее устройство и приемное устройство могут указывать разные направления мультимедийных потоков, вызывая различные типы приложений. Например, если передающее устройство хочет установить только односторонний сеанс (это означает, что передающее устройство хочет отправить видео и ожидает, что приемное устройство только примет это видео), оно обозначит это поток в SDP как a=sendonly. Приемное устройство при получении этого SDP сообщения и при условии, что оно хочет участвовать в этот сеансе, может обозначить указанный поток как a=recvonly. Для видеотелефонии как передающее устройство, так и приемное устройство обозначают направления мультимедийных потоков как a=sendrecv.
[0004] Как правило, в мультимедийном IP вызове необходимо синхронизировать различные типы мультимедийной информации на стороне приемного устройства. Например, в аудио/видео IP вызове, необходимо выполнять синхронизацию звука с изображением на стороне приемного устройства для получения хорошего качества такой услуги. Другой пример синхронизации включает использование субтитров; если отправитель аудио и/или видео говорит по-английски и если вместе с его речью в другом потоке транспортного протокола реального времени (Real Time Transport Protocol, RTP) передается текст этой речи на другом языке, необходимо, чтобы эти два потока были синхронизированы на приемном устройстве.
[0005] Разные мультимедийные потоки (со стороны передающего устройства) передаются в разных потоках RTP/протокола дейтаграмм пользователя (User Data Protocol, UDР)/протокола Интернет (Internet Protocol, IP). Для выполнения синхронизации между несколькими потоками клиентами приемного устройства используются временные метки RTP.
[0006] Фиг.1 изображает приемное устройство, получающее мультимедийные потоки от передающего устройства. Горизонтальная ось представляет истекшее время и показывает получаемые пакеты. Буфер аудио- и видеоданных, показанный на фиг.1, содержит RTP-пакеты, которые были получены от передающего устройства. Буфер выполняет устранение дрожания (из сети) и рассчитывает время воспроизведения для каждого пакета каждого типа мультимедиа. Когда пакет пробудет в буфере заданный промежуток времени, осуществляется его декодирование. Этот промежуток времени обычно является переменной величиной, и часть этого промежутка называется дрожанием. После того как на основе времени воспроизведения будет завершено декодирование, пакеты передаются для отображения или воспроизведения. Следует отметить, что может быть два разных буфера для хранения входящих RTP-пакетов - один для дрожания и один для очереди декодирования. Для облегчения понимания на фиг.1 показана только одна очередь, показывающая комбинированный буфер дрожания и декодирования. После того как пакеты декодированы, они готовы для воспроизведения или отображения при наступлении времени воспроизведения. Однако если приемное устройство пытается выполнить синхронизацию аудио/видео, оно попытается задержать те пакеты, которые прибыли первыми.
[0007] В примере, показанном на фиг.1, аудиопакет 1 прибыл во время ТА1, а видеопакет - во время TV1, несколько позднее, чем ТА1. Следует отметить, термин "прибыл" может относиться ко времени приема пакетов или ко времени воспроизведения для каждого пакета. В примере на фиг.1, аудио- и видеопакеты с одинаковым временем воспроизведения необходимо синхронизировать, поскольку они имеют одинаковое время захвата по системным часам (на передающем устройстве), что означает, что они были получены в передающем устройстве в одно и то же время. Расчет времени захвата по системным часам выполняется с использованием временной метки RTP в RTP-пакете и временной метки протокола сетевого времени (Network Time Protocol, NTP), которая передается в пакетах отчета отправителя (Sender Report, SR) протокола управления передачей в реальном времени (Real-Time Control Protocol, RTCP). Весьма вероятно, что аудио- и видеопакеты прибудут в приемное устройство в разное время, поскольку они могут направляться по различным сетевым трактам, и задержка обработки (кодирование, пакетирование, депакетирование, декодирование) может быть различна для каждого пакета. Следовательно, в примере, показанном на фиг.1, аудиопакеты должны быть задержаны на период времени TV1-ТА1, который является дрожанием или задержкой синхронизации.
[0008] В случае с примером на фиг.1, если приложение (или отправитель) не намерено выполнять аудио/видео синхронизацию, но приемное устройство, тем не менее, пытается выполнить синхронизацию (что принято по умолчанию), то приемное устройство будет вынуждено хранить аудиопакеты некоторое дополнительное время. В результате это может привести к переполнению аудиобуфера. Кроме этого, аудиопакеты в начале очереди задерживаются при попытке выполнения синхронизации, что отрицательно сказывается на восприятии пользователя и качестве мультимедиа. Если гарантируется качество обслуживания (Quality of Service, QoS), то может возникнуть ситуация, когда придется отбросить аудио- и видеопакеты, если они значительное время задерживаются в очереди. Следовательно, даже если передающее устройство не хочет, чтобы мультимедийные потоки были синхронизированы, все равно могут возникнуть проблемы, такие как потеря пакетов, задержка пакетов и ненужное расходование вычислительных ресурсов, вследствие отсутствия механизма, посредством которого передающее устройство могло бы указать приемному устройству, что синхронизации не требуется или требуется синхронизация с задержкой.
[0009] В рабочих предложениях (Request for Comments, RFC) №3388 рабочей группы по сетям IETF описан механизм, посредством которого передающее устройство может явно указывать, какой поток в сеансе должен быть синхронизирован. Определены новые атрибуты SDP (например, "group", "mid" и синхронизация звука и изображения (Lip Synchronization, LS), которые могут помочь передающему устройству указать, какие потоки в сеансе должны быть синхронно озвучены. Также по умолчанию приемное устройство RTP должно синхронизировать мультимедийные потоки, которые оно получает от того же источника. Кроме этого, спецификация не требует использовать RFC 3388, когда требуется синхронизация мультимедиа потоков. RFC 3388 только указывает механизм, который может позволить передающему устройству указывать, какие потоки должны быть синхронизированы, если оно отправляет два или более потока.
[0010] Однако есть приложения и случаи использования, когда необходимо, чтобы синхронизация мультимедийных потоков не выполнялась. Например, в приложениях совместного использования видео в режиме реального времени (Real Time Video Sharing, RTVS) пользователь запускает однонаправленное распределение видеоданных. Однонаправленный сеанс настраивается путем объявления потоков в SDP как a=sendonly или a=recvonly. При этом уже имеется двунаправленный (или, возможно, однонаправленный) аудиосеанс между двумя сторонами. Одна сторона в таком вызове хочет поделиться с другой стороной видеоданными. Аудио и видео передаются в IP-канале, хотя возможно, что аудио- и видеосеанс может быть передан по каналу с коммутацией цепей. Совместно используемое видео может представлять собой файл или прямую передачу с камеры.
[0011] В некоторых сценариях с однонаправленной передачей видеоданных передающее устройство не хочет синхронизировать видео (распределяемое из файла) и речь. Одной из причин для этого может быть то, что передающему устройству необходимо, чтобы видео было воспроизведено на приемном устройстве с высоким качеством, пусть даже с задержкой. В данной ситуации передающее устройство может предпочесть, чтобы приемное устройство имело буфер задержки увеличенного размера и, следовательно, не хочет выполнения синхронизации.
[0012] Другим примером однонаправленного распределения видеоданных является случай, когда пользователь снимает видеоизображение какого-либо объекта и рассказывает об этом. В этом случае будет достаточно упрощенной формы синхронизации, поскольку пользователь не снимает на видео свое лицо, а всего лишь снимает различные объекты. Еще один пример включает "расширенную реальность", где графика используется совместно с видео- и аудиосигналом реального времени. В этом случае также будет достаточно упрощенной формы синхронизации.
[0013] Если по умолчанию клиент должен синхронизировать эти два потока, то клиент приемного устройства должен использовать для этого специальные алгоритмы. Алгоритм синхронизации на стороне приемного устройства подразумевает определенное количество вычислительных мощностей, и клиент будет тратить некоторое количество ресурсов, даже если передающее устройство не требует синхронизации. Аудио- и видеопотоки могут прибывать в приемное устройство с различной задержкой. Если приемное устройство пытается синхронизировать эти потоки, это может привести к потере аудио- и видеосегментов или кадров, снижая таким образом качество полученной мультимедийной информации.
[0014] К сожалению, RFC 3388 не описывает механизм, благодаря которому можно было бы четко указать, какие потоки не должны синхронизироваться. Например, если передающее устройство хочет отправить 3 потока за сеанс, из которых 2 аудиопотока (А1 и А2) и 1 видеопоток (V1), и передающее устройство хочет синхронизировать (синхронизация звука с изображением) потоки А1 и V1, оно может указать это, используя такие атрибуты SDP как "group", "mid" и семантический тэг LS. Это укажет приемному устройству, что А1 и V1 должны быть синхронизированы, а А2 - не синхронизирован. Но для вариантов использования, когда не должны синхронизироваться два или более потоков, RFC 3388 недостаточно. Также, для указания относительно синхронизации звука с изображением (и в некоторых других случаях, где RFC 3388 может использоваться для указания того, что синхронизация звука с изображением не требуется), RFC 3388 должен быть обязателен. И наконец, RFC 3388 не предлагает механизма, с помощью которого устройство может указать желаемое дрожание синхронизации между различными мультимедийными потоками.
[0015] Вследствие перечисленных выше причин, на данный момент отсутствует механизм, с помощью которого передающее устройство могло бы указать приемному устройству в ходе мультимедийного вызова не синхронизировать мультимедийный поток, который передается передающим устройством, а также отсутствует механизм для указания дрожания или задержки синхронизация для мультимедийного потока.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
[0016] Настоящее изобретение предлагает механизм, посредством которого отправляющее или передающее устройство может явно указать, какие потоки в посылаемом мультимедийном потоке не должны синхронизироваться или должны включать заданное значение дрожания синхронизации. Этот механизм помогает приемному устройству понять характеристики потока и позволяет этому устройству принимать обоснованное решение относительно того, выполнять или нет синхронизацию, а также позволяет задавать величину дрожания синхронизации. Для некоторых приложений, таких как однонаправленное распределение видеоданных или видео РоС, передающее устройство может указать приемному устройству не выполнять какую-либо синхронизацию для лучшего качества мультимедийной передачи.
[0017] Один из вариантов осуществления настоящего изобретения включает введение ряда новых атрибутов SDP. Передающее устройство объявляет эти атрибуты в SDP на этапе установки сеанса, и затем они могут быть внесены в любой сигнальный протокол более высокого уровня (например, SIP, RTSP и т.д.). Однако эти атрибуты не ограничиваются применением только в SDP протоколе, и могут быть определены и выполнены с использованием любого протокола связи на любом из уровней 1-7 стека протоколов ISO OSI (например, XML, HTTP, UPnP, CC/PP и т.д.)
[0018] Настоящее изобретение имеет значительные преимущества по сравнению с традиционной инфраструктурой RFC 3388 за счет предоставления возможности передающему устройству в ходе этапа установки сеанса указывать предпочтения относительно невыполнения синхронизации мультимедийных потоков. Имеются варианты использования и приложения, где передающее устройство не требует, чтобы передаваемые им данные синхронизировались. Если можно передать информацию о таких предпочтениях приемному устройству, то указанное приемное устройство может соответствующим образом настроить свои ресурсы и не тратить вычислительные мощности впустую, а напротив, использовать их на выполнение других задач или на повышение качества мультимедийной информации. В результате настоящее изобретение может обеспечить в приемном устройстве меньший процент потери пакетов, которая может произойти, если приемное устройство пытается выполнить синхронизацию мультимедийных потоков.
[0019] В дополнение к вышесказанному, настоящее изобретение имеет значительные преимущества по сравнению с RFC 3388 за счет предоставления возможности передающему устройству в ходе этапа установки сеанса указывать предпочтения относительно дрожания синхронизации мультимедийных потоков. Поскольку также имеются случаи использования и приложения, в которых передающее устройство допускает, чтобы передаваемая мультимедийная информация синхронизировалась с более значительным дрожанием, то способность сообщать о предпочтениях приемному устройству позволяет этому приемному устройству соответствующим образом настраивать свои ресурсы. Это также предоставляет возможность экономить вычислительные мощности. В некоторых случаях это также позволяет повысить качество мультимедийной информации. По сути, при принудительной синхронизации возможны потери пакетов вследствие отбрасывания данных в приемном устройстве или вследствие других причин, которые могут возникнуть при попытке приемного устройства выполнить синхронизацию. Это может быть вызвано тем, что мультимедийные данные поступают в приемное устройство с разными задержками, что может привести к тому, что определенное содержимое поступит слишком поздно, чтобы обеспечить полностью синхронизированное воспроизведение. Данную проблему можно сделать менее острой или устранить путем управления дрожанием синхронизации.
[0020] Эти и другие задачи, преимущества и возможности данного изобретения, а также его организация и способ работы, будут объяснены в приведенном далее подробном описании изобретения совместно с прилагающимися чертежами, на которых сходные элементы имеют сходные номера на нескольких чертежах.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ.
[0021] Фиг.1 изображает передачу множества аудио- и видеопакетов от передающего устройства в приемное устройство, где приемным устройством выполняется синхронизация, даже если синхронизация не требовалась передающим устройством.
[0022] Фиг.2 изображает вид в перспективе электронного устройства, которое может использоваться в реализации настоящего изобретения;
[0023] Фиг.3 изображает схематическое представление схем электронного устройства, показанного на фиг.1; и
[0024] Фиг.4 изображает блок-схему, показывающую типовое осуществление одного из вариантов осуществления настоящего изобретения.
ПОДРОБНОЕ ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ
[0025] Настоящее изобретение предлагает механизм, посредством которого отправляющее или передающее устройство может явно указать, какие потоки в посылаемом мультимедийном потоке не должны синхронизироваться или должны включать заданное значение дрожания синхронизации. Этот механизм помогает приемному устройству понять характеристики потока и позволяет этому устройству принимать обоснованное решение относительно того, выполнять или нет синхронизацию, а также позволяет задавать величину дрожания синхронизации.
[0026] Для объяснения сути настоящего изобретения используем фиг.1, полагая при этом, что передающее устройство в ходе этапа установки сеанса сообщает приемному устройству, что оно не хочет, чтобы указанное приемное устройство выполняло какую-либо синхронизацию или выполняло синхронизацию с большей задержкой или дрожанием синхронизации, используя заданное значение (например, 500 миллисекунд). В данном сценарии приемное устройство по завершении декодирования и окончании времени выдержки для каждого пакета каждого потока может предоставлять соответствующие пакеты на воспроизведение. Приемное устройство не должно задерживать указанные пакеты дольше установленного значения времени. Это необходимо для того, чтобы предотвратить проблему переполнения буфера дрожания, благодаря чему пакеты не задерживаются для синхронизации и качество мультимедийной информации повышается. В данном сценарии приемное устройство должно управлять обеими очередями независимо, без какой-либо взаимосвязи.
[0027] В случае, если передающее устройство ожидает, что приемное устройство выполнит какую-либо синхронизацию с заданным значением задержки, то приемное устройство после декодирования определяет разницу во времени воспроизведения аудио- и видеопакетов (TV1-TA1). Если данное значение меньше, чем значение, указанное в ходе установки сеанса для дрожания синхронизации, то приемное устройство не должно удерживать аудио- и видеопакеты дольше, чем указано временем воспроизведения. Если значение (TV1-TA1) больше, чем дрожание синхронизации, то приемное устройство должно удерживать пакеты некоторый короткий промежуток времени. Например, если заданное в ходе установки сеанса дрожание синхронизации равно 500 миллисекунд, а TV1-TA1 равно 350 миллисекундам, то приемное устройство не должно что-либо определять. Однако, если TV1-TA1 равно 600 миллисекундам, то аудиопакет должен быть задержан в очереди на дополнительные 100 миллисекунд.
[0028] В первом варианте осуществления настоящего изобретения указаны два механизма, которые позволяют передающему устройству указывать, что мультимедийные потоки не должны синхронизироваться. Этот вариант осуществления включает введение новых SDP параметров, которые помогают передающему устройству указывать, что приемное устройство не должно выполнять синхронизацию.
[0029] В первом механизме вводится новый атрибут SDP, называющийся "NO_SYNC". "NO_SYNC" указывает, что потоки не должны синхронизироваться с любым другим мультимедийным потоком в сеансе. Атрибут NO_SYNC объявляется как a=NO_SYNC.
[0030] Атрибут NO_SYNC может быть определен на уровне мультимедиа (т.е. после строчки m в SDP), или может быть определен на сеансовом уровне. При определении на уровне мультимедиа атрибут NO_SYNC означает, что мультимедийный поток не должен синхронизироваться с любым другим потоком в сеансе. Ниже приведен пример использования атрибута NO_SYNC.
v=0
o=NRC 289084412 2890841235 IN EP4 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
[0031] В приведенном выше примере первые видеопотоки не должны синхронизироваться в приемном устройстве. Клиент приемного устройства при получении этого SDP получает команду, что этот видеопоток (с кодеком MPEG4) не должен синхронизироваться с каким-либо другим потоком. Приемное устройство может само выбирать, синхронизировать или нет остальные (аудио и видео) потоки.
[0032] Атрибут NO_SYNC может быть объявлен в начале сеанса, что подразумевает, что все потоки в сеансе не должны синхронизироваться. Это отображается следующим образом.
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
[0033] В приведенном выше примере передающее устройство указывает приемному устройству, что все потоки в данном сеансе не должны синхронизироваться.
[0034] В другом примере осуществления может быть определено расширение RFC 3388. Данное расширение может использоваться для указания того, какие потоки не должны синхронизироваться. Далее приведен пример традиционной системы RFC 3388, который демонстрирует, как указывается синхронизация в SDP:
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
t-00
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=This media stream contains the Spanish translation
a=mid:3
[0035] В приведенном выше примере должны быть синхронизированы потоки с mid 1 и mid 2. Это указывается семантическим тегом LS в атрибуте группы. В новом варианте осуществления, однако, используется новый семантический тег "NLS" с атрибутом группы, который обозначает отсутствие синхронизации. Приведенный далее пример показывает, как может быть дано указание на то, что указанный поток не должен синхронизироваться с другими потоками в сеансе:
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
t-00
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=This media stream contains the Spanish translation
a=mid:3
[0036] В этом примере поток с MID 1 не синхронизируется с другими потоками в сеансе. Таким образом, RFC 3388 может быть дополнен новыми тегами, которые помогают указывать передающему устройству, что для потока не требуется синхронизация.
[0037] Теги LS и NLS могут использоваться в описании одного и того же сеанса для указания того, какие потоки должны синхронизироваться, а какие - нет. Например, в примере SDP, приведенном ниже, поток 1 не должен синхронизироваться с каким-либо другим потоком в сеансе, а потоки 2 и 3 должны быть синхронизированы между собой. Таким образом передающее устройство может явно указать, какие потоки должны быть синхронизированы, а какие - нет.
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
t=00
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:l
m=video 30002 RTP/AVP 31
a=mid:2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation
a=mid:3
[0038] Во втором варианте осуществления настоящего изобретения предложен механизм, позволяющий передающему устройству указывать задержку или величину дрожания синхронизации между мультимедийными потоками, для которых приемное устройство должны выполнить синхронизацию. В этом варианте осуществления настоящего изобретения для указания величины дрожания используются новые параметры SDP. Используя эти новые атрибуты SDP, передающее устройство может также указывать, какие потоки в данном сеансе не должны синхронизироваться с другими потоками сеанса.
[0039] В одном варианте реализации данного варианта осуществления настоящего изобретения задан новый атрибут SDP - "sync_jitter". Данный атрибут устанавливает задержку синхронизации между мультимедийными потоками. Атрибут SDP "sync_jitter" задается в единицах времени (например, миллисекундах) или в других подходящих единицах измерения. Если для "sync_jitter" установлено значение "О", то это означает, что синхронизация выполняться не должна. Данный атрибут объявляется в SDP как:
a=sync_jitter:value // value is for example in milliseconds.
[0040] Атрибут "sync_jitter" может использоваться совместно с атрибутами "group" и "mid", а также семантическим тегом LS (как указано в RFC 3388). При использовании с этими атрибутами, "sync_jitter" указывает желаемое дрожание синхронизации между потоками, которые должны быть синхронизированы, как указано в теге LS. Далее приведен пример из RFC 3388, который демонстрирует, как традиционно указывается синхронизация в SDP;
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
t=00
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=This media stream contains the Spanish translation
a=mid:3
[0041] В этом примере потоки с mid 1 и mid 2 должны быть синхронизированы. Это указывается семантическим тегом LS в атрибуте группы. Однако в данном примере нет способа указать желаемое дрожание синхронизация между потоками с mid 1 и 2. В зависимости от приложения (такого как однонаправленное распределение видеоданных или видеотелефония в режиме реального времени) значение синхронизации может быть различным.
[0042] Приведенный далее пример дополняет приведенный выше, вводя в него атрибут "sync_jitter". Если приведенное выше описание SDP используется в приложении однонаправленного распределения видеоданных и если для конкретной ситуации будет достаточно упрощенной формы синхронизации, то передающее устройство использует значение 500 миллисекунд, например, для дрожания синхронизации между потоками с mid 1 и mid 2. В таком случае SDP будет иметь следующий вид:
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
t=00
c=IN IP4 224.2.17.12/127
a=group:LS 1 2
a=sync_jitter:500
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=This media stream contains the Spanish translation
a=mid:3
[0043] Атрибут "sync_jitter" может использоваться со значением «0». Значение «0» по сути указывает, что передающее устройство не хочет, чтобы данный поток был синхронизирован с каким-либо другим потоком в данном сеансе. Как говорилось выше, настройки по умолчанию подразумевают выполнение синхронизации, и если передающее устройство SDP не поддерживает RFC 3388, то указанное передающее устройство может использовать атрибут "sync_jitter" со значением «0» для указания того, что оно не хочет, чтобы данный поток в сеансе синхронизировался с каким-либо другим потоком. Пример SDP, где передающее устройство указывает значение "sync_jitter", равное 0, выглядит следующим образом:
v=0
o=NRC 289084412 2890841235 IN EP4 123.124.125.1
s=Demo
c=INIP4 123.124.125.1
ra=video 6001 RTP/AVP 98
a=rtpmap:98 MP4V-ES/90000
a=sync_jitter:0
m=video 5001 RTP/AVP 99
a=rtpmap 99 H2.63/90000
m=audio 6001 RTP/AVP 98
a=rtpmap:98 AMR
[0044] В приведенном выше примере передающее устройство не хочет, чтобы первый видеопоток (MPEG-4) синхронизировался с любым другим потоком в сеансе. Приемное устройство может выбирать, нужно ли синхронизировать остальные два потока в указанном сеансе.
[0045] Следует отметить, что возможна ситуация, когда потребуется, чтобы значение для "sync_jitter", указывающее, что синхронизация не требуется, было выбрано отличным от 0, поскольку 0 будет иметь другую семантику.
[0046] Фиг.4 представляет собой общую блок-схему, показывающую реализацию варианта осуществления настоящего изобретения, в котором передающее устройство может указывать либо не выполнять синхронизацию, либо устанавливать определенное значение дрожания синхронизации. На этапе 300 на фиг.4 передающее устройство передает информацию SDP. Указанная информация SDP включает инструкции описанных выше типов в отношении синхронизации передаваемых мультимедийных потоков. На этапе 310 приемное устройство получает указанную информацию SDP. На этапе 320 приемное устройство считывает информацию SDP для определения того, содержится ли в ней указание не выполнять синхронизацию какого-либо или всех мультимедийных потоков, установить определенное значение для дрожания синхронизации или же выполнить полную синхронизацию. Если есть указание не выполнять синхронизацию, то выполняется переход на этап 330. Если задано значение дрожания синхронизация, то к потоку применяет заданное значение дрожания на этапе 340. Если же отсутствуют инструкции касательно отмены синхронизации, или не указано дрожание синхронизации, или есть конкретная инструкция на выполнение полной синхронизации, то осуществляется полная синхронизация на этапе 350.
[0047] Фиг.2 и 3 изображают типовое электронное устройство 12, в котором может быть осуществлено настоящее изобретение. Электронное устройство на фиг.2 и 3 включает мобильный телефон и может быть использовано как передающее или как приемное устройство. Следует понимать, однако, что настоящее изобретение не ограничивается только одним конкретным типом электронных устройств. Например, электронное устройство 12 может включать КПК, комбинацию КПК и мобильного телефона, интегрированное устройство обмена сообщениями (IMD), настольный компьютер, ноутбук и разнообразные другие устройства.
[0048] Электронное устройство 12 на фиг.2 и 3 включает корпус 30, дисплей 32, в виде жидкокристаллического дисплея, кнопочный номеронабиратель 34, микрофон 36, громкоговоритель 38, аккумулятор 40, инфракрасный порт 42, антенну 44, смарт-карту 46 в виде UICC согласно одному из вариантов осуществления изобретения, устройство 48 считывания карт, схему 52 радиоинтерфейса, схему 54 кодека, контроллер 56 и память 58. Отдельные схемы и элементы хорошо известны в данной области техники, например в линейке мобильных телефонов Nokia.
[0049] Настоящее изобретение описывается в общем контексте этапов способа, который может быть реализован в одном из вариантов осуществления при помощи программного продукта, включающего выполняемые компьютером инструкции, такие как программный код, который выполняется компьютерами в сетевом окружении.
[0050] Обычно программные модули включают процедуры, программы, объекты, компоненты, структуры данных и т.д., которые выполняют конкретные задачи или обрабатывают отдельные абстрактные типы данных. Выполняемые компьютером инструкции, ассоциированные структуры данных и программные модули представляют собой примеры программного кода для осуществления этапов способов, описанных в данном документе. Конкретная последовательность таких инструкций и ассоциированных структур данных представляет собой примеры соответствующих действий по реализации функций, описанных в таких этапах.
[0051] Программная или сетевая реализация настоящего изобретения может быть осуществлена с помощью стандартных методов программирования с управляемой с помощью правил логикой или иной логикой, позволяющей осуществить этапы поиска по различным базам данных, этапы соотнесения, сравнения и принятия решения. Следует также отметить, что слова "компонент" и "модуль", в том смысле, в котором они применяются здесь и в формуле изобретения, охватывают варианты реализации с использованием одной или более строчек программного кода и/или варианты аппаратной реализации и/или оборудование для приема команд ручного ввода.
[0052] Вышеупомянутое описание вариантов осуществления настоящего изобретения было приведено в целях пояснения. Это описание не претендует на всесторонность и не ограничивает настоящее изобретение конкретной описанной формой, поскольку в свете вышеизложенных положений возможны изменения и модификации, или же возможны изменения, полученные в ходе применения настоящего изобретения. Описанные выше варианты осуществления настоящего изобретения были выбраны и объяснены для демонстрации принципов настоящего изобретения и его практического применения, с целью дать возможность специалистам в данной области использовать настоящее изобретение в различных вариантах его осуществления и вносить различные модификации, требуемые для конкретных вариантов использования.

Claims (36)

1. Способ предоставления передающим устройством информации синхронизации для множества мультимедийных потоков, включающий:
передачу множества мультимедийных потоков в приемное устройство; и
передачу информации, касающейся указанного множества мультимедийных потоков, причем указанная информация включает специальную инструкцию для приемного устройства, допускающую невыполнение синхронизации или заданное максимально допустимое значение задержки синхронизации между, по меньшей мере, одним из указанного множества мультимедийных потоков и, по меньшей мере, еще одним потоком из указанного множества мультимедийных потоков.
2. Способ по п.1, в котором указанную инструкцию включают как атрибут в информацию о сеансе, передаваемую приемному устройству.
3. Способ по п.1, в котором указанная инструкция включает максимально допустимое значение задержки синхронизации между, по меньшей мере, двумя мультимедийными потоками.
4. Способ по п.1, в котором указанная инструкция содержит атрибут "sync-jitter".
5. Способ по п.4, в котором указанный атрибут "sync-jitter" сопровождается значением, которое указывает не выполнять синхронизацию.
6. Способ по п.4, в котором указанный атрибут "sync-jitter" сопровождается максимально допустимым значением задержки синхронизации.
7. Способ по п.4, в котором указанный атрибут "sync-jitter" является атрибутом протокола описания сеанса.
8. Способ по п.1, в котором указанная инструкция содержит атрибут "NO-SYNC".
9. Способ по п.1, в котором указанная инструкция содержит семантический тег отсутствия синхронизации звука с изображением ("NLS").
10. Способ по п.1, в котором указанная переданная информация инструктирует приемное устройство не выполнять синхронизацию любого потока из указанного множества мультимедийных потоков с любым другим потоком.
11. Способ по п.1, в котором указанная переданная информация инструктирует приемное устройство не синхронизировать один из указанного множества мультимедийных потоков с любым другим потоком из указанного множества мультимедийных потоков.
12. Блок памяти, содержащий компьютерный программный продукт, обеспечивающий информацию синхронизации для множества мультимедийных потоков и включающий:
компьютерный код для передачи множества мультимедийных потоков в приемное устройство; и
компьютерный код для передачи информации, касающейся указанного множества мультимедийных потоков, причем указанная информация включает специальную инструкцию для указанного приемного устройства, допускающую невыполнение синхронизации или заданное максимально допустимое значение задержки синхронизации между, по меньшей мере, одним из указанного множества мультимедийных потоков и, по меньшей мере, еще одним потоком из указанного множества мультимедийных потоков.
13. Блок памяти по п.12, в котором указанная инструкция включена как атрибут в информацию о сеансе, передаваемую приемному устройству.
14. Блок памяти по п.12, в котором указанная инструкция включает максимально допустимое значение задержки синхронизации между, по меньшей мере, двумя мультимедийными потоками.
15. Блок памяти по п.12, в котором указанная инструкция содержит атрибут "sync-jitter".
16. Блок памяти по п.15, в котором указанный атрибут "sync-jitter" сопровождается максимально допустимым значением задержки синхронизации.
17. Блок памяти по п.15, в котором указанный атрибут "sync-jitter" является атрибутом протокола описания сеанса.
18. Блок памяти по п.12, в котором указанная переданная информация инструктирует приемное устройство не синхронизировать один из указанного множества мультимедийных потоков с любым другим потоком из указанного множества мультимедийных потоков.
19. Блок памяти по п.12, в котором указанная переданная информация инструктирует приемное устройство не выполнять синхронизацию любого потока из указанного множества мультимедийных потоков с любым другим потоком.
20. Передающее электронное устройство, содержащее:
процессор; и
блок памяти, функционально связанный с указанным процессором и включающий компьютерный код, который при выполнении процессором заставляет передающее электронное устройство:
передавать множество мультимедийных потоков в приемное устройство; и
передавать информацию, касающуюся указанного множества мультимедийных потоков, причем указанная информация включает специальную инструкцию для указанного приемного устройства, допускающую невыполнение синхронизации или заданное максимально допустимое значение задержки синхронизации между, по меньшей мере, одним из указанного множества мультимедийных потоков и, по меньшей мере, еще одним потоком из указанного множества мультимедийных потоков.
21. Передающее электронное устройство по п.20, где указанная инструкция включена как атрибут в информацию о сеансе, передаваемую приемному устройству.
22. Передающее электронное устройство по п.20, в котором указанная инструкция включает максимально допустимое значение задержки синхронизации между по меньшей мере двумя мультимедийными потоками.
23. Передающее электронное устройство по п.20, в котором указанная инструкция содержит атрибут "sync-jitter".
24. Передающее электронное устройство по п.23, в котором указанный атрибут "sync-jitter" сопровождается максимально допустимым значением задержки синхронизации.
25. Передающее электронное устройство по п.23, в котором указанный атрибут "sync-jitter" является атрибутом протокола описания сеанса.
26. Передающее электронное устройство по п.20, в котором указанная передаваемая информация инструктирует приемное устройство не выполнять синхронизацию любого потока из указанного множества мультимедийных потоков с любым другим потоком.
27. Передающее электронное устройство по п.20, в котором указанная передаваемая информация инструктирует приемное устройство не синхронизировать один из указанного множества мультимедийных потоков с любым другим потоком из указанного множества мультимедийных потоков.
28. Передающее электронное устройство по п.20, которое содержит устройство, выбранное из группы, включающей мобильный телефон, КПК, портативный компьютер, настольный компьютер, интегрированное устройство обмена сообщениями или их комбинацию.
29. Способ обработки мультимедийного содержимого, включающий:
прием множества мультимедийных потоков от передающего устройства;
прием информации, касающейся указанного множества мультимедийных потоков, от указанного передающего устройства, причем эта информация включает специальную инструкцию для приемного устройства, допускающую невыполнение синхронизации или заданное максимально допустимое значение задержки синхронизации между, по меньшей мере, одним из указанного множества мультимедийных потоков и, по меньшей мере, еще одним потоком из указанного множества мультимедийных потоков;
если принятая информация включает специальную инструкцию, допускающую заданное максимально допустимое значение задержки синхронизации,
определение разницы во времени воспроизведения между указанным, по меньшей мере, одним из множества мультимедийных потоков и указанным, по меньшей мере, еще одним потоком из множества мультимедийных потоков и,
если эта разница больше, чем заданное максимально допустимое значение задержки синхронизации, задержку воспроизведения указанного, по меньшей мере, одного из множества мультимедийных потоков для уменьшения указанной разницы до величины, меньшей или равной заданному максимально допустимому значению задержки синхронизации, и
представление указанного множества мультимедийных потоков.
30. Способ по п.29, в котором указанная инструкция включает максимально допустимое значение задержки синхронизации между, по меньшей мере, двумя из мультимедийных потоков.
31. Способ по п.29, в котором указанная инструкция содержит атрибут "sync-jitter".
32. Способ по п.31, в котором указанный атрибут "sync-jitter" сопровождается максимально допустимым значением задержки синхронизации.
33. Способ по п.29, в котором, в соответствии с принятой информацией, ни один поток из указанного множества мультимедийных потоков не синхронизируют с любым другим потоком.
34. Способ по п.29, в котором, в соответствии с принятой информацией, один из указанного множества мультимедийных потоков не синхронизируют с любым другим потоком из множества мультимедийных потоков.
35. Передающее электронное устройство, содержащее:
средства для передачи множества мультимедийных потоков в приемное устройство; и
средства для передачи информации, касающейся указанного множества мультимедийных потоков, причем указанная информация включает специальную инструкцию для указанного приемного устройства, допускающую невыполнение синхронизации или заданное максимально допустимое значение задержки синхронизации между, по меньшей мере, одним из указанного множества мультимедийных потоков и, по меньшей мере, еще одним потоком из указанного множества мультимедийных потоков.
36. Приемное электронное устройство, содержащее:
процессор; и
блок памяти, функционально связанный с указанным процессором и включающий компьютерный код, который при выполнении процессором заставляет приемное электронное устройство:
принимать множество мультимедийных потоков от передающего устройства;
принимать информацию, касающуюся указанного множества мультимедийных потоков, от указанного передающего устройства, причем эта информация включает специальную инструкцию для приемного устройства, допускающую невыполнение синхронизации или заданное максимально допустимое значение задержки синхронизации между, по меньшей мере, одним из указанного множества мультимедийных потоков и, по меньшей мере, еще одним потоком из указанного множества мультимедийных потоков;
если принятая информация включает специальную инструкцию, допускающую заданное максимально допустимое значение задержки синхронизации,
определять разницу во времени воспроизведения между указанным, по меньшей мере, одним из множества мультимедийных потоков и указанным, по меньшей мере, еще одним потоком из множества мультимедийных потоков и,
если эта разница больше, чем заданное максимально допустимое значение задержки синхронизации, задерживать воспроизведение указанного, по меньшей мере, одного из множества мультимедийных потоков для уменьшения указанной разницы до величины, меньшей или равной заданному максимально допустимому значению задержки синхронизации, и
представлять указанное множество мультимедийных потоков.
RU2008107932/09A 2005-08-26 2006-08-25 Способ подачи устройству команды не выполнять синхронизацию или ввести задержку синхронизации для мультимедийных потоков RU2392753C2 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/213,330 2005-08-26
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

Publications (2)

Publication Number Publication Date
RU2008107932A RU2008107932A (ru) 2009-10-10
RU2392753C2 true RU2392753C2 (ru) 2010-06-20

Family

ID=37771989

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2008107932/09A RU2392753C2 (ru) 2005-08-26 2006-08-25 Способ подачи устройству команды не выполнять синхронизацию или ввести задержку синхронизации для мультимедийных потоков

Country Status (10)

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

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
JP5782139B2 (ja) * 2011-02-11 2015-09-24 インターデイジタル パテント ホールディングス インコーポレイテッド 協調セッション中に移動局のメディアフローを同期化する方法および装置
CN109068155B (zh) * 2011-09-23 2021-01-26 韩国电子通信研究院 传送媒体数据的设备以及接收媒体数据的设备
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 삼성전자주식회사 컨텐츠 재생 방법 및 그 방법을 처리하는 전자 장치
EP3591908B9 (en) * 2017-03-23 2022-04-06 Huawei Technologies Co., Ltd. Method and device for lip-speech synchronization among multiple devices
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
EP0603269A1 (en) * 1991-09-10 1994-06-29 Hybrid Networks, Inc. Remote link adapter for use in tv broadcast data transmission system
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
EP1547337B1 (en) * 2002-07-26 2006-03-22 Green Border Technologies Watermarking at the packet level
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
WO2007023378A3 (en) 2007-04-26
MX2008002738A (es) 2008-03-26
RU2008107932A (ru) 2009-10-10
ZA200802531B (en) 2009-01-28
AU2006283294A1 (en) 2007-03-01
EP1938498A2 (en) 2008-07-02
CN101288257A (zh) 2008-10-15
WO2007023378A2 (en) 2007-03-01
KR20080038251A (ko) 2008-05-02
JP2009506611A (ja) 2009-02-12
US20070047590A1 (en) 2007-03-01

Similar Documents

Publication Publication Date Title
RU2392753C2 (ru) Способ подачи устройству команды не выполнять синхронизацию или ввести задержку синхронизации для мультимедийных потоков
US9654537B2 (en) Synchronization and mixing of audio and video streams in network-based video conferencing call systems
RU2494562C2 (ru) Управление мультимедийными каналами
EP2740265B1 (en) System and method for adapting video communications
US8149261B2 (en) Integration of audio conference bridge with video multipoint control unit
US20080100694A1 (en) Distributed caching for multimedia conference calls
US9143810B2 (en) Method for manually optimizing jitter, delay and synch levels in audio-video transmission
US20060282774A1 (en) Method and system for improving interactive media response systems using visual cues
US20150110134A1 (en) Adapting a Jitter Buffer
WO2020125153A1 (zh) 一种基于流媒体技术的网络视频流畅播放控制方法
Montagud et al. Design, development and assessment of control schemes for IDMS in a standardized RTCP-based solution
US7370126B2 (en) System and method for implementing a demand paging jitter buffer algorithm
WO2023231478A1 (zh) 音视频共享方法、设备及计算机可读存储介质
CA3213247A1 (en) Method and system for integrating video content in a video conference session
US10798141B2 (en) Multiplexing data
Cricri et al. Mobile and Interactive Social Television—A Virtual TV Room
Papadaki et al. Mobistream: Live multimedia streaming in mobile devices
Calvo‐Flores et al. Integrating multimedia streaming from heterogeneous sources to JavaME mobile devices
CN116684652A (zh) 音视频拉取方法、装置、存储介质及计算机设备
Yuan et al. A scalable video communication framework based on D-bus
Georganas Synchronization issues in multimedia presentational and conversational applications
Montagud et al. Design, Development and Assessment of Control Schemes for IDMS in an Evolved and Standardized RTCP-based Solution
Jang et al. Synchronization quality enhancement in 3G-324M video telephony
Fitz tgw: a webcast transcoding gateway
Liu et al. Achieving High-Level QoS in Multi-Party Video-Conferencing Systems via Exploitation of Global Time

Legal Events

Date Code Title Description
MM4A The patent is invalid due to non-payment of fees

Effective date: 20110826