ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Изобретение, в общем, относится к области инкапсуляции данных мультимедиа с временной привязкой, например, согласно базовому формату мультимедийного файла, как определен организацией по стандартизации MPEG, чтобы улучшать потоковую доставку, в частности, относящуюся к потоковой передаче HTTP (HyperText Transfer Protocol, протокола передачи гипертекстовых файлов) выбираемых пользователем интересующих областей в сжатых видеопотоках. Более конкретно, изобретение относится к способу, устройству, и компьютерной программе для инкапсуляции масштабируемых элементарных потоков, содержащих разделенные данные, такие как пространственные мозаичные элементы, что обеспечивает возможность эффективной потоковой передачи данных, в частности, одного или более мозаичных элементов.
УРОВЕНЬ ТЕХНИКИ
Кодирование видео является способом преобразования последовательности видеоизображений в компактный цифровой битовый поток, чтобы видеоизображения могли передаваться или храниться. Устройство кодирования используется, чтобы кодировать видеоизображения, при этом ассоциированное устройство декодирования имеет возможность восстановления битового потока для отображения и просмотра. Общая цель состоит в том, чтобы формировать битовый поток, чтобы он был меньшего размера, чем информация исходного видео. Это предпочтительно уменьшает пропускную способность, требуемую от сети передачи, или запоминающего устройства, чтобы передавать или сохранять код битового потока. Для передачи, битовый видеопоток, в общем, инкапсулируется согласно протоколу передачи, который обычно добавляет заголовки и контрольные биты.
Недавно, группа экспертов по движущимся изображениям (MPEG) опубликовала новый стандарт, чтобы унифицировать и заменить существующие решения потоковой передачи по HTTP (HyperText Transfer Protocol, протоколу передачи гипертекстовых файлов). Предполагается, что этот новый стандарт, называемый "динамическая адаптивная потоковая передача по HTTP (DASH)", будет поддерживать модель потоковой передачи мультимедиа по HTTP на основе стандартных веб-серверов, в которой логические возможности (то есть, выбор мультимедийных данных для потоковой передачи и динамическая адаптация битовых потоков для выборов пользователей, условий сети, и функциональных возможностей клиента) полагаются исключительно на выборы клиентов и устройства.
В этой модели, представление мультимедиа организовано в сегментах данных и в манифесте, называемом "описание представления мультимедиа (MPD)", который представляет организацию данных мультимедиа с временной привязкой, подлежащих представлению. В частности, манифест содержит идентификаторы ресурсов для использования для загрузки сегментов данных и обеспечивает контекст для выбора и комбинирования этих сегментов данных, чтобы получать действительное представление мультимедиа. Идентификаторы ресурсов обычно являются указателями HTTP-URL (Uniform Resource Locator, унифицированный указатель ресурса), возможно комбинированными с байтовыми диапазонами. На основе манифеста, клиентское устройство определяет в любое время то, какие сегменты мультимедиа должны загружаться из сервера мультимедийных данных, согласно его потребностям, его функциональным возможностям (например, поддерживаемым кодекам, размеру устройства отображения, частоте кадров, уровню качества, и т.д.), и в зависимости от условий сети (например, доступной полосы пропускания).
В дополнение, разрешение видео непрерывно возрастает, двигаясь от стандартной четкости (SD) к высокой четкости (HD), и к сверхвысокой четкости (например, 4K2K или 8K4K, то есть, можно сказать, видео, содержащему изображения 4,096×2,400 пикселей или 7,680×4,320 пикселей). Однако не все устройства приема и декодирования видео имеют ресурсы (например, полосу пропускания доступа к сети или CPU (Central Processing Unit, центральное обрабатывающее устройство)), чтобы осуществлять доступ к видео в полном разрешении, в частности, когда видео имеет сверхвысокую четкость, и не все пользователи нуждаются в доступе к такому видео. В таком контексте, является особенно предпочтительным обеспечивать возможность доступа только к некоторым областям интереса (ROI), то есть, можно сказать, чтобы осуществлять доступ только к некоторым пространственным подчастям полной видеопоследовательности.
Известный механизм для доступа к пространственным подчастям кадров, принадлежащих к видео, состоит в организации каждого кадра видео в виде компоновки независимо декодируемых пространственных областей, в общем, упоминаемых как мозаичные элементы. Некоторые форматы видео, такие как SVC (Scalable Video Coding, кодирование масштабируемого видео) или HEVC (High Efficiency Video Coding, высокоэффективное кодирование видео) обеспечивают поддержку для определения мозаичных элементов. Определяемая пользователем ROI может охватывать один или несколько смежных мозаичных элементов.
Соответственно, для потоковой передачи выбираемых пользователем областей ROI согласно протоколу HTTP, является важным обеспечивать инкапсуляцию данных мультимедиа с временной привязкой кодированного битового видеопотока таким способом, который обеспечивает возможность пространственного доступа к одному или более мозаичным элементам и который обеспечивает возможность комбинирования мозаичных элементов, к которым осуществляется доступ.
Следует напомнить, что кодированные битовые видеопотоки, в общем, конструируются как набор смежных временных выборок, которые соответствуют полным кадрам, при этом временные выборки организуются как функция порядка декодирования. Форматы файлов используются, чтобы инкапсулировать и описывать такие кодированные битовые потоки.
Для иллюстрации, базовый формат мультимедийного файла международной организации по стандартизации (ISO BMFF) является хорошо известным гибким и расширяемым форматом, который описывает кодированные битовые потоки данных мультимедиа с временной привязкой либо для локального хранения, либо для передачи посредством сети или посредством другого механизма доставки на основе битовых потоков. Этот формат файла является объектно-ориентированным. Он состоит из компоновочных блоков, называемых блоки, которые организованы последовательно или иерархически и которые определяют параметры кодированного битового потока данных мультимедиа с временной привязкой, такие как параметры временной привязки и структуры. Согласно этому формату файла, битовый поток данных мультимедиа с временной привязкой содержится в структуре данных, упоминаемой как блок mdat, который определен в другой структуре данных, упоминаемой как блок дорожки (track). Дорожка представляет временную последовательность выборок, где выборка соответствует всем данным, ассоциированным с одиночной временной меткой, то есть, можно сказать всем данным, ассоциированным с одиночным кадром, или всем данным, ассоциированным с несколькими кадрами, совместно использующими одну и ту же временную метку.
Для масштабируемого видео, такого как видео формата SVC, многоуровневая организация мультимедийных данных может эффективно представляться посредством использования множества зависимых дорожек, при этом каждая дорожка представляет видео на конкретном уровне масштабируемости. Чтобы избегать дублирования данных между дорожками, могут использоваться средства извлечения. Согласно стандартному формату файла, средство извлечения является структурой данных, непосредственно включаемой в битовый поток, которая обеспечивает возможность эффективного извлечения блоков уровня сетевой абстракции (NAL) из других битовых потоков. Поэтому, битовый поток, содержащий данные, которые уже включены в другой битовый поток, обрабатывается таким образом, чтобы заменять эти данные посредством средства извлечения, обеспечивающего возможность восстановления их из другого битового потока. Например, битовый поток дорожки уровня расширения может содержать средства извлечения, которые ссылаются на блоки NAL из дорожки базового уровня. Затем позже, когда такая дорожка уровня расширения извлекается из формата файла, средства извлечения должны заменяться на данные, на которые они ссылаются.
При использовании ISO BMFF могут использоваться несколько стратегий, встраивающих эти механизмы, чтобы описывать вложенную информацию и чтобы облегчать доступ к этой вложенной информации или чтобы эффективно организовывать битовые потоки в множество сегментов, в частности, для формата кодирования HEVC и его масштабируемого расширения.
Например, в статье, озаглавленной "Implications of the ISO Base Media File Format on Adaptive HTTP Streaming of H.264/SVC", авторы, Kofler и др., представляют три разных стратегии для организации масштабируемого битового видеопотока (H264/SVC) для потоковой передачи HTTP при рассмотрении возможностей также как ограничений формата ISO BMFF:
a) одиночный файл, содержащий конкретный заголовок файла, содержащий блок "ftyp" типа файла и блок "moov" фильма, содержащий все метаданные ISO BMFF (включающие в себя определения дорожек), при этом одиночный файл также содержит одиночный блок mdat, содержащий весь кодированный битовый поток. Эта организация является подходящей для локального хранения, но не приспособлена для потоковой передачи HTTP, где клиент может иметь необходимость только в части из всего битового потока;
b) одиночный файл, содержащий множество блоков moof/mdat, подходящих для фрагментации. Этот формат обеспечивает возможность последовательной загрузки. Блок moof является эквивалентным блоку moov на уровне фрагментов. Согласно этой схеме, с использованием фрагментированного мультимедийного файла, масштабируемый битовый поток разделяется на множество зависимых дорожек, представляющих видео на разных уровнях масштабируемости. Средства извлечения используются, чтобы ссылаться на блоки NAL из других дорожек. В случае, когда используется дорожка в расчете на мозаичный элемент, все адресуемые дорожки должны подготавливаться заранее и дорожки не могут выбираться независимо. Если должны отображаться несколько мозаичных элементов, должны декодироваться несколько битовых потоков и базовый уровень декодируется несколько раз;
c) множество файлов сегментов, при этом к каждому файлу может осуществляться доступ посредством его собственного URL и он может загружаться независимо. Каждый сегмент обычно состоит из блока типа сегмента (styp), который действует как тип заголовка файла, необязательного блока индекса сегмента (sidx) и одного или множества фрагментов. Снова, каждый фрагмент состоит из блока moof и mdat. Согласно этой схеме, с использованием фрагментированного мультимедийного файла, каждая дорожка сохраняется в своем собственном сегменте с ассоциированным битовым потоком, относящимся к одному уровню масштабируемости. Если необходимо, используются средства извлечения, чтобы ссылаться на требуемый битовый поток из зависимых дорожек. Такая схема кодирования является особенно подходящей для потоковой передачи дорожек независимым образом. Она является хорошо приспособленной для стандарта DASH, но она не является подходящей для потоковой передачи мозаичных элементов, так как должны декодироваться несколько битовых потоков и, таким образом, требуется один декодер в расчете на дорожку. Более того, имеется потенциальное дублирование битового потока базового уровня, когда выбирается более, чем один мозаичный элемент.
При применении к пространственным мозаичным элементам, никакая из этих стратегий не обеспечивает возможность эффективного доступа к специальным мозаичным элементам в контексте потоковой передачи HTTP. В самом деле, с существующим определением формата файла, все еще будет необходимо осуществлять доступ к множеству не непрерывных байтовых диапазонов в кодированном битовом потоке или это будет давать результатом дублирование битового потока, чтобы отображать пространственные мозаичные элементы нескольких кадров, соответствующих заданному временному интервалу.
Патент США 8,442,109 раскрывает способ для сигнализации информации масштабируемости ROI в формате файла, в частности, в формате сжатия видео типа SVC. Задача системы, раскрытой в этом документе, направлена на отображение блоков NAL в области интереса и в уровни масштабируемости, чтобы обеспечивать возможность извлечения данных ROI из мультимедийного файла. Этот документ раскрывает использование нового блока, указываемого как IroiInfoBox, для сигнализации геометрии области интереса. Раскрыты три разных решения, чтобы отображать блоки NAL в области интереса (то есть, чтобы ассоциировать блоки NAL с идентификаторами ROI):
- с использованием метаданных мозаичных элементов;
- с использованием выделенного блока, содержащего вложенный цикл по выборкам дорожки; и
- с использованием блоков NAL или специального описателя VisualSampleGroupEntry, исчерпывающе перечисляющего все блоки NAL с их назначенным идентификатором ROI.
В отношении отображения блоков NAL в уровни масштабируемости, используются блоки 'tier' (слово 'tier' ('ярус') используется, чтобы описывать уровень в черновом формате файла SVC). Посредством этого, геометрическая информация области ROI отделяется от идентификационной информации.
Однако обработка геометрической информации области ROI и идентификационной информации в одной и той же структуре, также как индексирование мозаичных элементов и областей ROI (вместо индексирования блоков NAL) является предпочтительным с точки зрения эффективности синтаксического разбора и с точки зрения извлечения областей интереса и мозаичных элементов.
Чтобы решать эти проблемы, обеспечивается эффективная схема организации данных и описания дорожек, подходящая для пространственных мозаичных элементов в масштабируемых видеопотоках, которая обеспечивает, что какая бы комбинация дорожек ни выбиралась клиентским приложением, результат синтаксического разбора формата ISO BMFF всегда ведет к действительному элементарному битовому видеопотоку для видеодекодера.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
С учетом этих ограничений, изобретатели обеспечивают способ и устройство для инкапсуляции мозаичных данных мультимедиа с временной привязкой в сервере и для обеспечения битового потока данных мультимедиа с временной привязкой из мозаичных данных мультимедиа с временной привязкой, инкапсулированных в множестве файлов сегментов мультимедиа.
Широкой задачей изобретения является исправление недостатков предшествующего уровня техники, как описано выше.
Согласно первому аспекту изобретения обеспечивается способ инкапсуляции разделенных данных мультимедиа с временной привязкой в сервере, при этом разделенные данные мультимедиа с временной привязкой содержат выборки с временной привязкой, при этом каждая выборка с временной привязкой содержит первый уровень и, по меньшей мере, один второй уровень, причем, по меньшей мере, один из уровней содержит множество подвыборок, представленных посредством одного или более блоков кодирования, при этом способ содержит:
- получение, по меньшей мере, одной подвыборки из множества подвыборок одной из выборок с временной привязкой, при этом полученные подвыборки формируют поднабор набора подвыборок упомянутой одной из выборок с временной привязкой;
- создание одной дорожки, содержащей упомянутую, по меньшей мере, одну полученную подвыборку; и
- независимую инкапсуляцию созданной дорожки в, по меньшей мере, одном файле сегмента мультимедиа, при этом упомянутый файл сегмента мультимедиа содержит метаданные отображения для обеспечения информации об упомянутой, по меньшей мере, одной полученной подвыборке по отношению к упомянутой одной из выборок с временной привязкой и уровню, которому она принадлежит.
Соответственно, изобретение обеспечивает возможность комбинирования разных масштабируемых частей, и, в частности, разных масштабируемых мозаичных элементов, и создания действительного формата файла, каким бы ни был выбранный набор масштабируемых частей или мозаичных элементов, загруженных клиентским устройством.
Поэтому, способ изобретения является подходящим для эффективной потоковой передачи независимых масштабируемых частей или мозаичных элементов, требует, чтобы только полезные данные посылались в клиентское устройство, является подходящим для выбора более, чем одной части или мозаичного элемента (то есть, произвольной ROI), уменьшает служебную информацию индексации, и может интегрироваться в стандарт MPEG.
Более того, обработка геометрической информации области ROI и идентификационной информации в одной и той же структуре, также как индексирование мозаичных элементов и областей ROI улучшает эффективность синтаксического разбора и извлечение областей интереса и мозаичных элементов.
В одном варианте осуществления, метаданные отображения сохраняются внутри одной и той же структуры.
В одном варианте осуществления, разделенные данные мультимедиа с временной привязкой являются мозаичными данными мультимедиа с временной привязкой, при этом подвыборки являются пространственными подвыборками.
В одном варианте осуществления, способ дополнительно содержит этап конфигурирования описателей данных для сохранения метаданных отображения, включающих в себя определения разных групп подвыборок, при этом первая группа ассоциирована с первым типом информации, характеризующей блоки кодирования подвыборки, и вторая группа ассоциирована со вторым типом информации, характеризующей блоки кодирования подвыборки.
В одном варианте осуществления, первый тип информации направлен на информацию, характеризующую отношение между блоками кодирования подвыборки и соответствующей выборкой с временной привязкой, и второй тип информации направлен на информацию, характеризующую отношение между блоками кодирования подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, тип группы ассоциирован с каждым блоком кодирования подвыборки, что обеспечивает возможность обрабатывать каждый блок кодирования как функцию информации, ассоциированной с первой группой, или как функцию информации, ассоциированной со второй группой.
В одном варианте осуществления, способ дополнительно содержит этап конфигурирования описателя данных для сохранения метаданных отображения, включающих в себя определение группы подвыборок, при этом метаданные отображения содержат информацию, характеризующую отношение между блоками кодирования подвыборки и соответствующей выборкой с временной привязкой.
В одном варианте осуществления, определение дополнительно содержит информацию, характеризующую отношение между, по меньшей мере, одним блоком кодирования подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, информация, характеризующая отношение между, по меньшей мере, одним блоком кодирования подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой, содержит информацию зависимости уровней подвыборок.
В одном варианте осуществления, информация зависимости уровней подвыборок содержит ссылку на определение подвыборки.
В одном варианте осуществления, информация, характеризующая отношение между, по меньшей мере, одним блоком кодирования подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой, содержит ссылку на описание уровня организации уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, описатель данных используется по умолчанию для характеризации блоков кодирования подвыборок, при этом способ дополнительно содержит этап конфигурирования, по меньшей мере, одного дополнительного описателя данных для сохранения метаданных отображения, содержащих идентификаторы подвыборок и соответствующую информацию, характеризующую отношение между блоками кодирования идентифицированных подвыборок и соответствующей выборкой с временной привязкой.
В одном варианте осуществления, метаданные отображения упомянутого, по меньшей мере, одного дополнительного описателя данных для сохранения метаданных отображения дополнительно содержат информацию, характеризующую отношение между, по меньшей мере, одним блоком кодирования идентифицированных подвыборок и организацией уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, сервер является совместимым с протоколом передачи гипертекстовых файлов (HTTP).
В одном варианте осуществления, файл сегмента мультимедиа, полученный в результате инкапсуляции созданной дорожки, является совместимым с базовым форматом мультимедийного файла и форматом динамической адаптивной потоковой передачи по HTTP, как определены международной организацией по стандартизации.
Согласно второму аспекту изобретения обеспечивается способ для обеспечения битового потока данных мультимедиа с временной привязкой из разделенных данных мультимедиа с временной привязкой, инкапсулированных в файле сегмента мультимедиа, в клиентском устройстве, при этом разделенные данные мультимедиа с временной привязкой содержат выборки с временной привязкой, при этом каждая выборка с временной привязкой содержит первый уровень и, по меньшей мере, один второй уровень, где, по меньшей мере, один из уровней содержит множество подвыборок, представленных посредством одного или более блоков кодирования, при этом файл сегмента мультимедиа содержит дорожку, содержащую, по меньшей мере, одну подвыборку, выбранную из множества подвыборок одной из выборок с временной привязкой, при этом упомянутая, по меньшей мере, одна подвыборка формирует поднабор набора подвыборок упомянутой одной из выборок с временной привязкой, при этом способ содержит:
- выбор элемента информации, представляющего, по меньшей мере, одну подвыборку;
- запрос дорожки, содержащей упомянутую, по меньшей мере, одну подвыборку, представленную посредством выбранного элемента информации;
- прием файла сегмента мультимедиа, при этом принятый файл сегмента мультимедиа содержит метаданные отображения для обеспечения информации об упомянутой, по меньшей мере, одной подвыборке, представленной посредством выбранного элемента информации, относящейся к соответствующей выборке и уровню, которому она принадлежит; и
- восстановление упомянутой, по меньшей мере, одной подвыборки, представленной посредством выбранного элемента информации, из принятого файла сегмента мультимедиа как функции метаданных отображения.
Соответственно, изобретение обеспечивает возможность комбинирования разных масштабируемых частей, и, в частности, разных масштабируемых мозаичных элементов, и создания действительного формата файла, каким бы ни был выбранный набор масштабируемых частей или мозаичных элементов, загруженных клиентским устройством.
Поэтому, способ изобретения является подходящим для эффективной потоковой передачи независимых масштабируемых частей или мозаичных элементов, требует, чтобы только полезные данные посылались в клиентское устройство, является подходящим для выбора более, чем одной части или мозаичного элемента (то есть, произвольной ROI), уменьшает служебную информацию индексации, и может интегрироваться в стандарт MPEG.
Более того, обработка геометрической информации области ROI и идентификационной информации в одной и той же структуре, также как индексирование мозаичных элементов и областей ROI улучшает эффективность синтаксического разбора и извлечение областей интереса и мозаичных элементов.
В одном варианте осуществления, метаданные отображения сохраняются внутри одной и той же структуры.
В одном варианте осуществления, разделенные данные мультимедиа с временной привязкой являются мозаичными данными мультимедиа с временной привязкой, при этом подвыборки являются пространственными подвыборками.
В одном варианте осуществления, способ дополнительно содержит этап получения из принятого файла сегмента мультимедиа описателей данных, хранящих метаданные отображения, включающие в себя определения разных групп подвыборок, при этом первая группа ассоциирована с первым типом информации, характеризующей блоки кодирования подвыборки, и вторая группа ассоциирована со вторым типом информации, характеризующей блоки кодирования подвыборки.
В одном варианте осуществления, первый тип информации направлен на информацию, характеризующую отношение между блоками кодирования подвыборки и соответствующей выборкой с временной привязкой, и второй тип информации направлен на информацию, характеризующую отношение между блоками кодирования подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, способ дополнительно содержит этап определения типа группы для каждого блока кодирования принятой подвыборки и этап обработки каждого из блоков кодирования как функции информации, ассоциированной с первой группой, или как функции информации, ассоциированной со второй группой.
В одном варианте осуществления, способ дополнительно содержит этап получения из принятого файла сегмента мультимедиа описателя данных, хранящего метаданные отображения, включающие в себя определение группы подвыборок, при этом метаданные отображения содержат информацию, характеризующую отношение между блоками кодирования принятой подвыборки и соответствующей выборкой с временной привязкой.
В одном варианте осуществления, определение дополнительно содержит информацию, характеризующую отношение между, по меньшей мере, одним блоком кодирования принятой подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой, при этом способ дополнительно содержит этап обработки блока кодирования принятой подвыборки как функции информации, характеризующей отношение между блоком кодирования и организацией уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, способ дополнительно содержит этап обработки блока кодирования принятой подвыборки как функции информации зависимости уровней подвыборок.
В одном варианте осуществления, способ дополнительно содержит этап получения определения подвыборки для подвыборки, от которой зависит обрабатываемый блок кодирования.
В одном варианте осуществления, информация, характеризующая отношение между, по меньшей мере, одним блоком кодирования принятой подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой, содержит ссылку на описание уровня организации уровней разделенных данных мультимедиа с временной привязкой, при этом способ дополнительно содержит этап обработки блока кодирования принятой подвыборки как функции ссылки на описание уровня организации уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, описатель данных используется по умолчанию для характеризации блоков кодирования принятых подвыборок, при этом способ дополнительно содержит этап получения, по меньшей мере, одного дополнительного описателя данных, хранящего метаданные отображения, содержащие идентификаторы подвыборок и соответствующую информацию, характеризующую отношение между блоками кодирования идентифицированных подвыборок и соответствующей выборкой с временной привязкой, при этом способ дополнительно содержит этап определения того, идентифицирована ли или нет подвыборка, подлежащая обработке, внутри дополнительного описателя данных.
В одном варианте осуществления, метаданные отображения упомянутого, по меньшей мере, одного дополнительного описателя данных, хранящего метаданные отображения, дополнительно содержат информацию, характеризующую отношение между, по меньшей мере, одним блоком кодирования идентифицированных подвыборок и организацией уровней разделенных данных мультимедиа с временной привязкой, при этом способ дополнительно содержит этап обработки принятой подвыборки как функции информации, характеризующей отношение между, по меньшей мере, одним блоком кодирования идентифицированных подвыборок и организацией уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, клиентское устройство является совместимым с протоколом передачи гипертекстовых файлов (HTTP).
В одном варианте осуществления, принятые файлы сегментов мультимедиа являются совместимыми с базовым форматом мультимедийного файла и форматом динамической адаптивной потоковой передачи по HTTP, как определены международной организацией по стандартизации.
Согласно третьему аспекту изобретения обеспечивается способ для инкапсуляции разделенных данных мультимедиа с временной привязкой в сервере, при этом разделенные данные мультимедиа с временной привязкой содержат выборки с временной привязкой, которые содержат множество подвыборок, представленных посредством одного или более блоков кодирования, при этом способ содержит:
- получение, по меньшей мере, одной подвыборки из множества подвыборок одной из выборок с временной привязкой, при этом полученные подвыборки формируют поднабор набора подвыборок упомянутой одной из выборок с временной привязкой;
- создание одной дорожки в расчете на полученную подвыборку; и
- инкапсуляцию созданных дорожек в, по меньшей мере, одном файле сегмента мультимедиа, при этом упомянутый файл сегмента мультимедиа содержит:
метаданные для сигнализации того, что созданные дорожки содержат подвыборки, которые являются частью одной и той же выборки с временной привязкой, и
мультимедийные данные, организованные в порции, при этом каждая порция содержит блоки кодирования одной и той же подвыборки для рассматриваемых выборок с временной привязкой.
Соответственно, изобретение обеспечивает возможность комбинирования разных масштабируемых частей, и, в частности, разных масштабируемых мозаичных элементов, и создания действительного формата файла, каким бы ни был выбранный набор масштабируемых частей или мозаичных элементов, загруженных клиентским устройством.
Поэтому, способ изобретения является подходящим для эффективной потоковой передачи независимых масштабируемых частей или мозаичных элементов, требует, чтобы только полезные данные посылались в клиентское устройство, является подходящим для выбора более, чем одной части или мозаичного элемента (то есть, произвольной ROI), уменьшает служебную информацию индексации, и может интегрироваться в стандарт MPEG.
Более того, обработка геометрической информации области ROI и идентификационной информации в одной и той же структуре, также как индексирование мозаичных элементов и областей ROI улучшает эффективность синтаксического разбора и извлечение областей интереса и мозаичных элементов.
Согласно четвертому аспекту изобретения обеспечивается способ для обеспечения битового потока данных мультимедиа с временной привязкой из разделенных данных мультимедиа с временной привязкой, инкапсулированных в файле сегмента мультимедиа, в клиентском устройстве, при этом разделенные данные мультимедиа с временной привязкой содержат выборки с временной привязкой, при этом каждая выборка с временной привязкой содержит первый уровень и, по меньшей мере, один второй уровень, где, по меньшей мере, один из уровней содержит множество подвыборок, представленных посредством одного или более блоков кодирования, при этом файл сегмента мультимедиа содержит множество дорожек, при этом каждая дорожка содержит одну подвыборку, выбранную из множества подвыборок одной из выборок с временной привязкой, при этом подвыборки дорожек формируют поднабор набора подвыборок упомянутой одной из выборок с временной привязкой, при этом способ содержит:
- выбор элемента информации, представляющего, по меньшей мере, одну подвыборку;
- запрос дорожек, содержащих подвыборки, представленные посредством выбранного элемента информации;
- прием файла сегмента мультимедиа, при этом принятый файл сегмента мультимедиа содержит
метаданные для сигнализации того, что принятые дорожки содержат подвыборки, которые являются частью одной и той же выборки с временной привязкой, и
мультимедийные данные, организованные в порции, при этом каждая порция содержит блоки кодирования одной и той же подвыборки для рассматриваемых выборок с временной привязкой,
- восстановление подвыборок, представленных посредством выбранного элемента информации, из принятого файла сегмента мультимедиа как функции метаданных отображения.
Соответственно, изобретение обеспечивает возможность комбинирования разных масштабируемых частей, и, в частности, разных масштабируемых мозаичных элементов, и создания действительного формата файла, каким бы ни был выбранный набор масштабируемых частей или мозаичных элементов, загруженных клиентским устройством.
Поэтому, способ изобретения является подходящим для эффективной потоковой передачи независимых масштабируемых частей или мозаичных элементов, требует, чтобы только полезные данные посылались в клиентское устройство, является подходящим для выбора более, чем одной части или мозаичного элемента (то есть, произвольной ROI), уменьшает служебную информацию индексации, и может интегрироваться в стандарт MPEG.
Более того, обработка геометрической информации области ROI и идентификационной информации в одной и той же структуре, также как индексирование мозаичных элементов и областей ROI улучшает эффективность синтаксического разбора и извлечение областей интереса и мозаичных элементов.
Согласно пятому аспекту изобретения обеспечивается устройство для инкапсуляции разделенных данных мультимедиа с временной привязкой в сервере, при этом разделенные данные мультимедиа с временной привязкой содержат выборки с временной привязкой, при этом каждая выборка с временной привязкой содержит первый уровень и, по меньшей мере, один второй уровень, где, по меньшей мере, один из уровней содержит множество подвыборок, представленных посредством одного или более блоков кодирования, при этом устройство содержит, по меньшей мере, один микропроцессор, сконфигурированный с возможностью для выполнения этапов:
- получения, по меньшей мере, одной подвыборки из множества подвыборок одной из выборок с временной привязкой, при этом полученные подвыборки формируют поднабор набора подвыборок упомянутой одной из выборок с временной привязкой;
- создания одной дорожки, содержащей упомянутую, по меньшей мере, одну полученную подвыборку; и
- независимой инкапсуляции созданной дорожки в, по меньшей мере, одном файле сегмента мультимедиа, при этом упомянутый файл сегмента мультимедиа содержит метаданные отображения для обеспечения информации об упомянутой, по меньшей мере, одной полученной подвыборке по отношению к упомянутой одной из выборок с временной привязкой и уровню, которому она принадлежит.
Соответственно, изобретение обеспечивает возможность комбинирования разных масштабируемых частей, и, в частности, разных масштабируемых мозаичных элементов, и создания действительного формата файла, каким бы ни был выбранный набор масштабируемых частей или мозаичных элементов, загруженных клиентским устройством.
Поэтому, устройство изобретения является подходящим для эффективной потоковой передачи независимых масштабируемых частей или мозаичных элементов, требует, чтобы только полезные данные посылались в клиентское устройство, является подходящим для выбора более, чем одной части или мозаичного элемента (то есть, произвольной ROI), уменьшает служебную информацию индексации, и может интегрироваться в стандарт MPEG.
Более того, обработка геометрической информации области ROI и идентификационной информации в одной и той же структуре, также как индексирование мозаичных элементов и областей ROI улучшает эффективность синтаксического разбора и извлечение областей интереса и мозаичных элементов.
В одном варианте осуществления, метаданные отображения сохраняются внутри одной и той же структуры.
В одном варианте осуществления, разделенные данные мультимедиа с временной привязкой являются мозаичными данными мультимедиа с временной привязкой, при этом подвыборки являются пространственными подвыборками.
В одном варианте осуществления, микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа конфигурирования описателей данных для сохранения метаданных отображения, включающих в себя определения разных групп подвыборок, при этом первая группа ассоциирована с первым типом информации, характеризующей блоки кодирования подвыборки, и вторая группа ассоциирована со вторым типом информации, характеризующей блоки кодирования подвыборки.
В одном варианте осуществления, первый тип информации направлен на информацию, характеризующую отношение между блоками кодирования подвыборки и соответствующей выборкой с временной привязкой, и второй тип информации направлен на информацию, характеризующую отношение между блоками кодирования подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, тип группы ассоциирован с каждым блоком кодирования подвыборки, что обеспечивает возможность обрабатывать каждый блок кодирования как функцию информации, ассоциированной с первой группой, или как функцию информации, ассоциированной со второй группой.
В одном варианте осуществления, микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа конфигурирования описателя данных для сохранения метаданных отображения, включающих в себя определение группы подвыборок, при этом метаданные отображения содержат информацию, характеризующую отношение между блоками кодирования подвыборки и соответствующей выборкой с временной привязкой.
В одном варианте осуществления, определение дополнительно содержит информацию, характеризующую отношение между, по меньшей мере, одним блоком кодирования подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, информация, характеризующая отношение между, по меньшей мере, одним блоком кодирования подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой, содержит информацию зависимости уровней подвыборок.
В одном варианте осуществления, информация зависимости уровней подвыборок содержит ссылку на определение подвыборки.
В одном варианте осуществления, информация, характеризующая отношение между, по меньшей мере, одним блоком кодирования подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой, содержит ссылку на описание уровня организации уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, описатель данных используется по умолчанию для характеризации блоков кодирования подвыборок, при этом микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа конфигурирования, по меньшей мере, одного дополнительного описателя данных для сохранения метаданных отображения, содержащих идентификаторы подвыборок и соответствующую информацию, характеризующую отношение между блоками кодирования идентифицированных подвыборок и соответствующей выборкой с временной привязкой.
В одном варианте осуществления, метаданные отображения упомянутого, по меньшей мере, одного дополнительного описателя данных для сохранения метаданных отображения дополнительно содержат информацию, характеризующую отношение между, по меньшей мере, одним блоком кодирования идентифицированных подвыборок и организацией уровней разделенных данных мультимедиа с временной привязкой.
Согласно шестому аспекту изобретения обеспечивается устройство для обеспечения битового потока данных мультимедиа с временной привязкой из разделенных данных мультимедиа с временной привязкой, инкапсулированных в файле сегмента мультимедиа, в клиентском устройстве, при этом разделенные данные мультимедиа с временной привязкой содержат выборки с временной привязкой, при этом каждая выборка с временной привязкой содержит первый уровень и, по меньшей мере, один второй уровень, где, по меньшей мере, один из уровней содержит множество подвыборок, представленных посредством одного или более блоков кодирования, при этом файл сегмента мультимедиа содержит дорожку, содержащую, по меньшей мере, одну подвыборку, выбранную из множества подвыборок одной из выборок с временной привязкой, при этом упомянутая, по меньшей мере, одна подвыборка формирует поднабор набора подвыборок упомянутой одной из выборок с временной привязкой, при этом устройство содержит, по меньшей мере, один микропроцессор, сконфигурированный с возможностью для выполнения этапов:
- выбора элемента информации, представляющего, по меньшей мере, одну подвыборку;
- запроса дорожки, содержащей упомянутую, по меньшей мере, одну подвыборку, представленную посредством выбранного элемента информации;
- приема файла сегмента мультимедиа, при этом принятый файл сегмента мультимедиа содержит метаданные отображения для обеспечения информации об упомянутой, по меньшей мере, одной подвыборке, представленной посредством выбранного элемента информации, относящейся к соответствующей выборке и уровню, которому она принадлежит; и
- восстановления упомянутой, по меньшей мере, одной подвыборки, представленной посредством выбранного элемента информации, из принятого файла сегмента мультимедиа как функции метаданных отображения.
Соответственно, изобретение обеспечивает возможность комбинирования разных масштабируемых частей, и, в частности, разных масштабируемых мозаичных элементов, и создания действительного формата файла, каким бы ни был выбранный набор масштабируемых частей или мозаичных элементов, загруженных клиентским устройством.
Поэтому, устройство изобретения является подходящим для эффективной потоковой передачи независимых масштабируемых частей или мозаичных элементов, требует, чтобы только полезные данные посылались в клиентское устройство, является подходящим для выбора более, чем одной части или мозаичного элемента (то есть, произвольной ROI), уменьшает служебную информацию индексации, и может интегрироваться в стандарт MPEG.
Более того, обработка геометрической информации области ROI и идентификационной информации в одной и той же структуре, также как индексирование мозаичных элементов и областей ROI улучшает эффективность синтаксического разбора и извлечение областей интереса и мозаичных элементов.
В одном варианте осуществления, метаданные отображения сохраняются внутри одной и той же структуры.
В одном варианте осуществления, разделенные данные мультимедиа с временной привязкой являются мозаичными данными мультимедиа с временной привязкой, при этом подвыборки являются пространственными подвыборками.
В одном варианте осуществления, микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа получения из принятого файла сегмента мультимедиа описателей данных, хранящих метаданные отображения, включающие в себя определения разных групп подвыборок, при этом первая группа ассоциирована с первым типом информации, характеризующей блоки кодирования подвыборки, и вторая группа ассоциирована со вторым типом информации, характеризующей блоки кодирования подвыборки.
В одном варианте осуществления, первый тип информации направлен на информацию, характеризующую отношение между блоками кодирования подвыборки и соответствующей выборкой с временной привязкой, и второй тип информации направлен на информацию, характеризующую отношение между блоками кодирования подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа определения типа группы для каждого блока кодирования принятой подвыборки и этапа обработки каждого из блоков кодирования как функции информации, ассоциированной с первой группой, или как функции информации, ассоциированной со второй группой.
В одном варианте осуществления, микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа получения из принятого файла сегмента мультимедиа описателя данных, хранящего метаданные отображения, включающие в себя определение группы подвыборок, при этом метаданные отображения содержат информацию, характеризующую отношение между блоками кодирования принятой подвыборки и соответствующей выборкой с временной привязкой.
В одном варианте осуществления, определение дополнительно содержит информацию, характеризующую отношение между, по меньшей мере, одним блоком кодирования принятой подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой, при этом микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа обработки блока кодирования принятой подвыборки как функции информации, характеризующей отношение между блоком кодирования и организацией уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа обработки блока кодирования принятой подвыборки как функции информации зависимости уровней подвыборок.
В одном варианте осуществления, микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа получения определения подвыборки для подвыборки, от которой зависит обрабатываемый блок кодирования.
В одном варианте осуществления, информация, характеризующая отношение между, по меньшей мере, одним блоком кодирования принятой подвыборки и организацией уровней разделенных данных мультимедиа с временной привязкой, содержит ссылку на описание уровня организации уровней разделенных данных мультимедиа с временной привязкой, при этом микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа обработки блока кодирования принятой подвыборки как функции ссылки на описание уровня организации уровней разделенных данных мультимедиа с временной привязкой.
В одном варианте осуществления, описатель данных используется по умолчанию для характеризации блоков кодирования принятых подвыборок, при этом микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа получения, по меньшей мере, одного дополнительного описателя данных, хранящего метаданные отображения, содержащие идентификаторы подвыборок и соответствующую информацию, характеризующую отношение между блоками кодирования идентифицированных подвыборок и соответствующей выборкой с временной привязкой, и при этом микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа определения того, идентифицирована ли или нет подвыборка, подлежащая обработке, внутри дополнительного описателя данных.
В одном варианте осуществления, метаданные отображения упомянутого, по меньшей мере, одного дополнительного описателя данных, хранящего метаданные отображения, дополнительно содержат информацию, характеризующую отношение между, по меньшей мере, одним блоком кодирования идентифицированных подвыборок и организацией уровней разделенных данных мультимедиа с временной привязкой, при этом микропроцессор дополнительно сконфигурирован с возможностью для выполнения этапа обработки принятой подвыборки как функции информации, характеризующей отношение между, по меньшей мере, одним блоком кодирования идентифицированных подвыборок и организацией уровней разделенных данных мультимедиа с временной привязкой.
Согласно седьмому аспекту изобретения обеспечивается устройство для инкапсуляции разделенных данных мультимедиа с временной привязкой в сервере, при этом разделенные данные мультимедиа с временной привязкой содержат выборки с временной привязкой, которые содержат множество подвыборок, представленных посредством одного или более блоков кодирования, при этом устройство содержит, по меньшей мере, один микропроцессор, сконфигурированный с возможностью для выполнения этапов:
- получения, по меньшей мере, одной подвыборки из множества подвыборок одной из выборок с временной привязкой, при этом полученные подвыборки формируют поднабор набора подвыборок упомянутой одной из выборок с временной привязкой;
- создания одной дорожки в расчете на полученную подвыборку; и
- инкапсуляции созданных дорожек в, по меньшей мере, одном файле сегмента мультимедиа, при этом упомянутый файл сегмента мультимедиа содержит:
метаданные для сигнализации того, что созданные дорожки содержат подвыборки, которые являются частью одной и той же выборки с временной привязкой, и
мультимедийные данные, организованные в порции, при этом каждая порция содержит блоки кодирования одной и той же подвыборки для рассматриваемых выборок с временной привязкой.
Соответственно, изобретение обеспечивает возможность комбинирования разных масштабируемых частей, и, в частности, разных масштабируемых мозаичных элементов, и создания действительного формата файла, каким бы ни был выбранный набор масштабируемых частей или мозаичных элементов, загруженных клиентским устройством.
Поэтому, устройство изобретения является подходящим для эффективной потоковой передачи независимых масштабируемых частей или мозаичных элементов, требует, чтобы только полезные данные посылались в клиентское устройство, является подходящим для выбора более, чем одной части или мозаичного элемента (то есть, произвольной ROI), уменьшает служебную информацию индексации, и может интегрироваться в стандарт MPEG.
Более того, обработка геометрической информации области ROI и идентификационной информации в одной и той же структуре, также как индексирование мозаичных элементов и областей ROI улучшает эффективность синтаксического разбора и извлечение областей интереса и мозаичных элементов.
Согласно восьмому аспекту изобретения обеспечивается устройство для обеспечения битового потока данных мультимедиа с временной привязкой из разделенных данных мультимедиа с временной привязкой, инкапсулированных в файле сегмента мультимедиа, в клиентском устройстве, при этом разделенные данные мультимедиа с временной привязкой содержат выборки с временной привязкой, при этом каждая выборка с временной привязкой содержит первый уровень и, по меньшей мере, один второй уровень, где, по меньшей мере, один из уровней содержит множество подвыборок, представленных посредством одного или более блоков кодирования, при этом файл сегмента мультимедиа содержит множество дорожек, при этом каждая дорожка содержит одну подвыборку, выбранную из множества подвыборок одной из выборок с временной привязкой, при этом подвыборки дорожек формируют поднабор набора подвыборок упомянутой одной из выборок с временной привязкой, при этом устройство содержит, по меньшей мере, один микропроцессор, сконфигурированный с возможностью для выполнения этапов:
- выбора элемента информации, представляющего, по меньшей мере, одну подвыборку;
- запроса дорожек, содержащих подвыборки, представленные посредством выбранного элемента информации;
- приема файла сегмента мультимедиа, при этом принятый файл сегмента мультимедиа содержит
метаданные для сигнализации того, что принятые дорожки содержат подвыборки, которые являются частью одной и той же выборки с временной привязкой, и
мультимедийные данные, организованные в порции, при этом каждая порция содержит блоки кодирования одной и той же подвыборки для рассматриваемых выборок с временной привязкой,
- восстановления подвыборок, представленных посредством выбранного элемента информации, из принятого файла сегмента мультимедиа как функции метаданных отображения.
Соответственно, изобретение обеспечивает возможность комбинирования разных масштабируемых частей, и, в частности, разных масштабируемых мозаичных элементов, и создания действительного формата файла, каким бы ни был выбранный набор масштабируемых частей или мозаичных элементов, загруженных клиентским устройством.
Поэтому, устройство изобретения является подходящим для эффективной потоковой передачи независимых масштабируемых частей или мозаичных элементов, требует, чтобы только полезные данные посылались в клиентское устройство, является подходящим для выбора более, чем одной части или мозаичного элемента (то есть, произвольной ROI), уменьшает служебную информацию индексации, и может интегрироваться в стандарт MPEG.
Более того, обработка геометрической информации области ROI и идентификационной информации в одной и той же структуре, также как индексирование мозаичных элементов и областей ROI улучшает эффективность синтаксического разбора и извлечение областей интереса и мозаичных элементов.
В одном варианте осуществления, сервер является совместимым с протоколом передачи гипертекстовых файлов (HTTP) и при этом принятые файлы сегментов мультимедиа являются совместимыми с базовым форматом мультимедийного файла и форматом динамической адаптивной потоковой передачи по HTTP, как определены международной организацией по стандартизации.
В одном варианте осуществления, клиентское устройство является совместимым с протоколом передачи гипертекстовых файлов (HTTP) и при этом принятые файлы сегментов мультимедиа являются совместимыми с базовым форматом мультимедийного файла и форматом динамической адаптивной потоковой передачи по HTTP, как определены международной организацией по стандартизации.
Согласно девятому и десятому аспектам изобретения обеспечивается видеокодер и видеодекодер, содержащий устройство, описанное выше.
Соответственно, изобретение обеспечивает возможность комбинирования разных масштабируемых частей, и, в частности, разных масштабируемых мозаичных элементов, и создания действительного формата файла, каким бы ни был выбранный набор масштабируемых частей или мозаичных элементов, загруженных клиентским устройством.
Поэтому, видеокодер и видеодекодер изобретения являются подходящими для эффективной потоковой передачи независимых масштабируемых частей или мозаичных элементов, требуют, чтобы только полезные данные посылались в клиентское устройство, являются подходящими для выбора более, чем одной части или мозаичного элемента (то есть, произвольной ROI), уменьшают служебную информацию индексации, и могут интегрироваться в стандарт MPEG.
Более того, обработка геометрической информации области ROI и идентификационной информации в одной и той же структуре, также как индексирование мозаичных элементов и областей ROI улучшает эффективность синтаксического разбора и извлечение областей интереса и мозаичных элементов.
Так как настоящее изобретение может осуществляться в программном обеспечении, настоящее изобретение может осуществляться как машиночитаемый код для обеспечения в программируемое устройство на любом подходящем носителе передачи. Материальный носитель передачи может содержать запоминающий носитель, такой как гибкий диск, CD-ROM, привод на жестких дисках, устройство на магнитной ленте или твердотельное запоминающее устройство и подобное. Временный носитель передачи может включать в себя сигнал, такой как электрический сигнал, электронный сигнал, оптический сигнал, акустический сигнал, магнитный сигнал или электромагнитный сигнал, например, микроволновый или RF сигнал.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Дополнительные преимущества настоящего изобретения станут видны специалистам в данной области техники при изучении чертежей и подробного описания. Предполагается, что здесь содержатся любые дополнительные преимущества.
Теперь будут описываться варианты осуществления изобретения, только в качестве примера, и со ссылкой на последующие чертежи, на которых:
Фиг. 1, содержащая фиг. 1a и 1b, иллюстрирует пример кодирования мозаичных элементов в кодированном битовом видеопотоке;
Фиг. 2 иллюстрирует временную последовательность мозаичных элементов, выбранных пользователем для отображения;
Фиг. 3, содержащая фиг. 3a, 3b, и 3c, иллюстрирует разные примеры конфигураций масштабируемых битовых потоков HEVC;
Фиг. 4 иллюстрирует пример мозаичного битового видеопотока, соответствующего стандарту HEVC, кодированного как одиночная дорожка mp4;
Фиг. 5 иллюстрирует пример потока SVC основанной на выборках инкапсуляции, соответствующего ISO/IEC 14496-15, кодированного в файле mp4;
Фиг. 6, содержащая фиг. 6a и 6b, иллюстрирует пример инкапсуляции мозаичного масштабируемого видеопотока типа HEVC как одиночной дорожки в файл mp4, согласно первому варианту осуществления;
Фиг. 7, содержащая фиг. 7a и 7b, иллюстрирует пример инкапсуляции мозаичного масштабируемого видеопотока типа HEVC как одиночной дорожки в файл mp4, согласно второму варианту осуществления;
Фиг. 8 иллюстрирует пример новых параметров описателя TileRegionGroupEntry, обеспечивающего возможность инкапсуляции мозаичного масштабируемого видеопотока типа HEVC в файл, такой как файл mp4;
Фиг. 9, содержащая фиг. 9a и 9b, иллюстрирует пример инкапсуляции мозаичного масштабируемого видеопотока типа HEVC как одиночной дорожки в файл mp4, согласно третьему варианту осуществления;
Фиг. 10 иллюстрирует описатели мозаичного элемента и масштабируемого уровня, согласно конкретному варианту осуществления, чтобы инкапсулировать битовый поток HEVC;
Фиг. 11, содержащая фиг. 11a и фиг. 11b, является блок-схемой последовательности операций, иллюстрирующей этапы для передачи данных мультимедиа с временной привязкой между сервером и клиентским устройством согласно конкретному варианту осуществления;
Фиг. 12 представляет блок-схему сервера или клиентского устройства, в которых могут осуществляться этапы одного или более вариантов осуществления;
Фиг. 13, содержащая фиг. 13a, 13b, и 13c, иллюстрирует примеры мозаичных элементов и сегментов срезов в битовом потоке HEVC;
Фиг. 14, содержащая фиг. 14a и фиг. 14b, иллюстрирует сигнализацию положения мозаичного элемента в полном видео, размера мозаичного элемента, и индикации, что дорожка с мозаичными элементами может декодироваться без какого-либо артефакта, на уровне подвыборок, адаптированную, чтобы обрабатывать различные конфигурации мозаичного размещения; и
Фиг. 15, содержащая фиг. 15a и 15b, иллюстрирует пример инкапсуляции мозаичных элементов в множестве дорожек, для эффективной адресации данных.
ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ
Согласно конкретному варианту осуществления, масштабируемые разделенные данные мультимедиа с временной привязкой, такие как мозаичные данные мультимедиа с временной привязкой (например, видеоданные), содержащие выборки с временной привязкой (например, изображения), передаются как набор файлов сегментов мультимедиа, например, файлов сегментов мультимедиа, соответствующих стандарту mp4 (ISO/IEC 14496-14). Файлы сегментов мультимедиа обычно состоят из части заголовка и части данных. Часть заголовка содержит описательные метаданные, чтобы адресовать и извлекать данные, содержащиеся в части данных. Выборки с временной привязкой содержат один или более уровней представления (масштабируемое видео) с пространственными подвыборками (мозаичными элементами). Каждая пространственная подвыборка может представляться посредством одного или нескольких блоков NAL.
Файл сегмента инициализации может использоваться, чтобы передавать метаданные, требуемые для декодирования файлов сегментов мультимедиа.
Фиг. 1, содержащая фиг. 1a и фиг. 1b, иллюстрирует пример кодирования мозаичных элементов в кодированном битовом видеопотоке.
Для иллюстрации, в последующем описании предполагается, что каждый видеокадр (выборка с временной привязкой) состоит из независимо декодируемых мозаичных элементов, соответствующих пространственным подчастям (пространственным подвыборкам) видеокадра. Видео является предпочтительно масштабируемым и организовано в разных уровнях масштабируемости. Как проиллюстрировано на фиг. 1a, видеокадр 100 может содержать базовый уровень (102) HD и уровень (104) расширения 4K2K. Еще для иллюстрации, уровень 104 расширения может разделяться на четыре правильных мозаичных элемента, обозначенных a, b, c, и d. Следует отметить, что могут использоваться мозаичные элементы разных форм. Подобным образом, базовый уровень 102 может разделяться на несколько мозаичных элементов.
Фиг. 1b представляет обычный кодированный битовый видеопоток в порядке декодирования. Как проиллюстрировано, кодированный битовый видеопоток содержит здесь три видеокадра (110, 112, и 114), кодированных во временном порядке. Каждый видеокадр содержит все блоки уровня сетевой абстракции (NAL) базового уровня (BL), за которыми следуют блоки NAL уровня расширения. Например, за блоками (1BL, 116) NAL базового уровня (102-1) первого видеокадра (110) следуют блоки NAL (1 общие, 1a, 1b, 1c, 1d, 118) уровня (104-1) расширения первого видеокадра.
Часть битового видеопотока, соответствующая уровню расширения с пространственными мозаичными элементами, состоит из блоков NAL каждого мозаичного элемента. Необязательно, она также может содержать блоки NAL, которые являются общими для всех мозаичных элементов и которые требуются, чтобы декодировать любой из мозаичных элементов. Блоки NAL, которые являются общими для всех мозаичных элементов заданного кадра, могут располагаться где угодно в соответствующей части битового видеопотока (то есть, перед, между, или после блоков NAL мозаичных элементов видеокадра).
Как проиллюстрировано, часть битового видеопотока, соответствующая уровню расширения первого видеокадра (110), содержащая пространственные мозаичные элементы a, b, c, и d, состоит из блоков NAL для каждого мозаичного элемента (1a, 1b, 1c, и 1d) и из блоков NAL (1 общие), которые являются общими для всех мозаичных элементов a, b, c, и d.
Фиг. 2 иллюстрирует временную последовательность мозаичных элементов, выбранных пользователем для отображения. Более точно, фиг. 2 представляет первый видеокадр n и второй видеокадр n+m (где n и m являются целочисленными значениями), при этом каждый из первого и второго видеокадров содержит двенадцать мозаичных элементов, пронумерованных 1 по 12. Среди этих двенадцати мозаичных элементов, должны отображаться только третий и седьмой мозаичные элементы (как обозначено с помощью полужирных линий). Видеокадры n и n+m принадлежат последовательности последовательных кадров, соответствующих заданному временному периоду. Поэтому, третий и седьмой мозаичные элементы каждого кадра от кадра n до кадра n+m отображаются последовательно.
Как проиллюстрировано на фиг. 1, данные битового видеопотока организованы как временные выборки, которые соответствуют полным кадрам. Соответственно, требуется осуществлять доступ к нескольким малым байтовым диапазонам для каждого кадра, когда должен осуществляться доступ к конкретным пространственным областям этих кадров в течение заданного периода времени, как описано выше посредством ссылки на фиг. 2.
Поэтому, чтобы обеспечивать эффективный доступ в сжатом видео для потоковой передачи ROI, то есть, чтобы обеспечивать эффективный доступ к данным конкретных мозаичных элементов и конкретных уровней масштабируемости, битовый поток данных мультимедиа с временной привязкой должен эффективно описываться.
Фиг. 3, содержащая фиг. 3a, 3b, и 3c, иллюстрирует разные примеры конфигураций масштабируемых битовых потоков HEVC.
Фиг. 3a является примером пространственно масштабируемого битового видеопотока, содержащего базовый уровень 300 и уровень 305 расширения. Уровень 310 расширения кодируется как функция базового уровня 300. В таком формате битового видеопотока, существует зависимость картинки от картинки, так как никакой из базового уровня и уровня расширения не содержит мозаичный элемент.
Фиг. 3b иллюстрирует другой пример масштабируемого битового видеопотока, содержащего базовый уровень 310 и уровень 315 расширения. Согласно этому примеру, уровень 315 расширения является мозаичным уровнем расширения, содержащим, в частности, мозаичный элемент 320. В таком формате битового видеопотока, существует зависимость мозаичного элемента от картинки, так как мозаичные элементы уровня расширения зависят от базового уровня.
Фиг. 3c иллюстрирует еще другой пример масштабируемого битового видеопотока, содержащего базовый уровень 325 и уровень 330 расширения. Согласно этому примеру, базовый уровень 325 является мозаичным базовым уровнем, содержащим, в частности, мозаичные элементы 335 и 340, и уровень 330 расширения является мозаичным уровнем расширения, содержащим, в частности, мозаичный элемент 345 и набор 350 мозаичных элементов. Базовый уровень 325 может пространственно расширяться с помощью уровня 330 расширения. В таком формате битового видеопотока, существует зависимость мозаичного элемента от мозаичного элемента, так как мозаичные элементы уровня расширения зависят от мозаичных элементов базового уровня. Также существует зависимость набора мозаичных элементов от мозаичного элемента, так как набор мозаичных элементов уровня расширения зависит от мозаичных элементов базового уровня. Для иллюстрации, мозаичный элемент 345 зависит от мозаичного элемента 340 и набор 350 мозаичных элементов зависит от мозаичного элемента 335. Могут существовать другие зависимости, такие как зависимость мозаичного элемента от набора мозаичных элементов или зависимость набора мозаичных элементов от набора мозаичных элементов.
Следует отметить, что аналогичные конфигурации существуют для масштабируемого уровня SNR, который может быть мозаичным или нет на вершине базового уровня, который также может быть мозаичным или нет.
Фиг. 4 иллюстрирует пример мозаичного битового видеопотока, соответствующего стандарту HEVC, кодированного как одиночная дорожка mp4, содержащая первую часть 400 для кодирования данных и вторую часть 410, содержащую описательные метаданные.
Видеоданные кодируются внутри блока 400 mdat, который содержит набор 401 параметров и данные выборок, например, данные 402 и 403 выборок, соответствующие выборке 1 и выборке S, соответственно. Как проиллюстрировано, набор параметров обычно содержит VPS (набор параметров видео), SPS (набор параметров последовательности), PPS (набор параметров картинок), и SEI (дополнительную информацию расширения). Каждая выборка содержит блоки NAL, как, например, выборка S, которая содержит блок 404 NAL. Согласно конкретной конфигурации, проиллюстрированной на фиг. 4, каждый мозаичный элемент кодируется внутри одного блока NAL. Например, блок 404 NAL содержит мозаичный элемент 405.
Как представлено, описательные метаданные содержатся внутри блока 410 moov. Он главным образом содержит информацию группирования выборок. В частности, он содержит блок 411 SampleToGroup ('sbgp'), который описывает назначение выборок группам выборок, и два блока 412 и 413 SampleGroupDescription ('sgpd'), которые, каждый описывает некоторый тип общих свойств выборок внутри конкретной группы выборок. Первый блок 412 SampleToGroupDescription описывает отображение блоков NAL в группы (идентифицируемые с помощью идентификаторов groupID), определяющие описания мозаичных элементов. Эти описания мозаичных элементов описываются во втором блоке 413 SampleGroupDescription.
Как проиллюстрировано в данном примере, каждый блок NAL, объявленный в блоке 414 NALUMapEntry, указывает на блок TileRegionGroupEntry (идентифицированный посредством флага 'trif' (информации области мозаичного элемента)), как, например, блоки 415 и 416 TileRegionGroupEntry. Каждый блок TileRegionGroupEntry обеспечивает информацию мозаичного элемента, такую как индикация декодирования, чтобы указывать, являются ли или нет данные мозаичного элемента независимо декодируемыми, и чтобы указывать положение мозаичного элемента и размер мозаичного элемента.
Фиг. 5 иллюстрирует пример потока SVC основанной на выборках инкапсуляции, соответствующего ISO/IEC 14496-15, кодированного в файле 500 mp4.
Как представлено, описательные метаданные содержатся внутри блока 501 moov и видеоданные кодированы внутри блока 502 mdat.
Блок 501 moov инкапсулирует одиночную дорожку 503, которая главным образом описывает то, как выборки видеоданных, например, выборки 504, 505 и 506 видеоданных, отображаются в описания. С этой целью, используется блок 507 SampleToGroup, ссылающийся на блоки 508 и 509 SampleToGroupDescription. Более точно, блок 507 SampleToGroup назначает идентификатор отображения каждой выборке, в зависимости от ее отображения блоков NAL в уровни масштабируемости. Как проиллюстрировано, каждая выборка может назначаться, в данном примере, идентификатору Отображения 0 или Отображения 1. Каждое отображение блоков NAL описывается в описателе ScalableNALUMapEntry, который хранится в блоке 508 SampleToGroupDescription. В каждом описателе ScalableNALUMapEntry, параметр groupID указывает, в каком блоке ScalableGroupEntry блока 510 SampleGroupDescription описание может быть найдено. Другими словами, параметр groupID указывает соответствующую запись группы масштабирования, множества видов, мозаичного элемента, набора мозаичных элементов, или уровня HEVC, как указано в описаниях групп выборок. Если значение этого параметра равняется нулю, никакая группа не ассоциирована с этими идентифицированными блоками NAL.
Описания уровней масштабируемости могут объявляться в элементах 'Tier', которые используются, чтобы описывать уровни согласно специальному понятию, введенному для инкапсуляции SVC. Более точно, 'Tier' описывает набор рабочих точек внутри дорожки, обеспечивая информацию о рабочих точках и инструкции в отношении того, как осуществлять доступ к соответствующим частям битового потока. Согласно стандарту SVC, рабочая точка представляется посредством триплета, содержащего следующие три идентификатора: dependency_id, temporal_id, и quality_id. 'Tier' представляется посредством одного или нескольких блоков, хранящихся внутри блока ScalableGroupEntry, такого как блок 509 ScalableGroupEntry. Один блок, указываемый как TierInfoBox, является обязательным в описании 'Tier', чтобы обеспечивать информацию профиля и уровня, как кодирована в элементарном потоке видео и в потоках пространственного и временного разрешения, как проиллюстрировано в блоке 509 ScalableGroupEntry.
Фиг. 6, содержащая фиг. 6a и 6b, иллюстрирует пример инкапсуляции мозаичного масштабируемого видеопотока типа HEVC как одиночной дорожки в файл mp4, согласно первому варианту осуществления.
Как проиллюстрировано на фиг. 6a, предполагается, что видеопоток содержит базовый уровень 600, который может расширяться посредством упомянутых двух независимых пространственных уровней 601 и 602 расширения. Уровень 601 расширения, указываемый как уровень A расширения, содержит мозаичные элементы T1 и T2, и уровень 602 расширения, указываемый как уровень B расширения, содержит мозаичные элементы T1, T2, T3, и T4 (мозаичные элементы T1 и T2 уровня A расширения отличаются от мозаичных элементов T1 и T2 уровня B расширения).
Как показано на фиг. 6b, чтобы инкапсулировать мозаичный масштабируемый видеопоток, кодированный согласно стандарту HEVC, в файл 610 mp4, видеоданные сохраняются в блоке 612 mdat как список выборок, содержащих, в частности, выборку 620. Каждая выборка кодируется как набор одного или более блоков NAL. Как проиллюстрировано, выборка 620 содержит чередующиеся блоки 621 по 627 NAL, соответствующие базовому уровню (блок 621 NAL), мозаичному уровню A расширения (блоки 622 и 623 NAL), и мозаичному уровню B расширения (блоки 624 по 627 NAL).
Описание этих данных хранится в блоке 611 moov, содержащем блок 'trak' для описания, в частности, отображения блоков NAL и группирования выборок. Согласно данному примеру, необходимо описать отображение блоков NAL в мозаичные элементы, как описано посредством ссылки на фиг. 4, и отображение блоков NAL в уровни масштабируемости, как описано посредством ссылки на фиг. 5.
Комбинирование решений, раскрытых посредством ссылки на фиг. 4 и 5, ведет к использованию двух блоков 613 и 614 SampleToGroup для отображения каждой выборки видеоданных как функции отображения для отображения блоков NAL в мозаичные элементы (блок 615 NALUMapEntry) и как функции отображения для отображения блоков NAL в уровни масштабируемости (блок 615 NALUMapEntry). Отношения мозаичных элементов могут описываться внутри структуры TileRegionGroupEntry в выделенном блоке SampleGroupDescription (не представлен на фиг. 6), в то время как отношения масштабируемых уровней могут описываться с использованием блоков, эквивалентных блокам 'Tier'.
Однако, так как элементы 'Tier' не определены в стандарте HEVC, должна использоваться эквивалентная структура, чтобы хранить информацию в отношении организации уровней. Это может делаться посредством использования блока HEVCLayerDefinitionBox для каждого уровня, как проиллюстрировано на фиг. 6b, где блоки 617, 618, и 619 HEVCLayerDefinitionBox дают информацию о базовом уровне, уровне A расширения, и уровне B расширения, соответственно. Пример структуры блока HEVCLayerDefinitionBox описывается посредством ссылки на фиг. 8 (ссылочная позиция 802).
Чтобы избегать какого-либо конфликта между идентификаторами groupID, используемыми в описании мозаичного элемента, и идентификаторами groupID, используемыми в уровнях масштабируемости, должно быть установлено отношение между блоками NAL, ассоциированными с мозаичными элементами, и блоками NAL, ассоциированными с уровнями масштабируемости. С этой целью, структура NALUMapEntry расширяется с помощью нового параметра, который может указываться как ref_grouping_type:
Согласно примеру, проиллюстрированному на фиг. 6, значение параметра ref_grouping_type может устанавливаться на 'trif' для выбора описателя NALUMapEntry, который является специальным для мозаичного элемента, указанно как отображение 615 (указывающее на описание мозаичного элемента), и на 'scif' (запись масштабируемой группы, обеспечивающую информацию масштабируемости) для выбора другого описателя NALUMapEntry, который является специальным для масштабируемости, указанно как отображение 616 (указывающее на описание уровня масштабируемости).
'trif' описан выше посредством ссылки на фиг. 4, в блоке 'sgpd'. Для ясности, этот блок не проиллюстрирован на фиг. 6b. Однако, как проиллюстрировано на фиг. 4, блок 'sgpd' может включаться в блок 'moov'.
'scif' является другим хорошо известным блоком, который обеспечивает информацию (не проиллюстрирована здесь для упрощения фигуры) в отношении масштабируемости, в виде идентификатора рабочей точки ('tier') или ссылки на блоки 'tier'.
Это обеспечивает полезную индикацию модулю синтаксического разбора mp4 для разрешения идентификаторов groupID, которые помещаются в конце записей отображений NALU (так как информация, соответствующая groupID может находиться в любом блоке SampleGroupDescription). Знание информации ref_grouping_type обеспечивает возможность модулю синтаксического разбора просматривать только один блок SampleGroupDescription для получения информации, которая относится к конкретному groupID (просматриваемый блок SampleGroupDescription является блоком, соответствующим значению ref_grouping_type).
Как упомянуто выше, обработка мозаичного элемента и геометрической информации области ROI и идентификационной информации (положение, зависимости, уровни и подобное) в одной и той же структуре (описателе NALUMapEntry), также как индексирование мозаичных элементов и областей ROI (вместо индексирования блоков NAL) является предпочтительным с точки зрения эффективности синтаксического разбора и с точки зрения извлечения областей интереса и мозаичных элементов более быстро.
Фиг. 7, содержащая фиг. 7a и 7b, иллюстрирует пример инкапсуляции мозаичного масштабируемого видеопотока типа HEVC как одиночной дорожки в файл mp4, согласно второму варианту осуществления, обеспечивающему возможность уменьшения объема дублированной информации.
Как проиллюстрировано на фиг. 7a, которая является аналогичной фиг. 6a, предполагается, что видеопоток содержит базовый уровень 700, который может расширяться посредством упомянутых двух независимых пространственных уровней 701 и 702 расширения. Уровень 701 расширения, указываемый как уровень A расширения, содержит мозаичные элементы T1 и T2, и уровень 702 расширения, указываемый как уровень B расширения, содержит мозаичные элементы T1, T2, T3, и T4 (мозаичные элементы T1 и T2 уровня A расширения отличаются от мозаичных элементов T1 и T2 уровня B расширения).
Снова, как показано на фиг. 7b, чтобы инкапсулировать мозаичный масштабируемый видеопоток, кодированный согласно стандарту HEVC, в файл 710 mp4, видеоданные сохраняются в блоке 712 mdat как список выборок, содержащих, в частности, выборку 720. Каждая выборка кодируется как набор одного или более блоков NAL. Как проиллюстрировано, выборка 720 содержит чередующиеся блоки 721 по 727 NAL, соответствующие базовому уровню (блок 721 NAL), мозаичному уровню A расширения (блоки 722 и 723 NAL), и мозаичному уровню B расширения (блоки 724 по 727 NAL).
Однако в противоположность схеме инкапсуляции, описанной посредством ссылки на фиг. 6, где используются несколько блоков NALUMapEntry, схема инкапсуляции основывается, здесь, на одиночном отображении блоков NAL, описанном в блоке 714 NALUMapEntry. Блок 714 NALUMapEntry указывается из блока 713 SampleToGroup, который имеет одну одиночную запись, так как количество блоков NAL в расчете на выборку рассматривается как постоянное от одной выборки к другой. Поэтому, все выборки дорожки отображаются как функция содержимого блока 714 NALUMapEntry.
Следует отметить, что использование идентификатора groupID для обеспечения ссылок для блоков NAL обеспечивает возможность отображать последние либо как функция описания мозаичного элемента, либо как функция описания уровня масштабируемости. Когда уровень масштабируемости содержит мозаичные элементы, блоки NAL сначала отображаются как функция описания мозаичного элемента и далее, как функция описания уровня масштабируемости, при этом информация мозаичного элемента указывает то, из какого уровня он проистекает, как описано посредством ссылки на фиг. 8.
Также следует отметить, что инкапсуляция согласно варианту осуществления, описанному посредством ссылки на фиг. 7, является более компактной, чем инкапсуляция, описанная посредством ссылки на фиг. 6, в том, что требуется одиночное отображение блоков NAL.
Фиг. 8 иллюстрирует пример новых параметров описателя TileRegionGroupEntry, обеспечивающих возможность инкапсуляции мозаичного масштабируемого видеопотока типа HEVC в файл, такой как файл mp4.
Как проиллюстрировано, описатели 800 и 801 TileRegionGroupEntry содержат, в данном примере, параметр 803 dependentGroupID и параметр 804 layerGroupID для доступа к информации масштабируемости и информации зависимости мозаичного элемента или картинки. Согласно данному примеру, информация масштабируемости хранится внутри описателя 802 HEVCLayerDefinitionBox и информация зависимости мозаичного элемента или картинки хранится внутри описателя 801 TileRegionGroupEntry.
Описатель 802 HEVCLayerDefinitionBox иллюстрирует пример параметров описателя HEVCLayerDefinitionBox (или блока HEVCLayerDefinitionBox), содержащего идентификатор, механизм сигнализации зависимости и дополнительные свойства, идущие от элементарного битового видеопотока. Для иллюстрации, дополнительные свойства содержат параметры visualWidth и visualHeight. Однако дополнительные свойства также могут содержать другие параметры, такие как частота кадров, битрейт и информация профиля и уровня. Они также могут содержать высокоуровневую синтаксическую информацию, описывающую уровень масштабируемости.
Новые и модифицированные параметры модифицированного описателя 801 TileRegionGroupEntry могут определяться следующим образом:
- dependentGroupID (ссылочная позиция 803), который задает идентификатор мозаичного элемента (как определяется посредством описателя TileRegionGroupEntry), набора мозаичных элементов (как определяется посредством описателя TileSetGroupEntry), или уровня HEVC (как определяется посредством описателя HEVCLayerDefinitionBox, например, описателя 802 HEVCLayerDefinitionBox), от которого этот мозаичный элемент зависит. Параметр предпочтительно устанавливается на 0, когда зависимости выводятся из блока ссылки на дорожку;
- layerGroupID (ссылочная позиция 804), который задает идентификатор уровня HEVC (как определяется посредством описателя HEVCLayerDefinitionBox), которому этот мозаичный элемент принадлежит. Этот параметр устанавливается на 0, когда зависимости выводятся из блока ссылки на дорожку; и
- region_width и region_height, которые соответственно определяют ширину и высоту прямоугольной области, представляемой мозаичным элементом, в терминах выборок яркости, уровня, идентифицируемого посредством параметра layerGroupID, если его значение отличается от нуля, или кадра, как указано в записи визуальной выборки блока 'stsd', хорошо известного специалистам в данной области техники и содержащегося в блоке 'moov'.
Аналогичные новые и модифицированные параметры также применяются к описателю TileSetGroupEntry при модификации количества битов, используемых для кодирования параметра groupID (так как конфигурации мозаичного размещения и масштабируемости комбинируются, и используется одиночное пространство имен, количество значений для параметра groupID должно увеличиваться).
Другая необходимая адаптация направлена на интерпретацию атрибута dependencyTileGroupID, который может определять идентификатор мозаичного элемента (как определяется посредством описателя TileRegionGroupEntry), набора мозаичных элементов (как определяется посредством описателя TileSetGroupEntry), или уровня HEVC (как определяется посредством описателя HEVCLayerDefinitionBox), от которого этот набор мозаичных элементов зависит. Если значение атрибута dependencyTileGroupID равняется нулю, зависимости выводятся из блока ссылки на дорожку.
Для иллюстрации, параметры нового описателя HEVCLayerDefinitionBox (ссылочная позиция 802) могут определяться следующим образом:
- groupID, который является однозначным идентификатором для уровня, описанного посредством группы. Значение 0 зарезервировано для специального использования в блоке 'nalm';
- dependentGroupID, который указывает идентификатор groupID уровня HEVC (как определяется посредством описателя HEVCLayerDefinitionBox), от которого уровень зависит. Если значение параметра dependentGroupID равняется нулю, зависимости выводятся из блока 'stsd' ссылки на дорожку, упомянутого выше. Это, например, имеет место, когда битовый поток SHVC расширяет дорожку AVC|H264;
- visualWidth, который задает значение ширины кодированной картинки или вида в выборках яркости; и
- visualHeight, который задает значение высоты кодированной картинки или вида в выборках яркости
Преимущество наличия описателя уровня ссылки на мозаичное размещение и наличия описателя уровня, способных ссылаться на описатель либо мозаичного элемента, либо уровня, состоит в том, чтобы обеспечивать унифицированную и гибкую сигнализацию зависимости, все посредством использования идентификаторов groupID. Посредством унификации пространства имен идентификаторов для идентификаторов groupID мозаичных элементов, наборов мозаичных элементов и уровней HEVC, и с введением упомянутых двух идентификаторов зависимости (параметров dependentGroupID и layerGroupID), следующие зависимости просто определяются:
- зависимости между мозаичными уровнями;
- зависимости между немозаичными уровнями;
- зависимости между немозаичным уровнем расширения и мозаичным базовым уровнем; и
- зависимости между мозаичным уровнем расширения и немозаичным базовым уровнем.
Следует отметить, что решения, описанные посредством ссылки на фиг. 6 по 8, являются применимыми в случае, когда уровни или мозаичные элементы хранятся в разных дорожках, как может иметь место для некоторого основанного на DASH решения, если определяется, что пространство имен для идентификаторов groupID является базовым уровнем (например, одно и то же значение groupID не используется в разных дорожках, ссылающихся на одну и ту же базу, при этом помня, что в большинстве случаев, область действия пространства имен groupID ассоциирована с блоком moov, так как только один базовый уровень видеопотока присутствует в обычном файле mp4).
Фиг. 9, содержащая фиг. 9a и 9b, иллюстрирует пример инкапсуляции мозаичного масштабируемого видеопотока типа HEVC как одиночной дорожки в файл mp4, согласно третьему варианту осуществления. Этот вариант осуществления в частности приспособлен для случая, согласно которому количество блоков NAL в расчете на выборку изменяется от одной выборки к другой. Фиг. 10 иллюстрирует описатели мозаичного элемента и масштабируемого уровня, согласно конкретному варианту осуществления, чтобы инкапсулировать битовый поток HEVC.
Как проиллюстрировано на фиг. 9a, которая является аналогичной фиг. 6a и 7a, предполагается, что видеопоток содержит базовый уровень 900, который может расширяться посредством упомянутых двух независимых пространственных уровней 901 и 902 расширения. Уровень 901 расширения, указываемый как уровень A расширения, содержит мозаичные элементы T1 и T2, и уровень 902 расширения, указываемый как уровень B расширения, содержит мозаичные элементы T1, T2, T3, и T4 (мозаичные элементы T1 и T2 уровня A расширения отличаются от мозаичных элементов T1 и T2 уровня B расширения).
Снова, как показано на фиг. 9b, чтобы инкапсулировать мозаичный масштабируемый видеопоток, кодированный согласно стандарту HEVC, в файл 910 mp4, видеоданные сохраняются в блоке 912 mdat как список выборок, содержащих, в частности, выборки 919 и 921. Каждая выборка кодируется как набор одного или более блоков NAL. Количество блоков NAL в расчете на выборку может изменяться.
Как проиллюстрировано, выборка 919 содержит семь чередующихся блоков NAL, соответствующих базовому уровню (один блок NAL), мозаичному уровню A расширения (два блока NAL), и мозаичному уровню B расширения (четыре блока NAL), но выборка 921 содержит девять чередующихся блоков NAL, соответствующих базовому уровню (один блок NAL), мозаичному уровню A расширения (три блока NAL), и мозаичному уровню B расширения (пять блоков NAL). В самом деле, мозаичный элемент T3 уровня B расширения инкапсулируется в одном блоке NAL (ссылочная позиция 920) в выборке 919, в то время как он инкапсулируется в двух блоках NAL (ссылочная позиция 922 и 923 в выборке 921).
Когда количество блоков NAL в расчете на выборку может изменяться, описатель NALUMapEntry, как описано выше, не является подходящим, чтобы описывать выборки и их блоки NAL по отношению к мозаичным элементам и уровням масштабируемости с помощью только одного отображения блоков NAL.
Согласно конкретному варианту осуществления, является возможным использовать агрегаторы mp4, чтобы справляться с таким изменением количества блоков NAL. Однако, так как агрегаторы mp4 являются специальными для формата SVC и/или MVC, они не являются доступными для стандарта HEVC и, в дополнение, это потребует вставки конкретных блоков NAL при формировании блока mdat и перезаписи битового потока при синтаксическом разборе блока mdat, чтобы извлекать элементарный поток. Следует отметить, что может делаться анализ разных шаблонов блоков NAL в выборках, чтобы создавать столько элементов NALUMapEntry, сколько шаблонов блоков NAL существует, но это имеет высокие затраты в отношении описания.
Еще согласно конкретному варианту осуществления, используется устанавливаемое по умолчанию отображение блоков NAL. Такое устанавливаемое по умолчанию отображение блоков NAL может использовать механизм defaultSampleGroup, введенный в Изменении 3 для MPEG-4 Часть-12. Оно может сигнализироваться в описателе 915 NALUMapEntry. Оно предпочтительно выбирается, чтобы соответствовать наиболее общему шаблону блоков NAL. Альтернативно, такое устанавливаемое по умолчанию отображение блоков NAL может соответствовать первому отображению блоков NAL или предварительно определенной конфигурации, как, например, один блок NAL в расчете на мозаичный элемент.
Конкретное значение параметра groupID, например, значение ноль, зарезервировано, чтобы сигнализировать описатель NALUMapEntry, подлежащий использованию в качестве устанавливаемого по умолчанию (описатель 915 NALUMapEntry в примере, проиллюстрированном на фиг. 9).
В дополнение, блок SubSampleInformation, введенный для формата файла HEVC, модифицируется, чтобы вводить новый параметр 'reserved', как проиллюстрировано с помощью ссылочных позиций 1001 и 1002 на фиг. 10, который используется совместно с описателем NALUMapEntry, соответствующим устанавливаемому по умолчанию отображению блоков NAL (то есть, ссылочная позиция 1005).
Соответственно, динамические отображения NALU могут легко определяться, так как блок SubSampleInformation обеспечивает возможность описывать каждую подвыборку или каждую группу подвыборок (ссылочная позиция 1004) выборки или группы выборок (ссылочная позиция 1003), при этом подвыборки соответствуют, здесь блокам NAL.
Посредством перегрузки, например, параметра "flags" блока SubSampleInformation, является возможным определять дополнительный тип подвыборок (после строки CTU, мозаичных элементов, срезов, и других, определенных в ISO/IEC 14496 Часть 15), которые являются основанными на groupID подвыборками.
В таком случае, подвыборка отображается в уровень HEVC, мозаичный элемент, или набор мозаичных элементов, идентифицированный посредством его groupID, как проиллюстрировано с помощью ссылочной позиции 914 на фиг. 9. Если описание группы выборок NALUMapEntry присутствует с устанавливаемым по умолчанию default_sample_description_index, устанавливаемое по умолчанию значение игнорируется (например, описатель SubSampleInformationBox замещает определение, присутствующее в описателе NALUMapEntry). Если значение groupID равняется нулю, никакая группа не ассоциирована с этим NALU.
Если значение параметра groupID равняется нулю, никакая группа не ассоциирована с этим блоком NAL (или группой блоков NAL), что означает, что блок NAL (или группа блоков NAL) ассоциирован с параметром groupID, объявленным для этого блока NAL (или группы блоков NAL) в устанавливаемом по умолчанию описателе NALUMapEntry. Это имеет место, например, для блока 914 'subs' на фиг. 9b, где блоки NAL выборки i (919) следуют устанавливаемому по умолчанию отображению, в то время как для выборки j (921) обеспечивается явное отображение.
Эта комбинация обеспечивает простой способ, чтобы описывать временные модификации устанавливаемого по умолчанию шаблона NALU, который регулярно используется. Такое описание обеспечивает возможность модулю синтаксического разбора легко строить отображение между группами блоков NAL и их положением в блоке mdat, так как блок SubSampleInformationBox обеспечивает размер в байтах подвыборки (блока NAL) или группы подвыборок (группы блоков NAL). Это обеспечивает извлечение данных согласно заданному критерию, например, данных, принадлежащих пространственной области или заданному уровню.
Фиг. 11, содержащая фиг. 11a и фиг. 11b, является блок-схемой последовательности операций, иллюстрирующей этапы для передачи данных мультимедиа с временной привязкой между сервером и клиентским устройством согласно конкретному варианту осуществления. Этапы, показанные на фиг. 11a, осуществляются внутри сервера, чтобы подготавливать представление мультимедиа посредством создания файлов сегментов, приспособленных для потоковой передачи ROI, из битового потока мозаичных данных мультимедиа с временной привязкой, в то время как этапы, показанные на фиг. 11b, осуществляются внутри клиентского устройства.
На первом этапе (этап 1100), видеопоток сжимается в масштабируемое видео с одним или более уровнями, особенно в высоком разрешении, содержащими мозаичные элементы. На последующем этапе (этап 1102), сервер идентифицирует все блоки NAL, которые ассоциированы с мозаичными элементами и, для каждого мозаичного элемента, создает описатель мозаичного элемента, содержащий подвыборки, составленные из всех блоков NAL, соответствующих заданному мозаичному элементу. При этом, он ассоциирует описатель уровня масштабируемости с каждым мозаичным элементом. В случае немозаичного уровня, с блоками NAL ассоциируется только описатель уровня масштабируемости. Например, сервер может полагаться на сообщения SEI уровня под-картинки, чтобы идентифицировать ассоциацию блоков NAL с разными областями, и на сообщения SEI уровня последовательности для идентификации положения и размера каждой ROI, как было предложено в стандартизации HEVC (предложение JCTVC-K0128).
Далее, на этапе 1104, сервер генерирует и сохраняет файл сегмента инициализации и файлы сегментов мультимедиа, содержащие временной период, согласно представлению ISO BMFF, как описано со ссылкой на фиг. 3 и 6. Все дорожки данных мультимедиа с временной привязкой (например, дорожки видео) сохраняются в отдельных файлах сегментов мультимедиа (временно сегментированных).
Сервер затем обеспечивает, при запросе, файлы инициализации и сегментов мультимедиа в клиентское устройство (этап 1106). Сервер может быть стандартным сервером HTTP, который отвечает на запросы HTTP.
В контексте потоковой передачи HTTP и в одном предпочтительном варианте осуществления, предполагается, что клиентское устройство имеет доступ к файлу манифеста, описывающему представление мультимедиа, доступное от сервера. Этот файл манифеста обеспечивает достаточную информацию (свойства мультимедиа и список сегментов) для клиентского устройства для потоковой передачи представления мультимедиа посредством сначала запроса сегментов инициализации и затем файлов сегментов мультимедиа от сервера.
При выборе ROI на конце клиентского устройства, обычно на устройстве отображения, с помощью средства выбора, такого как указывающее устройство, во время потоковой передачи мозаичного видео, определяются мозаичные элементы, соответствующие выбранной ROI (этап 1108 на фиг. 11b).
Далее, для каждого временного периода, в случае масштабируемых мультимедийных данных, клиентское устройство посылает запрос в сервер, чтобы загружать файлы сегментов, соответствующие зависимым уровням (этап 1110). Согласно конкретному варианту осуществления, уровни, от которых имеется зависимость, загружаются перед уровнями, которые зависят от уровней, от которых имеется зависимость. Например, файлы сегментов базового уровня загружаются перед файлами сегментов уровня расширения.
На последующем этапе, клиентское устройство посылает в сервер запрос, чтобы загружать файлы сегментов мультимедиа, соответствующие выбранным мозаичным элементам (этап 1112).
Далее, загруженные файлы сегментов конкатенируются клиентским устройством, чтобы построить действительный (декодируемый) битовый поток данных мультимедиа с временной привязкой, соответствующий стандарту ISO BMFF (этап 1114), соответствующий выбранной ROI.
Фиг. 12 представляет блок-схему сервера или клиентского устройства 1200, в которых могут осуществляться этапы одного или более вариантов осуществления.
Предпочтительно, устройство 1200 содержит шину 1202 передачи данных, центральное обрабатывающее устройство (CPU) 1204, выполненное с возможностью исполнения инструкций из программного ROM 1206 при включении устройства, и инструкций, относящихся к программному приложению из основной памяти 1208, после включения. Основная память 1208 является, например, типом оперативного запоминающего устройства (RAM), который функционирует как рабочая область CPU 1204 посредством шины 1202 передачи данных, и ее объем памяти может расширяться посредством необязательного RAM, соединенного с портом расширения (не проиллюстрирован). Инструкции, относящиеся к программному приложению, могут загружаться в основную память 1208 из жесткого диска (HD) 1210 или программного ROM 1206, например. Такое программное приложение, когда исполняется посредством CPU 1204, предписывает выполнение этапов, описанных со ссылкой на фиг. 11a, в сервере и выполнение этапов, описанных со ссылкой на фиг. 11b, в клиентском устройстве.
Ссылочная позиция 1212 является сетевым интерфейсом, который обеспечивает возможность соединения устройства 1200 с сетью 1214 связи. Программное приложение, когда исполняется посредством CPU 1204, выполнено с возможностью реагировать на запросы, принимаемые посредством сетевого интерфейса, и обеспечивать потоки данных и запросы через сеть в другие устройства.
Ссылочная позиция 1216 представляет пользовательские интерфейсы для отображения информации для, и/или приема вводов от, пользователя.
Следует отметить здесь, что, как вариант, устройство 1200 для управления приемом или отправкой битовых потоков мультимедиа может состоять из одной или более выделенных интегральных схем (ASIC), которые выполнены с возможностью осуществления способа, как описано со ссылкой на фиг. 11a и 11b. Эти интегральные схемы, например, и не ограничительно, интегрированы в устройство для генерирования или отображения видеопоследовательностей и/или для прослушивания аудио последовательностей.
Как описано выше, один вариант осуществления изобретения может применяться, в частности, к формату видео, известному как HEVC.
Согласно стандарту HEVC, изображения могут пространственно разделяться на мозаичные элементы, срезы, и сегменты срезов. В этом стандарте, мозаичный элемент соответствует прямоугольной области изображения, которая определяется посредством горизонтальной и вертикальной границ (то есть, строк и столбцов). Он содержит целое число блоков дерева кодирования (Coding Tree Unit, CTU). Поэтому, мозаичные элементы могут эффективно использоваться, чтобы идентифицировать области интереса посредством определения, например, положений и размеров для областей интереса. Однако структура битового потока HEVC также как его инкапсуляция в виде блоков уровня сетевой абстракции (NAL) не организованы с учетом мозаичных элементов, но основываются на срезах.
В стандарте HEVC, срезы являются наборами сегментов среза, при этом первый сегмент среза из набора сегментов среза является независимым сегментом среза, то есть, можно сказать сегментом среза, таким, что общая информация, сохраненная внутри заголовка, не ссылается какой-либо другой сегмент среза. Другие сегменты среза из набора сегментов среза, если есть какие-либо, являются зависимыми сегментами среза (то есть, сегментами среза, такими, что общая информация, сохраненная внутри заголовка, ссылается на какой-либо независимый сегмент среза).
Сегмент среза содержит целое число последовательных (в порядке растрового сканирования) блоков дерева кодирования. Поэтому, сегмент среза может быть прямоугольной формы или нет, и, таким образом, он не подходит для представления области интереса. Он кодируется в битовом потоке HEVC под формой заголовка сегмента среза, за которым следуют данные сегмента среза.
Независимые и зависимые сегменты среза отличаются их заголовком: так как зависимый сегмент среза зависит от независимого сегмента среза, объем информации его заголовка является более малым, чем объем информации независимого сегмента среза. Как независимые, так и зависимые сегменты среза содержат список точек входа в соответствующем битовом потоке, которые используются, чтобы определять мозаичные элементы, или как точки синхронизации энтропийного декодирования.
Фиг. 13, содержащая фиг. 13a, 13b, и 13c, иллюстрирует примеры мозаичных элементов и сегментов срезов. Более точно, фиг. 13a иллюстрирует изображение (1300), разделенное на девять частей посредством вертикальных границ 1305-1 и 1305-2 и горизонтальных границ 1310-1 и 1310-2. Каждая из девяти частей, указанных как 1315-1 по 1315-9, представляет конкретный мозаичный элемент.
Фиг. 13b иллюстрирует изображение (1300'), содержащее два вертикальных мозаичных элемента, разделенных посредством вертикальной границы 1305'. Изображение 1300' содержит одиночный срез (не указан), содержащий пять сегментов среза, один независимый сегмент 1320-1 среза (представленный с помощью штрихованных линий) и четыре зависимых сегмента 1320-2 по 1320-5 среза.
Фиг. 13c иллюстрирует изображение (1300''), содержащее два вертикальных мозаичных элемента, разделенных посредством вертикальной границы 1305''. Левый мозаичный элемент содержит два среза: первый срез, содержащий один независимый сегмент (1320'-1) среза и один зависимый сегмент (1320'-2) среза, и второй срез, также содержащий один независимый сегмент (1320'-3) среза и один зависимый сегмент (1320'-4) среза. Правый мозаичный элемент содержит один срез, содержащий один независимый сегмент (1320'-5) среза и один зависимый сегмент (1320'-6) среза.
Согласно стандарту HEVC, сегменты срезов связаны с мозаичными элементами согласно правилам, которые могут резюмироваться следующим образом (должны выполняться одно или оба условия):
- все блоки CTU в сегменте среза принадлежат одному и тому же мозаичному элементу (то есть, сегмент среза не может принадлежать нескольким мозаичным элементам); и
- все блоки CTU в мозаичном элементе принадлежат одному и тому же сегменту среза (то есть, мозаичный элемент может разделяться на несколько сегментов среза при условии, что каждый из этих сегментов среза принадлежит только этому мозаичному элементу).
Для ясности, в последующем предполагается, что один мозаичный элемент содержит один срез, имеющий только один независимый сегмент среза. Однако варианты осуществления изобретения могут выполняться с другими конфигурациями, как, например, конфигурациями, проиллюстрированными на фиг. 13b и 13c.
Как упомянуто выше, в то время как мозаичные элементы могут рассматриваться как надлежащая поддержка для областей интереса, сегменты срезов являются сущностями, которые фактически помещаются в блоках NAL для транспортировки по сети связи и агрегируются, чтобы формировать блоки доступа (то есть, кодированную картинку или выборки на уровне формата файла).
Следует напомнить, что согласно стандарту HEVC, тип блока NAL кодируется в двух байтах заголовка блока NAL, который может определяться следующим образом:
Блоки NAL, используемые, чтобы кодировать сегменты срезов, содержат заголовки сегментов срезов, указывающие адрес первого CTU в сегменте среза, благодаря элементу синтаксиса адреса сегмента среза. Такие заголовки сегмента среза могут определяться следующим образом:
Информация мозаичного размещения обеспечивается в блоке NAL PPS (набора параметров картинок). Отношение между сегментом среза и мозаичным элементом может, в таком случае, выводиться из этих параметров.
В то время как пространственные предсказания переустанавливаются на границах мозаичных элементов (по определению), ничто не препятствует мозаичному элементу использовать временные предсказатели от другого мозаичного элемента в опорном кадре (кадрах). Соответственно, чтобы строить независимые мозаичные элементы, векторы движения для блоков предсказания предпочтительно заключаются внутри мозаичного элемента, во время кодирования, чтобы оставаться в совместно расположенном мозаичном элементе в опорном кадре (кадрах). В дополнение, внутриконтурные фильтры (фильтры удаления блочности и адаптивного смещения выборок (SAO)) предпочтительно деактивируются на границах мозаичных элементов, чтобы никакой дрейф ошибок не вводился при декодировании только одного мозаичного элемента. Следует отметить, что такое управление внутриконтурными фильтрами является доступным в стандарте HEVC. Оно устанавливается в заголовке сегмента среза с помощью флага, известного как loop_filter_across_tiles_enabled_flag. Посредством явной установки этого флага на ноль, пиксели на границах мозаичного элемента не могут зависеть от пикселей, которые попадают на границу соседних мозаичных элементов. Когда эти два условия, относящиеся к векторам движения и к внутриконтурным фильтрам, удовлетворяются, мозаичные элементы могут рассматриваться как "независимо декодируемые мозаичные элементы" или "независимые мозаичные элементы".
Когда битовый видеопоток кодируется как набор независимых мозаичных элементов, это, в таком случае, обеспечивает возможность основанного на мозаичных элементах декодирования от одного кадра к другому без какого-либо риска отсутствия опорных данных или распространения ошибок восстановления. Эта конфигурация, в таком случае, обеспечивает возможность восстанавливать только пространственную часть исходного видео, которая может соответствовать, например, области интереса, проиллюстрированной на фиг. 2 (содержащей мозаичные элементы 3 и 7). Такая конфигурация может указываться как дополнительная информация в битовом видеопотоке, чтобы указывать, что основанное на мозаичных элементах декодирование является надежным.
Согласно одному варианту осуществления изобретения, эффективный доступ к мозаичным элементам в контексте потоковой передачи HTTP обеспечивается посредством использования формата файла ISO BMFF, применяемого к стандарту HEVC. Соответственно, каждый из независимых мозаичных элементов, подлежащих кодированию, (например, каждый из двенадцати мозаичных элементов, представленных на фиг. 2) инкапсулируется с ассоциированным описателем, называемым "TileRegionGroupEntry", как описано ниже посредством ссылки на фиг. 6.
Как описано выше, файл сегмента инициализации используется, чтобы передавать все метаданные, которые являются необходимыми, чтобы определять битовые потоки данных мультимедиа с временной привязкой, инкапсулированные в других файлах сегментов мультимедиа. Файл сегмента инициализации содержит блок 'ftyp' типа файла и блок 'moov' фильма. Блок типа файла предпочтительно идентифицирует то, с какими спецификациями ISO BMF файлы сегментов находятся в соответствии, и указывает номер версии этой спецификации. Блок 'moov' фильма обеспечивает все метаданные, описывающие представление, сохраненное в файлах сегментов мультимедиа, и, в частности, все дорожки, доступные в представлении.
Блок фильма содержит определение для каждой из дорожек (блоки 'trak').
Каждый блок дорожки содержит, по меньшей мере, блок 'tkhd' заголовка дорожки и блок 'mdia' мультимедийных данных дорожки. Если дорожка зависит от данных из других дорожек, имеется также блок 'tref' ссылки на дорожку.
Как упомянуто выше, следует отметить, что другие блоки могут быть обязательными или необязательными в зависимости от спецификаций ISO BMFF, используемых, чтобы инкапсулировать битовый поток данных мультимедиа с временной привязкой. Однако, так как варианты осуществления изобретения не полагаются на то, чтобы эти блоки были применимыми, они здесь не представлены.
Согласно варианту осуществления, описанному посредством ссылки на фиг. 6, сигнализация положения мозаичного элемента в полном видео, размера мозаичного элемента, и индикации, что дорожка с мозаичными элементами может декодироваться без какого-либо артефакта, делается один раз для всего битового потока HEVC, подлежащего инкапсуляции, в блоке (611) 'moov', в каждом определении дорожки, с использованием блока 'tkhd' заголовка дорожки (не представлен) и блоков блока 'mdia' информации мультимедиа (не представлен).
Согласно конкретному варианту осуществления, который выполнен с возможностью обрабатывать изменение в конфигурации мозаичного размещения вместе с видеопоследовательностью, сигнализация мозаичных элементов делается на уровне выборок, с использованием механизмов группирования выборок из стандарта ISO BMFF.
Такие механизмы группирования выборок используются для представления разделений выборок в дорожках. Они полагаются на использование двух блоков: блока SampleToGroup ('sbgp'), который описывает назначение выборок группам выборок, и блока SampleGroupDescription ('sgpd'), который описывает общие свойства выборок внутри конкретной группы выборок. Конкретный тип группирования выборок определяется посредством комбинации одного блока SampleToGroup и одного блока SampleGroupDescription посредством поля типа ('grouping_type'). Множество экземпляров группирований выборок (то есть, пар блоков SampleToGroup и SampleGroupDescription) могут существовать на основе разных критериев группирования.
Согласно конкретным вариантам осуществления, определен критерий группирования, относящийся к мозаичному размещению выборок. Этот grouping_type, называемый 'tile' ('мозаичный элемент'), описывает свойства мозаичного элемента и выводится из стандартного VisualSampleGroupEntry. Он может указываться как TileRegionGroupEntry и определяется следующим образом:
Согласно этому новому типу записи группы, параметр groupID является однозначным идентификатором для мозаичного элемента, описанного посредством группы. Параметры horizontal_offset и vertical_offset используются, чтобы устанавливать горизонтальное и вертикальное смещение, соответственно, верхнего левого пикселя прямоугольной области, представленной мозаичным элементом, по отношению к верхнему левому пикселю кадра HEVC, в выборках яркости базовой области. Параметры region_width и region_height используются, чтобы устанавливать ширину и высоту, соответственно, прямоугольной области, представленной посредством мозаичного элемента, в выборках яркости кадра HEVC. Параметр independent является 2-битным словом, которое определяет, что мозаичный элемент содержит зависимости декодирования, относящиеся к выборкам, принадлежащим только к тому же мозаичному элементу, как описано выше посредством ссылки на определение независимых мозаичных элементов. Для иллюстрации и со ссылкой на стандартное использование сообщений SEI для описания организации мозаичных элементов, может использоваться флаг, известный как tile_section_exact_match_flag, чтобы устанавливать значение флага independent. Смысл последнего может устанавливаться следующим образом:
- если параметр independent равняется 0, зависимости кодирования между этим мозаичным элементом и другими мозаичными элементами в том же кадре или в предыдущих кадрах являются неизвестными;
- если параметр independent равняется 1, не имеется никаких пространственных зависимостей кодирования между этим мозаичным элементом и другими мозаичными элементами в том же кадре, но могут иметься зависимости кодирования между этим мозаичным элементом и мозаичным элементом, имеющим такой же tileID, в предыдущих кадрах, и
- если параметр independent равняется 2, не имеется никаких зависимостей кодирования между этим мозаичным элементом и другими мозаичными элементами, имеющими такой же tileID, в том же кадре или в предыдущих кадрах;
значение 3 параметра independent зарезервировано.
Необязательно, параметр, описывающий средний битрейт в расчете на мозаичный элемент может устанавливаться в описателе мозаичного элемента, чтобы обеспечиваться клиенту потоковой передачи для адаптации на основе полосы пропускания.
Согласно одному варианту осуществления, свойства каждого мозаичного элемента задаются один раз в заголовке фильма (блоке 'moov') посредством определения, для каждой дорожки с мозаичными элементами, одного блока SampleGroupDescription ('sgpd') с 'trif' grouping_type и TileRegionGroupEntry. В таком случае, согласно стандарту ISO BMFF, блок SampleToGroup определяется в каждом фрагменте дорожки с мозаичными элементами, чтобы ассоциировать каждую выборку фрагмента дорожки с мозаичными элементами с ее свойствами, так как количество выборок не известно заранее.
Фиг. 14, содержащая фиг. 14a и фиг. 14b, иллюстрирует пример сигнализации положения мозаичного элемента в полном видео, размера мозаичного элемента, и индикации, что дорожка с мозаичными элементами может декодироваться без какого-либо артефакта, на уровне подвыборок, адаптированной, чтобы обрабатывать различные конфигурации мозаичного размещения.
Фиг. 14a иллюстрирует этапы, выполняемые клиентским устройством (например, проигрывателем видео), в то время как фиг. 14b иллюстрирует пример файла, содержащего одиночную дорожку, в которой инкапсулирован мозаичный масштабируемый видеопоток типа HEVC. Более точно, фиг. 14b иллюстрирует пример описания мозаичного размещения.
На первом этапе (этап 1400), клиентское устройство загружает данные инициализации или считывает данные инициализации, если файл является локальным файлом, например, данные инициализации инкапсулированного битового потока, соответствующего стандарту MPEG-4, обычно содержимое блока moov.
Из этих данных инициализации, клиентское устройство может осуществлять синтаксический разбор информации дорожки, содержащейся в блоке trak, в частности, блоке таблицы выборок, где кодированы информация выборок и описание (этап 1405). Далее, на этапе 1410, клиентское устройство строит список всех доступных блоков описания выборок (например, блоков 1470 и 1475 описания выборок на фиг. 14b). Как результат, клиентское устройство владеет полным списком идентификаторов groupID, на которые осуществляется ссылка из описателя NALUMapEntry (например, блока 1470 NALUMapEntry).
Поэтому, описания выборок обеспечивают возможность клиентскому устройству, для конкретного случая мозаичного и масштабируемого видео, определять то, какие блоки NAL должны загружаться (в случае использования передачи) или извлекаться (в случае локального файла), чтобы воспроизводить конкретную область интереса в заданном разрешении или качестве. Выбор мозаичных элементов и уровня может делаться посредством графического интерфейса клиентского устройства (этап 1415), которое воспроизводит информацию описания мозаичных элементов и масштабируемости. Может выбираться один или более уровней мозаичных элементов или/и масштабируемости.
Следует отметить, что за этапом 1410 синтаксического разбора может следовать необязательный этап индексации, выполняемый во внутренней структуре данных, чтобы ассоциировать список байтового диапазона с каждой соответствующей конфигурацией (мозаичным элементом, уровнем, выборкой) в блоке mdat (например, ссылочная позиция 1460). Построение такой внутренней структуры данных обеспечивает возможность внутреннему клиентскому устройству более быстро загружать или извлекать данные для заданной конфигурации (мозаичного элемента, уровня, выборки). Этот необязательный этап синтаксического разбора также может делаться на стороне сервера, когда сжатые видеоданные инкапсулируются. Это может затем использоваться, чтобы информировать о байтовых диапазонах, чтобы загружать мозаичные элементы или специальный уровень и для того, чтобы сервер осуществлял более быстрое извлечение заданной конфигурации (мозаичного элемента, уровня, выборки).
Далее, данные загружаются или считываются клиентским устройством (этапы 1420) и извлеченные или принятые данные (выборки из блока 1460 mdat) обеспечиваются в видеодекодер для отображения (этап 1425).
Как проиллюстрировано на фиг. 14b, описание 1450 мозаичного размещения содержит блок "moov" 1455 фильма и блок 'mdat' 1460 данных. Блок 1455 содержит один блок SampleTable в расчете на дорожку, который содержит блок 1465 SampleToGroup, который описывает разные группы выборок, блок 1470 описания группы выборок, который описывает отображение между блоками NAL каждой выборки и мозаичными элементами, и блок 1475 описания группы выборок, который содержит описания мозаичных элементов. Блок 1465 "выборка в группу" указывает тип группирования 'nalm' для описателя NALUMapEntry записи группы.
Фиг. 15, содержащая фиг. 15a и 15b, иллюстрирует пример инкапсуляции мозаичных элементов в множестве дорожек, для эффективной адресации данных.
Фиг. 15a иллюстрирует пример конфигурации мозаичных элементов. Для иллюстрации, она содержит четыре мозаичных элемента (мозаичный элемент 1 по мозаичный элемент 4), размер каждого мозаичного элемента равняется 310 пикселей в ширину и 256 пикселей в высоту.
Как проиллюстрировано на фиг. 15b, каждый мозаичный элемент инкапсулирован в своей собственной дорожке, что ведет к инкапсуляции видео в виде 5 дорожек: четыре дорожки с мозаичными элементами, указанные как 1501, 1502, 1503, и 1504, для инкапсуляции каждого мозаичного элемента и одна дорожка 1510 набора параметров, общая для всех дорожек с мозаичными элементами.
Дорожка с мозаичными элементами HEVC является дорожкой видео, для которой имеется либо ссылка 'dond' (зависимости порядка декодирования) на дорожку из базового уровня HEVC или ссылка 'sbas' на уровень HEVC.
Описание каждой дорожки (1501, 1502, 1503, и 1504) с мозаичными элементами основывается на блоке TileRegionGroupEntry (идентифицированном посредством ссылки 'trif'), таком как блок 1506 TileRegionGroupEntry.
Здесь, блоки 'trif' используют устанавливаемый по умолчанию механизм группирования выборок (с атрибутом def_sample_descr_index=1), чтобы указывать, что все выборки дорожки имеют одно и то же описание мозаичного элемента. Например, блоки 1521 NAL, соответствующие мозаичному элементу 1, описываются в дорожке 1 (указанной как 1501) в блоке 1506 TileRegionGroupEntry.
Здесь не имеется необходимости в описателе NALUMapEntry, так как все выборки в заданной дорожке отображаются в мозаичный элемент, описанный посредством этой дорожки. Ссылочные позиции 1521 и 1522 обозначают, соответственно, порции данных, которые содержат данные для мозаичного элемента 1 и мозаичного элемента 4 от момента времени 1 до момента времени S (продолжительность мультимедийного файла или сегмента мультимедиа в случае фрагментов дорожек).
Фактически выборки дорожки не являются классическими выборками видео, так как в этом варианте осуществления, они являются выборками мозаичных элементов: выборка, сохраненная в дорожке с мозаичными элементами, является полным набором срезов для одного или более мозаичных элементов, как определено в ISO/IEC 23008-2 (HEVC). Выборка HEVC, сохраненная в дорожке с мозаичными элементами, рассматривается как синхронизованная выборка, если блоки NAL VCL в выборке указывают, что кодированные срезы, содержащиеся в выборке, являются срезами мгновенного обновления декодирования (IDR), срезами чистого произвольного доступа (CRA), или срезами доступа с прерванной связью (BLA). Как таковые, они не имеют таких же размеров, как имеют классические выборки: согласно примеру из фиг. 15a, классические выборки HEVC имеют размер, равный 640×512 пикселей, в то время как здесь, выборки HEVC, сохраненные в каждой дорожке с мозаичными элементами, имеют размер, равный 320×256 пикселей. Чтобы избегать неоднозначности во время синтаксического разбора, выборки мозаичных элементов сигнализируются с новым типом описателя VisualSampleEntry: описателем HEVCTileSampleEntry, таким как описатель 1505 HEVCTileSampleEntry, ассоциированный с дорожкой 1 (обозначенный с помощью 4-х буквенного кода 'hvt1').
Следует отметить, что для TileSetGroupEntry, описание в независимой дорожке, элементы HEVCTileSampleEntry, также может использоваться. В этом случае, размер выборок будет размером ограничивающего блока набора мозаичных элементов.
В дополнение к информации размера, любая релевантная информация для описания выборки может помещаться в этом HEVCTileSampleEntry как необязательные элементы extra_box.
Формально, записи выборок дорожек видео HEVC являются элементами HEVCSampleEntry, объявленными в блоке описания выборок каждого заголовка дорожки. Здесь, так как используется множество дорожек, представляющих один и тот же видеопоток, каждая дорожка с мозаичными элементами содержит индикацию, согласно которой выборки в дорожке являются фактически выборками подчасти полного видеопотока, что указывает, что эти выборки являются HEVCTileSampleEntry (каждый блок 'hvt1' в блоке 'stsd' описания выборок каждой дорожки).
Для типа 'hvt1' описания выборок, ни выборки в дорожке с мозаичными элементами, ни блок описания выборок не должны содержать блоки NAL PS, SPS или PPS, эти блоки NAL должны находиться в выборках или в блоке описания выборок дорожки, содержащей базовый уровень (как идентифицируется посредством ссылок на дорожку) в случае масштабируемости или в выделенной дорожке, такой как выделенная дорожка 1510 на фиг. 15b.
Группирование подвыборок и выборок, определенное для обычных выборок HEVC, имеет такие же определения для выборки мозаичных элементов HEVC. Зависимости между дорожкой 1510 набора параметров и дорожками с мозаичными элементами описываются посредством зависимостей 'dond' порядка декодирования, указанных как 1511. Рекомендуется использовать ссылки 'dond' на дорожку, так как они обеспечивают информацию порядка, которая может использоваться, чтобы восстанавливать исходный битовый поток без синтаксического разбора заголовков срезов, чтобы получать порядок мозаичных элементов (здесь, 1, 2, 3, и 4).
Когда мозаичные элементы видео HEVC хранятся в разных дорожках, могут иметься случаи, когда никакие выборки не существуют в базовом уровне. То, как и выполняется ли повторная компоновка выборок мозаичных элементов, чтобы формировать совместимый битовый поток HEVC, оставляется реализации.
Естественно, чтобы удовлетворять локальным и специальным требованиям, специалист в данной области техники может применять к решению, описанному выше, множество модификаций и изменений все из которых, однако, содержатся в объеме защиты изобретения, как определено посредством последующей формулы изобретения.
Изобретение относится к области инкапсуляции данных мультимедиа с временной привязкой, например, согласно базовому формату мультимедийного файла организации по стандартизации (ISO BMFF), чтобы улучшать потоковую передачу по протоколу передачи гипертекстовых файлов (HTTP), выбираемых пользователем интересующих областей (ROI) в сжатых видеопотоках. Технический результат заключается в обеспечении схемы организации данных и описания дорожек, подходящей для пространственных мозаичных элементов в масштабируемых видеопотоках, которая обеспечивает, что какая бы комбинация дорожек ни выбиралась клиентским приложением, результат синтаксического разбора формата ISO BMFF всегда ведет к действительному элементарному битовому видеопотоку для видеодекодера. Указанный технический результат достигается тем, что каждая выборка с временной привязкой содержит первый уровень и, по меньшей мере, один второй уровень, и, по меньшей мере, один из уровней содержит множество подвыборок, представленных посредством одного или более блоков кодирования. После получения, по меньшей мере, одной подвыборки из множества подвыборок одной из выборок с временной привязкой создается одна дорожка, содержащая упомянутую, по меньшей мере, одну полученную подвыборку. Далее, созданная дорожка независимо инкапсулируется в, по меньшей мере, одном файле сегмента мультимедиа, при этом упомянутый файл сегмента мультимедиа содержит метаданные отображения для обеспечения информации об упомянутой, по меньшей мере, одной полученной подвыборке по отношению к упомянутой одной из выборок с временной привязкой и уровню, которому она принадлежит. 3 н. и 12 з.п. ф-лы. 26 ил.
1. Способ генерирования мультимедийного файла на основе данных мультимедиа, включающих одну или более выборок, каждая из которых содержит множество мозаичных областей, при этом способ содержит:
этап генерирования дорожки для генерирования множества дорожек, каждая из которых содержит данные мультимедиа, соответствующие по меньшей мере одной мозаичной области из множества мозаичных областей, соответствующих одной выборке;
этап генерирования файла для генерирования одного или более мультимедийных файлов, включающих все из
(i) множества дорожек, каждая из которых содержит данные мультимедиа, соответствующие по меньшей мере одной мозаичной области;
(ii) множества первых блоков, содержащих метаданные для описания соответствующей дорожки из множества дорожек; и
(iii) второго блока, содержащего метаданные для описания общих данных множества дорожек,
при этом каждый из первых блоков содержит 4-х буквенный код, который представляет собой мозаичную дорожку HEVC (высокоэффективного кодирования видео) в качестве входной выборки для дорожки,
второй блок не содержит 4-х буквенный код, и
метаданные по меньшей мере в одном из множества первых блоков и метаданные во втором блоке относятся к декодеру для декодирования данных мультимедиа, содержащихся по меньшей мере в одной дорожке.
2. Способ по п.1, в котором данные мультимедиа каждой из множества мозаичных областей кодированы на основе HEVC (High Efficiency Video Coding, высокоэффективное кодирование видео).
3. Способ по п.1, в котором выборка является изображением и данные мультимедиа являются видеоданными.
4. Способ по п.1, в котором ширина и высота соответствующей мозаичной области затем описываются в каждом из множества первых блоков.
5. Способ по п.4, в котором ширина и высота всей выборки затем описывается во втором блоке.
6. Способ по п.1, в котором пространственный сдвиг соответствующей мозаичной области затем описывается в каждом из множества первых блоков.
7. Способ по п.1, в котором упомянутый 4-х буквенный код является буквенным кодом «hvt1».
8. Устройство для генерирования мультимедийного файла на основе данных мультимедиа, включающих одну или более выборок, каждая из которых содержит множество мозаичных областей, при этом устройство содержит:
блок генерирования дорожки, сконфигурированный для генерирования множества дорожек, каждая из которых содержит данные мультимедиа, соответствующие по меньшей мере одной мозаичной области из множества мозаичных областей, соответствующих одной выборке;
блок генерирования файла, сконфигурированный для генерирования мультимедийного файла, включающего все из:
(i) множества дорожек, каждая из которых содержит данные мультимедиа, соответствующие по меньшей мере одной мозаичной области;
(ii) множества первых блоков для описания метаданных соответствующей дорожки из множества дорожек; и
(iii) второго блока для описания общих метаданных для множества дорожек,
при этом каждый из первых блоков содержит 4-х буквенный код, который представляет собой мозаичную дорожку HEVC (высокоэффективного кодирования видео) в качестве входной выборки для дорожки,
второй блок не содержит 4-х буквенный код,
метаданные по меньшей мере в одном из множества первых блоков и метаданные во втором блоке относятся к декодеру для декодирования данных мультимедиа, содержащихся по меньшей мере в одной дорожке.
9. Устройство по п.8, в котором данные мультимедиа каждой из множества мозаичных областей кодированы на основе HEVC (High Efficiency Video Coding, высокоэффективное кодирование видео).
10. Устройство по п.8, в котором выборка является изображением и данные мультимедиа являются видеоданными.
11. Устройство по п.8, в котором ширина и высота соответствующей мозаичной области затем описываются в каждом из множества первых блоков.
12. Устройство по п.11, в котором ширина и высота всей выборки затем описываются во втором блоке.
13. Устройство по п.8, в котором пространственный сдвиг соответствующей мозаичной области затем описывается в каждом из множества первых блоков.
14. Устройство по п.8, в котором 4-х буквенный код является буквенным кодом «hvt1».
15. Машиночитаемый носитель, на котором сохранена программа, предписывающая компьютеру выполнять этапы способа генерирования мультимедийного файла на основе данных мультимедиа, включающих одну или более выборок, каждая из которых содержит множество мозаичных областей, при этом способ содержит:
этап генерирования дорожки для генерирования множества дорожек, каждая из которых содержит данные мультимедиа, соответствующие по меньшей мере одной мозаичной области из множества мозаичных областей, соответствующих одной выборке;
этап генерирования файла для генерирования мультимедийного файла, включающего все из
(i) множества дорожек, каждая из которых содержит данные мультимедиа, соответствующие по меньшей мере одной мозаичной области;
(ii) множества первых блоков для описания метаданных соответствующей дорожки из множества дорожек; и
(iii) второго блока для описания общих метаданных множества дорожек,
при этом каждый из первых блоков содержит 4-х буквенный код, который представляет собой мозаичную дорожку HEVC (высокоэффективного кодирования видео) в качестве входной выборки для дорожки,
второй блок не содержит указанный 4-х буквенный код, и
метаданные по меньшей мере в одном из множества первых блоков и метаданные во втором блоке относятся к декодеру для декодирования данных мультимедиа, содержащихся по меньшей мере в одной дорожке.
| Support for efficient tile access in the HEVC File Format, ISO/IEC JTC1/SC29/WG11 MPEG2012/M29231, Incheon, April 2013 | |||
| WO 2008007304 A2, 2008-01-17 | |||
| US 2008225116 A1, 2008-09-18 | |||
| WO 2012168365 A1, 2012-12-13 | |||
| ПЕРЕДАЧА СООБЩЕНИЙ ДОПОЛНИТЕЛЬНОЙ РАСШИРЕННОЙ ИНФОРМАЦИИ В ФОРМАТЕ ПОЛЕЗНОЙ НАГРУЗКИ ТРАНСПОРТНОГО ПРОТОКОЛА РЕАЛЬНОГО ВРЕМЕНИ | 2008 |
|
RU2430483C2 |
