СПОСОБ ПОДАЧИ УСТРОЙСТВУ КОМАНДЫ НЕ ВЫПОЛНЯТЬ СИНХРОНИЗАЦИЮ ИЛИ ВВЕСТИ ЗАДЕРЖКУ СИНХРОНИЗАЦИИ ДЛЯ МУЛЬТИМЕДИЙНЫХ ПОТОКОВ Российский патент 2010 года по МПК H04L7/00 

ОБЛАСТЬ ТЕХНИКИ

[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] Вышеупомянутое описание вариантов осуществления настоящего изобретения было приведено в целях пояснения. Это описание не претендует на всесторонность и не ограничивает настоящее изобретение конкретной описанной формой, поскольку в свете вышеизложенных положений возможны изменения и модификации, или же возможны изменения, полученные в ходе применения настоящего изобретения. Описанные выше варианты осуществления настоящего изобретения были выбраны и объяснены для демонстрации принципов настоящего изобретения и его практического применения, с целью дать возможность специалистам в данной области использовать настоящее изобретение в различных вариантах его осуществления и вносить различные модификации, требуемые для конкретных вариантов использования.

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

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. Приемное электронное устройство, содержащее:
процессор; и
блок памяти, функционально связанный с указанным процессором и включающий компьютерный код, который при выполнении процессором заставляет приемное электронное устройство:
принимать множество мультимедийных потоков от передающего устройства;
принимать информацию, касающуюся указанного множества мультимедийных потоков, от указанного передающего устройства, причем эта информация включает специальную инструкцию для приемного устройства, допускающую невыполнение синхронизации или заданное максимально допустимое значение задержки синхронизации между, по меньшей мере, одним из указанного множества мультимедийных потоков и, по меньшей мере, еще одним потоком из указанного множества мультимедийных потоков;
если принятая информация включает специальную инструкцию, допускающую заданное максимально допустимое значение задержки синхронизации,
определять разницу во времени воспроизведения между указанным, по меньшей мере, одним из множества мультимедийных потоков и указанным, по меньшей мере, еще одним потоком из множества мультимедийных потоков и,
если эта разница больше, чем заданное максимально допустимое значение задержки синхронизации, задерживать воспроизведение указанного, по меньшей мере, одного из множества мультимедийных потоков для уменьшения указанной разницы до величины, меньшей или равной заданному максимально допустимому значению задержки синхронизации, и
представлять указанное множество мультимедийных потоков.