Устройство и способ для кодирования и декодирования видео

Авторы патента:

H04N19/70 - Передача изображений, например телевидение (измерения, испытания G01; системы для оригиналов рукописей например, пишущие телеграфные аппараты, которые рассматриваются в подклассе G08; накопление информации, основанное на относительном перемещении носителя записи и преобразователя G11B; кодирование; декодирование или преобразование кодов вообще H03M; радиовещание или регистрация использования радиосети H04H)

Владельцы патента RU 2784900:

НОКИА ТЕКНОЛОДЖИЗ ОЙ (FI)

Изобретение относится к области кодирования видео или изображения. Технический результат заключается в повышении эффективности кодирования видео. Предложены способ, устройство для кодирования и декодирования видео. Способ кодирования содержит заключение о том, что кодированная видеопоследовательность начинается в конкретной позиции в битовом потоке, причем кодированная видеопоследовательность является последовательностью кодированных изображений в порядке декодирования, которая независимо декодируема и за которой следует другая кодированная видеопоследовательность или окончание битового потока, при этом битовый поток содержит блоки доступа, и блок доступа содержит кодированные видеоданные для единого момента времени и связанные другие данные, и блок доступа содержит один или более блоков уровня сетевой абстракции (NAL); и указание, в разделителе блоков доступа, обрабатывать блок или блоки NAL, связанные с разделителем блоков доступа, как начало кодированной видеопоследовательности. 4 н. и 11 з.п. ф-лы, 23 ил., 5 табл.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

[0001] Настоящее изобретение относится к устройству, способу и компьютерной программе для кодирования и декодирования видео.

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

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

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

[0004] Стандарты и спецификации видеокодирования обычно позволяют кодерам делить, или разбивать, кодированное изображение на поднаборы. В видеокодировании, разбиение можно определить как деление изображения или подобласти изображения на поднаборы (блоки) таким образом, что каждый элемент изображения или подобласти изображения находится строго в одном из поднаборов (блоков). Например, H.265/HEVC ввел понятие пакета дерева кодирования (CTU, coding tree unit) размером по умолчанию 64×64 пикселя. CTU может либо содержать единственный блок кодирования (CU, coding unit), либо рекурсивно делиться на несколько CU меньшего размера, минимум 8×8 пикселей, на основании структуры квадрадерева. H.265/HEVC также предусматривает тайлы, которые имеют прямоугольную форму и содержат целое число CTU, и слайсы, которые задаются на основании сегментов слайса, содержащих целое число пакетов дерева кодирования, упорядоченных последовательно при сканировании тайла и содержащихся в одном блоке NAL. В стандарте HEVC, разбиение на тайлы формирует сетку, которая может характеризоваться списком ширин столбцов тайлов (в CTU) и списком высот строк тайлов (в CTU). Тайлы упорядочиваются в битовом потоке последовательно в порядке растрового сканирования сетки тайлов. Тайл может содержать целое число слайсов.

[0005] Изображения могут делиться на независимо кодируемые и декодируемые сегменты изображения или области изображения (например, слайсы или тайлы или группы тайлов). Такие сегменты изображения могут допускать параллельную обработку, "слайсы" в этом описании может означать сегменты изображения, построенные из некоторого количества базовых блоков кодирования, которые обрабатываются в порядке кодирования или декодирования, принятом по умолчанию, тогда как "тайлы" могут означать сегменты изображения, которые заданы как прямоугольные области изображения. Группу тайлов можно определить как группу из одного или более тайлов. Сегменты изображения могут кодироваться как отдельные блоки в битовом потоке, например, блоки NAL VCL в H.264/AVC и HEVC. Кодированные сегменты изображения могут содержать заголовок и полезную нагрузку, причем заголовок содержит значения параметра, необходимые для декодирования полезной нагрузки.

[0006] Для соединения независимо кодированных областей изображения из одного или более исходных битовых потоков в объединенный битовый поток требуется перезапись наборов параметров. Другими словами, наборы параметров в исходном(ых) битовом(ых) потоке(ах) как таковые неприменимы. Например, ширина изображения, высота изображения и/или разбиение изображения на тайлы и кирпичи в объединенном битовом потоке могут отличаются от соответствующих параметров любого из исходных битовых потоков.

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

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

[0008] Согласно варианту осуществления, клиентское устройство для соединения независимо декодируемых областей изображения содержит плеер (приложение воспроизведения) или любой другой объект, который соединяет независимо декодируемые области изображения в единый (объединенный) битовый поток; и декодер, который декодирует объединенный битовый поток. Приложение воспроизведения может передавать объединенный битовый поток в декодер, например, по одному блоку доступа за раз, по одной кодированной видеопоследовательности за раз или по целому битовому потоку за раз.

[0009] Согласно варианту осуществления, для создания объединенного битового потока из доступных последовательностей независимо декодируемых областей изображения, приложение воспроизведения осуществляет следующее:

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

- приложение воспроизведения выбирает принимаемый поднабор последовательностей независимо декодируемых областей изображения;

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

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

- приложение воспроизведения принимает блоки данных, например, блоки NAL VCL, выбранных независимо декодируемых областей изображения, и размещает их в порядке декодирования в объединенный битовый поток, вслед за отдельным блоком данных.

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

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

[0012] Согласно варианту осуществления, объект осуществляет одно или более из следующих действий:

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

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

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

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

- записи отсчета

- записи конфигурации декодера

- записи описания группы отсчетов.

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

- как значение конкретного атрибута, например, на уровне представления или субпредставления;

- в конкретном элементе, например, конкретном элементе описателя, включенном, например, на уровне представления или субпредставления.

[0015] Объект может получать значения идентификатора последовательностей независимо кодированных областей изображения из одного или более битовых потоков, например, из наборов параметров и/или заголовков слайсов в них.

[0016] Согласно варианту осуществления, который может применяться независимо или совместно с другими вариантами осуществления, объект осуществляет одно или более из следующих действий:

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

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

[0017] Наборы параметров делаются доступными в описании медиа-презентации или посредством нее. Варианты того, как наборы параметров делаются доступными, включают в себя, но без ограничения, следующие:

[0018] создатель файла создает базовый трек в файле-контейнере. Наборы параметров включены в запись отсчета или записи отсчета базового трека и/или в отсчет(ы) базового трека и/или в трек набора параметров, связанный с базовым треком. Треки, содержащие пригодные последовательности независимо кодированных областей изображения, подлежащие включению в объединенный битовый поток, указаны ссылками на трек, включающими в себя, но без ограничения, следующие варианты:

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

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

[0019] Генератор манифестов потоковой передачи создает главный адаптационный набор предварительного выбора в DASH MPD. Главный адаптационный набор содержит представление, несущее базовый трек, как объяснено выше. Наборы параметров включены в сегмент инициализации представления (в записи отсчета) и/или в конкретный атрибут представления и/или в конкретный элемент, например, конкретный элемент описателя представления.

[0020] Способ согласно первому аспекту содержит:

заключение, что кодированная видеопоследовательность начинается в конкретной позиции в битовом потоке, причем кодированная видеопоследовательность является последовательностью кодированных изображений в порядке декодирования, которая независимо декодируема и за которой следует другая кодированная видеопоследовательность или окончание битового потока, при этом битовый поток содержит блоки доступа, и блок доступа содержит кодированные видеоданные для единого момента времени и связанные другие данные, и блок доступа содержит один или более блоков уровня сетевой абстракции (NAL, network abstraction layer);

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

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

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

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

[0022] Компьютерный программный продукт согласно третьему аспекту содержит компьютерный программный код, выполненный с возможностью, при выполнении по меньшей мере в одном процессоре, заставлять устройство или систему:

[0023] Устройство согласно четвертому аспекту содержит средство для:

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

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

[0024] Способ согласно пятому аспекту содержит:

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

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

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

[0026] Компьютерный программный продукт согласно седьмому аспекту содержит компьютерный программный код, выполненный с возможностью, при выполнении по меньшей мере в одном процессоре, заставлять устройство или систему:

[0027] Устройство согласно восьмому аспекту содержит средство для:

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

[0028] Дополнительные аспекты относятся к устройствам и компьютерно-считываемым носителям данных, где хранится код, которые предназначены для осуществления вышеупомянутых способов и одному или более из вариантов осуществления, связанных с ними.

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

[0029] Для лучшего понимания настоящего изобретения, обратимся в порядке примера к прилагаемым чертежам, на которых:

[0030] фиг. 1 демонстрирует пример всенаправленного медиа-формата MPEG (OMAF, Omnidirectional Media Format);

[0031] фиг. 2 демонстрирует пример сшивания, проекции и упаковки по областям изображений;

[0032] фиг. 3 демонстрирует другой пример сшивания, проекции и упаковки изображений по областям;

[0033] фиг. 4 демонстрирует пример процесса формирования моноскопического равнопрямоугольного панорамного изображения;

[0034] фиг. 5 демонстрирует пример потоковой передачи всенаправленного видео на основе тайлов;

[0035] фиг. 6 демонстрирует буферизацию по последовательностям субизображений согласно варианту осуществления;

[0036] фиг. 7 демонстрирует процесс декодирования с процессом манипуляции опорными субизображениями, в соответствии с вариантом осуществления;

[0037] фиг. 8а демонстрирует пример использования разделители согласно примеру;

[0038] фиг. 8b демонстрирует пример перезаписи значений идентификатора уровня согласно примеру;

[0039] фиг. 9 демонстрирует пример потоковой передачи всенаправленного видео на основе тайлов, где две последовательности субизображений, имеющих разное качество, инкапсулируются в треки последовательности субизображений, в соответствии с примером;

[0040] фиг. 10 демонстрирует пример изображения, разделенного на четыре субизображения;

[0041] фиг. 11а демонстрирует пример, где контент кубической текстуры кодируется с разрешениями "8K", "6K", "4K" и "2K";

[0042] фиг. 11b демонстрирует пример, где сетка тайлов 3×11 выбирается для обеспечения возможности декодирования 4K;

[0043] фиг. 11с демонстрирует пример, где клиент может выбирать тайлы из любой версии разрешения с использованием любой стратегии;

[0044] фиг. 11d демонстрирует пример, где в представленной стратегии "6K" клиент выбирает тайлы, покрывающие более двух граней куба из версии "6K", более двух граней куба из версии "4K" и три грани куба из версии "2K";

[0045] фиг. 12а демонстрирует пример объединенного битового потока с динамически изменяющимися вариантами выбора независимо кодированных областей изображения, в соответствии с вариантом осуществления;

[0046] фиг. 12b демонстрирует пример генерации патчей согласно варианту осуществления;

[0047] фиг. 13а, 13b, 13с демонстрируют некоторые примеры разбиения изображения на пакеты дерева кодирования (CTU), тайлы, кирпичи и слайсы;

[0048] фиг. 14а - блок-схема операций, демонстрирующая способ согласно варианту осуществления;

[0049] фиг. 14b - блок-схема операций, демонстрирующая способ согласно другому варианту осуществления;

[0050] фиг. 15 демонстрирует устройство согласно варианту осуществления.

ПОДРОБНОЕ ОПИСАНИЕ НЕКОТОРЫХ ПРИМЕРОВ ОСУЩЕСТВЛЕНИЯ

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

[0052] В дальнейшем, некоторые варианты осуществления традиционно описаны со ссылкой на (де)кодирование, указывая, что варианты осуществления могут применяться к декодированию и/или кодированию.

[0053] Стандарт усовершенствованного видеокодирования (который сокращенно называется AVC или H.264/AVC), был разработан коллективом Joint Video Team (JVT) группы экспертов по видеокодированию (VCEG, Video Coding Experts Group) отдела стандартизации телекоммуникаций (Telecommunications Standardization Sector) международного телекоммуникационного союза (ITU-T, International Telecommunication Union) и группы экспертов по движущимся изображениям (MPEG, Moving Picture Experts Group) международной организации по стандартизации (ISO, International Organization for Standardization) / международной электротехнической комиссии (IEC, International Electrotechnical Commission). Стандарт H.264/AVC опубликован как родительскими организациями стандартизации, под названием ITU-T Recommendation Н.264, так и международным стандартом ISO/IEC 14496-10, также известным как усовершенствованное видеокодирование (AVC, Advanced Video Coding) MPEG-4 часть 10. Известно несколько версий стандарта Н.264/AVC, каждая из которых внедряет в спецификацию новые расширения или признаки. Эти расширения включают в себя масштабируемое видеокодирование (SVC, Scalable Video Coding) и многоракурсное видеокодирование (MVC, Multiview Video Coding).

[0054] Стандарт высокопроизводительного видеокодирования (который сокращенно называется HEVC или H.265/HEVC) был разработан Joint Collaborative Team - Video Coding (JCT-VC) из VCEG и MPEG. Стандарт опубликован обеими родительскими организациями стандартизации, под названием ITU-T Recommendation Н.265 и международный стандарт 23008-2 ISO/IEC, также известный как высокопроизводительное видеокодирование (HEVC, High Efficiency Video Coding) MPEG-H часть 2. Расширения H.265/HEVC включают в себя масштабируемое, многоракурсное, трехмерное расширение и расширение диапазона достоверности, которые могут именоваться SHVC, MV-HEVC, 3D-HEVC и REXT, соответственно. Ссылки в этом описании на H.265/HEVC, SHVC, MV-HEVC, 3D-HEVC и REXT, которые были сделаны в целях понимания определений, структур или принципов этих спецификаций стандарта, следует понимать как ссылки на последние версии этих стандартов, которые были доступны до подачи данной заявки, если не указано обратное.

[0055] Стандарт универсального видеокодирования (VVC, Versatile Video Coding, Н.266 или H.266/VVC) в настоящее время находится в процессе разработки группой Joint Video Experts Team (JVET), которая является плодом сотрудничества между ISO/IEC MPEG и ITU-T VCEG

[0056] Некоторые ключевые определения, битовый поток и структуры кодирования и принципы H.264/AVC и HEVC и некоторые из их расширений описаны в этом разделе в качестве примера видеокодера, декодера, способа кодирования, способа декодирования и структуры битового потока, в которых могут быть реализованы варианты осуществления. Некоторые из ключевых определений, битового потока и структур кодирования и принципов H.264/AVC такие же, как в стандарте HEVC - поэтому они описаны ниже совместно. Аспекты различных вариантов осуществления не ограничиваются Н.264/AVC или HEVC или их расширениями, но напротив описание приведено в качестве одной возможной основы, на которой могут быть частично или полностью реализованы настоящие варианты осуществления.

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

[0058] Гибридные видеокодеки, например ITU-T Н.264, могут кодировать видеоинформацию в две фазы. Сначала предсказываются пиксельные значения в некоторой области изображения (или "блоке"), например, средством компенсации движения (находящим и указывающим область в одном из ранее кодированных кадров видео, который в точности соответствует кодируемому блоку) или пространственным средством (с использованием пиксельных значений вокруг блока, подлежащего кодированию указанным образом). Затем кодируется ошибка предсказания, т.е. разность между предсказанным блоком пикселей и исходным блоком пикселей. Это может осуществляться путем преобразования разности пиксельных значений с использованием указанного преобразования (например, дискретного косинусного преобразования (DCT, Discrete Cosine Transform) или его разновидности), квантования коэффициентов и энтропийного кодирования квантованных коэффициентов. Путем изменения достоверности процесса квантования, кодер может управлять балансом между точностью пиксельного представления (качеством изображения) и размером полученного кодированного представления видео (размером файла или битовой скоростью передачи).

[0059] Во временном предсказании, источниками предсказания являются ранее декодированные изображения (также известные как опорные изображения). При внутреннем блочном копировании (IBC, intra block copy; также известном как предсказание с внутриблочным копированием или ссылка на текущее изображение), предсказание аналогично применяется к временному предсказанию, но опорное изображение является текущим изображением, и в процессе предсказания можно обращаться только к ранее декодированным отсчетам. Межуровневое или межракурсное предсказание может аналогично применяться к временному предсказанию, но опорное изображение является декодированным изображением из другого масштабируемого уровня или из другого вида, соответственно. В ряде случаев, внешнее предсказание может означать только временное предсказание, тогда как в других случаях внешнее предсказание может относиться одновременно к временному предсказанию и любому из внутриблочного копирования, межуровневого предсказания и межракурсного предсказания при условии, что они осуществляются в таком же или аналогичном процессе, как временное предсказание. Внешнее предсказание или временное предсказание иногда может именоваться компенсацией движения или предсказанием с компенсацией движения.

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

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

[0062] Энтропийное кодирование/декодирование может осуществляться разными способами. Например, может применяться контекстное кодирование/декодирование, где кодер и декодер изменяют контекстное состояние параметра кодирования на основании ранее кодированных/декодированных параметров кодирования. Контекстное кодирование может, например, быть контекстно-адаптивным двоичным арифметическим кодированием (CABAC) или контекстным кодированием с переменной длиной серии (CAVLC) или любым аналогичным энтропийным кодированием. Энтропийное кодирование/декодирование может альтернативно или дополнительно осуществляться с использованием схемы кодирования с переменной длиной серии, например, кодирования/декодирования Хаффмана или экспоненциального голомбова кодирования/декодирования. Декодирование параметров кодирования из энтропийно кодированного битового потока или кодовых слов может именоваться синтаксическим анализом.

[0063] Стандарты видеокодирования могут задавать синтаксис и семантику битового потока, а также процесс декодирования для безошибочных битовых потоков, тогда как процесс кодирования может не задаваться, но от кодеров может требоваться только генерация согласующихся битовых потоков. Согласование битового потока и декодера можно проверять с помощью гипотетического эталонного декодера (HRD, Hypothetical Reference Decoder). Стандарты могут содержать инструменты кодирования, которые помогают в копировании в условиях ошибок передачи и потерь, но использование этих инструментов при кодировании может быть опциональным, и процесс декодирования для ошибочных битовых потоков задавать не обязательно.

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

[0065] Элементарным блоком для ввода в кодер и вывода из декодера, соответственно, обычно является изображение. Изображение, заданное для ввода в кодер, также может именоваться исходным изображением, и изображение, декодированное декодером, может именоваться декодированным изображением или реконструированным изображением.

[0066] Каждое из исходных и декодированных изображений состоит из одного или более массивов отсчетов, например, одного из следующих наборов массивов отсчетов:

- только яркости (Y) (монохромный).

- яркости и двух сигналов цветности (YCbCr или YCgCo).

- зеленого, синего и красного (GBR, также известные как RGB).

- массивов, представляющих другие не специфицированные монохромные или трехцветные системы цветовых отсчетов (например, YZX, также известные как XYZ).

[0067] В дальнейшем эти массивы могут именоваться яркостью (или L или Y) и цветностью, где два массива сигналов цветности могут именоваться СЬ и Сг; независимо от фактически используемого способа цветового представления. Фактически используемый способ цветового представления может указываться, например, в кодированном битовом потоке, например, с использованием синтаксиса информации пригодности видео (VUI, Video Usability Information) HEVC и т.п. Компонент можно определить как массив или единственный отсчет из одного из трех массивов отсчетов (яркости и двух сигналов цветности) или массив или единственный отсчет массива, который составляет изображение в монохромном формате.

[0068] Изображение может задаваться как кадр или поле. Кадр содержит матрицу отсчетов яркости и, возможно, соответствующих отсчетов цветности. Поле является набором чередующихся строк отсчетов кадра и может использоваться для ввода в кодер, когда исходный сигнал является чересстрочным. Массивы отсчетов цветности могут отсутствовать (и, таким образом, может использоваться монохромная дискретизация) или массивы отсчетов цветности могут прореживаться по сравнению с массивами отсчетов яркости.

[0069] Ниже перечислены некоторые форматы цветности:

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

- В дискретизации 4:2:0 каждый из двух массивов сигналов цветности имеет половинную высоту и половинную ширину массива яркости.

- В дискретизации 4:2:2 каждый из двух массивов сигналов цветности имеет равную высоту и половинную ширину массива яркости.

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

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

[0071] Когда используется прореживание цветности (например, дискретизация цветности 4:2:0 или 4:2:2), положение отсчетов цветности в отношении отсчетов яркости может определяться на стороне кодера (например, на этапе предобработки или как часть кодирования). Позиции отсчетов цветности относительно позиций отсчетов яркости могут быть заранее заданы, например, в стандарте кодирования, например, Н.264/AVC или HEVC, или могут быть указаны в битовом потоке, например как часть VUI H.264/AVC или HEVC.

[0072] В общем случае исходная(ые) видеопоследовательность(и), обеспеченный(ые) в качестве ввода для кодирования, могут представлять либо чересстрочный исходный контент, либо прогрессивный исходный контент. Поля противоположной четности были захвачены в разные моменты времени для чересстрочного исходного контента. Прогрессивный исходный контент содержит захваченные кадры. Кодер может кодировать поля чересстрочного исходного контента двумя путями: пара чередующихся полей может кодироваться в кодированном кадре, или поле может кодироваться как кодированное поле. Аналогично, кодер может кодировать кадры прогрессивного исходного контента двумя путями: кадр прогрессивного исходного контента может кодироваться в кодированный кадр или пару кодированных полей. Пару полей или пару взаимно дополняющих полей можно определить как два поля, следующие одно за другим в порядке декодирования и/или вывода, имеющие противоположную четность (т.е. одно является верхним полем, и другое является нижним полем), и ни одно из них не принадлежит никакой другой паре взаимно дополняющих полей. Некоторые стандарты или схемы видеокодирования допускают смешивание кодированных кадров и кодированных полей в одной и той же кодированной видеопоследовательности. Кроме того, предсказание кодированного поля из поля в кодированном кадре и/или предсказание кодированного кадра для пары взаимно дополняющих полей (кодированных как поля) может активироваться при кодировании и/или декодировании.

[0073] Разбиение (partitioning) можно определить как деление набора на поднаборы таким образом, что каждый элемент набора находится строго в одном из поднаборов. В видеокодировании, разбиение можно определить как деление изображения или подобласти изображения на поднаборы таким образом, что каждый элемент изображения или подобласти изображения находится строго в одном из поднаборов. Например, при разбиении, связанном с кодированием и/или декодированием HEVC, и/или с кодированием и/или декодированием VVC, могут использоваться следующие термины. Блок кодирования (coding block) можно определить как блок N×N отсчетов для некоторого значения N таким образом, что деление блока дерева кодирования на блоки кодирования является разбиением. Блок дерева кодирования (СТВ, coding tree block) можно определить как блок N×N отсчетов для некоторого значения N, так что деление компонента на блоки дерева кодирования является разбиением. Пакет дерева кодирования (CTU, coding tree unit) можно определить как блок дерева кодирования отсчетов яркости, два соответствующих блока дерева кодирования отсчетов цветности изображения, которое имеет три массива отсчетов, или блок дерева кодирования отсчетов монохромного изображения или изображения, которое кодируется с использованием трех отдельных цветовых плоскостей и синтаксических структур, используемых для кодирования отсчетов. Пакет кодирования (CU, coding unit) можно определить как блок кодирования отсчетов яркости, два соответствующих блока кодирования отсчетов цветности изображения, которое имеет три массива отсчетов, или блок кодирования отсчетов монохромного изображения или изображения, которое кодируется с использованием трех отдельных цветовых плоскостей и синтаксических структур, используемых для кодирования отсчетов. CU максимально разрешенного размера может именоваться LCU (наибольшим пакетом кодирования, largest coding unit) или пакетом дерева кодирования (CTU), и видеоизображение делится на неперекрывающиеся LCU.

[0074] В HEVC CU состоит из одного или более блоков предсказания (PU, prediction unit), задающих процесс предсказания для отсчетов в CU, и одного или более блоков преобразования (TU, transform unit), задающих процесс кодирования ошибки предсказания для отсчетов в упомянутом CU. Обычно CU состоит из квадратного блока отсчетов, размер которого выбирается из заранее заданного набора возможных размеров CU. Каждый PU и TU может дополнительно делиться на меньшие PU и TU для увеличения гранулярности процессов предсказания и кодирования ошибки предсказания, соответственно. С каждым PU связана информация предсказания, указывающая, какого рода предсказание подлежит применению для пикселей в этом PU (например, информация вектора движения для внешне предсказанных PU и информация направленности внутреннего предсказания для внутренне предсказанных PU).

[0075] Каждый TU может быть связан с информацией, описывающей процесс декодирования ошибки предсказания для отсчетов в упомянутом TU (включающей в себя, например, информацию коэффициентов DCT). Обычно на уровне CU сигнализируется, применяется ли кодирование ошибки предсказания для каждого CU. В случае отсутствия остаточной ошибки предсказания, связанной с CU, можно считать, что для упомянутого CU не существует TU. Деление изображения на CU и деление CU на PU и TU обычно сигнализируется в битовом потоке, что позволяет декодеру воспроизводить предполагаемую структуру этих блоков.

[0076] В предварительной версии H.266/VVC, применяется следующее разбиение. Заметим, что приведенное здесь описание может получить дальнейшее развитие в более поздних предварительных версиях H.266/VVC, пока стандарт не приобретет законченную форму. Изображения разбиваются на CTU аналогично HEVC, хотя максимальный размер CTU увеличен до 128×128. Пакет дерева кодирования (CTU) сначала разбивается структурой квадратурного дерева (также известным как квадрадерево). Затем краевые узлы квадратурного дерева могут дополнительно разбиваться структурой многотипного дерева. В структуре многотипного дерева существует четыре типа разбиения, вертикальное двоичное разбиение, горизонтальное двоичное разбиение, вертикальное троичное разбиение и горизонтальное троичное разбиение. Краевые узлы многотипного дерева называются пакетами кодирования (CU). CU, PU и TU имеют один и тот же размер блока, пока CU не станет слишком велик для максимальной длины преобразования. Структурой сегментирования для CTU является квадрадерево с вложенным многотипным деревом с использованием двоичного и троичного разбиений, т.е. не используются никакие отдельные концепции CU, PU и TU, кроме необходимых для CU, размер которых слишком велик для максимальной длины преобразования. CU может иметь квадратную или прямоугольную форму.

[0077] Элементарным блоком для вывода кодеров некоторых форматов кодирования, например VVC, и ввода декодеров некоторых форматов кодирования, например VVC, является блок уровня сетевой абстракции (NAL). Для переноса по пакетно-ориентированным сетям или сохранения в структурированные файлы, блоки NAL могут инкапсулироваться в пакеты или аналогичные структуры.

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

[0079] Блок NAL можно определить как синтаксическую структуру, содержащую указание типа данных, которые следуют далее, и байты, содержащие эти данные, в форме RBSP, перемеженные по мере необходимости с байтами предотвращения эмуляции. Полезную нагрузку первичной байтовой последовательности (RBSP, raw byte sequence payload) можно определить как синтаксическую структуру, содержащую целое число байтов, инкапсулированных в блок NAL. RBSP либо пуста, либо имеет форму строки битов данных, содержащей синтаксические элементы, сопровождаемые стоповым битом RBSP и сопровождаемые нулем или более последующих битов, равных 0.

[0080] Блоки NAL состоят из заголовка и полезной нагрузки. Заголовок блока NAL указывает тип блока NAL, помимо прочего.

[0081] Блоки NAL можно классифицировать на блоки NAL уровня видеокодирования (VCL) и блоки NAL не-VCL. Блоки NAL VCL обычно являются блоками NAL кодированных слайсов.

[0082] Блок NAL не-VCL может быть, например, одним из следующих типов: набор параметров последовательности, набор параметров изображения, блок NAL информации дополнительного улучшения (SEI, supplemental enhancement information), разделитель блоков доступа, блок NAL конца последовательности, блок NAL конца битового потока или блок NAL заполняющих данных. Наборы параметров могут требоваться для реконструкции декодированных изображений, тогда как многие из других блоков NAL не-VCL не требуются для реконструкции декодированных значений отсчетов.

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

[0084] Некоторые типы наборов параметров кратко описаны ниже, но следует понимать, что могут существовать другие типы наборов параметров, и что варианты осуществления могут применяться, но не ограничиваться описанными типами наборов параметров. Параметры, которые не изменяются в кодированной видеопоследовательности, могут быть включены в набор параметров последовательности (SPS, sequence parameter set). Помимо параметров, которые могут потребоваться процессу декодирования, набор параметров последовательности может опционально содержать информацию пригодности видео (VUI), которая включает в себя параметры, которые могут быть важны для буферизации, синхронизации вывода изображения, рендеринга и резервирования ресурсов. Набор параметров изображения (PPS, picture parameter set) содержит такие параметры, которые, вероятно, будут оставаться неизменными в нескольких кодированных изображениях. Набор параметров изображения может включать в себя параметры, к которым могут обращаться кодированные сегменты изображения одного или более кодированных изображений. Было предложено, чтобы набор параметров заголовка (HPS, header parameter set) содержал такие параметры, которые могут изменяться от изображения к изображению.

[0085] Битовый поток можно определить как последовательность битов, которые в некоторых форматах или стандартах кодирования могут принимать форму потока блоков NAL или байтового потока, который формирует представление кодированных изображений и связанные данные, образующие одну или более кодированных видеопоследовательностей. Первый битовый поток может сопровождаться вторым битовым потоком в одном и том же логическом канале, например, в одном и том же файле или одном и том же соединении протокола связи. Элементарный поток (в контексте видеокодирования) можно определить как последовательность одного или более битовых потоков. В некоторых форматах или стандартах кодирования, окончание первого битового потока может быть указано конкретным блоком NAL, который может именоваться блоком NAL окончания битового потока (ЕОВ), и который является последним блоком NAL битового потока.

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

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

[0088] Кодированную видеопоследовательность (CVS, coded video sequence) можно определить как такую последовательность кодированных изображений в порядке декодирования, которая независимо декодируема и за которой следует другая кодированная видеопоследовательность или окончание битового потока. Конец кодированной видеопоследовательности может дополнительно или альтернативно объявляться, когда в битовом потоке появляется конкретный блок NAL, который может именоваться блоком NAL конца последовательности (EOS).

[0089] Изображения могут делиться на независимо кодируемые и декодируемые сегменты изображения (например, слайсы и/или тайлы и/или группы тайлов). Такие сегменты изображения могут допускать параллельную обработку, "слайсы" в этом описании может означать сегменты изображения, построенные из некоторого количества базовых блоков кодирования, которые обрабатываются в порядке кодирования или декодирования, принятом по умолчанию, тогда как "тайлы" могут означать сегменты изображения, которые заданы как прямоугольные области изображения вдоль сетки тайлов. Группу тайлов можно определить как группу из одного или более тайлов. Сегменты изображения могут кодироваться как отдельные блоки в битовом потоке, например, блоки NAL VCL в Н.264/AVC и HEVC и VVC. Кодированные сегменты изображения могут содержать заголовок и полезную нагрузку, причем заголовок содержит значения параметра, необходимые для декодирования полезной нагрузки. Полезная нагрузка слайса может именоваться данными слайса.

[0090] В HEVC изображение может разбиваться на тайлы, которые имеют прямоугольную форму и содержат целое число LCU. В HEVC разбиение на тайлы формирует правильную сетку, где высоты и ширины тайлов отличаются друг от друга максимум на один LCU. В HEVC, слайс определяется как целое число блоков дерева кодирования, содержащихся в одном независимом сегменте слайса и все последующие зависимые сегменты слайса (при наличии), которые предшествуют следующему независимому сегменту слайса (при наличии) в одном и том же блоке доступа. В HEVC, сегмент слайса определяется как целое число блоков дерева кодирования, упорядоченных последовательно при сканировании тайла и содержащихся в едином блоке NAL. Деление каждого изображения на сегменты слайса является разбиением. В HEVC независимый сегмент слайса определяется как сегмент слайса, для которого значения синтаксических элементов заголовка сегмента слайса не выводятся из значений для предыдущего сегмента слайса, и зависимый сегмент слайса определяется как сегмент слайса, для которого значения некоторых синтаксических элементов заголовка сегмента слайса выводятся из значений для предыдущего независимого сегмента слайса в порядке декодирования. В HEVC заголовок слайса определяется как заголовок сегмента слайса для независимого сегмента слайса, который является текущим сегментом слайса или независимым сегментом слайса, который предшествует текущему зависимому сегменту слайса, и заголовок сегмента слайса определяется как часть кодированного сегмента слайса, содержащего элементы данных, относящиеся к первому или всем блокам дерева кодирования, представленным в сегменте слайса. CU сканируются в порядке растрового сканирования LCU в тайлах или в изображении, если тайлы не используются. В LCU CU имеют конкретный порядок сканирования.

[0091] Соответственно, стандарты и спецификации видеокодирования дают возможность кодерам делить кодированное изображение на кодированные слайсы и т.п. Предсказание внутри изображения обычно запрещено через границы слайса. Таким образом, слайсы можно рассматривать как способ деления кодированного изображения на независимо декодируемые фрагменты. В H.264/AVC и HEVC, предсказание внутри изображения через границы слайса может быть запрещено. Таким образом, слайсы можно рассматривать как способ деления кодированного изображения на независимо декодируемые фрагменты, и поэтому слайсы часто рассматриваются как элементарные блоки передачи. Во многих случаях, кодеры могут указывать в битовом потоке, какие типы предсказания внутри изображения через границы слайса отключены, и операция декодирования учитывает эту информацию, например, при заключении о доступных источниках предсказания. Например, отсчеты из соседнего CU можно рассматривать как недоступные для внутреннего предсказания, если соседний CU находится в другом слайсе.

[0092] В последней предварительной версии VVC, т.е. VVC Draft 5, разбиение изображений на слайсы, тайлы и кирпичи определяется следующим образом.

[0093] Изображение делится на одну или более строк тайлов и один или более столбцов тайлов. Разбиение изображения на тайлы формирует сетку тайлов, которая может характеризоваться списком ширин столбцов тайлов (в CTU) и списком высот строк тайлов (в CTU).

[0094] Тайл является последовательностью пакетов дерева кодирования (CTU), которая покрывает одну "ячейку" в сетке тайлов, т.е. прямоугольной области изображения. Тайл делится на один или более кирпичей, каждый из которых состоит из нескольких строк CTU в тайле. Тайл, который не разбивается на несколько кирпичей, также именуется кирпичом. Однако кирпич, который является истинным поднабором тайла, не называется тайлом.

[0095] Слайс содержит либо несколько тайлов изображения, либо несколько кирпичей тайла. Слайс является блоком NAL VCL, который содержит заголовок слайса и данные слайса.

[0096] Поддерживаются два режима слайсов, а именно, режим слайсов растрового сканирования и режим прямоугольных слайсов. В режиме слайсов растрового сканирования, слайс содержит последовательность тайлов в растровом сканировании тайлов изображения. В режиме прямоугольных слайсов, слайс содержит несколько кирпичей изображения, которые совместно образуют прямоугольную область изображения. Кирпичи в прямоугольном слайсе упорядочены посредством растрового сканирования кирпичей слайса.

[0097] Сканирование кирпичей можно определить как конкретное последовательное упорядочение CTU разбиения изображения, в котором CTU упорядочиваются последовательно в растровом сканировании CTU в кирпиче, кирпичи в тайле упорядочиваются последовательно в растровом сканировании кирпичей тайла, и тайлы в изображении упорядочиваются последовательно в растровом сканировании тайлов изображения. В стандарте кодирования может потребоваться, например, чтобы блоки NAL кодированных слайсов располагались в порядке увеличения адреса CTU при сканировании кирпичей для первого CTU каждого блока NAL кодированного слайса, где адрес CTU может задаваться в порядке увеличения в растровом сканировании CTU в изображении. Растровое сканирование можно определить как отображение прямоугольного двухмерного рисунка в одномерный рисунок таким образом, что первые записи в одномерном рисунке начинаются с первой сверху строки двухмерного рисунка, сканируемого слева направо, аналогично продолжается во второй, третей и т.д. строках рисунка (сверху вниз), каждая из которых сканируется слева направо.

[0098] В VVC Draft 5, заголовок слайса содержит синтаксический элемент sliceaddress, прямо или косвенно указывающий адрес слайса для слайса, где адрес слайса можно рассматривать как пространственное положение или позицию в изображении. Когда слайсы порядка растрового сканирования используются, синтаксический элемент slice address указывает индекс тайла в порядке растрового сканирования изображений. Когда используются прямоугольные слайсы, и в PPS не указывается явное упорядочение slice address, slice address указывает индекс кирпича в порядке сканирования кирпичей первого кирпича слайса. Когда используются прямоугольные слайсы, и в PPS указывается явное упорядочение slice address, список значений slice address (также известных как значения ID слайса) предоставляется в PPS в заранее заданном порядке сканирования, указывающем пространственную позицию слайсов с этими значениями slice address в изображении.

[0099] Фиг. 13а демонстрирует пример слайса растрового сканирования, разбивающего изображения, где изображение делится на 12 тайлов и 3 слайса растрового сканирования. Фиг. 13b демонстрирует пример разбиения прямоугольного слайса изображения (18×12 CTU), где изображение делится на 24 тайла (6 столбцов тайлов и 4 строки тайлов) и 9 прямоугольных слайсов. Фиг. 13 с демонстрирует пример изображения, разбиваемого на тайлы, кирпичи и прямоугольные слайсы, где изображение делится на 4 тайла (2 столба тайлов и 2 строки тайлов), 11 кирпичей (верхний левый тайл содержит 1 кирпич, верхний правый тайл содержит 5 кирпичей, нижний левый тайл содержит 2 кирпича, и нижний правый тайл содержать 3 кирпича), и 4 прямоугольных слайсов.

[0100] В VVC Draft 5, разбиение на тайлы, кирпичи и прямоугольные слайсы указано в наборе параметров изображения (PPS). Следующие синтаксис и семантика обеспечивают примеры синтаксических элементов, которые могут использоваться в различных вариантах осуществления. Согласно варианту осуществления, кодер определяет включать разбиение на тайлы, кирпичи и прямоугольные слайсы на уровне последовательностей (например, в SPS) или на уровне изображений (например, в PPS), и указывает синтаксическую структуру, содержащую разбиение на уровне последовательностей (например, в SPS). Согласно варианту осуществления, декодер декодирует указание, какая синтаксическая структура содержит разбиение на тайлы, кирпичи и прямоугольные слайсы, из синтаксической структуры уровня последовательностей (например, из SPS), и, соответственно, декодирует разбиение на тайлы, кирпичи и прямоугольные слайсы из указанной синтаксической структуры уровня последовательностей (например, SPS) или уровня изображений (например, PPS). Указание может, например, быть наподобие описанного ниже sps_tile_brick_rect_slice_present_flag. Согласно варианту осуществления, кодер создает PPS или его части согласно нижеприведенным синтаксису и семантике и/или декодер декодирует PPS или его части согласно нижеприведенным синтаксису и семантике, причем PPS включает в себя разбиение на тайлы, кирпичи и прямоугольные слайсы. Согласно варианту осуществления, кодер создает SPS или его части согласно нижеприведенным синтаксису и семантике, и/или декодер декодирует SPS или его части согласно нижеприведенным синтаксису и семантике, причем SPS включает в себя разбиение на тайлы, кирпичи и прямоугольные слайсы.

[0101] sps_tile_brick_rect_slice_present_flag, равный 0, указывает, что tile_brick_rect_slice() присутствует в PPS, обращающихся к этому SPS. sps_tile_brick_rect_slice_present_flag, равный 1, указывает, что tile_brick_rect_slice() присутствует в синтаксисе SPS RBSP.

[0102] single_tile_in_pic_flag, равный 1, указывает, что существует только один тайл в каждом изображении со ссылкой на PPS. single_tile_in_pic_flag равный 0, указывает, что существует более чем один тайл в каждом изображении со ссылкой на PPS. Примечание - В отсутствие дополнительного разбиения на кирпичи в тайле, целый тайл именуется кирпичом. Когда изображение содержит единственный тайл без дополнительного разбиения на кирпичи, он именуется единственным кирпичом. Согласование битового потока требует, чтобы значение single_tile_in_pic_flag было одинаковым для всех PPS, активированных в CVS.

[0103] uniform_tile_spacing_flag, равный 1, указывает, что границы столбца тайлов и, аналогично, границы строки тайлов равномерно распределяются по изображению и сигнализируются с использованием синтаксических элементов tile_cols_width_minus1 и tile_rows_height_minus1. uniform_tile_spacing_flag, равный 0, указывает, что границы столбца тайлов и, аналогично, границы строки тайлов могут равномерно или неравномерно распределяться по изображению и сигнализируются с использованием синтаксических элементов num_tile_columns_minus1 и num_tile_rows_minus1 и список пар синтаксических элементов tile_column_width_minus1[i] и tile_row_height_minus1[i]. Когда отсутствует, значение uniform_tile_spacing_flag предполагается равным 1.

[0104] tile_cols_width_minus1 плюс 1 указывает ширину столбцов тайлов, за исключением самого правого столбца тайлов изображения в единицах СТВ, когда uniform_tile_spacing_flag равен 1. Значение tile_cols_width_minus1 должно находиться в диапазоне от 0 до PicWidthInCtbsY - 1, включительно. Когда отсутствует, значение tile_cols_width_minus1 предполагается равным PicWidthInCtbsY - 1.

[0105] tile_rows_height_minus1 плюс 1 указывает высоту строк тайлов, за исключением нижней строки тайлов изображения в единицах СТВ, когда uniform_tile_spacing_flag равен 1. Значение tile_rows_height_minus1 должно находиться в диапазоне от 0 до PicHeightInCtbsY - 1, включительно. Когда отсутствует, значение tile_rows_height_minus1 предполагается равным PicHeightInCtbsY - 1.

[0106] num_tile_columns_minus1 плюс 1 указывает количество столбцов тайлов, разбивающих изображение, когда uniform_tile_spacing_flag равен 0. Значение num_tile_columns_minus1 должно находиться в диапазоне от 0 до PicWidthInCtbsY - 1, включительно. Если single_tile_in_pic_flag равен 1, значение num_tile_columns_minus1 предполагается равным 0. Иначе, когда uniform_tile_spacing_flag равен 1, значение num_tile_columns_minus1 логически определяется, как указано в процессе растрового сканирования СТВ, сканирования тайла и сканирования кирпича.

[0107] num_tile_rows_minus1 плюс 1 указывает количество строк тайлов, разбивающих изображение, когда uniform_tile_spacing_flag равен 0. Значение num_tile_rows_minus1 должно находиться в диапазоне от 0 до PicHeightInCtbsY - 1, включительно. Если single_tile_in_pic_flag равен 1, значение num_tile_rows_minus1 предполагается равным 0. Иначе, когда uniform_tile_spacing_flag равен 1, значение num_tile_rows_minus1 предполагается, как указано в процессе растрового сканирования СТВ, сканирования тайла и сканирования кирпича. Переменная NumTilesInPic устанавливается равной (num_tile_columns_minus1 + 1) * (num_tile_rows_minus1 + 1). Когда single_tile_in_pic_flag равен 0, NumTilesInPic должна быть больше 1.

[0108] tile_column_width_minus1[i] плюс 1 указывает ширину i-го столбца тайлов в единицах СТВ.

[0109] tile_row_height_minus1[i] плюс 1 указывает высоту i-й строки тайлов в единицах СТВ.

[0110] brick_splitting_present_flag, равный 1, указывает, что один или более тайлов изображений со ссылкой на PPS может делиться на два или более кирпичей. brick_splitting_present_flag равный 0, указывает, что ни один из тайлов изображений со ссылкой на PPS не делится на два или более кирпичей.

[0111] brick_split_flag[i], равный 1, указывает, что i-й тайл делится на два или более кирпичей. brick_split_flag[i] равный 0, указывает, что i-й тайл не делится на два или более кирпичей. Когда отсутствует, значение brick_split_flag[i] предполагается равным 0.

[0112] uniform_brick_spacing_flag[i], равный 1, указывает, что горизонтальные границы кирпича распределяются равномерно по i-му тайлу и сигнализируются с использованием синтаксического элемента brick_height_minus1[i]. uniform_brick_spacing_flag[i], равный 0, указывает, что горизонтальные границы кирпича могут равномерно или неравномерно распределяться по i-му тайлу и сигнализируются с использованием синтаксического элемента num_brick_rows_minus1[i] и списка синтаксических элементов brick_row_height_minus1[i][j]. Когда отсутствует, значение uniform_brick_spacing_flag[i] предполагается равным 1.

[0113] brick_height_minus1[i] плюс 1 указывает высоту строк кирпичей за исключением нижнего кирпича в i-ом тайле в единицах СТВ, когда uniform_brick_spacing_flag[i] равен 1. При наличии, значение brick_height_minus1 должно находиться в диапазоне от 0 до RowHeight[i] - 2, включительно. Когда отсутствует, значение brick_height_minus1[i] предполагается равным RowHeight[i] - 1.

[0114] num_brick_rows_minus1[i] плюс 1 указывает количество кирпичей, разбивающих i-й тайл, когда uniform_brick_spacing_flag[i] равен 0. При наличии, значение num_brick_rows_minus1[i] должно находиться в диапазоне от 1 до RowHeight[i] - 1, включительно. Если brick_split_flag[i] равен 0, значение num_brick_rows_minus1[i] предполагается равным 0. Иначе, когда uniform_brick_spacing_flag[i] равен 1, значение num_brick_rows_minus1[i] предполагается, как указано в процессе растрового сканирования СТВ, сканирования тайла и сканирования кирпича.

[0115] brick_row_height_minus1[i][j] плюс 1 указывает высоту j-го кирпича в i-м тайле в единицах СТВ, когда uniform_tile_spacing_flag равен 0.

[0116] Следующие переменные выводятся, и, когда uniform_tile_spacing_flag равен 1, значения num_tile_columns_minus1 и num_tile_rows_minus1 выводятся, и, для каждого i в пределах от 0 до NumTilesInPic - 1, включительно, когда uniform_brick_spacing_flag[i] равен 1, значение num_brick_rows_minus1[i] выводится, путем вызова процесса растрового сканирования СТВ, сканирования тайла и сканирования кирпича:

- список RowHeight[j] для j в пределах от 0 до num_tile_rows_minus1, включительно, указывающий высоту j-ой строки тайлов в единицах СТВ,

- список CtbAddrRsToBs[ctbAddrRs] для ctbAddrRs в пределах от 0 до PicSizeInCtbsY - 1, включительно, указывающий преобразование от адреса СТВ в растровом сканировании СТВ изображения до адреса СТВ при сканировании кирпичей,

- список CtbAddrBsToRs[ctbAddrBs] для ctbAddrBs в пределах от 0 до PicSizeInCtbsY - 1, включительно, указывающий преобразование от адреса СТВ при сканировании кирпичей до адреса СТВ в растровом сканировании СТВ изображения,

- список BrickId[ctbAddrBs] для ctbAddrBs в пределах от 0 до PicSizeInCtbsY - 1, включительно, указывающий преобразование от адреса СТВ при сканировании кирпичей до ID кирпича,

- список NumCtusInBrick[brickldx] для brickIdx в пределах от 0 до NumBricksInPic - 1, включительно, указывающий преобразование от индекса кирпича до количества CTU в кирпиче,

- список FirstCtbAddrBs[brickIdx] для brickIdx в пределах от 0 до NumBricksInPic - 1, включительно, указывающий преобразование от ID кирпича до адреса СТВ при сканировании кирпичей первого СТВ в кирпиче.

[0117] single_brick_per_slice_flag равный 1, указывает, что каждый слайс, который относится к этому PPS, включает в себя один кирпич. single_brick_per_slice_flag, равный 0, указывает, что слайс, который относится к этому PPS, может включать в себя более чем один кирпич. Когда отсутствует, значение single_brick_per_slice_flag предполагается равным 1.

[0118] rect_slice_flag равный 0, указывает, что кирпичи в каждом слайсе располагаются в порядке растрового сканирования и информация слайса не сигнализируется в PPS. rect_slice_flag равный 1, указывает, что кирпичи в каждом слайсе покрывают прямоугольную область изображения, и информация слайса сигнализируется в PPS. Когда single_brick_per_slice_flag равен 1, rect_slice_flag предполагается равным 1.

[0119] num_slices_in_pic_minus1 плюс 1 указывает количество слайсов в каждом изображении со ссылкой HaPPS. Значение num_slices_in_pic_minus1 должно находиться в диапазоне от 0 до NumBricksInPic - 1, включительно. Когда отсутствует, и single_brick_per_slice_flag равен 1, значение num_slices_in_pic_minus1 предполагается равным NumBricksInPic - 1.

[0120] top_left_brick_idx[i] указывает индекс кирпича для кирпича, расположенного в верхнем левом углу i-го слайса. Значение top_left_brick_idx[i] не должно быть равно значению top_left_brick_idx[j] для любого i, не равного j. Когда отсутствует, значение top_left_brick_idx[i] предполагается равным i. Длина синтаксического элемента top_left_brick_idx[i] равна Ceil(Log2(NumBricksInPic) битов.

[0121] bottom_right_brick_idx_delta[i] указывает разность между индексом кирпича для кирпича, расположенного в нижнем правом углу i-го слайса и top_left_brick_idx[i]. Когда single_brick_per_slice_flag равен 1, значение bottom_right_brick_idx_delta[i] предполагается равным 0. Длина синтаксического элемента bottom_right_brick_idx_delta[i] равна Ceil(Log2(NumBricksInPic - top_left_brick_idx[i])) битов.

[0122] Согласование битового потока требует, чтобы слайс включал в себя либо несколько полных тайлов или только последовательную последовательность полных кирпичей одного тайла. Переменные NumBricksInSlice[i] и BricksToSliceMap[j], которые указывают количество кирпичей в i-м слайсе и отображение кирпичей в слайсы, выводятся следующим образом:

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

[0124] Фильтрация может, например, включать в себя одно или более из следующего: деблокирование, адаптивное смещение отсчетов (SAO, sample adaptive offset) и/или адаптивная контурная фильтрация (ALF).

[0125] Деблокирующий контурный фильтр может включать несколько режимов или напряженностей фильтрации, которые могут адаптивно выбираться на основании признаков блоков, соседствующих с границей, например, значения параметра квантования и/или сигнализации, включенных кодером в битовый поток. Например, деблокирующий контурный фильтр может содержать режим нормальной фильтрации и режим сильной фильтрации, которые могут отличаться количеством отводов фильтра (т.е. количеством отсчетов, фильтруемых по обе стороны границы) и/или значениями отводов фильтра. Например, фильтрация двух отсчетов по обе стороны границы может осуществляться фильтром, имеющим импульсную характеристику (3 7 9 -3)/16, если пренебречь возможным влиянием операции обрезки.

[0126] Информация движения может быть указана векторами движения, связанными с каждым блоком изображения, скомпенсированным с учетом движения, в видеокодеках. Каждый из этих векторов движения представляет перемещение блока изображения в изображении, подлежащем кодированию (на стороне кодера) или декодированию (на стороне декодера) и исходного блока предсказания в одном из ранее кодированных или декодированных изображений. Для эффективного представления векторов движения их можно кодировать по-разному в отношении предсказанных векторов движения конкретного блока. Предсказанные векторы движения могут создаваться заранее заданным способом, например, путем вычисления медианы кодированных или декодированных векторов движения соседних блоков. Другой путь создания предсказаний на основе вектора движения состоит в генерации списка предсказаний-кандидатов из соседних блоков и/или соответственно расположенных блоков во временных опорных изображениях, и сигнализации выбранного кандидата как предсказателя вектора движения. Помимо предсказания значений векторов движения, можно предсказывать ссылочный индекс ранее кодированного/декодированного изображения. Ссылочный индекс можно предсказывать из соседних блоков и/или соответственно расположенных блоков во временном опорном изображении. Кроме того, высокопроизводительные видеокодеки могут использовать дополнительный механизм кодирования/декодирования информации движения, часто именуемый режимом соединения/объединения, где вся информация поля движения, которая включает в себя вектор движения и соответствующий индекс опорного изображения для каждого доступного списка опорных изображений, предсказывается и используется без какого-либо изменения/коррекции. Аналогично, предсказание информации поля движения осуществляется с использованием информации поля движения соседних блоков и/или соответственно расположенных блоков во временных опорных изображениях, и используемая информация поля движения сигнализируется в списке кандидатов поля движения, заполненном информацией поля движения доступных соседних/соответственно расположенных блоков.

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

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

[0129] Остаток предсказания после компенсации движения или внутреннего предсказания может сначала преобразовываться ядром преобразования (наподобие DCT) и затем кодироваться. Причина в том, что часто по-прежнему существует некоторая корреляция между остатками, и преобразование во многих случаях помогает снижать эту корреляцию и обеспечивать более эффективное кодирование.

[0130] Видеокодер может использовать функции Лагранжа для нахождения оптимальных режимов кодирования, например, режима желаемого макроблока и связанных с ним векторов движения. Этот вид функции затрат использует весовой коэффициент X для связывания друг с другом (точного или оценочного) искажения изображения вследствие способов кодирования с потерями и (точное или оценочное) объема информации, который требуется для представления пиксельных значений в области изображения:

[0131]

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

[0132] В некоторых кодеках используется понятие порядкового номера изображения (РОС, picture order count). Значение РОС выводится для каждого изображения и не убывает с увеличением позиции изображения в порядке вывода. Поэтому РОС указывает порядок вывода изображений. РОС может использоваться в процессе декодирования, например, для неявного масштабирования векторов движения и для инициализации списка опорных изображений. Кроме того, РОС может использоваться при проверке согласования порядка вывода.

[0133] В стандартах видеокодирования согласованный битовый поток должен иметь возможность декодироваться гипотетическим эталонным декодером, который может быть концептуально подключен к выходу кодера и состоит из по меньшей мере преддекодерного буфера, декодера и блока вывода/отображения. Этот виртуальный декодер может быть известен как гипотетический эталонный декодер (HRD) или верификатор буферизации видео (VBV, video buffering verifier). Поток является согласованным, если его можно декодировать с помощью HRD без переполнения или, в ряде случаев, опустошения буфера. Переполнение буфера происходит, когда в буфер направляется больше битов, чем он может вместить. Опустошение буфера происходит, если некоторые биты не находятся в буфере, когда упомянутые биты подлежат извлечению из буфера для декодирования/воспроизведения. Одной из мотиваций для HRD является избежание так называемых порочных битовых потоков, которые расходуют столько ресурсов, что практические реализации декодера не смогут их обработать.

[0134] Модели HRD обычно включают в себя мгновенное декодирование, тогда как битовую скорость на входе в буфер кодированных изображений (СРВ, coded picture buffer) HRD можно рассматривать как ограничение для кодера и битового потока по скорости декодирования кодированных данных и требование для декодеров по скорости обработки. Кодер может включать в себя СРВ, как указано в HRD, для проверки и контроля соблюдения ограничений буферизации при кодировании. Реализация декодера также может иметь СРВ, который может, но не обязательно действовать аналогично или идентично СРВ, заданному для HRD.

[0135] Буфер декодированных изображений (DPB, Decoded Picture Buffer) может использоваться в кодере и/или декодере. Может существовать две причины буферизовать декодированные изображения, для ссылок при внешнем предсказании и для переупорядочения декодированных изображений в порядке вывода. Некоторые форматы кодирования, например, HEVC, обеспечивают значительную гибкость как для маркировки опорного изображения, как и для переупорядочения вывода, отдельные буферы для буферизации опорного изображения и буферизации выходного изображения могут растрачивать ресурсы памяти. Следовательно, DPB может включать в себя унифицированный процесс буферизации декодированных изображений для опорных изображений и переупорядочения вывода. Декодированное изображение можно удалять из DPB, когда оно больше не используется для ссылки и не требуется для вывода. HRD также может включать в себя DPB. DPB HRD и реализация декодера могут, но не обязаны, работать одинаково.

[0136] Порядок вывода можно определить как порядок вывода декодированных изображений из буфера декодированных изображений (для декодированных изображений, которые подлежат выводу из буфера декодированных изображений).

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

[0138] В системе видеокодирования может существовать одна или более синтаксических структур для маркировки (декодированного) опорного изображения. Кодер генерирует экземпляр синтаксической структуры, например, в каждом кодированном изображении, и декодер декодирует экземпляр синтаксической структуры, например, из каждого кодированного изображения. Например, декодирование синтаксической структуры может приводить к адаптивной маркировке изображений как "используемых в качестве ссылки " или "не используемых в качестве ссылки".

[0139] Синтаксическая структура "набор опорных изображений" (RPS, reference picture set) HEVC является примером синтаксической структуры для маркировки опорного изображения. Набор опорных изображений, действительный или активный, для изображения включает в себя все опорные изображения, которые могут использоваться в качестве ссылки для изображения, и все опорные изображения, которые остаются маркированными как "используемые в качестве ссылки" для любых последующих изображений в порядке декодирования. Опорные изображения, которые остаются маркированными как "используемые в качестве ссылки" для любых последующих изображений в порядке декодирования, но которые не используются в качестве опорных изображений для текущего изображения или сегмента изображения, можно считать неактивными. Например, они не могут включаться в начальный(е) список(ки) опорных изображений.

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

[0141] В некоторых форматах кодирования, опорное изображение для внешнего предсказания может быть указано индексом в списке опорных изображений. В некоторых кодеках, два списка опорных изображений (список опорных изображений 0 и список опорных изображений 1) генерируются для каждого слайса двойного предсказания (В), и один список опорных изображений (список опорных изображений 0) формируется для каждого внешне кодированного (Р) слайса.

[0142] Список опорных изображений, например, список опорных изображений 0 и список опорных изображений 1, может быть построен в два этапа: сначала генерируется начальный список опорных изображений. Начальный список опорных изображений может генерироваться с использованием алгоритма, заранее заданного в стандарте. Такой алгоритм может использовать, например, РОС и/или временной подуровень, в качестве основы. Алгоритм может обрабатывать опорные изображения с конкретной маркировкой, например, "используемое в качестве ссылки", и исключать другие опорные изображения, т.е. исключать вставку других опорных изображений в начальный список опорных изображений. Примером такого другого опорного изображения является опорное изображение, маркированное как "не используемое в качестве ссылки", но все еще присутствующее в буфере декодированных изображений в ожидании вывода из декодера. Затем начальный список опорных изображений может переупорядочиваться посредством конкретной синтаксической структуры, например, команды переупорядочения списка опорных изображений (RPLR, reference picture list reordering) H.264/AVC или синтаксической структуры изменения списка опорных изображений HEVC или чего-то подобного. Кроме того, количество активных опорных изображений может быть указано для каждого списка, и использование изображений помимо активных в списке в качестве ссылки для внешнего предсказания запрещено. Инициализация списка опорных изображений и/или изменение списка опорных изображений могут обрабатывать только активные опорные изображения среди тех опорных изображений, которые маркированы как "используемые в качестве ссылки" и т.п.

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

[0144] Масштабируемый видеокодек для масштабируемости качества (также известного как масштабирование отношения сигнал/шум или SNR) и/или пространственной масштабируемости может быть реализован следующим образом. Для базового уровня, используются традиционные немасштабируемые видеокодер и декодер. Реконструированные/ декодированные изображения базового уровня включаются в буфер опорных изображений для уровня улучшения. В Н.264/AVC, HEVC и аналогичных кодеках, использующих список(ки) опорных изображений для внешнего предсказания, декодированные изображения базового уровня могут вставляться в список(ки) опорных изображений для кодирования/декодирование изображения уровня улучшения аналогично декодированным опорным изображениям уровня улучшения. В результате, кодер может выбирать опорное изображение базового уровня как опору для внешнего предсказания и указывать на его использование, например, индексом опорного изображения в кодированном битовом потоке. Декодер декодирует из битового потока, например, из индекса опорного изображения, что изображение базового уровня используется как опора для внешнего предсказания для уровня улучшения. Когда декодированное изображение базового уровня используется в качестве ссылки предсказания для уровня улучшения, оно именуется межуровневым опорным изображением.

[0145] Режимы масштабируемости или размеры масштабируемости могут включать в себя, но без ограничения, следующее:

- масштабируемость качества: изображения базового уровня кодируются с более низким качеством, чем изображения уровня улучшения, что может достигаться, например, с использованием большего значения параметра квантования (т.е. большего размера шага квантования для квантования коэффициента преобразования) в базовом уровне, чем в уровне улучшения.

- пространственную масштабируемость: изображения базового уровня кодируются с более низким разрешением (т.е. имеют меньше отсчетов), чем изображения уровня улучшения. Пространственная масштабируемость и масштабируемость качества иногда могут рассматриваться как один и тот же тип масштабируемости.

- масштабируемость битовой глубины: изображения базового уровня кодируются с меньшей битовой глубиной (например, 8 битов), чем изображения уровня улучшения (например, 10 или 12 битов).

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

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

- масштабируемость цветовой гаммы: изображения уровня улучшения имеют более богатый/широкий диапазон цветового представления, чем у изображений базового уровня - например, уровень улучшения может иметь цветовую гамму UHDTV (ITU-R ВТ.2020), а базовый уровень может иметь цветовую гамму ITU-R ВТ.709.

- масштабируемость зоны интереса (ROI): уровень улучшения представляет пространственный поднабор базового уровня, масштабируемость ROI может использоваться совместно с другим типами масштабируемости, например, качеством или пространственной масштабируемостью, чтобы уровень улучшения обеспечивал более высокое субъективное качество пространственного поднабора.

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

- масштабируемость глубины, которая также может именоваться кодированием с увеличенной глубиной. Уровень или некоторые уровни битового потока могут представлять вид(ы) текстуры, тогда как другой уровень или уровни может представлять вид(ы)глубины.

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

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

[0148] Отправитель, шлюз и т.п. может выбирать переданные уровни и/или подуровни битового потока масштабируемого видео, или аналогично приемник, клиент, приложение воспроизведения и т.п. может запрашивать передачу выбранных уровней и/или подуровней битового потока масштабируемого видео. Термины "извлечение уровня", "извлечение уровней" или переключение уровней вниз может означать передачу меньшего количества уровней, чем доступно в битовом потоке, переключение уровней вверх может означать передачу дополнительного уровня по сравнению с передававшимися до переключения уровней вверх, т.е. перезапуск передачи одного или более уровней, передача которых прекратилась ранее при переключении уровней вниз. Аналогично переключению уровней вниз и/или переключению вверх, может осуществляться переключение вниз и/или вверх временных подуровней. Аналогично может осуществляться переключение вниз и/или переключение вверх уровня и подуровня. Переключение вниз и/или переключение вверх уровня и подуровня может осуществляться в одном и том же блоке доступа и т.п. (т.е. практически одновременно) или может осуществляться в разных блоках доступа и т.п. (т.е. практически в разное время). Переключение уровней вверх может происходить на изображении произвольного доступа (например, изображении IRAP в HEVC). Переключение подуровня вверх может происходить на изображении конкретного типа (например, изображении STSA или TSA в HEVC).

[0149] Элементарным блоком для вывода кодером некоторых форматов кодирования, например, HEVC, и ввода в декодер некоторых форматов кодирования, например, HEVC, является блок уровня сетевой абстракции (NAL). Для переноса по пакетноориентированным сетям или сохранения в структурированные файлы, блоки NAL могут инкапсулироваться в пакеты или аналогичные структуры.

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

[0151] Блок NAL можно определить как синтаксическую структуру, содержащую указание типа данных, которые следуют далее, и байты, содержащие эти данные в форме полезной нагрузки первичной байтовой последовательности (RBSP), перемеженные по мере необходимости с байтами предотвращения эмуляции. RBSP можно определить как синтаксическую структуру, содержащую целое число байтов, инкапсулированных в блок NAL. RBSP либо пуста, либо имеет форму строки битов данных, содержащей синтаксические элементы, сопровождаемые стоповым битом RBSP и сопровождаемые нулем или более последующих битов, равных 0.

[0152] Блоки NAL состоят из заголовка и полезной нагрузки. В HEVC двухбайтовый заголовок блока NAL используется для всех указанных типов блока NAL, тогда как в других кодеках заголовок блока NAL может быть аналогичным заголовку из HEVC

[0153] В HEVC заголовок блока NAL содержит один зарезервированный бит, шестибитовое указание типа блока NAL, трехбитовое указание temporal_id_plus1 для временного уровня или подуровня (может потребоваться, чтобы оно было больше или равно 1,) и шестибитовый синтаксический элемент nuhlayerid. Синтаксический элемент temporal_id_plus1 можно рассматривать как временной идентификатор для блока NAL, и переменную TemporalId с отсчетом от нуля можно вывести следующим образом: TemporalId=temporal_id_plus1 - 1. Сокращение TID может использоваться взаимозаменяемо с переменной TemporalId. TemporalId, равный 0, соответствует самому низкому временному уровню. Значение temporal_id_plus1 должно быть ненулевым во избежание эмуляции начального кода с участием двухбайтового заголовка блока NAL. Битовый поток, созданный исключением всех блоков NAL VCL, для которых TemporalId больше или равен выбранному значению, и включением всех остальных блоков NAL VCL, остается согласующимся. В результате, изображение, имеющее TemporalId, равный tid_value, не использует ни одно изображение, имеющее TemporalId, больший tid_value, как опору для внешнего предсказания. Подуровень или временной подуровень может задаваться как масштабируемый по времени уровень (или временной уровень, TL, temporal layer) масштабируемого по времени битового потока. Такой масштабируемый по времени уровень может содержать блоки NAL VCL с конкретным значением переменной TemporalId и связанные блоки NAL не-VCL. nuh_layer_id можно понимать как идентификатор уровня масштабируемости.

[0154] Блоки NAL можно классифицировать на блоки NAL уровня видеокодирования (VCL) и блоки NAL не-VCL. Блоки NAL VCL обычно являются блоками NAL кодированных слайсов. В HEVC блоки NAL VCL содержат синтаксические элементы, представляющие один или более CU. В HEVC тип блока NAL в некотором диапазоне указывает блок NAL VCL, и тип блока NAL VCL указывает тип изображения.

[0155] Изображения могут делиться на независимо кодируемые и декодируемые сегменты изображения (например, слайсы или тайлы или группы тайлов). Такие сегменты изображения могут допускать параллельную обработку, "слайсы" в этом описании может означать сегменты изображения, построенные из некоторого количества базовых блоков кодирования, которые обрабатываются в порядке кодирования или декодирования, принятом по умолчанию, тогда как "тайлы" могут означать сегменты изображения, которые заданы как прямоугольные области изображения. Группу тайлов можно определить как группу из одного или более тайлов. Сегменты изображения могут кодироваться как отдельные блоки в битовом потоке, например, блоки NAL VCL в Н.264/AVC и HEVC. Кодированные сегменты изображения могут содержать заголовок и полезную нагрузку, причем заголовок содержит значения параметров, необходимые для декодирования полезной нагрузки.

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

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

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

[0159] Термин "составляющий битовый поток" может использоваться для последовательности независимо кодированных областей изображения. Однако, составляющий битовый поток также может использоваться для других целей; например, битовый поток видео текстуры и битовый поток видео глубины, которые мультиплексируются в один и тот же битовый поток (например, как отдельные независимые уровни) можно рассматривать как составляющие битовые потоки.

[0160] Термины "независимо декодируемая область изображения" и "независимо кодированная область изображения" могут использоваться взаимозаменяемо. Может существовать много способов реализации независимо кодированной области изображения и/или последовательности независимо кодированных областей изображения при кодировании и/или декодировании, и следует понимать, что варианты осуществления не ограничиваются каким-либо одним способом, но допускают применение любого способа. Далее описаны некоторые примеры независимо кодированных областей изображения и последовательностей независимо кодированных областей изображения.

[0161] Набор тайлов с ограничением движения (MCTS, motion-constrained tile set) является примером реализации независимо кодированной области изображения, и аналогично последовательность MCTS является примером последовательности независимо кодированных областей изображения. Набор тайлов с ограничением движения (MCTS) обладает тем свойством, что процесс внешнего предсказания ограничивается при кодировании таким образом, что за пределами набора тайлов с ограничением движения нет ни одного значения отсчета, и ни одно значение отсчета в дробной позиции отсчета, которое выводится с использованием одного или более значений отсчетов за пределами набора тайлов с ограничением движения, не используется для внешнего предсказания любого отсчета в наборе тайлов с ограничением движения. Дополнительно, кодирование MCTS ограничивается таким образом, что ни переменные, ни любые результаты декодирования, которые выводятся из блоков за пределами MCTS, не используются ни в каких процессах декодирования в MCTS. Например, кодирование MCTS ограничивается таким образом, что кандидаты в векторы движения не выводятся из блоков за пределами MCTS. Это может осуществляться путем отключения временного предсказания вектора движения HEVC, или путем запрещения кодеру использовать кандидата в TMVP или любого кандидата на предсказание вектора движения, следующего за кандидатом в TMVP в объединении или списке кандидатов в AMVP для PU, расположенных непосредственно слева от правой границы тайла MCTS, кроме последнего внизу справа MCTS. В общем случае, MCTS может задаваться как набор тайлов, который не зависит ни от каких значений отсчетов и кодированных данных, например, векторов движения, находящихся за пределами MCTS. Последовательность MCTS можно определить как последовательность соответствующих MCTS в одной или более кодированных видеопоследовательностях и т.п. В ряде случаев, MCTS может потребоваться для формирования прямоугольной области. Следует понимать, что в зависимости от контекста, MCTS может означать набор тайлов в изображении или соответствующий набор тайлов в последовательности изображений. Соответствующий набор тайлов может, но, в общем случае, не обязан, соответственно располагаться в последовательности изображений. Набор тайлов с ограничением движения можно рассматривать как независимо кодированный набор тайлов, поскольку его можно декодировать без других наборов тайлов.

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

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

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

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

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

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

[0166] Сообщение SEI (информации дополнительного улучшения) наборов временных тайлов с ограничением движения HEVC может использоваться для указания присутствия наборов тайлов с ограничением движения в битовом потоке.

[0167] Блок HAL не-VCL может быть, например, один из следующих типов: набор параметров последовательности, набор параметров изображения, блок NAL информации дополнительного улучшения (SEI), разделитель блоков доступа, блок NAL конца последовательности, блок NAL конца битового потока или блок NAL заполняющих данных. Наборы параметров могут требоваться для реконструкции декодированных изображений, тогда как многие из других блоков NAL не-VCL не требуются для реконструкции декодированных значений отсчетов.

[0168] Некоторые форматы кодирования указывают наборы параметров, которые могут нести значения параметра, необходимые для декодирования или реконструкции декодированных изображений. Параметры, которые не изменяются в кодированной видеопоследовательности, могут быть включены в набор параметров последовательности (SPS). Помимо параметров, которые могут потребоваться процессу декодирования, набор параметров последовательности может опционально содержать информацию пригодности видео (VUI), которая включает в себя параметры, которые могут быть важны для буферизации, синхронизации вывода изображения, рендеринга и резервирования ресурсов. Набор параметров изображения (PPS) содержит такие параметры, которые, вероятно, будут оставаться неизменными в нескольких кодированных изображениях. Набор параметров изображения может включать в себя параметры, к которым могут обращаться кодированные сегменты изображения одного или более кодированных изображений. Было предложено, чтобы набор параметров заголовка (HPS) содержал такие параметры, которые могут изменяться от изображения к изображению.

[0169] Набор параметров видео (VPS, video parameter set) можно определить как синтаксическую структуру, содержащую синтаксические элементы, которые применяются к нулю или более полным кодированным видеопоследовательностям. VPS может обеспечивать информацию об отношениях зависимости уровней в битовом потоке, а также различной другой информации, которая применяется ко всем слайсам по всем уровням во всей кодированной видеопоследовательности. В HEVC, VPS можно рассматривать как содержащий две части, базовый VPS и расширение VPS, где расширение VPS может присутствовать опционально. Набор параметров видео RBSP может включать в себя параметры, к которым может обращаться один или более наборов параметров последовательности RBSP.

[0170] Набор параметров может активироваться при обращении к нему, например, посредством его идентификатора. Например, заголовок сегмента изображения, например заголовок слайса, может содержать идентификатор PPS, который активируется для декодирования кодированного изображения, содержащего сегмент изображения. PPS может содержать идентификатор SPS, который активируется при активации PPS. Активация набора параметров конкретного типа может приводить к деактивации ранее активного набора параметров одного и того же типа.

[0171] Соотношение и иерархию между VPS, SPS и PPS можно описать следующим образом. VPS располагается уровнем выше SPS в иерархии наборов параметров. VPS может включать в себя параметры, которые являются общими для всех сегментов изображения по всем уровням во всей кодированной видеопоследовательности. SPS включает в себя параметры, которые являются общими для всех сегментов изображения в конкретном уровне во всей кодированной видеопоследовательности и может совместно использоваться несколькими уровнями. PPS включает в себя параметры, которые являются общими для всех сегментов изображения в кодированном изображении и, вероятно, совместно используются всеми сегментами изображения в множественных кодированных изображениях.

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

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

[0174] Кодированное изображение является кодированным представлением изображения.

[0175] Изображение точки произвольного доступа (RAP, Random Access Point), которое также может именоваться интраизображением точки произвольного доступа (IRAP), может содержать только внутренне кодированные сегменты изображения. Кроме того, изображение RAP может ограничивать подпоследовательность изображений в порядке вывода таким образом, чтобы их можно было правильно декодировать без осуществления процесса декодирования любых изображений, которые предшествуют изображению RAP в порядке декодирования.

[0176] Блок доступа может содержать кодированные видеоданные для единого момента времени и связанные другие данные. В HEVC, блок доступа (AU, access unit) можно определить как набор блоков NAL, которые связаны друг с другом согласно заданному правилу классификации, следуют друг за другом в порядке декодирования, и содержат самое большее одно изображение с любым конкретным значением nuh_layer_id. Помимо содержания блоков NAL VCL кодированного изображения, блок доступа может также содержать блоки NAL не-VCL. Упомянутое заданное правило классификации может, например, связывать изображения с одинаковым временем вывода или значением счетчика вывода изображения в один и тот же блок доступа.

[0177] Может потребоваться, чтобы кодированные изображения появлялись в блоке доступа в некотором порядке. Например, может потребоваться, чтобы кодированное изображение с nuh_layer_id, равным nuhLayerIdA, предшествовало, в порядке декодирования, всем кодированным изображениями с nuh_layer_id, большим nuhLayerIdA в одном и том же блоке доступа.

[0178] Битовый поток можно определить как последовательность битов, которые в некоторых форматах или стандартах кодирования могут принимать форму потока блоков NAL или байтового потока, который формирует представление кодированных изображений и связанные данные, образующие одну или более кодированных видеопоследовательностей. Первый битовый поток может сопровождаться вторым битовым потоком в одном и том же логическом канале, например, в одном и том же файле или одном и том же соединении протокола связи. Элементарный поток (в контексте видеокодирования) можно определить как последовательность одного или более битовых потоков. В некоторых форматах или стандартах кодирования, окончание первого битового потока может быть указано конкретным блоком NAL, который может именоваться блоком NAL окончания битового потока (ЕОВ), и который является последним блоком NAL битового потока.

[0179] Кодированную видеопоследовательность (CVS) можно определить как такую последовательность кодированных изображений в порядке декодирования, которая независимо декодируема и за которой следует другая кодированная видеопоследовательность или окончание битового потока. Конец кодированной видеопоследовательности может дополнительно или альтернативно объявляться, когда в битовом потоке появляется конкретный блок NAL, который может именоваться блоком NAL конца последовательности (EOS). В HEVC блок NAL EOS с nuh_layer_id, равным 0, завершает кодированную видеопоследовательность.

[0180] Битовые потоки или кодированные видеопоследовательности могут кодироваться с масштабированием по времени следующим образом. Каждое изображение может назначаться конкретному временному подуровню. Временные подуровни могут нумероваться, например, от 0 вверх. Самый низкий временной подуровень, подуровень 0, может декодироваться независимо. Изображения во временном подуровне 1 можно предсказывать из реконструированного изображения во временных подуровнях 0 и 1. Изображения во временном подуровне 2 можно предсказывать из реконструированного изображения во временных подуровнях 0, 1 и 2 и т.д. Другими словами, изображение во временном подуровне N не использует ни одно изображение во временном подуровне больше N в качестве ссылки для внешнего предсказания. Битовый поток, созданный исключением всех изображений, больших или равных выбранному значению подуровня, и включающий в себя изображения, остается согласующимся.

[0181] Изображение доступа к подуровню можно определить как изображение, с которого декодирование подуровня может правильно начинаться, т.е. начало, от которого можно правильно декодировать все изображения подуровня. В HEVC существуют два типа изображения, изображение доступа к временному подуровню (TSA, temporal sub-layer access) и поэтапного доступа к временному подуровню (STSA, step-wise temporal sub-layer access), которые могут использоваться для указания моментов переключения временного подуровня. Если временные подуровни с TemporalId до N декодированы до изображения TSA или STSA (исключительно), и изображение TSA или STSA имеет TemporalId, равный N+1, изображение TSA или STSA позволяет декодировать все последующие изображения (в порядке декодирования), имеющие TemporalId, равный N+1. Изображение типа TSA может налагать ограничения на само изображение TSA и все изображения в одном и том же подуровне, которые следуют за изображением TSA в порядке декодирования. Ни одно из этих изображений не годится для использования внешнего предсказания из любого изображения в одном и том же подуровне, которое предшествует изображению TSA в порядке декодирования. Определение TSA может дополнительно налагать ограничения на изображения в более высоких подуровнях, которое следуют за изображением TSA в порядке декодирования. Ни одно из этих изображений не годится для указания изображения, которое предшествует изображению TSA в порядке декодирования, если это изображение принадлежит тому же или более высокому подуровню, что и изображение TSA. Изображения TSA имеют TemporalId больше 0. Изображения STSA аналогичны изображению TSA, но не налагают ограничений на изображения в более высоких подуровнях, которые следуют за изображением STSA в порядке декодирования и, таким образом допускают переключение вверх только к подуровню, где находится изображение STSA.

[0182] Следующее может использоваться для указания процесса разбора синтаксических элементов.

- u(n): беззнаковое целое число с использованием n битов. Когда n - это "v" в таблице синтаксиса, количество битов изменяется в зависимости от значения других синтаксических элементов. Процесс разбора для этого описателя указан n следующими битами из битового потока, интерпретированного как двоичное представление беззнакового целого числа, где старший бит записан первым.

- ue(v): беззнаковый целочисленный кодированный экспоненциальным кодом Голомба синтаксический элемент, где левый бит - первый.

[0183] Кодированная экспоненциальным кодом Голомба битовая строка может преобразовываться в кодовое число (codeNum), например, с использованием следующей таблицы:

[0184] Доступные стандарты формата медиафайла включают в себя базовый формат медиафайла ISO (ISO/IEC 14496-12, который сокращенно называется ISOBMFF), формат файла MPEG-4 (ISO/IEC 14496-14, также известный как формат МР4), формат файла для структурированного видео блока NAL (ISO/IEC 14496-15) и формат файла 3GPP (3GPP TS 26.244, также известный как формат 3GP). Формат файла ISO является базовым для вывода всех вышеупомянутых форматов файла (за исключением самого формата файла ISO). Эти форматы файла (включающие сам формат файла ISO) в общем случае именуются семейством ISO форматов файла.

[0185] Некоторые принципы, структуры и спецификации ISOBMFF описаны ниже в качестве примера формата файла-контейнера, на основании которого можно реализовать варианты осуществления. Аспекты изобретения не ограничиваются ISOBMFF, а описание приведено в качестве одной возможной основы, на которой изобретение может быть частично или полностью реализовано.

[0186] Основной строительный блок в базовом формате медиафайла ISO именуется боксом (box). Каждый бокс имеет заголовок и полезную нагрузку. Заголовок бокса указывает тип бокса и размер бокса в байтах. Бокс может охватывать другие боксы, и формат файла ISO указывает, какие типы боксов разрешены в боксе того или иного типа. Кроме того, присутствие некоторых боксов может быть обязательным в каждом файле, тогда как присутствие других боксов может быть опциональным. Дополнительно, для некоторых типов боксов допустимо, чтобы в файле присутствовала более одного бокса. Таким образом, базовый формат медиафайла ISO можно рассматривать как указание иерархической структуры боксов.

[0187] Согласно семейству ISO форматов файла, файл включает в себя медиаданные и метаданные, которые инкапсулируются в боксы. Каждый бокс идентифицируется четырехсимвольным кодом (4СС) и начинается с заголовка, который сообщает тип и размер бокса.

[0188] В файлах, согласующихся с базовым форматом медиафайла ISO, медиаданные могут предоставляться в боксе медиаданных 'mdat', а бокс фильма 'moov' может использоваться для включения метаданных. В ряде случаев, чтобы можно было оперировать файлом, может потребоваться присутствие обоих боксов 'mdat' и 'moov'. Бокс фильма 'moov' может включать в себя один или более треков, и каждый трек может располагаться в одном соответствующем TrackBox ('trak'). Трек может относиться к одному из многих типов, включающих в себя медиа-трек, который относится к отсчетам, форматированным согласно формату сжатия медиа (и его инкапсуляции в базовый формат медиафайла ISO). Трек можно рассматривать как логический канал.

[0189] Фрагменты фильма могут использоваться, например, при записи контента в файлы ISO, например, во избежание потери данных вследствие аварийного закрытия приложения записи, выхода за пределы пространства памяти или какого-либо другого инцидента. В отсутствие фрагментов фильма, потеря данных может происходить из-за того, что формат файла может требовать, чтобы все метаданные, например, бокс фильма, записывались в одну непрерывную область файла. Кроме того, при записи файла, может отсутствовать достаточный объем пространства памяти (например, оперативной памяти RAM) для буферизации бокса фильма в соответствии с доступным размером хранилища, и повторное вычисление содержимого бокса фильма, когда фильм закрывается, может осуществляться слишком медленно. Кроме того, фрагменты фильма может допускать одновременные запись и воспроизведение файла с использованием правильного анализатора файла ISO. Кроме того, меньшая длительность начальной буферизации может потребоваться для последовательной загрузки, например, одновременных приема и воспроизведения файла, когда используются фрагменты фильма, и начальный бокс фильма меньше по сравнению с файлом, содержащим тот же медиа-контент, но структурированным без фрагментов фильма.

[0190] Признак фрагмента фильма может допускать разбиение метаданных, которые иначе могли бы располагаться в боксе фильма, на несколько фрагментов. Каждый фрагмент может соответствовать некоторому периоду времени трека. Другими словами, признак фрагмента фильма может допускать чередование метаданных и медиаданных файла. В результате, размер бокса фильма может ограничиваться, и вышеупомянутые варианты использования могут реализовываться.

[0191] В некоторых примерах, отсчеты медиа для фрагментов фильма могут располагаться в боксе mdat, если они находятся в том же файле, что и бокс moov. Однако для метаданных фрагментов фильма может предоставляться бокс moof. Бокс moof может включать в себя информацию для некоторой длительности времени воспроизведения, которая ранее располагалась в боксе moov. Бокс moov может по-прежнему самостоятельно представлять действительный фильм, но кроме того, он может включать в себя бокс mvex, указывающий, что фрагменты фильма последуют в том же файле. Фрагменты фильма могут продлевать время презентации, связанной с боксом moov.

[0192] Во фрагменте фильма может существовать набор фрагментов треков, от нуля до нескольких на трек. Фрагменты треков в свою очередь могут включать в себя от нуля до нескольких проходов треков (также известных как проходы фрагментов трека), каждый из которых в этом документе является непрерывной последовательностью отсчетов для этого трека. В этих структурах многие поля являются опциональными и могут быть исключены. Метаданные, которые могут быть включены в бокс moof, могут ограничиваться поднабором метаданных, которые могут быть включены в бокс moov, и могут кодироваться по-разному в ряде случаев. Детали, касающиеся боксов, которые могут быть включены в бокс moof, можно найти в спецификации базового формата медиафайла ISO. Самодостаточный фрагмент фильма может задаваться состоящим из бокса moof и бокса mdat, которые следуют друг за другом в порядке файлов, где бокс mdat содержит отсчеты фрагмента фильма (для которого бокс moof предоставляет метаданные) и не содержит отсчеты никакого другого фрагмента фильма (т.е. никакого другого бокса moof).

[0193] Для связывания треков друг с другом можно использовать механизм ссылки на трек. TrackReferenceBox включает в себя боксы, каждый из которых обеспечивает ссылку из содержащего трека в набор других треков. Эти ссылки помечены посредством типа бокса (т.е. четырехсимвольного кода бокса) содержащегося бокса.

[0194] TrackGroupBox, который содержится в TrackBox, позволяет указывать группу треков, где каждая группа совместно использует конкретную характеристику, или треки в группе имеют конкретное соотношение. Бокс содержит нуль или более боксов, и конкретная характеристика или соотношение указывается типом бокса содержащихся боксов. Содержащиеся боксы включают в себя идентификатор, который может использоваться для заключения, что треки принадлежат одной и той же группе треков. Треки, которые содержат один и тот же тип содержащегося бокса в TrackGroupBox и имеют одно и то же значение идентификатора в этих содержащихся боксах, принадлежат одной и то же группе треков.

[0195] Унифицированный идентификатор ресурса (URI, uniform resource identifier) можно определить как строку символов, используемых для идентификации имени ресурса. Такая идентификация позволяет взаимодействовать с представлениями ресурса по сети с использованием конкретных протоколов. URI определяется посредством схемы, указывающей конкретный синтаксис и связанный протокол для UR1 Унифицированный указатель местоположения ресурса (URL, uniform resource locator) и унифицированное имя ресурса (URN, uniform resource name) являются формами URI. URL можно определить как URI который идентифицирует сетевой ресурс и указывает средство воздействия на ресурс или получения представления ресурса, указывающего как первичный механизм доступа к нему, так и его положение в сети. URN можно определить как URI, который идентифицирует ресурс по имени в конкретном пространстве имен. URN может использоваться для идентификации ресурса безотносительно к его положению или порядку доступа к нему.

[0196] В последнее время протокол передачи гипертекста (HTTP, Hypertext Transfer Protocol) широко используется для доставки мультимедийного контента реального времени по Интернету, например, в приложениях потоковой передачи видео. В отличие от использования транспортного протокола реального времени (RTP, Realtime Transport Protocol) по протоколу пользовательских дейтаграмм (UDP), HTTP легко конфигурировать и обычно он обеспечивает прохождение брандмауэров и преобразователей сетевого адреса (NAT), что делает его привлекательным для приложений потоковой передачи мультимедиа.

[0197] Было запущено несколько коммерческих решений для адаптивной потоковой передачи по HTTP, например, Microsoft® Smooth Streaming, Apple® Adaptive HTTP Live Streaming и Adobe® Dynamic Streaming, а также были осуществлены проекты стандартизации. Адаптивная потоковая передача HTTP (AHS, Adaptive HTTP streaming) сначала была стандартизована в службе потоковой передачи с коммутацией пакетов (PSS) проекта партнерства третьего поколения (3GPP) выпуск 9 (3GPP TS 26.234 выпуск 9: "Transparent end-to-end packet-switched streaming service (PSS); protocols and codecs"). MPEG взяла AHS 3GPP выпуск 9 в качестве отправной точки для стандарта MPEG DASH (ISO/ГЕС 23009-1: "Dynamic adaptive streaming over HTTP (DASH)-Part 1: Media presentation description and segment formats", международный стандарт, 2-е издание, 2014). 3GPP продолжил работать над адаптивной потоковой передачей HTTP в содружестве с MPEG и опубликовал ТУ 3GP-DASH (динамическая адаптивная потоковая передача по HTTP; 3GPP TS 26.247: "Transparent end-to-end packet-switched streaming Service (PSS); Progressive download and dynamic adaptive Streaming over HTTP (3GP-DASH)". MPEG DASH и 3GP-DASH технически близки друг к другу и поэтому могут совместно именоваться DASH. Некоторые принципы, форматы и операции DASH описаны ниже в качестве примера системы потоковой передачи видео, в которых могут быть реализованы варианты осуществления. Аспекты изобретения не ограничиваются DASH, а описание приведено в качестве одной возможной основы, на которой можно частично или полностью реализовать изобретение.

[0198] В DASH мультимедийный контент может храниться на сервере HTTP и может доставляться с использованием HTTP. Контент может храниться на сервере в двух частях: описание медиа-презентации (MPD, Media Presentation Description), которое описывает манифест доступного контента, его различные альтернативы, их URL-адреса и другие характеристики; и сегменты, которые содержат фактические мультимедийные битовые потоки в форме фрагментов, в единственном файле или множественных файлах. MDP предоставляет информацию, необходимую клиентам для установления динамической адаптивной потоковой передачи по HTTP. MPD содержит информацию, описывающую медиа-презентацию, например, унифицированный указатель местоположения ресурса (URL) HTTP каждого сегмента, чтобы делать запрос сегмента GET. Для воспроизведения контента, клиент DASH может получать MPD, например, с использованием HTTP, электронной почты, флэш-накопителя, вещания или других способов переноса. Разбирая MPD, клиент DASH может узнавать о синхронизации программы, доступности медиа-контента, типах медиа, разрешениях, минимальной и максимальной полосах и наличии различных кодированных альтернатив мультимедийных компонентов, признаках доступности и необходимого управления цифровыми правами (DRM), положениях медиа-компонентов в сети и других характеристиках контента. С использованием этой информации, клиент DASH может выбирать надлежащую кодированную альтернативу и начинать потоковую передачу контента путем выборки сегментов с использованием, например, запросов GET HTTP. После надлежащей буферизации для обеспечения изменений пропускной способности сети, клиент может продолжать выборку последующих сегментов и также отслеживать флуктуации полосы сети. Клиент может принимать решение, как адаптироваться к доступной полосе, путем выборки сегментов разных альтернатив (с более низкими или более высокими битовыми скоростями) для поддержания адекватного буфера.

[0199] В DASH иерархическая модель данных используется для структурирования медиа-презентации следующим образом. Медиа-презентация состоит из последовательности одного или более периодов, каждый из которых содержит одну или более групп, каждая из которых содержит один или более адаптационных наборов, каждый из которых содержит одно или более представлений, каждое из которых состоит из одного или более сегментов. Представление является одним из альтернативных вариантов выбора медиа-контента или его поднабора, обычно отличающегося выбором кодирования, например, битовой скоростью, разрешением, языком, кодеком и т.д. Сегмент содержит некоторую длительность медиаданных, и метаданные для декодирования и презентации включенного медиа-контента. Сегмент идентифицируется посредством URI и обычно может запрашиваться посредством запроса GET HTTP. Сегмент можно определить как блок данных, связанных с HTTP-URL и, опционально, байтовым диапазоном, которые указаны посредством MPD.

[0200] DASH MPD согласуется с расширяемым языком разметки (XML) и поэтому задается элементами и атрибутами, заданными в XML.

[0201] В DASH, все описательные элементы структурируются одинаково, а именно, они содержат атрибут @schemeIdUri, который предоставляет URI для идентификации схемы, опциональный атрибут @value и опциональный атрибут @id. Семантика элемента характерна для используемой схемы. URI-идентификация схемы может быть URN или URL.

[0202] В DASH, независимое представление можно определить как представление, которое можно обрабатывать независимо от любых других представлений. Можно понять, что независимое представление содержит независимый битовый поток или независимый уровень битового потока. Зависимое представление можно определить как представление, для которого сегменты из дополняющих его представлений необходимы для презентации и/или декодирования содержащихся компонентов медиа-контента. Можно понять, что зависимое представление содержит, например, предсказанный уровень масштабируемого битового потока. Дополняющее представление можно определить как представление, которое дополняет по меньшей мере одно зависимое представление. Дополняющее представление может быть независимым представлением или зависимым представлением. Зависимые представления можно описать элементом представления, который содержит атрибут @dependencyId. Зависимые представления можно рассматривать как регулярные представления, за исключением того, что они зависят от набора дополняющих представлений для декодирования и/или презентации. @dependencyId содержит значения атрибута @id всех дополняющих представлений, т.е. представлений, которые необходимы для презентации и/или декодирования компонентов медиа-контента, содержащихся в этом зависимом представлении.

[0203] Ссылки на трек ISOBMFF можно отразить в списке четырехсимвольных кодов в атрибуте @associationType DASH MPD, который взаимно-однозначно отображается в список значений Representation@id, заданных в @associationId. Эти атрибуты могут использоваться для связывания представлений медиа с представлениями метаданных.

[0204] Служба DASH может предоставляться как служба по требованию или оперативная служба. В первом случае, MPD является статическим, и все сегменты медиа-презентации уже доступны, когда поставщик контента публикует MPD. В последнем случае, однако, MPD может быть статическим или динамическим в зависимости от способа построения URL сегментов, используемых в MPD, и сегменты создаются непрерывно по мере создания контента и его публикации клиентам DASH поставщиком контента. Способ построения URL сегментов может представлять собой либо способ построения URL сегментов на основе шаблона, либо способ генерации списка сегментов. В первом случае, клиент DASH способен строить URL сегментов без обновления MPD до запрашивания сегмента. В последнем случае, клиенту DASH приходится периодически загружать обновленные MPD для получения URL сегментов. Следовательно, для оперативной службы, способ построения URL сегментов на основе шаблона предпочтительнее способа генерации списка сегментов.

[0205] Сегмент инициализации можно определить как сегмент, содержащий метаданные, необходимые для презентации медиа-потоков, инкапсулированных а медиа-сегментах. В форматах сегмента на основе ISOBMFF, сегмент инициализации может содержать бокс фильма ('moov'), который не включает в себя метаданные ни для каких отсчетов, т.е. любые метаданные для отсчетов предоставляются в боксах 'moof.

[0206] Медиа-сегмент содержит некоторую длительность медиаданных для воспроизведения с нормальной скоростью, такая длительность называется длительностью медиа-сегмента или длительностью сегмента. Создатель контента или поставщик услуг может выбирать длительность сегмента согласно желаемым характеристикам службы. Например, относительно малая длительность сегмента может использоваться в оперативной службе для достижения короткого времени задержки между конечными пунктами. Причина в том, что длительность сегмента обычно является нижней границей времени задержки между конечными пунктами, воспринимаемой клиентом DASH, поскольку сегмент является дискретной единицей генерирования медиаданных для DASH. Генерация контента обычно осуществляется таким образом, что весь сегмент медиаданных становится доступным для сервера. Кроме того, многие реализации клиента используют сегмент в качестве блока для запросов GET. Таким образом, в типичных конфигурациях для оперативных служб сегмент может запрашиваться клиентом DASH только тогда, когда полная длительность медиа-сегмента доступна, а также кодируется и инкапсулируется в сегмент. Для службы по требованию могут использоваться разные стратегии выбора длительности сегмента.

[0207] Сегмент может дополнительно разбиваться на подсегменты, например, чтобы можно было загружать сегменты множественными частями. Может потребоваться, чтобы подсегменты содержали полные блоки доступа. Подсегменты могут индексироваться боксом индексации сегмента (также известным как SegmentIndexBox), который содержит информацию для отображения временного диапазона презентации и байтового диапазона для каждого подсегмента. Бокс индексации сегмента также может описывать подсегменты и точки доступа потока в сегменте путем сигнализации их длительностей и байтовых смещений. Клиент DASH может использовать информацию, полученную из бокса(ов) индексации сегмента, чтобы делать запрос GET HTTP для конкретного подсегмента с использованием запроса байтового диапазона HTTP. Если используется относительно большая длительность сегмента, то подсегменты можно использовать для поддержания размера ответов HTTP приемлемым и гибким для адаптации битовой скорости. Информацию индексации сегмента можно помещать в единственный бокс в начале этого сегмента, или распределять между многими боксами индексации в сегменте. Возможны разные способы распределения, например, иерархический, гирляндная цепь и гибридный. Этот метод может избегать добавления большого бокса в начале сегмента и, таким образом может препятствовать возможной задержке начальной загрузки.

[0208] (Под)сегмент обозначения (нотации) относится либо к сегменту, либо к подсегменту. В отсутствие боксов индексации сегментов, (под)сегмент обозначения относится к сегменту. При наличии боксов индексации сегментов, (под)сегмент обозначения может означать сегмент или подсегмент, например, в зависимости от того, выдает ли клиент запросы на основе сегментов или подсегментов.

[0209] MPEG-DASH задает форматы сегмента-контейнера для транспортных потоков обоих базовых форматов медиафайла ISO и MPEG-2. Другие спецификации могут указывать форматы сегмента на основании других форматов контейнера. Например, предложен формат сегмента на основании формата файла-контейнера Matroska.

[0210] DASH поддерживает адаптацию скорости путем динамического запрашивания медиа-сегментов из разных представлений в адаптационном наборе для согласования с изменяющейся полосой сети. Когда клиент DASH переключает представление вверх/вниз, нужно учитывать зависимости кодирования в представлении. Переключение представления может происходить в точке произвольного доступа (RAP), которая обычно используется в методах видеокодирования, например H.264/AVC. В DASH более общее понятие, именуемое точкой доступа к потоку (SAP, Stream Access Point), вводится для обеспечения кодеко-независимого решения для осуществления доступа к представлению и переключения между представлениями. В DASH SAP указывают как позицию в представлении, которая позволяет воспроизводить медиа-поток, который должен начинаться с использованием только информации, содержащейся в данных представления, начинающихся с этой позиции вперед (которой предшествуют данные инициализации в сегменте инициализации, при их наличии). Следовательно, представление переключение может осуществляться в SAP.

[0211] В DASH автоматизированный выбор между представлениями в одном и том же адаптационном наборе осуществлено на основании ширины и высоты (@width и @height); частоты кадров (@frameRate); битовой скорости (@bandwidth); указанного упорядочения качества между представлениями (@qualityRanking). Семантика @qualityRanking указана следующим образом: указывает ранжирование качества представления относительно других представлений в одном и том же адаптационном наборе. Более низкие значения представляют более высокое качество контента. В случае отсутствия, ранжирование не определяется.

[0212] Было определено несколько типов SAP, включающих в себя следующее. Тип SAP 1 соответствует тому, что известно в некоторых схемах кодирования как "точка произвольного доступа замкнутой GOP" (где все изображения, в порядке декодирования, можно правильно декодировать, получая непрерывную временную последовательность правильно декодированных изображений без промежутков) и, кроме того, первое изображение в порядке декодирования также является первым изображением в порядке презентации. Тип SAP 2 соответствует тому, что известно в некоторых схемах кодирования как "точка произвольного доступа замкнутой GOP" (где все изображения, в порядке декодирования, можно правильно декодировать, получая непрерывную временную последовательность правильно декодированных изображений без промежутков), для которого первое изображение в порядке декодирования может не быть первым изображением в порядке презентации. Тип SAP 3 соответствует тому, что известно в некоторых схемах кодирования как "точка произвольного доступа открытой GOP", где могут существовать некоторые изображения в порядке декодирования, которые не могут правильно декодироваться и имеют времена презентации, меньшие, чем внутренне кодированное изображение, связанное с SAP.

[0213] В некоторых стандартах видеокодирования, например MPEG-2, каждое интра-изображение является точкой произвольного доступа в кодированной последовательности. Возможность гибкого использования множественных опорных изображения для внешнего предсказания в некоторых стандартах видеокодирования, например, Н.264/AVC и H.265/HEVC, приводит к тому, что интра-изображения может быть недостаточно для произвольного доступа. Поэтому изображения могут маркироваться в отношении их функциональности как точек произвольного доступа вместо вывода такой функциональности из типа кодирования; например, изображение ПЖ, как указано в стандарте H.264/AVC, может использоваться в качестве точки произвольного доступа. Замкнутая группа изображений (GOP, group of pictures) это такая группа изображений, в которой все изображения можно правильно декодировать. Например, в Н.264/AVC, замкнутая GOP может начинаться с блока доступа ПЖ.

[0214] Открытая группа изображений (GOP) это такая группа изображений, в которой изображения, предшествующие начальному интра-изображению в порядке вывода, может неправильно декодироваться, но изображения, следующие за начальным интра-изображением в порядке вывода, декодируются правильно. Такое начальное интра-изображение может быть указано в битовом потоке и/или выводиться из указаний из битового потока, например, с использованием типа блока NAL CRA в HEVC. Изображения, предшествующие начальному интра-изображению, начинающему открытую GOP в порядке вывода и следующие за начальным интра-изображением в порядке декодирования, могут именоваться опережающими изображениями (leading pictures). Существуют два типа опережающих изображений: декодируемые и недекодируемые. Декодируемые опережающие изображения, например, изображения RADL HEVC, отличаются тем, что их можно правильно декодировать, когда декодирование начинается от начального интра-изображения, начинающего открытую GOP. Другими словами, декодируемые опережающие изображения используют только начальное интра-изображение или последующие изображения в порядке декодирования в качестве ссылки во внешнем предсказании. Недекодируемые опережающие изображения, например, изображения RASL HEVC, отличаются тем, что их нельзя правильно декодировать, когда декодирование начинается от начального интра-изображения, начинающего открытую GOP.

[0215] Предварительный выбор DASH задает поднабор медиа-компонентов MPD, которые предполагаются совместно используемыми одним экземпляром декодера, причем использование может содержать декодирование и рендеринг. Адаптационный набор, который содержит главный медиа-компонент для предварительного выбора, именуется главным адаптационным набором. Кроме того, каждый предварительный выбор может включать в себя один или несколько частичных адаптационных наборов. Частичные адаптационные наборы могут нуждаться в обработке совместно с главным адаптационным набором. Главный адаптационный набор и частичные адаптационные наборы могут быть указаны одним из двух средств: описателем предварительного выбора или элементом предварительного выбора.

[0216] Виртуальная реальность является быстро развивающейся областью технологии, в которой изображение или видеоконтент, иногда сопровождаемое аудиодорожкой, обеспечивается пользовательским устройством, например, пользовательской гарнитурой (также известной как шлем-дисплей). Как известно, пользовательское устройство может обеспечиваться оперативным или сохраненным контентом от источника контента, причем контент представляет виртуальное пространство для иммерсионного вывода посредством пользовательского устройства. В настоящее время многие пользовательские устройства виртуальной реальности используют так называемые три степени свободы (3DoF), и это означает, что движение головы по осям рысканья, тангажа и крена измеряют и определяют, что пользователь видит, для определения окна наблюдения. Известно, что рендеринг с учетом позиции пользовательского устройства и изменений позиции может улучшать иммерсионное восприятие. Таким образом, улучшение до 3DoF является системой виртуальной реальности с шестью степенями свободы (6DoF), где пользователь может свободно перемещаться в евклидовом пространстве, а также поворачивать голову по осям рысканья, тангажа и крена. Системы виртуальной реальности с шестью степенями свободы обеспечивают предоставление и потребление объемного контента. Объемный контент содержит данные, представляющие пространства и/или объекты в трех измерениях из всех углов, что позволяет пользователю полностью перемещаться вокруг пространства и/или объектов для наблюдения их под любым углом. Такой контент может задаваться данными, описывающими геометрию (например, форму, размер, позицию в трехмерном пространстве), и атрибутами, например, цветом, непрозрачностью и коэффициентом отражения. Данные также могут задавать изменения с течением времени в геометрии и атрибутах в заданные моменты времени, аналогично кадрам в двухмерном видео.

[0217] Термины 360-градусное видео или видео виртуальной реальности (VR, virtual reality) могут иногда использоваться взаимозаменяемо. Они могут в общем случае относиться к видеоконтенту, который обеспечивает такое большое поле зрения (FOV), что только часть видео отображается в единственный момент времени в конфигурациях отображения. Например, видео VR можно наблюдать на шлеме-дисплее (HMD), который имеет возможность отображения, например, около 100-градусного поля зрения. Пространственный поднабор видеоконтента VR, подлежащего отображению, может выбираться на основании ориентации HMD. В другом примере, предполагается плоскопанельная среда наблюдения, в которой может отображаться поле зрения шириной, например, до 40 градусов. При отображении контента широкого FOV (например, рыбий глаз) на таком дисплее, предпочтительно отображать пространственный поднабор, а не все изображение.

[0218] Всенаправленный медиа-формат (OMAF) MPEG (ISO/ГЕС 23090-2) является стандартом системы виртуальной реальности (VR). OMAF задает медиа-формат (содержащий как формат файла, выведенный из ISOBMFF, и форматы потоковой передачи для переноса медиа DASH и MPEG). OMAF версия 1 поддерживает 360° видео, изображения и аудио, а также связанный синхронизированный текст и облегчает потребление контента с тремя степенями свободы (3DoF), в том смысле, что окно наблюдения можно выбирать с любым азимутом и диапазоном возвышения и углом наклона, которые покрыты всенаправленным контентом, но контент не адаптирован к поступательному движению позиции наблюдения. Сценарии потоковой передачи, зависящей от окна наблюдения, дополнительно описанные ниже, также разработаны для 3DoF, хотя потенциально могут быть адаптированы к другому количеству степеней свободы.

[0219] Рассмотрим OMAF со ссылкой на фиг. 1. Аудиовизуальная сцена (А) реального мира может захватываться 220 датчиками аудиодорожки, а также набором камер или устройством камеры с многочисленными линзами и датчиками. Захват дает набор сигналов цифрового изображения/видео (Bi) и аудио (Ва). Камеры/линзы могут покрывать все направления вокруг центральной точки набора камер или устройства камеры, из-за чего это и называется 360-градусное видео.

[0220] Аудио может захватываться с использованием многих разных конфигураций микрофонов и сохраняться как несколько разных форматов контента, включающих в себя сигналы на канальной основе, сигналы статических или динамических (т.е. движущихся посредством 3D сцены) объектов, и сигналы на основе сцены (например, амбиофония более высокого порядка). Сигналы на канальной основе могут отвечать одной из компоновок громкоговорителей, заданных в CICP (не зависящих от кодирования кодовых точках, Coding-Independent Code-Points). В приложении всенаправленных медиа сигналы компоновки громкоговорителей представляемой иммерсионной аудио-программы могут преобразовываться в стерео-формат для презентации через наушники.

[0221] Изображения (Bi) одного и того же момента времени сшиваются, проецируются и отображаются 221 в упакованное изображение (D).

[0222] Для моноскопического 360-градусного видео, входные изображения одного момента времени могут сшиваться для генерации проецируемого изображения, представляющего один ракурс. Пример процесса сшивания, проекции и упаковки по областям изображений для моноскопического контента проиллюстрирован на фиг. 3. Входные изображения (Bi) сшиваются и проецируются 202 на структуру трехмерной проекции, которой может быть, например, единичная сфера. Структуру проекции можно рассматривать как содержащую одну или более поверхностей, например, плоскость(и) или ее часть(и). Структуру проекции можно определить как трехмерную структуру, состоящую из одной или более поверхностей, куда проецируется захваченное(ый) изображение/видеоконтент VR, и из которого может формироваться соответствующее проецируемое изображение. Данные изображения на структуре проекции дополнительно размещаются на двухмерном проецируемом изображении (CL для левого глаза, CR для правого глаза) 203. Термин "проекция" можно определить как процесс, в котором набор входных изображений проецируется на проецируемое изображение. Может существовать заранее заданный набор форматов представления проецируемого изображения, включающий в себя, например, формат равнопрямоугольной проекции (ERP, equirectangular projection) и формат проекции кубической карты (CMP, cube map projection). Можно считать, что проецируемое изображение покрывает всю сферу.

[0223] Опционально, затем применяется упаковка 204 по областям для отображения проецируемого изображения 203 (С) в упакованное изображение 205 (D). Если упаковка по областям не применяется, упакованное изображение идентично проецируемому изображению, и это изображение задается в качестве ввода в кодирование 206 изображения/видеосигнала. Иначе, области проецируемого изображения (С) отображаются в упакованное изображение (D) путем указания положения, формы и размера каждой областям в упакованном изображении, и упакованное изображение (D) задается в качестве ввода в кодирование изображения/видеосигнала. Термин "упаковка по областям" можно определить как процесс, в котором проецируемое изображение отображается в упакованное изображение. Термин "упакованное изображение" можно определить как изображение, получаемое путем упаковки по областям проецируемого изображение.

[0224] В случае стереоскопического 360-градусного видео, входные изображения одного момента времени сшиваются для генерации проецируемого изображения, представляющего два ракурса (CL, CR), по одному для каждого глаза. Оба ракурса (CL, CR) могут отображаться в одно и то же упакованное изображение (D) и кодироваться традиционным 2D видеокодером. Альтернативно, каждый ракурс проецируемого изображения может отображаться в его собственное упакованное изображение, и в этом случае сшивание, проекция и упаковка по областям изображений осуществляется, как показано на фиг. 2. Последовательность упакованных изображений левого ракурса или правого ракурса может кодироваться независимо или, при использовании многоракурсного видеокодера, предсказываться из другого ракурса.

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

[0226] 360-градусный панорамный контент (т.е. изображения и видео) охватывает по горизонтали полное 360-градусное поле зрения вокруг позиции захвата устройства формирования изображения. Вертикальное поле зрения может изменяться и может, например, составлять 180 градусов. Панорамное изображение, охватывающее 360-градусное поле зрения по горизонтали и 180-градусное поле зрения по вертикали, может быть представлено сферой, которая отображается в плоскость двухмерного изображения с использованием равнопрямоугольной проекции (ERP). В этом случае, горизонтальную координату можно рассматривать как эквивалент долготе, и вертикальную координату можно рассматривать как эквивалент широте, без применения преобразования или масштабирования. Процесс формирования моноскопического равнопрямоугольного панорамного изображения проиллюстрирован на фиг. 4. Набор входных изображений 211, например, изображения типа рыбий глаз массива камер или устройства камеры с многочисленными линзами и датчиками, сшивается 212 на сферическое изображение 213. Сферическое изображение дополнительно проецируется 214 на цилиндр 215 (без верхней и нижней граней). Цилиндр разворачивается 216 для формирования двухмерного проецируемого изображения 217. На практике один или более из представленных этапов могут объединяться; например, входные изображения могут непосредственно проецироваться на цилиндр без промежуточной проекции на сферу. Структуру проекции для равнопрямоугольной панорамы можно рассматривать как цилиндр, который содержит единую поверхность.

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

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

[0229] Информация упаковки по областям может кодироваться как метаданные в битовом потоке или наряду с ним. Например, информация упаковки может содержать отображение по областям из заранее заданного или указанного исходного формата в формат упакованного изображения, например из проецируемого изображения в упакованное изображение, как описано выше.

[0230] Метаданные прямоугольной упаковки по областям можно описать следующим образом:

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

[0232] Помимо прочего, упаковка по областям обеспечивает сигнализацию для следующих сценариев использования:

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

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

3) Генерация зависимых от окна наблюдения битовых потоков, которые используют независимые от окна наблюдения форматы проекции. Например, области ERP или грани СМР могут иметь разные плотности дискретизации, и нижележащая структура проекции может иметь разные ориентации.

4) Указание областей упакованных изображений, представленных треком экстрактора. Это необходимо, когда трек экстрактора собирает тайлы из битовых потоков разных разрешений.

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

[0234] Возвращаясь к фиг. 1, OMAF позволяет исключать сшивания, проекции и упаковки по областям изображений и кодировать изображение/видеоданные в их захваченном формате. В этом случае, изображения (D) считаются такими же, как изображения (Bi), и кодируются ограниченное количество изображений типа рыбий глаз на момент времени.

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

[0236] Сшитые изображения (D) кодируются 206 как кодированные изображения (Ei) или битовый поток кодированного видео (Ev). Захваченное аудио (Ва) кодируется 222 как битовый поток аудио (Еа). Затем кодированные изображения, видео и/или аудио составляются 224 в медиафайл для воспроизведения (F) файла или последовательности сегментов инициализации и медиа-сегментов для потоковой передачи (Fs), согласно конкретному формату файла-контейнера медиа. В этом описании изобретения, формат файла-контейнера медиа является базовым форматом медиафайла ISO. Файловый инкапсулятор 224 также включает метаданные в файл или сегменты, например, информацию проекции и упаковки по областям, помогающую в рендеринге декодированных упакованных изображений.

[0237] Метаданные в файле могут включать в себя:

- формат проекции проецируемого изображения,

- параметры видео типа рыбий глаз,

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

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

- информацию упаковки по областям, и

- ранжирование качества по областям (опционально).

[0238] Информация упаковки по областям может кодироваться как метаданные в битовом потоке или наряду с ним, например, как сообщение(я) SEI упаковки по областям и/или как боксы упаковки по областям в файле, содержащем битовый поток. Например, информация упаковки может содержать отображение по областям из заранее заданного или указанного исходного формата в формат упакованного изображения, например из проецируемого изображения в упакованное изображение, как описано выше. Информация отображения по областям может содержать, например, для каждой отображаемой области исходный прямоугольник (также известный как проецируемая область) в проецируемом изображении и конечный прямоугольник (также известный как упакованная область) в упакованном изображении, где отсчеты в исходном прямоугольнике отображаются в конечный прямоугольник, и прямоугольники можно указывать, например, положениями верхнего левого угла и нижнего правого угла. Отображение может содержать передискретизацию. Дополнительно или альтернативно, информация упаковки может содержать одно или более из следующих: ориентацию структуры трехмерной проекции относительно системы координат, указание используемого формата проекции, ранжирование качества по областям, указывающее ранжирование качества изображения между областями и/или первую и вторую последовательности пространственных областей, одну или более операций преобразования, например, поворот на 90, 180 или 270 градусов, горизонтальное отражение и вертикальное отражение. Семантика информации упаковки может задаваться таким образом, что они указывают для каждого отсчета положение в упакованных областях декодированного изображения, которое является соответствующим положением в сферических координатах.

[0239] Сегменты (Fs) могут доставляться 225 с использованием механизма доставки в приложение воспроизведения.

[0240] Файл (F), который выводит файловый инкапсулятор, идентичен файлу (F'), который вводится в файловый декапсулятор. Файловый декапсулятор 226 обрабатывает файл (F') или принятые сегменты (F's) и извлекает кодированные битовые потоки (Е'а, E'v и/или E'i) и разбирает метаданные. Затем аудио, видео и/или изображения декодируются 228 в декодированные сигналы (В'а для аудио, и D' для изображений/видео). Декодированные упакованные изображения (D') проецируются 229 на экран шлема-дисплея или любое другое устройство 230 отображения на основании текущей ориентации наблюдения или окна наблюдения и проекции, сферического покрытия, ориентации структуры проекции и метаданных упаковки по областям, разобранных из файла. Аналогично, декодированный аудиосигнал (В'а) представляется 229, например, посредством наушников 231, согласно текущей ориентации наблюдения. Текущая ориентация наблюдения определяется путем отслеживания положения головы и, возможно, также функционала 227 отслеживания направления взгляда. Помимо использования рендерера 229 для рендеринга надлежащей части декодированных видео- и аудиосигналов, текущая ориентация наблюдения также может использоваться видео-и аудио-декодерами 228 для оптимизации декодирования.

[0241] Вышеописанный процесс применим как к оперативному использованию, так и варианту использования по требованию.

[0242] В любой момент времени видео, визуализированное приложением на HMD или другом устройстве отображения, визуализирует участок 360-градусного видео. Этот участок можно определить как окно наблюдения. Под окном наблюдения можно понимать окно в 360-градусном мире, представленном во всенаправленном видео, отображаемое посредством дисплея рендеринга. Согласно другому определению, окно наблюдения можно определить как часть сферического видео, отображаемого в данный момент. Окно наблюдения может характеризоваться горизонтальным и вертикальным полями зрения (FOV или FoV).

[0243] Точку наблюдения можно определить как точку или пространство, из которой(го) пользователь наблюдает сцену; она обычно соответствует позиции камеры. Небольшое движение головы не приводит к смене точки наблюдения. Позицию наблюдения можно определить как позицию в пространстве наблюдения, откуда пользователь наблюдает сцену. Пространство наблюдения можно определить как 3D пространство позиций наблюдения, где разрешен рендеринг изображения и видео и возможно восприятие VR.

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

[0245] Развитие вычислительных ресурсов и устройств трехмерного получения позволяют реконструировать высокодетальные объемные представления. Инфракрасные, лазерные, времяпролетные и структурированные световые технологии являются примерами построения такого контента. Представление объемного контента может зависеть от того, как использовать данные. Например, плотные массивы вокселей могут использоваться для представления объемных медицинских изображений. В трехмерной графике широко используются многоугольные сетки. Облака точек, с другой стороны, весьма пригодны для приложений, например, сцен захвата реального мира, где топология сцены не обязательно является двухмерной поверхностью или многообразием. Другой способ предусматривает кодирование трехмерных данных в набор карт текстуры и глубины. С этим тесно связано использование карт возвышения и многоуровневой поверхности. Рассмотренные здесь варианты осуществления применимы к любой из вышеперечисленных технологий.

[0246] "Воксель" трехмерного мира соответствует пикселю двухмерного мира. Воксели существуют в компоновке трехмерной сетки. Октадеревом является древовидная структура данных, используемая для разбиения трехмерного пространства. Октадеревья являются трехмерным аналогом квадрадеревьев. Разреженное октадерево вокселей (SVO, sparse voxel octree) описывает объем пространства, содержащего набор сплошных вокселей изменяющихся размеров. Пустые области в пределах объема отсутствуют в дереве, из-за чего оно именуется "разреженным".

[0247] Трехмерное объемное представление сцены может определяться как множество вокселей на основе входных потоков по меньшей мере одного многокамерного устройства. Таким образом, по меньшей мере один, но предпочтительно несколько (т.е. 2, 3, 4, 5 или более) многокамерных устройств может использоваться для захвата 3D представление видео сцены. Многокамерные устройства распределяются в разных положениях относительно сцены, и, таким образом каждое многокамерное устройство захватывает отдельное 3D представление видео сцены. 3D представления видео, захваченные каждым многокамерным устройством, могут использоваться в качестве входных потоков для создания 3D объемного представления сцены, причем упомянутое 3D объемное представление содержит множество вокселей. Воксели могут формироваться из захваченных 3D точек, например, путем соединения 3D точек в воксели, содержащие множество 3D точек, таким образом, что для выбранной 3D точки все соседние 3D точки в пределах заранее заданного порога от выбранной 3D точки объединяются в воксель без превышения максимального количества 3D точек в вокселе.

[0248] Воксели также можно формировать путем построения разреженного октадерева вокселей. Каждый лист такого дерева представляет сплошной воксель в пространстве мира; корневой узел дерева представляет границы мира. Построение разреженного октадерева вокселей может осуществляться следующими этапами: 1) отображать каждую входную карту глубины в облако точек пространства мира, где каждый пиксель карты глубины отображается в одну или более 3D точек; 2) определять атрибуты вокселя, например, цвет и вектор нормали к поверхности путем проверки соседства исходного(ых) пикселя(ей) в изображениях камеры и карты глубины; 3) определять размер вокселя на основании значения глубины из карты глубины и разрешения карты глубины; 4) определять уровень SVO для сплошного вокселя как функцию его размера относительно границ мира; 5) определять координаты вокселя на этом уровне относительно границ мира; 6) создавать новые и/или обходить существующие узлы SVO, до прихода в определенные координаты вокселя; 7) вставлять сплошной воксель как лист дерева, возможно заменять или соединять атрибуты из ранее существовавшего вокселя в этих координатах. Тем не менее, размеры вокселя в 3D объемном представлении сцены могут отличаться друг от друга. Воксели 3D объемного представления, таким образом, представляют пространственные положения в сцене.

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

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

[0251] В таких технологиях как плотные облака точек и массивы вокселей может существовать десятки или даже сотни миллионов точек. Для хранения и переноса такого контента между объектами, например, между сервером и клиентом по IP-сети, обычно требуется сжатие.

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

[0253] Угловая протяженность окружения, наблюдаемого или слышимого посредством конфигурации рендеринга, например, шлема-дисплея, может именоваться визуальным полем зрения (FOV). Фактическое FOV, наблюдаемое или слышимое пользователем, зависит от межзрачкового расстояния и от расстояния между линзами гарнитуры виртуальной реальности и глазами пользователя, но FOV можно считать приблизительно одинаковым для всех пользователей заданного устройства отображения, когда пользователь носит гарнитуру виртуальной реальности.

[0254] При наблюдении объемного контента из единственной позиции наблюдения, участок (часто половина) контента может быть не виден, поскольку он обращен от пользователя. Этот участок иногда именуется "задним контентом".

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

[0256] Информация видимости патча представляет собой данные, указывающие, где в объемном пространстве можно видеть переднюю поверхность патча. Например, информация видимости патча может содержать конус видимости, который может содержать вектор (X, Y, Z) направления конуса видимости и угол раскрытия (А). Угол раскрытия (А) задает набор телесных углов, из которых можно видеть переднюю поверхность патча. В другом примере, метаданные видимости патча могут содержать определение ограничивающей сферической поверхности и метаданные области сферы, идентичные или аналогичные указанным стандартом всенаправленного медиа-формата (OMAF) (ISO/ГЕС 23090-2). Ограничивающая сферическая поверхность может задаваться, например, трехмерным положением центра сферы и радиусом сферы. Когда позиция наблюдения совпадает с ограничивающей сферической поверхностью, патч можно считать видимым в указанной области сферы. В общем случае, геометрия ограничивающей поверхности также может отличаться от сферы, например, принимая форму цилиндра, куба или прямоугольного параллелепипеда. Множественные наборы метаданных видимости патча могут задаваться для того же трехмерного положения центра ограничивающей поверхности, но с другими радиусами (или информацией, указывающей расстояние ограничивающей поверхности от трехмерного положения). Указание нескольких фрагментов метаданных видимости патча может быть полезно для обработки преград.

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

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

[0259] В ряде случаев, исходный объем объемного изображения, например кадр облака точек, может проецироваться на одну или более проекционных поверхностей. Патчи на проекционных поверхностях могут определяться, и эти патчи могут располагаться в одном или более двухмерных кадрах. Как указано выше, патчи текстуры и глубины могут формироваться аналогично. Демонстрирует проекцию исходного объема на проекционную поверхность, и вписывание разреженной проекции. Другими словами, модель трехмерной (3D) сцены, содержащая геометрические примитивы, например, элементы сетки, точки и/или воксель, проецируется на одну или более проекционных поверхностей. Эти геометрии проекционной поверхности могут "развертываться" на 2D плоскости (обычно по две плоскости на проецируемый исходный объем: одну для текстуры, одну для глубины). "Развертка" может включать в себя определение патчей. Затем 2D плоскости могут кодироваться с использованием стандартного 2D изображения или технологий сжатия видео. Соответствующая информация проекционной геометрии может передаваться совместно с кодированными видеофайлами в декодер. Затем декодер может декодировать кодированное изображение/видеопоследовательность и осуществлять обратную проекцию для регенерации объекта модели 3D сцены в любом желаемом формате представления, который может отличаться от начального формата, например, реконструировать облако точек из исходных данных модели сетки.

[0260] В ряде случаев, множественные точки объемного видео или изображения (например, облако точек) проецируются в одну и ту же пиксельную позицию. Такие случаи могут обрабатываться путем создания более чем одного "уровня". Заметим, что понятие уровня в объемном видео, например, при сжатии облака точек, может отличаться от понятия уровня в масштабируемом видеокодировании. Таким образом, такие термины как уровень РСС или уровень объемного видео могут использоваться для отличия от уровня масштабируемого видеокодирования. Каждый объемный (3D) патч может проецироваться на более чем один 2D патч, представляющие разные уровни визуальных данных, например, точек, проецируемых в одни и те же 2D позиции. Патчи могут быть организованы, например, на основе увеличения расстояния до плоскости проекции. Точнее говоря, следующий иллюстративный процесс может использоваться для создания двух уровней, но также может быть обобщен на другое количество уровней: пусть H(u,v) - набор точек текущего патча, который проецируется в один и тот же пиксель (u, v). Первый уровень, также именуемый ближним уровнем, сохраняет точку H(u,v) с самой малой глубиной D0. Второй уровень, именуемый дальним уровнем, захватывает точку H(u,v) с самой большой глубиной в интервале [D0, D0+d], где d - заданный пользователем параметр, который выражает толщину поверхности.

[0261] Следует понимать, что объемное изображение/видео может содержать, дополнительно или альтернативно текстуре и глубине, другие типы патчей, например, коэффициент отражения, непрозрачность или прозрачность (например, патч альфа-канала), нормаль к поверхности, альбедо и/или другие патчи атрибутов материала или поверхности.

[0262] Двухмерная форма патчей может упаковываться в один или более атласов. Атласы текстуры, известные в технике, содержат изображение, состоящее из субизображений, причем изображение обрабатывается как отдельный блок графическим оборудованием и может сжиматься и передаваться как единое изображение для последующей идентификации и снятия сжатия. Атласы геометрии могут строиться аналогично атласам текстуры. Атласы текстуры и геометрии могут обрабатываться как отдельные изображения (и как отдельные последовательности изображений в случае объемного видео), или атласы текстуры и геометрии могут упаковываться в один и тот же кадр, например аналогично традиционно осуществляемой упаковке кадров. Атласы могут кодироваться как кадры с помощью кодера изображений или видео.

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

[0264] В ряде случаев, один или более (но не весь набор) пространственно-временных блоков может предоставляться и храниться как трек в контексте базового формата медиафайла ISO или как структура файла-контейнера любого аналогичного формата. Такой трек может именоваться треком патча. Треки патчей могут быть, например, треками субизображений, применяемых в контексте OMAF, или треками тайлов, применяемых в контексте ISO/IEC 14496-15.

[0265] В ряде случаев кодируется несколько версий одного или более атласов. Различные версии могут включать в себя, но без ограничения, одно или более из следующих: разные версии битовой скорости одного или более атласов с одним и тем же разрешением; разные пространственные разрешения атласов; и различные версии для разных интервалов произвольного доступа; они могут включать в себя один или более внутренне кодированных атласов (где каждое изображение допускает произвольный доступ).

[0266] В ряде случаев, комбинации патчей из различных версий атласа текстур могут быть предписаны и описаны как метаданные, например, треки экстрактора, применимые в контексте OMAF и/или ISO/IEC 14496-15.

[0267] Когда счетчик суммарного количества отсчетов атласа текстур и, в ряде случаев, изображений соответствующей геометрии и/или других вспомогательных изображений (при наличии) превышает предел, например, предельный уровень видеокодека, предписание можно авторизовать таким образом, чтобы предел соблюдался. Например, патчи можно выбирать из атласа текстур более низкого разрешения согласно субъективной важности. Выбор может осуществляться независимо от позиции наблюдения. Предписание может сопровождаться метаданными, характеризующими соблюдаемый(е) предел(ы), например, соблюдаемый уровень кодека.

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

[0269] Предписание может использовать конкретную сетку или рисунок из независимых пространственно-временных блоков. Например, предписание может использовать некоторую сетку тайлов, где границы тайла также являются границами MCTS. Предписание может сопровождаться метаданными, указывающими возможные источники (например, группы треков, треки или представления), которые пригодны в качестве пространственно-временных блоков.

[0270] В ряде случаев трек патча формирует представление в контексте DASH. В результате, элемент представления в DASH MPD может предоставлять метаданные о патче, например, метаданные видимости патча, связанные с треком патча. Клиент может выбирать представления патча и запрашивать (под)сегменты из выбранных представлений на основе метаданных видимости патча.

[0271] Трек сборщика можно определить как трек, который извлекает неявно или явно кодированные видеоданные, например, кодированные видеоданные MCTS или субизображений, из других треков. Будучи разрешенным для приложения чтения файлов и т.п., трек сборщика может давать битовый поток, который согласуется со стандартом или форматом видеокодирования. Трек сборщика может, например, извлекать MCTS или субизображения для формирования последовательности кодированных изображений, где MCTS или субизображения располагаются в сетке. Например, когда трек сборщика извлекает два MCTS или субизображения, они могут располагаться в сетке 2×1 MCTS или субизображения. Как будет рассмотрено ниже, трек экстрактора, который извлекает MCTS или субизображения из других треков, можно рассматривать как трек сборщика. Базовый трек тайлов, как будет рассмотрено ниже, является другим примером трека сборщика. Трек сборщика также может именоваться треком коллекции. Трек, который является источником для извлечения в трек сборщика, может именоваться треком элемента коллекции.

[0272] Экстракторы, заданные в ISO/IEC 14496-15 для H.264/AVC и HEVC, позволяют компактно формировать треки, которые извлекают данные блока NAL посредством ссылки. Экстрактор является структурой наподобие блока NAL. Структура наподобие блока NAL может задаваться содержащей заголовок блока NAL и полезную нагрузку блока NAL, как и любые блоки NAL, но предотвращение эмуляции начального кода (который требуется для блока NAL) может не использоваться в структуре наподобие блока NAL. Для HEVC экстрактор содержит один или более конструкторов. Конструктор отсчетов извлекает, посредством ссылки, данные блока NAL из отсчета другого трека. Встроенный конструктор включает в себя данные блока NAL. Термин "встроенный" может определяться, например, в отношении блока данных для указания, что содержащая синтаксическая структура содержит или несет блок данных (но не включает в себя блок данных посредством ссылки или посредством указателя данных). Когда экстрактор обрабатывается приложением чтения файлов, которое требует этого, экстрактор логически заменяется байтами, обусловленными разрешением содержащихся конструкторов в порядке их появления. Вложенное извлечение может быть запрещено, например, байты, на которые ссылается конструктор отсчетов, не могут содержать экстракторы; экстрактор не должен ссылаться, прямо или косвенно, на другой экстрактор. Экстрактор может содержать один или более конструкторов для извлечения данных из текущего трека или из другого трека, который связан с треком, в котором находится экстрактор, посредством ссылки на трек типа 'scal'. Байты разрешаемого экстрактора могут представлять один или более полных блоков NAL. Разрешаемый экстрактор начинается с верного поля длины и заголовка блока NAL. Байты конструктора отсчетов копируются из единственного идентифицированного отсчета в треке, указанном ссылкой 'scal' на трек. Выравнивание осуществляется по времени декодирования, т.е. с использованием только таблицы время-отсчет, за которой следует отсчитанное смещение номера отсчета. Экстракторы являются понятием уровня медиа и, таким образом, применяются к конечному треку до рассмотрения любого списка редактирования. (Однако обычно предполагается, что списки редактирования в двух треках идентичны).

[0273] При потоковой передаче, зависящей от окна наблюдения, которая также может именоваться потоковой передачей, адаптивной к окну наблюдения (VAS, viewport-adaptive streaming) или потоковой передачей, зависящей от окна наблюдения, поднабор 360-градусного видеоконтента, охватывающего окно наблюдения (т.е. текущая ориентация наблюдения), передается с лучшим качеством и/или более высоким разрешением, чем качество и/или разрешение для оставшегося 360-градусного видео. Для обеспечения потоковой передачи всенаправленного видео, зависящей от окна наблюдения, существует несколько альтернатив. В потоковой передаче на основе тайлов, зависящей от окна наблюдения, проецируемые изображения разбиваются на тайлы, которые кодируются как наборы тайлов с ограничением движения (MCTS) и т.п. Несколько версий контента кодируются с разными битовыми скоростями или характеристиками качества с использованием одного и того же разбиения MCTS. Каждая последовательность MCTS делается доступной для потоковой передачи как представление DASH и т.п. Приложение воспроизведения выбирает на основе MCTS битовую скорость или качество приема.

[0274] Н.264/AVC не включает в себя понятие тайлов, но операционно-подобные MCTS могут достигаться путем размещения областей вертикально в качестве слайсов и ограничения кодирования аналогично кодированию MCTS. Для простоты в этом документе используются термины тайл и MCTS, но следует понимать, что в Н.264/AVC они имеют ограниченное применение. В общем случае, следует понимать, что термины тайл и MCTS применяются к аналогичным принципам в любом формате или спецификации кодирования.

[0275] Возможные разновидности схем потоковой передачи на основе тайлов, зависящей от окна наблюдения, перечислены ниже:

- 360° видео смешанного качества по областям (RWMQ, Region-wise mixed quality): несколько версий контента кодируются с одинаковым разрешением, одинаковой сеткой тайлов и разной битовой скоростью / разным качеством изображения. Приложения воспроизведения выбирают высококачественные MCTS для окна наблюдения.

- Окно наблюдения + 360° видео: одна или более версий битовой скорости и/или разрешения полного всенаправленного видео низкого разрешения / низкого качества кодируются и делаются доступными для потоковой передачи. Кроме того, осуществляется кодирование на основе MCTS, и последовательности MCTS делаются доступными для потоковой передачи. Приложения воспроизведения принимают полное всенаправленное видео низкого разрешения / низкого качества и выбирают и принимают MCTS высокого разрешения, охватывающие окно наблюдения.

- 360° видео смешанного разрешения по областям (RWMR, Region-wise mixed resolution): MCTS кодируются с множественными разрешениями. Приложения воспроизведения выбирают комбинацию MCTS высокого разрешения, охватывающих окно наблюдения, и MCTS низкого разрешения для оставшихся областей.

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

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

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

[0279] В подходе трека тайлов, одна или более последовательностей наборов тайлов с ограничением движения извлекаются из битового потока, и каждая извлеченная последовательность наборов тайлов с ограничением движения сохраняется как трек тайлов (например, трек тайлов HEVC) в файле. Базовый трек тайлов (например, базовый трек тайлов HEVC) может генерироваться и сохраняться в файле. Базовый трек тайлов представляет битовый поток путем неявного сбора наборов тайлов с ограничением движения из треков тайлов. На стороне приемника треки тайлов, подлежащие потоковой передаче, могут выбираться на основании ориентации наблюдения. Клиент может принимать треки тайлов, охватывающие весь всенаправленный контент. Треки тайлов более высокого качества или разрешения могут приниматься для текущего окна наблюдения по сравнению с качеством или разрешением, охватывающим оставшееся 360-градусное видео. Базовый трек тайлов может включать в себя ссылки на треки тайлов, и/или треки тайлов могут включать в себя ссылки на базовый трек тайлов. Например, в HEVC, ссылка 'sabt' на трек используется в отношении треков тайлов из базового трека тайлов, и упорядочение тайлов указывается порядком треков тайлов, содержащихся в ссылке 'sabt' на трек. Кроме того, в HEVC, трек тайлов имеет ссылку 'tbas' на базовый трек тайлов.

[0280] В рамках подхода с участием экстрактора, одна или более последовательностей наборов тайлов с ограничением движения извлекаются из битового потока, и каждая извлеченная последовательность наборов тайлов с ограничением движения модифицируется с целью согласования со своим собственным битовым потоком (например, битовым потоком HEVC) и сохранения как трека субизображений (например, с непреобразованной записью отсчета типа 'hvc1' для HEVC) в файле. Один или более треков экстрактора (например, треки экстрактора HEVC) могут генерироваться и сохраняться в файле. Трек экстрактора представляет битовый поток путем явного извлечения (например, экстракторами HEVC) наборов тайлов с ограничением движения из треков субизображений. На стороне приемника треки субизображений, подлежащие потоковой передаче, могут выбираться на основании ориентации наблюдения. Клиент может принимать треки субизображений, охватывающие весь всенаправленный контент. Для текущего окна наблюдения могут приниматься треки субизображений более высокого качества или более высокого разрешения по сравнению с качеством или разрешением, охватывающим оставшееся 360-градусное видео.

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

[0282] Количество независимо кодированных областей изображения может быть сравнительно велико. В качестве примера часто упоминаются 96 областей (4×4 области для каждой грани куба). В приложениях потоковой передачи, один и тот же контент нередко подготавливается с несколькими разрешениями и битовыми скоростями; например, можно обеспечить с полдюжины вариантов из которых можно динамически выбирать клиентов потоковой передачи.

[0283] Намеченный размер изображения для объединенного битового потока может выбираться, например, согласно пригодному уровню видеокодирования. Разбиение изображений на сегменты изображения или независимо кодированные области изображения, например, разбиение на тайлы и кирпичи, применительно к объединенному битовому потоку может выбираться согласно ширине и высоте сегментов изображения или независимо кодированных областей изображения в доступных исходных битовых потоках. Для обеспечения гибкости для разных клиентских стратегий и условий наблюдения (например, поля зрения), ширину и высоту сегментов изображения и/или независимо кодированных областей изображения можно выбирать одинаковыми во всех доступных исходных битовых потоков.

[0284] Фиг. 11а демонстрирует пример, где контент кубической текстуры кодируется с разрешениями "8K", "6K", "4K" и "2K", для которого количество отсчетов яркости на экваторе равно 8192, 6144, 4096 и 2048, соответственно. Ширина и высота тайлов во всех версиях выбираются равными (512 отсчетов яркости). Каждый тайл кодируется как независимо кодированная область изображения.

[0285] Фиг. 11b демонстрирует пример, где сетка тайлов 3×11 выбирается для обеспечения возможности декодирования 4K.

[0286] Фиг. 11с демонстрирует пример, где клиент может выбирать тайлы из любой версии разрешения с использованием любой стратегии. В этом примере клиент выбирает столько тайлов из кубической текстуры "8K", сколько возможно, и поддерживает всю кубическую текстуру "2K" как резервную копию на случай непредвиденных изменений ориентации наблюдения.

[0287] Фиг. 11d демонстрирует пример, где в представленной стратегии "6K" клиент выбирает тайлы, покрывающие более двух граней куба из версии "6K", более двух граней куба из версии "4K" и три грани куба из версии "2K", таким образом, ориентируясь на постепенные изменения качества изображения в случае изменения ориентации наблюдения.

[0288] Следует понимать, что хотя подход трека тайлов и подход с участием экстрактора описаны подробно, в частности, в контексте HEVC, они применяются к другим кодекам и аналогичным принципам, как трекам тайлов или экстракторам. Кроме того, возможна комбинация или смесь подходов трека тайлов и с участием экстрактора. Например, такая смесь может быть основана на подходе трека тайлов, но при этом базовый трек тайлов может содержать предписание перезаписи операций для клиента, например, базовый трек тайлов может включать в себя перезаписанные заголовки слайсов или групп тайлов.

[0289] В порядке альтернативы кодированию контента на основе MCTS, авторское создание контента для потоковой передачи на основе тайлов, зависящей от окна наблюдения, может быть реализовано посредством авторского создания контента на основе субизображений, описанного далее. Предобработка (до кодирования) содержит разбиение изображений без сжатия на субизображения. Несколько битовых потоков субизображений одной и той же последовательности субизображений без сжатия кодируется, например, с одним и тем же разрешением, но разными характеристиками качества и битовыми скоростями. Кодирование может ограничиваться соединением битового потока кодированных субизображений с согласованным битовым потоком, представляющим всенаправленное видео. Например, зависимостей от отсчетов за пределами границ декодированного изображения можно избежать при кодировании путем выбора векторов движения таким образом, чтобы процесс внешнего предсказания не обращался к положениям отсчетов за пределами изображения. Каждый битовый поток субизображений может инкапсулироваться как трек субизображений, и дополнительно могут формироваться один или более треков экстрактора, соединяющих треки субизображений разных положений субизображения. Если намечен подход на основе трека тайлов, каждый битовый поток субизображений модифицируется, чтобы стать последовательностью MCTS и сохраняется как трек тайлов в файле, и для треков тайлов создаются один или более базовых треков тайла.

[0290] Подходы потоковой передачи на основе тайлов, зависящей от окна наблюдения, можно реализовать путем выполнения одного экземпляра декодера или одного экземпляра декодера для каждой последовательности MCTS (или в ряде случаев, промежуточного варианта, например, по одному экземпляру декодера для MCTS одного и того же разрешения), например, в зависимости от возможности устройства и операционной системы, над которой выполняется приложение воспроизведения. Использование одного экземпляра декодера может инициироваться поздним связыванием или ранним связыванием. Для обеспечения множественных экземпляров декодера, подход с участием экстрактора может использовать треки субизображений, согласованные с форматом или стандартом кодирования без модификаций. Другие подходы могут требоваться либо для перезаписи заголовков сегментов изображения, наборов параметров и/или подобной информации на стороне клиента для построения согласованного битового потока или для обеспечения реализации способности декодера декодировать последовательность MCTS в отсутствие других кодированных видеоданных.

[0291] Может существовать по меньшей мере два подхода для инкапсуляции и обращения к трекам тайлов или трекам субизображений в подходе трека тайлов и подходе с участием экстрактора, соответственно:

- обращение к идентификаторам треков из базового трека тайлов или трека экстрактора;

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

[0292] В способе RWMQ достаточно одного трека экстрактора для каждого размера изображения и каждой сетки тайлов. В видео 360° + окно наблюдения и видео RWMR, один трек экстрактора может потребоваться для каждой отдельной ориентации наблюдения.

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

[0294] В потоковой передаче, адаптивной к окну наблюдения, первичное окно наблюдения (т.е. текущая ориентация наблюдения) передается с хорошим качеством/разрешением, тогда как оставшееся 360-градусное видео передается с более низким качеством/разрешением. Когда ориентация наблюдения изменяется, например, когда пользователь поворачивает голову при наблюдении контента с помощью шлема-дисплея, другая версия контента нуждается в потоковой передаче согласно новой ориентации наблюдения. В общем случае, новая версия может запрашиваться, начиная с точки доступа к потоку (SAP), которая обычно выровнена с (под)сегментами. В битовых потоках одноуровневого видео, SAP соответствуют изображениям произвольного доступа, внутренне кодируются и, следовательно, являются дорогостоящими в отношении характеристика скорость-искажение. Поэтому, традиционно, обычно используются относительно длинные интервалы SAP и, в результате, относительно большие длительности (под)сегментов, порядка секунд. Таким образом, задержка (именуемая здесь задержкой обновления качества окна наблюдения) обновления качества после изменения ориентации наблюдения (например, поворота головы) традиционно составляет порядка секунд и поэтому отчетливо заметна и вызывает раздражение.

[0295] Поскольку в типичной ситуации наблюдения ориентация наблюдения изменяется постепенно, качество изображения изменяется только в поднаборе положений для независимо кодированных областей изображения. Например, когда сетка MCTS 4×2 используется для равнопрямоугольной проекции, вероятно, что качество изображения изменится в половине MCTS. Обновление всех положений MCTS с сегментами, начинающимися с изображения произвольного доступа, не эффективно в отношении характеристики скорость-искажение потоковой передачи и приводит к большой флуктуации битовой скорости, что может становиться причиной прерывания воспроизведения для повторной буферизации или может компенсироваться за счет достаточно длинной начальной задержки буферизации.

[0296] Было предложено, чтобы независимо кодированные области изображения, происходящие из различных типов кодированных изображений (например, изображений IRAP и не-IRAP) в одном и том же кодированном изображении объединенного битового потока, позволяли обрабатывать изменения ориентации наблюдения в зависимой от окна наблюдения 360°-ой потоковой передаче, благодаря чему из изображения IRAP происходит только поднабор независимо кодированных областей изображения. Для поддержки этого, VVC Draft 5 позволяет указывать списки опорных изображений в заголовках слайсов изображений IDR, чтобы клиенты могли изменять тип IDR блока NAL на тип TRAIL блока NAL, когда возможен такой вариант использования.

[0297] Как объяснено выше, переключение окна наблюдения при потоковой передаче, зависящей от окна наблюдения, которая может быть согласована с MPEG OMAF, разрешено в точках доступа потока, которые предусматривают внутреннее кодирование и, таким образом, большую битовую скорость по сравнению с соответствующими внешне кодированными изображениями с тем же качеством. Следовательно, компромисс между интервалом между точками доступа к потоку и характеристикой скорость-искажение выбирается в конфигурации кодирования.

[0298] Далее в качестве примера описана потоковая передача, адаптивная к окну наблюдения битовых потоков HEVC равного разрешения с MCTS. Несколько битовых потоков HEVC одного и того же всенаправленного исходного контента может кодироваться с одним и тем же разрешением, но разными характеристиками качества и битовыми скоростями с использованием наборов тайлов с ограничением движения. Сетка MCTS во всех битовых потоках одинакова. Для обеспечения клиенту возможности использования одного и того же базового трека тайлов для реконструкции битового потока из MCTS, принятых из разных исходных битовых потоков, каждый битовый поток инкапсулируется в свой собственный файл, и один и тот же идентификатор трека используется для каждого трека тайлов одной и той же позиции сетки тайлов во всех этих файлах. Треки тайлов HEVC формируются из каждой последовательности наборов тайлов с ограничением движения, и дополнительно формируется базовый трек тайлов. Клиент может разбирать базовый трек тайлов, чтобы неявно реконструировать битовый поток из треков тайлов. Реконструированный битовый поток можно декодировать с помощью согласованного декодера HEVC.

[0299] Клиенты могут выбирать принимаемую версию каждого MCTS. Одного и того же базового трека тайлов достаточно для комбинирования MCTS из разных битовых потоков, поскольку одни и те же идентификаторы треков используются в соответствующих треках тайлов.

[0300] Фиг. 5 демонстрирует пример, как треки тайлов одного и того же разрешения могут использоваться для потоковой передачи на основе тайлов всенаправленного видео. Сетка тайлов 4×2 использовалась при формировании наборов тайлов с ограничением движения. Два битовых потока HEVC, происходящие из одного и того же исходного контента, кодируются с разными характеристиками качества изображения и битовыми скоростями. Каждый битовый поток может инкапсулироваться в свой собственный файл, причем каждая последовательность наборов тайлов с ограничением движения может быть включена в один трек тайлов, и базовый трек тайлов также включен. Клиент может выбирать качество, с которым принимается каждый трек тайлов, на основании ориентации наблюдения. В этом примере клиент принимает треки тайлов 1, 2, 5 и 6 с конкретным качеством и треки тайлов 3, 4, 7 и 8 с другим качеством. Базовый трек тайлов используется для упорядочения данных принятого трека тайлов в битовый поток, который можно декодировать с помощью декодера HEVC.

[0301] Для соединения независимо кодированных областей изображения из одного или более исходных битовых потоков в объединенный битовый поток требуется перезапись наборов параметров. Другими словами, наборы параметров в исходном(ых) битовом(ых) потоке(ах) как таковые неприменимы. Например, ширина изображения, высота изображения и/или разбиение изображения на тайлы и кирпичи в объединенном битовом потоке могут отличаться от соответствующих параметров любого из исходных битовых потоков. Последствия перезаписи набора параметров может включать в себя следующее:

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

[0303] Кроме того, если размер наборов параметров изменяется в объединенном битовом потоке, они могут влиять на HRD и могут делать неверными параметры буферизации HRD (в SPS и в сообщениях SEI периода буферизации). В результате, если перезапись набора параметров нормативно не задана, влияние соединения на поведение HRD может быть непредсказуемым.

[0304] При соединении независимо кодированных областей из изображений IDR и не-IDR, декодеру необходимо заключать, что такое "смешанное изображение" обрабатывается наподобие изображения не-IDR для маркировки опорного изображения. В одном подходе "указание смешанного изображения" предоставляется в PPS. Однако, когда PPS используется для других изображений, чем те, где происходит смешивание, подход требует создания нового PPS и перезаписи значений ID PPS в заголовке слайса. В другом подходе, внешне управляемая переменная используется в процессе декодирования для указания "смешанного изображения". Однако API декодер для таких внешних переменных может не существовать или может различаться в зависимости от операционного окружения.

[0305] Метаданные, синхронизированные с изображением, могут потребоваться для рендеринга, например, для упакованного по областям 360-градусного видео и/или объемного видео (3DoF+, 6DoF и видео облака точек). Например, метаданные патча и/или упаковка по областям могут изменяться от изображения к изображению. В некоторых операционных системах и/или архитектурах устройств, приложение воспроизведения может быть неспособно передавать метаданные процессу рендеринга синхронно с изображением, а делать это может только видеодекодер. Это можно применять к любому видео (как к шифрованному, так и нешифрованному) или только к шифрованному видео. Однако в общем случае это не было определено, и нет возможности управлять тем, какие метаданные (например, с сообщениями SEI) видеодекодеры должны передавать с декодированными изображениями в качестве выхода, синхронно с изображением. Некоторые из метаданных могут не задаваться первой версией спецификации видеодекодирования, но все же декодер согласно первой версии должен быть способен передавать метаданные совместно с декодированными изображениями в качестве выхода. В настоящее время стандарты видеокодирования указывают вывод только декодированных изображений. Вывод метаданных не был нормативно задан.

[0306] Визуальный контент в конкретные моменты времени может делиться на несколько частей, где каждая часть представлена с использованием субизображения. Соответствующие субизображения в разные моменты времени образуют последовательность субизображений, причем определение "соответствующих" может зависеть от контекста, но может быть, например, одним и тем же пространственным участком области изображения в последовательности изображений или контентом, полученным с одними и теми же настройками, например, одной и той же позицией получения, ориентацией и проекционной поверхностью. Изображение в конкретный момент времени можно определить как коллекцию всех субизображений в конкретный момент времени. Каждое субизображение кодируется с использованием традиционного видеокодера, и реконструированное субизображение сохраняется в памяти реконструированных субизображений, соответствующей последовательностям субизображений. Для предсказания субизображения в конкретной последовательности субизображений, кодер может использовать реконструированные субизображения из одной и той же последовательности субизображений в качестве ссылки для предсказания. Кодированные субизображения включены как отдельные блоки (например, блоки NAL VCL) в один и тот же битовый поток.

[0307] Декодер принимает кодированные видеоданные (например, битовый поток). Субизображение декодируется как отдельный от других субизображений блок с использованием традиционного видеодекодера. Декодированное субизображение может буферизоваться с использованием процесса буферизации декодированных изображений. Процесс буферизации декодированных изображений может подавать декодированное субизображение конкретной последовательности субизображений в декодер, и декодер может использовать декодированное субизображение в качестве ссылки предсказания с целью предсказания субизображения в одной и той же последовательности субизображений.

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

- поворот, например, на 0, 90, 180 или 270 градусов;

- отражение, например, по горизонтали или вертикали;

- передискретизацию (например, перемасштабирование по ширине и/или высоте);

- позиционирование в области управляемого опорного субизображения;

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

[0309] Геометрическое заполнение для 360° видео может содержать, например, заполнение грани куба из соседних граней куба, проецируемых на ту же плоскость, что и грань куба в субизображении.

[0310] В объемном видеокодировании (например, кодировании облака точек) геометрическое изображение и/или текстурное изображение может заполняться элементом заполнения изображения. Целью заполнение является наполнение пустого пространства между патчами для генерации кусочно-гладкого изображения, пригодного для сжатия видео. Элемент заполнения изображения может считать сжатие по-прежнему высоким, а также позволяет оценивать карты занятости (ЕОМ) с достаточной точностью по сравнению с исходной картой занятости (ООМ).

[0311] Согласно одному подходу, может использоваться следующая стратегия заполнения:

[0312] Каждый блок Т×Т (например, 16×16) пикселей обрабатывается независимо. Если блок пуст (т.е. все его пиксели принадлежат пустому пространству), то пиксели блока заполняются путем копирования либо последней строки, либо столбца предыдущего блока Т×Т в порядке сканирования. Если блок полон (т.е. пустые пиксели отсутствуют), ничего не происходит. Если в блоке имеются как пустые, так и заполненные пиксели, то пустые пиксели итерационно заполняются средним значением их непустых соседей.

[0313] Сгенерированные изображения/уровни могут сохраняться как кадры видео и сжиматься. Например, изображение заполненной геометрии и изображение заполненной текстуры поступают в элемент сжатия видео для сжатия изображения заполненной геометрии и изображения заполненной текстуры, откуда сжатые геометрические и текстурные изображения поступают, например, на мультиплексор, который мультиплексирует входные данные в сжатый(е) битовый(е) поток(и).

[0314] Сжатые геометрические и текстурные изображения также поступают, например, на оцениватель карты занятости, который генерирует оценочную карту занятости.

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

[0316] Карта занятости может состоять из двоичной карты, которая указывает для каждой ячейки сетки, принадлежит ли она пустому пространству или облаку точек. Одна ячейка 2D сетки будет создавать пиксель в процессе генерации изображения.

[0317] На оценочном этапе генерации заполнения, на основании варианта осуществления, используемого на этапе заполнения, можно рассматривать разные процессы между соответствующими компонентами Y, U и/или V заполненной геометрии. На основании таких процессов будет вырабатываться оценка краев (т.е. контуры, задающие карту занятости). Такая оценка может тонко настраиваться в случаях, когда более чем один компонент/изображение подлежат использованию для оценивания карты занятости.

[0318] Пример алгоритма обнаружения краев является многомасштабным алгоритмом обнаружения краев, который базируется на модели скрытого дерева Маркова векторов импульсной области. Однако и какой-либо другой алгоритм может применяться в этом контексте.

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

[0320] При повторной проекции опорный патч опорного(ых) субизображения(й) может интерпретироваться как патчи 3D облака точек, и патчи 3D облака точек могут повторно проецироваться на плоскость, пригодную для внешнего 2D предсказания.

[0321] Для стандарта MPEG была разработана пробная модель сжатия облака точек. В MPEG W17248 раскрыта пробная модель для кодирования облака точек MPEG для обеспечения стандартизованного способа динамического сжатия облака точек. В пробной модели MPEG W17248, 2D поверхности проекции 3D объема определяются в отношении данных трех изображений: изображений движения, изображений текстуры и изображений глубины/атрибута.

[0322] В блоке передискретизации облака точек, входной 3D кадр облака точек передискретизируется на основе опорного кадра облака точек. Блок 3D компенсации движения используется в процессах межкадрового кодирования/декодирования. Он вычисляет разность между позициями опорного облака точек и его деформированной версии. Полученные поля движения состоят из 3D векторов движения {MV_i(dx, dy, dz)}_i, связанных с точкой опорного кадра. Отображение опорного кадра из 3D в 2D используется для преобразования поля движения в 2D изображение путем сохранения dx как Y, dy как U и dz как V, где это 2D изображение может именоваться изображением движения. Масштабная карта, обеспечивающая масштабный коэффициент для каждого блока изображения движения, также кодируется.

[0323] В процессе генерации изображения применяется отображение 3D в 2D, вычисленное в ходе процесса упаковки для сохранения геометрии/текстуры/движения облака точек в качестве изображений. Эти изображения сохраняются как кадры видео и сжимаются видеокодером, например, кодером HEVC. Сгенерированные видеозаписи могут иметь следующие характеристики:

[0324] геометрия: WxH YUV420-86HT,

[0325] текстура: WxH YUV420-86HT,

[0326] движение: WxH YUV444-106HT.

[0327] Синтез ракурсов (также известный как рендеринг на основе изображения глубины) может осуществляться из субизображений, представляющих один или более видов текстуры и глубины.

[0328] Рендеринг на основе изображения глубины (DIBR) или синтез ракурсов относится к генерации нового ракурса на основании одного или более существующих/принятых ракурсов. Изображения глубины могут использоваться для помощи в правильном синтезе виртуальных ракурсов. Даже отличаясь в деталях, большинство алгоритмов синтеза ракурсов используют 3D искривление на основании явной геометрии, т.е. изображений глубины, где обычно каждый пиксель текстуры связан с пикселем глубины, указывающим расстояние или значение z от камеры до физического объекта, из которого отбирается пиксель текстуры. Один известный подход использует неевклидову формулировку 3D искривления, что эффективно в условиях, когда параметры камеры не известны или калибровка камеры ограничена. Однако еще один известный подход строго следует евклидовой формулировке, предполагая параметры камеры для получения и интерполяции ракурса известными. В еще одном подходе, целью синтеза ракурсов является не оценка ракурса, как если бы камера использовалась для его съемки, а обеспечивается субъективно приятное представление контента, которое может включать в себя нелинейную регулировку расхождения для разных объектов.

[0329] Преграды, проколы и ошибки реконструкции являются наиболее общими артефактами, вносимыми в процессе 3D искривления. Эти артефакты чаще возникают на краях объекта, где пиксели с разными уровнями глубины могут отображаться в одно и то же положение пикселя виртуального изображения. Когда эти пиксели усредняются для реконструкции окончательного значения пикселя для положения пикселя в виртуальном изображении, может генерироваться артефакт, поскольку пиксели с разными уровнями глубины обычно принадлежат разным объектам.

[0330] Несколько подходов было предложено для представления последовательностей изображения глубины, включающих в себя использование вспомогательных видеопотоков карты глубины. Видеопоток карты глубины для единого ракурса можно рассматривать как правильный монохроматический видеопоток и кодировать любым видеокодеком. Некоторые характеристики потока карты глубины, например, минимальная и максимальная глубина в мировых координатах, может указываться в сообщениях, форматированных, например, согласно стандарту MPEG-C, часть 3.

[0331] Частности работы алгоритмов синтеза ракурсов зависят от того, какой формат представления использовался для текстурных ракурсов и последовательностей изображения глубины.

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

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

- кодирования многоракурсного видео смешанного разрешения или изображения, где последовательность субизображений соответствует ракурсу. Межракурсное предсказание может осуществляться посредством предсказания из первого субизображения (первой последовательности субизображений) во второе субизображение (второй последовательности субизображений), где первое и второе субизображения могут относиться к одному и тому же моменту времени. В ряде случаев может быть полезно поворачивать один из ракурсов (например, для размещения субизображений рядом по горизонтали или сверху вниз при составлении выходного изображения). Следовательно, передискретизация может сопровождаться поворотом (например, на 90, 180 или 270 градусов).

[0333] Преобразование цветовой гаммы: например, если одно субизображение, используемое в качестве источника, представлено первой цветовой гаммой или первым форматом, например ITU-R ВТ. 709, и управляемое опорное субизображение представлено второй цветовой гаммой или вторым форматом, например ITU-RBT.2020, субизображение, используемое в качестве источника, может преобразовываться ко второй цветовой гамме или второму формату как часть процесса.

[0334] Преобразование динамического диапазона и/или преобразование отображения цвета: отображение цвета может означать отображение значений отсчетов в линейное представление света. Реконструированное(ые) субизображение(я), используемое(ые) в качестве источника для генерации управляемого опорного субизображения, можно преобразовывать к целевому динамическому диапазону и отображению цвета.

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

[0336] Преобразование формата цветности: например, управляемое опорное субизображение может иметь формат YUV 4:4:4 цветности, тогда как по меньшей мере некоторые реконструированные субизображения, используемые в качестве источника для генерации управляемого опорного субизображения, могут иметь формат цветности 4:2:0. В этом примере субизображения, используемые в качестве источника, можно дискретизировать с повышением до YUV 4:4:4 как часть процесса.

[0337] Преобразование проекции: например, если одно субизображение находится в первой проекции, например ERP, и управляемое субизображение находится во второй проекции, например СМР, субизображение, используемое в качестве опорного, может преобразовываться ко второй проекции. В качестве варианта использования весь 360-градусный контент может кодироваться с более низким разрешением в формате ERP, а контент окна наблюдения может кодироваться с более высоким разрешением в формате СМР.

[0338] Преобразование частоты кадров: например, если одно субизображение кодируется с первой частотой кадров, и второе субизображение может кодироваться со второй частотой кадров, субизображение, используемое в качестве ссылки, может интерполироваться по времени до момента времени второго субизображения. В качестве варианта использования, в стереоскопической потоковой передаче преобладающий ракурс может передаваться с более высокой частотой кадров, и вспомогательный ракурс может передаваться с более низкой частотой кадров.

[0339] Можно дать следующие определения, касающиеся стандарта высокопроизводительного видеокодирования, но также они могут применяться для других кодеков. Независимый уровень - это уровень, который не имеет уровней прямой ссылки, т.е. не может быть получен межуровневым предсказанием. Небазовый уровень - это уровень, в котором все блоки NAL VCL имеют одно и то же значение nuh_layer_id, большее 0. Независимый небазовый уровень является независимым уровнем и одновременно небазовым уровнем.

[0340] Далее будет кратко объяснен пример процесса извлечения битового подпотока. Битовый поток outBitstream может генерироваться из независимого небазового уровня битового потока inBitstream следующим образом. Битовый поток outBitstream задается идентичным битовому потоку inBitstream. Блоки NAL с nal_unit_type, не равным SPS_NUT, PPS_NUT и EOB_NUT, и с nuh_layer_id, не равным assignedBaseLayerId удаляются из outBitstream. Блоки NAL с nal_unit_type, равным SPS_NUT, или PPS_NUT с nuh_layer_id, не равным 0, или assignedBaseLayerId удаляются из outBitstream. Блоки NAL с nal_unit_type, равным VPS_NUT, удаляются из outBitstream. Все блоки NAL с TemporalId, большим tIdTarget, удаляются из outBitstream. nuh_layer_id устанавливается равным 0 в каждом блоке NAL outBitstream. Битовый поток outBitstream можно декодировать в процессе декодирования HEVC.

[0341] Далее будет кратко объяснен пример набора параметров видео (VPS) HEVC для указания свойств уровня. Набор параметров видео содержит часть расширения, часть которой представлена ниже:

[0342] Набор параметров видео HEVC указывает маску масштабируемости, которая указывает тип(ы) масштабируемости, которые используются для уровня:

[0343] scalability_mask_flag[i], равный 1, указывает наличие синтаксических элементов dimension_id, соответствующих i-му измерению масштабируемости в таблице F.1. scalability_mask_flag[i], равный 0, указывает отсутствие синтаксических элементов dimension_id, соответствующих i-му измерению масштабируемости.

[0345] layer_id_in_nuh[i] указывает значение синтаксического элемента nuh_layer_id в блоках NAL VCL i-го уровня. Когда i больше 0, layer_id_in_nuh[i] должен быть больше layer_id_in_nuh[i-1]. Для любого значения i в диапазоне от 0 до MaxLayersminus1 включительно, когда отсутствует, значение layer_id_in_nuh[i] предполагается равным i.

[0346] Для i от 0 до MaxLayersminus1 включительно, переменная LayerIdxInVps[layer_id_in_nuh[i]] устанавливается равной i.

[0347] dimension id[i][j] указывает идентификатор j-го присутствующего типа измерения масштабируемости i-го уровня. Количество битов, используемых для представления dimension_id[i][j], равно dimension_id_len_minus1[j]+1 битов.

[0348] В зависимости от splitting_flag, применяется следующее. Если splitting_flag равен 1, для i от 0 до MaxLayersMinus1 включительно, и j от 0 до NumScalability Types - 1, включительно, dimension_id[i][j] предполагается равным ((layer_id_in_nuh[i] & ((1 << dimBitOffset[j+1])-1)) >> dimBitOffset[j]). Если splitting_flag не равен 1, (splitting_flag равен 0), для j от 0 до NumScalabilityTypes - 1, включительно, dimension_id[0][j] предполагается равным 0.

[0349] Переменная ScalabilityId[i][smIdx], указывающая идентификатор smIdx-го типа измерения масштабируемости i-го уровня, и переменные DepthLayerFlag[lId], ViewOrderIdx[lId], DependencyId[lId] и AuxId[lId], указывающие флаг глубины, индекс порядка ракурса, идентификатор масштабируемости пространства/качества и вспомогательный идентификатор, соответственно, уровня с nuh_layer_id, равным lId, можно вывести следующим образом:

[0350] Набор выходных уровней (OLS, output layer set) можно определить как набор уровней, для которых один или более уровней указаны как выходные уровни. Выходной уровень (набора выходных уровней) может задаваться как уровень, который выводится при декодировании этого набора выходных уровней. Изображение выходного уровня выводится декодером, когда флаг вывода, указанный или предполагаемый для него, равен 1. В противном случае, изображение может не выводиться декодером. Наборы выходных уровней могут задаваться в VPS.

[0351] Процесс извлечения битового подпотока можно определить как заданный процесс, в котором блоки NAL в битовом потоке, которые не принадлежат целевому набору, например, определенному целевым индексом OLS и целевым самым высоким TemporalId, удаляются из битового потока, причем выходной битовый подпоток состоит из блоков NAL в битовом потоке, которые принадлежат целевому набору.

[0352] Визуальный контент в конкретные моменты времени делится на несколько частей, где каждая часть представлена с использованием субизображения. Соответствующие субизображения в разные моменты времени образуют последовательность субизображений, причем определение "соответствующие" может зависеть от контекста, но могут быть, например, одним и тем же пространственным участком области изображения в последовательности изображений или контентом, полученным с одними и теми же настройками, например, одной и той же позицией получения, ориентацией и проекционной поверхностью. Изображение в конкретный момент времени можно определить как коллекцию всех субизображений в конкретный момент времени. Каждое субизображение кодируется с использованием традиционного видеокодера, и реконструированное субизображение сохраняется в памяти реконструированных субизображений, соответствующей последовательностям субизображений. Для предсказания субизображения в конкретной последовательности субизображений, кодер может использовать реконструированные субизображения из одной и той же последовательности субизображений в качестве ссылки для предсказания. Кодированные субизображения включены как отдельные блоки (например, блоки NAL VCL) в один и тот же битовый поток.

[0353] Декодер принимает кодированные видеоданные (например, битовый поток). Субизображение декодируется как отдельный от других субизображений блок с использованием традиционного видеодекодера. Декодированное субизображение может буферизоваться с использованием процесса буферизации декодированных изображений. Процесс буферизации декодированных изображений может подавать декодированное субизображение конкретной последовательности субизображений в декодер, и декодер может использовать декодированное субизображение в качестве ссылки для предсказания с целью предсказания субизображения в одной и той же последовательности субизображений.

[0354] Фиг. 6 демонстрирует пример декодера. Декодер принимает кодированные видеоданные (например, битовый поток). Субизображение декодируется в процессе 610 декодирования как отдельный от других субизображений блок с использованием традиционного видеодекодера. Декодированное субизображение может буферизоваться с использованием процесса 620 буферизации декодированных изображений. Процесс буферизации декодированных изображений может обеспечивать декодированное субизображение конкретной последовательности субизображений процессу 610 декодирования, и декодер может использовать декодированное субизображение в качестве ссылки для предсказания с целью предсказания субизображения в той же последовательности субизображений.

[0355] Процесс 620 буферизации декодированных изображений может содержать буферизацию 630 по последовательностям субизображений, которая может содержать маркировку реконструированных субизображений как "используемых в качестве ссылки" и "не используемых в качестве ссылки", а также отслеживание, выведены ли реконструированные субизображения из декодера. Последовательности субизображений могут буферизоваться независимо друг от друга или могут синхронизироваться одним или обоими из следующих способов:

- вывод всех реконструированных субизображений для одного и того же момента времени может осуществляться синхронно;

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

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

[0357] Согласно примеру, выход декодера содержит коллекцию разных и отдельных декодированных субизображений.

[0358] Согласно другому примеру, показанному на фиг. 7, выходное изображение, которое может дополнительно или альтернативно именоваться декодированным изображением, из процесса 810 декодирования является коллекцией разных и отдельных субизображений. Согласно другому примеру, выходное изображение составляется путем размещения реконструированных субизображений в двухмерном (2D) изображении. Этот пример поддерживает традиционную конструкцию единого выходного изображения (в каждый момент времени) в качестве выхода видеодекодера и, таким образом, оно может быть прямо интегрировано в системы. Декодированные субизображения подвергаются буферизации декодированных субизображений 812. Затем процесс 810 декодирования может использовать буфер изованное(ые) субизображение(я) в качестве ссылки для декодирования последующих изображений. Процесс декодирования может получать указание или предполагать, какое из декодированных субизображений подлежит использованию в качестве источника для генерации управляемого(ых) субизображения(й). Эти субизображения предоставляются 814 процессу управления опорными субизображениями 816. Затем управляемые опорные субизображения предоставляются для буферизации 818 декодированных субизображений 812, где управляемые опорные субизображения буферизуются. Затем субизображения и управляемые опорные субизображения могут использоваться процессом 820 составления выходного изображения, который берет данные композиции изображения в качестве ввода и размещает реконструированные субизображения в выходных изображениях. Кодер кодирует данные композиции изображения в битовый поток или наряду с ним, где данные композиции изображения указывают, как надо размещать реконструированные субизображения в 2D изображениях, формирующих выходное(ые) изображение(я). Декодер декодирует данные композиции изображения из битового потока или наряду с ним и формирует 820 выходное изображение из реконструированных субизображений и/или управляемых опорных субизображений согласно декодированным данным композиции изображения. Декодирование данных композиции изображения может происходить как часть процесса 820 составления выходного изображения или в функциональном соединении с ним. Таким образом, традиционный процесс видеодекодирования декодирует данные композиции изображения.

[0359] Согласно примеру, данные композиции изображения кодируются в битовом потоке или наряду с ним и/или декодируются из битового потока или наряду с ним с использованием битового потока или порядка декодирования субизображений и размеров субизображений. Алгоритм для позиционирования субизображений в области изображения осуществляется в кодере и/или в декодере, при этом субизображения вводятся в алгоритм в своем порядке битового потока или декодирования. Согласно примеру, алгоритм для позиционирования субизображений в области изображения состоит в следующем: когда изображение содержит множественные субизображения, и когда начинается кодирование изображения и/или декодирование кодированного изображения, каждое положение CTU в реконструированном или декодированном изображении маркируется как не занятое. Для каждого субизображения в битовом потоке или порядке декодирования, субизображение берет следующее такое не занятое положение в порядке растрового сканирования CTU в изображении, достаточно большом, чтобы субизображение умещалось в границах изображения.

[0360] Согласно примеру, кодер указывает, в битовом потоке или наряду с ним,

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

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

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

[0361] Согласно примеру, декодер декодирует, из битового потока или наряду с ним, если

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

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

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

[0362] Декодер адаптирует свою работу в соответствии с намерением или разрешением декодирования.

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

[0364] Согласно примеру, изображения делятся на субизображения, группы тайлов и тайлы. Тайл может задаваться аналогично тайлу HEVC, таким образом, тайл можно определить как последовательность CTU, покрывающих прямоугольную область изображения. Как рассмотрено выше, несколько типов групп тайлов, например, группы тайлов порядка растрового сканирования и прямоугольные группы тайлов, могут быть доступны в формате кодирования, и кодер может выбирать используемый тип. Группу тайлов порядка растрового сканирования можно определить как последовательность тайлов в растровом сканировании тайлов в субизображении. Прямоугольную группу тайлов можно определить как прямоугольную группу тайлов в субизображении. Можно задать, что блок NAL VCL содержит строго одну группу тайлов, т.е. группа тайлов содержится в строго одном блоке NAL VCL. Субизображение можно определить как прямоугольный набор из одной или более из всех групп тайлов. Согласно примеру, изображение разбивается на субизображения, т.е. все изображение занято субизображениями, и в изображении не существует незанятых областей. Согласно другому примеру, изображение содержит субизображения и одну или более незанятых областей.

[0365] Согласно примеру, кодер кодирует в битовом потоке или наряду с ним и/или декодер декодирует из битового потока или наряду с ним информацию, указывающую один или более тайл разбиения для субизображений. Разбиение тайлов может, например, быть сеткой тайлов, заданной значениями ширины и высоты столбцов тайлов и строк тайлов, соответственно. Кодер кодирует в битовом потоке или наряду с ним, и/или декодер декодирует из битового потока или наряду с ним разбиение тайлов, которое применяется для конкретного субизображения или последовательности субизображений. Согласно примеру, синтаксические элементы, описывающие разбиение тайлов, кодируются в, и/или декодируются из, набора параметров изображения, и PPS активируется для субизображения, например, посредством идентификатора PPS в заголовке группы тайлов. Каждое субизображение может означать свой собственный PPS и, следовательно, может иметь свое собственное разбиение тайлов. Например, фиг. 10 иллюстрирует изображение, которое делится на 4 субизображения. Каждое субизображение может иметь свою собственную сетку тайлов. В этом примере субизображение 1 делится на сетку 3×2 тайлов равной ширины и равной высоты, субизображение 2 делится на 2×1 тайла высотой 3 и 5 CTU. Каждое из субизображений 3 и 4 имеет только один тайл. Субизображение 1 имеет 3 группы тайлов, содержащие 1, 3 и 2 тайла, соответственно. Каждое из субизображений 2, 3 и 4 имеет одну группу тайлов.

[0366] Фиг. 10 также иллюстрирует рассмотренный выше алгоритм для позиционирования субизображений в области изображения. Субизображение 1 является первым в порядке декодирования и, таким образом, располагается в верхнем левом углу области изображения. Субизображение 2 является вторым в порядке декодирования и, таким образом, располагается в следующем незанятом положении в порядке растрового сканирования. Алгоритм действует таким же образом для третьего и четвертого субизображений в порядке декодирования, т.е. субизображений 3 и 4, соответственно. Порядок декодирования субизображений указывается номерами (1, 2, 3, 4) за пределами границ изображения.

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

[0368] Согласно примеру, буферизация декодированных изображений осуществляется на основе изображений, а не на основе субизображений. Кодер и/или декодер генерирует опорное изображение из декодированных субизображений одного и того же блока доступа или момента времени с использованием данных композиции изображения. Генерация опорного изображения осуществляется одинаково или аналогично описанному в других примерах для генерации выходных изображений. При обращении к опорному изображению при кодировании и/или декодировании субизображения, опорные субизображения для кодирования и/или декодирования субизображения генерируются путем извлечения области, совмещенной с текущим субизображением, из опорных изображений в буфере декодированных изображений. Таким образом, процесс декодирования получает опорное(ые) субизображение(я) из процесса буферизации декодированных изображений аналогично другим примерам, и процесс декодирования может осуществляться аналогично другим примерам.

[0369] Согласно примеру, кодер выбирает опорные изображения для предсказания текущего субизображения таким образом, что опорные изображения содержат субизображение, которое имеет такое же положение, что и текущее субизображение (в изображении) и такие же размеры (ширину и высоту), что и текущее субизображение. Кодер избегает выбора опорных изображений для предсказания текущего субизображения, если опорные изображения не содержат субизображение, которое имеет такое же положение, что и текущее субизображение (в изображении) или такие же размеры, что и текущее субизображение. Согласно примеру, субизображениям одного и того же блока доступа или момента времени разрешено относиться к различным типам, например, быть субизображениями произвольного доступа и субизображениями без произвольного доступа, определенными аналогично описанным ранее в отношении типов блока NAL и/или типов изображения. Кодер кодирует первый блок доступа субизображением произвольного доступа в первом положении и размере и субизображением без произвольного доступа во втором положении и размере, и последующий блок доступа в порядке декодирования, включающий в себя субизображение в первом положении и размере, ограниченном таким образом, чтобы избегать опорных изображений, предшествующих первому блоку доступа в порядке декодирования, и включающий в себя другое субизображение во втором положении и размере с использованием опорного изображения, предшествующего первому блоку доступа в порядке декодирования в качестве ссылки для предсказания.

[0370] Согласно примеру, для кодирования и/или декодирования текущего субизображения, кодер и/или декодер включает в начальный список опорных изображений только такие опорные изображения, которые содержат субизображение, которое имеет такое же положение, что и текущее субизображение (в изображении) и такие же размеры (ширину и высоту), что и текущее субизображение. Опорные изображения, которые не содержат субизображение, которое имеет такое же положение, что и текущее субизображение (в изображении) или такие же размеры (ширину и высоту), что и текущее субизображение, пропускаются или исключаются для генерации начального списка опорных изображений для кодирования и/или декодирования текущего субизображения. Согласно примеру, субизображениям одного и того же блока доступа или момента времени разрешено относиться к различным типам, например, быть субизображениями произвольного доступа и субизображениями без произвольного доступа, определенными аналогично описанным ранее в отношении типов блока NAL и/или типов изображения. Процесс или алгоритм инициализации списка опорных изображений в кодере и/или декодере включает в себя только предыдущее субизображение произвольного доступа и последующие субизображения, в порядке декодирования, в начальном списке опорных изображений и пропускает или исключает субизображения, предшествующие, в порядке декодирования, предыдущему субизображению произвольного доступа.

[0371] Согласно примеру, субизображение во второй последовательности субизображений предсказывается из одного или более субизображений первой последовательности субизображений. Пространственное соотношение субизображения с одним или более субизображениями первой последовательности субизображений либо предполагается, либо указывается кодером в битовом потоке или наряду с ним и/или декодируется декодером из битового потока или наряду с ним. В отсутствие такой информации пространственного соотношения в битовом потоке или наряду с ним, кодер и/или декодер может предположить, что субизображения располагаются соответственно, т.е. в точности перекрываясь для пространственного соответствия в предсказании. Информация пространственного соотношения не зависит от данных композиции изображения. Например, субизображения могут располагаться друг над другом в выходном изображении (в конфигурации упаковки сверху вниз), пока они рассматриваются как соответственно расположенные для предсказания.

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

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

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

- Идентификатор последовательности субизображений, включенный в синтаксическую структуру разделителя субизображений, заголовка изображения и т.п., на которую неявно ссылаются кодированные видеоданные. Разделителем субизображений может быть, например, конкретный блок NAL, с которого начинается новое субизображение. Неявная ссылка может, например, означать, что можно ссылаться на предыдущую в порядке декодирования или битового потока синтаксическую структуру (например, разделитель субизображений или заголовок изображения).

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

[0373] Согласно примеру, значения идентификатора последовательности субизображений верны в заранее заданном поднаборе битового потока (который может именоваться "периодом действительности" или "поднабором действительности"), который может представлять собой, но без ограничения, одно из следующих:

- Единый блок доступа, т.е. кодированные видеоданные для единого момента времени.

- Кодированную видеопоследовательность.

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

- Весь битовый поток.

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

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

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

[0377] Согласно примеру, идентификатором последовательности субизображений является кодовое слово переменной длины, например, экспоненциальный код Голомба и т.п.

[0378] Согласно примеру, кодер указывает отображение блоков NAL VCL или сегментов изображения, в порядке декодирования, в субизображения или последовательности субизображений в битовом потоке или наряду с ним, например, в наборе параметров видео, наборе параметров последовательности или наборе параметров изображения. Аналогично, согласно примеру, декодер декодирует отображение блоков NAL VCL или сегментов изображения, в порядке декодирования, в субизображения или последовательность субизображений из битового потока или наряду с ним. Отображение может касаться единого момента времени или блока доступа за раз.

[0379] Согласно примеру, несколько отображений обеспечиваются, например, в единой синтаксической структуре контейнера, и каждое отображение индексируется или явно идентифицируется, например, значением идентификатора.

[0380] Согласно примеру, кодер указывает в битовом потоке, например, в заголовке блока доступа или разделителе, наборе параметров изображения, наборе параметров заголовка, заголовке изображения, заголовке сегмента изображения (например, группы тайлов или слайса), какое отображение применяется к конкретному блоку доступа или моменту времени. Аналогично, согласно примеру, декодер декодирует из битового потока, какое отображение применяется к конкретному блоку доступа или моменту времени. Согласно примеру, указание, какое отображение применяется, является индексом списка из нескольких отображений (заданных, например, в наборе параметров последовательности) или идентификатором набора из нескольких отображений (заданных, например, в наборе параметров последовательности). В другом примере, указание, какое отображение применяется, содержит само отображение, например, в виде списка идентификаторов последовательностей субизображений для блоков NAL VCL в порядке декодирования, включенных в блок доступа, связанный с отображением.

[0381] Согласно примеру, декодер делает заключение о субизображении или последовательности субизображений для блока NAL VCL или сегмента изображения следующим образом:

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

- Отображение, применяемое к блоку доступа или моменту времени, определяется согласно любому вышеприведенному примеру.

- Для каждого блока NAL VCL или сегмента изображения в порядке декодирования, соответствующая последовательность субизображений или субизображение определяется из отображения.

[0382] Ниже приведен пример со следующими проектными решениями:

- Отображения указаны в наборе параметров последовательности.

- Отображения указаны для отображения блоков NAL VCL в последовательности субизображений.

- Указание, какое отображение применяется для конкретного блока доступа или момента времени, происходит в заголовке группы тайлов.

[0383] Следует понимать, что другие примеры можно аналогично реализовать с другими проектными решениями, например, синтаксическими структурами контейнера, отображением для сегментов изображения вместо блоков NAL VCL, и отображением для субизображений вместо последовательностей субизображений.

[0384] В соответствии с примером, субизображение может быть полным изображением нормального одноракурсного 2D видео, в котором каждое изображение имеет только одно субизображение, каждой частью видео (которая может быть известна как тайл), каждым ракурсом (асимметричного) многоракурсного или стереоскопического видео, каждым уровнем многоуровневого (масштабируемого) видео, каждой гранью многогранной 360-градусной проекции (например, кубической текстуры), каждой частью упаковки видео множественного разрешения (например, ERP или СМР множественного разрешения), или каждой частью облака точек, проецируемого на поверхность (текстуры или глубины).

[0385] Значения идентификатора могут оказываться несогласованными при соединении последовательностей субизображений. Это может происходить потому, что для кодирования разных частей контента могут использоваться разные кодеры. Например, для кодирования текстурных и геометрических битовых потоков контента РСС, или наложенного и фонового видео могут использоваться разные кодеры. Кодеры могут не обеспечивать достаточные интерфейсы конфигурации для управления использованием идентификаторов последовательностей субизображений или использованием битовых потоков, поскольку последовательность(и) субизображений могут быть даже неизвестны во время кодирования. Таким образом, битовые потоки, подлежащие использованию в качестве последовательностей субизображений, могут использовать одни и те же идентификаторы последовательностей субизображений, или кодирование идентификаторов последовательностей субизображений может быть полностью запрещено. Также может быть возможно, что битовые потоки, подлежащие использованию в качестве последовательностей субизображений, могут использовать одни и те же идентификаторы набора параметров для обращения к наборам параметров разного контента.

[0386] Последовательности субизображений могут потребоваться для использования разных параметров уровня последовательностей. Например, битовый поток текстуры может использовать формат цветности 4:2:0, тогда как соответствующий битовый поток глубины может использовать формат цветности 4:0:0. Используемый формат цветности кодируется в наборе параметров последовательности. Только один набор параметров последовательности активируется для каждой кодированной видеопоследовательности в Н.264/AVC и для каждой кодированной по уровням видеопоследовательности (CLVS, coded layer-wise video sequence) в HEVC. CLVS можно определить как последовательность кодированных изображений с одним и тем же значением идентификатора уровня (т.е. одним и тем же значением nuh_layer_id в HEVC), который состоит, в порядке декодирования, из изображения произвольного доступа конкретного(ых) типа(ов) (в HEVC, изображения IRAP с NoRaslOutputFlag, равным 1), сопровождаемого всеми кодированными изображениями, при наличии, вплоть до, но не включая, следующее изображение произвольного доступа конкретного(ых) типа(ов) (в HEVC, следующего изображения IRAP с NoRaslOutputFlag, равным 1).

[0387] Расхождений значений идентификатора можно избежать, перезаписывая значения идентификатора при соединении последовательностей субизображений. Однако такая перезапись может быть особенно уязвимой, когда идентификатор кодируется кодовыми словами переменной длины, например экспоненциальным голомбовым кодом ue(v), идентификатор появляется в битовом положении, на которое могут влиять байты предотвращения эмуляции начального кода, причем идентификатору предшествуют синтаксические элементы, кодированные с переменной длиной серии, причем сам идентификатор может предписывать вывод байта предотвращения эмуляции начального кода (например, значения 0), и/или контент шифруется, и идентификатор является частью шифрованной части контента.

[0388] Может потребоваться, чтобы диапазон значений и битовая скорость для идентификаторов уровней и/или идентификаторов последовательностей субизображений были сравнительно велики. Ниже кратко перечислены некоторые примеры различных вариантов использования, которые могут использовать слияние подпоследовательностей:

- Может потребоваться, чтобы количество субизображений для потоковой передачи, зависящей от окна наблюдения, 360-градусного видео 3DoF было сравнительно велико. Например, для достижения зависимой от окна наблюдения доставки 360-градусного видео 3DoF может быть выгодно использовать 96 субизображений.

- Большое количество субизображений также может быть полезно в объемном видеокодировании, например, кодировании облака точек на основе видео или видеокодировании 3DoF+. В объемном видеокодировании 3D контент может проецироваться на 2D патчи, которые могут располагаться на субизображениях, например, на основании аналогичного конуса наблюдения. Кроме того, в объемном видеокодировании могут кодироваться несколько типов видео, например, текстура, геометрия, занятость, и атрибуты различных типов.

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

- Кодирование супер-многоракурсного или оконного 6DoF видео, где контент захватывается десятками камер.

- Один или более 2D, 360-градусных или объемных видеоклипов с наложением 360-градусного фона, который может кодироваться с использованием субизображений, для доставки, зависимой от окна наблюдения.

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

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

[0391] В H.264/AVC и HEVC, идентификаторы уровней и т.п. кодируются в заголовке блока NAL. Сравнительно большой диапазон значений идентификаторов уровней и/или идентификаторов последовательностей субизображений требует относительно высокой битовой скорости. В Н.264/AVC и HEVC использовались кодовые слова фиксированной длины. Для поддержки большого разнообразия вариантов использования, например, от 8 до 12 битов может быть зарезервировано для идентификаторов последовательностей субизображений, и, например, от 4 до 6 битов для идентификаторов уровней. Возможно объединить оба варианта в единое значение идентификатора, например, длиной от 10 до 16 битов. Однако, будучи включено в заголовок блока NAL, значение идентификатора может требовать 2 байтов на блок NAL дополнительного хранения по сравнению с системой кодирования без поддержки субизображений и уровней. Например, для 96 субизображений на частоте 60 Гц это будет соответствовать более чем 90 кбит/с.

[0392] HEVC использует 6-битовое значение nuh_layer_id, и уровни могут быть независимыми небазовыми уровнями. Хотя это конкретно не упомянуто в стандарте HEVC, по-видимому будет разрешено помечать все идентификаторы измерений масштабируемости равными 0 для любых уровней, т.е. указывать, что уровни являются кодированной текстурой того же вида, не являются вспомогательными уровнями и не являются уровнями качества или пространственного улучшения. Это можно использовать для указания того, что уровни используются для последовательностей субизображений. Однако, поскольку используется только 6-битовый nuh_layer_id, последовательности субизображений не могут однозначно отображаться в значения nuh_layer_id во многих вариантах использования (например, 96 субизображений для 360-градусной потоковой передачи, зависящей от окна наблюдения). Так или иначе, количество одновременно декодированных последовательностей субизображений, вероятно, меньше, чем позволяет 6-битовое значение nuh_layer_id.

[0393] В порядке примера, разделителем является блок NAL разделителя, который может, например, именоваться блоком NAL разделителя последовательностей субизображений или блоком NAL управления декодированием. Следует понимать, что варианты осуществления применяются независимо от именования разделителя. Блок NAL разделителя последовательностей субизображений может быть конкретным, но не обязан ограничиваться переносом указаний или предписаний, связанных с субизображением, тогда как более общее наименование, например, блок NAL разделителя или блок NAL управления декодированием, может использоваться для любых целей, также включающих в себя указания или предписания, связанные с субизображением. Разделитель может быть блоком NAL, когда основной единицей в синтаксисе битового потока является блок NAL. Варианты осуществления не ограничиваются блоком NAL в качестве разделителя, но могут предусматривать любую синтаксическую структуру в битовом потоке видео, например, заголовок блока доступа и т.п. или его часть. Термины разделитель, блок NAL разделителя, разделитель последовательностей субизображений и блок NAL управления декодированием используются взаимозаменяемо.

[0394] Блок NAL разделителя блоков доступа является примером блока NAL разделителя. Предварительная версия стандарта VVC задает RBSP разделителя блоков доступа (AUD, access unit delimiter), которая содержится в блоке NAL разделителя блоков доступа (AUD), с помощью следующего синтаксиса:

[0395] В предварительной версии стандарта VVC, разделитель AU (AUD) используется для указания начала блока доступа (AU), независимо от того, является ли AU IRAP или AU постепенного обновления декодирования (GDR, gradual decoding refresh), и типа слайсов, присутствующих в кодированных изображениях в AU, содержащем блок NAL разделителя AU. Флаг aud_irap_or_gdr_au_flag, равный 1, указывает, что AU, содержащий разделитель AU, является AU IRAP или GDR. Флаг aud_irap_or_gdr_au_flag, равный 0, указывает, что AU, содержащий разделитель AU, не является ни AU IRAP, ни AU GDR. Может потребоваться, чтобы кодированная видеопоследовательность начиналась с AU IRAP или GDR. AU IRAP можно определить как AU, где присутствуют все уровни и содержится изображение IRAP. AU GDR можно определить как AU, где присутствуют все уровни и содержится изображение GDR. aud_pic_type указывает разрешенный типы слайса из I (внутренне кодированных), Р (внешне кодированных с одинарным предсказанием), и В (внешне кодированный с двойным предсказанием) слайсов.

[0396] В соответствии с примером, заранее заданное значение идентификатора последовательности субизображений (например, 0) указано в отношении всех последовательностей субизображений. Разделитель последовательностей субизображений с идентификатором последовательности субизображений, равным 0, может использоваться, например, перед блоком NAL набора параметров, который применяется ко всем последовательностям субизображений. Например, когда кодирование осуществляется с одним и тем же кодером, с одной и той же конфигурацией кодирования, и все субизображения имеют одинаковую ширину и высоту, они могут совместно использовать одни и те же наборы параметров последовательности (SPS) и наборы параметров изображения (PPS).

[0397] Согласно варианту осуществления, который может использоваться совместно с другими вариантами осуществления или независимо от них, значение идентификатора конкретного уровня резервируется для информации, не характерной ни для какого конкретного уровня, применительно ко всему битовому потоку или по всем уровням, и/или для блоков NAL (и т.п.), для которых назначение какому-либо конкретному уровню не имеет значения. Блоки NAL VCL (или такие кодированные видеоданные) не назначаются этому идентификатору уровня. Например, конец блока NAL битового потока и/или блока NAL разделителя блоков доступа может назначаться идентификатору конкретного уровня. Блок NAL управления декодированием, как описано в других вариантах осуществления, может назначаться идентификатору конкретного уровня, или когда предписания, переносимые в блоке NAL управления декодированием, не характерны ни для какого конкретного уровня, применительно ко всему битовому потоку или по всем уровням. Блоки NAL набора параметров, которые совместно используются между уровнями и/или между битовыми потоками (части которых, например, последовательности независимо кодированных областей изображения, могут объединяться в единый битовый поток), могут назначаться идентификатору конкретного уровня, например, во избежание расхождения значении идентификатора.

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

- информацию, по существу, переносимую в системе (например, формат файла, медиа-презентацию и/или протокол связи),

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

[0399] Информация, управляемая или обусловленная клиентским устройством, приложением воспроизведения или подобным объектом, которая может влиять на процесс декодирования, может содержать, но без ограничения, следующее:

Указание для обработки связанного(ых) блока(ов) NAL или кодированного изображения, как начала кодированной видеопоследовательности. Это может использоваться, например, с интра-изображениями открытой GOP (например, изображениями CRA HEVC), когда декодирование (повторно) начинается с интра-изображения открытой GOP. Например, процесс декодирования HEVC вводит внешне управляемый флаг HandleCraAsBlaFlag, который может быть включен в блок NAL разделителя.

Указание для обработки связанного(ых) блока(ов) NAL или кодированного изображения, как начала нового составляющего битового потока.

Указание для обработки связанного(ых) блока(ов) NAL или кодированного изображения, как начала декодирования предсказанного уровня после переключения уровня вверх.

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

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

Указание конца предсказанного уровня (например, обусловленного переключением уровней вниз). В этом случае, блок NAL разделителя не обязан относиться к каким-либо последующим блокам NAL.

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

[0400] Некоторые подходы базируются на добавление новых блоков данных (например, блоков NAL разделителя) в объединенный битовый поток после кодирования составляющих битовых потоков. Параметры буферизации (например, параметры HRD) можно авторизовать для составляющих битовых потоков и, таким образом, не учитывать добавленные блоки данных. В порядке примера, задано, что модель буферизации проверяет тип блока данных. Если блок данных входит в число тех, которые добавляются или могут добавляться в объединенный битовый поток (например, блок NAL разделителя), модель буферизации не включает ее в буфер кодированных изображений и т.п. Иначе, если блок данных не входит в число тех, которые добавляются или могут добавляться в объединенный битовый поток, модель буферизации добавляет блок данных в буфер кодированных изображений и т.п.

[0401] Согласно варианту осуществления, операция клиентского устройства, приложения воспроизведения или аналогичного объекта (например, объекта в краевой сети) содержит следующие этапы.

[0402] Два или более битовых потоков выбираются из множества битовых потоков 900 (фиг. 8а). Битовые потоки могут быть последовательностями субизображений. Выбранные битовые потоки могут именоваться составляющими битовыми потоками. Выбор битового потока может, например, содержать выбор и разбор трека (в файле-контейнере), который несет битовый поток. Альтернативно или дополнительно, выбор может содержать выбор представления медиа-описания, причем представление соответствует треку, несущему битовый поток, и запрашивает данные, например, (под)сегменты или блоки данных, представления от сервера и принимает запрашиваемые данные.

[0403] Битовые потоки объединяются в единый объединенный битовый поток 902 или объединенный поток блоков данных. Как часть процесса комбинирования, разделители 904 могут записываться в объединенный битовый поток 902, причем разделители 904 указывают битовый поток, которому назначаются блоки данных, связанные с разделителем. Разделителем может быть, например, блок данных разделителя, например, блок NAL разделителя или заголовок субизображения, или идентификатор 908 уровня (фиг. 8b). Подход блоков данных разделителя может использоваться, например, когда система кодирования по существу не позволяет использовать уровни или последовательности субизображений. В подходе идентификаторов уровня идентификатор уровня могут присутствовать, например, в заголовке блока NAL. Этот подход может использоваться, например, когда система кодирования позволяет использовать независимые небазовые уровни, аналогично HEVC

[0404] Когда объект в краевой сети осуществляет вышеописанные этапы, этот объект может действовать как концевая точка сеанса, например, клиент сеанса потоковой передачи DASH. Другой сеанс могут присутствовать между объектом декодера и объектом в краевой сети, где может использоваться другой набор протоколов связи.

[0405] Блок данных в потоке блоков данных может представлять собой, но без ограничения, одно из следующих: блок NAL, кодированное изображение, группу изображений.

[0406] Фиг. 9 иллюстрирует конфигурацию, где две последовательности 950 субизображений, имеющие разное качество, инкапсулируются 952 в треки 954 последовательности субизображений и доставляются 956, например, в клиентское устройство или в облачную службу. Субизображения трека второй последовательности субизображений (изображенные внизу фигуры квадратами с жирными и подчеркнутыми номерами) отличаются качеством (качество 2) от субизображений трека первой последовательности субизображений (изображенных вверху фигуры квадратами с номерами без жирного шрифта и подчеркивания). Клиентское устройство генерирует 958 отдельный поток блоков данных из выбранных последовательностей субизображений и включает разделители в надлежащие места. Блоки данных отдельного потока блоков данных декодируются 960 в множество декодированных последовательностей 962 субизображений. Декодированные последовательности 962 субизображений составляются 964 в последовательности 966 выходных изображений смешанного качества. На иллюстрации этих последовательностей 966 выходных изображений на фиг. 9 последовательности субизображений, исходящие из трека второй последовательности субизображений, изображены квадратами с жирными и подчеркнутыми номерами.

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

[0408] Далее рассмотрен иллюстративный вариант осуществления для указания, что независимо кодированные области изображения происходят из различных типов кодированных изображений (например, изображений IRAP и не-IRAP) в одном и том же кодированном изображении объединенного битового потока.

[0409] Согласно варианту осуществления, приложение воспроизведения включает в себя, в отдельном блоке данных объединенного битового потока, например, в блоке NAL управления декодированием, указание, содержит ли связанное кодированное изображение независимо кодированные области изображения, происходящие из различных типов кодированных изображений (например, изображений IRAP и не-IRAP), или содержит ли связанное кодированное изображение блоки NAL VCL разных типов, например, типа TRAIL и любых типов IRAP блока NAL. Указание может именоваться указанием смешанного типа изображения, и кодированное изображение, связанное с указанием смешанного типа изображения, указывающим независимо кодированные области изображения, исходящие из различных типов изображений или кодированного изображения, имеющего блоки NAL VCL разных типов, можно рассматривать как имеющее свойство смешанного типа изображения или связанное с ним.

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

[0411] Согласно варианту осуществления, когда указание указывает, что кодированное изображение имеет свойство смешанного типа изображения, декодер декодирует, что кодированное изображение декодируется как "последующее" изображение (trailing picture). Следовательно, декодер затем может декодировать кодированное изображение как "последующее" изображение.

[0412] Согласно варианту осуществления, когда указание указывает, что кодированное изображение имеет свойство смешанного типа изображения, декодер декодирует, что порядковый номер изображения (РОС) для кодированного изображения декодируется как "последующее" изображение, РОС для кодированного изображения выводится согласно заранее заданному алгоритму относительно РОС предыдущего опорного изображения во временном подуровне 0. Следовательно, декодер затем может декодировать кодированное изображение как "последующее" изображение и выводит РОС согласно заранее заданному алгоритму относительно РОС предыдущего опорного изображения во временном подуровне 0.

[0413] Согласно варианту осуществления, когда указание указывает, что кодированное изображение не имеет смешанный тип изображения свойство, декодер декодирует из упомянутого отдельного блока данных, что маркировка опорного изображения осуществляется согласно структуре(ам) списка опорных изображений и/или структуре(ам) набора опорных изображений, которые включены в любой сегмент изображения или на которые они ссылаются, например, слайс, кодированного изображения. Заметим, что это также применяется к типам сегментов изображения, которые традиционно предписывают конкретную маркировку опорных изображений, например, маркировку всех опорных изображений как "не используемых в качестве ссылки", обусловленную типом(ами) IDR блока NAL.

[0414] В соответствии с вариантом осуществления, разделитель, например, разделитель последовательностей субизображений или разделитель блоков доступа, или блок NAL управления декодированием используется для передачи свойства масштабируемости битового потока в декодер, что может содержать, но без ограничения, одно или более из следующего:

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

- Указание, являются ли все изображения в области действия разделителя изображениями IRAP и/или GDR.

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

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

[0415] Согласно варианту осуществления, область действия разделителя блоков доступа в AU IRAP или GDR определяется как кодированная видеопоследовательность, которая начинается с AUD.

[0416] Преимущества передачи свойства масштабируемости битового потока в разделителе или блоке NAL управления декодированием на декодер включают в себя, но не ограничиваются один или более из следующих:

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

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

- Когда декодер способен декодировать некоторые, но не все подуровни, уровни и/или OLS, которые могут быть указаны в VPS, знание подуровней, уровней и/или OLS, представленных битовым потоком, позволит приложению заключить, требуется ли извлечение битового подпотока, до передачи битового потока в декодер. Некоторые декодеры могут требовать задания битового потока в качестве ввода для точного представления указанного OLS и указанного самого высокого временного подуровня.

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

[0417] Операция декодирования может извлекать пользу из знания уровней или OLS, представленных битовым потоком и/или самого высокого подуровня, присутствующего в битовом потоке. Передача соответствующих свойств масштабируемости битового потока в разделителе или блоке NAL управления декодированием в декодер может в результате иметь одно или более из следующих преимущества. Аналогично, варианты осуществления указаны для декодирования свойств масштабируемости битового потока и вывода соответствующих действий декодера, как рассмотрено в любом одном или более из следующих пунктов:

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

- Буфер для хранения изображения можно определить как пространство памяти, которое используется для хранения одного декодированного изображения в DPB. Можно задать, что все буферы для хранения изображений имеют одинаковую ширину и высоту (в отсчетах), одну и ту же битовую глубину и/или один и тот же формат цветности. Если изображения в разных уровнях отличаются шириной в отсчетах, высотой в отсчетах, битовой глубиной или форматом цветности, можно задать, что буферы для хранения изображений резервируются с максимальными значениями среди уровней в OLS. Благодаря знанию OLS, представленного битовым потоком, декодер может делать заключение о ширине, высоте, битовой глубине и/или формате цветности, подлежащих резервированию для буферов хранения изображений DPB;

- Параметры HRD, например, задержки начальной буферизации, могут зависеть от того, какой OLS представлен битовым потоком и/или какие подуровни присутствуют. Благодаря знанию OLS, представленного битовым потоком и/или подуровней, присутствующих в битовом потоке, декодер может выбирать параметры HRD, применимые к битовому потоку. В результате декодер может использовать указанные параметры HRD, например, начальную задержку буферизации, для управления СРВ и/или DPB, используемыми в декодере.

[0418] Далее будет рассмотрен иллюстративный вариант осуществления для блока NAL разделителя блоков доступа. Может использоваться следующий синтаксис:

[0419] Семантика aud_irap_or_gdr_au_flag и aud_pic_type описаны ранее. Семантика других синтаксических элементов может задаваться следующим образом.

[0420] aud_htid_info_present_flag, равный 0, указывает, что aud_cvs_htid_plus1 отсутствует в блоке NAL AUD. aud_htid_info_present_flag, равный 1, указывает, что aud_cvs_htid_plus1 присутствует в блоке NAL AUD.

[0421] aud_ols_info_present_flag, равный 0, указывает, что aud_cvs_ols_idx отсутствует в блоке NAL AUD. aud_ols_info_present_flag, равный 1, указывает, что aud_cvs_ols_idx присутствует в блоке NAL AUD.

[0422] aud_cvs_htid_plus1, равный 0, указывает, что все изображения в CVS, начинающиеся с блока NAL AUD, являются изображениями IRAP или изображениями GDR с ph_recovery_poc_cnt, равным 0. aud_cvs_htid_plus1, больший 0, указывает, что все изображения в CVS, начинающиеся с блока NAL AUD, имеют TemporalId, меньший, чем aud_cvs_htid_plus1.

[0423] aud_cvs_ols_idx указывает, что CVS, начинающийся с блока NAL AUD, не содержит никаких других уровней, помимо включенных в OLS с индексом OLS, равным aud_cvs_ols_idx.

[0424] Следует понимать, что аналогично можно вывести другие иллюстративные варианты осуществления. Например, два флага стробирования (aud_htid_info_present_flag и aud_ols_info_present_flag) можно заменить единым флагом стробирования (стробирующим оба aud_cvs_htid_plus1 и aud_cvs_ols_idx) или можно вообще удалить (в результате aud_cvs_htid_plus1 и aud_cvs_ols_idx будут присутствовать, когда aud_irap_or_gdr_au_flag равен 1). В другом примере, в синтаксис включены только самый высокий временной подуровень или сигнализация OLS, но не оба. В еще одном примере, синтаксический элемент aud_cvs_htid используется вместо aud_cvs_htid_plus1 и указывает, что все изображения в CVS, начинающиеся с блока NAL AUD, имеют TemporalId, меньший или равный aud_cvs_htid. Также нужно отметить, что типы данных для синтаксических элементов не обязаны совпадать с представленными в иллюстративном варианте осуществления; например, u(8) можно использовать вместо ue(v) для aud_cvs_ols_idx. Кроме того, следует понимать, что семантика синтаксических элементов предоставляется в качестве примеров, и варианты осуществления аналогично применяются к другой аналогичной семантике. Например, aud_cvs_ols_idx может задаваться как индекс OLS, который использовался для создания битового потока из входного битового потока с использованием заданного процесса извлечения битового подпотока.

[0425] Согласно варианту осуществления, процесс извлечения битового подпотока может иметь на входах битовый поток inBitstream, а также целевой индекс OLS targetOlsIdx и/или целевое самое высокое значение TemporalId, обозначенное tIdTarget, и на выходе битовый подпоток outBitstream. Процесс извлечения битового подпотока вставляет targetOlsIdx и/или самый высокий TemporalId, заданный в качестве ввода в процесс, в разделитель(и), например, разделитель(и) блоков доступа, или блоки NAL управления декодированием в outBitstream.

[0426] Согласно варианту осуществления, процесс извлечения битового подпотока может иметь на входах битовый поток inBitstream, целевой индекс OLS targetOlsIdx и целевое самое высокое значение TemporalId, обозначенное tIdTarget, и на выходе битовый подпоток outBitstream, и содержит один или более из следующих этапов для вывода выходного битового подпотока OutBitstream:

- битовый поток outBitstream задается идентичным битовому потоку inBitstream.

- удалять из outBitstream все блоки NAL с TemporalId, большим tIdTarget.

- удалять из outBitstream все блоки NAL с nal_unit_type, не равным любому из VPS_NUT, DCI_NUT, AUD_NUT и EOB_NUT и с nuh_layer_id, не включенным в целевой OLS.

- удалять из outBitstream все блоки NAL VCL, которых нет в выходных уровнях целевого OLS и которые либо являются изображениями не-IRAP (когда в качестве межуровневых опорных изображений для других уровней в OLS используются только изображения IRAP), либо находятся в подуровнях, которые не используются в качестве ссылки для межуровневого предсказания (когда только до некоторого подуровня используется в качестве ссылки для межуровневого предсказания).

- Когда все блоки NAL VCL AU удаляются на любом вышеописанном этапе вывода, и блок NAL AUD присутствует в AU, удалять блок NAL AUD из outBitstream.

- Когда все блоки изображения (PU) из AU в outBitstream являются GDR PU или все PU из AU в outBitstream являются IRAP PUs, применяется следующее:

Если множественные уровни присутствуют или могут присутствовать (например, если vps_max_layers_minus1 больше 0), и AU в outBitstream не содержит блок NAL AUD, блок NAL AUD добавляется в outBitstream как первый блок NAL в AU, с aud_irap_or_gdr_au_flag, равным 1.

Иначе, если AU в outBitstream содержит блок NAL AUD, значение aud_irap_or_gdr_au_flag устанавливается равным 1 в блоке NAL AUD.

- Установить значения синтаксического элемента каждого блока NAL AUD с aud_irap_or_gdr_au_flag, равным 1, следующим образом (или аналогично, в зависимости от используемого варианта синтаксиса):

aud_htid_info_present_flag устанавливается равным 1.

aud_ols_info_present_flag устанавливается равным 1.

aud_cvs_htid_plus1 устанавливается равным tIdTarget+1.

aud_cvs_ols_idx устанавливается равным targetOlsIdx.

[0427] Далее будет рассмотрен иллюстративный вариант осуществления для блока NAL управления декодированием.

[0428] Согласно варианту осуществления, синтаксис блока NAL управления декодированием содержит по меньшей мере флаги стробирования для присутствия соответствующих синтаксических элементов управления в одном и том же блоке NAL управления декодированием и/или синтаксические элементы управления. Синтаксические элементы управления могут включать в себя, но без ограничения, один или более из target_layer_id, highest_temporal_id, handle_as_cvs_start_flag, no_output_of_prior_pics_flag и/или signaled_slice_id_flag.

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

[0430] target_layer_id является идентификатором уровня, который подлежит декодированию.

[0431] Индекс набора выходных уровней в OLS, который подлежит декодированию.

[0432] highest_temporal_id является идентификатором самого высокого подуровня, который подлежит декодированию.

[0433] handle_as_cvs_start_flag указывает, обрабатывается ли связанное изображение (например, изображение CRA или GRA) как изображение, с которого начинается CLVS.

[0434] no_output_of_prior_pics_flag, когда равен 1, указывает, что изображения, время вывода которых предшествует времени декодирования связанного изображения IDR, не выводятся.

[0435] signaled_slice_id_flag, когда равен 0, указывает, что синтаксический элемент slice address (или любые аналогичные синтаксические элементы, указывающие идентификатор слайса в заголовке слайса, или идентификатор для независимо кодированной области изображения в ее заголовке, например, заголовке слайса) начинается с 0 и увеличивается на 1 для каждого слайса в кодированном изображении в порядке декодирования. Когда signaled_slice_id_flag равен 1, он указывает значения синтаксических элементов slice_address в порядке декодирования. Когда signaled_slice_id_flag равен 1, дополнительно присутствуют следующие синтаксические элементы: deco_slice_id_length_minus1, deco_slices_in_pic_minus1 и slice_id[i].

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

[0437] deco_slice_id_length_minus1 указывает длину синтаксического элемента slice_id[i] fixed-length-coded.

[0438] deco_slices_in_pic_minus1 указывает количество прямоугольных слайсов в изображении.

[0439] slice_id[i], который присутствует для каждого прямоугольного слайса изображения, индексированного по i, содержит значение синтаксического элемента slice_address в порядке декодирования.

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

[0441] Флаги стробирования указывают присутствие соответствующих синтаксических элементов управления. Семантика флагов стробирования может задаваться следующим образом:

[0442] target_lid_present_flag, равный 0, указывает, что target_layer_id отсутствует, и target_lid_present_flag, равный 1, указывает, что target_layer_id присутствует.

[0443] highest_tid_present_flag, равный 0, указывает, что highest_temporal_id отсутствует, и highest_tid_present_flag, равный 1, указывает, что highest_temporal_id присутствует.

[0444] handle_as_cvs_start_present_flag, равный 0, указывает, что handle_as_cvs_start_flag отсутствует, и handle_as_cvs_start_present_flag, равный 1, указывает, что handle_as_cvs_start_flag присутствует.

[0445] no_output_of_prior_pics_present_flag, равный 0, указывает, что no_output_of_prior_pics_flag отсутствует, и no_output_of_prior_pics_present_flag, равный 1, указывает, что no_output_of_prior_pics_flag присутствует.

[0446] slice_id_signalling_present_flag, равный 0, указывает, что signaled_slice_id_flag отсутствует, и slice_id_signalling_present_flag, равный 1, указывает, что signaled_slice_id_flag присутствует.

[0447] vcl_nal_unit_info_present_flag, равный 0, указывает, что mixed_vcl_nal_unit_types_flag отсутствует, и vcl_nal_unit_info_present_flag, равный 1, указывает, что mixed_vcl_nal_unit_types_flag присутствует.

[0448] control_extension_flag, равный 0, указывает, что ни один из синтаксических элементов control_extension_data_flag не присутствует в синтаксической структуре RBSP управления декодированием. Когда control_extension_flag равен 1, это указывает наличие синтаксических элементов control_extension_data_flag в синтаксической структуре RBSP управления декодированием.

[0449] Семантика синтаксических элементов управления может задаваться следующим образом. В семантике, кодированное изображение, связанное с этим блоком NAL управления декодированием, является кодированным изображением, которое содержится в блоке доступа, который содержит этот блок NAL управления декодированием и имеет то же значение NuhLayerId, что и этот блок NAL управления декодированием.

[0450] target_layer_id, при наличии, указывает значение TargetLayerld, которое применяется от блока доступа, содержащего этот RBSP управления декодированием, до, но за исключением следующего блока доступа, в порядке декодирования, содержащего блок NAL управления декодированием с target_layer_id. Когда ни один блок NAL управления декодированием с target_layer_id не присутствует в первом блоке доступа битового потока, TargetLayerId устанавливается равным vps_included_layer_id[0] от начала битового потока до, но за исключением первого блока доступа, в порядке декодирования, содержащего блок NAL управления декодированием с target_layer_id. При наличии в множественных блоках NAL управления декодированием в блоке доступа, все значения target_layer_id в блоке доступа должны быть одинаковыми. Блок NAL управления декодированием с target_layer_id не должен присутствовать в блоке доступа, который не является блоком доступа CVSS.

[0451] highest_temporal_id, при наличии, указывает значение HighestTid, которое применяется от блока доступа, содержащего этот RBSP управления декодированием, до, но за исключением следующего блока доступа, в порядке декодирования, содержащего блок NAL управления декодированием с highest_temporal_id. Когда ни один блок NAL управления декодированием с highest_temporal_id не присутствует в первом блоке доступа битового потока, HighestTid устанавливается равным sps_max_sub_layers_minus1 от начала битового потока до, но за исключением первого блока доступа, в порядке декодирования, содержащего блок NAL управления декодированием с highest_temporal_id. При наличии в множественных блоках NAL управления декодированием в блоке доступа, все значения highest_temporal_id в блоке доступа должны быть одинаковыми. Блок NAL управления декодированием с highest_temporal_id не должен присутствовать в блоке доступа, который не является блоком доступа CVSS.

[0452] handle_as_cvs_start_flag, при наличии, указывает значение HandleAsCvsStartFlag для кодированного изображения, связанное с этим блоком NAL управления декодированием. Когда кодированное изображение, связанное с этим блоком NAL управления декодированием, не является изображением IRAP и не является изображением GRA, handle_as_cvs_start_flag не должен присутствовать. Когда множественные блоки NAL управления декодированием, содержащие handle_as_cvs_start_flag и имеющие то же значение NuhLayerId, присутствуют в блоке доступа, все значения handle_as_cvs_start_flag в этих блоках NAL управления декодированием должны быть одинаковыми. Когда ни один блок NAL управления декодированием с handle_as_cvs_start_flag, равным 1, не связан с кодированным изображением, HandleAsCvsStartFlag устанавливается равным 0 для кодированного изображения.

[0453] Флаг no_output_of_prior_pics_flag, при наличии, указывает значение NoOutputOfPriorPicsFlag для кодированного изображения, связанного с этим блоком NAL управления декодированием. Когда кодированное изображение, связанное с этим блоком NAL управления декодированием, не является изображением ПЖ, no_output_of_prior_pics_flag не должен присутствовать. Когда множественные блоки NAL управления декодированием, содержащие no_output_of_prior_pics_flag и имеющие одно и то же значение NuhLayerId, присутствуют в блоке доступа, все значения no_output_of_prior_pics_flag в этих блоках NAL управления декодированием должны быть одинаковыми.

[0454] Когда slice_id_signalling_present_flag равен 1, в блоке NAL управления декодированием с конкретным значением NuhLayerId, signaled_slice_id_flag, deco_slice_id_length_minus1 (при наличии), deco_slices_in_pic_minus1 (при наличии) и slice_id[i] (при наличии) применяются к кодированным изображениям с этим конкретным значением NuhLayerId от блока доступа, содержащего этот блок NAL управления декодированием до, но за исключением следующего блока доступа, в порядке декодирования, содержащего блок NAL управления декодированием с тем же конкретным значением NuhLayerId и с slice_id_signalling_present_flag, равным 1, или окончания CLVS, в зависимости от того, что наступает раньше в порядке декодирования. Применяется следующая семантика:

[0455] Флаг signalled_slice_id_flag, равный 0, указывает, что deco_slice_id_length_minus1, deco_slices_in_pic_minus1 и slice_id[i] отсутствуют, signalled_slice_id_flag, равный 1, указывает, что deco_slice_id_length_minus1, deco_slices_in_pic_minus1 и slice_id[i] присутствуют.

[0456] deco_slice_id_length_minus1 плюс 1 указывает количество битов, используемых для представления синтаксического элемента slice_id[i]. Значение deco_slice_id_length_minus1 должно находиться в диапазоне от 0 до 15, включительно. Значение deco_slice_id_length_minus1, связанное с кодированным изображением, должно быть равно signaled_slice_id_length_minus1 в активном SPS или PPS для одного и того же кодированного изображения.

[0457] deco_slices_in_pic_minus1 плюс 1 указывает количество синтаксических элементов slice_id[i]. Значение deco_slices_in_pic_minus1, связанное с кодированным изображением, должно быть равно num_slices_in_pic_minus1 в активном SPS или PPS для одного и того же кодированного изображения.

[0458] slice_id[i] указывает ID слайса i-го слайса. Длина синтаксического элемента slice_id[i] составляет deco_slice_id_length_minus1 + 1 битов. Когда отсутствует, значение slice_id[i] предполагается равным i, для каждого i в диапазоне от 0 до num_slices_in_pic_minus1, включительно.

[0459] Флаг mixed_vcl_nal_unit_types_flag используется для вывода переменной mixedVclNalUnitTypesFlag. Переменная mixedVclNalUnitTypesFlag, которая идентифицирует, что все блоки NAL VCL CurrPic имеют одно и то же значение NalUnitType (когда равна 0), или что блоки NAL VCL связанного кодированного изображения могут иметь разные значения NalUnitType, задается следующим образом:

[0460] Если блок NAL управления декодированием с vcl_nal_unit_info_present_flag, равным 1, присутствует в блоке доступа, содержащем CurrPic, переменная mixedVclNalUnitTypesFlag устанавливается равной значению mixed_vcl_nal_unit_types_flag блока NAL управления декодированием. Иначе, mixedVclNalUnitTypesFlag устанавливается равным 0.

[0461] Флаг mixedVclNalUnitTypesFlag может обрабатываться следующим образом в процессе декодирования:

[0462] Когда mixedVclNalUnitTypesFlag равен 1, переменные и функции, связанные с порядковым номером изображения, выводятся посредством обработки текущего изображения как изображения TRAIL независимо от значения NalUnitType. Это необходимо вызывать только для первого слайса изображения.

[0463] Когда mixedVclNalUnitTypesFlag равен 0, вызывается процесс декодирования для маркировки опорного изображения, в котором опорные изображения могут маркироваться как "не используемые в качестве ссылки" или "используемые для долговременной ссылки". Это необходимо вызывать только для первого слайса изображения. Процесс маркировки опорного изображения может оставлять все изображения, включенные в списки опорных изображений, в составе заголовка слайса или снабженные ссылкой из него, как "используемые в качестве ссылки" и помечать все остальные изображения (не включенные в списки опорных изображений) как "не используемые в качестве ссылки".

[0464] Флаг control_extension_data_flag может иметь любое значение. Декодеры могут игнорировать все синтаксические элементы control_extension_data_flag.

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

[0466] Согласно варианту осуществления, синтаксис блока NAL управления декодированием содержит один или более из следующих:

[0467] Синтаксический элемент типа (например, именуемый control_type), который имеет заданные значения, где каждое заданное значение указывает, какой тип управления декодированием включен в этот блок NAL.

[0468] Синтаксический элемент, несущий значение(я) управления указанного типа, например, именуемый control_value. Тип данных синтаксического элемента может задаваться согласно значению типа.

[0469] Биты расширения, которые могут использоваться, например, для увеличения заранее заданной длины синтаксического элемента control value.

[0470] В этом варианте осуществления может использоваться следующий синтаксис:

[0471] Кодирование всех исходных битовых потоков может осуществляться таким образом, чтобы можно было извлекать независимо кодированные области изображения из исходного битового потока и соединять их в один и тот же объединенный битовый поток. В результате, кодирование может приводить к тому, что SPS и PPS всех исходных битовых потоков будут идентичными за исключением:

- уровня (например, в SPS),

- ширины и высоты изображения (например, в SPS),

- разбиения изображений на сегменты изображения, например, разбиения тайла/кирпича (например, в PPS),

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

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

[0472] Назначение ID слайса прямоугольным слайсам (в PPS) рассматривается как один подходящий вариант, который можно использовать как информацию позиционирования для независимо кодированных областей изображения. Однако этот вклад в общем случае применяется к любым видам информации позиционирования, которая позволяет указывать пространственные положения независимо кодированных областей изображения и/или связывать значения ID слайса, ID субизображения или любой аналогичный синтаксический элемент с пространственными положениями.

[0473] Далее будут рассмотрены некоторые детали разбиения изображения на тайлы, кирпичи и прямоугольные слайсы в SPS или PPS, в соответствии с некоторыми вариантами осуществления.

[0474] Согласно варианту осуществления, синтаксис SPS включает в себя синтаксические элементы для разбиения изображения на тайлы, кирпичи и прямоугольные слайсы, в соответствии со значением флага стробирования. Когда разбиение задано в SPS, оно отсутствует в PPS. Когда разбиение не задано в SPS, оно присутствует в PPS.

[0475] В этом варианте осуществления могут использоваться синтаксис и семантика, представленные в вышеприведенных таблицах 1, 2 и 3, или подобных им.

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

[0477] Представленный пример продолжает пример, представленный ранее в этом описании.

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

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

[0480] Кодирование всех версий битовой скорости и разрешения осуществляется таким образом, что позволяет соединять независимо кодированные области изображения из любого исходного битового потока в один и тот же объединенный битовый поток. SPS и PPS всех исходных битовых потоков (например, разные версии разрешения) могут быть идентичны за исключением синтаксических элементов для ширины и высоты изображения, разбиения изображения на тайлы и/или кирпичи, позиции и размера прямоугольных слайсов, и назначения значений ID слайса порядку сканирования или позициям прямоугольных слайсов.

[0481] Кодирование исходных битовых потоков (т.е. всех версий битовой скорости и разрешения) осуществляется таким образом, что значения slice_address битовых потоков не перекрываются, и длина синтаксического элемента slice_address одинакова во всех исходных битовых потоках.

[0482] Последовательности независимо кодированных областей изображения делаются доступными для потоковой передачи, благодаря чему клиент может выбирать, какие из них принимать. Например, каждая последовательность независимо кодированных областей изображения может инкапсулироваться как трек субизображения, как указано в OMAF.

[0483] Для создания объединенного битового потока из доступных последовательностей независимо кодированных областей изображения, клиент (или приложение воспроизведения на клиенте) осуществляет следующие этапы:

[0484] Приложение воспроизведения создает или принимает один или более наборов параметров, пригодных для его способности декодирования. Например, приложение воспроизведения создает один или более наборов параметров, пригодных для способности декодирования "4K", которая может ограничивать максимальный размер изображения до "4K", например, до 8912896 отсчетов яркости, и/или ограничивать максимальную частоту отсчетов, например, в соответствии с декодированием "4K" на конкретной частоте кадров (например, 60 Гц), что в этом примере будет соответствуют 60×8912896 отсчетов яркости в секунду. Для возможности декодирования "4K", разбиение тайлов, наподобие показанного на фиг. 11b, может кодироваться в наборе параметров, и каждый тайл заключается в свой собственный прямоугольный слайс. В этом примере предполагается, что приложение воспроизведения имеет способность декодирования 4K. В общем случае, намеченная способность декодирования может использоваться для выбора ширины и высоты изображения, разбиения тайлов/кирпичей, информации позиции и размера прямоугольного слайса для объединенного битового потока.

[0485] Приложение воспроизведения выбирает принимаемый поднабор последовательностей независимо декодируемых областей изображения и получает значения идентификатора последовательностей независимо декодируемых областей изображения поднабора. В этом примере значения идентификатора являются значениями slice_id (или, эквивалентно, slice_address) прямоугольных слайсов, причем значение идентификатора включено в синтаксис заголовка слайса.

[0486] Приложение воспроизведения создает блок NAL управления декодированием, содержащий значения slice_id выбранных независимо кодированных областей изображения.

[0487] Приложение воспроизведения принимает блоки NAL VCL выбранных независимо кодированных областей изображения и размещает их в порядке декодирования, следующие за блоком NAL управления декодированием.

[0488] Вышеописанные этапы, от выбора поднаборов до приема блоков NAL VCL, могут повторяться всякий раз, когда необходим новый выбор независимо кодированных областей изображения, например, в ответ на изменение ориентации наблюдения.

[0489] Объединенный битовый поток, а также этапы, осуществляемые приложением воспроизведения, проиллюстрированы на фиг. 12а.

[0490] Согласно варианту осуществления, который может использоваться совместно с другими вариантами осуществления или независимо от них, декодер:

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

- принимает независимо кодированные области изображения в порядке декодирования;

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

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

[0491] Согласно варианту осуществления, декодирование или реконструкция некодированной независимо кодированной области изображения заранее задано, например, в стандарте кодирования. Например, декодирование может использовать некоторый заранее заданный режим, например, внешнее предсказание с нулевыми векторами движения от ближайшего опорного изображение (в разности РОС), маркированного как используемого в качестве ссылки без ошибки предсказания.

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

[0493] Декодирование или реконструкция некодированной независимо кодированной области изображения позволяет избегать прерываний при воспроизведении, когда некодированная независимо кодированная область изображения не появляются в окне наблюдения (для 360-градусного видео) или так или иначе не требуется для отображения.

[0494] Согласно варианту осуществления, декодер может вставлять и/или декодировать соответственно расположенную некодированную независимо кодированную область изображения в последующие изображения, пока не будет принята соответственно расположенная независимо кодированная область изображения, исходящая из изображения IRAP.

[0495] Далее будет рассмотрен пример указания, следует ли предоставлять синхронизированные метаданные на выходе видеодекодера.

[0496] Согласно варианту осуществления, который может использоваться совместно с другими вариантами осуществления или независимо от них, объект, например, кодер указывает в первой синтаксической структуре, содержащейся в битовом потоке, должен ли декодер выводить метаданные, содержащиеся в первой синтаксической структуре. Метаданные, содержащиеся в первой синтаксической структуре, могут выводиться, например путем вывода всей первой синтаксической структуры или вывода второй синтаксической структуры, содержащейся в первой синтаксической структуре. Первая синтаксическая структура может представлять собой, но без ограничения любое из следующих:

- сообщение SEI

- блок NAL SEI

- блок NAL управления декодированием

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

[0497] Указание в первой синтаксической структуре может представлять собой, но без ограничения, флаг управления выводом и/или конкретный диапазон значений типа.

[0498] Флаг управления выводом может указывать, например, когда равен 0, что метаданные, содержащиеся в первой синтаксической структуре, не должны выводиться; и когда равен 1, что метаданные, содержащиеся в первой синтаксической структуре, должны выводиться декодером.

[0499] Конкретный диапазон значений типа может быть реализован, например, таким образом, что некоторый диапазон значений типа полезной нагрузки сообщения SEI, задается, например, в стандарте кодирования таким, который декодер выводит.

[0500] В иллюстративном варианте осуществления для сообщения SEI с флагом управления выводом, может использоваться следующий синтаксис:

[0501] В соответствии с вариантом осуществления, sei_output_flag, равный 1, указывает, что сообщение SEI выводится совместно с декодированным и обрезанным изображением, полученным в результате декодирования кодированного изображения, с которым связано сообщение SEI. Флаг sei_output_flag, равный 0, указывает, что сообщение SEI может выводиться или не выводиться совместно с декодированным и обрезанным изображением, полученным в результате декодирования кодированного изображения, с которым связано сообщение SEI.

[0502] Согласно варианту осуществления, объект, например, декодер, декодирует из первой синтаксической структуры, содержащейся в битовом потоке, подлежат ли метаданные, содержащиеся в первой синтаксической структуре, выводу декодером.

[0503] Согласно варианту осуществления, при выводе изображения, объект, например, декодер выводит (совместно с изображением) сообщения SEI, которые имеют sei_output_flag, равный 1, и связаны с изображением.

[0504] Например, в стандарте кодирования может быть заранее задано, или в синтаксическом элементе может быть указано или может декодироваться из него, передаются ли метаданные, содержащиеся в первой синтаксической структуре, совместно с декодированным изображением, полученным декодированием кодированного изображения, которое содержит первую синтаксическую структуру, или передаются ли метаданные, содержащиеся в первой синтаксической структуре, совместно со всеми декодированными изображениями в объеме первой синтаксической структуры.

[0505] Согласно варианту осуществления, объект кодирует временной диапазон в первую синтаксическую структуру. Согласно варианту осуществления, объект декодирует временной диапазон из первой синтаксической структуры. Временной диапазон может представлять собой, но без ограничения, единственный блок NAL VCL, единственное кодированное изображение, блок доступа (потенциально с множественными кодированными изображениями), пока не будет достигнут следующий блок NAL разделителя с тем же типом контента или окончание кодированной видеопоследовательности (в зависимости от того, что наступает раньше), кодированную видеопоследовательность, битовый поток.

[0506] Согласно варианту осуществления, объект кодирует диапазон по уровням в первую синтаксическую структуру. Согласно варианту осуществления, объект декодирует диапазон по уровням из первой синтаксической структуры. Диапазон по уровням указывает уровни, находящиеся в диапазоне действия метаданных, содержащихся в первой синтаксической структуре.

[0507] Согласно варианту осуществления, объект, например, приложение воспроизведения, создающее объединенный битовый поток, создает в объединенном битовом потоке первую синтаксическую структуру, которая указывает рендеринг поднабора последовательностей независимо кодированных областей изображения. Первая синтаксическая структура может дополнительно указывать пространственное позиционирование последовательностей независимо кодированных областей изображения. Например, объект может генерировать сообщение SEI упаковки по областям HEVC, или аналогичную синтаксическую структуру, указывающую положение независимо кодированных областей изображения на проецируемом изображении. Объект может указывать, например, флагом sei_output_flag, равным 1, или аналогичным указанием, что метаданные в первой синтаксической структуре должны выводиться с декодированными изображениями в рамках первой синтаксической структуры.

[0508] Согласно варианту осуществления, указывается, включен ли блок NAL в СРВ для управления HRD. Например, синтаксис блока NAL управления декодированием и/или блока NAL SEI может включать в себя синтаксический элемент, который указывает, включен ли блокИЛЬ в СРВ. Согласно варианту осуществления, приложение воспроизведения и т.п. создает блок NAL управления декодированием и/или блок NAL SEI в битовом потоке, и устанавливает синтаксический элемент для указания, что блок NAL не включен в СРВ.

[0509] Следует понимать, что изобретение не ограничивается никакими конкретными типами составляющих битовых потоков. Например, составляющие битовые потоки могут представлять любое из следующих:

- разделы пространственно-временного разбиения видео (т.е. последовательности субизображений);

- ракурсы стереоскопического или многоракурсного видео;

- поверхности структуры проекции 360-градусной проекции, например, грани многогранной 360-градусной проекции (например, кубической текстуры);

- упакованные области, как указано информацией упаковки по областям;

- пространственно смежные части с единственным разрешением упаковки видео множественного разрешения (например, ERP или СМР множественного разрешения);

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

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

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

[0510] Следует понимать, что другие варианты осуществления можно аналогично реализовать с другими проектными решениями, например, синтаксическими структурами контейнера, отображением для сегментов изображения вместо блоков NAL VCL, и отображением для субизображений вместо последовательностей субизображений.

[0511] Далее рассмотрены некоторые иллюстративные варианты осуществления с использованием (де)кодирования на основе субизображений, например, с точки зрения потоковой передачи зависимого от окна наблюдения 360-градусного видео; кодирования масштабируемого, многоракурсного и стереоскопического видео; кодирования многогранного контента с перекрытием; кодирования контента облака точек.

[0512] Потоковая передача зависимого от окна наблюдения 360-градусного видео:

[0513] Согласно примеру, последовательность кодированных субизображений может инкапсулироваться в трек файла-контейнера, причем трек может разбиваться на сегменты и/или подсегменты, и представление может создаваться в манифесте потоковой передачи (например, MPEG-DASH MPD) для создания (под)сегментов, доступных по запросу, и для объявления свойств последовательности кодированных субизображений. Процесс предыдущего предложения может осуществляться для каждой из кодированных последовательностей субизображений.

[0514] Согласно примеру, клиентское устройство может быть выполнено с возможностью извлекать из информации манифеста множество представлений и извлекать из манифеста сферическую область для каждого из множества представлений. Клиентское устройство также может извлекать из манифеста значения, указывающие качество сферических областей, и/или информацию разрешения для сферических областей или их 2D проекций. Клиентское устройство определяет, какие представления пригодны для использования в нем. Например, клиентское устройство может включать в себя средство для обнаружения ориентации головы при использовании шлема-дисплея и выбора представления с более высоким качеством для покрытия окна наблюдения, чем в представлениях, выбранных для других областей. В результате выбора клиентское устройство может запрашивать (под)сегменты выбранных представлений.

[0515] Согласно примеру, определяется порядок декодирования кодированных изображений или отсчетов формата файла. Выровненные по времени кодированные изображения или отсчеты формата файла выделяются из принятых (под)сегментов выбранных представлений. Базовый трек объединения может использоваться для определения порядка декодирования выровненных по времени кодированных изображений или отсчетов формата файла. Разделители записываются в объединенный битовый поток, где разделители указывают представление, откуда происходят блоки данных, связанные с разделителем. Объединенный битовый поток передается для декодирования.

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

[0517] Согласно примеру, один и тот же контент кодируется в разных интервалах произвольного доступа с использованием последовательности субизображений.

[0518] Согласно примеру, который дополняет и может использоваться в вариантах осуществления, представленных ранее, изменение ориентации наблюдения обуславливает частично другой выбор представлений для запроса, чем ранее. Если последовательности субизображений представлены как отдельные уровни, блок NAL EOS, которому предшествует разделитель, может записываться, в частности, в надлежащий уровень, несущий последовательность субизображений, для указания, что прием и/или декодирование представления выбирается для прерывания. Новые представления, подлежащие запросу, могут запрашиваться, или их декодирование может начинаться со следующей позиции произвольного доступа в последовательностях субизображений, переносимых в представлениях. Когда последовательности субизображений делаются доступными в нескольких интервалах произвольного доступа, представления, имеющие более частые позиции произвольного доступа, могут запрашиваться в ответ на изменение ориентации наблюдения, пока следующий (под)сегмент с позицией произвольного доступа и аналогичного качества не будет доступен из соответствующих представлений, имеющих менее частые позиции произвольного доступа. Представления, которые не нуждаются в изменении в ответ на изменение ориентации наблюдения, не нуждаются в позициях произвольного доступа. Как было рассмотрено ранее, субизображениям может быть разрешено иметь разные типы субизображения или типы блока NAL. Например, субизображение конкретного блока доступа или момента времени может относиться к типу произвольного доступа, тогда как другое субизображение того же конкретного блока доступа или момента времени может относиться к типу без произвольного доступа. Таким образом, субизображения битовых потоков, имеющих разные интервалы произвольного доступа, можно комбинировать.

[0519] Преимущества использования изобретения в 360-градусной потоковой передаче, зависящей от окна наблюдения, включают в себя следующее:

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

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

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

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

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

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

[0520] Как рассмотрено выше, в зависимости от варианта использования, термин "субизображение" может относиться к различным вариантам использования и/или типам проекции. Далее будут рассмотрены примеры, связанные с кодированием субизображений в контексте нескольких из этих вариантов использования.

[0521] Кодирование многогранного контента с перекрытием

[0522] Согласно примеру, разные части 360-градусного контента могут проецироваться на разные поверхности, и проецируемые грани могут иметь перекрывающийся контент. В другом варианте осуществления контент может делиться на несколько областей (например, тайлов с перекрывающимся контентом. Каждая грань или область может кодироваться как субизображение. Каждое субизображение может использовать часть другого субизображения в качестве опорного кадра, как показано на фиг. 12а и 12b для двух примеров, где неперекрывающееся содержимое показано белым прямоугольником, перекрывающиеся области показаны серым цветом, и соответствующие части в субизображениях указаны пунктирным прямоугольником. Информацию пространственного соотношения можно использовать для указания того, как субизображение в пространстве относятся к другим субизображениям.

[0523] Кодирование контента облака точек

[0524] Согласно примеру, каждая часть контента облака точек проецируется на поверхность для генерации патча. Каждый патч может кодироваться как субизображение. Разные патчи могут иметь избыточные данные. Для компенсации этой избыточности каждое субизображение может использовать другое субизображение. В примере на фиг. 12b разные части облака точек спроецированы на поверхность 1 и поверхность 2 для генерации патча 1 и патча 2, соответственно. Каждый патч кодируется как субизображение. В этом примере, часть контента облака точек, обозначенная c, d, e, с избыточностью проецируется на две поверхности, поэтому соответствующий контент избыточен в патче 1 и патче 2. На фиг. 12b, та часть субизображения 2, которую можно предсказывать из субизображения 1, указана пунктирным прямоугольником. Коллекция реконструированных субизображений может формировать выходное изображение. Альтернативно, реконструированные субизображения могут располагаться в 2D выходном изображении.

[0525] Согласно примеру кодирования, патч второго уровня РСС кодируется как второе субизображение и предсказывается реконструированное субизображение соответствующего патча первого уровня РСС. Аналогично, согласно варианту осуществления декодирования, декодируется второе субизображение, причем второе субизображение представляет патч второго уровня РСС, при этом декодирование содержит предсказание из реконструированного субизображения, которое представляет соответствующий патч первого уровня РСС.

[0526] Согласно примеру, последовательности субизображений намеренно кодируются, запрашиваются, передаются, принимаются, и/или декодируются на разных частотах кадров и/или с другим количеством подуровней. Этот вариант осуществления применим, например, когда только часть контента требуется для рендеринга в конкретное время. Например, в 360-градусном видео только окно наблюдения требуется для рендеринга в конкретное время, и при кодировании облака точек и объемного видео часть, необходимая для рендеринга, может зависеть от позиции наблюдения и ориентации наблюдения. Частота кадров и/или количество подуровней для последовательностей субизображений, которые необходимы для рендеринга, может выбираться (при кодировании, запрашивании, передаче, приеме и/или декодировании) более высокой, чем для тех последовательностей субизображений, которые не требуются для рендеринга и/или вероятно не скоро потребуются для рендеринга (например, в порядке реакции на изменение ориентации наблюдения). Описанная конфигурация позволяет снизить необходимую способность декодирования и энергопотребление. Альтернативно, может достигаться ускорение доставки и/или декодирования, например, для более быстрого, чем в реальном времени, воспроизведения. Когда желательно декодирование последовательности субизображений с большим количеством подуровней (например, в порядке реакции на изменение ориентации наблюдения), изображения доступа к подуровню, например, изображения TSA и/или STSA HEVC, могут использоваться для перезапуска кодирования, запрашивания, передачи, приема, и/или декодирования подуровней.

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

[0528] Настоящие варианты осуществления могут обеспечивать некоторые преимущества. При генерации объединенного битового потока, перезаписи заголовков слайсов независимо кодированных областей изображения не требуется. Для объединенного битового потока необходим единственный набор из наборов параметров, взаимно-однозначно согласующихся с наборами параметров исходных битовых потоков. Автор контента может предоставлять наборы параметров возможных объединенных битовых потоков в описании медиа-презентации; таким образом, клиенту не нужно ни создавать, ни перезаписывать наборы параметров. Информация позиционирования независимо кодированных областей изображения может быть включена в синтаксис набора параметров, а не в отдельный блок данных (например, блок NAL управления декодированием). Однако, например, эти подходы не оптимальны, что проанализировано в дальнейшем.

[0529] Если информация позиционирования независимо кодированных областей изображения находится в SPS, в общем случае невозможно объединять разные типы блоков NAL VCL в одно и то же кодированное изображение, чтобы можно было обрабатывать изменения ориентации наблюдения в зависимой от окна наблюдения 360°-ной потоковой передачи, благодаря чему из изображения IRAP происходит только поднабор независимо кодированных областей изображения. Если информация позиционирования независимо кодированных областей изображения находится в SPS, новый выбор независимо кодированных областей изображения может активироваться только в изображении IRAP в объединенном битовом потоке.

[0530] Если информация позиционирования независимо кодированных областей изображения находится в PPS, клиенты необходимы для перезаписи PPS каждый раз, когда делается новый выбор независимо кодированной области изображения. Для перезаписи требуется извлечение всего PPS из исходного битового потока, включающее в себя извлечение синтаксических элементов, не связанных с информацией позиционирования, кодовых слов переменной длины и кодовых слов, условно присутствующих в зависимости от значений синтаксического элемента в активном SPS или переменных, выведенных из него.

[0531] Обобщения

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

[0533] Вышеописанные варианты осуществления пригодны для сопряжения одноуровневого 2D видеокодека с дополнительной функциональностью.

[0534] На фиг. 14а показана блок-схема операций, демонстрирующая способ согласно варианту осуществления. Способ содержит выбор поднабора последовательностей независимо декодируемых областей изображения, представляющих кодированный видеоконтент (блок 151 на фиг. 14а). Затем получаются (152) значения идентификатора последовательностей независимо декодируемых областей изображения поднабора. Определяются (153) порядок независимо декодируемых областей изображения в изображениях последовательности кодированных изображений. Порядок кодируется в битовый поток как отдельный блок данных (154). Блок данных содержит список значений идентификатора последовательностей независимо декодируемых областей изображения поднабора. Последовательность кодированных изображений включена в битовый поток (155), вслед за отдельным блоком данных.

[0535] На фиг. 14b показана блок-схема операций, демонстрирующая способ согласно другому варианту осуществления. Способ содержит получение последовательности независимо декодируемых областей изображения, представляющих кодированный видеоконтент (блок 156 на фиг. 14b). Получают (157) значения идентификатора последовательностей независимо декодируемых областей изображения. Затем описание медиа-презентации авторизуется за счет того, что последовательности независимо декодируемых областей изображения становятся индивидуально доступными (158), и назначают значения идентификатора последовательностям независимо декодируемых областей изображения в описании медиа-презентации (159).

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

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

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

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

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

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

[0537] Пример устройства 1200, например, устройства для кодирования и/или декодирования, проиллюстрирован на фиг. 15. Обобщенная структура устройства будет объяснена в соответствии с функциональными блоками системы. Несколько функциональных возможностей может осуществляться единым физическим устройством, например, все процедуры вычисления могут при желании осуществляться в едином процессоре. Система обработки данных устройства согласно примеру на фиг. 15 содержит главный блок 100 обработки, память 102, запоминающее устройство 104, устройство 106 ввода, устройство 108 вывода и графическую подсистему 110, которые все соединены между собой шиной 112 данных.

[0538] Главный блок 100 обработки может быть традиционным блоком обработки, приспособленным для обработки данных в системе обработки данных. Главный блок 100 обработки может содержать или быть реализованным в виде одного или более процессоров или схемы процессора. Память 102, запоминающее устройство 104, устройство 106 ввода и устройство 108 вывода могут включать в себя традиционные компоненты, известные специалистам в данной области техники. Память 102 и запоминающее устройство 104 сохраняют данные в системе 100 обработки данных. Компьютерный программный код находится в памяти 102 для реализации, например, способов согласно вариантам осуществления. Устройство 106 ввода вводит данные в систему, а устройство 108 вывода принимает данные из системы обработки данных и пересылает данные, например, на дисплей. Шина 112 данных является традиционной шиной данных и, хотя изображена единой линией, она может быть любой комбинацией следующего: шины процессора, шины PCI, графической шины, шины ISA. Соответственно, специалисту очевидно, что устройство может быть любым устройством обработки данных, например, компьютерным устройством, персональным компьютером, компьютером-сервером, мобильным телефоном, смартфоном или устройством доступа в Интернет, например, планшетным компьютером Интернета.

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

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

[0541] Согласно вариантам осуществления, которые перезаписывают идентификаторы уровней, количество последовательностей субизображений может превышать количество уровней, разрешенных ограниченным диапазоном значений идентификаторов уровней. Например, 96 последовательностей субизображений можно использовать для потоковой передачи зависимого от окна наблюдения 360-градусного видео с 6-битовым nuh_layer_id HEVC.

[0542] Кроме того, перезапись полезных нагрузок блоков NAL VCL и большинства или всех блоков NAL не-VCL не требуется при слиянии кодированных последовательностей субизображений в единый битовый поток.

[0543] Заметим, что последовательности субизображений или независимые уровни и т.п. могут использоваться совместно с MCTS и т.п. Реализации декодера и/или профили или уровни кодирования могут иметь ограничения на количество последовательностей субизображений или независимых уровней и т.п. Если больший объем независимо декодируемых пространственно-временных блоков требуется в приложении или варианте использования, допустимо, чтобы он включал в себя более чем один MCTS в последовательности субизображений или независимом уровне и т.п.

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

[0545] При желании, разные рассмотренные здесь функции могут осуществляться в другом порядке и/или одновременно. Кроме того, при желании, одна или более из вышеописанных функций и вариантов осуществления могут быть опциональными или могут объединяться.

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

[0547] Аналогично, где иллюстративные варианты осуществления были описаны со ссылкой на декодер, следует понимать, что кодер может иметь структуру и/или компьютерную программу для генерации битового потока подлежащего декодированию декодером.

[0548] Выше, где иллюстративные варианты осуществления были описаны со ссылкой на синтаксис и семантику, следует понимать, что варианты осуществления аналогично охватывают кодер, который выводит часть битового потока согласно синтаксису и семантике. Аналогично, варианты осуществления аналогично охватывают декодер, который декодирует участок битового потока согласно синтаксису и семантике.

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

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

[0551] Хотя различные аспекты вариантов осуществления изложены в независимых пунктах формулы изобретения, другие аспекты содержат другие комбинации признаков из описанных вариантов осуществления и/или зависимых пунктов формулы изобретения с признаками независимых пунктов формулы изобретения, а не только комбинации, явно изложенные в формуле изобретения.

1. Устройство для кодирования видео, содержащее средство для:

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

2. Устройство по п. 1, которое дополнительно содержит средство для:

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

3. Устройство для декодирования видео, содержащее средство для:

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

4. Устройство по п. 3, которое дополнительно содержит средство для:

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

5. Устройство по п. 4, которое дополнительно содержит средства для:

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

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

6. Устройство по п. 4, которое дополнительно содержит средство для:

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

7. Устройство по п. 3, которое дополнительно содержит средство для:

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

8. Устройство по п. 4, которое дополнительно содержит средство для:

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

9. Способ кодирования видео, содержащий:

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

10. Способ по п. 9, дополнительно содержащий:

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

11. Способ декодирования видео, содержащий:

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

12. Способ по п. 11, дополнительно содержащий:

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

13. Способ по п. 12, дополнительно содержащий:

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

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

14. Способ по п. 12, дополнительно содержащий:

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

15. Способ по п. 11, дополнительно содержащий:

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

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

Унифицированная процедура комбинирования предсказаний в зависимости от позиции // 2784805

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

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

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

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

Способ декодирования изображений, декодер и компьютерный носитель данных // 2784440

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

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

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

Кодирование многокомпонентных атрибутов для кодирования облака точек // 2784416

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

Сигнализация размера выходного изображения для передискретизации опорного изображения // 2784414

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

Кодер, декодер, способ кодирования, способ декодирования и программа сжатия кадров // 2784381

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

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