Область техники, к которой относится изобретение
Изобретение, в общем, относится к области техники инкапсуляции синхронизированных мультимедийных данных, например, согласно базовому формату мультимедийных файлов, заданному посредством организации по стандартизации MPEG, чтобы улучшать доставку потока, в частности, относительно потоковой передачи по HTTP (протоколу передачи гипертекста) выбираемых пользователем интересующих областей в сжатых видеопотоках. Более конкретно изобретение относится к способу, устройству и компьютерной программе для инкапсуляции элементарного потока, содержащего сегментированные данные, к примеру, пространственные мозаичные фрагменты, обеспечивающим эффективную потоковую передачу данных, в частности, одного или более мозаичных фрагментов.
Уровень техники
Кодирование видео представляет собой способ преобразования последовательности видеоизображений в компактный оцифрованный поток битов, так что видеоизображения могут передаваться или сохраняться. Устройство кодирования используется для того, чтобы кодировать видеоизображения, при этом ассоциированное устройство декодирования является доступным для того, чтобы восстанавливать поток битов для отображения и просмотра. Общая цель состоит в том, чтобы формировать поток битов таким образом, что он имеет меньший размер по сравнению с исходной видеоинформацией. Это преимущественно уменьшает пропускную способность, требуемую для сети передачи или устройства хранения данных, чтобы передавать или сохранять код потока битов. Для передачи поток видеобитов, в общем, инкапсулируется согласно протоколу передачи, который типично добавляет заголовки и контрольные биты.
Недавно экспертная группа по киноизображению (MPEG) публиковала новый стандарт, чтобы унифицировать и заменять существующие решения по потоковой передаче по HTTP (протоколу передачи гипертекста). Этот новый стандарт, называемый "динамической адаптивной потоковой передачей по HTTP (DASH)", предназначен для того, чтобы поддерживать модель потоковой передачи мультимедиа по HTTP на основе стандартных веб-серверов, в которых интеллектуальность (т.е. выбор мультимедийных данных для потоковой передачи и динамическая адаптация потоков битов к вариантам пользовательского выбора, характеристикам сети и характеристикам клиента) базируется исключительно на вариантах клиентского выбора и устройствах.
В этой модели мультимедийное представление организовано в сегментах данных и в манифесте, называемом "описанием мультимедийного представления (MPD)", который представляет организацию синхронизированных мультимедийных данных, которые должны быть представлены. В частности, манифест содержит идентификаторы ресурсов для использования при загрузке сегментов данных и предоставляет контекст для того, чтобы выбирать и комбинировать эти сегменты данных, чтобы получать допустимое мультимедийное представление. Идентификаторы ресурсов типично представляют собой HTTP URL-адреса (универсальные указатели ресурса), возможно комбинированные с байтовыми диапазонами. На основе манифеста, клиентское устройство определяет в любое время то, какие мультимедийные сегменты должны загружаться с сервера мультимедийных данных, согласно своим потребностям, характеристикам (например, поддерживаемым кодекам, размеру отображения, частоте кадров, уровню качества и т.д.) и в зависимости от характеристик сети (например, доступной полосы пропускания).
Помимо этого разрешение видео непрерывно увеличивается в диапазоне от стандартной четкости (SD) до высокой четкости (HD) и до сверхвысокой четкости (например, 4K2K или 8K4K, другими словами, видео, содержащее изображения 4096×2400 пикселов или 7680×4320 пикселов). Тем не менее, не все устройства приема и декодирования видео имеют ресурсы (например, полосу пропускания доступа к сети или CPU (центральный процессор)) для того, чтобы осуществлять доступ к видео при полном разрешении, в частности, когда видео имеет сверхвысокую четкость, и не всем пользователям требуется осуществлять доступ к такому видео. В таком контексте, в частности, преимущественно предоставлять возможность осуществления доступа только к некоторым интересующим областям (ROI), другими словами, осуществлять доступ только к некоторым пространственным подчастям всей видеопоследовательности.
Известный механизм для того, чтобы осуществлять доступ к пространственным подчастям кадров, принадлежащих видео, состоит в организации каждого видеокадра в качестве компоновки независимо декодируемых пространственных областей, в общем, называемых "мозаичными фрагментами". Некоторые видеоформаты, такие как SVC (масштабируемое кодирование видео) или HEVC (стандарт высокоэффективного кодирования видео), предоставляют поддержку для определения мозаичного фрагмента. Определяемая пользователем ROI может охватывать один или несколько смежных мозаичных фрагментов.
Соответственно для потоковой передачи выбираемых пользователем ROI согласно HTTP-протоколу, важно предоставлять инкапсуляцию синхронизированных мультимедийных данных кодированного потока видеобитов таким способом, который обеспечивает пространственный доступ к одному или более мозаичным фрагментам и который обеспечивает возможность комбинирования мозаичных фрагментов для доступа.
Следует напомнить, что кодированные потоки видеобитов, в общем, создаются в качестве набора смежных временных выборок, которые соответствуют полным кадрам, причем временные выборки организуются в качестве функции от порядка декодирования. Форматы файлов используются для того, чтобы инкапсулировать и описывать такие кодированные потоки битов.
Для иллюстрации базовый формат мультимедийных файлов Международной организации по стандартизации (ISO BMFF) является известным гибким и наращиваемым форматом, который описывает кодированные потоки битов синхронизированных мультимедийных данных либо для локального устройства хранения, либо для передачи через сеть или через другой механизм доставки потоков битов. Этот формат файла является объектно-ориентированным. Он состоит из стандартных блоков, называемых "полями", которые последовательно или иерархически организованы и которые задают параметры кодированного потока битов синхронизированных мультимедийных данных, к примеру, параметры синхронизации и структуры. Согласно этому формату файла, поток битов синхронизированных мультимедийных данных содержится в структуре данных, называемой "полем mdat", которая задается в другой структуре данных, называемой "полем track". Дорожка представляет синхронизированную последовательность выборок, в которой выборка соответствует всем данным, ассоциированным с одной временной меткой, другими словами, всем данным, ассоциированным с одиночным кадром, или всем данным, ассоциированным с несколькими кадрами, совместно использующими идентичную временную метку.
Для масштабируемого видео, к примеру, видео SVC-формата, многослойная организация мультимедийных данных может быть эффективно представлена посредством использования нескольких зависимых дорожек, причем каждая дорожка представляет видео на конкретном уровне масштабируемости. Во избежание дублирования данных между дорожками могут использоваться экстракторы. Согласно стандартному формату файла, экстрактор представляет собой структуру данных, непосредственно включенную в поток битов, которая обеспечивает эффективное извлечение единиц уровня абстрагирования от сети (NAL) из других потоков битов. Например, поток битов дорожки улучшающего слоя может содержать экстракторы, которые ссылаются на NAL-единицы из дорожки базового слоя. После этого, когда такая дорожка улучшающего слоя извлекается из формата файла, экстракторы должны быть заменены посредством данных, на которые они ссылаются.
Несколько стратегий могут приспосабливаться при использовании ISO BMFF, встраивающего эти механизмы, чтобы описывать вспомогательную информацию и упрощать доступ к этой вспомогательную информации или эффективно организовывать потоки битов в несколько сегментов.
Например, в статье, озаглавленной "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-передачи. Фактически, для существующего определения форматов файлов, по-прежнему необходимо осуществлять доступ к множеству прерывистых байтовых диапазонов в кодированном потоке битов, либо в результате возникает дублирование потоков битов, чтобы отображать пространственные мозаичные фрагменты нескольких кадров, соответствующих данному временному интервалу.
Чтобы разрешать эти проблемы, предусмотрена эффективная схема организации данных и описания дорожек, подходящая для пространственных мозаичных фрагментов, которая обеспечивает, безотносительно того, какая комбинация дорожек выбирается посредством клиентского приложения, то, что результат синтаксического ISO BMFF-анализа всегда приводит к допустимому элементарному потоку видеобитов для видеодекодера.
Сущность изобретения
В силу этих ограничении, авторы изобретения предоставляют способ и устройство для инкапсуляции мозаичных синхронизированных мультимедийных данных на сервере и для предоставления потока битов синхронизированных мультимедийных данных из мозаичных синхронизированных мультимедийных данных, инкапсулированных во множестве файлов мультимедийных сегментов.
Общая цель изобретения настоящего изобретения заключается в том, чтобы исправлять недостатки предшествующего уровня техники, как описано выше.
Согласно первому аспекту изобретения, предусмотрен способ инкапсуляции сегментированных синхронизированных мультимедийных данных на сервере, при этом сегментированные синхронизированные мультимедийные данные содержат синхронизированные выборки, причем каждая синхронизированная выборка содержит множество подвыборок, при этом способ содержит:
- выбор по меньшей мере одной подвыборки из множества подвыборок одной из синхронизированных выборок;
- для каждой выбранной подвыборки, создание одной дорожки сегментации, содержащей выбранную подвыборку и одну соответствующую подвыборку каждой из других синхронизированных выборок;
- создание по меньшей мере одной опорной дорожки, содержащей по меньшей мере один экстрактор, идентифицирующий по меньшей мере одну из созданных дорожек сегментации; и
- независимую инкапсуляцию каждой из созданных дорожек по меньшей мере в одном файле мультимедийных сегментов.
Соответственно изобретение обеспечивает возможность комбинирования различных частей и, в частности, различных мозаичных фрагментов и создания допустимого формата файла и элементарного потока во время синтаксического анализа, безотносительно выбранного набора частей или мозаичных фрагментов, загруженных посредством клиентского устройства.
Следовательно, способ изобретения является подходящим для эффективной потоковой передачи независимых частей или мозаичных фрагментов, требует только полезных данных для отправки в клиентское устройство, является подходящим более чем для одной части или выбора мозаичных фрагментов (т.е. произвольной ROI), уменьшает объем служебной информации для индексации (по сравнению с запросами в байтовом диапазоне) и может быть интегрирован в MPEG-стандарт.
В варианте осуществления сегментированные синхронизированные мультимедийные данные представляют собой мозаичные синхронизированные мультимедийные данные, при этом подвыборки представляют собой пространственные подвыборки, причем по меньшей мере одна дорожка сегментации представляет собой по меньшей мере одну дорожку мозаичных фрагментов, и по меньшей мере одна опорная дорожка представляет собой по меньшей мере одну составную дорожку. По меньшей мере, одна опорная дорожка может содержать экстракторы и необязательно данные инициализации.
В варианте осуществления по меньшей мере один экстрактор дополнительно идентифицирует по меньшей мере одну пространственную подвыборку по меньшей мере одной идентифицированной дорожки мозаичных фрагментов.
В варианте осуществления способ дополнительно содержит этап создания файла сегментов инициализации, содержащего параметры, обеспечивающие описание пространственной части мозаичных синхронизированных мультимедийных данных из созданных дорожек мозаичных фрагментов и созданной по меньшей мере одной составной дорожки. Файл сегментов инициализации может содержать ссылки на созданные дорожки мозаичных фрагментов, список дорожек мозаичных фрагментов, на которые имеются ссылки, ассоциированных по меньшей мере с одной созданной составной дорожкой, обработчик мозаичных фрагментов, ассоциированный с каждой из созданных дорожек мозаичных фрагментов, указывающий то, что дорожка содержит информацию о пространственных подвыборках и/или общую информацию представления, ассоциированную с каждой из созданных дорожек мозаичных фрагментов.
В варианте осуществления по меньшей мере две дорожки мозаичных фрагментов создаются на этапе создания одной дорожки мозаичных фрагментов для каждой выбранной пространственной подвыборки, причем по меньшей мере одна составная дорожка содержит по меньшей мере один элемент данных, которые должны использоваться для того, чтобы декодировать любую из двух пространственных подвыборок, содержащихся в идентичной синхронизированной выборке.
В варианте осуществления мозаичные синхронизированные мультимедийные данные представляют собой масштабируемые мозаичные синхронизированные мультимедийные данные, согласно которым каждая из синхронизированных выборок содержит опорный слой и по меньшей мере один улучшающий слой, причем опорный слой содержит по меньшей мере одну опорную пространственную подвыборку, а по меньшей мере один улучшающий слой содержит множество улучшающих пространственных подвыборок, при этом дорожки мозаичных фрагментов, созданные на этапе создания одной дорожки мозаичных фрагментов для каждой выбранной пространственной подвыборки, представляют собой улучшающие дорожки мозаичных фрагментов, содержащие улучшающие пространственные подвыборки, причем способ дополнительно содержит этап создания по меньшей мере одной опорной дорожки, содержащей опорные пространственные подвыборки.
В варианте осуществления опорный слой содержит множество опорных пространственных подвыборок, при этом создается множество опорных дорожек, причем каждая опорная дорожка из множества опорных дорожек формирует опорную дорожку мозаичных фрагментов.
В варианте осуществления файлы мультимедийных сегментов, получающиеся в результате инкапсуляции каждой из созданных дорожек, содержат структуру данных для сохранения метаданных, включающих в себя определения соответствующей дорожки.
В варианте осуществления по меньшей мере один из файлов мультимедийных сегментов, получающихся в результате инкапсуляции каждой из созданных дорожек, содержит структуру данных для сохранения метаданных, включающих в себя по меньшей мере одно определение по меньшей мере одной группы подвыборок соответствующей дорожки.
В варианте осуществления по меньшей мере один из файлов мультимедийных сегментов, получающихся в результате инкапсуляции каждой из созданных дорожек, содержит структуру данных для сохранения метаданных, включающих в себя различные определения различных групп подвыборок соответствующей дорожки.
В варианте осуществления структура данных, сохраняющая метаданные включает в себя по меньшей мере одно определение и тип версии, указывающий то, что по меньшей мере одно определение применяется ко всем подвыборкам соответствующей дорожки.
В варианте осуществления по меньшей мере один параметр структуры данных, сохраняющей метаданные, включающие в себя по меньшей мере одно определение по меньшей мере одной группы подвыборок соответствующей дорожки, связанные с зависимостями при декодировании подвыборок, указывает то, что каждая подвыборка группы может декодироваться без использования подвыборки другой группы.
В варианте осуществления подвыборки группы идентифицированы согласно типу группировки, которому принадлежат подвыборки.
В варианте осуществления подвыборки группы идентифицированы согласно типу группировки, которому принадлежат подвыборки, причем тип группировки предоставляет определение для каждой подвыборки группы.
В варианте осуществления файл сегментов инициализации содержит одно определение, которое должно использоваться по умолчанию для обработки подвыборок по меньшей мере одной дорожки мозаичных фрагментов, которые не ассоциированы с конкретными определениями, сохраненными в файле мультимедийных сегментов, получающемся в результате инкапсуляции соответствующей по меньшей мере одной дорожки мозаичных фрагментов.
В варианте осуществления способ дополнительно содержит этап добавления данных инициализации по меньшей мере в один из файлов мультимедийных сегментов, получающихся в результате инкапсуляции каждой из созданных дорожек, чтобы обеспечивать модификацию определения, сохраненного в файле сегментов инициализации, который должен использоваться по умолчанию.
В варианте осуществления файлы мультимедийных сегментов, получающиеся в результате инкапсуляции каждой из созданных дорожек, содержат структуру данных для сохранения пространственных подвыборок.
Файлы мультимедийных сегментов, получающиеся в результате инкапсуляции каждой из созданных дорожек, содержат структуру данных для сохранения экстракторов.
В варианте осуществления по меньшей мере один из файлов мультимедийных сегментов, получающихся в результате инкапсуляции каждой из созданных дорожек, содержит данные инициализации, сохраненные в опорной дорожке, так что по меньшей мере один из файлов мультимедийных сегментов может обрабатываться независимо в качестве стандартного файла мультимедийных сегментов.
В варианте осуществления по меньшей мере один из файлов мультимедийных сегментов, получающихся в результате инкапсуляции каждой из созданных дорожек, содержит структуру данных для сохранения по меньшей мере одного экстрактора, идентифицирующего данные инициализации, сохраненные в опорной дорожке.
В варианте осуществления по меньшей мере один из файлов мультимедийных сегментов, получающихся в результате инкапсуляции каждой из созданных дорожек, содержит структуру данных для сохранения по меньшей мере одного экстрактора, идентифицирующего данные инициализации составной дорожки, так что по меньшей мере один из файлов мультимедийных сегментов может обрабатываться независимо в качестве стандартного файла мультимедийных сегментов.
В варианте осуществления способ дополнительно содержит этап задания флага, указывающего то, что по меньшей мере один из файлов мультимедийных сегментов может обрабатываться независимо в качестве стандартного файла мультимедийных сегментов.
В варианте осуществления способ дополнительно содержит этап создания по меньшей мере одной дорожки данных инициализации, содержащей данные инициализации, причем по меньшей мере одна дорожка данных инициализации независимо инкапсулируется по меньшей мере в одном файле мультимедийных сегментов.
В варианте осуществления по меньшей мере один из файлов мультимедийных сегментов, получающихся в результате инкапсуляции каждой из созданных дорожек, содержит структуру данных для сохранения по меньшей мере одного экстрактора, идентифицирующего данные инициализации, сохраненные в дорожке данных инициализации, так что по меньшей мере один из файлов мультимедийных сегментов может обрабатываться независимо в качестве стандартного файла мультимедийных сегментов.
В варианте осуществления способ дополнительно содержит этап задания флага, указывающего на то, что по меньшей мере один из файлов мультимедийных сегментов может обрабатываться независимо в качестве стандартного файла мультимедийных сегментов.
В варианте осуществления сервер является совместимым с протоколом передачи гипертекста (HTTP).
В варианте осуществления файлы мультимедийных сегментов, получающиеся в результате инкапсуляции каждой из созданных дорожек, являются совместимыми с базовым форматом мультимедийных файлов и форматом динамической адаптивной потоковой передачи по HTTP, заданными посредством Международной организации по стандартизации.
В варианте осуществления способ инкапсуляции сегментированных синхронизированных мультимедийных данных на сервере, при этом сегментированные синхронизированные мультимедийные данные содержат синхронизированные выборки, причем каждая синхронизированная выборка содержит множество пространственных подвыборок, содержит:
- выбор по меньшей мере одной подвыборки из множества подвыборок одной из синхронизированных выборок;
- для каждой выбранной пространственной подвыборки, создание одной дорожки сегментации, содержащей выбранную подвыборку и одну соответствующую подвыборку каждой из других синхронизированных выборок;
- создание по меньшей мере одной опорной дорожки, содержащей информацию, ассоциирующую первую пространственную подвыборку, включенную в первую дорожку сегментации, и вторую пространственную подвыборку, включенную во вторую дорожку сегментации; и
- независимую инкапсуляцию каждой созданной дорожки по меньшей мере в одном файле мультимедийных сегментов.
Этот вариант осуществления может быть комбинирован с один или несколькими из предыдущих вариантов осуществления, раскрытых выше в отношении первого аспекта изобретения.
Второй аспект изобретения предоставляет способ предоставления потока битов синхронизированных мультимедийных данных из сегментированных синхронизированных мультимедийных данных, инкапсулированных во множестве файлов мультимедийных сегментов, в клиентском устройстве, при этом сегментированные синхронизированные мультимедийные данные содержат синхронизированные выборки, причем каждая синхронизированная выборка содержит множество подвыборок, множество файлов мультимедийных сегментов, содержащих по меньшей мере одну опорную дорожку и по меньшей мере одну дорожку сегментации, причем каждая по меньшей мере из одной дорожки сегментации содержит одну подвыборку, выбранную из множества подвыборок одной из синхронизированных выборок, и содержит одну соответствующую пространственную подвыборку каждой из других синхронизированных выборок, причем по меньшей мере одна опорная дорожка содержит по меньшей мере один экстрактор, идентифицирующий по меньшей мере одну дорожку сегментации и идентифицирующий по меньшей мере одну подвыборку идентифицированной дорожки сегментации, при этом способ содержит:
- выбор элемента информации, представляющего подвыборку;
- запрос по меньшей мере одной дорожки сегментации, содержащей выбранную подвыборку, причем выбранная подвыборка соответствует выбранному элементу информации;
- прием множества файлов мультимедийных сегментов; и
- замену экстракторов по меньшей мере одной опорной дорожки посредством соответствующих идентифицированных подвыборок, чтобы формировать поток битов синхронизированных мультимедийных данных.
Соответственно изобретение обеспечивает возможность комбинирования различных частей и, в частности, различных мозаичных фрагментов и создания допустимого формата файла и элементарного потока во время синтаксического анализа, безотносительно выбранного набора частей или мозаичных фрагментов, загруженных посредством клиентского устройства.
Следовательно, способ изобретения является подходящим для эффективной потоковой передачи независимых частей или мозаичных фрагментов, требует только полезных данных для отправки в клиентское устройство, является подходящим более чем для одной части или выбора мозаичных фрагментов (т.е. произвольной ROI), уменьшает объем служебной информации для индексации (по сравнению с запросами в байтовом диапазоне) и может быть интегрирован в MPEG-стандарт.
В варианте осуществления сегментированные синхронизированные мультимедийные данные представляют собой мозаичные синхронизированные мультимедийные данные, при этом подвыборки представляют собой пространственные подвыборки, причем по меньшей мере одна дорожка сегментации представляет собой по меньшей мере одну дорожку мозаичных фрагментов, и по меньшей мере одна опорная дорожка представляет собой по меньшей мере одну составную дорожку.
В варианте осуществления сегментированные синхронизированные мультимедийные данные представляют собой мозаичные синхронизированные мультимедийные данные, при этом подвыборки представляют собой пространственные подвыборки, причем по меньшей мере одна дорожка сегментации представляет собой по меньшей мере одну дорожку мозаичных фрагментов, и по меньшей мере одна опорная дорожка представляет собой по меньшей мере одну составную дорожку, содержащую экстракторы и необязательно данные инициализации.
В варианте осуществления способ дополнительно содержит:
- получение ссылки на дорожку из экстрактора по меньшей мере одной составной дорожки;
- проверку того, принята или нет дорожка, соответствующая полученной ссылке на дорожку; и
- если дорожка, соответствующая полученной ссылке на дорожку, не принята, удаление соответствующего экстрактора, чтобы формировать поток битов синхронизированных мультимедийных данных.
В варианте осуществления способ дополнительно содержит этап верификации того, что дорожка, соответствующая полученной ссылке на дорожку, представляет собой дорожку типа мозаичного фрагмента.
В варианте осуществления способ дополнительно содержит:
- получение ссылки на дорожку из экстрактора по меньшей мере одной составной дорожки;
- проверку того, принята или нет дорожка, соответствующая полученной ссылке на дорожку; и
- если дорожка, соответствующая полученной ссылке на дорожку, не принята, замену соответствующего экстрактора посредством дополнения, чтобы формировать поток битов синхронизированных мультимедийных данных.
В варианте осуществления способ дополнительно содержит этап верификации того, что дорожка, соответствующая полученной ссылке на дорожку, представляет собой дорожку типа мозаичного фрагмента.
В варианте осуществления способ дополнительно содержит этап приема файла сегментов инициализации, содержащего параметры, обеспечивающие формирование пространственной части мозаичных синхронизированных мультимедийных данных из созданных дорожек мозаичных фрагментов и созданной по меньшей мере одной составной дорожки.
В варианте осуществления по меньшей мере два файла мультимедийных сегментов, представляющие по меньшей мере две дорожки мозаичных фрагментов, принимаются, причем по меньшей мере одна составная дорожка содержит по меньшей мере один элемент данных, которые должны использоваться для того, чтобы декодировать любую из двух пространственных подвыборок, принадлежащих идентичному набору пространственных подвыборок.
В варианте осуществления мозаичные синхронизированные мультимедийные данные представляют собой масштабируемые мозаичные синхронизированные мультимедийные данные, согласно которым каждая из синхронизированных выборок содержит опорный слой и по меньшей мере один улучшающий слой, причем опорный слой содержит по меньшей мере одну опорную пространственную подвыборку, а по меньшей мере один улучшающий слой содержит множество улучшающих пространственных подвыборок, при этом по меньшей мере два файла мультимедийных сегментов, представляющие по меньшей мере две дорожки, принимаются, причем одна по меньшей мере из двух принимаемых дорожек представляет собой опорную дорожку, содержащую опорные пространственные подвыборки, а другая по меньшей мере из двух принимаемых дорожек представляет собой улучшающую дорожку мозаичных фрагментов, содержащую улучшающие пространственные подвыборки.
В варианте осуществления опорный слой содержит множество опорных пространственных подвыборок, при этом множество опорных дорожек, каждая из которых формирует опорную дорожку мозаичных фрагментов, принимаются.
В варианте осуществления по меньшей мере один из файлов мультимедийных сегментов содержит структуру данных для сохранения метаданных, включающих в себя по меньшей мере одно определение по меньшей мере одной группы подвыборок соответствующей дорожки, при этом способ содержит этап получения по меньшей мере одного определения для обработки по меньшей мере одной группы подвыборок соответствующей дорожки.
В варианте осуществления по меньшей мере один из файлов мультимедийных сегментов содержит данные инициализации, сохраненные в опорной дорожке, причем способ дополнительно содержит этап независимой обработки по меньшей мере одного из файлов мультимедийных сегментов в качестве стандартного файла мультимедийных сегментов.
В варианте осуществления по меньшей мере один из файлов мультимедийных сегментов содержит структуру данных для сохранения по меньшей мере одного экстрактора, идентифицирующего данные инициализации, сохраненные в опорной дорожке, причем способ дополнительно содержит этап осуществления доступа к данным, сохраненным в опорной дорожке, при обработке по меньшей мере одного из файлов мультимедийных сегментов.
В варианте осуществления по меньшей мере один из файлов мультимедийных сегментов содержит структуру данных для сохранения по меньшей мере одного экстрактора, идентифицирующего данные инициализации составной дорожки, причем способ дополнительно содержит этап осуществления доступа к данным, сохраненным в опорной дорожке, для независимой обработки по меньшей мере одного из файлов мультимедийных сегментов в качестве стандартного файла мультимедийных сегментов.
В варианте осуществления способ дополнительно содержит этап получения по меньшей мере одной дорожки данных инициализации, содержащей данные инициализации, причем по меньшей мере одна дорожка данных инициализации независимо инкапсулируется по меньшей мере в одном файле мультимедийных сегментов.
В варианте осуществления по меньшей мере один из файлов мультимедийных сегментов содержит структуру данных для сохранения по меньшей мере одного экстрактора, идентифицирующего данные инициализации, сохраненные в дорожке данных инициализации, причем способ дополнительно содержит этап осуществления доступа к данным, сохраненным в опорной дорожке, для независимой обработки по меньшей мере одного из файлов мультимедийных сегментов.
В варианте осуществления клиентское устройство является совместимым с протоколом передачи гипертекста (HTTP).
В варианте осуществления принятые файлы мультимедийных сегментов являются совместимыми с базовым форматом мультимедийных файлов и форматом динамической адаптивной потоковой передачи по HTTP, заданными посредством Международной организации по стандартизации.
Согласно третьему аспекту изобретения, предусмотрено устройство, содержащее средство, выполненное с возможностью осуществления каждого этапа способа, описанного выше.
Согласно четвертому аспекту изобретения, предусмотрено устройство для инкапсуляции сегментированных синхронизированных мультимедийных данных на сервере, при этом сегментированные синхронизированные мультимедийные данные содержат синхронизированные выборки, причем каждая синхронизированная выборка содержит множество подвыборок, при этом устройство содержит по меньшей мере один микропроцессор, выполненный с возможностью осуществления этапов:
- выбора по меньшей мере одной подвыборки из множества подвыборок одной из синхронизированных выборок;
- для каждой выбранной подвыборки, создания одной дорожки сегментации, содержащей выбранную подвыборку и одну соответствующую подвыборку каждой из других синхронизированных выборок;
- создания по меньшей мере одной опорной дорожки, содержащей по меньшей мере один экстрактор, идентифицирующий по меньшей мере одну из созданных дорожек сегментации; и
- независимой инкапсуляции каждой из созданных дорожек по меньшей мере в одном файле мультимедийных сегментов.
Соответственно изобретение обеспечивает возможность комбинирования различных частей и, в частности, различных мозаичных фрагментов и создания допустимого формата файла и элементарного потока во время синтаксического анализа, безотносительно выбранного набора частей или мозаичных фрагментов, загруженных посредством клиентского устройства.
Следовательно, способ изобретения является подходящим для эффективной потоковой передачи независимых частей или мозаичных фрагментов, требует только полезных данных для отправки в клиентское устройство, является подходящим более чем для одной части или выбора мозаичных фрагментов (т.е. произвольной ROI), уменьшает объем служебной информации для индексации (по сравнению с запросами в байтовом диапазоне) и может быть интегрирован в MPEG-стандарт.
В варианте осуществления сегментированные синхронизированные мультимедийные данные представляют собой мозаичные синхронизированные мультимедийные данные, при этом подвыборки представляют собой пространственные подвыборки, причем по меньшей мере одна дорожка сегментации представляет собой по меньшей мере одну дорожку мозаичных фрагментов, и по меньшей мере одна опорная дорожка представляет собой по меньшей мере одну составную дорожку.
В варианте осуществления сегментированные синхронизированные мультимедийные данные представляют собой мозаичные синхронизированные мультимедийные данные, при этом подвыборки представляют собой пространственные подвыборки, причем по меньшей мере одна дорожка сегментации представляет собой по меньшей мере одну дорожку мозаичных фрагментов, и по меньшей мере одна опорная дорожка представляет собой по меньшей мере одну составную дорожку, содержащую экстракторы и необязательно данные инициализации.
В варианте осуществления микропроцессор дополнительно выполнен с возможностью осуществления этапа создания файла сегментов инициализации, содержащего параметры, обеспечивающие формирование пространственной части мозаичных синхронизированных мультимедийных данных из созданных дорожек мозаичных фрагментов и созданной по меньшей мере одной составной дорожки, причем файл сегментов инициализации содержит ссылки на созданные дорожки мозаичных фрагментов.
В варианте осуществления файл сегментов инициализации дополнительно содержит список дорожек мозаичных фрагментов, на которые имеются ссылки, ассоциированных по меньшей мере с одной созданной составной дорожкой.
В варианте осуществления файл сегментов инициализации дополнительно содержит обработчик мозаичных фрагментов, ассоциированный с каждой из созданных дорожек мозаичных фрагментов, указывающий то, что дорожка содержит информацию о пространственных подвыборках.
В варианте осуществления файл сегментов инициализации дополнительно содержит общую информацию представления, ассоциированную с каждой из созданных дорожек мозаичных фрагментов.
В варианте осуществления микропроцессор дополнительно выполнен таким образом, что по меньшей мере две дорожки мозаичных фрагментов создаются на этапе создания одной дорожки мозаичных фрагментов для каждой выбранной пространственной подвыборки, причем по меньшей мере одна составная дорожка содержит по меньшей мере один элемент данных, которые должны использоваться для того, чтобы декодировать любую из двух пространственных подвыборок, содержащихся в идентичной синхронизированной выборке.
В варианте осуществления мозаичные синхронизированные мультимедийные данные представляют собой масштабируемые мозаичные синхронизированные мультимедийные данные, согласно которым каждая из синхронизированных выборок содержит опорный слой и по меньшей мере один улучшающий слой, причем опорный слой содержит по меньшей мере одну опорную пространственную подвыборку, а по меньшей мере один улучшающий слой содержит множество улучшающих пространственных подвыборок, при этом микропроцессор дополнительно имеет такую конфигурацию, в которой дорожки мозаичных фрагментов, созданные на этапе создания одной дорожки мозаичных фрагментов для каждой выбранной пространственной подвыборки, представляют собой улучшающие дорожки мозаичных фрагментов, содержащие улучшающие пространственные подвыборки, при этом микропроцессор дополнительно выполнен с возможностью осуществления этапа создания по меньшей мере одной опорной дорожки, содержащей опорные пространственные подвыборки.
В варианте осуществления опорный слой содержит множество опорных пространственных подвыборок, при этом микропроцессор дополнительно имеет такую конфигурацию, в которой создается множество опорных дорожек, причем каждая опорная дорожка из множества опорных дорожек формирует опорную дорожку мозаичных фрагментов.
В варианте осуществления файлы мультимедийных сегментов, получающиеся в результате инкапсуляции каждой из созданных дорожек, содержат структуру данных для сохранения метаданных, включающих в себя определения соответствующей дорожки.
В варианте осуществления файлы мультимедийных сегментов, получающиеся в результате инкапсуляции каждой из созданных дорожек, содержат структуру данных для сохранения пространственных подвыборок.
В варианте осуществления файлы мультимедийных сегментов, получающиеся в результате инкапсуляции каждой из созданных дорожек, содержат структуру данных для сохранения экстракторов.
В варианте осуществления сервер является совместимым с протоколом передачи гипертекста (HTTP), при этом файлы мультимедийных сегментов, получающиеся в результате инкапсуляции каждой из созданных дорожек, являются совместимыми с базовым форматом мультимедийных файлов и форматом динамической адаптивной потоковой передачи по HTTP, заданными посредством Международной организации по стандартизации.
В варианте осуществления устройство для инкапсуляции сегментированных синхронизированных мультимедийных данных на сервере, при этом сегментированные синхронизированные мультимедийные данные содержат синхронизированные выборки, причем каждая синхронизированная выборка содержит множество пространственных подвыборок, содержит:
- модуль выбора, выполненный с возможностью выбирать по меньшей мере одну подвыборку из множества подвыборок одной из синхронизированных выборок;
- первый модуль создания, выполненный с возможностью создавать, для каждой выбранной пространственной подвыборки, одну дорожку сегментации, содержащую выбранную подвыборку и одну соответствующую подвыборку каждой из других синхронизированных выборок;
- второй модуль создания, выполненный с возможностью создавать по меньшей мере одну опорную дорожку, содержащую информацию, ассоциирующую первую пространственную подвыборку, включенную в первую дорожку сегментации, и вторую пространственную подвыборку, включенную во вторую дорожку сегментации; и
- модуль инкапсуляции, выполненный с возможностью инкапсулировать независимо каждую созданную дорожку по меньшей мере в одном файле мультимедийных сегментов.
Этот вариант осуществления может быть комбинирован с один или несколькими из предыдущих вариантов осуществления, раскрытых выше в отношении четвертого аспекта изобретения.
Согласно пятому аспекту изобретения, предусмотрен видеокодер, содержащий устройство, как описано выше.
Согласно шестому аспекту изобретения, предусмотрено устройство для устройства для предоставления потока битов синхронизированных мультимедийных данных из сегментированных синхронизированных мультимедийных данных, инкапсулированных во множестве файлов мультимедийных сегментов, в клиентском устройстве, при этом сегментированные синхронизированные мультимедийные данные содержат синхронизированные выборки, причем каждая синхронизированная выборка содержит множество подвыборок, множество файлов мультимедийных сегментов, содержащих по меньшей мере одну опорную дорожку и по меньшей мере одну дорожку сегментации, причем каждая по меньшей мере из одной дорожки сегментации содержит одну подвыборку, выбранную из множества подвыборок одной из синхронизированных выборок, и содержит одну соответствующую подвыборку каждой из других синхронизированных выборок, причем по меньшей мере одна опорная дорожка содержит по меньшей мере один экстрактор, идентифицирующий по меньшей мере одну дорожку сегментации и идентифицирующий по меньшей мере одну подвыборку идентифицированной дорожки сегментации, при этом устройство содержит по меньшей мере один микропроцессор, выполненный с возможностью осуществления этапов:
- выбора элемента информации, представляющего подвыборку;
- запроса по меньшей мере одной дорожки сегментации, содержащей выбранную подвыборку, причем выбранная подвыборка соответствует выбранному элементу информации;
- приема множества файлов мультимедийных сегментов; и
- замены экстракторов по меньшей мере одной опорной дорожки посредством соответствующих идентифицированных подвыборок, чтобы формировать поток битов синхронизированных мультимедийных данных.
Соответственно изобретение обеспечивает возможность комбинирования различных частей и, в частности, различных мозаичных фрагментов и создания допустимого формата файла и элементарного потока во время синтаксического анализа, безотносительно выбранного набора частей или мозаичных фрагментов, загруженных посредством клиентского устройства.
Следовательно, способ изобретения является подходящим для эффективной потоковой передачи независимых частей или мозаичных фрагментов, требует только полезных данных для отправки в клиентское устройство, является подходящим более чем для одной части или выбора мозаичных фрагментов (т.е. произвольной ROI), уменьшает объем служебной информации для индексации (по сравнению с запросами в байтовом диапазоне) и может быть интегрирован в MPEG-стандарт.
В варианте осуществления сегментированные синхронизированные мультимедийные данные представляют собой мозаичные синхронизированные мультимедийные данные, при этом подвыборки представляют собой пространственные подвыборки, причем по меньшей мере одна дорожка сегментации представляет собой по меньшей мере одну дорожку мозаичных фрагментов, и по меньшей мере одна опорная дорожка представляет собой по меньшей мере одну составную дорожку.
В варианте осуществления сегментированные синхронизированные мультимедийные данные представляют собой мозаичные синхронизированные мультимедийные данные, при этом подвыборки представляют собой пространственные подвыборки, причем по меньшей мере одна дорожка сегментации представляет собой по меньшей мере одну дорожку мозаичных фрагментов, и по меньшей мере одна опорная дорожка представляет собой по меньшей мере одну составную дорожку, содержащую экстракторы и необязательно данные инициализации.
В варианте осуществления микропроцессор дополнительно выполнен с возможностью осуществления этапов:
- получения ссылки на дорожку из экстрактора по меньшей мере одной составной дорожки;
- проверки того, принята или нет дорожка, соответствующая полученной ссылке на дорожку; и
- если дорожка, соответствующая полученной ссылке на дорожку, не принята, удаления соответствующего экстрактора, чтобы формировать поток битов синхронизированных мультимедийных данных.
В варианте осуществления микропроцессор дополнительно выполнен с возможностью осуществления этапа верификации того, что дорожка, соответствующая полученной ссылке на дорожку, представляет собой дорожку типа мозаичного фрагмента.
В варианте осуществления микропроцессор дополнительно выполнен с возможностью осуществления этапов:
- получения ссылки на дорожку из экстрактора по меньшей мере одной составной дорожки;
- проверки того, принята или нет дорожка, соответствующая полученной ссылке на дорожку; и
- если дорожка, соответствующая полученной ссылке на дорожку, не принята, замены соответствующего экстрактора посредством дополнения, чтобы формировать поток битов синхронизированных мультимедийных данных.
В варианте осуществления микропроцессор дополнительно выполнен с возможностью осуществления этапа верификации того, что дорожка, соответствующая полученной ссылке на дорожку, представляет собой дорожку типа мозаичного фрагмента.
В варианте осуществления микропроцессор дополнительно выполнен с возможностью осуществления этапа приема файла сегментов инициализации, содержащего параметры, обеспечивающие формирование пространственной части мозаичных синхронизированных мультимедийных данных из созданных дорожек мозаичных фрагментов и созданной по меньшей мере одной составной дорожки.
В варианте осуществления микропроцессор дополнительно имеет такую конфигурацию, в которой по меньшей мере два файла мультимедийных сегментов, представляющие по меньшей мере две дорожки мозаичных фрагментов, принимаются, причем по меньшей мере одна составная дорожка содержит по меньшей мере один элемент данных, которые должны использоваться для того, чтобы декодировать любую из двух пространственных подвыборок, принадлежащих идентичному набору пространственных подвыборок.
В варианте осуществления мозаичные синхронизированные мультимедийные данные представляют собой масштабируемые мозаичные синхронизированные мультимедийные данные, согласно которым каждая из синхронизированных выборок содержит опорный слой и по меньшей мере один улучшающий слой, причем опорный слой содержит по меньшей мере одну опорную пространственную подвыборку, а по меньшей мере один улучшающий слой содержит множество улучшающих пространственных подвыборок, при этом микропроцессор дополнительно имеет такую конфигурацию, в которой по меньшей мере два файла мультимедийных сегментов, представляющие по меньшей мере две дорожки, принимаются, причем одна по меньшей мере из двух принимаемых дорожек представляет собой опорную дорожку, содержащую опорные пространственные подвыборки, а другая по меньшей мере из двух принимаемых дорожек представляет собой улучшающую дорожку мозаичных фрагментов, содержащую улучшающие пространственные подвыборки.
В варианте осуществления клиентское устройство является совместимым с протоколом передачи гипертекста (HTTP), при этом принятые файлы мультимедийных сегментов являются совместимыми с базовым форматом мультимедийных файлов и форматом динамической адаптивной потоковой передачи по HTTP, заданными посредством Международной организации по стандартизации.
Согласно седьмому аспекту изобретения, предусмотрен видеодекодер, содержащий устройство, как описано выше.
Поскольку настоящее изобретение может быть реализовано в программном обеспечении, настоящее изобретение может быть осуществлено в качестве машиночитаемого кода для предоставления в программируемое устройство на любом подходящем носителе. Материальный носитель может содержать носитель хранения данных, такой как гибкий диск, CD-ROM, жесткий диск, устройство на магнитных лентах или полупроводниковое запоминающее устройство и т.п. Переходная несущая среда может включать в себя такой сигнал, как электрический сигнал, электронный сигнал, оптический сигнал, акустический сигнал, магнитный сигнал либо электромагнитный сигнал, например, микроволновый или RF-сигнал.
Краткое описание чертежей
Дополнительные преимущества настоящего изобретения должны становиться очевидными для специалистов в данной области техники после изучения чертежей и подробного описания. Подразумевается, что все дополнительные преимущества содержатся в данном документе.
Далее описываются варианты осуществления изобретения, только в качестве примера и со ссылкой на прилагаемые чертежи, на которых:
фиг. 1, содержащая фиг. 1a и 1b, иллюстрирует пример кодирования мозаичных фрагментов в кодированном потоке видеобитов;
фиг. 2 иллюстрирует временной конвейер мозаичных фрагментов, выбранных пользователем для отображения;
фиг. 3 иллюстрирует пример блок-схем файла сегментов инициализации с использованием дорожек масштабируемых мультимедийных данных согласно конкретному варианту осуществления;
фиг. 4 иллюстрирует пример блок-схем файлов мультимедийных сегментов, содержащих дорожки мозаичных фрагментов и одну составную дорожку, согласно конкретному варианту осуществления, соответствующую дорожкам, объявленным в файле сегментов инициализации, таком как файл сегментов инициализации, показанный на фиг. 3;
фиг. 5 иллюстрирует пример конкатенации загруженных сегментов мультимедийных данных, чтобы компоновать допустимый декодируемый поток битов синхронизированных мультимедийных данных, представляющий пространственную часть последовательных видеокадров в течение данного временного периода;
фиг. 6, содержащая фиг. 6a и фиг. 6b, является блок-схемой последовательности операций способа, иллюстрирующей этапы для передачи синхронизированных мультимедийных данных между сервером и клиентским устройством согласно конкретному варианту осуществления;
фиг. 7 является блок-схемой последовательности операций способа, иллюстрирующей формирование допустимого потока битов синхронизированных мультимедийных данных из конкатенированных мультимедийных сегментов, принимаемых посредством клиентского устройства; и
фиг. 8 представляет блок-схему сервера или клиентского устройства, в котором могут реализовываться этапы одного или более вариантов осуществления;
фиг. 9, содержащая фиг. 9a, 9b и 9c, иллюстрирует примеры мозаичных фрагментов и сегментов серий последовательных макроблоков в HEVC-потоке битов;
фиг. 10 иллюстрирует пример инкапсуляции HEVC-потока битов в качестве набора дорожек, содержащих составную дорожку и дорожки независимых мозаичных фрагментов, согласно варианту осуществления изобретения;
фиг. 11 иллюстрирует пример блок-схем файла сегментов инициализации с использованием дорожек мультимедийных данных, согласно первому варианту осуществления, чтобы инкапсулировать HEVC-поток битов;
фиг. 12, содержащая фиг. 12a и фиг. 12b, иллюстрирует передачу в служебных сигналах позиции мозаичного фрагмента в полном видео, размера мозаичного фрагмента и индикатора того, что дорожка мозаичных фрагментов может декодироваться без артефактов, на уровне подвыборки, адаптированный, чтобы обрабатывать различную конфигурацию мозаичного размещения;
фиг. 13 иллюстрирует пример инкапсуляции HEVC-потока битов в качестве набора дорожек, содержащих составную дорожку и дорожки независимых мозаичных фрагментов, которые являются воспроизводимыми в качестве стандартных видеодорожек, согласно варианту осуществления изобретения; и
фиг. 14 иллюстрирует пример инкапсуляции HEVC-потока битов в качестве набора дорожек, содержащих составную дорожку, дорожку данных инициализации и дорожки независимых мозаичных фрагментов, которые являются воспроизводимыми в качестве стандартных видеодорожек, согласно другому варианту осуществления изобретения.
Осуществление изобретения
Согласно конкретному варианту осуществления, сегментированные синхронизированные мультимедийные данные, к примеру, мозаичные синхронизированные мультимедийные данные (например, видеоданные), содержащие синхронизированные выборки (например, изображения), передаются в качестве набора нескольких дорожек синхронизированных мультимедийных данных, типично дорожки базового слоя и нескольких дорожек мозаичных фрагментов и опорной или составной дорожки, которая содержит ссылки на дорожки синхронизированных мультимедийных данных. Каждая дорожка мозаичных фрагментов содержит одну пространственную подвыборку (например, несколько NAL-единиц) нескольких синхронизированных выборок. Расширенный тип экстрактора задается для ссылки на дорожки синхронизированных мультимедийных данных из составной дорожки. Дорожки синхронизированных мультимедийных данных помечаются как неотображаемые и передают и описывают синхронизированные мультимедийные данные для мозаичных фрагментов. Этот набор дорожек синхронизированных мультимедийных данных и составной дорожки обеспечивает выбор, составление и эффективную потоковую передачу пространственных мозаичных видеофрагментов. Каждая дорожка может передаваться из серверного устройства в клиентское устройство в качестве набора файлов мультимедийных сегментов. Файл сегментов инициализации может использоваться для того, чтобы передавать метаданные, требуемые для того, чтобы декодировать файлы мультимедийных сегментов.
Фиг. 1, содержащая фиг. 1a и фиг. 1b, иллюстрирует пример кодирования мозаичных фрагментов в кодированном потоке видеобитов.
Для иллюстрации, в нижеприведенном описании считается, что каждый видеокадр (синхронизированная выборка) состоит из независимо декодируемых мозаичных фрагментов, соответствующих пространственным подчастям (пространственным подвыборкам) видеокадра. Видео предпочтительно является масштабируемым и организуется на разных уровнях масштабируемости. Как проиллюстрировано на фиг. 1a, видеокадр 100 может содержать базовый HD-слой (102) и улучшающий 4K2K-слой (104). Также для иллюстрации, улучшающий слой 104 может быть разделен на четыре обычных мозаичных фрагмента, обозначенных как a, b, c и d. Следует отметить, что могут обрабатываться мозаичные фрагменты различных форм. Аналогично базовый слой 102 может быть разделен на несколько мозаичных фрагментов. В таком случае, могут использоваться несколько составных дорожек, например, одна для базового слоя и одна для улучшающих слоев либо для каждого из улучшающих слоев.
Также следует отметить, что изобретение не ограничено масштабируемым видеоформатом. Оно может применяться ко всем видеоформатам, обеспечивающим независимое декодирование мозаичных фрагментов. Соответственно любые алгоритмы сжатия видео, такие как MPEG4, AVC, HEVC, SVC или будущий SHVC, могут использоваться в сочетании с вариантом осуществления изобретения.
Фиг. 1b представляет типичный кодированный поток видеобитов в порядке декодирования. Как проиллюстрировано, кодированный поток видеобитов содержит здесь три видеокадра (110, 112 и 114), кодированные во временном порядке. Каждый видеокадр содержит все единицы уровня абстрагирования от сети (NAL) базового слоя (BL), после которых находятся NAL-единицы улучшающего слоя. Например, после NAL-единицы (1 BL, 116) базового слоя (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. Это является неэффективным в потоковой HTTP-передаче с точки зрения числа сформированных запросов и с точки зрения объема служебных данных.
Следовательно, чтобы предоставлять более эффективный доступ в сжатых видео для потоковой ROI-передачи, поток битов синхронизированных мультимедийных данных должен быть реорганизован, так что данные конкретного мозаичного фрагмента организованы в качестве смежного байтового диапазона (формирующего конвейер) для данного периода времени (т.е. набора последовательных кадров).
Соответственно когда должна отображаться только пространственная подчасть видеокадров, только конвейеры мозаичных фрагментов, соответствующих выбранной пространственной области, должны загружаться (например, мозаичные фрагменты 3 и 7 на фиг. 2) с использованием одного HTTP-запроса в расчете на конвейер и в расчете на период времени.
Фиг. 3 иллюстрирует пример блок-схем файла сегментов инициализации с использованием дорожек мультимедийных данных согласно конкретному варианту осуществления.
Файл сегментов инициализации, проиллюстрированный на фиг. 3, и файлы мультимедийных сегментов, проиллюстрированные на фиг. 4, иллюстрируют вариант осуществления изобретения, чтобы реорганизовывать и инкапсулировать поток видеобитов в базовом формате мультимедийных файлов по стандарту ISO, в то время как несколько дорожек передаются в потоковом режиме независимо. Для иллюстрации, контент по фиг. 3 и 4 основан на потоке видеобитов, проиллюстрированном на фиг. 1.
Чтобы реорганизовывать и инкапсулировать поток видеобитов в ISO BMFF в то время, когда несколько дорожек передаются в потоковом режиме независимо, задается новый тип дорожки, называемой "дорожкой мозаичных фрагментов". Дорожка мозаичных фрагментов представляет собой дорожку, которая по определению является синхронизированной последовательностью связанных выборок, в которой выборка представляет все данные, ассоциированные с одной временной меткой. В отличие от известной мультимедийной видеодорожки, в которой выборка типично представляет собой отдельный видеокадр, выборка дорожки мозаичных фрагментов задает пространственно заданную подчасть полного видеокадра. Соответственно дорожки мозаичных фрагментов содержат только NAL-единицы, связанные с данным мозаичным фрагментом. Таким образом, можно создавать конвейеры мозаичных фрагментов со смежными байтовыми диапазонами посредством сохранения каждой дорожки в независимых файлах сегментов.
Тем не менее, поскольку дорожка мозаичных фрагментов не содержит все требуемые NAL-единицы и информацию для декодирования и воспроизведения, используется дополнительная дорожка, называемая "составной дорожкой". Согласно конкретному варианту осуществления, составная дорожка представляет собой мультимедийную дорожку, представляющую полный мозаичный кадр (т.е. композицию всех мозаичных фрагментов). Составная дорожка является представлением кодированного потока битов синхронизированных мультимедийных данных в его типичной организации, как описано со ссылкой на фиг. 1 (покадрово в порядке декодирования). Составная дорожка использует объекты экстрактора, чтобы обращаться к NAL-единицам в соответствующих дорожках мозаичных фрагментов. Помимо этого она может содержать NAL-единицы, которые являются общими для всех мозаичных фрагментов, если такие NAL-единицы существуют.
Согласно конкретному варианту осуществления, файл сегментов инициализации используется для того, чтобы передавать все метаданные, которые необходимы для того, чтобы задавать потоки битов синхронизированных мультимедийных данных, инкапсулированные в других файлах мультимедийных сегментов. Как проиллюстрировано на фиг. 3, файл 300 сегментов инициализации содержит поле ftyp 302 типов файлов и кинополе moov 304. Поле 302 типов файлов предпочтительно идентифицирует то, каким спецификациям ISO BMF соответствуют файлы сегментов, и указывает номер версии этой спецификации. Кинополе moov 304 предоставляет все метаданные, описывающие представление, сохраненное в файлах мультимедийных сегментов, и, в частности, все дорожки, доступные в представлении.
Кинополе moov 304 содержит определение для каждой из дорожек (поля 306-1 - 306-6 track), соответствующих масштабируемого потоку видеобитов, предоставленному в качестве примера на фиг. 1.
Поле 306-1 track представляет базовый слой (track_ID=1), четыре поля 306-2 - 306-5 track (поля 306-3 и 306-4 track не показаны), представляют четыре мозаичных фрагмента a, b, c и d улучшающего слоя (track_ID=2 в 5), и поле 306-6 track представляет составную дорожку, описывающую улучшающий слой (track_ID=6).
Каждое поле track содержит по меньшей мере поле tkhd заголовков дорожек, обобщенно со ссылкой с номером 308, и поле mdia мультимедиа дорожек, обобщенно со ссылкой с номером 310. Если дорожка зависит от данных из других дорожек, также предусмотрено поле tref ссылок на дорожки. Как проиллюстрировано, составная дорожка, имеющая идентификатор track_ID=6, содержит поле tref 312 ссылок на дорожки, указывающее то, что дорожка зависит от данных из дорожек, имеющих идентификаторы track_ID=1-6.
Следует отметить, что другие поля могут быть обязательными или необязательными в зависимости от спецификаций ISO BMFF, используемых для того, чтобы инкапсулировать поток битов синхронизированных мультимедийных данных. Тем не менее, поскольку варианты осуществления изобретения не основываются на этих полях в качестве применимых, они не представлены здесь.
Поле 308 заголовков дорожек указывает характеристики дорожки. Из нескольких элементов информации, оно предоставляет идентификатор (trackID) дорожки, длительность дорожки и/или размер визуального представления дорожки (т. е. ширину и высоту области отображения). Оно также содержит флаговый параметр, который указывает то, является или нет дорожка воспроизводимой.
Согласно варианту осуществления, значение по умолчанию флага заголовка дорожки для дорожек мозаичных фрагментов равно 0 (track_enabled=0, track_in_movie=0, track_in_preview=0), что означает то, что дорожки мозаичных фрагментов игнорируются для локального воспроизведения и предварительного просмотра посредством клиентского устройства. В другом варианте осуществления новый флаг заголовка дорожки может быть создан, чтобы передавать в служебных сигналах то, что дорожка представляет собой дорожку мозаичных фрагментов.
Поле mdia 310 мультимедиа дорожек может рассматриваться в качестве контейнера, содержащего все объекты, используемые для того, чтобы объявлять параметры синхронизированных мультимедийных данных в дорожке. Оно содержит по меньшей мере поле mdhd заголовков мультимедиа, обобщенно со ссылкой с номером 314, поле hdlr ссылок на обработчики, обобщенно со ссылкой с номером 316, и поле minf мультимедийной информации, обобщенно со ссылкой с номером 318.
Поле hdlr 316 ссылок на обработчики объявляет процесс, посредством которого синхронизированные мультимедийные данные дорожки должны быть представлены, и в силу этого характер синхронизированных мультимедийных данных в дорожке. Например, видеодорожка должна обрабатываться посредством видеообработчика (помечено с помощью атрибута типа обработчика, равного "vide"). Видеовыборка может описываться посредством использования объекта типа VisualSampleEntry(). Согласно конкретному варианту осуществления, задается новый тип обработчика, называемый "обработчиком мозаичных фрагментов" (помечен с помощью атрибута типа обработчика, равного tile), чтобы указывать то, что дорожка содержит информацию о пространственных подвыборках. В зависимости от формата кодирования, если объект типа VisualSampleEntry() не может описывать выборку в дорожке мозаичных фрагментов, можно задавать конкретный объект типа TileSampleEntry(), чтобы описывать выборку.
Поле minf 318 мультимедийной информации содержит все объекты, которые задают характеристическую информацию синхронизированных мультимедийных данных в дорожке. Например, для базового слоя и для улучшающего слоя, заданного в составной дорожке, поле minf может содержать стандартное поле vmhd (320) заголовков видеомультимедиа.
Относительно дорожек мозаичных фрагментов, конкретное поле, называемое "полем (tmhd, 322) заголовков мультимедиа для мозаичных фрагментов", соответствующее новому обработчику мозаичных фрагментов, используется для того, чтобы задавать общую информацию представления, независимую от кодирования, для мозаичных фрагментов. В частности, оно может содержать геометрическую информацию пространственной области, покрытой мозаичным фрагментом, относительно разрешения видео, представленного посредством составной видеодорожки, которая может задаваться следующим образом:
aligned(8) class TileMediaHeaderBox
extends FullBox("tmhd", version=0, 0) {
unsigned int(16) horizontal_offset;
unsigned int( 16) vertical_offset;
}
Как описано выше, составная дорожка содержит конкретное поле tref 312 ссылок на дорожки, которое предоставляет типизированную ссылку на другую дорожку в представлении. Согласно конкретному варианту осуществления, такие типизированные ссылки могут содержать ссылку (324) tile, которая может использоваться для того, чтобы устанавливать соединение из составной дорожки с дорожкой мозаичных фрагментов, к которой она обращается, и ссылку (326) seal, которая может использоваться для того, чтобы устанавливать соединение из дорожки, содержащей эту ссылку, с дорожкой синхронизированных мультимедийных данных, от которой она зависит (например, дорожкой базового слоя (trackID=1)).
Фиг. 4 иллюстрирует пример блок-схем файлов мультимедийных сегментов, содержащих дорожки мозаичных фрагментов и одну составную дорожку, согласно конкретному варианту осуществления, соответствующую дорожкам, объявленным в файле сегментов инициализации, таком как файл сегментов инициализации, показанный на фиг. 3. Как описано выше, файл сегментов инициализации, проиллюстрированный на фиг. 3, и файлы мультимедийных сегментов, проиллюстрированные на фиг. 4, иллюстрируют вариант осуществления изобретения, чтобы реорганизовывать и инкапсулировать поток видеобитов в базовом формате мультимедийных файлов по стандарту ISO, в то время как несколько дорожек передаются в потоковом режиме независимо.
Как проиллюстрировано на фиг. 4, каждый из файлов 400-1 - 400-6 мультимедийных сегментов (файлы 400-3 - 400-5 мультимедийных сегментов не показаны) содержит, как указано в DASH-стандарте, поле styp типов сегментов, обобщенно со ссылкой с номером 402 по меньшей мере одно поле moof кинофрагментов, обобщенно со ссылкой с номером на 404, и по меньшей мере одно поле mdat мультимедийных данных, обобщенно со ссылкой с номером 406. Файл мультимедийных сегментов ассоциирован с HTTP URL-адресом.
Следует отметить, что другие поля могут быть обязательными или необязательными в зависимости от спецификаций ISO BMFF, используемых для того, чтобы инкапсулировать поток битов синхронизированных мультимедийных данных. Тем не менее, поскольку варианты осуществления изобретения не основываются на этих полях в качестве применимых, они не представлены здесь.
Формат поля styp 402 типов сегментов является аналогичным формату поля ftyp 302 типов файлов на фиг. 3, тем не менее его ссылка указывает то, что файл представляет собой файл мультимедийных сегментов.
Поле 404 кинофрагментов предоставляет информацию, которая, в общем, сохраняется в кинополе moov. Его заголовок (mfhd) содержит порядковый номер (помечен seq_num на фиг. 4), который увеличивается для каждого кинофрагмента. Такой порядковый номер позволяет клиентскому устройству конкатенировать принятые файлы сегментов в порядке возрастания и верифицировать целостность последовательности (при необходимости). Поле 404 кинофрагментов содержит поле traf фрагментов дорожек (обобщенно со ссылкой с номером 408) для каждой дорожки, имеющей данные в ассоциированном поле (mdat, 406) мультимедийных данных. Поле 408 фрагментов дорожек содержит поле tfhd заголовков фрагментов дорожек обобщенно со ссылкой с номером 410, которое используется для того, чтобы сохранять идентификатор (trackID) потока битов дорожки, присутствующего в соответствующем поле (mdat, 406) мультимедийных данных.
Поле мультимедийных данных, в общем, содержит синхронизированные мультимедийные данные. В стандартных видеодорожках оно содержит видеокадры. В дорожках мозаичных фрагментов поле 406 мультимедийных данных содержит пространственно заданные подчасти полных видеокадров. Для иллюстрации, поле мультимедийных данных, ассоциированное с идентификатором дорожки track_ID=2, содержит все NAL-единицы, соответствующие мозаичному фрагменту улучшающего слоя.
В составной дорожке (track_ID=6 на фиг. 4), поле 406 мультимедийных данных содержит экстракторы (помечены E на фиг. 4) для каждого мозаичного фрагмента и для каждого зависимого слоя, и содержит NAL-единицы, общие для всех мозаичных фрагментов (если таковые имеются).
Как проиллюстрировано на фиг. 4, поле 406 мультимедийных данных файла 400-6 мультимедийных сегментов, ассоциированного с составной дорожкой, содержит, в частности:
- первый экстрактор 412-1, который предоставляет соединение с данными базового слоя (NAL-единицами 1 BL), кодированными в дорожке базового слоя, сохраненной в поле 406 мультимедийных данных файла 400-1 мультимедийных сегментов, ассоциированного с дорожкой базового слоя;
- NAL-единицы 412-2, которые являются общими для нескольких мозаичных фрагментов;
- второй экстрактор 412-3, который предоставляет соединение с данными улучшающего слоя (NAL-единицами 1a) первого мозаичного фрагмента, кодированного в поле 406 мультимедийных данных файла 400-2 мультимедийных сегментов, ассоциированного с первой дорожкой мозаичных фрагментов улучшающего слоя;
- третий экстрактор 412-4, который предоставляет соединение с данными улучшающего слоя (NAL-единицы 1b) второго мозаичного фрагмента, кодированного в поле 406 мультимедийных данных файла 400-3 мультимедийных сегментов (не показан), ассоциированного со второй дорожкой мозаичных фрагментов улучшающего слоя;
- четвертый экстрактор 412-5, который предоставляет соединение с данными улучшающего слоя (NAL-единицы 1c) третьего мозаичного фрагмента, кодированного в поле 406 мультимедийных данных файла 400-4 мультимедийных сегментов (не показан), ассоциированного с третьей дорожкой мозаичных фрагментов улучшающего слоя; и
- пятый экстрактор 412-6, который предоставляет соединение с данными улучшающего слоя (NAL-единицы 1d) четвертого мозаичного фрагмента, кодированного в поле 406 мультимедийных данных файла 400-5 мультимедийных сегментов (не показан), ассоциированного с четвертой дорожкой мозаичных фрагментов улучшающего слоя.
NAL-единицы, которые могут получаться благодаря экстрактору 412-1, обеспечивают декодирование базового слоя кадра, улучшающий слой которого может быть полностью декодирован с использованием NAL-единиц 412-2 и NAL-единиц, которые могут получаться благодаря экстракторам 412-3 - 412-6. Как можно видеть из фиг. 4, если только пространственная часть кадра должна декодироваться, необязательно загружать все файлы 400-2 - 400-5 мультимедийных сегментов (т.е. потоки битов, соответствующие дорожкам мозаичных фрагментов).
Согласно конкретному варианту осуществления, экстрактор является внутренней структурой формата файла, имеющей следующий синтаксис:
class aligned(8) Extractor {
NALUnitHeader();
unsigned int(8) track_ref_index;
signed int(8) sample_offset;
unsigned int((lengthSizeMinusOne+1)*8)
data_offset;
unsigned int((lengthSizeMinusOne+1)*8)
datalength;
}
где NALUnitHeader представляет первые четыре байта NAL-единицы, совместимой с форматом кодирования, используемым для того, чтобы кодировать поток видеобитов. Эти четыре байта идентифицируют NAL-единицу в качестве экстрактора (например, в SVC, атрибут nal_unit_type задается равным типу NAL-единицы-экстрактора (типу 31)).
Дорожка значения ref_index указывает индекс, который должен использоваться, в поле tref ссылок на дорожки типа seal или tile составной дорожки, для нахождения дорожки, из которой должны извлекаться данные. Значение sample_offset задает относительный индекс выборки в соединенной дорожке, которая должна использоваться в качестве источника информации. Значения data_offset и datalength представляют собой смещение первого байта в опорной выборке для копирования и число байтов для копирования, соответственно.
Для иллюстрации и со ссылкой на фиг. 3, если значение дорожки ref_index данного экстрактора равно 2, это означает то, что экстрактор ссылается на дорожку, идентифицированную посредством второй записи в поле tref (т.е. дорожку, имеющую идентификатор track_ID=2, которая представляет собой дорожку мозаичных фрагментов для мозаичного фрагмента a, при этом первый индекс представляет опорную дорожку (например, базовый слой)).
Фиг. 5 иллюстрирует пример конкатенации загруженных сегментов мультимедийных данных, чтобы компоновать допустимый декодируемый поток битов синхронизированных мультимедийных данных, представляющий пространственную часть последовательных видеокадров в течение данного временного периода (соответствующего здесь двум последовательным кадрам). Идентичный чертеж может повторяться для других временных периодов.
Как описано со ссылкой на фиг. 3 и 4, синхронизированный мозаичный поток битов мультимедийных данных предпочтительно передается в качестве набора данных, содержащего один файл сегментов инициализации и множество файлов мультимедийных сегментов, причем второй из них содержит несколько дорожек мозаичных фрагментов и одну составную дорожку.
Файл сегментов инициализации содержит кинополе (moov), которое предоставляет общую информацию относительно каждой дорожки, в частности, тип дорожки (например, мультимедийная дорожка (аудио или видео) или дорожка мозаичных фрагментов), формат кодирования, кадровое разрешение и зависимость между дорожками (представленные в поле tref ссылок на дорожки). Эти данные используются для того, чтобы обрабатывать загруженные файлы мультимедийных сегментов. Ссылаясь на пример, описанный со ссылкой на фиг. 1, 3 и 4, контент кинополя файла сегментов инициализации может содержать, в частности, следующее:
MOOV
track 1: base layer
track 2: tile a
track 3: tile b
track 4: tile c
track 5: tile d
track 6: enhancement layer
tref(seal): track_ID=1
tref(tile): track_ID=2
track_ID=3
track_ID=4
track_ID=5
Фиг. 5 примерно иллюстрирует формат файла, полученный посредством конкатенации мультимедийных сегментов, когда только требуемые файлы мультимедийных сегментов (соответствующий здесь базовому слою и мозаичным фрагментам a и c в улучшающем слое) загружаются из сервера. Следует отметить, что такой механизм не только обеспечивает загрузку только требуемых файлов мультимедийных сегментов, но он также и предотвращает загрузку дублированных данных.
Как проиллюстрировано, составная дорожка 500 обеспечивает компоновку допустимого декодируемого потока 502 битов синхронизированных мультимедийных данных посредством ссылки на данные из дорожки 504 базового слоя (в случае масштабируемости) и из невоспроизводимых дорожек (506 и 508) мозаичных фрагментов и посредством обработки надлежащим образом экстракторов, ссылающихся на отсутствующие данные (как описано со ссылкой на фиг. 7).
Полученный формат файла является совместимым с масштабируемым определением форматов файлов. Например, клиентское устройство может решать воспроизводить только базовый слой посредством выбора дорожки базового слоя или улучшающего слоя с выбранными мозаичными фрагментами a и c посредством выбора составной дорожки. Клиентское устройство также может изменять мозаичные фрагменты, которые должны отображаться, посредством загрузки различных "дорожек мозаичных фрагментов" (т.е. файлов мультимедийных сегментов) в последующий временной период, в то время как оно продолжает воспроизводить составной трек.
Фиг. 6, содержащая фиг. 6a и фиг. 6b, является блок-схемой последовательности операций способа, иллюстрирующей этапы для передачи синхронизированных мультимедийных данных между сервером и клиентским устройством согласно конкретному варианту осуществления. Этапы, показанные на фиг. 6a, реализуются на сервере, чтобы подготавливать мультимедийное представление посредством создания файлов сегментов, адаптированных к потоковой ROI-передаче из потока битов мозаичных синхронизированных мультимедийных данных, в то время как этапы, показанные на фиг. 6b, реализуются в клиентском устройстве.
На первом этапе (этап 600) сервер идентифицирует все NAL-единицы, которые ассоциированы с мозаичными фрагментами, и для каждого мозаичного фрагмента, создает дорожку мозаичных фрагментов, содержащую подвыборки, составленные из всех NAL-единиц, соответствующих данному мозаичному фрагменту. Например, сервер может основываться на SEI-сообщениях уровня субизображения, чтобы идентифицировать ассоциирование NAL-единиц с различными областями, и на SEI-сообщениях на уровне последовательности для идентификации позиции и размера каждой ROI, как предложено в стандартизации HEVC (проект JCTVC-K0128). Соответственно сервер может создавать конвейеры мозаичных фрагментов для данных периодов времени.
На следующем этапе (этап 602) сервер создает составную дорожку, содержащую экстракторы, соединенные с дорожками масштабируемости нижнего уровня (если таковые имеются), NAL-единицы, общие для всех мозаичных фрагментов, и экстракторы, соединенные с каждой дорожкой мозаичных фрагментов. Экстракторы и общие NAL-единицы преимущественно упорядочиваются таким образом, что замена экстракторов посредством данных, на которые они ссылаются, приводит к допустимому потоку битов синхронизированных мультимедийных данных, составленному из полных выборок в порядке декодирования (как описано со ссылкой на фиг. 1).
Затем, на этапе 604, сервер формирует и сохраняет файл сегментов инициализации и файлы мультимедийных сегментов, содержащие временной период согласно представлению ISO BMFF, как описано со ссылкой на фиг. 3 и 4. Все дорожки синхронизированных мультимедийных данных (например, видеодорожки), составные дорожки и дорожки мозаичных фрагментов сохраняются в отдельных файлах мультимедийных сегментов.
Сервер затем предоставляет, по запросу, файлы инициализации и мультимедийных сегментов в клиентское устройство (этап 606). Сервер может представлять собой традиционный HTT-сервер, который отвечает на HTTP-запросы.
В контексте потоковой HTTP-передачи и в предпочтительном варианте осуществления предполагается, что клиентское устройство имеет доступ к файлу манифеста, описывающему мультимедийное представление, доступное из сервера. Этот файл манифеста предоставляет достаточную информацию (мультимедийные свойства и список сегментов) для клиентского устройства, чтобы передавать в потоковом режиме мультимедийное представление посредством запроса сначала сегментов инициализации, а затем файлов мультимедийных сегментов из сервера.
После выбора ROI на стороне клиентского устройства, типично на дисплее со средством выбора, к примеру, указательным устройством, во время потоковой передачи мозаичного видео определяются мозаичные фрагменты, соответствующие выбранной ROI, (этап 608).
Затем, в течение каждого временного периода, в случае масштабируемых мультимедийных данных, клиентское устройство отправляет запрос на сервер, чтобы загружать файлы сегментов, соответствующие зависимым слоям (этап 610). Согласно конкретному варианту осуществления, слои, от которых исходит зависимость, загружаются до слоев, зависящих от слоев, от которых исходит зависимость. Например, файлы сегментов базового слоя загружаются до файлов сегментов улучшающего слоя.
На следующем этапе клиентское устройство отправляет запрос на сервер, чтобы загружать файлы мультимедийных сегментов, соответствующие выбранным мозаичным фрагментам (этап 612), и отправляет запрос на сервер, чтобы загружать файлы мультимедийных сегментов, соответствующие составной дорожке (этап 614).
Затем загруженные файлы сегментов конкатенируются посредством клиентского устройства, чтобы компоновать допустимый (декодируемый) поток битов синхронизированных мультимедийных данных, соответствующий ISO BMFF-стандарту (этап 616), соответствующему выбранной ROI.
Этап 616 подробно описывается со ссылкой на фиг. 7.
Фиг. 7 является блок-схемой последовательности операций способа, иллюстрирующей формирование допустимого потока битов синхронизированных мультимедийных данных из конкатенированных мультимедийных сегментов, принимаемых посредством клиентского устройства, другими словами, формирование декодируемого потока битов из выбранных мозаичных фрагментов и одной составной дорожки, когда составной трек воспроизводится посредством клиентского устройства.
На первом этапе (этап 700) клиентское устройство принимает файлы мультимедийных сегментов, которые ранее запрошены (например, этапы 612, 614 и 616 на фиг. 6), и тест выполняется для того, чтобы определять то, принят или нет по меньшей мере один файл мультимедийных сегментов (этап 702). Если файл мультимедийных сегментов не принят, процесс завершается.
Если по меньшей мере один файл мультимедийных сегментов принят, и если принятые файлы мультимедийных сегментов не содержат составную дорожку (т.е. они содержат зависимые дорожки, например, дорожки слоя нижнего уровня или мозаичных фрагментов), они буферизуются для последующего использования.
Наоборот, если по меньшей мере один мультимедийный сегмент принят, и если принимаемый файл мультимедийных сегментов содержит составную дорожку, поток битов (типично NAL-единицы), соответствующий составной дорожке, синтаксически анализируется, чтобы извлекать первый элемент данных (или следующий элемент данных, если по меньшей мере один элемент данных принимаемого мультимедийного сегмента обработан, типично NAL-единица) из поля mdat мультимедийных данных принимаемого мультимедийного сегмента (этап 704). Если отсутствуют дополнительные элементы данных для синтаксического анализа в поле мультимедийных данных, процесс возвращается к этапу 700, чтобы принимать новые файлы мультимедийных сегментов (этап 706).
Затем тест выполняется для того, чтобы определять то, соответствует или нет извлеченный элемент данных (например, извлеченная NAL-единица) экстрактору (этап 708). Если извлеченный элемент данных не соответствует экстрактору, он возвращается, поскольку он должен быть дополнительно декодирован посредством видеодекодера (этап 710). Наоборот, если извлеченный элемент данных представляет собой экстрактор, он должен быть заменен посредством элемента данных, на которые он ссылается. С этой целью, значения параметров экстрактора получаются из его структуры (этап 712). Как описано выше, экстрактор содержит все значения параметров, требуемые для того, чтобы извлекать данные из другой дорожки (например, track_ref_index, sample_offset, data_offset и data_length).
После того как идентификатор дорожки, на которую имеется ссылка, идентифицирован, тест выполняется (этап 714), чтобы определять то, доступна или нет дорожка, на которую имеется ссылка, в наборе файлов мультимедийных сегментов, буферизованных в ходе этапа 700. Следует напомнить, что некоторые дорожки мозаичных фрагментов отсутствуют, поскольку клиентское устройство загружает только файлы мультимедийных сегментов, соответствующие выбранной интересующей области.
Если дорожка, на которую имеется ссылка, доступна в наборе файлов мультимедийных сегментов, буферизованных в ходе этапа 700, экстрактор заменен посредством данных, на которые он ссылается (этап 716), и поток битов отправляется в видеодекодер для декодирования (этап 710).
Если дорожка, на которую имеется ссылка, не доступна в наборе файлов мультимедийных сегментов, буферизованных в ходе этапа 700, конкретные этапы должны выполняться, поскольку отсутствие данных, на которые ссылаются в экстракторе, приводит к фатальной ошибке согласно ISO BMF-стандарту. Тест выполняется для того, чтобы определять то, представляет собой или нет дорожка, на которую имеется ссылка, дорожку мозаичных фрагментов (дорожка, на которую имеется ссылка, может соответствовать зависимому слою масштабируемости), и то, имеет или нет экстрактор тип мозаичного фрагмента (этап 718).
Если дорожка, на которую имеется ссылка, не представляет собой дорожку мозаичных фрагментов, либо если экстрактор не имеет тип мозаичного фрагмента, стандартная фатальная ошибка обнаруживается. Наоборот, если дорожка, на которую имеется ссылка, представляет собой дорожку мозаичных фрагментов, и если экстрактор имеет тип мозаичного фрагмента, экстрактор удаляется (этап 722), или экстрактор заменяется посредством дополнения из альтернативной "дополняющей дорожки", или "дополняющего поля", содержащего "пропущенные" данные для пропущенных мозаичных фрагментов (этап 724), в зависимости от формата кодирования, используемого для того, чтобы кодировать поток битов синхронизированных мультимедийных данных (этап 720). Здесь, "пропущенные" данные представляют пиксельные данные, отсутствующие в текущем изображении, которые заменены посредством других пиксельных данных, полученных из ранее декодированного изображения, принадлежащего идентичному масштабируемому слою или принадлежащего другому масштабируемому слою. "Пропущенные" данные, в общем, представляются посредством по меньшей мере одного флага. Например, при рассмотрении HEVC-формата сжатия видео, дополняющие данные могут представлять собой одну или более NALU, которые исключительно содержат единицы кодирования, кодированные с помощью флага пропуска, заданного равным 1.
Затем поток битов передается в видеодекодер для декодирования (этап 710) и отображения, и процесс переходит к этапу 704, чтобы обрабатывать следующий элемент данных.
Фиг. 8 представляет блок-схему сервера или клиентского устройства 800, в котором могут реализовываться этапы одного или более вариантов осуществления.
Предпочтительно устройство 800 содержит шину 802 связи, центральный процессор 804 (CPU), допускающий выполнение инструкций из ROM 806 для программ при включении питания устройства и инструкций, связанных с приложением из основного запоминающего устройства 808, после включения. Основное запоминающее устройство 808 имеет, например, тип оперативного запоминающего устройства (RAM), который выступает в качестве рабочей области CPU 804 через шину 802 связи, и емкость запоминающего устройства этого может быть расширена посредством необязательного RAM, соединенного с портом расширения (не проиллюстрирован). Инструкции, связанные с приложением, могут загружаться в основное запоминающее устройство 808, например, с жесткого диска 810 (HD) или из ROM 806 для программ. Такое приложение при выполнении посредством CPU 804 инструктирует этапам, описанным со ссылкой на фиг. 6a, выполняться на сервере, и этапам, описанным со ссылкой на фиг. 6b и 7, выполняться в клиентском устройстве.
Ссылка с номером 812 представляет собой сетевой интерфейс, который обеспечивает соединение устройства 800 с сетью 814 связи. Приложение при выполнении посредством CPU 804 выполнено с возможностью реагировать на запросы, принятые через сетевой интерфейс, и предоставлять потоки данных и запросы через сеть в другие устройства.
Ссылка с номером 816 представляет пользовательские интерфейсы для того, чтобы отображать информацию и/или принимать вводы от пользователя.
Здесь следует отметить, что в качестве разновидности, устройство 800 для управления приемом или отправкой мультимедийных потоков битов может состоять из одной или более специализированных интегральных схем (ASIC), которые допускают реализацию способа, как описано со ссылкой на фиг. 6a, 6b и 7. Эти интегральные схемы для пример, и не в качестве ограничения интегрированы в устройство для формирования или отображения видеопоследовательностей и/или для прослушивания аудиопоследовательностей.
Как описано выше, вариант осуществления изобретения может применяться, в частности, к видеоформату, известному как HEVC.
Согласно HEVC-стандарту, изображения могут быть пространственно разделены на мозаичные фрагменты, серии последовательных макроблоков и сегменты серий последовательных макроблоков. В этом стандарте, мозаичный фрагмент соответствует прямоугольной области изображения, которая задается посредством горизонтальной и вертикальной границ (т.е. строк и столбцов). Он содержит целое число единиц дерева кодирования (CTU). Следовательно, мозаичные фрагменты могут быть эффективно использованы для того, чтобы идентифицировать интересующие области посредством задания, например, позиций и размеров для интересующих областей. Тем не менее структура HEVC-потока битов, а также его инкапсуляции в качестве единиц уровня абстрагирования от сети (NAL) не организована с учетом мозаичных фрагментов, а основана на сериях последовательных макроблоков.
В HEVC-стандарте, серии последовательных макроблоков представляют собой наборы сегментов серий последовательных макроблоков, причем первый сегмент серий последовательных макроблоков из набора сегментов серий последовательных макроблоков представляет собой независимый сегмент серий последовательных макроблоков, другими словами, сегмент серий последовательных макроблоков, для которого общая информация, сохраненная в заголовке, не ссылается на один из другого сегмента серий последовательных макроблоков. Другие сегменты серий последовательных макроблоков из набора сегментов серий последовательных макроблоков, если таковые имеются, представляют собой зависимые сегментами серий последовательных макроблоков (т.е. сегменты серий последовательных макроблоков, для которых общая информация, сохраненная в заголовке, ссылается на один из независимого сегмента серий последовательных макроблоков).
Сегмент серий последовательных макроблоков содержит целое число последовательных (в порядке растрового сканирования) единиц дерева кодирования. Следовательно, сегмент серий последовательных макроблоков может иметь либо не иметь прямоугольную форму и в силу этого он не подходит для того, чтобы представлять интересующую область. Он кодируется в HEVC-потоке битов в форме заголовка сегмента серий последовательных макроблоков, после которого находятся данные сегмента серий последовательных макроблоков. Независимые и зависимые сегменты серий последовательных макроблоков отличаются посредством своего заголовка: поскольку зависимый сегмент серий последовательных макроблоков зависит от независимого сегмента серий последовательных макроблоков, объем информации его заголовка меньше объем информации заголовка независимого сегмента серий последовательных макроблоков. Как независимые, так и зависимые сегменты серий последовательных макроблоков содержат список точек входа в соответствующем потоке битов, которые используются для того, чтобы задавать мозаичные фрагменты, либо в качестве точек синхронизации энтропийного декодирования.
Фиг. 9, содержащая фиг. 9a, 9b и 9c, иллюстрирует примеры мозаичных фрагментов и сегментов серий последовательных макроблоков. Более точно, фиг. 9a иллюстрирует изображение (900), разделенное на девять частей посредством вертикальных границ 905-1 и 905-2 и горизонтальных границ 910-1 и 910-2. Каждая из девяти частей со ссылками с номерами 915-1 - 915-9, представляет конкретный мозаичный фрагмент.
Фиг. 9b иллюстрирует изображение (900'), содержащее два вертикальных мозаичных фрагмента, разграниченные посредством вертикальной границы 905'. Изображение 900' содержит одну серию последовательных макроблоков (на которую нет ссылки), содержащую пять сегментов серий последовательных макроблоков, один независимый сегмент 920-1 серий последовательных макроблоков (представлен с помощью заштрихованных линий) и четыре зависимых сегмента 920-2 - 920-5 серий последовательных макроблоков.
Фиг. 9c иллюстрирует изображение (900"), содержащее два вертикальных мозаичных фрагмента, разграниченные посредством вертикальной границы 905". Левый мозаичный фрагмент содержит две серии последовательных макроблоков: первую серию последовательных макроблоков, содержащую один независимый сегмент (920'-1) серий последовательных макроблоков и один зависимый сегмент (920'-2) серий последовательных макроблоков, и вторую серию последовательных макроблоков, также содержащую один независимый сегмент (920'-3) серий последовательных макроблоков и один зависимый сегмент (920'-4) серий последовательных макроблоков. Правый мозаичный фрагмент содержит одну серию последовательных макроблоков, содержащую один независимый сегмент (920'-5) серий последовательных макроблоков и один зависимый сегмент (920'-6) серий последовательных макроблоков.
Согласно HEVC-стандарту, сегменты серий последовательных макроблоков соединяются с мозаичными фрагментами согласно правилам, которые могут обобщаться следующим образом (должны удовлетворяться одно или оба условия):
- все CTU в сегменте серий последовательных макроблоков принадлежат идентичному мозаичному фрагменту (т.е. сегмент серий последовательных макроблоков не может принадлежать нескольким мозаичным фрагментам); и
- все CTU в мозаичном фрагменте принадлежат идентичному сегменту серий последовательных макроблоков (т.е. мозаичный фрагмент может быть разделен на несколько сегментов серий последовательных макроблоков при условии, что каждый из этих сегментов серий последовательных макроблоков принадлежит только этому мозаичному фрагменту).
Для понятности, далее считается, что один мозаичный фрагмент содержит одну серию последовательных макроблоков, имеющую только один независимый сегмент серий последовательных макроблоков. Тем не менее, варианты осуществления изобретения могут выполняться с использованием других конфигураций, аналогичных конфигурациям, проиллюстрированным на фиг. 9b и 9c.
Как упомянуто выше, в то время как мозаичные фрагменты могут считаться надлежащей поддержкой для интересующих областей, сегменты серий последовательных макроблоков представляют собой объекты, которые фактически помещены в NAL-единицы для транспортировки по сети связи и агрегированы, чтобы формировать единицы доступа (т.е. кодированное изображение или выборки на уровне формата файла).
Следует напомнить, что согласно HEVC-стандарту, тип NAL-единицы кодируется в двух байтах заголовка NAL-единицы, который может задаваться следующим образом:
nal_unit_header() {
forbidden_zero_bit
nal_unit_type
nuh_layer id
nuh_temporal_id_plus 1
}
NAL-единицы, используемые для того, чтобы кодировать сегменты серий последовательных макроблоков, содержат заголовки сегмента серий последовательных макроблоков, указывающие адрес первой CTU в сегменте серий последовательных макроблоков благодаря элементу синтаксиса адреса сегмента серий последовательных макроблоков. Такие заголовки сегмента серий последовательных макроблоков могут задаваться следующим образом:
slice_segment_header () {
first_slice_segment_in_pic_flag
if(nal_unit_type >= BLA_W_LP andand nal_unit_type <= RSV_IRAP_VCL23) no_output_of_prior_pics_flag
slice_pic_parameter_set_id
if(!first_slice_segment_in_pic_flag){
if(dependent_slice_segments_enabled_flag)
dependent_slice_segment_flag
slice_segment_address
}
if(!dependent_slice_segment_flag){
[...]
Информация мозаичного размещения предоставляется в NAL-единице PPS (набора параметров изображения). Взаимосвязь между сегментом серий последовательных макроблоков и мозаичным фрагментом затем может быть выведена из этих параметров.
Хотя пространственное прогнозирование сбрасывается на границах мозаичных фрагментов (по определению), ничего не мешает мозаичному фрагменту использовать временные предикторы из другого мозаичного фрагмента в опорном кадре(ах). Соответственно, чтобы компоновать независимые мозаичные фрагменты, векторы движения для единиц прогнозирования преимущественно ограничены в мозаичном фрагменте, в ходе кодирования, так что они остаются в совместно размещенном мозаичном фрагменте в опорном кадре(ах). Помимо этого внутриконтурные фильтры (фильтры удаления блочности и фильтры на основе дискретизированного адаптивного смещения (SAO)) предпочтительно деактивированы на границах мозаичных фрагментов, так что уход ошибки не вводится при декодировании только одного мозаичного фрагмента. Следует отметить, что такое управление внутриконтурными фильтрами доступно в HEVC-стандарте. Оно задается в заголовке сегмента серий последовательных макроблоков с помощью флага, известного как loop_filter_across_tiles_enabled_flag. Посредством явного задания этого флага равным нулю, пикселы на границах мозаичных фрагментов не могут зависеть от пикселов, которые попадают на границу соседних мозаичных фрагментов. Когда эти два условия, связанные с векторами движения и с внутриконтурными фильтрами, удовлетворяются, мозаичные фрагменты могут рассматриваться "как независимо декодируемые мозаичные фрагменты" или "независимые мозаичные фрагменты".
Когда поток видеобитов кодирован как набор независимых мозаичных фрагментов, он в таком случае обеспечивает декодирование на основе мозаичных фрагментов между кадрами без риска отсутствующих опорных данных или распространения ошибок восстановления. Эта конфигурация затем позволяет восстанавливать только пространственную часть исходного видео, которое может соответствовать, например, интересующей области, проиллюстрированной на фиг. 2 (содержащей мозаичные фрагменты 3 и 7). Такая конфигурация может указываться в качестве дополнительной информации в потоке видеобитов с тем, чтобы указывать то, что декодирование на основе мозаичных фрагментов является надежным.
Согласно варианту осуществления изобретения, эффективный доступ к мозаичным фрагментам в контексте потоковой HTTP-передачи предоставляется посредством использования формата файлов ISO BMFF, применяемого к HEVC-стандарту. Соответственно каждый из независимых мозаичных фрагментов, которые должны кодироваться (например, каждый из двенадцати мозаичных фрагментов, представленных на фиг. 2), представлен посредством конкретной дорожки, называемой "дорожкой мозаичных фрагментов", как описано ниже со ссылкой на фиг. 10.
На эти дорожки мозаичных фрагментов содержатся ссылки (через поле tref ссылок на дорожки кинополя moov, содержащего определение для каждой из дорожек) в составной дорожке, которая соответствует HEVC-потоку битов в полном кадре, как проиллюстрировано на фиг. 10. Каждая дорожка мозаичных фрагментов содержит сжатые видеоданные, пакетируемые в NAL-единицах. Составная дорожка содержит различные наборы параметров (например, набор параметров видео, набор параметров последовательности и/или набор параметров изображения), соответствующие данным инициализации. Она также содержит экстракторы, которые представляют собой NAL-единицы конкретного типа.
Как описано выше, экстрактор может представлять собой внутреннюю структуру формата файла, имеющую следующий синтаксис:
class aligned(8) Extractor () {
NALUnitHeader();
unsigned int(8) track ref_index;
signed int(8) sample_offset;
unsigned int((lengthSizeMinusOne+1)*8)
data_offset;
unsigned int((lengthSizeMinusOne+1)*8)
data_length;
}
Экстрактор выступает в качестве указателей или ссылок на данные из других дорожек и обеспечивает компоновку компактных дорожек со ссылками на зависимые дорожки вместо дублирования данных в обеих дорожках. Экстрактор предпочтительно использует синтаксис NAL-единиц. Соответственно он содержит заголовок, имеющий структуру, идентичную структуре заголовка NAL-единицы, содержащего, в частности, информацию, связанную с типом NAL-единицы. Этот тип NAL-единицы задается, например, равным значению 47, в данный момент соответствующему зарезервированному типу NAL-единицы в HEVC. После заголовка находится индекс (обозначаемый как дорожка ref_index) в поле (tref) ссылок на дорожки, которое обеспечивает извлечение записи поля tref, которое содержит идентификатор дорожки (track_id), соответствующий дорожке, на которую ссылается экстрактор. Третий параметр представляет собой временное смещение (sample_offset) выборки, на которое ссылается экстрактор, по сравнению с текущей выборкой. Четвертый и пятый параметры (обозначаемые как data_offset и data_length), соответственно, предоставляют позицию (предпочтительно в байтах), с которой следует копировать, и объем данных для копирования (значение 0 зарезервировано, чтобы указывать копию всей NAL-единицы, на которую имеется ссылка).
Фиг. 10 иллюстрирует пример инкапсуляции HEVC-потока битов в качестве набора дорожек, содержащих составную дорожку и дорожки независимых мозаичных фрагментов, согласно варианту осуществления изобретения. Для иллюстрации, инкапсулированный поток битов соответствует видеопоследовательности, схематично проиллюстрированной на фиг. 2.
Как проиллюстрировано, инкапсулированный поток 1000 битов содержит файл 1005 сегментов инициализации, содержащий кинополе (moov), предоставляющее определения для дорожек, и файл 1010 мультимедийных сегментов, представляющий составную дорожку 1015 и двенадцать дорожек 1020-1 - 1020-12 мозаичных фрагментов (причем каждая из дорожек 1020-1 - 1020-12 мозаичных фрагментов ассоциирована с одним мозаичным фрагментом видеопоследовательности).
Составная дорожка 1015 содержит, как указано в DASH-стандарте, поле styp типов сегментов (не представлено) по меньшей мере одно поле moof 1025 кинофрагментов, содержащее метаданные, такие как тип сегмента дорожки и идентификатор, и по меньшей мере одно поле mdat 1030 мультимедийных данных, содержащее, для каждых видеоданных, выборки, PPS и ссылки на видеоданные.
Аналогично каждая из дорожек 1020-1 - 1020-12 мозаичных фрагментов содержит поле styp типов сегментов (не представлено) по меньшей мере одно поле moof кинофрагментов, содержащее метаданные, такие как тип сегмента дорожки и идентификатор, и по меньшей мере одно поле mdat мультимедийных данных, содержащее сжатые видеоданные, пакетируемые в NAL-единицах (NALU).
На дорожки 1020-1 - 1020-12 мозаичных фрагментов, имеющие идентификатор 2-13, содержатся ссылки в поле tref 1035 ссылок на дорожки файла 1005 сегментов инициализации (более точно, кинополя moov файла 1005 сегментов инициализации в определении составной дорожки, имеющей идентификатор id=1).
Как проиллюстрировано, составная дорожка 1015 содержит экстракторы, выступающие в качестве указателей или ссылок на данные из других дорожек. Для иллюстрации, представлены несколько параметров, в числе которых индекс (track_ref_index) дорожки мозаичных фрагментов, смещение (data_offset) данных и длина (data_length) данных, соответствующие экстракторам 1035-1 и 1035-p составной дорожки 1015.
Также для иллюстрации, когда NAL-единица 1035-1 составной дорожки 1015 обрабатывается, определяется то, что она представляет NAL-единицу типа экстрактора (NALUnitHeader равен шестнадцатеричному значению 5E00). Соответственно она обрабатывается, чтобы восстанавливать соответствующие сжатые видеоданные. С этой целью, ее индекс дорожки мозаичных фрагментов (т. е. track_ref_index=1) получается. Из этого индекса, можно восстанавливать идентификатор дорожки мозаичных фрагментов из определений дорожки мозаичных фрагментов, сохраненных в файле 1005 сегментов инициализации. В данном примере, поскольку индекс равен единице, первый идентификатор дорожки мозаичных фрагментов поля tref выбирается (id=2). Затем этот идентификатор используется для того, чтобы осуществлять доступ к соответствующей дорожке мозаичных фрагментов, и затем с использованием параметров смещения данных (т.е. относительного индекса выборки в идентифицированной дорожке, которая должна использоваться в качестве источника информации) и длины данных (т.е. числа байтов для копирования, например, вся NALU, когда data_length=0) экстрактора 1035-1, сжатые видеоданные извлекаются из дорожки 1020-1 мозаичных фрагментов (т.е. NALU 1040 кодированного сегмента серий последовательных макроблоков в данном примере).
После обработки, экстрактор заменен посредством данных, на которые он ссылается. Согласно примеру, проиллюстрированному на фиг. 10, синтаксический анализ и обработка экстрактора 1035-1 приводят к ее замене посредством NALU 1040 кодированного сегмента серий последовательных макроблоков, за счет этого формируя HEVC-совместимый поток битов.
Следует отметить, что семантика, используемая для сохранения параметров HEVC-экстрактора, может быть близкой к семантике, заданной в SVC-стандарте. Соответственно для экстрактора, ссылающегося на HEVC NAL-единицы, следующее может применяться:
- параметр, известный как forbidden_zero_bit, задается так, как указано в ISO/IEC 23008-2;
- параметр, известный как nal_unit_type, задается равным 47 (зарезервированный код в текущем FDIS);
- параметры, известные как nuh_layer_id и nuh_temporal_id_plus1, копируются из первой NALU, указываемой ссылкой в экстракторе (экстрактор в HEVC-дорожке, ссылающейся на HEVC NAL-единицы, не ссылается на несколько NAL-единиц с различными значениями nuh_layer_id и nuh_temporal_id_plus1); и
- параметр, известный как sample_offset, задается равным 0.
Согласно вариантам осуществления изобретения, дорожки мозаичных фрагментов должны рассматриваться как конкретные дорожки, используемые для того, чтобы поддерживать индексацию пространственно размещенных данных (например, мозаичных HEVC-фрагментов). Следовательно, конкретная передача служебных сигналов требуется для каждой дорожки, чтобы указывать, в частности, позицию мозаичного фрагмента в полном видео (горизонтальные и вертикальные координаты) и размер мозаичного фрагмента (ширину и высоту), и предоставлять информацию, чтобы указывать то, может или нет эта дорожка мозаичных фрагментов декодироваться без артефактов. Такая передача служебных сигналов может осуществляться согласно нескольким вариантам осуществления.
Согласно конкретному варианту осуществления, проиллюстрированному на фиг. 11, аналогично варианту осуществления, описанному выше, передача служебных сигналов может выполняться на уровне дорожки.
Фиг. 11 иллюстрирует пример блок-схем файла сегментов инициализации с использованием дорожек мультимедийных данных, согласно первому варианту осуществления, чтобы инкапсулировать HEVC-поток битов. Она основана на примере, описанном со ссылкой на фиг. 10.
Файл 1100 сегментов инициализации и файлы мультимедийных сегментов (не представлены) используются для того, чтобы реорганизовывать и инкапсулировать поток видеобитов, соответствующий HEVC-стандарту в базовом формате мультимедийных файлов по стандарту ISO. Дорожки передаются в потоковом режиме независимо.
Как описано выше, файл сегментов инициализации используется для того, чтобы передавать все метаданные, которые необходимы для того, чтобы задавать потоки битов синхронизированных мультимедийных данных, инкапсулированные в других файлах мультимедийных сегментов. Как проиллюстрировано на фиг. 11, файл 1100 сегментов инициализации содержит поле 1105 ftyp типов файлов и кинополе moov 1110. Поле 1105 типов файлов предпочтительно идентифицирует то, каким спецификациям ISO BMF соответствуют файлы сегментов, и указывает номер версии этой спецификации. Кинополе moov 1110 предоставляет все метаданные, описывающие представление, сохраненное в файлах мультимедийных сегментов, и, в частности, все дорожки, доступные в представлении.
Кинополе 1110 содержит определение для каждой из дорожек (поля 1115-1 - 1115-13 track), содержащих, в данном примере, одну составную дорожку (1115-1) и двенадцать дорожек (1115-2 - 1115-13) мозаичных фрагментов.
Каждое поле track содержит по меньшей мере поле tkhd заголовков дорожек, обобщенно со ссылкой с номером 1120, и поле mdia мультимедиа дорожек, обобщенно со ссылкой с номером 1125. Если дорожка зависит от данных из других дорожек, также предусмотрено поле tref ссылок на дорожки. Как проиллюстрировано, составная дорожка, имеющая идентификатор track_ID=1, содержит поле tref 1130 ссылок на дорожки, указывающее то, что дорожка зависит от данных из дорожек мозаичных фрагментов, имеющих идентификаторы track_ID=2-13.
Как упомянуто выше, следует отметить, что другие поля могут быть обязательными или необязательными в зависимости от спецификаций ISO BMFF, используемых для того, чтобы инкапсулировать поток битов синхронизированных мультимедийных данных. Тем не менее, поскольку варианты осуществления изобретения не основываются на этих полях в качестве применимых, они не представлены здесь.
Согласно варианту осуществления, описанному со ссылкой на фиг. 11, передача в служебных сигналах позиции мозаичного фрагмента в полном видео, размера мозаичного фрагмента и индикатора того, что дорожка мозаичных фрагментов может декодироваться без артефактов, выполняется один раз для всего HEVC-потока битов, который должен инкапсулироваться, в поле (1110) moov, в каждом определении дорожки, с использованием поля tkhd (1120) заголовков дорожек и полей для поля mdia (1125) мультимедийной информации.
Позиции мозаичных фрагментов размещены в новом типе поля 1135 информации заголовков мультимедиа, называемого "полем (1140) TileMediaHandlerEntry, или trmhd", которое задает горизонтальные и вертикальные смещения (horizontal_offset и vertical_offset).
Размер визуального представления рассматриваемого мозаичного фрагмента помещен в параметры ширины и высоты существующего заголовка дорожки. При необходимости реальные размеры в пикселах рассматриваемого мозаичного фрагмента могут быть задокументированы в описаниях выборок (через параметры, известные как VisualSampleEntry, в поле, известном как SampleDescriptionBox).
В завершение, передача в служебных сигналах конкретной дорожки (дорожки мозаичных фрагментов) явно выполняется посредством задания нового типа дорожки (tile) в поле hdlr (1145) обработчиков.
Кинополе moov 1110 файла 1100 сегментов инициализации дополнительно содержит поле 1150 mvex. Это поле используется для того, чтобы информировать клиента, осуществляющего доступ к инкапсулированному файлу, в отношении того, что присутствуют кинофрагменты. Оно позволяет указывать в файле сегментов инициализации длительность самой длинной дорожки в представлении. Это упрощает вычисление длительности представления с исключением анализа длительности каждого кинофрагмента. Как проиллюстрировано, поле 1150 mvex содержит поле расширения дорожки в расчете на дорожку во избежание дублирования информации, которая является общей для всех фрагментов каждой дорожки (т.е. дорожек мозаичных фрагментов и составной дорожки), например, идентификаторы дорожки и размер по умолчанию выборок в дорожке.
Следует отметить, что такой вариант осуществления передачи в служебных сигналах дорожек мозаичных фрагментов не вводит значимый объем служебной информации по сравнению с обычной передачей в служебных сигналах видеодорожек. Кроме того, он остается независимым от числа кинофрагментов, на которые разбивается представление. Тем не менее, он не адаптирован к варьирующейся конфигурации мозаичного размещения вдоль видеопоследовательности.
Согласно другому конкретному варианту осуществления, который выполнен с возможностью обрабатывать изменение в конфигурации мозаичного размещения вдоль видеопоследовательности, передача служебных сигналов выполняется на уровне выборки, с использованием механизмов группировки выборок из ISO BMFF-стандарта.
Такие механизмы группировки выборок используются для представления сегментов выборок в дорожках. Они основываются на использовании двух полей: поля SampleToGroup (sbgp), которое описывает назначение выборок для групп выборок, и поля SampleGroupDescription (sgpd), которое описывает общие свойства выборок в конкретной группе выборок. Конкретный тип группировки выборок задается посредством комбинации одного поля SampleToGroup и одного поля SampleGroupDescription через поле типа (grouping_type). Несколько экземпляров группировки выборок (т.е. пара полей SampleToGroup и SampleGroupDescription) могут существовать на основе различных критериев группировки.
Согласно вариантам осуществления изобретения, задается новый критерий группировки, связанный с мозаичным размещением выборок. Этот новый grouping_type, называемый "tile", описывает свойства мозаичного фрагмента и извлекается из стандартного VisualSampleGroupEntry. Он может упоминаться в качестве TileRegionSampleGroupEntry или HEVCSpatialEntry и задается следующим образом:
class HEVCSpatialEntryO extends VisualSampleGroupEntry ("trsg")
{unsigned int(32) tileID;
unsigned int(16) horizontal_offset;
unsigned int(16) vertical_offset;
unsigned int( 16) region_width;
unsigned int(16) region_height;
unsigned int(2) independent;
unsigned int(6) reserved=0;
}
Согласно этому новому типу записи группы, параметр tileID является уникальным идентификатором для мозаичного фрагмента, описанного посредством группы. Параметры horizontal_offset и vertical_offset используются для того, чтобы задавать горизонтальное и вертикальное смещение, соответственно, левого верхнего пиксела прямоугольной области, представленной посредством мозаичного фрагмента, относительно левого верхнего пиксела HEVC-кадра, в выборках сигнала яркости параметров базовой области, параметры ширины области и высоты области используются для того, чтобы задавать ширину и высоту, соответственно, прямоугольной области, представленной посредством мозаичного фрагмента, в выборках сигнала яркости HEVC-кадра, независимый параметр является 2-битовым словом, которое указывает то, что мозаичный фрагмент содержит зависимости при декодировании, связанные с выборками, принадлежащими только идентичному мозаичному фрагменту, как описано выше со ссылкой на определение независимых мозаичных фрагментов. Для иллюстрации и со ссылкой на стандартное использование SEI-сообщений для описания организации мозаичных фрагментов, флаг, известный как tile_section_exact_match_flag, может использоваться для того, чтобы задавать значение независимого флага. Его смысл может задаваться следующим образом:
- если независимый параметр равен 0, зависимости при кодировании между этим мозаичным фрагментом и другими мозаичными фрагментами в идентичном кадре или в предыдущих кадрах являются неизвестными;
- если независимый параметр равен 1, отсутствуют пространственные зависимости при кодировании между этим мозаичным фрагментом и другими мозаичными фрагментами в идентичном кадре, но могут быть зависимости при кодировании между этим мозаичным фрагментом и мозаичным фрагментом, имеющим идентичный tileID в предыдущих кадрах, и
- если независимый параметр равен 2, отсутствуют зависимости при кодировании между этим мозаичным фрагментом и другими мозаичными фрагментами, имеющими идентичное мозаичное размещение в идентичном кадре или в предыдущих кадрах;
- значение независимого параметра 3 зарезервировано.
Необязательно, параметр, описывающий среднюю скорость передачи битов в расчете на мозаичный фрагмент, может задаваться в дескрипторе мозаичного фрагмента, так что он предоставляется в клиент потоковой передачи для адаптации на основе полосы пропускания.
Согласно этому варианту осуществления, свойства каждого мозаичного фрагмента задаются один раз в кинозаголовке (поле moov) посредством задания, для каждой дорожки мозаичных фрагментов, одного поля SampleGroupDescription (sgpd) с типом группировки tile и HEVCSpatialEntry. Затем согласно ISO BMFF-стандарту, поле SampleToGroup задается в каждом фрагменте дорожки мозаичных фрагментов, чтобы ассоциировать каждую выборку фрагмента дорожки мозаичных фрагментов с его свойствами, поскольку число выборок не известно заранее.
В случае если сетка мозаичных фрагментов изменяется во времени, новое поле SampleGroupDescription (sgpd) с новым HEVCSpatialEntry может задаваться в поле (traf) фрагментов дорожек и указываться ссылкой посредством поля SampleToGroup (sbgp). Следовательно, в случае, согласно которому сетка является статической во времени по меньшей мере одно поле SampleToGroup задается в расчете на дорожку мозаичных фрагментов и фрагмент дорожки мозаичных фрагментов. Это поле представляет, с точки зрения описания по меньшей мере 28 байтов. При условии 16 мозаичных фрагментов с фрагментами с 2-секундной длительностью, это должно представлять 1792 бита в секунду для того, чтобы передавать конфигурацию мозаичного размещения во времени, только для поля SampleToGroup. В случае, согласно которому сетка изменяется во времени, затраты (с точки зрения объема данных) являются более высокими. Как описано ниже, этот объем дополнительных данных инициализации может уменьшаться.
Следует отметить, что поля группы выборок предоставляют эффективное и наращиваемое инструментальное средство, чтобы добавлять метаданные в отдельные выборки. Тем не менее распространенная практика заключается в том, что данные метаданные являются допустимыми для всех выборок данной дорожки, как может иметь место с дескриптором мозаичного размещения с фиксированным NALU-шаблоном в каждом AU (т.е. для статической конфигурации мозаичного размещения во времени).
Это может указываться посредством установки флага, соответственно, каждой выборки группы с использованием поля SampleToGroup.
Альтернативно, для того чтобы уменьшать объем данных инициализации в расчете на дорожку мозаичных фрагментов, некоторые группы выборок могут помечаться как " по умолчанию" (т.е. допустимые для всех выборок). Эта группировка по умолчанию ограничивает затраты на описание с точки зрения байтов, поскольку для статической конфигурации мозаичного размещения, она задается на уровне поля moov, один раз в расчете на дорожку для всей последовательности.
С этой целью вторая версия (version=2) типа описания группы может использоваться в поле, известном как SampleGroupDescriptionBox (может быть предусмотрено несколько SampleGroupDescriptionBox в расчете на поле traf/stbl), указывающем (через параметр, известный как тип группировки) то, что группа выборок, на которые имеется ссылка, применяется ко всем выборкам в текущей дорожке или в текущих фрагментах дорожек.
Новая версия поля описания групп выборок может задаваться следующим образом:
aligned(8) class SampleGroupDescriptionBox (unsigned int (32) handler type) extends FullBox("sgpd", version, 0) {
unsigned int(32) grouping type;
if (version ==1) // (version==2) {unsigned int (32) defaultlength;}unsigned int (32) entry count;
int i;
for ( i = 1; i <= entry count; i++) {
if (version != 0) {
if (default_length==0) {
unsigned int(32) description length;
}
}
switch(handler_type) {
case "vide": //для видеодорожек
VisualSampleGroupEntry(grouping type);
break;
case "soun": //для аудиодорожек
AudioSampleGroupEntry(grouping type);
break;
case "hint": //для дорожек с подсказками
HintSampleGroupEntry(grouping type);
break;
Согласно этому расширенному типу поля SampleGroupDescription, когда версия равна 2, это описание группы и любой SampleGroupEntry применяются ко всем выборкам текущей дорожки или фрагмента дорожки. Параметр типа группировки является целым числом, которое идентифицирует поле SampleToGroup, которое ассоциировано с этим описанием групп выборок. Следует отметить, что когда дорожка или фрагмент дорожки содержит в своих данных инициализации поле SampleGroupDescription с version=2, нет необходимости вставлять их данные инициализации поле SampleToGroup, описывающее соответствующий тип группировки (поскольку описание применяется ко всем выборкам по определению).
В этом определении новой версии поля описания групп выборок, счетчик записей является целым числом, которое задает число записей в следующей таблице, defaultlength указывает длину каждой записи группы (если длина является постоянной) или нуль, если она является переменной, и description length указывает длину отдельной записи группы в случае, если она варьируется в зависимости от записи, и в силу этого defaultlength равно нулю.
Согласно этому варианту осуществления, тип группировки может иметь конкретное значение, чтобы указывать пространственную группировку мозаичных фрагментов: он может представлять собой, например, шестнадцатеричное значение, соответствующее ASCII-коду для tile (0x74696C65). Самое большее одно возникновение этого поля с идентичным значением для типа группировки должно существовать для дорожки.
Следует отметить, что в случае перемещения адаптивной сетки во времени, поле выборок для группировки остается идентичным (т.е. тип группировки tile) и продолжает применяться ко всем выборкам. В связи с этим, только поле описания групп выборок должно обновляться во фрагментах дорожек для дорожек мозаичных фрагментов, конфигурация мозаичного размещения которых изменена с конфигурации по умолчанию, передаваемой в служебных сигналах в поле moov/trak/mdia/minf/stbl. Это уменьшает затраты на передачу служебных сигналов для адаптивных мозаичных фрагментов.
Альтернативно и при этом для того, чтобы уменьшать объем данных инициализации в расчете на дорожку мозаичных фрагментов (чтобы не допускать повторения поля SampleToGroup в каждом фрагменте дорожки мозаичных фрагментов), новое поле DefaultSampleToGroups, называемое "dsgp" (или другое аналогичное поле, имеющее идентичную семантику, безотносительно своего названия), задается для включения только в поле SampleTable (stbl) из каждого поля moov/trak в качестве части информации инициализации. Это новое поле должно ассоциировать, со всеми выборками, набор описаний групп выборок, которые должны применяться ко всем выборкам в дорожке.
Новое поле DefaultSampleToGroup может задаваться следующим образом:
aligned(8) class DefaultSampleToGroups extends FullBox("dsgp", version, 0) {
unsigned int(32) entry count;
for (i=1; i<=entry count; i++) {
unsigned int(32) grouping type;
if (version==1) {
unsigned int(32) grouping_type_parameter;
}
unsigned int(32) group_description_index;
}
}
где параметр счетчика записей задает число записей в списке групп, которые должны быть ассоциированы с каждой выборкой, и параметр типа группировки представляет собой идентификатор для типа группировки, на которую содержится ссылка в поле SampleGroupDescription. Например, в конкретном варианте осуществления тип группировки может иметь конкретное значение, указывающее пространственную группировку мозаичных фрагментов. Он может представлять собой, например, шестнадцатеричное значение, соответствующее ASCII-коду для tile (0x74696C65). Параметр group_description_index является целым числом, которое задает индекс записи группы выборок, которая описывает выборки в этой группе. Индекс варьируется от единицы до числа записей группы выборок в поле SampleGroupDescription либо принимает значение нуль, чтобы указывать то, что эта выборка не является элементом ни одной из групп этого типа. В завершение, параметр grouping_type_parameter представляет собой индикатор для подтипа группировки (если используется посредством типа группировки).
Это позволяет передавать в служебных сигналах то, что все выборки из дорожки находятся после идентичного описания группы для данного типа группировки, с использованием самое большее 32 байтов в расчете на мозаичный фрагмент безотносительно числа кинофрагментов, если только группировка мозаичных фрагментов используется (entry_count^). В случае перемещения адаптивной сетки во времени, новое поле DefaultSampleToGroups и новое поле SampleGroupDescription могут задаваться во фрагментах дорожек. Новое поле DefaultSampleToGroups заменяет предыдущее определение и ссылается на новое описание мозаичного фрагмента в новом поле SampleGroupDescription. Таким образом, поле SampleToGroup задается не для каждого фрагмента дорожки, а только когда изменяется определение сетки мозаичных фрагментов.
Также согласно конкретному варианту осуществления, который выполнен с возможностью обрабатывать изменение в конфигурации мозаичного размещения вдоль видеопоследовательности, передача служебных сигналов выполняется на уровне подвыборки с новым полем карты выборок.
Этот вариант осуществления для описания выборок относительно конфигурации мозаичного размещения применяется к однодорожечному инкапсулированному мозаичному HEVC-потоку битов. Он может находить применение для MPEG-4-инкапсуляции мозаичного HEVC-потока битов или на стороне клиента после разрешения экстракторов составной дорожки, чтобы сохранять загруженные пространственные части в одной видеодорожке, соответствующей MPEG-4-стандарту. Другой вариант применения, если направлен на преобразование составной дорожки в стандартную одну дорожку, соответствующую MPEG-4, нацелен на синтаксический MPEG-4-анализатор, который не поддерживает экстракторы.
Фиг. 12, содержащая фиг. 12a и фиг. 12b, иллюстрирует передачу в служебных сигналах позиции мозаичного фрагмента в полном видео, размера мозаичного фрагмента и индикатора того, что дорожка мозаичных фрагментов может декодироваться без артефактов, на уровне подвыборки, адаптированную с возможностью обрабатывать различную конфигурацию мозаичного размещения.
Фиг. 12a иллюстрирует этапы, выполняемые посредством клиентского устройства (например, видеопроигрывателя). На первом этапе (этап 1200), клиентское устройство загружает данные инициализации или считывает данные инициализации, если файл представляет собой локальный файл, например, данные инициализации инкапсулированного потока битов, соответствующего MPEG-4-стандарту, типично контент поля moov.
Из этих данных инициализации, клиентское устройство может синтаксически анализировать информацию заголовков дорожек, в которой кодируется информация мозаичных фрагментов (этап 1205). С помощью этой информации мозаичных фрагментов пользователь может выбирать интересующую область через графический интерфейс клиентского устройства (этап 1210), который может соответствовать одному или более мозаичным фрагментам.
Соответствующие дорожки мозаичных фрагментов, а также составная дорожка загружаются или считываются посредством клиентского устройства (этапы 1215 и 1220). Затем экстракторы составных дорожек разрешаются с использованием дорожек мозаичных фрагментов, с тем чтобы получать одну видеодорожку (этап 1225). В завершение, клиентское устройство компонует и добавляет описание мозаичного размещения, например, в SampleTableBox, в полученной видеодорожке (этап 1230).
Пример описания мозаичного размещения проиллюстрирован на фиг. 12b. Как проиллюстрировано, описание 1250 мозаичного размещения содержит кинополе moof 1255 и поле 1260 mdat данных. Поле moof 1255 содержит одно поле SampleTable в расчете на дорожку, которое содержит поле 1265 SampleToGroup, которое описывает различные группы выборок, поле 1270 описания групп выборок, которое описывает преобразование между NAL-единицами каждой выборки и мозаичными фрагментами, и поле 1275 описания групп выборок, которое содержит описания мозаичных фрагментов. Поле 1265 выборок для группировки указывает тип группировки tsgm для записи TileNALUMapEntry группы.
Запись 1270 TileNALUMapEntry группы задает преобразование между NAL-единицами выборки и мозаичными фрагментами (это является причиной, по которой такой вариант осуществления обращается к передаче служебных сигналов на уровне подвыборки). Это поле, параметр типа группировки которого равен tsgm, содержит число NAL-единиц в расчете на выборку.
Поле TileNALUMapEntry может задаваться следующим образом (как проиллюстрировано на фиг. 12b):
class TileNALUMapEntry() extends VisualSampleGroupEntry ("tsgm") {unsigned int(8) reserved = 0;
unsigned int(8) entry count;
for (i=1; /<=entry count; i++)
unsigned int(32) reserved;
где счетчик записи указывает число NALU в выборке дорожки, и tileID предоставляет уникальный идентификатор для пространственного мозаичного фрагмента, описанного посредством текущей дорожки.
Поле TileNALUMapEntry также может быть оптимизировано, с точки зрения размера, следующим образом:
class TileNALUMapEntry() extends VisualSampleGroupEntry ("tsgm") {unsigned int(6) reserved = 0;
unsigned int(1) large_size;
unsigned int( 1) mode;
if (large_size) {
unsigned int(16) entry count;
} else {
unsigned int(8) entry count;
for (i=1; /<=entry count; i++)
if (mode) {
if (large_size) {
unsigned int(16) NALU_start_number;
} else {
unsigned int(8) NALU_start_number;
}
}
unsigned int(16) tileID;
где параметр large_size указывает то, представлено число записей NAL-единиц в выборках дорожки в 8 или 16 битах, и параметр режима указывает то, описывается каждая запись NAL-единицы (когда режим не задается) либо только записи NAL-единиц, соответствующие изменению идентификатора мозаичного (когда режим задается). Во втором случае, номер NAL-единицы кодируется в 16 или 8 битах в зависимости от значения параметра large_size.
Он указывает преобразование между каждой из этих NAL-единиц и конкретным мозаичным фрагментом. Описание мозаичного фрагмента предоставляется в поле 1275 описания групп выборок, как описано выше, при этом каждый мозаичный фрагмент описывается по очереди.
Следует отметить, что данный пример является конкретным случаем, когда одна NAL-единица содержит данные для одного мозаичного фрагмента и вдоль длительности последовательности. Когда данные мозаичного фрагмента разбиваются по нескольким NAL-единицам, несколько агрегаторов используются для описания набора NAL-единиц, соответствующих мозаичному фрагменту. Когда число NAL-единиц варьируется во времени, несколько записей tileSampleMap могут задаваться, и выборки для группировки ссылаются, альтернативно, между фрагментами, в заголовке фрагмента дорожки, на надлежащую запись карты мозаичных фрагментов через тип группировки.
В схеме инкапсуляции данных, описанной со ссылкой на фиг. 10, HEVC-поток битов инкапсулируется в качестве составной дорожки 1015, которая указывает на дорожки 1020-1 - 1020-2 мозаичных фрагментов, фактически содержащие сжатые видеоданные. Составная дорожка содержит конфигурационные данные, исходящие из различных HEVC NAL-единиц набора параметров (обозначается как PS на фиг. 10). Другие элементы составной дорожки, главным образом, состоят из списка экстракторов, один в расчете на выборку и в расчете на дорожку мозаичных фрагментов, указывающих (через поле (tref) ссылок на дорожки, содержащееся в поле moov файла 1005 сегментов инициализации), на сжатые видеоданные, инкапсулированные в дорожках мозаичных фрагментов.
Текущие средства передачи в служебных сигналах зависимостей в ISO BMFF-стандарте (часть 15 стандарта) расположены в поле tref ссылок на дорожки, которое является частью полей track в поле moov файла 1005 сегментов инициализации. Поле tref предоставляет ссылку из вложенной дорожки на другую дорожку в представлении. Вложенная дорожка может ссылаться на несколько других дорожек в представлении. Тип зависимости между дорожками указывается посредством параметра reference_type, который может принимать два значения seal или sbas в действующем стандарте, значение sbas означает масштабируемое основание. Оно указывает то, что дорожка, на которую имеется ссылка, является масштабируемой базовой дорожкой текущей дорожки в масштабируемом представлении, значение seal означает масштабируемость. Оно указывает взаимосвязь между дорожками, представляющими различные слои масштабируемого представления. Оно означает то, что вложенная дорожка зависит от дорожки, на которую имеется ссылка.
В варианте осуществления, описанном со ссылкой на фиг. 10, отсутствуют конкретные связанные с масштабируемостью зависимости. Даже если масштабируемые видео могут учитываться, внимание здесь акцентируется на пространственных зависимостях между составной дорожкой и дорожками мозаичных фрагментов. Эти зависимости могут явно указываться, например, с новым значением tile, как задано в поле tref поля moov файла 1005 сегментов инициализации, соответствующего составной дорожке 1015 (id=1).
Хотя проиллюстрированный пример зависимостей от одной дорожки на другие дорожки направлен на мозаичные фрагменты (т.е. зависимости от одной составной дорожки на дорожки мозаичных фрагментов), другие типы одной дорожки на одну или нескольких дорожек могут обрабатываться аналогично. Следовательно, параметр reference_type может указывать, например, зависимость от подслоя (например, значение subl), чтобы указывать то, что дорожка зависит от одной или более дорожек.
Соответственно дорожки подслоя могут задаваться как дорожки, содержащие части элементарного HEVC-потока битов, которые могут отбрасываться без нарушения процесса декодирования других HEVC NAL-единиц. Такое определение применяется, в частности, к временным слоям в потоках битов масштабируемого HEVC, а также к дорожкам мозаичных фрагментов, как описано выше. Каждая дорожка, соответствующая дорожке подслоя, может помечаться в записи HEVCConfiguration (т.е. в SampleTableBox) с использованием бита (или флага), который, когда задан равным предварительно определенному, значению указывает то, что эта HEVC-дорожка представляет собой дорожку подслоя, и содержит только NAL-единицы, на которые содержатся ссылки в другой дорожке(ках) (т.е. эта HEVC-дорожка не является отображаемой), например, из составной дорожки. Когда значение этого бита или флага имеет противоположное значение, оно указывает то, что эта HEVC-дорожка представляет собой дорожку подслоя, которая также содержит данные инициализации (т.е. эта HEVC-дорожка является отображаемой). Например, можно использовать зарезервированные биты в текущем поле HEVCDecoderConfigurationRecord.
Согласно конкретному варианту осуществления, описанному со ссылкой на фиг. 12, каждая дорожка мозаичных фрагментов является воспроизводимой в качестве стандартной видеодорожки.
Фиг. 13 иллюстрирует пример инкапсуляции HEVC-потока битов в качестве набора дорожек, содержащих составную дорожку и дорожки независимых мозаичных фрагментов, которые являются воспроизводимыми в качестве стандартных видеодорожек, согласно варианту осуществления изобретения. Для иллюстрации, инкапсулированный поток битов соответствует видеопоследовательности, схематично проиллюстрированной на фиг. 2.
Инкапсуляция HEVC-потоков битов, проиллюстрированная на фиг. 13, отличается от инкапсуляции HEVC-потоков битов, проиллюстрированной на фиг. 10, главным образом тем, что каждая дорожка мозаичных фрагментов содержит конкретный экстрактор, который обеспечивает восстановление данных инициализации и конфигурационных данных.
Как проиллюстрировано, каждая из дорожек 1300-1 - 1300-12 мозаичных фрагментов содержит экстрактор 1305-1 - 1305-12, который указывает на HEVC NAL-единицы набора параметров (обозначаемого как PS) составной дорожки 1310, представляющей данные инициализации и конфигурационные данные, при этом следует напомнить, что согласно HEVC-стандарту, эти данные инициализации и конфигурационные данные типично соответствуют различным наборам параметров HEVC-потока битов. Соответственно такие данные инициализации и конфигурационные данные делают каждую дорожку мозаичных фрагментов воспроизводимой в качестве нормальной видеодорожки.
Экстрактор, добавляемый в каждую дорожку мозаичных фрагментов, преимущественно находится в начале поля mdat мультимедийных данных каждой дорожки мозаичных фрагментов перед выборками видеоданных.
Эти зависимости от дорожек (1300-1 - 1300-12) мозаичных фрагментов с составной дорожкой (1310), обозначаемые как 1315-1 - 1315-12, должны передаваться в служебных сигналах, например, в параметре reference_type полей tref 1320-1 - 1320-12, ассоциированных с дорожками мозаичных фрагментов (в кинополе moov файла 1325 сегментов инициализации). Согласно этому варианту осуществления, дорожка, содержащая набор параметров, рассматривается как базовая HEVC-дорожка hbas (это близко к SVC-случаю, в котором дорожка, которая содержит наименьшую рабочую точку в масштабируемом представлении, рассматривается как масштабируемая базовая дорожка sbas). Как проиллюстрировано, дорожки в зависимости от базовой дорожки (т.е. дорожки 1300-1 - 1300-12 мозаичных фрагментов, имеющие идентификаторы id=2 - 12, в зависимости от составной дорожки 1310, имеющей идентификатор id=1), имеют значение hbas в поле (1320-1 - 1320-12) ссылок на дорожки.
С другой стороны, передача в служебных сигналах мозаичного размещения может выполняться на уровне дорожки, на уровне выборки или на уровнях дорожки и выборки.
Следует отметить, что по умолчанию дорожки мозаичных фрагментов считаются неотображаемыми. Тем не менее, усовершенствованный синтаксический анализатор, соответствующий MPEG-4-стандарту, может обнаруживать отображаемые дорожки мозаичных фрагментов и представлять их, например, в файле манифеста потоковой передачи посредством рассмотрения поля tref (если дорожка мозаичных фрагментов содержит ссылочный тип типа hbas, она может рассматриваться как отображаемая). Это означает то, что эта дорожка мозаичных фрагментов может рассматриваться как стандартная видеодорожка, даже если помечена значением tile в поле обработчиков. Когда передача в служебных сигналах мозаичного размещения основана на выборках, дорожки мозаичных фрагментов или дорожки подслоя могут быть тегированы в качестве "vide" в поле обработчиков, поскольку информация мозаичного размещения помещена в поле, известное как SampleTableBox.
Фиг. 14 иллюстрирует пример инкапсуляции HEVC-потока битов в качестве набора дорожек, содержащих составную дорожку, дорожку данных инициализации и дорожки независимых мозаичных фрагментов, которые являются воспроизводимыми в качестве стандартных видеодорожек, согласно другому варианту осуществления изобретения. Для иллюстрации, инкапсулированный поток битов соответствует видеопоследовательности, схематично проиллюстрированной на фиг. 2.
Инкапсуляция HEVC-потоков битов, проиллюстрированная на фиг. 14, отличается от инкапсуляции HEVC-потоков битов, проиллюстрированной на фиг. 13, тем, что данные инициализации помещены в выделенную дорожку 1400 данных инициализации (а не в составную дорожку 1310).
Одно из преимуществ, предоставленных посредством такого варианта осуществления, по сравнению с вариантом осуществления, описанным со ссылкой на фиг. 13, нацелено на объем данных, которые должны передаваться, когда дорожки мозаичных фрагментов должны воспроизводиться независимо. Поскольку данные инициализации передаются в выделенной дорожке, они не запрашиваются для того, чтобы передавать составную дорожку.
Следует напомнить, что согласно текущей спецификации HEVC-формата файлов, предусмотрено два варианта передавать наборы параметров (PS) в формате файла: в поле, известном как SampleEntryonly, либо в поле SampleEntry и в выборках данных. Эти две конфигурации, соответственно, переданы в служебных сигналах с полями hvcV и hevV в поле, известном как SampleTable. Хотя сохранение параметров в выборках является более сложным, оно обеспечивает больший динамизм в случае обновлений наборов параметров. Следовательно, в предпочтительном варианте осуществления наборы параметров передаются в поле SampleEntry и в выборках данных (со значением hev1 в параметре HEVCSampleEntries в поле SampleTable), чтобы иметь возможность обрабатывать изменения наборов параметров изображения (PPS), в частности, для изменений конфигурации мозаичного размещения.
Соответственно выделенная дорожка 1400 данных инициализации содержит в качестве данных только не-VCL HEVC NAL-единицы, такие как NAL-единицы, тип которых равен 32, 33 или 34, соответствующие набору параметров видео, набору параметров последовательности или набору параметров изображения, соответственно.
Как проиллюстрировано на фиг. 14, экстракторы 1415-1 - 1415-12, расположенные в начале поля mdat мультимедийных данных дорожек 1410-1 - 1410-12 мозаичных фрагментов, указывают на данные выделенной дорожки 1400 данных инициализации. Аналогично первый экстрактор (1420) составной дорожки 1405 указывает на данные выделенной дорожки 1400 данных инициализации. Следовательно, дорожка 1400 данных инициализации является единственной дорожкой инкапсулированного HEVC-потока битов, которая вообще не ссылается ни другие дорожки. В связи с этим, поскольку отсутствуют зависимости, указываемые в поле tref (отсутствует зависимость от hbas в поле tref), ассоциированном с дорожкой 1400 данных инициализации (id=2), она считается неотображаемой независимо.
Когда некоторые данные инициализации модифицируются в потоке видеобитов (т.е. когда наборы параметров изображения возникают в HEVC-потоке битов), они помещены в дискретизированные данные, как проиллюстрировано со ссылкой 1425, во временном местоположении, в котором возникают изменения. Соответствующие экстракторы со ссылками с номерами 1430 и 1435-1 - 1435-12 вставляются в составной дорожке 1405 и в каждой из дорожек 1410-1 - 1410-12 мозаичных фрагментов, соответственно, другими словами, в каждой дорожке мозаичных фрагментов, ссылающейся на новый PPS.
В каждой дорожке инкапсулированного HEVC-потока битов, выборки (и ассоциированные NALU) организованы во временном порядке. Аналогично наборы параметров изображения организованы во временном порядке в выделенной дорожке 1400 данных инициализации. Поле trun (не представлено на фиг. 14) обеспечивает предоставление корректного времени декодирования для каждой выборки.
Безусловно, для того чтобы удовлетворять локальные и специальные требования, специалисты в данной области техники могут применять к решению, описанному выше, множество модификаций и изменений, все из которых тем не менее включены в пределы объема защиты изобретения, заданного посредством прилагаемой формулы изобретения.
Изобретение относится к области техники инкапсуляции синхронизированных мультимедийных данных, например, согласно базовому формату мультимедийных файлов MPEG. Техническим результатом является обеспечение организации данных и описания дорожек для пространственных мозаичных фрагментов, которая обеспечивает, безотносительно того, какая комбинация дорожек выбирается посредством клиентского приложения, то, что результат синтаксического ISO BMFF-анализа всегда приводит к допустимому элементарному потоку видеобитов для видеодекодера. Предложен cпособ формирования мультимедийного файла, содержащего область мультимедийных данных и область метаданных, в котором мультимедийные данные содержат множество выборок, причем каждая выборка содержит один или более пространственных мозаичных фрагментов, и формируют мультимедийный файл, в котором множество единиц уровня абстрагирования от сети (NAL), основанных на полученных мультимедийных данных, описываются в области мультимедийных данных, и информация о мозаичных фрагментах, которая указывает информацию, относящуюся к одному или более пространственным мозаичным фрагментам, соответствующим множеству единиц NAL, описанных в области мультимедийных данных, описывается в области метаданных. 2 н. и 10 з.п. ф-лы, 19 ил.
1. Способ формирования мультимедийного файла, содержащего область мультимедийных данных и область метаданных, причем способ содержит этапы, на которых:
- получают мультимедийные данные, содержащие множество выборок, причем каждая выборка содержит один или более пространственных мозаичных фрагментов;
- формируют мультимедийный файл, в котором множество единиц уровня абстрагирования от сети (NAL), основанных на полученных мультимедийных данных, описываются в области мультимедийных данных, и информация о мозаичных фрагментах, которая указывает информацию, относящуюся к одному или более пространственным мозаичным фрагментам, соответствующим множеству единиц NAL, описанных в области мультимедийных данных, описывается в области метаданных.
2. Способ формирования по п.1, причем информация о мозаичных фрагментах включает в себя:
- информацию об идентификаторе мозаичных фрагментов для идентификации каждого из множества пространственных мозаичных фрагментов, соответствующих одной выборке;
- информацию о ширине мозаичных фрагментов для идентификации ширины каждого из множества пространственных мозаичных фрагментов, соответствующих одной выборке; и
- информацию о высоте мозаичных фрагментов для идентификации высоты каждого из множества пространственных мозаичных фрагментов, соответствующих одной выборке.
3. Способ формирования по п.2, причем информация о мозаичных фрагментах включает в себя:
- информацию о смещении мозаичных фрагментов для идентификации смещения каждого из множества пространственных мозаичных фрагментов, соответствующих одной выборке.
4. Способ формирования по п.2, причем информация о мозаичных фрагментах дополнительно содержит параметр для передачи сигнала о зависимостях при декодировании одного или более пространственных мозаичных фрагментов от других пространственных мозаичных фрагментов.
5. Способ формирования по п.4, причем упомянутый параметр задается равным одному значению, выбранному из следующих значений:
- первое значение для передачи сигнала о том, что зависимости при кодировании между одним или более пространственными мозаичными фрагментами и другими мозаичными фрагментами в одной и той же выборке или в предыдущих выборках неизвестны;
- второе значение для передачи сигнала о том, что не существует зависимостей при пространственном кодировании между одним или более пространственными мозаичными фрагментами и другими мозаичными фрагментами в одной и той же выборке, но могут существовать зависимости при кодировании между одним или более пространственными мозаичными фрагментами и пространственным мозаичным фрагментом, имеющим такой же идентификатор мозаичного фрагмента в предыдущих выборках;
- третье значение для передачи сигнала о том, что не существует зависимостей при кодировании между одним или более пространственными мозаичными фрагментами и другими мозаичными фрагментами, имеющими такой же идентификатор мозаичного фрагмента в одной и той же выборке или в предыдущих выборках;
- четвертое значение для передачи сигнала о зарезервированном значении.
6. Способ формирования по п.5, причем упомянутый параметр является 2-битовым параметром, и первое, второе, третье и четвертое значения являются «0», «1», «2» и «3», соответственно.
7. Устройство для формирования мультимедийного файла, содержащего область мультимедийных данных и область метаданных, причем устройство содержит по меньшей мере один микропроцессор, сконфигурированный с возможностью выполнения этапов, на которых:
- получают мультимедийные данные, содержащие множество выборок, причем каждая выборка содержит один или более пространственных мозаичных фрагментов;
- формируют мультимедийный файл, в котором множество единиц уровня абстрагирования от сети (NAL), основанных на полученных мультимедийных данных, описываются в области мультимедийных данных, и информация о мозаичных фрагментах, которая указывает информацию, относящуюся к одному или более пространственным мозаичным фрагментам, соответствующим множеству единиц NAL, описанных в области мультимедийных данных, описывается в области метаданных.
8. Устройство по п.7, причем информация о мозаичных фрагментах включает в себя:
- информацию об идентификаторе мозаичных фрагментов для идентификации каждого из множества пространственных мозаичных фрагментов, соответствующих одной выборке;
- информацию о ширине мозаичных фрагментов для идентификации ширины каждого из множества пространственных мозаичных фрагментов, соответствующих одной выборке; и
- информацию о высоте мозаичных фрагментов для идентификации высоты каждого из множества пространственных мозаичных фрагментов, соответствующих одной выборке.
9. Устройство по п.8, причем информация о мозаичных фрагментах включает в себя:
- информацию о смещении мозаичных фрагментов для идентификации смещения каждого из множества пространственных мозаичных фрагментов, соответствующих одной выборке.
10. Устройство по п.8, причем информация о мозаичных фрагментах дополнительно содержит параметр для передачи сигнала о зависимостях при декодировании одного или более пространственных мозаичных фрагментов от других пространственных мозаичных фрагментов в одной и той же выборке и/или предыдущих выборках.
11. Устройство по п.10, причем микропроцессор дополнительно сконфигурирован с возможностью задания упомянутого параметра равным одному значению, выбранному из следующих значений:
- первое значение для передачи сигнала о том, что зависимости при кодировании между одним или более пространственными мозаичными фрагментами и другими мозаичными фрагментами в одной и той же выборке или в предыдущих выборках неизвестны;
- второе значение для передачи сигнала о том, что не существует зависимостей при пространственном кодировании между одним или более пространственными мозаичными фрагментами и другими мозаичными фрагментами в одной и той же выборке, но могут существовать зависимости при кодировании между одним или более пространственными мозаичными фрагментами и пространственным мозаичным фрагментом, имеющим такой же идентификатор мозаичного фрагмента в предыдущих выборках;
- третье значение для передачи сигнала о том, что не существует зависимостей при кодировании между одним или более пространственными мозаичными фрагментами и другими мозаичными фрагментами, имеющими такой же идентификатор мозаичного фрагмента в одной и той же выборке или в предыдущих выборках;
- четвертое значение для передачи сигнала о зарезервированном значении.
12. Устройство по п.11, причем упомянутый параметр является 2-битовым параметром, и первое, второе, третье и четвертое значения являются «0», «1», «2» и «3», соответственно.
| Benjamin Bross et al, Proposed Editorial Improvements for High efficiency video coding (HEVC), JCTVC-K0030_v1, 11th Meeting: Shanghai, 10-19 October 2012 | |||
| INGO KOFLER et al, Implications of the ISO base media file format on adaptive HTTP streaming of H.264/SVC, Consumer Communications and Networking Conference, IEEE, 14 January 2012 | |||
| US 2010262628 A1, 2010-10-14 | |||
| WO 2012168365 A1, 2012-12-13 | |||
| US 8184153 B2, 2012-05-22 | |||
| RU 2009141712 A, 2011-05-20. |
