Результат интеллектуальной деятельности: СПОСОБЫ, УСТРОЙСТВА И КОМПЬЮТЕРНЫЕ ПРОГРАММЫ ДЛЯ УЛУЧШЕНИЯ ОТОБРАЖЕНИЯ ВИЗУАЛИЗАЦИИ ВО ВРЕМЯ ПОТОКОВОЙ ПЕРЕДАЧИ СПЛАНИРОВАННЫХ ПО ВРЕМЕНИ МУЛЬТИМЕДИЙНЫХ ДАННЫХ

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

Изобретение в целом относится к области потоковой передачи спланированных по времени мультимедийных данных по сетям связи, например, по сетям связи, соответствующим стандарту Интернет-протокола (IP), позволяющей передавать видеоданные как наборы пространственно-временных выборок, соответствующих заданной пространственной области первоначального видео. Более конкретно, изобретение относится к способам, устройствам и компьютерным программам для улучшения отображения визуализации во время потоковой передачи спланированных по времени мультимедийных данных.

УРОВЕНЬ ТЕХНИКИ

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

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

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

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

В контексте динамической и адаптивной потоковой передачи по HTTP стандарт под названием DASH (Dynamic Adaptive Streaming over HTTP - динамическая адаптивная потоковая передача по HTTP) появился в результате работы комитета по стандартизации MPEG ("ISO/IEC 23009-1, Dynamic adaptive streaming over HTTP (DASH), Part1: Media presentation description and segment formats"). Этот стандарт позволяет ассоциировать компактное описание мультимедийного контента мультимедийного представления с унифицированными указателями информационных ресурсов (URL) HTTP. Такая ассоциация обычно описывается в файле, называемом файлом манифеста или файлом описания. В контексте стандарта DASH этот файл манифеста представляет собой XML-файл, также называемый MPD-файлом (Media Presentation Description - описание мультимедийного представления). Существуют другие основанные на манифесте решения для потоковой передачи, такие как плавная потоковая передача (Smooth Streaming), также использующая XML-файл, или живая потоковая передача HTTP (HTTP Live Streaming), вместо этого использующая для манифеста простой текстовый файл, также называемый списком воспроизведения. В качестве предпочтительных вариантов осуществления как протокол потоковой передачи используется стандарт DASH, однако, описательная информация, добавленная в манифесте, может обеспечить те же самые эффекты и в других решениях.

Файлы манифеста собирают набор дескрипторов, которые определяют описательную информацию о мультимедийных выборках, описанных в манифесте. Дескриптор может представлять собой структурированные элементы, такие как, например, XML-узлы (элементы и/или атрибуты), или может быть описан с помощью JSON (JavaScript Object Notation - объектная нотация JavaScript; JavaScript является торговой маркой), или даже в формате простого текста при условии, что ключевые слова или комментарии предназначены для выражения этих дескрипторов.

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

В дополнение к такой ассоциации стандарт DASH предлагает разбивать каждый мультимедийный контент как функцию периодов времени. Декомпозиция во времени описана в MPD-файле. Соответственно, последний определяет ассоциацию между HTTP URL и компактным описанием каждого компонента из мультимедийного контента за каждый период времени. Каждый компонент мультимедийного контента может быть инкапсулирован в множественные независимые мультимедийные сегменты, соответствующие этим периодам времени. Количество мультимедийных компонентов может изменяться от одного периода к другому, и/или их свойства также могут изменяться от одного периода к другому. Эта декомпозиция на периоды времени представлена в стандарте DASH элементом <Period>.

Этот стандарт позволяет клиенту загружать желаемые компоненты мультимедийного контента мультимедийного представления в желаемые периоды времени.

Информация, раскрытая в манифесте, фактически извлечена из описательных метаданных, добавленных к сжатым мультимедийным данным во время этапа инкапсуляции. Существуют различные форматы инкапсуляции, также иногда называемые форматами контейнера, такие как, например, базовый формат медиа-файлов ISO (ISO BMFF), WebM, Quicktime, транспортный поток MPEG-2 и общий формат мультимедийных приложений (Quicktime и MPEG являются торговыми марками). В действительности, стандарт DASH является независимым от формата инкапсуляции.

Для иллюстрации в дальнейшем рассматривается инкапсуляция с использованием базового формата медиа-файлов ISO, определенного в контексте деятельности по стандартизации MPEG.

В частности, формат файла инкапсуляции может относиться к стандартизации инкапсуляции высокоэффективного видеокодирования (High Efficiency Video Coding, HEVC) и его масштабируемого расширения в базовом формате медиа-файлов ISO (ISO/IEC 14496, часть 15). ISO/IEC 14496-15 содержит раздел, описывающий инкапсуляцию вырезок HEVC как одной или более областей вырезок, соответствующих, например, интересующей области, или просто состоящее в разбиении видеокадров и обеспечении пространственного доступа в видеопоток.

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

Следует помнить, что разрешение видео непрерывно увеличивается, начиная от стандартной четкости (SD) до высокой четкости (HD) и до сверхвысокой четкости (например, 4K2K или 8K4K). Видеопоследовательности могут быть закодированы с использованием либо однослойного (например, HEVC), либо многослойного (например, масштабируемый HEVC) стандарта кодирования. В случае многослойного формата кодирования заданный слой может использоваться в качестве опорных данных для одного или более других слоев. Многоуровневая организация видео может быть эффективно представлена с использованием множественных зависимых компонентов мультимедийного контента, причем каждый компонент мультимедийного контента представляет слой видео на ином уровне масштабируемости. Чтобы декодировать заданный компонент мультимедийного контента, клиентское устройство должно иметь доступ к самому компоненту мультимедийного контента, но также и ко всем компонентам мультимедийного контента, от которых он зависит.

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

В то время как в первых приложениях стандарта DASH клиентские устройства загружали по одному представлению для каждого типа мультимедиа за раз, начал появляться более усовершенствованный сценарий, подобный тому, что описан ниже, в соответствии с которым несколько представлений заданного типа мультимедиа передаются в потоке одновременно. Существуют такие варианты использования для аудио следующего поколения, в которых множественные аудиопотоки могут передаваться и воспроизводиться одновременно, чтобы обеспечить более хорошее пользовательское восприятие. В манифесте стандарта DASH был определен конкретный дескриптор для описания такого случая использования. Это также имеет место для видео, когда пользователь может выбрать несколько частей видео, которые будут одновременно передаваться в потоке для визуализации в составном или собранном, или агрегированном видео. Это обычно имеет место для видеопотоков, организованных в пространственные подчасти, и сжатых на разных уровнях качества, как изображено на фиг. 1a. Эти пространственные подчасти могут быть описаны с помощью функции описания пространственных отношений стандарта DASH, как в примере, проиллюстрированном на фиг. 2. Пользователь может выбрать интересующую область (ROI) в большем видео и решить сфокусироваться на этой интересующей области.

Статья, озаглавленная "Design and evaluation of tile selection algorithms for tiled HTTP adaptive streaming" ("Дизайн и оценка алгоритмов выбора вырезок для адаптивной потоковой передачи HTTP вырезок"), авторы Jens Devloo и др., 2013, 2013, Lecture Notes in Computer Sciences, Vol. 7943, страницы 25-36, раскрывает предварительно сконфигурированные клиентские логические схемы адаптации в зависимости от сценария использования для больших видео, например, панорамных видео. В одном из рассматриваемых сценариев, позволяющих панорамирование и изменение масштаба, авторы представляют многопотоковый подход, в котором низкокачественная версия всегда передается в потоке клиенту, и только некоторые части в зависимости от доступной пропускной способности передаются в потоке клиенту с высоким качеством. Затем в соответствии с критерием видимости, т.е., с учетом того, покрывает или нет пространственная подчасть интересующую область для пользователя, клиент через модуль запроса вырезок загружает сначала видимые пространственные подчасти. Затем в зависимости от оставшейся пропускной способности клиент также загружает высокое качество для других пространственных подчастей, которые находятся близко к интересующей области.

Однако, хотя такое решение является эффективным с точки зрения использования пропускной способности, авторы изобретения заметили, что пользовательское восприятие может быть сомнительным.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Настоящее изобретение было разработано для решения одной или более упомянутых выше проблем.

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

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

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

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

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

В соответствии с конкретными вариантами осуществления участок изображения представляет собой все изображение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В соответствии с конкретным вариантом осуществления участок изображения представляет собой все изображение.

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

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

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

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

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

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

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

В варианте осуществления информация о качестве получена независимо из серверного устройства.

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

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

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

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

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

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

В соответствии с конкретными вариантами осуществления участок изображения представляет собой все изображение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В соответствии с конкретными вариантами осуществления участок изображения представляет собой все изображение.

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

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

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

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

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

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

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

В варианте осуществления информация о качестве получена независимо из серверного устройства.

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

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

Также обеспечен способ обработки описательных данных, которые описывают информацию относительно компонентов мультимедийного контента, причем способ содержит этапы

формирования описательных данных, и

передачи сформированных описательных данных клиенту,

причем описательные данные включают в себя:

по меньшей мере два набора адаптации;

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

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

информацию адреса, на которую ссылается клиент для запроса компонента мультимедийного контента.

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

формирования описательных данных, и

передачи сформированных описательных данных клиенту,

причем описательные данные включают в себя:

по меньшей мере два набора адаптации;

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

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

информацию адреса, на которую ссылается клиент для запроса компонента мультимедийного контента.

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

формирование описательных данных, и

передачу сформированных описательных данных клиенту,

причем описательные данные содержат:

по меньшей мере два набора адаптации, каждый из которых содержит одну или более альтернативных версий одного или более компонентов мультимедийного контента;

первую информацию, идентифицирующую для каждого набора адаптации ранжирование качества каждой альтернативной версии одного или более компонентов мультимедийного контента;

вторую информацию, указывающую соотношение между первой информацией, ассоциированной по меньшей мере с двумя наборами адаптации, и

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

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

формирование описательных данных, и

передачу сформированных описательных данных клиенту,

причем описательные данные содержат:

по меньшей мере два набора адаптации, каждый из которых содержит одну или более альтернативных версий одного или более компонентов мультимедийного контента;

первую информацию, идентифицирующую для каждого набора адаптации ранжирование качества каждой альтернативной версии одного или более компонентов мультимедийного контента;

вторую информацию, указывающую соотношение между первой информацией, ассоциированной по меньшей мере с двумя наборами адаптации, и

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

Фиг. 1, содержащая фиг. 1a и 1b, иллюстрирует пример разделенного кадра видео, в котором видеопоследовательность закодирована по трем уровням качества, и примеры композиций видео, соответственно;

Фиг. 2 иллюстрирует пример манифеста потоковой передачи, описывающего пространственные части или вырезки в битовом видеопотоке;

Фиг. 3 иллюстрирует серверное устройство стандарта DASH и клиентское устройство, позволяющие реализовывать варианты осуществления изобретения;

Фиг. 4 иллюстрирует типичное описание мультимедийного представления в стандарте DASH в соответствии со спецификацией MPEG DASH;

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

Фиг. 6, содержащая фиг. 6a-6d, иллюстрирует примеры манифестов в соответствии с вариантами осуществления "создателя контента" при использовании дескриптора правила качества и при использовании дескриптора эквивалентности качества;

Фиг. 7 является блок-схемой вычислительного устройства для реализации одного или более вариантов осуществления изобретения, и

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

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

Для иллюстрации в дальнейшем считается, что "мультимедийный компонент" (или "компонент мультимедийного контента") представляет собой элемент данных мультимедийного потока конкретного типа мультимедиа (например, аудиоинформацию, видео, текст или метаданные). В соответствии со стандартом MPEG мультимедийный компонент определен как "один непрерывный компонент мультимедийного контента с присвоенным типом мультимедийного компонента". В дальнейшем мультимедийный компонент используется более обобщенным образом, чем элемент ContentComponent в стандарте DASH.

Также для иллюстрации в дальнейшем считается, что "вырезка" представляет собой пространственную часть (или раздел, или участок) одного или более изображений. Изображения могут являться кадрами битового видеопотока (как проиллюстрировано на фиг. 1a) или всего лишь одного сжатого неподвижного изображения, безотносительно формата кодирования. Вырезка определена позицией (x, y) и размером (ширина (w), высота (h)). По умолчанию вырезка является статичной, то есть, для каждого кадра видеопоследовательности позиция и размер вырезки остаются одинаковыми. Однако могут использоваться динамические вырезки, позиция и/или размер которых изменяется по последовательности по кадрам или по временным сегментам. В соответствии со стандартом DASH MPEG, вырезка является прямоугольной областью блоков кодового дерева (объектов кодирования) в конкретном столбце вырезок (позиция x) и конкретном ряду вырезок (позиция y) в изображении.

"Область вырезок" в общем случае представляет собой прямоугольную область в изображении, также определенную посредством (x, y, w, h). Что касается вырезок, область вырезок может являться фиксированной по видеопоследовательности или нет. В соответствии с форматом ISO BMFF область вырезок представляет одну или более полных вырезок HEVC в одном или нескольких полных сегментах слоя, которые находятся в одном том же закодированном изображении, и которые не содержат никакие другие вырезки HEVC.

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

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

Также для иллюстрации в дальнейшем считается, что "составное видео или изображение" представляет собой пакет или комбинацию видео, или комбинацию компонентов видеоконтента. Это видео или изображение, полученные в результате сшивки, композиции или сборки по меньшей мере двух участков видеокадра или участков изображения. Участок видеокадра или участок изображения может соответствовать вырезке, области вырезок или области ROI..., а также участку изображения. Это позволяет визуализировать сшивку, композицию или сборку по меньшей мере двух участков видеокадра или участков изображения в одном кадре или изображении, отображаемом пользовательским устройством.

Наконец, "правило качества" рассматривается в дальнейшем как указания, которые обеспечивают ограничения или параметры для основанного на качестве выбора. Как описано далее, примером правила качества является max_quality_degradation.

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

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

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

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

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

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

Фиг. 1, содержащая фиг. 1a и 1b, иллюстрирует пример разделенного кадра видео, в котором видеопоследовательность закодирована по трем уровням качества, и примеры композиций видео, соответственно

Фиг. 1a иллюстрирует пример разделенного кадра видео (для ясности проиллюстрирован только один кадр, но все кадры видеопоследовательности могут иметь такое же разделение на вырезки), в котором видеопоследовательность закодирована по трем уровням качества: высокое ("HQ"), среднее ("MQ") и низкое ("LQ"), обозначенным 100, 110 и 120, соответственно.

Каждый уровень качества может быть закодирован как независимый битовый видеопоток. В качестве альтернативы каждый уровень качества может представлять собой слой масштабируемости другого слоя. Для иллюстрации кадр 100 высокого качества может представлять собой слой улучшения качества улучшающего слоя, соответствующего кадру 110 среднего качества, который представляет собой улучшающий слой базового слоя, соответствующего кадру 120 низкого качества.

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

В конкретном варианте осуществления вырезки представляют собой вырезки HEVC без зависимостей с другими вырезками. Это позволяет собирать набор выбранных вырезок (например, выбранный набор 105) в один битовый видеопоток, который может декодировать и отобразить один декодер HEVC.

Также возможно использование независимых вырезок и/или закодированных не в кодировке HEVC. Например, каждая вырезка может быть закодирована в своем собственном битовом видеопотоке возможно в формате кодировки, отличающемся от HEVC (например, AVC или VP9).

Для кодирования данных в масштабируемые слои может использоваться SHVC, SVC или любой масштабируемый или многослойный формат кодирования. Тогда клиентское устройство должно либо выполнить некоторую повторную сборку потока, чтобы подать его на единственный декодер, либо использовать несколько декодеров для воспроизведения составной видео, полученной в результате из выбранного набора вырезок.

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

Фиг. 1b иллюстрирует некоторые примеры композиций видео, которые могут использовать преимущества изобретения для получения выровненного качества на составной видео. Например, составное видео 150 получается в результате сопоставления пространственных частей двух отдельных битовых видеопотоков. Эти битовые потоки могут представлять собой разные версии одной и той же сцены или даже могут представлять собой битовые видеопотоки из разных сцен.

Составное видео 160 состоит из сборки частей одной и той же видео с разным качеством. Битовые видеопотоки, представляющие видео 161 и 162, могут являться независимыми битовыми видеопотоками или слоями масштабируемого битового потока. Они даже могут быть закодированы в разных форматах (таким образом, требуется несколько видеодекодеров на клиентской стороне), формат кодирования передается в формате ISO BMFF и раскрыт в атрибуте @codecs стандарта DASH.

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

Для такой многослойной составной видео и для примера 160 пространственная часть 1, исходящая из видео 162, помещается на более высокий слой, в то время как другие пространственные части из видео 161 (или даже она вся в целом) помещаются на нижний слой.

Фиг. 2 иллюстрирует пример манифеста потоковой передачи, описывающего пространственные части или вырезки в битовом видеопотоке. В конкретном случае стандарта MPEG DASH один дескриптор пространственного отношения (Spatial Relationship Descriptor, SRD) может быть ассоциирован с описанием каждой вырезки, области вырезок или пространственной части.

Для иллюстрации видео 200 разделено на 4 вырезки. Пример соответствующего манифеста 210 описания MPD стандарта DASH иллюстрирует описание каждой пространственной части (вырезки 1, 2, 3 и 4) с дескриптором SRD. Также для иллюстрации показано только описание MPD для вырезок 1 и 2.

Первый набор адаптации (AdaptationSet), имеющий идентификатор id="1", соответствует описанию вырезки 1. Он содержит одно представление (Representation) с разрешением 1920×1080 пикселей (одна четверть полного видеокадра). Дескриптор SRD (использующий дескриптор SupplementalProperty) определяет, что это видео является пространственной частью видео (не описанной в манифесте) с параметром source_id (первый параметр атрибута "value"), равным 1, с позицией его верхнего левого угла, обозначенной 220, в точке (0, 0) опорного кадра, ассоциированного с параметром source_id, равным 1. Размер этой пространственной части представляет половину опорного кадра в каждом направлении (ширина и высота, обозначенные 221, покрывают 1 по 2 произвольным блокам опорного кадра, обозначенным 222). Из дескриптора SRD можно заключить, что все опорное пространство в целом действительно представляет видео 4k2k (3840×2160 пикселей).

Как указано в дескрипторе SRD второго набора AdaptationSet, имеющего идентификатор id="2", этот набор AdaptationSet содержит описание другой пространственной части (вырезки 2). Этот дескриптор SRD использует дескриптор SupplementalProperty, чтобы определить, что вырезка принадлежит тому же опорному кадру, что и первый набор AdaptationSet (тот же самый source_id=1), и она расположена посередине на оси X (значение 1 по 2) и на начале оси y (значение 0), как проиллюстрировано номером 230, с такими же размерами, как у первой вырезки, как проиллюстрировано номерами 231 и 232.

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

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

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

Фиг. 3 иллюстрирует серверное устройство стандарта DASH и клиентское устройство, позволяющие реализовать варианты осуществления изобретения.

Как проиллюстрировано, мультимедийное серверное устройство 300 содержит мультимедийные представления и среди них, в частности, мультимедийное представление 305, которое содержит разные компоненты мультимедийного контента, например, потоки видеоданных и аудиоданных. Аудио и видеопотоки могут быть чередованы или сохранены независимо. Мультимедийное представление может предлагать альтернативные версии одних и тех же компонентов мультимедийного контента (с разной битовой скоростью, качеством, разрешением, частотой дискретизации, разными точками обзора во всенаправленных мультимедиа, таких как, например, видео с охватом 360°, и т.д.).

Например, компоненты мультимедийного контента этого мультимедийного представления инкапсулированы в соответствии с базовым форматом медиа-файлов ISO, и описываются и передаются в потоке в соответствии с рекомендациями стандарта DASH. В результате этапа инкапсуляции каждая альтернативная версия (или представление в контексте стандарта DASH, например, представления Representation 1 и Representation 2) разделяются по времени на малые независимые и последовательные временные мультимедийные сегменты (например, временные мультимедийные сегменты с 310-1 по 310-3 и с 311-1 по 311-3, соответственно), например, мультимедийные сегменты, соответствующие стандарту DASH и стандартам базового формата медиа-файлов ISO (соответственно ISO/IEC 23009-1 и ISO/IEC 14496, части 12 и 15), которые могут быть адресованы и загружены независимо. Каждый мультимедийный сегмент может содержать один или более компонентов мультимедийного контента в зависимости от того, мультиплексирован ли контент или нет. Адреса (т.е. адреса HTTP URL в проиллюстрированном примере) установлены серверным устройством 300 для всех мультимедийных сегментов, и создан манифест 315, описывающий мультимедийное представление (как описано, например, со ссылкой на фиг. 5a).

Следует помнить, что манифест, например, MPD, представляет собой документ, обычно XML-файл (или даже простой текстовый файл, для живой потоковой передачи HTTP), который описывает все компоненты мультимедийного контента, к которым можно осуществить доступ, для данного мультимедийного представления. Такое описание может содержать типы компонентов мультимедийного контента (например, аудио, видео, аудио-видео, метаданные или текст), продолжительности мультимедийных сегментов и адреса (например, URL), ассоциированные с мультимедийными сегментами, то есть, адреса, по которым могут быть получены компоненты мультимедийного контента. Компоненты мультимедийного контента могут быть описаны как альтернативные версии одного и того же контента, или как части одного и того же контента (например, пространственные части, интересующие области или вырезки видео с дескриптором SRD или полем видимости в виртуальной реальности или всенаправленном мультимедийном контенте), или как части "мультимедийного восприятия", которые описывают компоненты контента, предназначенные для совместного представления или отображения.

Обычно представление MPD основан на иерархической модели данных, как изображено на фиг. 4.

Фиг. 4 иллюстрирует типичное описание мультимедийного представления в стандарте DASH в соответствии со спецификацией MPEG DASH.

Как проиллюстрировано, оно главным образом состоит из одного или более периодов, обозначенных 400, каждый из которых описывается элементом Period, каждый элемент Period имеет время начала и продолжительность. В свою очередь каждый элемент Period главным образом состоит из одного или более элементов AdaptationSet, обозначенных 401.

Элемент AdaptationSet предоставляет информацию об одном или нескольких компонентах мультимедийного контента и их различных закодированных альтернативах, как проиллюстрировано номером 402. Каждая закодированная альтернатива для одного и того же компонента мультимедийного контента называется представлением (Representation), которое обычно состоит из одного или более мультимедийных сегментов и/или сегментов инициализации, обозначенных 403.

Возвращаясь к фиг. 3 и для иллюстрации, только один пример набора AdaptationSet из мультимедийного представления 305 проиллюстрирован в связи с серверным устройством 300. В соответствии с проиллюстрированным примером этот набор AdaptationSet содержит две альтернативных версии, обозначенных 310 и 311, одного и того же контента заданного типа мультимедиа, и мультимедийный сегмент также может содержать мультиплексированные данные разных типов мультимедиа. Каждая версия разделена на последовательные временные мультимедийные сегменты, например, на три последовательных временных мультимедийных сегмента с 310-1 по 310-3 и с 311-1 по 311-3, соответствующих трем последовательным временным интервалам.

Такой файл манифеста может быть отправлен клиентскому устройству 320 (этап 325), как правило по протоколу HTTP.

После приема файл 315 манифеста анализируется посредством синтаксического анализатора 307 клиентского устройства, чтобы определить, какие представления являются доступными, и какие мультимедийные сегменты с 310-1 по 310-3 и с 311-1 по 311-3 из мультимедийного представления 305 являются доступными.

Файл 315 манифеста также используется, чтобы определить адреса HTTP этих мультимедийных сегментов и отношения между этими мультимедийными сегментами. Здесь следует отметить, что файл 315 описания и мультимедийные сегменты, обобщенно обозначенные как 310 и 311, могут храниться на разных серверах. Кроме того, файл 315 манифеста дает элементы информации о контенте мультимедийного представления с помощью дескрипторов, например, элемента <Role> или элемента <Label>, или через обобщенный дескриптор, такой как элементы <EssentialProperty> или <SupplementalProperty>. Эти элементы информации могут содержать разрешение, битовую скорость и подобную информацию.

С учетом принятого описания модуль 308 логической схемы адаптации клиентского устройства 320 может, таким образом, выбрать мультимедийные сегменты из подходящих версий, чтобы отправить соответствующие запросы HTTP (этап 330) для загрузки этих мультимедийных сегментов.

В ответ серверное устройство 300 передает требуемые временные мультимедийные сегменты (этап 335). Эти временные мультимедийные сегменты, принятые в ответе HTTP 335, могут быть проанализированы (или подвергнуты декапсуляции) модулем 340 синтаксического анализатора (например, модулем считывания mp4 или ISOBMFF), и каждый мультимедийный поток отправляется подходящему мультимедийному декодеру 341 и 342. Существует по меньшей мере один декодер для каждого типа мультимедиа (например, декодер 341 для аудиоинформации и декодер 342 для видео), и факультативно несколько дополнительных декодеров для типа мультимедиа, например, декодер 343 для видео. Также могут иметься дополнительные декодеры для других типов мультимедиа, таких как, например, аудиоинформация.

В конце декодированные мультимедийные потоки воспроизводятся в модуле 345 отображения. Иногда модуль 345 отображения включает в себя процесс преобразования, например, чтобы спроецировать панорамное изображение в новый опорный кадр (опорный кадр отображения), или модуль обрезки, чтобы вместить большое изображение в малое окно отображения, или функциональные возможности постобработки для применения фильтров к декодированным изображениям.

Следует отметить, что серверное устройство 300 может состоять из отдельных серверных устройств, каждое из которых выполняет один или более из следующих этапов:

- формирование мультимедийного контента,

- инкапсуляция мультимедийного потока в формате файла,

- формирование манифеста потоковой передачи или файла списка воспроизведения,

- передача мультимедийного представления, и

- передача мультимедийного контента, чаще всего как сегментов контента.

Клиентское устройство, таким образом, может выдавать запросы манифеста первому серверному устройству, например, устройству сервера приложений, и запросы мультимедийного контента одному или более другим серверным устройствам, например, серверным устройствам мультимедиа или серверным устройствам потоковой передачи. Серверное устройство, которое передает мультимедийные выборки, также может быть другим, например, если мультимедийные данные доставляются через CDN (сеть доставки контента).

В соответствии с конкретными вариантами осуществления серверное устройство 300 представляет собой серверное устройство HTTP/2, поддерживающее директивы принудительной доставки из стандарта DASH, часть 6. В таком случае некоторые данные могут принудительно доставляться клиентскому устройству 320, как проиллюстрировано номером 336, при условии, что клиентское устройство также поддерживает HTTP/2, и предпочтительно стандарт DASH, часть 6 (следует отметить, что поддержка стандарта DASH, часть 6 не требуется для реализации изобретения, за исключением конкретных вариантов осуществления, называемых "серверным управлением").

Фиг. 5, содержащая фиг. 5a и 5b, иллюстрирует использование правил качества для улучшения качества визуализации во время потоковой передачи мультимедийных данных с точки зрения серверного устройства и с точки зрения клиентского устройства, соответственно.

Фиг. 5a иллюстрирует разные альтернативы, направленные на подготовку мультимедийного потока авторами данных контента для доставки, в соответствии с вариантом осуществления "формирования контента".

Как проиллюстрировано, первый этап таких вариантов осуществления направлен на запись мультимедийного контента, также называемого мультимедийным представлением, например, аудиозапись (этап 501) и видеозапись (этап 502).

Записанный мультимедийный контент затем может быть факультативно обработан в модуле 503 анализа видео, чтобы извлечь некоторые признаки, в частности, из видео, которое пользователь может использовать для управления аудиокодером и/или видеокодером, обобщенно обозначенными 505 и 506, соответственно.

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

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

То же самое относится к аудиоданным и аудиокодированию.

Модуль анализа видео также может сформировать аннотации видео, которые могут рассматриваться как потоки метаданных (текстовые данные или структурированные данные, такие как XML или JSON), возможно спланированные по времени метаданные, которые могут быть выровнены по времени с видеокадрами и/или аудиокадрами. Если пользователь имеет дополнительные ресурсы для записанного контента, они также могут быть добавлены в качестве других дорожек метаданных, предоставляющих информацию о мультимедийном представлении. Модуль анализа видео также может получить информацию и/или статистику от мультимедийных кодеров 505 или 506 и сохранить соответствующие элементы информации как дорожки метаданных. Например, в случае битовых видеопотоков элементы информации о качестве могут быть сохранены для каждого кадра. Когда пространственное разделение сконфигурировано пользователем, эти элементы информации могут быть сохранены для каждой вырезки.

Когда кодирование выполнено, все мультимедийные потоки плюс потоки метаданных инкапсулированы в один или более медиа-файлов. Снова пользователь может сконфигурировать метод, посредством которого инкапсулирован мультимедийный контент (этап 532). Например, битовые видеопотоки могут быть инкапсулированы в одну дорожку или в отдельные дорожки. В соответствии с конкретными вариантами осуществления, если форматом кодировки является HEVC или многослойный HEVC с вырезками, пользователь может инкапсулировать каждую вырезку в дорожке вырезок с дескриптором области вырезок и собрать общую информацию в базовую дорожку вырезки.

Когда закодированы независимые потоки, пользователь может инкапсулировать один битовый видеопоток в свою собственную дорожку. Если эти битовые видеопотоки фактически являются пространственными частями другой видео, пользователь может аннотировать каждую видеодорожку дескриптором области вырезок, известным как 'trif' (как определено в разделе 10 ISO/IEC 14496-15, 4-й выпуск). В зависимости от пользовательских настроечных параметров или от модуля анализа видео пользователь может управлять гранулярностью пространственных частей, инкапсулированных в дорожке.

Когда дорожка метаданных присутствует в качестве аннотации 507 видео или некоторое пользовательское описание 508, эта дорожка метаданных может быть ассоциирована с рассматриваемой видеодорожкой через тип ссылки на дорожку 'cdsc'. Это указывает, что дорожка метаданных содержит описательную информацию для видеодорожки. Примером дорожки метаданных может являться динамическая информация области ROI или метрики качества, как определено в ISO/IEC 23001-10.

Затем после этапа 509 инкапсуляции пользователь может управлять упаковкой данных для адаптивной потоковой передачи (этап 533). Этот этап может быть выполнен в соответствии с конкретным вариантом осуществления посредством модуля записи mp4 (ISO BMFF). Также могут быть использованы другие форматы упаковки или описательные форматы, такие как MPEG CMAF, WebM, Matroska или транспортный поток MPEG-2. Во время этого этапа пользователь может выбрать формат адаптивной потоковой передачи, например, стандарт DASH, HLS или Smooth Streaming (удостоверившись, что формат инкапсуляции, выбранный на этапе 532, поддерживается протоколом потоковой передачи, выбранным на этапе 533).

В соответствии с конкретным вариантом осуществления пользователь выбирает стандарт DASH, тем самым приводя к формированию MPD в качестве файла манифеста и к формированию сегментов инициализации и мультимедийных сегментов. Сегменты инициализации содержат данные для настройки декодеров клиентских устройств, в то время как мультимедийные сегменты фактически содержат мультимедийные данные. В зависимости от выбора кодирования на этапе 531 или конфигурации (если настроечные параметры фиксированы) мультимедийных кодеров 505 и 506 может быть несколько альтернативных версий одного и того же мультимедийного компонента. Мультимедийный компонент представляет собой один аудиопоток, или один видеопоток, или один поток метаданных, или любой поток с конкретным типом мультимедиа. Видеопоток может фактически соответствовать полной видео или разделам полной видео, таким как как вырезка, набор вырезок, или соответствовать интересующей области.

Следует отметить, что для живого контента этапы 531, 532 и 533 пользовательского управления могут быть не возможными, поскольку они вносят некоторую задержку. В таком сценарии пользователь априорно конфигурирует разные модули, отвечающие за кодирование (505, 506), инкапсуляцию (509) и формирование манифеста и сегментов (510).

Фиг. 5b иллюстрирует пример этапов для обработки мультимедийных данных клиентским устройством (например, клиентским устройством 320 на фиг. 3).

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

После приема (этап 552) манифест подвергается синтаксическому анализу (этап 553), чтобы построить представление MPD в памяти или скомпилированный MPD организации мультимедийного представления с точки зрения ресурсов мультимедиа и их альтернативных представлений.

Из манифеста клиент может определить, объявлены ли в файле манифеста композиции или предвыборки (проверка 554). Это может быть сделано посредством поиска элемента <Preselection> (предвыборка) или дескриптора, или другого дескриптора, указывающего, что ресурсы могут быть агрегированы перед их предоставлением синтаксическому анализатору (для декапсуляции и формирования битового мультимедийного потока) и мультимедийному декодеру. В конкретном случае видео вырезок, это может заключаться в проверке, существует ли представление Representation или набор AdaptationSet, соответствующий базовой дорожке вырезки, и соответствующие представления Representation или наборы AdaptationSet, описывающие дорожки вырезок. Дорожки вырезок могут быть легко идентифицированы через атрибут кодеков (со значением, начинающимся с 'hvt1') в элементах Representation, AdaptationSet, Preselection или SubRepresentation.

Если композиции или предвыборки объявлены в файле манифеста, и если клиентское устройство может обрабатывать эти композиции или предвыборки (проверка 555), клиентское устройство осведомлено о том, что процесс выбора должен быть выполнен для динамической адаптации к сетевым условиям (например, к вариациям пропускной способности или вариациям задержки). Затем клиентское устройство исследует файл манифеста (этап 556) для поиска в манифесте дополнительного описания, обеспечивающего некоторое руководство по адаптации качества, помогающее клиентскому устройству определить комбинацию данных для запроса (как описано далее).

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

Если клиентское устройство не поддерживает такой передовой опыт, оно определяет через взаимодействие с серверным устройством (как описано далее со ссылкой на варианты осуществления "серверного управления"), может ли оно полагаться на сервер для обработки адаптации качества (проверка 558).

Если клиентское устройство может полагаться на сервер для обработки адаптации качества, оно запрашивает интересующий основной мультимедийный компонент (этап 559), например, основной ресурс в предвыборке, только область ROI в видео вырезки, пользовательский ракурс в видео с охватом 360°, или только один мультимедийный поток без ассоциированных дополнительных ресурсов, таких как потоки метаданных, и оно обеспечивает серверному устройству указания, чтобы принять дополнительный контент (оставшийся контент предвыборки или комбинации композиции мультимедийных компонентов с тем же самым типом мультимедиа).

Если клиентское устройство не может полагаться на сервер для обработки адаптации качества (проверка 558), сервер может сообщить пользовательскому устройству, что некоторые функции могут быть недоступными (этап 560), например, некоторые режимы просмотра для выровненного качества по всей составной видео в целом (например, область ROI плюс окружающие вырезки) могут быть не разрешены. Сервер также может не сообщать пользователю о не поддерживаемых функциях и адаптировать навигационные меню и/или функции, предлагаемые пользователю в графическом интерфейсе. Это может быть сделано, например, посредством исключения из рассмотрения элементов MPD, объявляющих композиции, комбинации или предвыборки в представлении MPD в памяти, или скомпилированного MPD, построенного на этапе 553. В таком случае клиент переходит к базовому стандарту DASH, в котором мультимедийные компоненты данного типа мультимедиа передаются в потоке в данный момент времени (этап 561).

Как проиллюстрировано, то же самое относится к случаю, если клиентское устройство не может обрабатывать композиции или предвыборки (проверка 555).

Если клиентское устройство поддерживает передовой опыт (проверка 557), оно может воспроизводить комбинации, предвыборки или композицию, объявленные в манифесте. В соответствии с этим оно во время потоковой передачи активирует и применяет логическую схему усовершенствованной адаптации (этап 562), описанную далее. Затем клиентское устройство запрашивает разные мультимедийные сегменты, соответствующие всем выбранным мультимедийным компонентам композиции, предвыборки или комбинации. Подходящая версия для каждого сегмента для загрузки вычисляется логической схемой усовершенствованной адаптации.

Если манифест содержит дополнительную информацию, обеспечивающую некоторое руководство по адаптации качества (проверка 556), также называемое правилами адаптации качества, например, санкционированное ухудшение качества между смежными видеопотоками, которые будут воспроизводиться как единое составное видео, клиентское устройство может полагаться на него для выбора подходящих мультимедийных сегментов для запроса (этапы 563 и 564).

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

Клиентское устройство может поддерживать одинаковый режим запросов во время всего сеанса потоковой передачи или может решить изменить его. Изменение режима запросов (этап 561, 559, 562 или 563) может произойти по решению клиентского устройства, или в ответ на пользовательский ввод, или в зависимости от серверного устройства. Один пример состоит в том, когда пользователь изменяет свой режим просмотра, например, переходит от просмотра интересующей области в полной видео к просмотру только области ROI. Этот пример приведет к переключению обратно на запрос базового мультимедийного потока (этап 561), например, если область ROI соответствует одной вырезке.

Аналогичным образом клиентское устройство может решить применить свою собственную логическую схему усовершенствованной адаптации (этап 562), несмотря на показатель относительно правил качества (проверка 556 и этапы 563 и 564). Однако клиентское устройство, пытаясь определять комбинацию данных для потоковой передачи, может столкнуться с проблемами адаптации (например, приостановка отображения, истощение или переполнение буфера, или составные мультимедийные потоки, требующие слишком большого объема вычислений для декодирования и/или отображения). В таком случае клиент может решить изменить свой режим запросов, например, с этапа 562 на этап 563. Другой пример, зависящий от серверного устройства, имеет место, когда клиентское устройство решает полагаться на серверное устройство (этап 559), например, с использованием принудительной доставки данных, и серверное устройство в какой-то момент решает прекратить принудительную доставку. В таком случае клиентское устройство может перейти в базовый режим (этап 561) или попытаться самостоятельно адаптировать выбор из нескольких мультимедийных компонентов (этап 562). Так или иначе, аннотации для адаптации правил качества, которые добавлены к манифесту, представляют собой лишь рекомендации от создателя контента (или от редактора MPD, агрегирующего мультимедийный контент) клиентскому устройству. Клиентское устройство может решить использовать их или не использовать (т.е., выполнять или не выполнять этап 563).

Следует также отметить, что пользователю могут быть обеспечены некоторые режимы браузера. Например, когда статическая область ROI определена во время кодирования, пользователю может быть сообщено, что присутствует одна область ROI, для выбора только между областью ROI, областью ROI в полной видео, но с высшим качеством, или обрезанным видео вокруг области ROI. Относительно двух последних возможностей конкретная логическая схема адаптации может использоваться, чтобы помочь клиенту выбрать хороший набор вырезок. Область ROI также может быть динамической или выбранной пользователем как предпочтительная часть видео, в которой следует попытаться оптимизировать качество. Если выбранная область соответствует нескольким компонентам видео, также требуется некоторая усовершенствованная адаптация, чтобы гарантировать согласованное качество во всем изображении в целом. Также для применения к контенту виртуальной реальности или всенаправленному контенту разное качество может быть выбрано между текущей точкой обзора пользователя и окружающими областями. Имеется хороший баланс качества для текущей точки обзора и окружающими областями, чтобы качество не падало слишком сильно, когда пользователь смотрит на другую точку в виртуальной сцене или в другую область во всенаправленном видео (т.е., следует управлять различием качества или разностью качества между разными областями).

Применение правил качества

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

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

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

Для иллюстрации эти варианты осуществления, в соответствии с которыми правила адаптации качества вставляются в манифест потоковой передачи, описаны в контексте стандарта DASH, т.е., как расширение MPD. Чтобы гарантировать согласованное пользовательское восприятие по клиентам стандарта DASH, создатель контента указывает некоторое руководство по выбору пространственно сходного контента, преимущественно с точки зрения качества. С этой целью MPD обеспечивает средство оповещения для ассоциирования компонентов мультимедийного контента с одинаковым типом мультимедиа, имеющих уровень качества, который создатель контента рассматривает как эквивалентный. Эта информация может быть определена модулем анализа видео (например, модулем 503 анализа видео на фиг. 5a), или из видеокодеров (например, видеокодеров 506 на фиг. 5a), журналов регистрации, или посредством кодирования параметров, определенных создателем контента (например, во время этапа 551 на фиг. 5b), или на основе субъективных тестов, выполненных создателем контента при кодировании мультимедийного контента.

Оповещение об эквивалентности качества или оповещение о качестве между наборами адаптации

Уровень качества представления Representation может быть определен атрибутом "qualityRanking" в элементе Representation в соответствии со стандартом MPEG, DASH, помня о том, что элемент Representation обычно описывает версию компонента мультимедийного контента, имеющего тип мультимедиа, равный видео. Контекст атрибута qualityRanking ограничен одним набором AdaptationSet, чтобы позволить упорядочить представления Representation в соответствии с уровнем качества в наборе AdaptationSet.

Поскольку комбинация участков изображений или вырезок, имеющих разные уровни качества, должна ранжировать представления Representation по наборам AdaptationSet, решение состоит в установлении привязок между уровнями качества разных наборов AdaptationSet на основе атрибута "qualityRanking". Это может быть сделано посредством использования нового дескриптора на уровне элемента Period (или даже на уровне элемента MPD, если ранги качества не изменяются от одного периода к другому). Такой новый дескриптор может быть выражен следующим образом:

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality_equivalence" value="1, 2" />

где новое значение @schemeIdUri указывает, что атрибут @qualityRanking обеспечивает qualityRanking по AdaptationSet, и атрибут "value" обеспечивает список AdaptationSet, затронутых этой перегрузкой @qualityRanking.

Например, в упомянутом ниже фрагменте MPD новый дескриптор указывает, что в течение заданного периода Period представление Representation с id "1.1" и представление Representation с id "2.1" могут рассматриваться как эквивалентные с точки зрения качества.

Приведенный ниже пример MPD иллюстрирует дескриптор эквивалентности качества.

<MPD...>

<Period>...

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality_equivalence" value="1, 2"/>

<AdaptationSet contentType=" video " id="1"...>

<Representation id=" 1.1 " bandwidth=" 1000 " qualityRanking=" 0 "...> <!--/*высшее качество*/->... </Representation>

<Representation id=" 1.2 " bandwidth=" 500 " qualityRanking=" 1 "...> <!-- /*среднее качество*/ ->... </Representation>

<Representation id=" 1.3 " bandwidth=" 250 " qualityRanking=" 2 "...> <!-- /*низкое качество*/ ->... </Representation>

</AdaptationSet>

<AdaptationSet contentType=" video " id=2...>

<Representation id=" 2.1 " bandwidth=" 1000 " qualityRanking=" 0 "...> <!-- /*высшее качество*/ ->... </Representation>

<Representation id=" 2.2 " bandwidth=" 800 " qualityRanking=" 1 "...> <!--/*среднее качество*/ ->... </Representation>

<Representation id=" 2.3 " bandwidth=" 500 " qualityRanking=" 2 "...> <!--/*низкое качество*/ ->... </Representation>

<Representation id=" 2.4 " bandwidth=" 250 " qualityRanking=" 3 "...> <!--/*низкое качество*/ ->... </Representation>

</AdaptationSet>

... </Period>

</MPD>

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

Показатель правила адаптации качества (или правила качества)

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

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

Например, создатель контента может указать, что должен иметься не более чем 1 уровень разности качества (в единицах ранжирования качества) между одной или более вырезок, соответствующих области ROI, и ее окружающими вырезками. Другими словами, создатель контента разрешает максимальное различие качества на один уровень качества. Чтобы выразить это, может использоваться следующий дескриптор:

<SupplementalProperty schemeIdUri="urn:mpeg:dash:max_quality_degradation "value="1"/>

Этот дескриптор, как и предыдущий, может быть помещен на уровень элемента MPD или на уровень элемента Period. Значение атрибута @schemeIdUri указывает предложенное максимальное ухудшение качества между одной вырезкой и ее соседними вырезками, или в более общем случае между одним мультимедийным компонентом и другим мультимедийным компонентом, которые будут отображены вместе. Атрибут @value указывает, что при воспроизведении набора представлений Representation одинакового типа мультимедиа из различных наборов AdaptationSet клиент не должен выбирать смежные представления Representation, имеющие разность рангов качества, превышающую 1.

Для иллюстрации такая схема адаптации может привести к следующему сценарию: сначала клиентское устройство пытается выбрать все пространственные части, формирующие составную видео с высшим качеством; если требуемая битовая скорость, соответствующая этому выбору, является слишком высокой для доступной пропускной способности, то оно переключается для понижения уровня качества для всех вырезок, кроме соответствующих интересующей области; если оно остается слишком высоким с точки зрения битовой скорости, то оно переключается на более низкий уровень качества для вырезок, соответствующих области ROI, а также для окружающих вырезок. Без использования такого правила качества клиентское устройство, возможно, выбрало бы представление Representation с наиболее высоким качеством для области ROI и с наиболее низким качеством для окружающих вырезок, что привело бы к резким переходам качества вокруг границ области ROI и произвело бы плохое пользовательское восприятие.

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

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality_equivalence" "value="1.1,2.1; 1.2, 2.2"/>.

Использование такого дескриптора больше не требует, чтобы был определен атрибут qualityRanking.

Затем предыдущий пример (сокращенно) переписывается как приведенный ниже пример:

<MPD...>

<Period>...

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality_equivalence" value="1.1, 1.2; 2.1, 2.2" />

<AdaptationSet contentType=" video " id=1...>

<Representation id=" 1.1 " bandwidth=" 1000 "...> <!--/* первый уровень качества */-->... </Representation>

<Representation id=" 1.2 " bandwidth=" 500 "...> <!--/* второй уровень качества */ -->... </Representation>...

</AdaptationSet>

<AdaptationSet contentType=" video " id=2...>

<Representation id=" 2.1 " bandwidth=" 1000 "...> <!--/* первый уровень качества */ -->... </Representation>

<Representation id=" 2.2 " bandwidth=" 800 "...> <!--/* второй уровень качества */ -->... </Representation>...

</AdaptationSet>

... </Period>

</MPD>

Следует отметить, что в соответствии с этим примером создатель контента гарантирует, что представление Representation с "1.1" и "1.2" имеет эквивалентное качество, даже если соответствующие пропускные способности не равны. Аналогичным образом, представления Representation с равными требованиями пропускной способности автоматически не означают, что они эквивалентны с точки зрения качества. Эквивалентность должна быть выведена из дескриптора эквивалентности качества, когда присутствует.

Кроме того, это прямая ассоциация между представлениями Representation выбираемых компонентов мультимедийного контента, безотносительно критерия, используемого создателем контента для эквивалентности качества (пропускная способность, разрешение, ассоциированные метаданные и т.д.).

Пример использования этого дескриптора эквивалентности качества направлен на случай, в соответствии с которым манифест потоковой передачи содержит масштабируемый поток, такой как, например, битовый видеопоток, закодированный с помощью SVC или SHVC. Если один и тот же манифест содержит альтернативы масштабируемому потоку, в котором каждый слой закодирован как битовый видеопоток, например, в AVC или HEVC, то дескриптор эквивалентности качества может использоваться, чтобы указать эквивалентность между независимым битовым потоком с одним или более слоями масштабируемого потока.

Приведенный ниже пример MPD обеспечивает пример для двух независимых битовых потоков (описанных посредством представления Representation "1.1" и "1.2"), закодированных в HEVC, для которых эквивалентность качества задана масштабируемым слоям масштабируемого битового потока HEVC (SHVC), представленного базовым слоем (Representation с id "2.1") и улучшающим слоем (Representation "2.2", которое зависит от Representation "2.1"). Типом масштабируемости в данном случае является пространственная масштабируемость, но это может применяться к другим типам масштабируемости, преимущественно многоракурсное кодирование HEVC. Атрибут кодека каждого представления Representation указывает формат кодировки.

<MPD....>

<Period>...

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality_equivalence " value="1.1, 2.1; 1.2, 2. 2"/>

<AdaptationSet contentType=" video " id=1...>

<Representation id=" 1.1 " codec="hvc1..." bandwidth=" 1000 " width=1920...>... </Representation>

<Representation id=" 1.2 " codec="hvc1..." bandwidth="2500 " width="3840"...>... </Representation>

</AdaptationSet>

<AdaptationSet contentType=" video " id=2...>

<Representation id=" 2.1 " codec="hvc1..." bandwidth=" 1000 " width="1920"...>... </Representation>

<Representation id=" 2.2 " codec="hvc2..." dependencyId="2.1" bandwidth=" 1200 "... </Representation>

</AdaptationSet>

... </Period>

</MPD>

Альтернативный вариант осуществления для дескриптора эквивалентности качества состоит в том, чтобы определить в качестве нового атрибута в определении представления Representation элемент, который указывает, какое представление Representation может быть объединено с другими представлениями Representation в MPD с эквивалентным качеством. Значением этого атрибута может являться, например, целое число без знака или строка. Каждое значение этого атрибута должно быть уникальным в течение заданного периода Period. Приведенный ниже пример обеспечивает пример такого дескриптора для информации ранга качества между наборами AdaptationSet:

<AdaptationSet id="1"...>

<Representation id="Rep1" bandwidth ="500000"... preselect="HQ"...>

...

</Representation>

<Representation id="Rep2" bandwidth ="250000"... preselect="MQ"...>

...

</Representation>

<Representation id="Rep3" bandwidth ="175000"... preselect="LQ"...>

...

</Representation>

</AdaptationSet>

<AdaptationSet id="2"...>

<Representation id="Rep4" bandwidth ="540000"... preselect="HQ"...>

...

</Representation>

<Representation id="Rep5" bandwidth ="280000"... preselect="MQ"...>

...

</Representation>

<Representation id="Rep6" bandwidth ="195000"... preselect="LQ"...>

...

</Representation>

</AdaptationSet>

В соответствии с этим вариантом осуществления клиентское устройство может немедленно идентифицировать три уровня предвыборки, которые представляют собой "HQ", "MQ" и "LQ". Значение, принимаемое этим новым атрибутом, может иметь тип строки (xs:string, когда выражено в XML-схеме). Использование этого атрибута действительно простое, поскольку все представления Representation, совместно использующие одинаковое значение в своем атрибуте "preselect", рассматриваются автором контента как являющиеся эквивалентными с точки зрения качества.

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

Это оповещение делает несложным поиск представлений Representation, которые могут быть комбинированы друг с другом без внесения различия качества: клиентское устройство выбирает набор представлений Representation, имеющих одинаковое значение в их атрибуте "preselect".

Существуют альтернативы для динамической адаптации и управления различием качества.

В соответствии с первой альтернативой значения атрибута preselect ограничены целыми числами без знака (xs:unsignedInt в XML-схеме). Посредством этого, клиентское устройство может определить, что когда оно имеет санкционированное ухудшение качества, установленное равным 2 уровням качества (либо через конкретное оповещение в манифесте, либо через конфигурацию клиентского устройства, либо через динамическое определение от пользователя через графический интерфейс), оно может выбрать одно первое представление Representation со значением атрибута preselect, установленным равным "N", и скомбинировать его с другими представлениями Representation, имеющими свои атрибуты preselect установленными равными не менее чем значение "N-2". По умолчанию, когда в манифесте не указана никакая информация о комбинации, композиции или предвыборке, все представления Representation с атрибутом preselect могут быть комбинированы.

Вторая альтернатива для динамической адаптации и управления различием качества главным образом состоит в определении другого атрибута в элементе Representation, например, атрибута, имеющего имя "max_quality_disparity" (может использоваться другое имя, если оно объявлено в XML-схеме MPD). Этот атрибут может быть объявлен как имеющий тип целого числа, его значение указывает максимальное различие качества или разность между выбранными мультимедийными компонентами, которые будут скомпонованы и воспроизведены одновременно.

Приведенный выше пример тогда переписывается следующим образом:

<AdaptationSet id="1"...>

<Representation id="Rep1" bandwidth ="500000"... preselect="HQ" max_quality_disparity="2">

...

</Representation>

<Representation id="Rep2" bandwidth ="250000"... preselect="MQ" max_quality_disparity="2">

...

</Representation>

<Representation id="Rep3" bandwidth ="175000"... preselect="LQ" max_quality_disparity="2">

...

</Representation>

</AdaptationSet>

<AdaptationSet id="2"...>

<Representation id="Rep4" bandwidth ="540000"... preselect="HQ" max_quality_disparity="2">

...

</Representation>

<Representation id="Rep5" bandwidth ="280000"... preselect="MQ" max_quality_disparity="2">

...

</Representation>

<Representation id="Rep6" bandwidth ="195000"... preselect="LQ" max_quality_disparity="2">

...

</Representation>

</AdaptationSet>

Когда в манифесте присутствует max_quality_disparity="2", когда уже существует дескриптор для описания максимального ухудшения качества, например, на верхнем уровне MPD, в элементе <Period> или элементе <MPD>, тогда этот параметр max_quality_disparity предпочтительно определяет значение дескриптора высокого уровня. В качестве альтернативы для значения атрибута параметр max_quality_disparity может быть помещен в элемент дескриптора стандарта DASH элемента Representation, такой как SupplementalProperty, например, или в специализированный элемент для показателя правила качества. Это относится также к случаю, когда Representation содержит элементы SubRepresentation. Параметр max_quality_disparity указывает, что автор контента рекомендует избегать объединять Representation или SubRepresentation с другим Representation или SubRepresentation, имеющим уровень качества на два шага ниже того, который содержит этот параметр max_quality_disparity.

Иллюстративными значениями для предложенного выше атрибута также может являться целое число со знаком, и значение "0" может указывать, например, версию по умолчанию, с которой следует начинать, положительное значение указывает более высокое качество, и более низкие значения указывают более низкое качество. Основное отличие для атрибута qualityRanking состоит в том, что это абсолютный показатель качества для заданного элемента Period, в то время как атрибут qualityRanking применяется только в одном наборе AdaptationSet.

Чтобы определить на основе этого варианта осуществления, какие наборы представлений Representation могут быть скомбинированы вместе, существует несколько альтернатив.

Первая альтернатива состоит в определении нового атрибута, используемого, чтобы определить представления Representation с эквивалентным качеством (который, например, может называться @preselect), как пары значений, содержащих два идентификатора: первый идентификатор, используемый для обеспечения уникального идентификатора для композиции, комбинации или предвыборки, и второй идентификатор, как описанный ранее, т.е., для обеспечения значения абсолютного качества по наборам AdaptationSet.

Первый идентификатор может рассматриваться как концептуально аналогичный параметру "source_id" в дескрипторе SRD стандарта DASH. Следует отметить, что с помощью внедрения этого первого идентификатора, контекст абсолютного качества может быть сокращен до представлений Representation, атрибут @preselect которых несет такое же значение для этого первого идентификатора. Этот идентификатор может представлять собой строку, или целое число, или любой тип, если возможно легко и быстро сравнить, отличается ли одно значение от другого.

Предыдущий пример переписывается следующим образом:

... <AdaptationSet id="1"...>

<Representation id="Rep1" bandwidth ="500000"... preselect="C1, HQ" max_quality_disparity="2">

...

</Representation>

<Representation id="Rep2" bandwidth ="250000"... preselect="C1, MQ" max_quality_disparity="2">

...

</Representation>

<Representation id="Rep3" bandwidth ="175000"... preselect="C1, LQ" max_quality_disparity="2">

...

</Representation>

</AdaptationSet>

<AdaptationSet id="2"...>

<Representation id="Rep4" bandwidth ="540000"... preselect="C1, HQ" max_quality_disparity="2">

...

</Representation>

<Representation id="Rep5" bandwidth ="280000"... preselect="C1, MQ" max_quality_disparity="2">

...

</Representation>

<Representation id="Rep6" bandwidth ="195000"... preselect="C1, LQ" max_quality_disparity="2">

...

</Representation>

</AdaptationSet>...

В приведенном выше примере имеется только одна композиция, комбинация или предвыборка, определенная с помощью идентификатора "C1". Разные уровни качества идентифицированы как "HQ", "MQ" или "LQ".

Приведенный ниже пример иллюстрирует использование одинакового атрибута только с двумя уровнями качества "HQ" и "LQ", но с двумя композициями, комбинациями или предвыборками, обозначенными "C1" и "C2". Для ясности возможная комбинация с атрибутом "max_quality_disparity" не показана в этом примере, но также могла бы применяться.

<MPD>...

<AdaptationSet id="1"...>

<Representation id="Rep1" bandwidth ="500000"... preselect="C1, HQ" >

...

</Representation>

<Representation id="Rep2" bandwidth ="175000"... preselect="C1, LQ" >

...

</Representation>

</AdaptationSet>

<AdaptationSet id="2"...>

<Representation id="Rep3" bandwidth ="540000"... preselect="C2, HQ" >

...

</Representation>

<Representation id="Rep4" bandwidth ="195000"... preselect="C2,LQ" >

...

</Representation>

</AdaptationSet>

<AdaptationSet id="3"...>

<Representation id="Rep5" bandwidth ="540000"... preselect="C1, HQ" >

...

</Representation>

<Representation id="Rep6" bandwidth ="195000"... preselect="C1,LQ" >

...

</Representation>

</AdaptationSet>

<AdaptationSet id="3"...>

<Representation id="Rep7" bandwidth ="640000"... preselect="C2, HQ" >

...

</Representation>

<Representation id="Rep8" bandwidth ="235000"... preselect="C2,LQ" >

...

</Representation>

</AdaptationSet>

...

</MPD>

В соответствии с этим примером клиентское устройство может легко вывести из синтаксического анализа MPD, что представление Representation с id="1" может быть комбинировано без разности качества с представлением Representation, имеющим id="5". Аналогичным образом представления Representation с id="3" и id="7" могут быть комбинированы. Эти две комбинации в качестве более низкого качества имеют комбинации: представления Representation с id="2" и id="6" и представления Representation с id="4" и id="8".

Правило качества и эквивалентность качества, обсуждаемые в этом варианте осуществления, также могут быть комбинированы с элементом <Preselection>, определенном в стандарте DASH, как обсуждается в соответствии с вариантами осуществления, называемыми "создателем контента".

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

Эквивалентность качества и дескрипторы правил качества применяются к компонентам контента, которые сообщаются как компонуемые или комбинируемые вместе. Это требует, чтобы дескриптор выборки компонентов контента сообщил клиенту, что предлагает создатель контента. Этот дескриптор выборки компонентов контента обсуждается и описывается ниже с вариантом осуществления для "создателя контента".

Существуют разные альтернативы для оповещения о шаблоне правила адаптации качества, в более общем случае, называемом дескриптором правила качества.

В соответствии с конкретными вариантами осуществления, он описан на уровне <MPD> или <Period> в зависимости от того, является ли правило адаптации фиксированным для всего представления в целом, или может изменяться от одного элемента Period к другому, обычно когда мультимедийное представление прерывается рекламными объявлениями в некоторые периоды, может быть полезно деактивировать правило адаптации качества в эти периоды (если объявления также не подразумевают композицию или комбинацию нескольких компонентов мультимедийного контента). Существуют случаи, в которых это правило адаптации качества может быть объявлено на более низких уровнях, чем элемент Period. Это может иметь место для представления видеопотоков, инкапсулирующих вырезки в дорожки вырезок, каждая из которых инкапсулирована в Representation.

Правило качества при указании максимального санкционированного уровня ухудшения может быть разбито на два измерения: указание первого значения в горизонтальном измерении и другого в вертикальном измерении. Например: <SupplementalProperty schemeIdUri="urn:mpeg:dash:max_quality_degradation value="1, 2"/> или с явными названиями атрибутов: <SupplementalProperty schemeIdUri="urn:mpeg:dash:max_quality_degradation value_h ="1" value_v="2"/>, чтобы указать максимальную санкционированную разность качества на один уровень в горизонтальном окружении и разность качества до 2 уровней качества в вертикальном измерении.

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

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality_rule_filter "value="3, 3, 2, 1, 2, 1, 0, 1, 2, 1, 2 "/>

указывает шаблон размером 3×3 с разными санкционированными значениями ухудшения качества вокруг пространственной части видео, расположенной на значении 0 (центр фильтра). "Подобное фильтру" сокращение качества также может быть разбито на два фильтра, по одному на каждое измерение, например:

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality_rule_filter_2D "value="(3, 1,0,1); (3, 1, 0,1)"/>, чтобы указать шаблон размером 1×3 с разными санкционированными значениями ухудшения качества вокруг пространственной части видео, расположенной на значении 0 для каждого из горизонтального и вертикального измерений.

Приведенный выше пример присваивает одинаковые значения в обоих направлениях, но имеются случаи, в которых полезно иметь разные шаблоны в соответствии с направлением. Это может быть выгодно для такого применения, как потоковая передача с охватом 360°, когда пользователь главным образом двигает головой вдоль одного направления: клиент может помещать больше качества в области, потенциально видимые пользователем (т.е., левый и/или правый ракурс относительно текущего вместо верхнего и нижнего). Правило качества даже может динамически вычисляться клиентом в зависимости от движения головы: при перемещении вправо качество будет с максимальной возможностью сохраняться для правых частей видео, и большее ухудшение позволяется в других направлениях (влево, вверх и вниз). В идеальном случае фильтр следует за решеткой вырезок или композиции пространственных частей, как изображено на фиг. 1a или 1b, чтобы весовой коэффициент адаптации качества определялся для каждого компонента предвыборки.

Он также может указать другие параметры, такие как атрибут maxDeltaQuality, maxHorizDeltaQuality, maxVertDeltaQuality или maxDiagDeltaQuality, показатель того, следует ли создать один битовый поток, показатель, относящийся к вырезкам или мультимедийным данным не вырезок. Другое правило качества может состоять в перечислении некоторых предварительно выбранных компонентов контента, чтобы они были заморожены во время одного или более сегментов, когда условия становятся тяжелыми (перегрузка сети, высокая задержка,...). Правило качества также может комбинироваться с дескриптором SRD посредством определения списка из параметра, такого как source_id, для указания на вырезку, или область в видео с охватом 360°, или контент виртуальной реальности, и максимального ухудшения качества, допустимого для соответствующей вырезки или области: например, value="<SRD_source_id>, NULL, <maxQualityDegradation>", или value="<SRD_source_id>, NULL, <maxHQualityDegradation> <maxVQualityDegradation>", чтобы определить одно ухудшение качества для каждого направления, или value="<SRD_source_id>, NULL, <maxHQualityDegradation> <maxVQualityDegradation> <maxDiagQualityDegradation>" для нагружения вырезок весовыми коэффициентами в соответствии с манхэттенским расстоянием. Правила качества также могут быть обозначены в дорожках метаданных с использованием конкретных значений @associationType. Например, конкретное значение associationType определено и записано как код из четырех символов (например: 'qinf' для информации о качестве), чтобы указать, что поток метаданных содержит метаданные для адаптации качества ассоциированного представления Representation или спланированных по времени выборок для информации о качестве на ассоциированном представлении Representation. Когда поток метаданных содержит правила качества, тогда дескриптор правила качества может непосредственно отразить это, например:

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality_rule_external "value=" (ID of the metadata stream) "/>

В соответствии с этими вариантами осуществления клиент потоковой передачи знает, что имеется шаблон ухудшения качества, указанный создателем контента (результат проверки 556 на фиг. 5b - "истина"). Он может принять его во внимание при запросе мультимедийных данных. Это должно быть полезно для согласованного восприятия между клиентским устройствам.

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

Создатель контента

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

В этих вариантах осуществления создатель контента делает неявным правило качества, предоставляя исчерпывающее описание возможных комбинаций компонентов мультимедийного контента (например, на этапе 533 на фиг. 5a или при конфигурировании кодеров, транскодеров или упаковщиков соответственно на этапах 531 и 532).

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

Элемент выборки компонентов контента может представлять собой расширение элемента <Preselection>, который существует в стандарте DASH MPD (с 4-ой поправки, как определено в w16221, июнь 2016). Дескриптор выборки компонентов контента также может представлять собой конкретный вид набора AdaptationSet с конкретным атрибутом или дескриптором для указания, что этот набор AdaptationSet является композицией, комбинацией или пакетом классических наборов AdaptationSet, объявленных в том же самом MPD, или, например, через элемент Xlink наборов AdaptationSet, которые объявлены в других MPD). Одним примером аннотации является новый атрибут, безотносительно его имени, для указания, что набор AdaptationSet является "виртуальным" набором адаптации:

<AdaptationSet virtual="true".... >

или "ссылочный" AdaptationSet, объявленный через дескриптор стандарта DASH:

<AdaptationSet....>

<EssentialProperty scheme_id_uri="urn:mpeg:dash:2017:component-selection" value="1, 2"/>...

</AdaptationSet>

В приведенном выше примере набор AdaptationSet для выборки компонентов контента ссылается на другие наборы AdaptationSet с id="1" и id="2". Это означает, что при использовании набора AdaptationSet в качестве выборки компонентов контента набор AdaptationSet, на который делается ссылка, должен объявить атрибут "id". Элемент выборки компонентов контента не объявляет URL сегмента, а вместо этого ссылается на другие наборы AdaptationSet. Элемент выборки компонентов (расширенный элемент Preselection или конкретный набор AdaptationSet) может содержать элементы представления Representation для объявления альтернативных версий композиции, комбинации или пакета, но эти представления Representation только ссылаются на другие представления Representation из наборов AdaptationSet, на которые делается ссылка посредством элемента выборки компонентов контента.

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

В частности, не ясно, должны ли воспроизводиться вместе все компоненты preselectionComponents, или только основной, или также допустимы основной плюс подмножество частичных наборов AdaptationSet.

В соответствии с другим вариантом осуществления изобретения предложено включить в элемент выборки компонентов контента дополнительный параметр, описывающий ожидаемое использование автора контента с точки зрения комбинации мультимедийных компонентов. Например, этот новый параметр (приведенное ниже имя "selectionType" является примером) обеспечен как дополнительный атрибут в элементе Preselection:

<Preselection id="P1" selectionType="all" preselectionComponents="(list of components)"...>... </Preselection>

<Preselection id="P2" selectionType="any" preselectionComponents="(list of components)"...>... </Preselection>

<Preselection id="P2" selectionType="main" preselectionComponents="(list of components)"...>... </Preselection>

Этот новый параметр также может быть объявлен в дескрипторе Preselection:

<SupplementalProperty schemeIdUri=" urn:mpeg:dash:preselection:2016" selectionType ="all" value=" (list of components)".../>

<SupplementalProperty schemeIdUri=" urn:mpeg:dash:preselection:2016" selectionType ="main" value=" (list of components)".../>

<SupplementalProperty schemeIdUri=" urn:mpeg:dash:preselection:2016" selectionType ="any" value=" (list of components)".../>

Следует отметить, что этот дополнительный параметр для намеченных или ожидаемых комбинаций мультимедийных компонентов в предвыборке Preselection или, в более общем случае, в элементе выборки компонентов контента относится к предвыборке Preselection безотносительно ее декларации: SupplementalProperty, EssentialProperty или конкретный элемент, наследующий от DescriptorType, определенный в схеме MPD. Это может быть реализовано как любой узел (например, элемент или атрибут) под элементом Preselection или дескриптором. В случае дескриптора Preselection это также может быть один из параметров, перечисленных в атрибуте "value".

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

- когда параметр имеет значение "any" ("любой"), это означает, что любая комбинация мультимедийных компонентов в элементе выборки компонентов контента (например, элемент Preselection или дескриптор) может быть выбрана для загрузки и визуализации, даже без мультимедийного компонента, соответствующего основному набору AdaptationSet;

- когда параметр принимает значение "main" ("основной"), это означает, что любая комбинация мультимедийных компонентов в элементе выборки компонентов контента (например, элемент Preselection или дескриптор) может быть выбрана для загрузки и визуализации при условии, что выбран мультимедийный компонент, соответствующий основному набору AdaptationSet;

- последним возможным значением является "all" ("все") - оно означает, что может быть воспроизведена только перечисленная комбинация, т.е., одна альтернативная закодированная версия для каждого мультимедийного компонента, объявленного в элементе выборки компонентов контента - например, в элементе Preselection это список, объявленный в атрибуте "preselectionComponents" - для дескриптора Preselection это будет список идентификаторов, обеспеченных в атрибуте "value" - таблица 800 на фиг. 8 обеспечивает для каждой комбинации между основным набором AdaptationSet и частичными наборами AdaptationSet возможные значения для этого параметра;

- другим возможным значением является "recommended" ("рекомендуемый"), или "best" ("наилучший"), или "fallback" ("резервный") со списком идентификаторов, обеспечивающих список компонентов в предвыборке Preselection, который обеспечивает интересующую комбинацию только между основным набором AdaptationSet и всей предвыборкой Preselection в целом - этот "рекомендуемый" или "наилучший" выбор может быть рассмотрен как рабочая точка перехода в резервный режим, когда некоторая адаптация с точки зрения потоковой передачи или обработки контента на стороне приемника требует адаптации - в таком случае может быть невозможно загрузить и визуализировать всю предвыборку в целом - переход в резервный режим только к основному набору адаптации может обеспечить плохое пользовательское восприятие при переключении обратно на подмножество компонентов, объявленных в предвыборке.

Альтернативный вариант осуществления для атрибута selectionType состоит в его использовании, чтобы явно указать, какой компонент контента соответствует основному мультимедийному компоненту (т.е. AdaptationSet или ContentComponent). Например, приведенная ниже декларация:

<Preselection id= "P1" preselectionComponents="3 1 2 4" selectionType="main 3">

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

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

Для ссылки на другие представления Representation для композиций или комбинаций создатель контента может использовать атрибут dependencyId, особенно для основного компонента контента (того, который должен воспроизводиться по умолчанию, когда клиент не может поддержать всю комбинацию в целом). Для других представлений Representation, на которые делается ссылка, создатель контента может объявить их через associationId со значением "aggregate" или любым зарезервированным или зарегистрированным значением для атрибута associationType, чтобы указать что associatedRepresentation, как определено стандартом DASH, содержит представление Representation с id, значение которого присутствует в атрибуте associationId, как один компонент мультимедийной композиции, мультимедийного восприятия или пакета.

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

В варианте осуществления изобретения предложено явно различать мультимедийные компоненты, которые могут быть выбраны и воспроизведены отдельно, от мультимедийных компонентов, которые описаны лишь потому, что они используются при вычислении других компонентов, или на них делается ссылка в пакете, предвыборке или выборке компонентов контента. Это позволяет проигрывателям потокового мультимедиа легко фильтровать мультимедийные компоненты для раскрытия пользователю или приложению, отвечающему за выбор контента. Это различие сделано с помощью дополнительного параметра, связанного с мультимедийными компонентами, например, такого как атрибут в элементах AdaptationSet, ContentComponent, Representation или Sub-Representation. В качестве примера этот атрибут можно назвать "playbackType".

Он может использоваться, например, с дорожками вырезок. Когда наборы AdaptationSet, описывающие дорожки вырезок, являются частью выборки компонентов контента (например, предвыборки Preselection), они могут иметь этот атрибут "playbackType" установленным как "disable" ("запретить"), чтобы указать, что дорожки вырезок нельзя выбрать для отдельного воспроизведения. Выборка компонентов контента (например, Preselection) в этом случае обеспечивает выбираемую часть мультимедийного представления (которую можно назвать точкой входа). Раскрытие всех дорожек как элемента Representation в элементе AdaptationSet, на который делается ссылка в элементе Preselection, и описание их как не выбранных для воспроизведения (@playback_type="disable") позволяет избежать неоднозначности, когда манифест содержит элемент AdaptationSet, описывающий дорожки с тем же самым типом кодека.

Например, это позволяет отличить базовую дорожку вырезок hvc2 или hev2 от составной дорожки hvc2 или hev2 или классической дорожки HEVC, которые сами могут быть объявлены как playbackType=="always" ("всегда") (что является значением по умолчанию.):

<AdaptationSet id="10" playbackType="disable"... >... </AdaptationSet>

<Preselection preselectionComponents="... 10..." id="P1"/>.

Мультимедийный компонент, который является точкой входа (значение первого мультимедийного компонента, который будет подвергнут синтаксическому анализу клиентом) в манифесте, может быть помечен значением "always" в этом атрибуте "playbackType". Это значение "always" является значением по умолчанию для "playbackType"; т.е., когда оно отсутствует, предполагается, что мультимедийный компонент может быть выбран и воспроизведен отдельно. "Отдельно" означает соответствующие текущие представления Representation плюс представления Representation, от которых зависит это текущее представление. Имя и возможные значения для этого нового параметра являются указательными и обеспечены в качестве примеров. Другим возможным значением является "preview" ("предварительный просмотр"), чтобы указать, что мультимедийный компонент может быть воспроизведен, когда пользователю или приложению нужен предварительный просмотр фильма, или несколько секунд аудиоклипа, или любое короткое представление элемента мультимедиа. Обеспеченные здесь примеры не являются исчерпывающими. Набор AdaptationSet, помеченный посредством этого атрибута, не должен рассматриваться клиентами стандарта DASH как интерактивно выбираемый и/или как точка входа в представлении.

Когда компоненты мультимедийного контента описаны посредством элемента SubRepresentation, элемент SubRepresentation также становится элементом выборки компонентов контента, и список компонентов для этого элемента SubRepresentation ссылается на компоненты из другого элемента SubRepresentations, содержащегося в представлениях Representation, на которые ссылается родительский элемент Representation этого элемента SubRepresentation.

Дескриптор эквивалентности качества и дескриптор правила адаптации качества в этих вариантах осуществления могут быть неявными, поскольку синтаксический элемент (Preselection, AdaptationSet или Representation), который содержит дескриптор выборки компонентов, обеспечивает упорядоченный список альтернатив. В дополнение к упомянутым выше дескрипторам описание мультимедийного представления также может содержать другие информативные дескрипторы: дескриптор целевого назначения (purpose) композиции (или "целевого назначения комбинации", или "целевого назначения предвыборки", или "целевого назначения пакета") и дескриптор требований декодера. Дескриптор целевого назначения композиции представляет собой дескриптор, ассоциированный с дескриптором выборки компонентов контента. Им может являться атрибут дескриптора выборки компонентов контента или элемент EssentialProperty или SupplementalProperty как дочерний элемент дескриптора выборки компонентов контента. Приведенный ниже отрывок MPD иллюстрирует использование такого дескриптора, когда дескриптор выборки компонентов контента использует элемент Preselection:

...<Preselection... purpose="HEVC tiling">

</Preselection>....

Описание целевого назначения может предоставить дополнительную информацию о намеченной комбинации, например, чтобы описать разные комбинации в соответствии с фиг. 1b. Например, когда композиция подразумевает независимые видео, когда делается обрезка на подмножестве извлеченных вырезок без модификации потока, когда несколько независимых видео собраны в единый битовый видеопоток. В случае, если существует только одна композиция или предвыборка, дескриптор целевого назначения и дескриптор требований декодера могут быть объявлены на уровне элемента MPD (если являются статичными) или на уровне элемента Period, если изменяются по времени.

Цель этого "целевого назначения композиции" состоит в том, чтобы сообщить клиентскому устройству о виде композиции, комбинации или предвыборки, которые автор контента подготовил для потоковой передачи. Это может использоваться клиентским устройством, чтобы настроить пользовательский интерфейс и предложить, или активировать, или деактивировать некоторые навигационные меню. Например, с проиллюстрированным выше целевым назначением "HEVC tiling" ("вырезки HEVC") клиентское устройство может отобразить пользователю решетку вырезок, чтобы пользователь мог легко выбрать ряд вырезок для одновременного воспроизведения. Возможны другие значения, такие как "область ROI плюс окружающие вырезки" или "основной ракурс с охватом 360° плюс другие ракурсы". Значение этого "целевого назначения комбинации" или "целевого назначения композиции" может иметь строковый тип. Это также может быть значение, извлеченное из списка предопределенных значений в реестре. Последний факультативный вариант обеспечивает возможность дополнительной интерпретации от клиентских устройств. Следует отметить, что элемент Label (метка) также может использоваться, чтобы выразить "целевое назначение комбинации" в манифесте потоковой передачи.

Другой необязательный дескриптор представляет собой дескриптор "требований декодера". Действительно, когда создатель контента обеспечивает усовершенствованные комбинации, для клиентского устройства может потребоваться использовать одновременно несколько декодеров. Таким образом, дескриптор требований декодера может использоваться в MPD под дескриптором выборки компонентов контента. Что касается предыдущего, это может быть конкретный атрибут или параметр в дескрипторе выборки компонентов контента или в дескрипторе стандарта DASH на scheme_id_uri. Например:

<Preselection...>...

<EssentialProperty scheme_id_uri="urn:mpeg:decoder-reqs" value="single"/>

...

</Preselection>

В случае, когда композиция, комбинация или предвыборка требует более одного экземпляра декодера заданного типа мультимедиа (например, видеодекодер 343 на фиг. 3 или аудиодекодер), значение этого дескриптора может быть установлено равным "multiple" ("несколько"). Он также может использоваться, чтобы указать выполнение операции пост-обработки немедленно вслед за этапом декодирования посредством клиентских устройств, которые реализуют некоторую пост-фильтрацию (например, value="post-filter"). Значения могут быть объединены (например, value="post-filter&single", чтобы указать с этапом пост-обработки требуется единственный декодер). Дескриптор требований декодера также может использоваться, чтобы рекомендовать операцию пост-фильтрации на клиентской стороне, когда, например, доступен фильтр удаления блочности. Операция пост-фильтрации может быть сообщена в информации пост-декодера, содержащейся в файле ISO BMFF, или даже обеспечена посредством потока метаданных. Она ассоциирована с элементом выборки компонентов контента.

В случае, когда элемент Preselection определен как набор мультимедийных компонентов, которые должны быть обеспечены единственному экземпляру декодера, для клиентов может быть полезен показатель относительно сегментов инициализации. Действительно, элемент Preselection определяет "основной" набор AdaptationSet как обеспечивающий декодеру конкретную информацию. Это означает, что основной набор AdaptationSet содержит сегмент инициализации (в терминологии стандарта DASH). На предшествующем уровне техники не ясно, использует ли частичный набор (наборы) AdaptationSet этот сегмент инициализации или может иметь свой собственный сегмент инициализации. Эта информация полезна для проигрывателей мультимедиа, чтобы корректно настроить свои декодеры. Например, если элемент Preselection объявляет набор видеодорожек с дорожками вырезок 'hvt1' с базовой дорожкой вырезок как основным набором AdaptationSet, объявлен только один сегмент инициализации (сегмент инициализации базовой дорожки вырезок). Наоборот, при рассмотрении элемента Preselection для трехмерной (3D) аудиоинформации с многопоточной аудиоинформацией может иметься несколько сегментов инициализации, например, один для каждого потока. Они могут обрабатываться, например, модулями пространственной обработки аудиоинформации, которые обеспечивают каждый аудиопоток одному или более аудиодекодерам. Для обработки вырезок и единственного экземпляра видео синтаксический анализатор ISOBMFF и видеодекодер отвечают за соответствующее формирование согласующегося битового видеопотока (например, согласующегося с одним или более профилями, иерархическими уровнями, уровнями HEVC) и декодирование этого битового потока.

Также может иметь место случай для дорожек вырезок с использованием дорожек 'hvc1' (вместо 'hvt1'), когда каждая вырезка соответствует независимому битовому потоку HEVC. В варианте осуществления изобретения предложено в конкретном оповещении позволить клиенту быстро идентифицировать (при синтаксическом анализе манифеста) в зависимости от конкретной для декодера информации, существуют ли ограничения в комбинациях мультимедийных компонентов, перечисленных в элементе выборки компонентов контента (например, в элементе Preselection или дескрипторе). Это оповещение может представлять собой новый атрибут, например, принимающий булево значение и называющий "singleInit". Этот атрибут может присутствовать в элементе Preselection или в дескрипторе Preselection как показано ниже.

Две приведенные ниже строки иллюстрируют элемент Preselection с дополнительным параметром, представляющим информацию о количестве сегментов инициализации, присутствующих в Preselection:

<Preselection id="P1" singleInit="true" preselectionComponents="(list of components)"...>... </Preselection>

<Preselection id="P2" singleInit="false" preselectionComponents="(list of components)"...>... </Preselection>

Приведенные ниже иллюстративные строки иллюстрируют дескриптор Preselection (в данном случае как SupplementalProperty) с дополнительным параметром, представляющим информацию о количестве сегментов инициализации, присутствующих в Preselection:

<SupplementalProperty schemeIdUri=" urn:mpeg:dash:preselection:2016" singleInit="true" value=" (list of components)".../>

<SupplementalProperty schemeIdUri=" urn:mpeg:dash:preselection:2016" singleInit="false" value=" (list of components)".../>

Следует отметить, что в определении дескриптора Preselection в стандарте DASH, 3-й выпуск (w16221, июнь 2016), значение Дескриптора обеспечивает два поля, разделенные запятой: тег предвыборки Preselection и id содержащихся компонентов контента этого списка Preselection как разделенный пробелами список в порядке обработки. Первый id определяет основной мультимедийный компонент. Предыдущий пример также работает с такой семантикой для атрибута значения. Следует отметить, что этот дополнительный параметр "singleInit" применяется к Preselection безотносительно ее декларации: SupplementalProperty, EssentialProperty или конкретный элемент, наследующий от DescriptorType, определенные в схеме MPD.

Когда этот новый атрибут установлен как "true" ("истина"), он указывает, что могут быть объединены только мультимедийные компоненты предвыборки Preselection, совместно использующие один и тот же сегмент инициализации. Это вводит ограничения в комбинациях мультимедийных компонентов, объявленных в Preselection. Тогда клиент знает, что в одном запросе он может получить всю информацию целиком для настройки своего декодера (декодеров). Когда этот новый атрибут установлен как "false" ("ложь"), он указывает, что может иметься один или более сегментов инициализации, но возможная комбинация мультимедийных компонентов, объявленных в Preselection, задана параметром "selectionType". Если значение не присутствует, значением по умолчанию, применяемое к предвыборке, является "false". Это сохраняет обратную совместимость с клиентами, не интерпретирующими этот новый параметр.

Например, при использовании для видео вырезок в разных разрешениях, таких как пример в таблицах 1a и 1b, может иметься один сегмент инициализации на каждое разрешение. Затем только вырезки с одинаковым разрешением могут быть объединены для обеспечения плавного переключения. Это означает, что переключение на другое разрешение может потребовать повторной инициализации декодера (декодеров) с помощью сегмента инициализации, соответствующего другому разрешению. Следует отметить, что поскольку стандарта MPD стандарта DASH полагается на XML-схему, любой узел (например, элемент или атрибут) под элементом Preselection или дескриптором Preselection может использоваться, чтобы перенести эту единственную информацию инициализации. Кроме того, это может быть полезно в любом синтаксическом элементе MPD, описывающем несколько мультимедийных компонентов.

Таблица 1a иллюстрирует пример одной предвыборки Preselection (как элемента) с singleInit="true", собирающей две дорожки вырезок на двух разных уровнях разрешения.

Таблица 1b иллюстрирует пример того же самого набора из двух дорожек вырезок на двух разных уровнях разрешения, каждая в предвыборке Preselection (для удобочитаемости присутствуют не все синтаксические элементы).

Таблица 1a:

<MPD....>

<Period...>

<AdaptationSet id="10"...>

<Representation id="101" codecs='hvc2..." width="1920" height="1080"... >...</Representation>

<Representation id="102" codecs='hvc2..." width="960" height="540"... >...</Representation>

</AdaptationSet >

<AdaptationSet id="11" bitstreamSwitching="false"...>

<Representation id="111" dependencyId="101" codecs='hvt1..." width="1920" height="1080"... >...</Representation>

<Representation id="112" dependencyId="102" codecs='hvt1..." width="960" height="540"... >...</Representation>

</AdaptationSet >

<AdaptationSet id="12" bitstreamSwitching="false"...>

<Representation id="121" dependencyId="101" codecs='hvt1..." width="1920" height="1080"... >...</Representation>

<Representation id="122" dependencyId="102" codecs='hvt1..." width="960" height="540"... >...</Representation>

</AdaptationSet >

<Preselection id="P1" preselectionComponents="10 11 12" singleInit="true" />

</Period>

</MPD>

Пример MPD в таблице 1a описывает расширенный элемент Preselection с параметром "singleInit". Предвыборка, идентифицированная как "P1", объявляет три набора AdaptationSet (с id, равными 10, 11 и 12) как компоненты предвыборки. Каждый из этих наборов AdaptationSet содержит два представления Representation для дорожек HEVC с разными разрешениями. Первый набор AdaptationSet в примере описывает базовую дорожку вырезок HEVC, оба других набора описывают дорожки вырезок HEVC. Поскольку в данном случае имеется два подмножества для воссоздания: сцепление сегментов для представлений 101, 111 и 121, с одной стороны, и для представлений 102, 112 и 122, с другой стороны, параметр "singleInit"=true указывает, что в предвыборке Preselection разрешены не все комбинации. Только представление Representation, совместно использующее один и тот же сегмент инициализации, может быть комбинировано для совместной визуализации, даже если атрибут "selectionType" указывает значение "any". Параметр "singleInit" представляет собой предупреждение для проигрывателя, что комбинации представлений Representation в предвыборке Preselection должны быть тщательно выбраны, чтобы гарантировать плавное воспроизведение и бесперебойное переключение. Кроме того, автор MPD может указать, например, с помощью атрибута bitstreamSwitching на уровне набора AdaptationSet, что переключение не всегда может быть бесперебойным через представления Representation, т.е., переключение может потребовать повторной инициализации декодера.

Таблица 1b:

<MPD....>

<Period...>

<AdaptationSet id="10"...>

<Representation id="100" codecs='hvc2..." width="1920" height="1080"... >...</Representation>

</AdaptationSet >

<AdaptationSet id="20"...>

<Representation id="200" codecs='hvc2..." width="960" height="540"... >...</Representation>

</AdaptationSet >

<AdaptationSet id="11"...>

<Representation id="110" dependencyId="100" codecs='hvt1..." width="1920" height="1080"... >...</Representation>

</AdaptationSet>

<AdaptationSet id="21"...>

<Representation id="210" dependencyId="200" codecs='hvt1..." width="960" height="540"... >...</Representation>

</AdaptationSet >

<AdaptationSet id="12"...>

<Representation id="120" dependencyId="100" codecs='hvt1..." width="1920" height="1080"... >...</Representation>

</AdaptationSet >

<AdaptationSet id="22"...>

<Representation id="220" dependencyId="200" codecs='hvt1..." width="960" height="540"... >...</Representation>

</AdaptationSet >

<Preselection id="P1" preselectionComponents="10 11 12" singleInit="false" />

<Preselection id="P2" preselectionComponents="20 21 22" />

</Period>

</MPD>

Пример MPD в таблице 1b обеспечивает альтернативу для описания двух дорожек вырезок HEVC с разными уровнями разрешения. В этом примере каждый уровень разрешения доступен клиенту потоковой передачи как предвыборка Preselection. Предвыборка "P1" обеспечивает предвыборку для высокого разрешения (HD), в то время как предвыборка "P2" обеспечивает предвыборку со стандартным разрешением SD. Поскольку автор гарантирует бесперебойное переключение среди представлений в каждом из наборов адаптации 10, 11, 12 и 20, 21, 22, значение "singleInit" для элемента Preselection может быть установлено равным значению "false". Это позволяет любую комбинацию представлений Representation в предвыборке Preselection. Предвыборка "P2" не объявляет значение для "singleInit", подразумевая значение по умолчанию, которое равно "false". В итоге, когда параметр "singleInit" установлен равным значению "true", указывает, что могут быть комбинированы только представления, совместно использующие один и тот же сегмент инициализации, безотносительно варианта использования: несколько разрешений в видеопотоках, или разные качества, но не бесперебойно переключаемые.

Таблица 2a обеспечивает пример дорожек вырезок HEVC, описанных в MPD стандарта DASH. Более точно, она предоставляет пример дорожек вырезок с дескриптором эквивалентности качества, раскрытым в дескрипторе Preselection.

Таблица 2a:

<MPD....>

<Period...>

<AdaptationSet id="1"...>

<Representation id ="1.1" codecs="hev2..." bandwidth="312"...>

// Сегменты URL for дорожки на основе вырезок...

</Representation>

</AdaptationSet>

<AdaptationSet id="2"...>

<Representation codecs="hvt1..." dependencyId="1.1" qualityRanking="1"...>

...

</Representation>

<Representation codecs="hvt1..." dependencyId="1.1" qualityRanking="2"...>

</AdaptationSet>

// другие AdaptationSet для 3 других дорожек вырезок

<AdaptationSet id="3"...>... </AdaptationSet >

<AdaptationSet id="4"...>... </AdaptationSet >

<AdaptationSet id="5"...>... </AdaptationSet>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:preselection:2016 " id="P1" value="1, 2, 3, 4, 5" singleInit="true"/>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="P:P1">

</Period>

</MPD>

В этом примере манифест описывает один набор AdaptationSet для базовой дорожки вырезок (с id="1", обеспечивающим в его дочернем представлении (представлениях) Representation одну или более альтернативных закодированных версий, каждая в дорожке 'hev2'). Манифест также описывает один набор AdaptationSet на дорожку вырезок (4 вырезки), дорожки 'hvt1'. В приведенном выше примере (таблица 2a) описание предвыборки Preselection определяет идентификатор предвыборки в атрибуте "id" и список мультимедийных компонентов, которые составляют предвыборку, в атрибуте "value" как разделенный пробелами список идентификаторов (список идентификаторов наборов AdaptationSet в примере таблицы 2a).

Основной набор AdaptationSet представляет собой набор, описывающий базовую дорожку вырезок (с @id="1"). Частичные наборы AdaptationSet (id от 2 до 5 в примере) соответствуют наборам AdaptationSet для каждой дорожки вырезок 'hvt1'. Следует отметить, что каждое представление Representation для дорожки вырезок 'hvt1' содержит атрибут "dependencyId" для представления Representation, соответствующего его базовой дорожке вырезок. Кроме того, каждое представление Representation каждой дорожки вырезок имеет атрибут "qualityRanking". Это дает два факультативных варианта для описания дорожек вырезок hvt1. В первом факультативном варианте базовая дорожка вырезок (не в таблице 2a) не объявлена в списке компонентов предвыборки. Тогда предвыборка Preselection объявляет только дорожки вырезок (hvt1). Базовая дорожка вырезок автоматически выбирается для загрузки и отображения из-за зависимостей от каждой дорожки вырезок (каждая дорожка вырезок имеет ссылку дорожки 'tbas' на базовую дорожку вырезок). Значением для атрибута "selectionType" предвыборки Preselection тогда является "any". Второй факультативный вариант (в таблице 2a) состоит в том, чтобы включить базовую дорожку вырезок в список компонентов предвыборки. Набор AdaptationSet, соответствующий базовой дорожке вырезок, тогда перечислен первым в списке компонентов предвыборки. Каждое представление Representation, соответствующее дорожке вырезок, по-прежнему объявляет зависимость для соответствующего представления для базовой дорожки вырезок (вследствие типа ссылки дорожки 'tbas'). Значение для атрибута "selectionType" предвыборки Preselection тогда установлено равным значению "main".

В примере таблицы 2a факультативно дескриптор Preselection также содержит атрибут "singleIni"», в этом случае установленный равным "true", чтобы указать, что проигрыватель DASH должен только скомбинировать представления Representation компонентов контента (один, много или все, в зависимости от значения параметра "selectionType"), совместно использующих один и тот же сегмент инициализации, который предназначен для базовой дорожки вырезок. Следует отметить, что механизм зависимости стандарта DASH, основанный на атрибуте "dependencyId" представления Representation позволяет идентифицировать и сцепить сегмент инициализации и мультимедийный сегмент, чтобы получить последовательность сегментов или подсегментов, соответствующую формату данных, определенному в @mimeType выбранных представлений Representation. Эквивалентность качества также присутствует в MPD, который ссылается в данном случае на предвыборку Preselection с идентификатором "P1". Следует отметить, что любой атрибут ("tag"....) или значение (первый параметр в атрибуте "value", например), позволяющий идентификацию предвыборки Preselection, может использоваться для ссылки на предвыборку Preselection. Эквивалентность качества указывает, что применяется эквивалентность качества между представлениями Representation мультимедийных компонентов, перечисленных в предвыборке Preselection. Например, из одного набора AdaptationSet в другой могут быть идентифицированы эквивалентные представления Representation с точки зрения качества. Эквивалентность качества в данном случае не обеспечивает рекомендацию максимальной разности качества среди этих представлений Representation. Как показано в приведенных выше примерах, эквивалентность качества может относиться к элементу Preselection. Таким образом, она может быть определена как дочерний элемент элемента Preselection, тогда параметр для выборки компонентов контента больше не является необходимым. Таким образом, он считается факультативным параметром в дескрипторе эквивалентности качества. Приведенные выше примеры используют наборы AdaptationSet, описывающие базовые дорожки вырезок и дорожки вырезок, но аналогичным образом применяются к любым мультимедийным дорожкам (например, аудио или видео).

Например:

Таблица 2b:

<Preselection id="P1" preselectionComponents="(list of media components).... >

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" >

</Preselection>

В иллюстративной таблице 2b простое присутствие дескриптора указывает, что для всех компонентов Preselection (родительский элемент дескриптора эквивалентности качества) применяется эквивалентность качества. В данном случае со значениями по умолчанию для всех параметров эквивалентности качества это неявно означает, что все компоненты контента родительского элемента Preselection имеют qualityRanking, который может быть сравнен по наборам AdaptationSet. Кроме того, рекомендуемая разность качества составляет 0, что соответствует значению по умолчанию.

Таблица 2c:

<Preselection id="P1" preselectionComponents="(list of media components).... >

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="2">

</Preselection>

В иллюстративной таблице 2c присутствие дескриптора эквивалентности качества указывает, что для всех компонентов родительского элемента Preselection эквивалентность качества применяется с максимальной разностью качества, равной 2. Список рассматриваемых компонентов является неявным, поскольку дескриптор объявлен как дочерний элемент элемента Preselection: тогда это относится ко всем компонентам контента предвыборки Preselection.

Таблица 2d:

<Preselection id="P1" preselectionComponents="11, 12, 13, 14"... >

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="AS:13,14 2">

</Preselection>

В приведенном выше примере (таблица 2d) присутствие дескриптора эквивалентности качества указывает, что для подмножества компонентов (наборов AdaptationSets с "id", равным 13 и 14) предвыборки Preselection эквивалентность качества применяется с максимальной разностью качества, равной 2.

Таблица 2e:

<Preselection id="P1" preselectionComponents="11, 12, 13, 14"... >

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="AS:13,14">

</Preselection>

В приведенном выше примере (таблица 2e) присутствие дескриптора эквивалентности качества указывает, что для подмножества компонентов (наборов AdaptationSets с "id", равным 13 и 14) предвыборки Preselection эквивалентность качества применяется с максимальной разностью качества, равной 0 (что является значением по умолчанию).

Таблица 2f:

<Preselection id="P1" preselectionComponents="11, 12, 13, 14"... >

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="*">

</Preselection>

В приведенном выше примере (таблица 2f) присутствие дескриптора эквивалентности качества указывает, что для всех компонентов предвыборки Preselection эквивалентность качества применяется с максимальной разностью качества по умолчанию, равной 0 (что является значением по умолчанию).

Таблица 2g:

<Preselection id="P1" preselectionComponents="11, 12, 13, 14"... >

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="* 1">

</Preselection>

В приведенном выше примере (таблица 2g) присутствие дескриптора эквивалентности качества указывает, что для всех компонентов предвыборки Preselection эквивалентность качества применяется с максимальной разностью качества по умолчанию, равной 1. Следует обратить внимание на то, что приведенная выше декларация для дескриптора эквивалентности качества эквивалентна следующей:

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="1">

Поскольку элемент Preselection и дескриптор расширяемы с точки зрения схемы, то же самое использование эквивалентности качества относится к элементу Preselection или дескриптору, расширенным с помощью новых элементов или атрибутов.

Дескриптор эквивалентности качества аналогичным образом применяется к дескриптору Preselection.

Таблица 3a:

<MPD...>...

<Period...>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:preselection:2016" value="P1 1 2 3">

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="P:P1">

<AdaptationSet id="1"... >... </AdaptationSet>

<AdaptationSet id="2"... >... </AdaptationSet>

<AdaptationSet id="3"... >... </AdaptationSet>

...

</Period>...

</MPD>

Пример в таблице 3a указывает, что дескриптор эквивалентности качества относится ко всем компонентам контента, объявленным в дескрипторе Preselection, идентифицированном как "P1", с максимальной разностью качества, равной 0 (значение по умолчанию).

Таблица 3b:

<MPD...>...

<Period...>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:preselection:2016" value="P1 1 2 3">

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="AS:1 2">

<AdaptationSet id="1"... >... </AdaptationSet>

<AdaptationSet id="2"... >... </AdaptationSet>

<AdaptationSet id="3"... >... </AdaptationSet>

...

</Period>...

</MPD>

Пример в таблице 3b указывает, что дескриптор эквивалентности качества относится к подмножеству компонентов контента, объявленных в дескрипторе Preselection, идентифицированном как "P1", с максимальной разностью качества, равной 0 (значение по умолчанию).

Таблица 3c:

<MPD...>...

<Period...>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:preselection:2016" value="P1 1 2 3">

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="P:P1 2">

<AdaptationSet id="1"... >... </AdaptationSet>

<AdaptationSet id="2"... >... </AdaptationSet>

<AdaptationSet id="3"... >... </AdaptationSet>

...

</Period>...

</MPD>

Пример в таблице 3c указывает, что дескриптор эквивалентности качества относится ко всем компонентам контента, объявленным в дескрипторе Preselection, идентифицированном как "P1", с максимальной разностью качества, равной 2.

Таблица 3d:

<MPD...>...

<Period...>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:preselection:2016" value="P1 1 2 3">

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="AS:1,2 1 ">

<AdaptationSet id="1"... >... </AdaptationSet>

<AdaptationSet id="2"... >... </AdaptationSet>

<AdaptationSet id="3"... >... </AdaptationSet>

...

</Period>...

</MPD>

Пример в таблице 3d указывает, что дескриптор эквивалентности качества относится к подмножеству компонентов контента, объявленных в дескрипторе Preselection, идентифицированном как "P1" (в данном случае наборы AdaptationSet с id, равным 1 и 2) с максимальной разностью качества, равной 1.

Таблица 3e:

<MPD...>...

<Period...>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:preselection:2016" value="P1 1 2">

<SupplementalProperty schemeIdUri="urn:mpeg:dash:preselection:2016" value="P2 1 3">

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="P: P1,P2">

<AdaptationSet id="1"... >... </AdaptationSet>

<AdaptationSet id="2"... >... </AdaptationSet>

<AdaptationSet id="3"... >... </AdaptationSet>

...

</Period>...

</MPD>

Пример в таблице 3e указывает, что дескриптор эквивалентности качества относится ко всем компонентам контента обоих дескрипторов Preselection, идентифицированных как "P1" и "P2". Максимальная разность качества равна 0 (значение по умолчанию).

Таблица 3f:

<MPD...>...

<Period...>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:preselection:2016" value="P1 1 3">

<SupplementalProperty schemeIdUri="urn:mpeg:dash:preselection:2016" value="P2 2 4">

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="P: P1">

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="P: P2 1">

<AdaptationSet id="1"... >... </AdaptationSet>

<AdaptationSet id="2"... >... </AdaptationSet>

<AdaptationSet id="3"... >... </AdaptationSet>

<AdaptationSet id="4"... >... </AdaptationSet>

...

</Period>...

</MPD>

Пример таблицы 3f указывает, что первый дескриптор эквивалентности качества относится к дескриптору Preselection, идентифицированному как "P1", с максимальной разностью качества, равной 0.

Второй дескриптор эквивалентности качества относится к дескриптору Preselection, идентифицированному как "P2", с максимальной разностью качества, равной 1.

Когда в MPD не объявлен никакой элемент Preselection, дескриптор эквивалентности качества, когда он присутствует, может непосредственно ссылаться на некоторые наборы AdaptationSet через его первый параметр. Второй параметр может указывать максимальную разность качества или по умолчанию указывать значение максимальной разности качества, равное 0. Приведенные ниже таблицы обеспечивают некоторый пример использования.

Таблица 4a:

<MPD...>...

<Period...>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" >

<AdaptationSet id="1"... >... </AdaptationSet>

<AdaptationSet id="2"... >... </AdaptationSet>

<AdaptationSet id="3"... >... </AdaptationSet>

<AdaptationSet id="4"... >... </AdaptationSet>

</Period>...

</MPD>

Пример в таблице 4a указывает, что дескриптор эквивалентности качества относится ко всем компонентам контента (в данном случае к наборам AdaptationSet с id от 1 до 4), определенным для заданного периода Period, со значением максимальной разности качества, равным 0.

Таблица 4b:

<MPD...>...

<Period...>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="3">

<AdaptationSet id="1"... >... </AdaptationSet>

<AdaptationSet id="2"... >... </AdaptationSet>

<AdaptationSet id="3"... >... </AdaptationSet>

<AdaptationSet id="4"... >... </AdaptationSet>

</Period>...

</MPD>

Пример в таблице 4b указывает, что дескриптор эквивалентности качества относится ко всем компонентам контента (в данном случае к наборам AdaptationSet с id с 1 по 4), определенным для заданного периода Period, со значением максимальной разности качества, равным 3. Хотя максимальная разность качества является явной, список компонентов контента, затрагиваемых эквивалентностью качества, является неявным. Приведенная выше нотация эквивалентна следующей:

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="* 3">

Таблица 4c:

<MPD...>...

<Period...>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="AS: 1,2">

<AdaptationSet id="1"... >... </AdaptationSet>

<AdaptationSet id="2"... >... </AdaptationSet>

<AdaptationSet id="3"... >... </AdaptationSet>

<AdaptationSet id="4"... >... </AdaptationSet>

</Period>...

</MPD>

Пример в таблице 4c указывает, что дескриптор эквивалентности качества относится к подмножеству компонентов контента (в данном случае к наборам AdaptationSet с id 1 и 2), определенному для заданного периода Period, со значением максимальной разности качества, равным 0 (значение по умолчанию). Хотя максимальная разность качества является неявной, список компонентов контента, затрагиваемых эквивалентностью качества, является явным.

Таблица 4d:

<MPD...>...

<Period...>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="AS: 1,2 1">

<AdaptationSet id="1"... >... </AdaptationSet>

<AdaptationSet id="2"... >... </AdaptationSet>

<AdaptationSet id="3"... >... </AdaptationSet>

<AdaptationSet id="4"... >... </AdaptationSet>

</Period>...

</MPD>

Пример в таблице 4d указывает, что дескриптор эквивалентности качества относится к подмножеству компонентов контента (в данном случае к наборам AdaptationSet с id 1 и 2), определенному для заданного периода Period, со значением максимальной разности качества, равным 1 (явное значение).

Таблица 4e:

<MPD...>...

<Period...>

<SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="AS: 1,2 1">

SupplementalProperty schemeIdUri="urn:mpeg:dash:quality-equivalence" value="AS: 3,4 2">

<AdaptationSet id="1"... >... </AdaptationSet>

<AdaptationSet id="2"... >... </AdaptationSet>

<AdaptationSet id="3"... >... </AdaptationSet>

<AdaptationSet id="4"... >... </AdaptationSet>

</Period>...

</MPD>

Пример в таблице 4e указывает, что каждый из двух дескрипторов эквивалентности качества применяется к подмножеству наборов AdaptationSet, определенному в элементе Period. Первый дескриптор рекомендует значение максимальной разности качества, равное 1, в то время как второй дескриптор рекомендует значение максимальной разности качества, равное 2.

Когда выше определен элемент Period, дескриптор эквивалентности качества аналогичным образом относится к компонентам контента (к элементу Preselection, или к дескриптору Preselection, или к элементу AdaptationSet, или к элементу ContentComponent), определенным в каждом периоде Period дескриптора MPD.

Следует отметить, что когда дескриптор эквивалентности качества ссылается на элемент Preselection или дескриптор, который объявляет параметр "singleInit" равным "true", возможная комбинация представлений Representation ограничена посредством ограничений сначала на сегмент инициализации, затем на qualityRanking.

Когда эквивалентность качества объявлена на уровне периода Period, и когда этот дескриптор эквивалентности качества не указывает компоненты контента, тогда эквивалентность качества относится ко всем мультимедийным компонентам, объявленным в родительском элементе дескриптора эквивалентности качества. Это означает, что когда несколько элементов выборки компонентов контента, например, элемент Preselection или дескриптор присутствуют в этом родительском элементе, эквивалентность качества относится ко всем мультимедийным компонентам всех предвыборок Preselection. Это не означает, что разрешены любые комбинации, это обозначается компонентами каждой предвыборки Preselection и, наконец, с помощью параметра "singleInit". В случае, если эквивалентность качества относится только к одной предвыборке Preselection в списке предвыборок, объявленных на данном уровне в манифесте потоковой передачи, дескриптор эквивалентности качества должен указать в параметре выборки компонентов контента список мультимедийного компонента, затрагиваемых эквивалентностью качества.

Фиг. 6, содержащая фиг. 6a-6d, иллюстрирует примеры манифестов в соответствии с вариантами осуществления "создателя контента" с использованием дескриптора правила качества и с использованием дескриптора эквивалентности качества.

Фиг. 6a направлена на потоковую передачу на основе вырезок. Рассматривая в качестве входной информации видеоконфигурацию, проиллюстрированную на фиг. 1, фиг. 6a обеспечивает пример одного манифеста 600 потоковой передачи с описанием одной вырезки, обозначенным 601 (среди девяти вырезок для краткости и ясности другие 8 вырезок будут описаны аналогичным образом). Этот манифест потоковой передачи объявляет элемент 602 выборки компонентов контента на основе использования конкретного элемента AdaptationSet (атрибут "virtual" и атрибут "purpose"). Дескриптор SRD 603 указывает, что этот виртуальный набор AdaptationSet 602 состоит из сборки 9 вырезок в полученной в результате видео размером 3×3 вырезок.

Второй дескриптор 604 является дескриптором "требований декодера", указывающим в данном случае, что композиция потребует нескольких декодеров, вероятно по одному на каждую вырезку. В альтернативном варианте осуществления значение "multiple" ожидает значение "number", которое указывает количество требуемых одновременно экземпляров декодеров, например, value="multiple=9".

Первое представление Representation 605 объявлено в манифесте для явного описания эквивалентности качества для всех представлений Representation, включенных в композицию, описанную в 602. Эта эквивалентность качества задана в данном случае, например, в атрибуте associationId как список всех представлений Representation в рассматриваемом наборе AdaptationSets посредством композиции 602. Этот список содержит все представления Representation с одинаковым уровнем качества (в данном случае соответствует уровню высшего качества "HQ" на фиг. 1). Представление Representation вырезки, упомянутое в атрибуте dependencyId (5.1 в примере), является вырезкой, которую создатель контента описывает как основной компонент комбинации 602. Это компонент, который должен быть воспроизведен клиентским устройством, не поддерживающим описание предвыборки или комбинации, или не способным декодировать девять вырезок за раз.

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

Например, представление Representation 606 (с id="«C.2") указывает клиентскому устройству альтернативную версию композиции с более низким общим качеством для полученной в результате составной видео. Эта альтернатива по-прежнему рассматривает центральную вырезку на высшем качестве (Representation "5.1" в атрибуте dependencyId), но ухудшает качество для окружающих вырезок: все выбраны из Representation "MQ" в 606.

Последнее представление Representation 607 описывает другую альтернативу, если пропускная способность не разрешает использовать одно из предыдущих представления: это представление ухудшает качество для центральной вырезки с "HQ" до "MQ" (представление Representation "5.2" в атрибуте dependencyId), а также для окружающих вырезок с конкретным шаблоном: вырезки в том же ряду сохраняются на среднем качестве (представления Representation 4.2 и 6.2 в атрибуте associationId), в то время как оставшиеся вырезки (верхний и нижний ряды) ухудшаются до наиболее низкого качества. Это явно указывает правило качества, выбранное создателем контента, и является альтернативой шаблону ухудшения качества, выраженному в дескрипторе правила качества, как разъяснено в предыдущем варианте осуществления.

Фиг. 6b является альтернативным вариантом осуществления, в котором элемент выборки компонентов контента использует расширение элемента Preselection. Он объявляет в требуемом, например, в требуемом атрибуте "preselectionComponents" список компонентов контента или наборы AdaptationSet, включенные в комбинацию или предвыборку. В этом примере это главным образом состоит в объявлении вырезки из фиг. 1 в каждом наборе AdaptationSet. Это может быть сделано посредством использования уникального идентификатора компонента контента или набора AdaptationSet, такого как атрибут "id", или атрибут "tag", или любой другой синтаксический элемент, зарезервированный для целей идентификации.

Этот элемент Preselection содержит дескриптор SRD 623, чтобы указать, что предвыборка Preselection приводит в результате к изображению, собирающему 9 вырезок в одну большую видео. Второй дескриптор, дескриптор 624 требований декодера, указывает, что составное видео, получающееся в результате из предвыборки Preselection, может быть декодировано и отображено единственным декодером, но сначала требует воссоздания битового потока (объект второго параметра в атрибуте значения дескриптора требований декодера). Это воссоздание битового потока означает, что сцепленные битовые потоки каждого компонента видеоконтента, включенного в предвыборку (т.е., для каждой вырезки), должны быть транскодированы в единственный битовый поток, в данном случае имеющий 9 вырезок. Другой дескриптор 625 указывает, что целевым назначением предвыборки является "композиция вырезок". Это полезный показатель для процесса воссоздания битового потока: клиент может интерпретировать, что он должен воссоздать битовый поток с типом, обозначенным значением атрибута кодека, объявленного в элементе выборки компонентов контента (в данном случае в элементе Preselection), и 'hvc2...', за которым следует профиль, иерархический уровень, информация уровня, в данном примере означает, что он должен фактически являться битовым потоком HEVC.

Затем, как в примере фиг. 6a, следует список альтернативных представлений Representation с явным атрибутом qualityRanking в данном случае, чтобы удостовериться, что клиент понимает порядок этих альтернатив (следует отметить, что также может использоваться атрибут selectionPriority). Атрибут пропускной способности, который указывает агрегированную пропускную способность для составной видео для каждого представления предвыборки или комбинации, также может использоваться клиентом для ее динамической адаптации.

В альтернативных вариантах осуществления дескриптор 625 целевого назначения может быть реализован как новый атрибут или элемент элемента Preselection. Аналогичным образом, дескриптор требований декодера может быть реализован как новый атрибут или элемент элемента Preselection. В обоих случаях фиг. 6a и 6b дескриптор "целевого назначения композиции" в качестве альтернативы может быть объявлен как элемент Label в элементе выборки компонентов контента.

Фиг. 6c иллюстрирует то же самое мультимедийное представление (т.е., 9 вырезок на фиг. 1 и их комбинации с фокусом на центральной вырезке) при использовании дескриптора 640 правила качества и дескриптора 641 эквивалентности качества, выраженных в начале элемента Period. Набор AdaptationSet 642 является описанием вырезки 1. Дескриптор MPD будет содержать один такой набор AdaptationSet на каждую вырезку (не представлены для краткости и ясности). В этом примере дескриптор выборки компонентов контента, в данном случае элемент Preselection 643, не содержит каких-либо представлений Representation для динамической адаптации. Вместо этого клиентское устройство полагается на набор представлений Representation по наборам AdaptationSet, перечисленным в атрибуте preselectionComponents, которые имеют эквивалентный уровень качества. Затем после дескриптора 640 правила качества клиентское устройство при необходимости вычисляет санкционированное ухудшение качества. В этом примере дескриптор 640 правила качества указывает, что никакие представления Representation, собранные в предвыборке, не должны иметь разность ранжирования качества больше, чем 2, и тем самым сокращается количество возможных комбинаций для выбора клиента. Следует отметить, что эквивалентность качества в примере, проиллюстрированном на фиг. 6c, обеспечивает в его атрибуте значения список наборов AdaptationSet, включенных в предвыборку. Здесь он основан на значении их атрибута "id". Чтобы снять неоднозначность, какой параметр компонента мультимедийного контента используется для указания эквивалентности качества, значение, вставленное в атрибут schemeIdUri, может быть определено как действительно явное, например:

"urn:mpeg:dash:quality-equivalence-id", чтобы указать, что используется атрибут "id", или

"urn:mpeg:dash:quality-equivalence-tag", чтобы указать, что атрибут "tag" используется для перечисления компонентов мультимедийного контента, включенных в предвыборку комбинации. В более общем случае, "urn:mpeg:dash:quality-equivalence-xxx", чтобы указать, что синтаксический элемент "xxx" используется, чтобы идентифицировать компоненты мультимедийного контента, которые являются частями предвыборки или комбинации.

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

schemeIdUri="urn:mpeg:dash:quality-equivalence" и value="id, 1, 2" или

schemeIdUri="urn:mpeg:dash:quality-equivalence" и value="tag, AS1, AS2" соответственно укажут, что наборы AdaptationSet с id="1" и id="2" включены в предвыборку или комбинацию, и наборы AdaptationSet с tag="AS1" и tag="AS2" включены в предвыборку или комбинацию. В более общем случае:

schemeIdUri="urn:mpeg:dash:quality-equivalence" и value="foo, foo1, foo2" укажут, что компоненты мультимедийного контента с элементом "foo" или атрибутом, имеющим значение "foo1" и "foo2", являются частью предвыборки или комбинации.

Фиг. 6d иллюстрирует пример в соответствии с которым дескриптор эквивалентности качества помещен как новый атрибут элемента Representation каждого набора AdaptationSet (ссылка 661). Факультативно элемент 663 выборки компонентов контента может содержать синтаксический элемент, перечисляющий некоторые предопределенные уровни качества для предвыборки или комбинации.

В соответствии с примером, проиллюстрированный на фиг. 6d, элемент 663 Preselection содержит новый атрибут "levels" ("уровни") (название в данном случае является просто примером), который зарезервирован для описания списка возможных уровней качества. Эта информация может быть помещена как дочерний элемент элемента выборки компонентов контента, например, как элемент descriptorType стандарта DASH, обычно элемент SupplementalProperty с его собственным конкретным значением schemeIdUri. Это полезно для клиента, чтобы знать, что возможна некоторая адаптация перед выбором композиции, или комбинации, или предвыборки компонентов мультимедийного контента. Поскольку, если динамическая адаптация не возможна, это может привести к низкому качеству восприятия для пользователя, и клиент потоковой передачи может использовать эту информацию, чтобы предупредить клиента.

Альтернативный вариант осуществления для ассоциирования уровней качества с элементом выборки компонентов контента может состоять в том, чтобы определить в качестве первого значения атрибута preselect представлений Representation 661 значение рассматриваемой комбинации или предвыборки, например, "P1" в примере на фиг. 6d. Атрибут Preselect был бы написан как: preselect="P1, HQ" или preselect="P1, MQ", и т.д. В случае, если элементом выборки компонентов контента является набор AdaptationSet или расширенный набор AdaptationSet, как описано в предыдущем варианте осуществления, также может использоваться значение атрибута "id".

В случае потоковой передачи на основе вырезок, когда входным видео является один битовый поток HEVC с видео с вырезками, инкапсулированный (например, во время этапа 509 инкапсуляции на фиг. 5) в базовую дорожку вырезок, плюс 9 дорожек вырезок (для каждого уровня качества). Затем некоторые предложения, внесенные в стандарте MPEG DASH, по описанию базовой дорожки вырезок в стандарте DASH могут быть повторно использованы.

В конкретном случае вырезок и видеопотоков может использоваться один или более наборов AdaptationSet, соответствующих описанию базовой дорожки вырезок, как определено в ISO/IEC 14496-15, 4-й выпуск. Это также требует некоторого показателя относительно эквивалентности качества между представлениями Representation, которые зависят от этой базовой дорожки вырезок набора AdaptationSet, как дескриптора компонента контента, поскольку это дает возможность воссоздания всех, одной или набора вырезок. Конкретная часть набора AdaptationSet в данном случае является тем фактом, что она совместно использует среди всех дорожек вырезок, включенных в предвыборку или комбинацию, базовую дорожку вырезок, содержащую информацию о настройке декодера. Дескриптор целевого назначения указывает вырезку HEVC, и дескриптор требований декодера указывает, что только единственный экземпляр видеодекодера может обработать полученную в результате составную видео.

Когда вырезки используются для видео виртуальной реальности (VR) или с охватом 360°, чтобы содержать данные для заданной области, например, части сферической сцены, проецируемой на грани куба, изобретение также применяет для обработки качества, например, между видом спереди и другими ракурсами. В более общем случае это относится к контенту виртуальной реальности, когда спроецированные части записанной 3D-сцены проецируются на 2D-поверхность, содержащуюся в одной или более вырезках. С приведенными выше вариантами осуществления клиент потоковой передачи знает, что существует шаблон ухудшения качества, указанный создателем контента. Он принимает его во внимание при запросе мультимедиа. Это должно быть полезно для согласованного восприятия среди клиентов потоковой передачи. Другой вариант осуществления может состоять в разрешении клиентам реализовать свои собственные решения для адаптации качества, как разъяснено далее.

Клиентская логическая схема адаптации

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

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

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

,

где

- набор вырезок, принадлежащих области ROI;

- набор вырезок, не принадлежащих области ROI;

- набор соседних вырезок: он содержит набор пар вырезок, каждая пара содержит две соседних вырезки;

обеспечивает значение качества для данной вырезки , это качество зависит от выбранного представления для этой вырезки; и

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

Таким образом, входными данными этого алгоритма оптимизации будут:

- максимальная доступная пропускная способность,

- возможная пропускная способность/доступные скорости передачи каждого возможного представления Representation каждой выбранной вырезки и ассоциированных качеств, и

- вырезки, покрывающие область ROI, для которой пользователь хотел бы иметь более хорошее качество,

- и геометрия вырезок для сохранности более близких вырезок.

Качества для заданной вырезки оцениваются, например, посредством упорядочения битовых скоростей представлений (или с использованием атрибута qualityRanking, если он присутствует) этой вырезки от наиболее высокой битовой скорости до наиболее низкой битовой скорости и подгонки их к кривой отношения скорость/искажение.

Для простоты качество может быть установлено равным 1/n для n-ой битовой скорости: наиболее высокая битовая скорость тогда будет иметь качество, равное 1. В качестве альтернативы качество n-ой битовой скорости может быть установленным равным , где - n-ая битовая скорость, и - наиболее высокая битовая скорость для представления этой вырезки.

Этот вид задачи может быть рассмотрен как комбинаторная задача оптимизации.

Она может быть решена, или может быть найдено субоптимальное решение, с использованием классических алгоритмов оптимизации. Например, может использоваться динамическое программирование или методика экспертных систем. Также может использоваться эвристика, чтобы упростить процесс оптимизации. В качестве примера такого возможного алгоритма оптимизации нулевой весовой коэффициент задается каждой вырезке области ROI, и каждой другой вырезке задается весовой коэффициент, который является ее минимальным манхэттенским расстоянием до вырезки области ROI. Оптимизация начинается посредством ассоциирования никакого качества со всеми вырезками (т.е., вырезки не будут передаваться). Затем, пока не превышена максимальная пропускная способность, итеративным образом подразумевается наиболее низкое качество для вырезок с нулевым весовым коэффициентом, затем с весовым коэффициентом 1, вплоть до наиболее высокого весового коэффициента. Затем, пока не превышена максимальная пропускная способность, начиная с 'max_d=0', качество (если доступно более хорошее качество) вырезок с нулевым весовым коэффициентом до вырезок с весовым коэффициентом 'max_d' итеративно увеличивается. Затем увеличивается 'max_d'. Если не все вырезки имеют высшее качество, алгоритм продолжается. Эти значения используются, чтобы сначала сбросить качество самых дальних вырезок, затем к самым дальним и "самым дальним - 1" вырезкам. Этот алгоритм оптимизации позволяет получить максимальную разность качества "1" между соседними вырезками. Он может быть легко распространен для поддержки другой максимальной разности качества или других шаблонов изменений качества.

Этот вид алгоритма оптимизации может быть встроен в клиентское устройство как предопределенный алгоритм логической схемы адаптации. Другие алгоритмы логической схемы адаптации также могут быть встроены в клиентское устройство (например, модуль 309 на фиг. 3), каждый алгоритм следует своему предопределенному правилу адаптации качества. Затем в зависимости от пользовательского выбора для использования контента клиентское устройство может активировать наиболее релевантный алгоритм адаптации.

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

Другая альтернатива направлена на расширение классической логической схемы адаптации (например, логической схемы 308 адаптации на фиг. 3), работающей для наборов AdaptationSet в данный момент времени: клиент вычисляет возможную комбинацию с использованием информации из манифеста: например, дескрипторы SRD, элементы Preselection, и т.д. Затем он строит в памяти упорядоченный список возможных комбинаций с ассоциированной требуемой пропускной способностью (как суммой @bandwidth каждого представления Representation, включенного в комбинацию).

Затем, чтобы избежать слишком больших затрат времени на переключение, набор возможных комбинаций может быть сокращен до подмножества предопределенных комбинаций, например, до 5 альтернатив. Это может быть сделано посредством сохранения комбинаций со значительной разницей с точки зрения требуемой пропускной способности. Посредством этого клиент может продолжить использовать логическую схему адаптации для одного набора AdaptationSet посредством переключения на следующий набор представлений Representation, когда доступно большее количество пропускной способности (или буфер заполняется быстро), или при обратном переключении к более низкому набору представлений Representation, когда доступная пропускная способность уменьшается (или имеется риск истощения буфера). Основное различие состоит в том, что в этом случае переключение приводит к нескольким запросам (один на каждое представление Representation в наборе представлений с одинаковым типом мультимедиа, которые формируют комбинацию), тогда как в классическом варианте использования переключение приводит к одному запросу сегмента одного представления Representation данного типа мультимедиа. Эти логические схемы адаптации могут быть выполнены непосредственно без какого-либо требования дескриптора "правила качества". В этом случае весь выбор предоставляется клиенту. В качестве альтернативы клиент может использовать "правила качества" и/или дескрипторы "эквивалентности качества", чтобы выбрать наилучшую логическую схему адаптации для улучшения визуализации для пользователя.

Управление серверным устройством: принудительная доставка и перенаправление

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

Манифест может содержать описание комбинаций или предвыборок. В этом варианте осуществления пользователь через графический пользовательский интерфейс может выбрать режим просмотра, например, акцент на области ROI и более низкие версии окружающих вырезок. Если и сервер, и клиент поддерживают HTTP/2, клиент может указать серверу при запросе основного компонента комбинации или предвыборки, что он также интересуется другими компонентами.

Это может быть сделано посредством введения новой директивы принудительной доставки, например, с именем типа принудительной доставки, установленным как "urn:mpeg:dash:fdh:push-bundle". Это требует, чтобы сервер также поддерживал директивы принудительной доставки и знал о возможной комбинации или предвыборках. Правило качества также известно серверу, например, максимальная разность уровня качества между основным ресурсом и другими компонентами предвыборки. Это может быть сделано с помощью сервера стандарта DASH, способного анализировать манифест потоковой передачи, или сервера, сконфигурированного таким образом, чтобы он знал, какие ресурсы относятся к основным ресурсам предвыборки. В ответ на запрос GET основного ресурса предвыборки сервер может пообещать принудительную доставку соответствующего ресурса в предвыборке. На основе требуемого ресурса, зная дескриптор MPD, сервер может определить уровень качества, который требует клиент. В качестве альтернативы директива принудительной доставки может указать в качестве параметра директивы "push-bundle" уровень качества, который требуется для основного ресурса. Например, это может быть задано как информация о пропускной способности:

Accept-Push-Policy= "urn:mpeg:fdh:push-bundle"; "bw:1000000" означает, что основной ресурс запрашивается при 1 МБит/с, или как показатель относительно уровня качества:

Accept-Push-Policy= "urn:mpeg:fdh:push-bundle"; "qRank:HQ" в случае вырезок на фиг. 1 или в случае, если атрибут preselect используется для эквивалентности качества:

Accept-Push-Policy= "urn:mpeg:fdh:push-bundle"; "preselect:HQ". В варианте использования области ROI эта директива принудительной доставки может упростить запрос посредством клиента: он выдает запрос частей видео, соответствующих области ROI, в то время как сервер принудительно доставляет окружающие вырезки. Этот подход на основе директивы принудительной доставки упрощает задачу клиента: он должен знать только то, что существует предвыборка, чтобы сосредоточиться на требовании основного ресурса и ждать, пока сервер отправит дополнительные компоненты на уровне качества, однородном с качеством, выбранным для основного ресурса. Принимая и применяя директиву принудительной доставки, сервер отвечает с подтверждением (Ack) принудительной доставки:

Push-policy= "urn:mpeg:fdh:push-bundle"; без каких-либо параметров для подтверждения запроса и директивы, отправленных клиентом. Когда подтверждение push-bundle содержит параметр, он используется клиентом, чтобы идентифицировать уровень эквивалентности качества в предвыборке или комбинации компонентов мультимедийного контента. Это может быть такой параметр, как "preselect=HQ" или "qRank=MQ", в зависимости от того, какой дескриптор эквивалентности качества используется.

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

- с центральным процессором (ЦП; CPU) 701, таким как микропроцессор;

- с оперативным запоминающим устройством (ОЗУ; RAM) 702 для хранения исполняемого кода способа вариантов осуществления изобретения, а также с регистрами, выполненными с возможностью записывать переменные и параметры, необходимых для реализации способа для потоковой передачи данных, объем памяти может быть расширен посредством факультативного ОЗУ, например, соединенного с портом расширения;

- с постоянным запоминающим устройством (ПЗУ; ROM) 703 для хранения компьютерных программ для реализации вариантов осуществления изобретения;

- с сетевым интерфейсом 704, который в свою очередь обычно соединен с сетью связи, по которой передаются и принимаются цифровые данные для обработки. Сетевой интерфейс 704 может являться единственным сетевым интерфейсом или состоять из множества разных сетевых интерфейсов (например, проводных и беспроводных интерфейсов, или разных видов проводных или беспроводных интерфейсов). Данные записываются в сетевой интерфейс для передачи или считываются из сетевого интерфейса для приема под управлением прикладной программы, работающей в ЦП 701;

- с пользовательским интерфейсом (UI) 705 для приема ввода от пользователя или отображения информации пользователю;

- с жестким диском (HD) 706;

- с модулем 707 ввода/вывода для приема/отправки данных от внешних устройств/внешним устройствам, таким как источник видеосигнала или дисплей.

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

Центральный процессор 701 выполнен с возможностью управлять и направлять исполнение инструкций или частей программного кода программы или программ в соответствии с вариантами осуществления изобретения, эти инструкции сохранены в одном из упомянутых выше средств хранения. После включения центральный процессор 701 способен исполнять из ОЗУ 702 инструкции, соответствующие прикладной программе, после того как эти инструкции были загружены, например, из программного ПЗУ 703 или с жесткого диска (HD) 706. Такая прикладная программа при ее исполнении посредством ЦП 701 заставляет исполнять этапы блок-схем последовательности этапов, показанные на предыдущих чертежах.

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

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

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

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