система и способ указания взаимосвязей треков в мультимедийном файле

Формула изобретения

1. Способ хранения кодированного мультимедийного содержания в иерархически структурированном контейнерном файле, содержащий: включение множества треков в контейнерный файл; определение информации о взаимосвязях треков, идентифицирующей взаимосвязи треков многоуровневых групп или кодирования с множеством описаний (MDC) среди множества треков; указание информации о взаимосвязях треков в блоке взаимосвязей треков; и организацию множества треков и блока взаимосвязей треков в иерархически структурированном контейнерном файле.

2. Способ по п.1, в котором блок взаимосвязей треков также содержит информацию о: числе групп альтернативных треков в контейнерном файле, идентификаторе для каждой группы альтернативных треков, числе треков в каждой группе альтернативных треков и идентификаторе для каждого трека в каждой группе альтернативных треков.

3. Способ по п.1, в котором блок взаимосвязей треков также содержит информацию о: числе групп переключаемых треков в контейнерном файле, идентификаторе для каждой группы переключаемых треков, числе треков в каждой группе переключаемых треков и идентификаторах для каждого трека в каждой группе переключаемых треков.

4. Способ по п.1, в котором блок взаимосвязей треков также содержит информацию о: числе многоуровневых групп треков в контейнерном файле, идентификаторе для каждой многоуровневой группы треков, числе треков в каждой многоуровневой группе треков, идентификаторе для каждого трека в каждой многоуровневой группе треков, для каждого трека, указание числа других треков, от которых прямо или косвенно зависит соответствующий трек, и для каждого трека, идентификацию других треков, от которых прямо или косвенно зависит соответствующий трек.

5. Способ по п.1, в котором блок взаимосвязей треков также содержит информацию о: числе групп треков MDC в контейнерном файле, идентификаторе для каждой группы треков MDC, числе треков в каждой группе треков MDC и идентификаторе для каждого трека в каждой группе треков MDC.

6. Читаемый компьютером носитель, который хранит компьютерную программу, содержащую выполняемый компьютером программный код, обеспечивающий выполнение устройством способа по любому из пп.1-5.

7. Устройство для сохранения кодированного мультимедийного содержания в иерархически структурированном контейнерном файле, содержащее процессор; и блок памяти, подключенный к процессору с возможностью взаимодействия и включающий: компьютерный код для включения множества треков в контейнерный файл; компьютерный код для определения информации о взаимосвязях треков, идентифицирующей взаимосвязи треков многоуровневых групп или кодирования с множеством описаний (MDC) среди множества треков; компьютерный код для указания информации о взаимосвязях треков в блоке взаимосвязей треков; и компьютерный код для организации множества треков и блока взаимосвязей треков в иерархически структурированном контейнерном файле.

8. Устройство по п.7, в котором блок взаимосвязей треков также содержит информацию о: числе групп альтернативных треков в контейнерном файле, идентификаторе для каждой группы альтернативных треков, числе треков в каждой группе альтернативных треков и идентификаторе для каждого трека в каждой группе альтернативных треков.

9. Устройство по п.7, в котором блок взаимосвязей треков также содержит информацию о: числе групп переключаемых треков в контейнерном файле, идентификаторе для каждой группы переключаемых треков, числе треков в каждой группе переключаемых треков и идентификаторах для каждого трека в каждой группе переключаемых треков.

10. Устройство по п.7, в котором блок взаимосвязей треков также содержит информацию о: числе многоуровневых групп треков в контейнерном файле, идентификаторе для каждой многоуровневой группы треков, числе треков в каждой многоуровневой группе треков, идентификаторе для каждого трека в каждой многоуровневой группе треков, для каждого трека, указание числа других треков, от которых прямо или косвенно зависит соответствующий трек, и для каждого трека, идентификацию других треков, от которых прямо или косвенно зависит соответствующий трек.

11. Устройство по п.7, в котором блок взаимосвязей треков также содержит информацию о: числе групп треков MDC в контейнерном файле, идентификаторе для каждой группы треков MDC, числе треков в каждой группе треков MDC и идентификаторе для каждого трека в каждой группе треков MDC.

12. Способ анализа кодированного мультимедийного содержания иерархически структурированного контейнерного файла, включающий: обнаружение блока взаимосвязей треков, содержащегося в контейнерном файле, содержащем множество треков, при этом блок взаимосвязей треков содержит информацию о взаимосвязях треков, идентифицирующую кодирование с множеством описаний (MDC) или взаимосвязи треков многоуровневых групп среди множества треков; анализ указанной в файле информации о взаимосвязях треков, кодированной в указанном блоке взаимосвязей треков и идентифицирующей взаимосвязи треков многоуровневых групп или кодирования с множеством описаний (MDC) среди множества треков; и анализ множества треков контейнерного файла в соответствии с проанализированной информацией о взаимосвязях треков.

13. Способ по п.12, в котором блок взаимосвязей треков также содержит информацию о: числе групп альтернативных треков в контейнерном файле, идентификаторе для каждой группы альтернативных треков, числе треков в каждой группе альтернативных треков и идентификаторе для каждого трека в каждой группе альтернативных треков.

14. Способ по п.12, в котором блок взаимосвязей треков также содержит информацию о: числе групп переключаемых треков в контейнерном файле, идентификаторе для каждой группы переключаемых треков, числе треков в каждой группе переключаемых треков и идентификаторе для каждого трека в каждой группе переключаемых треков.

15. Способ по п.12, в котором блок взаимосвязей треков также содержит информацию о: числе многоуровневых групп треков в контейнерном файле, идентификаторе для каждой многоуровневой группы треков, числе треков в каждой многоуровневой группе треков, идентификаторе для каждого трека в каждой многоуровневой группе треков, для каждого трека, указание числа других треков, от которых прямо или косвенно зависит соответствующий трек, и для каждого трека идентификацию других треков, от которых прямо или косвенно зависит соответствующий трек.

16. Способ по п.12, в котором блок взаимосвязей треков также содержит информацию о: числе групп треков MDC в контейнерном файле, идентификаторе для каждой группы треков MDC, числе треков в каждой группе треков MDC и идентификаторе для каждого трека в каждой группе треков MDC.

17. Читаемый компьютером носитель, который хранит компьютерную программу, содержащую выполняемый компьютером программный код, обеспечивающий выполнение устройством способа по любому из пп.12-16.

18. Устройство для анализа кодированного мультимедийного содержания иерархически структурированного контейнерного файла, включающее процессор; и блок памяти, подключенный к процессору с возможностью взаимодействия и включающий: компьютерный код для обнаружения блока взаимосвязей треков, содержащегося в контейнерном файле, содержащем множество треков, при этом блок взаимосвязей треков содержит информацию о взаимосвязях треков, идентифицирующую кодирование с множеством описаний (MDC) или взаимосвязи треков многоуровневых групп среди множества треков; компьютерный код для анализа указанной информации о взаимосвязях треков, кодированной в указанном блоке взаимосвязей треков и идентифицирующей взаимосвязи треков многоуровневых групп или кодирования с множеством описаний (MDC) среди множества треков; и компьютерный код для анализа множества треков контейнерного файла в соответствии с проанализированной информацией о взаимосвязях треков.

19. Устройство по п.18, в котором блок взаимосвязей треков также содержит информацию о: числе групп альтернативных треков в контейнерном файле, идентификаторе для каждой группы альтернативных треков, числе треков в каждой группе альтернативных треков и идентификаторе для каждого трека в каждой группе альтернативных треков.

20. Устройство по п.18, в котором блок взаимосвязей треков также содержит информацию о: числе групп переключаемых треков в контейнерном файле, идентификаторе для каждой группы переключаемых треков, числе треков в каждой группе переключаемых треков и идентификаторе для каждого трека в каждой группе переключаемых треков.

21. Устройство по п.18, в котором блок взаимосвязей треков также содержит информацию о: числе многоуровневых групп треков в контейнерном файле, идентификаторе для каждой многоуровневой группы треков, числе треков в каждой многоуровневой группе треков, идентификаторе для каждого трека в каждой многоуровневой группе треков, для каждого трека, указание числа других треков, от которых прямо или косвенно зависит соответствующий трек, и для каждого трека, идентификацию других треков, от которых прямо или косвенно зависит соответствующий трек.

22. Устройство по п.18, в котором блок взаимосвязей треков также содержит информацию о: числе групп треков MDC в контейнерном файле, идентификаторе для каждой группы треков MDC, числе треков в каждой группе треков MDC и идентификаторе для каждого трека в каждой группе треков MDC.

Описание изобретения к патенту

Область техники

Настоящее изобретение относится, в общем, к хранению кодированных мультимедийных файлов. В частности, настоящее изобретение относится к хранению кодированных мультимедийных данных в файлах для локального воспроизведения или трансляции.

Предпосылки изобретения

Данный раздел нацелен на описание предпосылок или контекста изобретения, изложенного в формуле изобретения. Приведенное здесь описание может содержать известные принципы, но не обязательно ограничивается только теми, которые были реально предложены и разработаны.

Таким образом, если не указано обратное, описанное в данном разделе не ограничивается существующим уровнем техники и не признается существующим уровнем техники вследствие его включения в данный раздел.

Мультимедийные приложения имеют такие сервисы, как локальное воспроизведение, потоковое воспроизведение или воспроизведение по требованию, диалоговые и широковещательные/многоадресные сервисы. Технологии, используемые в мультимедийных приложениях, включают, среди прочих, кодирование мультимедийной информации (аудио/видео данных), ее хранение и передачу. Для различных технологий были приняты соответствующие стандарты. Масштабируемое кодирование позволяет получать масштабируемые мультимедийные потоки, в которых отдельный поток может кодироваться на нескольких уровнях. При использовании масштабируемого кодирования каждый уровень, совместно с необходимыми нижележащими уровнями, является одним из возможных представлений мультимедийной последовательности с определенным пространственным разрешением, временным разрешением, заданным уровнем качества или некоторой комбинацией этих трех параметров. Часть масштабируемого потока может быть выделена и декодирована с необходимым пространственным разрешением, временным разрешением, заданным уровнем качества или некоторой комбинацией этих параметров. Масштабируемый поток содержит немасштабируемый базовый уровень и один или более улучшающих уровней. Улучшающий уровень может улучшать временное разрешение (т.е. частоту кадров), пространственное разрешение, или просто качество видеосодержания, представляемого нижележащим уровнем или его частью. В некоторых случаях данные улучшающего уровня могут быть отброшены, начиная с определенного места или даже с произвольно выбранных позиций, где каждая такая позиция может содержать добавочные данные, представляющие постепенно повышающееся качество видео.

SVC (масштабируемое видеокодирование, scalable video coding) является примером масштабируемого видеокодирования. Актуальный на сегодня проект стандарта SVC описан в документе JVT-S202 «Объединенная модель масштабируемого видео JSVM-6: Объединенный проект № 6 с предложенными изменениями» 19-ая встреча, Женева, Швейцария, апрель 2006 г., полностью включенном в настоящий документ путем ссылки.

При видеокодировании с множеством точек наблюдения (multi-view video coding, MVC) видеопоследовательности на выходе различных камер, соответствующих различным видам, кодируются в один битовый поток. После декодирования для отображения конкретного вида показываются изображения, принадлежащие этому виду. Актуальный на сегодня проект стандарта MVC описан в документе JVT-T208 «Объединенная модель видео с множеством точек наблюдения (JMVM-6)» «Объединенный проект № 6 с предложенными изменениями», 20-ая встреча JVT, Клагенфурт, Австрия, Июль 2006 г., полностью включенном в настоящий документ путем ссылки.

При кодировании с множеством описаний (multiple description coding, MDC) входная мультимедийная последовательность кодируется в несколько подпотоков, каждый из которых называется описанием (description). Каждое описание является независимо декодируемым и представляет определенное качество мультимедийных данных. Однако, на основе декодирования одного или нескольких описаний, добавочное декодирование еще одного описания может дать повышение общего качества мультимедиа. MDC подробно обсуждается в документе «Кодирование с множеством описаний для передачи видео» «Multiple description coding for video delivery» Y. Wang, A. Reibman и S. Lin, заседания IEEE, т.93, № 1, январь 2005, полностью включенном в настоящий документ путем ссылки.

Важным звеном в цикле производства мультимедийного содержания (контента), его обработки, передачи и потребления является формат файла. Существует определенная разница между форматом кодирования и форматом файла. Понятие «формат кодирования» относится к действиям конкретного алгоритма кодирования, кодирующего информационное содержание в битовый поток. Понятие «формат файла», в отличие от него, включает систему организации сгенерированного битового потока таким образом, чтобы он мог быть доступен для локального декодирования и воспроизведения, передан в качестве потока или файла, и все это при использовании множества различных архитектур хранения и транспортировки. Также формат файла может облегчать обмен и редактирование мультимедийных данных. Например, большое число приложений потоковой доставки приложений требуют, чтобы заранее закодированный битовый поток на сервере сопровождался метаданными, хранящимися в «треках-указаниях», помогающих серверу в осуществлении потоковой передачи видео клиенту. Примеры информации, которая может входить в метаданные треков-указаний, включают информацию о привязке по времени, отметки точек синхронизации, указания по пакетированию. Эта информация используется для снижения вычислительной нагрузки на сервер и получения максимального качества сервиса для конечного пользователя.

Существующие стандарты форматов мультимедийных файлов включают формат файла ISO (ISO/IEC 14496-12), формат файла MPEG-4 (ISO/IEC 14496-14), формат файла AVC (ISO/IEC 14496-15) и формат файла 3GPP (3GPP TS 26.244). Существует также проект группы MPEG по разработке формата файла SVC, который станет поправкой к формату файла AVC. Параллельно группой MPEG прикладываются усилия по определению формата треков-указаний для сессий FLUTE (file delivery over unidirectional transport, доставка файлов с помощью однонаправленного транспортного протокола).

Формат файла ISO является основой, из которой вытекают все остальные вышеупомянутые форматы файлов. Все эти форматы файлов в совокупности, включая формат файла ISO, называются семейством форматов файлов ISO. В соответствии с семейством форматов файлов ISO каждый файл, будучи иерархически структурированным, содержит только один блок фильма (movie box), который может содержать один или более треков ( дорожек ), при этом каждый трек содержится в одном блоке трека (track box). Мультимедийная информация конкретного типа может храниться сразу на нескольких треках. Подмножество таких треков может образовывать группу альтернативных треков, в которой каждый трек может быть декодирован и выбран для воспроизведения или передачи независимо, при этом только один трек из группы должен быть выбран для воспроизведения или передачи.

Все треки в альтернативной группе являются кандидатами при выборе мультимедийной информации. Тем не менее, может не иметь смысла переключаться между некоторыми из этих треков во время сессии. Например, может разрешаться переключение между видеотреками с различным битрейтом при одинаковом размере кадра, но не разрешаться переключение между треками с отличающимся размером кадра. Аналогично, может позволяться выбор (но не переключение) треков с различными видеокодеками или со звуковым сопровождением на разных языках. Различение треков, доступных для выбора, и треков, доступных для переключения, осуществляется путем введения структуры подгрупп, называемых группами переключения. В то время как треки в альтернативной группе являются кандидатами для выбора мультимедийной информации, для треков из (под)группы переключения дополнительно доступно переключение в течение сессии. Различные группы переключения отражают различные аспекты воспроизведения, такие как различный размер кадра, высокое/низкое качество и т.п.

Формат файла ISO поддерживает треки-указания (hint tracks), предоставляющие детальные инструкции для инкапсуляции данных в передаваемые пакеты и передачи сформированных пакетов в соответствии с конкретными отметками времени. Механизм треков-указаний может использоваться серверами, такими, например, как приложения потоковой доставки, для аудио-, видеоданных реального времени. (Детальные инструкции могут включать указания по сборке заголовка пакета и охватывать также сборку полезной части (payload) пакета. При сборке полезной части пакета возможны ссылки на данные, находящиеся в других треках или объектах данных, т.е. при этом ссылкой обозначается какой фрагмент данных в конкретном треке или объекте данных предназначен для копирования в пакет во время его сборки. Механизм треков-указаний надстраивается над любым транспортным протоколом и в настоящее время формат трека-указания для транспортного протокола реального времени (Real-Time Transport Protocol, RTP), (IETF RFC 3550 (www.ietf.org/rfc/rfc3550.txt) (полностью включено в настоящий документ путем ссылки)) определен, а форматы треков-указаний для протоколов доставки файлов по однонаправленным каналам, таких как FLUTE (IETF RFC 3926 (www.ietf.org/rfc/rfc3926.txt) (полностью включено в настоящий документ путем ссылки)) и ALC (IETF RFC 3450 (www.ietf.org/rfc/rfc3450.txt) (полностью включено в настоящий документ путем ссылки)) находятся в процессе стандартизации.

Как было сказано выше, семейство форматов файлов ISO поддерживает треки-указания. Проект формата файла SVC поддерживает структуру данных, называемую экстрактором. Экстрактор аналогичен определенной части указания, но не привязан к конкретному транспортному протоколу. Экстрактор ссылается на подмножество данных порции мультимедийной информации (медиасэмпла), при этом данные, на которые осуществляется ссылка, соответствуют данным, необходимым в этой порции для декодирования и воспроизведения конкретного масштабируемого уровня.

Для многоадресных приложений с масштабируемыми мультимедийными потоками, информация масштабируемого потока может храниться на различных треках, при этом каждый трек будет соответствовать определенному масштабируемому уровню или некоторому множеству смежных уровней. Эти треки могут быть как треками-указаниями, так и треками-экстракторами. Как указывалось ранее, треком-экстрактором называют трек, который содержит экстракторы и, возможно, порции данных неэкстракторов, например блоки мультимедийных данных. Таким образом, если используется многоуровневая многоадресная передача, подпоток в каждом треке может передаваться в отдельной сессии транспортного протокола реального времени (Real-time Transport Protocol, RTP), а приемник подписывается на несколько RTP сессий, содержащих требуемый масштабируемый уровень и необходимые нижележащие уровни. Эти треки называются многоуровневой группой треков. Треки, входящие в состав многоуровневой группы треков, формируют независимо декодируемый масштабируемый поток, при этом декодирование подпотока, соответствующего каждому отдельному треку в многоуровневой группе треков, может зависеть от подпотоков, соответствующих другим трекам. Подобно этому, для потока MDC информация каждого подпотока, или описания, может также храниться на своем собственном треке. Эти треки, соответствующие всем описаниям MDC потока, называются группой треков MDC.

Протокол FLUTE, описанный в запросе на обсуждение (Request for Comments, RFC) IETF № 3926 (www.ietf.org/rfc/rfc3926.txt), полностью включен в настоящий документ путем ссылки, широко используется в качестве протокола доставки файлов для многоадресных и широковещательных приложений. FLUTE основан на протоколе асинхронного многоуровневого кодирования (asynchronous layered coding protocol, ALC), описанном в IETF RFC 3451 (www.ietf.org/rfc/rfc3451.txt). FLUTE наследует всю функциональность, определенную в протоколах ALC и LCT, которые полностью включены в настоящий документ путем ссылки. LCN определяет понятие каналов LCT для обеспечения широкой масштабируемости. Масштабируемость LCT была разработана на основе принципа управляемой приемником многоуровневой многоадресной передачи (Receiver-driven Layered Multicast, RLM), в которой приемник отвечает за соответствующий алгоритм контроля перегрузки, основанный на добавлении или удалении уровней передаваемых данных. Отправитель посылает данные на различных уровнях, каждый из которых адресуется отдельной группе многоадресной передачи.

В LCT один или несколько каналов могут использоваться для доставки файлов сессии FLUTE. Отправителю FLUTE предоставляется высокая степень свободы в отношении того, каким образом данные разбиваются между каналами LCT. Часто возникающий случай - отправка одних и тех же, но имеющих различный битрейт данных, по различным каналам LCT. В дополнение к этому отправитель FLUTE может действовать интеллектуально, позволяя приемникам запрашивать все файлы сессии FLUTE путем присоединения сразу по всем каналам на более короткое время, чем это обычно требуется при единственном канале. В таком случае данные, посылаемые в каждом отдельном канале, дополняют данные других каналов.

Информация о каналах LCT сессии FLUTE, а также о том, как данные разбиты между различными каналами, задается в настоящее время в спецификации треков-указаний FLUTE. Эта информация помогает серверу FLUTE выбирать нужные каналы и присоединять их к требуемой сессии FLUTE в соответствии с целевым приложением. Если треки в наборе треков-указаний FLUTE не зависят друг от друга, и в ходе сессии FLUTE планируется обработка только одного из этих треков, то, следовательно, они принадлежат группе альтернативных треков, и по меньшей мере их подмножество принадлежит группе переключаемых треков. Если же треки-указания FLUTE дополняют друг друга, они принадлежат к многоуровневой группе треков.

Существующие на сегодняшний день проекты файловых форматов не поддерживают способов обозначения многоуровневой группы треков или группы треков MDC. Более того, применяемым в настоящее время способом обозначения групп альтернативных или переключаемых треков является включение идентификатора (ID) выбираемой или переключаемой группы в структуру данных уровня треков (блок данных заголовка трека для групп альтернативных треков и блок выбора трека в пользовательском блоке данных уровня треков). Это влечет за собой необходимость анализа всех треков в блоке фильма для того, чтобы извлечь информацию о группах альтернативных или переключаемых треков. Если число треков велико, задача анализа становится сложной.

Сущность изобретения

Настоящее изобретение предлагает систему и способ указания информации о взаимосвязи треков в мультимедийных файлах. В частности, настоящее изобретение предлагает механизм указания информации многоуровневых групп треков и информации групп треков MDC, наряду с механизмом указания информации о взаимосвязях треков эффективным образом.

Эти и другие характерные особенности и достоинства настоящего изобретения, совместно с организацией и способом функционирования, будут пояснены в следующем ниже подробном описании с прилагающимися чертежами, на которых одни и те же элементы сохраняют постоянную нумерацию во всех чертежах.

Краткое описание чертежей

На фиг.1 показана типовая мультимедийная система связи, предназначенная для использования с различными вариантами осуществления настоящего изобретения.

На фиг.2 показан вид в перспективе мобильного телефона, пригодного для использования в вариантах реализации настоящего изобретения; и

фиг.3 является схематичным изображением телефонных электрических цепей в мобильном телефоне на фиг.2.

Подробное описание вариантов осуществления изобретения

На фиг.1 показана типовая мультимедийная система связи, предназначенная для использования с настоящим изобретением. Как видно из фиг.1, источник 100 данных предоставляет исходный сигнал в аналоговом, несжатом цифровом, сжатом цифровом формате или любой комбинации этих форматов. Кодирующее устройство 110 кодирует исходный сигнал в кодированный битовый поток мультимедийных данных. Кодирующее устройство 110 может кодировать более одного типа мультимедийных данных, или же более одного кодирующего устройства 110 может потребоваться для кодирования различных типов мультимедийных данных исходного сигнала. Кодирующее устройство 110 может также получать на вход синтезированную информацию, такую, например, как графику или текст, или быть способным порождать кодированный битовый поток синтезированных мультимедийных данных. В дальнейшем, для простоты описания, будет рассматриваться обработка кодированного битового потока только одного мультимедийного типа данных. Тем не менее, следует отметить, что широковещательные сервисы реального времени, как правило, содержат несколько потоков (в большинстве случаев, как минимум, по одному аудио, видео и текстовому потоку субтитров). Также следует отметить, что система может включать несколько кодирующих устройств, однако в дальнейшем для простоты описания будет рассматриваться только одно кодирующее устройство 110.

Кодированный битовый поток мультимедийных данных передается в устройство 120 хранения. Устройство 120 хранения может содержать память большой емкости любого типа для хранения кодированного мультимедийного битового потока. Формат кодированного мультимедийного битового потока в устройстве 120 хранения может быть простым самодостаточным форматом битового потока, или же один или более кодированных мультимедийных битовых потоков могут инкапсулироваться в контейнерный файл. Некоторые системы могут функционировать в режиме «на лету», т.е. минуя устройство хранения, при необходимости передавать кодированный мультимедийный битовый поток в передатчик 130, называемый также сервером. Формат битового потока, используемый при передаче, может быть простым самодостаточным форматом, или же один или более кодированных мультимедийных битовых потоков могут инкапсулироваться в контейнерный файл. Кодирующее устройство 110, устройство 120 хранения и передатчик 130 могут находиться на одном физическом устройстве или входить в состав различных устройств. Кодирующее устройство 110 и передатчик 130 могут оперировать с контентом реального времени «на лету», в этом случае кодированный мультимедийный битовый поток обычно хранится не постоянно, а буферизуется на короткие промежутки времени в кодирующем содержимое устройстве 110 и/или в передатчике 130 с целью сгладить отклонения в задержках обработки, передачи, а также в битрейте (битовой скорости) кодированных мультимедийных данных.

Передатчик 130 передает кодированный мультимедийный битовый поток с использованием стека протоколов передачи данных. Стек может включать (не обязательно ограничиваясь данным списком): транспортный протокол реального времени (Real-Time Transport Protocol, RTP), протокол пользовательских датаграмм (User Datagram Protocol, UDP), протокол Интернета (Internet Protocol, IP). В случае если стек протоколов передачи данных пакетно ориентирован, передатчик 130 инкапсулирует кодированный мультимедийный битовый поток в пакеты. Например, когда используется RTP, передатчик 130 заключает кодированный мультимедийный битовый поток в пакеты RTP в соответствии с форматом полезной нагрузки RTP. Как правило, для каждого типа мультимедийных данных имеется свой отдельный формат полезной нагрузки RTP. Следует еще раз отметить, что система может содержать более одного передатчика 130, но для простоты в дальнейшем описании рассматривается случай, когда имеется только один передатчик 130.

Передатчик 130 может быть соединен (или не соединен) со шлюзом 140 посредством сети связи. Шлюз 140 может выполнять различные функции, такие как трансляцию потока пакетов, соответствующего одному стеку протоколов передачи данных, в другой стек протоколов передачи данных, слияние и разветвление потоков данных, и обработка потоков данных в соответствии с возможностями нисходящей линии связи и/или приемника, например управление битрейтом пересылаемого потока в соответствии с преобладающими условиями нисходящей линии связи в сети. Примерами шлюзов 140 могут служить: устройства для реализации многоточечных аудио- и видеоконференций (multipoint conference control units, MCU), шлюзы между видеотелефонией с коммутацией каналов и коммутацией пакетов, серверы системы «нажми и говори в мобильной сети» (Push-to-talk over Cellular servers, PoC), инкапсуляторы IP в портативных широковещательных системах цифрового видео (digital video broadcasting-handheld, DVB-H), или приставках, перенаправляющих широковещательные передачи локально в домашние беспроводные сети. В случае, когда используется RTP, шлюз 140 называется микшером RTP и выполняет функции конечной точки RTP соединения.

Система содержит один или более приемников 150, способных, как правило, к приему, демодуляции и извлечению (декапсуляции) переданного сигнала с получением кодированного мультимедийного битового потока. Кодированный мультимедийный битовый поток в дальнейшем обычно обрабатывается декодирующим устройством 160, на выходе которого формируется один или несколько несжатых мультимедийных потоков. Наконец, рендерер 170 способен воспроизводить несжатые мультимедийные потоки, с помощью, например, громкоговорителя или дисплея. Приемник 150, декодирующее устройство 160, рендерер 170 могут находиться на одном физическом устройстве или могут входить в состав различных устройств. Следует понимать, что битовый поток, предназначенный для декодирования, может быть принят от удаленного устройства, находящегося в сети потенциально любого типа, а также являться информацией, полученной в результате работы локального аппаратного или программного обеспечения в устройстве. Необходимо также понимать, что хотя текст и примеры, содержащиеся в настоящем документе, могут описывать именно процесс кодирования, те же самые идеи и принципы применимы для соответствующего процесса декодирования и наоборот, что очевидно специалистам в данной области.

При использовании настоящего изобретения выбор треков для локального воспроизведения или передачи в мультимедийных приложениях упрощается в сравнении с общепринятой схемой. В случае локального воспроизведения или в одноадресных приложениях потоковой доставки, при выборе независимо декодируемого трека для конкретного типа мультимедийных данных, сначала находится информация о группах альтернативных треков с помощью блока взаимосвязей треков. В многоадресных приложениях с масштабируемыми или MDC потоками, треки в многоуровневой группе или группе MDC могут быть с легкостью найдены с помощью блока взаимосвязей треков и отобраны среди других многоуровневых или MDC групп.

В одном из вариантов осуществления настоящего изобретения, определяется новый блок (box), идентифицирующий взаимосвязи между треками, он называется в этом документе блок взаимосвязей треков . Блок взаимосвязей треков описывается следующим образом:

Тип блока:	'trel'
Контейнер:	Movie Box ('moov') - блок фильма
Обязательность:	нет
Количество:	ноль или один

Синтаксис блока взаимосвязей треков имеет следующий вид:

В приведенной выше синтаксической структуре version (версия) - целое число, определяющее версию блока взаимосвязей треков (0, как указано выше).

Flags (флаги) - 24-битное целое число с флагами. Задаются описанные ниже биты, при этом бит 0 - это бит с наименьшим значением, бит 1 - второй от наименьшего и т.д. Когда бит 0 равен 1, это означает, что в данном блоке присутствует информация о группе альтернативных треков. Когда бит 0 равен 0, это означает, что информация о группе альтернативных треков в данном блоке отсутствует.

Когда бит 1 равен 1, это означает, что в данном блоке присутствует информация о группах переключаемых треков. Когда бит 1 равен 0, это означает, что информация о группах переключаемых треков в данном блоке отсутствует.

Когда бит 2 равен 1, это означает, что в данном блоке присутствует информация о многоуровневых группах треков. Когда бит 2 равен 0, это означает, что информация о многоуровневых группах треков в данном блоке отсутствует.

Когда бит 3 равен 1, это означает, что в данном блоке присутствует информация о группах треков MDC. Когда бит 3 равен 0, это означает, что информация о группах треков MDC в данном блоке отсутствует.

Num_alternate_groups обозначает число групп альтернативных треков, о которых сообщается. Alternate_group_id обозначает идентификатор i-ой группы альтернативных треков, о которой сообщается. Это величина, не равная 0. Любой трек, на который ссылается alternate_group_id, имеет значение alternate_group (в блоке заголовке трека) равное значению alternate_group_id. Любой трек, имеющий значение alternate_group (в блоке заголовка трека) не равное 0, имеет соответствующий alternative_group_id. Num_tracks_in_alternate_group обозначает число треков в i-ой группе альтернативных треков, о котором сообщается. Alternate_track_id обозначает идентификатор j-го трека в i-ой группе альтернативных треков, о котором сообщается.

Num_switch_groups обозначает число групп переключаемых треков, о которых сообщается. Switch_group_id обозначает идентификатор i-ой группы переключаемых треков, о которой сообщается. Это величина, не равная 0. Для любого трека, соответствующего switch_group_id, в случае, если присутствует блок выбора трека, значение switch_group, указанное в блоке выбора трека, равно значению switch_group_id. Для любого трека, имеющего блок выбора трека, если alternate_group не равно 0, будет иметься соответствующий ему switch_group_id. Num_tracks_in_switch_group обозначает число треков в i-ой группе переключаемых треков, о которой сообщается. Switch_track_id обозначает идентификатор j-го трека в i-ой группе переключаемых треков, о котором сообщается.

Num_layered_groups обозначает число многоуровневых групп треков, о которых сообщается. Layered_group_id обозначает идентификатор i-ой многоуровневой группы треков, о которой сообщается.

Num_tracks_in_layered_group обозначает число треков в i-ой многоуровневой группе треков, о которой сообщается. Layered_track_id обозначает идентификатор j-го трека в i-ой многоуровневой группе треков, о которой сообщается.

Num_dependent_on_tracks обозначает число треков, от которых j-ый трек в i-ой многоуровневой группе треков прямо или косвенно зависит.

Dependent_on_track_id обозначает идентификатор к-го трека, от которого j-ый трек в i-ой многоуровневой группе треков прямо или косвенно зависит.

Num_mdc_groups обозначает число групп треков MDC, о которых сообщается. Mdc_group_id обозначает идентификатор i-ой группы треков MDC, о которой сообщается.

Num_tracks_in_mdc_group обозначает число треков в i-ой группе треков MDC, о которой сообщается. Mdc_track_id обозначает идентификатор j-го трека в i-ой группе треков MDC, о которой сообщается.

В дополнение к вышесказанному, информация о взаимосвязях треков может быть представлена в соответствии с другими вариантами осуществления настоящего изобретения. Например, возможно указание информации о многоуровневых группах треков или треков MDC на уровне треков. Для случая многоуровневых групп треков идентификатор многоуровневой группы указывается в блоке заголовка трека, в пользовательском блоке данных уровня треков или в любой другой структуре данных уровня треков. Ситуация аналогична для случая групп треков MDC. В другом варианте осуществления изобретения блок взаимосвязи треков может также содержаться в блоке заголовка фильма или в пользовательском блоке данных уровня фильма. Еще в одном варианте осуществления изобретения информация о различных типах групп треков может указываться в отдельных блоках. Возможны также, в дополнение к описанным в настоящем документе, иные варианты осуществления изобретения.

На фиг.2 и 3 изображено типовое электронное устройство 12, на основе которого может быть реализовано настоящее изобретение. Необходимо, тем не менее, понимать, что настоящее изобретение не ограничено использованием в конкретном электронном устройстве 12. Электронное устройство 12 на фиг.2 и 3 включает корпус 30, дисплей 32 в виде дисплея на жидких кристаллах, клавиатуру 34, микрофон 36, головной телефон 38, аккумулятор 40, инфракрасный порт 42, антенну 44, смарт-карту 46 в виде UICC в соответствии с одним из вариантов осуществления изобретения, кард-ридер 48, электронные цепи радиоинтерфейса 52, электронные цепи кодека, контроллер 56 и память 58. Все отдельно взятые цепи и элементы широко известны и применяются, например, в модельном ряду мобильных телефонов Nokia.

Устройства связи, реализующие настоящее изобретение, могут осуществлять связь с использованием различных технологий передачи данных, включая (но не ограничиваясь этим): множественный доступ с кодовым разделением (Code Division Multiple Access, CDMA), глобальную систему мобильной связи (Global System for Mobile Communications, GSM), универсальную систему мобильной связи (Universal Mobile Telecommunication System, UMTS), множественный доступ с разделением по времени (Time Division Multiple Access, TDMA), множественный доступ с разделением каналов по частоте (Frequency Division Multiple Access, FDMA), протокол управления передачей/протокол Интернета (Transmission Control Protocol/Internet Protocol, TCP/IP), службу коротких сообщений (Short Messaging Service, SMS), службу мультимедийных сообщений (Multimedia Messaging Service, MMS), сервис мгновенной передачи сообщений (Instant Messaging Service, IMS), Bluetooth, IEEE 802.11 и т.д. Устройство связи может осуществлять связь с использованием различных каналов связи, включая (не обязательно ограничиваясь данным списком) радио, инфракрасные, лазерные, кабельные соединения и т.п.

Настоящее изобретения описано в общем контексте шагов способа, который может быть реализован в одном из вариантов осуществления изобретения с помощью программного продукта, включающего компьютерно-выполняемые инструкции, такие как, например, программный код, выполняемый компьютерами в сетевой среде. Как правило, программные модули включают процедуры, программы, объекты, компоненты, структуры данных и т.д., которые выполняют определенные задачи или представляют определенные типы абстрактных данных. Компьютерно-выполняемые инструкции, связанные с ними структуры данных и программные модули служат примерами программного года для осуществления шагов способа, описанного в этом документе. Определенная последовательность таких исполняемых инструкций или связанных структур данных является примером соответствующих действий по реализации функций, описанных в этих шагах.

Программные и сетевые реализации настоящего изобретения могут быть выполнены с применением стандартных технологий программирования, использующих основанную на правилах или иную логику для осуществления различных шагов поиска в базе данных, шагов по сопоставлению, сравнению и принятию решений. Также следует отметить, что слова «компонент» и «модуль», при использовании их здесь и в формуле изобретения, нацелены на охват различных реализаций с использованием одной или более строки программного кода и/или аппаратные реализации, и/или оборудования для приема ручного ввода.

Вышеизложенное описание вариантов осуществления настоящего изобретения было приведено с целью иллюстрации. Оно не имеет целью быть исчерпывающим и ограничить настоящее изобретение точно описанной формой; изменения и модификации могут осуществляться на основании вышеприведенных идей или вытекать из практики применения настоящего изобретения. Варианты осуществления изобретения, выбранные и описанные для разъяснения принципов настоящего изобретения и их практического применения, предназначены для того, чтобы позволить специалистам использовать настоящее изобретение в различных вариантах его осуществления и с различными модификациями, соответствующими планируемому конкретному применению.