[0001] Данная заявка испрашивает приоритет по предварительной заявке на патент США 61/925,191, поданной 8 января 2014 года, содержимое которой полностью содержится в данном документе по ссылке.
Область техники, к которой относится изобретение
[0002] Данное раскрытие сущности относится к кодированию видео, а более конкретно, к переносу потоков битов многослойного HEVC-расширения.
Уровень техники
[0003] Возможности цифрового видео могут быть встроены в широкий диапазон устройств, включающих в себя цифровые телевизоры, системы цифровой прямой широковещательной передачи, беспроводные широковещательные системы, планшетные компьютеры, смартфоны, персональные цифровые устройства (PDA), переносные или настольные компьютеры, цифровые камеры, цифровые записывающие устройства, цифровые мультимедийные проигрыватели, устройства для видеоигр, консоли для видеоигр, сотовые или спутниковые радиотелефоны, устройства видеоконференц-связи, абонентские приставки и т.п.
[0004] Различные устройства реализуют такие технологии сжатия видео, как технологии сжатия видео, описанные в стандартах, заданных посредством стандартов MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, часть 10, усовершенствованное кодирование видео (AVC), стандарта высокоэффективного кодирования видео (HEVC), и расширений таких стандартов. Многовидовое HEVC (MV-HEVC), масштабируемое HEVC (SHVC) и трехмерное HEVC (3D-HEVC) являются примерами многослойных расширений в HEVC-стандарт.
Сущность изобретения
[0005] В общем, это раскрытие сущности описывает технологии для переноса потоков битов многослойного расширения стандарта высокоэффективного кодирования видео (HEVC), включающих в себя потоки битов расширения многовидового HEVC (MV-HEVC), масштабируемого HEVC (SHVC) и трехмерного HEVC (3D-HEVC), с помощью MPEG-2-систем. В соответствии с одной или более технологий этого раскрытия сущности, видеодекодер собирает, в буферной модели, единицу доступа из множества элементарных потоков для потока данных. Поток данных может представлять собой транспортный поток или программный поток. Идентичная буферная модель используется независимо от того, содержат либо нет элементарные потоки SHVC-, MV-HEVC- или 3D-HEVC-потоки битов. Кроме того, видеодекодер декодирует единицу доступа.
[0006] В одном аспекте, это раскрытие сущности описывает способ декодирования видеоданных, при этом способ содержит: прием потока видеоданных, содержащего множество элементарных потоков; сборку, в буферной модели, единицы доступа из множества элементарных потоков для потока видеоданных, при этом: поток видеоданных представляет собой транспортный поток или программный поток, и идентичная буферная модель используется для того, чтобы собирать единицу доступа, независимо от того, содержат ли элементарные потоки какие-либо из множества различных типов многослойного кодированного потока битов; и декодирование единицы доступа, причем единица доступа содержит одно или более изображений видеоданных.
[0007] В другом аспекте, это раскрытие сущности описывает устройство декодирования видео, содержащее: запоминающее устройство, выполненное с возможностью сохранять видеоданные; и один или более процессоров, выполненных с возможностью: принимать поток видеоданных, содержащий множество элементарных потоков; собирать, в буферной модели, единицу доступа из множества элементарных потоков для потока видеоданных, при этом: поток видеоданных представляет собой транспортный поток или программный поток, и идентичная буферная модель используется для того, чтобы собирать единицу доступа, независимо от того, содержат ли элементарные потоки какие-либо из множества различных типов многослойного кодированного потока битов; и декодировать единицу доступа, причем единица доступа содержит одно или более изображений видеоданных.
[0008] В другом аспекте, это раскрытие сущности описывает устройство декодирования видео, содержащее: средство для приема потока видеоданных, содержащего множество элементарных потоков; средство для сборки, в буферной модели, единицы доступа из множества элементарных потоков для потока видеоданных, при этом: поток видеоданных представляет собой транспортный поток или программный поток, и идентичная буферная модель используется для того, чтобы собирать единицу доступа, независимо от того, содержат ли элементарные потоки какие-либо из множества различных типов многослойного кодированного потока битов; и средство для декодирования единицы доступа, причем единица доступа содержит одно или более изображений видеоданных.
[0009] В другом аспекте, это раскрытие сущности описывает компьютерно-читаемый носитель хранения данных, содержащий сохраненные на нем инструкции, которые, при выполнении, инструктируют устройству декодирования видео: принимать поток видеоданных, содержащий множество элементарных потоков; собирать, в буферной модели, единицу доступа из множества элементарных потоков для потока видеоданных, при этом: поток видеоданных представляет собой транспортный поток или программный поток, и идентичная буферная модель используется для того, чтобы собирать единицу доступа, независимо от того, содержат ли элементарные потоки какие-либо из множества различных типов многослойного кодированного потока битов; и декодировать единицу доступа, причем единица доступа содержит одно или более изображений видеоданных.
[0010] Подробности одного или более вариантов осуществления данного раскрытия сущности изложены на прилагаемых чертежах и в нижеприведенном описании. Другие признаки, цели и преимущества технологий, описанных в данном раскрытии сущности, должны становиться очевидными из описания, чертежей и из формулы изобретения.
Краткое описание чертежей
[0011] Фиг. 1 является блок-схемой, иллюстрирующей примерную систему кодирования и декодирования видео, которая может использовать технологии этого раскрытия сущности.
[0012] Фиг. 2 является концептуальной схемой, иллюстрирующей примерные расширения модели на основе декодера системных целевых объектов транспортного потока (T-STD) для стандарта однослойного высокоэффективного кодирования видео (HEVC).
[0013] Фиг. 3 является концептуальной схемой, иллюстрирующей примерные расширения T-STD-модели для многослойной транспортировки временных HEVC-видеоподнаборов.
[0014] Фиг. 4 является концептуальной схемой, иллюстрирующей примерное расширение T-STD-модели для многослойных HEVC-субпотоков видеобитов в соответствии с одной или более технологий этого раскрытия сущности.
[0015] Фиг. 5 является концептуальной схемой, иллюстрирующей примерные расширения P-STD-модели для многослойных HEVC-субпотоков видеобитов, в соответствии с одной или более технологий этого раскрытия сущности.
[0016] Фиг. 6 является блок-схемой, иллюстрирующей примерный видеокодер, который может реализовывать технологии этого раскрытия сущности.
[0017] Фиг. 7 является блок-схемой, иллюстрирующей примерный видеодекодер, который может реализовывать технологии этого раскрытия сущности.
[0018] Фиг. 8 является блок-схемой последовательности операций способа, иллюстрирующей примерную работу видеодекодера, в соответствии с одной или более технологий этого раскрытия сущности.
[0019] Фиг. 9 является блок-схемой последовательности операций способа, иллюстрирующей примерную работу видеодекодера, чтобы собирать и декодировать единицу доступа, в соответствии с одной или более технологий этого раскрытия сущности.
Подробное описание изобретения
[0020] Это раскрытие сущности описывает технологии для переноса потоков битов многослойного HEVC-расширения, включающих в себя потоки битов расширения многовидового HEVC (MV-HEVC), масштабируемого HEVC (SHVC) и трехмерного HEVC (3D-HEVC), с помощью MPEG-2-систем. В MV-HEVC, несколько видов могут кодироваться, например, для различных перспектив. В SHVC, несколько слоев могут кодироваться, например, чтобы поддерживать пространственную масштабируемость, временную масштабируемость или масштабируемость на основе качества. В 3D-HEVC, несколько видов могут кодироваться, например, с компонентами текстуры и глубины, чтобы поддерживать трехмерные представления. В общем, вид в MV-HEVC, слой в SHVC или вид в 3D-HEVC обобщенно могут упоминаться в качестве слоя. Следовательно, SHVC, MV-HEVC и 3D-HEVC могут совместно упоминаться в качестве технологий многослойного HEVC или многослойного HEVC-кодирования.
[0021] Спецификация MPEG-2-систем описывает то, как сжатые потоки мультимедийных (видео и аудио) данных могут мультиплексироваться с другими данными, чтобы формировать один поток данных, подходящий для цифровой передачи или хранения. Спецификация MPEG-2-систем задает принципы программного потока и транспортного потока. Программные потоки смещаются для хранения и отображения одной программы из цифровой услуги хранения, и программный поток предназначен для использования в безошибочных окружениях. Напротив, транспортные потоки предназначены для одновременной доставки определенного числа программ по потенциально подверженным ошибкам каналам. Программные потоки и транспортные потоки включают в себя пакеты пакетизированных элементарных потоков (PES). PES-пакеты программных потоков и транспортных потоков принадлежат одному или более элементарных потоков. Элементарный поток представляет собой один кодированный в цифровой форме (возможно MPEG-сжатый) компонент программы. Например, кодированная видео- или аудиочасть программы может представлять собой элементарный поток.
[0022] Видеодекодер принимает PES-пакеты программных потоков и транспортных потоков. Видеодекодер может декодировать видеоданные, полученные из PES-пакетов. В многослойном HEVC, единица доступа (AU) может включать в себя изображения, ассоциированные с идентичным моментом времени, но с различными слоями. До декодирования изображений единицы доступа видеодекодер, возможно, должен повторно собирать кодированные данные, соответствующие единице доступа, из данных в PES-пакетах. Другими словами, видеодекодер, возможно, должен иметь кодированные данные, соответствующие единице доступа, в состоянии, готовом к декодированию.
[0023] Grüneberg et al. "Text of ISO/IEC 13818-1: 2013/Final Draft Amendment 3 - Transport of HEVC video over MPEG-2 Systems", ISO/IEC JTC1/SC29/WG11 MPEG105/N13656, июль 2013 года, Вена, Австрия (в данном документе, "n13656" или "FDAM 3"), описывает транспортировку HEVC-видео с помощью MPEG-2-систем. Кроме того, Chen и др. "Carriage of HEVC extension streams with MPEG-2 Systems", входной документ m31430 по MPEG, 106th MPEG Meeting, октябрь 2013 года, Женева, Швейцария, входной документ m31430 по MPEG (в данном документе, "входной документ m31430 по MPEG"), предлагает базовое проектное решение переноса потоков HEVC-расширения с помощью MPEG-2-систем. Потоки HEVC-расширения представляют собой HEVC-потоки, соответствующие SHVC, MV-HEVC и 3D-HEVC. Ни FDAM 3, ни входной документ m31430 по MPEG не описывают то, как видеодекодер повторно собирает единицы доступа потоков HEVC-расширения. Например, ни FDAM 3, ни входной документ m31430 по MPEG не описывают буферную модель, которую видеодекодер может использовать для повторной сборки единиц доступа потоков HEVC-расширения.
[0024] В соответствии с одной или более технологий этого раскрытия сущности, видеодекодер собирает, в буферной модели, единицу доступа из множества элементарных потоков для потока данных, такого как транспортный поток или программный поток. Идентичная буферная модель используется независимо от того, содержат либо нет элементарные потоки SHVC-, MV-HEVC- или 3D-HEVC-потоки битов. Видеодекодер затем может декодировать единицу доступа. Посредством использования модели буферизации, видеодекодер может группировать данные из PES-пакетов транспортного потока или программного потока для повторной сборки в единицы доступа, готовые к декодированию. Использование унифицированной буферной модели для SHVC MV-HEVC и 3D-HEVC позволяет минимизировать дополнительную сложность видеодекодера для поддержки SHVC, MV-HEVC и 3D-HEVC.
[0025] Фиг. 1 является блок-схемой, иллюстрирующей примерную систему 10 кодирования и декодирования видео, которая может быть выполнена с возможностью использовать различные технологии этого раскрытия сущности, к примеру, технологии для переноса потоков битов многослойного HEVC-расширения, включающих в себя потоки битов расширения многовидового HEVC (MV-HEVC), масштабируемого HEVC (SHVC) и трехмерного HEVC (3D-HEVC), с помощью MPEG-2-систем.
[0026] Как показано на фиг. 1, система 10 включает в себя исходное устройство 12, которое предоставляет кодированные видеоданные, которые должны быть декодированы позднее посредством целевого устройства 14. В частности, исходное устройство 12 предоставляет кодированные видеоданные в целевое устройство 14 через компьютерно-читаемый носитель 16. Исходное устройство 12 и целевое устройство 14 могут содержать любые из широкого диапазона устройств, включающих в себя настольные компьютеры, ноутбуки (т.е. переносные компьютеры), планшетные компьютеры, абонентские приставки, телефонные аппараты, к примеру, так называемые смартфоны, телевизионные приемники, камеры, устройства отображения, цифровые мультимедийные проигрыватели, консоли для видеоигр, устройство потоковой передачи видео и т.п. В некоторых случаях, исходное устройство 12 и целевое устройство 14 могут быть оснащены возможностями беспроводной связи.
[0027] Целевое устройство 14 может принимать кодированные видеоданные через компьютерно-читаемый носитель 16. Компьютерно-читаемый носитель 16 может содержать любой тип носителя или устройства, допускающего перемещение кодированных видеоданных из исходного устройства 12 в целевое устройство 14. В одном примере, компьютерно-читаемый носитель 16 может содержать среду связи, такую как канал передачи, чтобы давать возможность исходному устройству 12 передавать кодированные видеоданные непосредственно в целевое устройство 14 в реальном времени.
[0028] Кодированные видеоданные могут быть модулированы согласно стандарту связи, такому как протокол беспроводной связи, и переданы в целевое устройство 14. Среда связи может содержать любую беспроводную или проводную среду связи, такую как радиочастотный (RF) спектр или одна или более физических линий передачи. Среда связи может формировать часть сети с коммутацией пакетов, такой как локальная вычислительная сеть, глобальная вычислительная сеть либо глобальная сеть, такая как Интернет. Среда связи может включать в себя маршрутизаторы, коммутаторы, базовые станции или любое другое оборудование, которое может быть полезным для того, чтобы упрощать передачу из исходного устройства 12 в целевое устройство 14.
[0029] В некоторых примерах, кодированные данные могут выводиться из интерфейса 22 вывода в компьютерно-читаемый носитель хранения данных, к примеру, в энергонезависимый компьютерно-читаемый носитель хранения данных, т.е. устройство хранения данных. Аналогично, к кодированным данным может осуществляться доступ из устройства хранения данных посредством интерфейса ввода. Устройство хранения данных может включать в себя любые из множества энергонезависимых носителей хранения данных с распределенным или локальным доступом, такие как жесткий диск, Blu-Ray-диски, DVD, CD-ROM, флэш-память, энергозависимое или энергонезависимое запоминающее устройство или любые другие подходящие цифровые носители хранения данных для сохранения кодированных видеоданных. В дополнительном примере, устройство хранения данных может соответствовать файловому серверу или другому промежуточному устройству хранения данных, которое может сохранять кодированное видео, сформированное посредством исходного устройства 12. Целевое устройство 14 может осуществлять доступ к сохраненным видеоданным из устройства хранения данных, например, через потоковую передачу или загрузку. Файловый сервер может быть любым типом сервера, допускающего сохранение кодированных видеоданных и передачу этих кодированных видеоданных в целевое устройство 14. Примерные файловые серверы включают в себя веб-сервер (например, для веб-узла), FTP-сервер, устройства системы хранения данных с подключением по сети (NAS) или локальный накопитель на дисках. Целевое устройство 14 может осуществлять доступ к кодированным видеоданным через любое стандартное подключение для передачи данных, включающее в себя Интернет-подключение. Оно может включать в себя беспроводной канал (например, Wi-Fi-подключение), проводное подключение (например, DSL, кабельный модем и т.д.) или комбинацию означенного, которая является подходящей для того, чтобы осуществлять доступ к кодированным видеоданным, сохраненным на файловом сервере. Передача кодированных видеоданных из устройства хранения данных может представлять собой потоковую передачу, передачу на основе загрузки или комбинацию вышеозначенного.
[0030] Технологии этого раскрытия сущности могут применяться к кодированию видео в поддержку любых из множества проводных или беспроводных мультимедийных приложений, таких как телевизионные широковещательные передачи по радиоинтерфейсу, кабельные телевизионные передачи, спутниковые телевизионные передачи, потоковые передачи видео по Интернету, такие как динамическая адаптивная потоковая передача по HTTP (DASH), цифровое видео, которое кодируется на носитель хранения данных, декодирование цифрового видео, сохраненного на носителе хранения данных, или другие приложения. В некоторых примерах, система 10 может быть выполнена с возможностью поддерживать одностороннюю или двустороннюю передачу видео для того, чтобы поддерживать такие приложения, как потоковая передача видео, воспроизведение видео, широковещательная передача видео и/или видеотелефония.
[0031] В примере по фиг. 1, исходное устройство 12 включает в себя видеоисточник 18, видеокодер 20 и интерфейс 22 вывода. Целевое устройство 14 включает в себя интерфейс 28 ввода, видеодекодер 30 и устройство 32 отображения. В других примерах, исходное устройство 12 и целевое устройство 14 включают в себя другие компоненты или компоновки. Например, исходное устройство 12 может принимать видеоданные из внешнего видеоисточника, такого как внешняя камера. Аналогично, целевое устройство 14 может взаимодействовать с внешним устройством отображения вместо включения в себя интегрированного устройства отображения.
[0032] Это раскрытие сущности описывает видеокодер 20 и видеодекодер 30 в контексте расширений HEVC-кодирования и, в частности, расширений MV-HEVC-, SHVC- и 3D-HEVC-кодирования. Тем не менее, технологии этого раскрытия сущности могут быть применимыми к другим стандартам или способам кодирования видео. Технологии, описанные в этом раскрытии сущности, могут выполняться посредством видеокодера 20, видеодекодера 30 или других устройств, таких как механизмы сращивания, мультимедийно-ориентированные сетевые элементы, серверы потоковой передачи, маршрутизаторы и другие устройства, которые кодируют, декодируют, собирают, составляют, извлекают или иным образом обрабатывают кодированные потоки видеобитов.
[0033] Проиллюстрированная система 10 по фиг. 1 является просто одним примером. Технологии, описанные в этом раскрытии сущности, могут выполняться посредством устройства кодирования и/или декодирования цифрового видео. Хотя, в общем, технологии этого раскрытия сущности выполняются посредством видеокодера 20 и/или видеодекодера 30, технологии также могут выполняться посредством видеокодера/декодера, типично называемого в качестве "кодека". Кроме того, технологии этого раскрытия сущности также могут выполняться посредством видеопрепроцессора. Исходное устройство 12 и целевое устройство 14 являются просто примерами таких устройств кодирования, в которых исходное устройство 12 формирует кодированные видеоданные для передачи в целевое устройство 14. В некоторых примерах, устройства 12, 14 могут работать практически симметрично, так что каждое из устройств 12, 14 включает в себя компоненты кодирования и декодирования видео. Следовательно, система 10 может поддерживать одностороннюю и двухстороннюю передачу видео между видеоустройствами 12, 14, к примеру, для потоковой передачи видео, воспроизведения видео, широковещательной передачи видео или видеотелефонии.
[0034] Видеоисточник 18 исходного устройства 12 может включать в себя устройство видеозахвата, такое как видеокамера, видеоархив, содержащий ранее захваченное видео, и/или интерфейс прямой видеотрансляции, чтобы принимать видео от поставщика видеосодержимого. В качестве дополнительной альтернативы, видеоисточник 18 может формировать данные компьютерной графики в качестве исходного видео или комбинации передаваемого вживую видео, архивного видео и компьютерно-генерируемого видео. В некоторых примерах, если видеоисточник 18 представляет собой видеокамеру, исходное устройство 12 и целевое устройство 14 могут формировать так называемые смартфоны, планшетные компьютеры или видеофоны. Тем не менее, как упомянуто выше, технологии, описанные в этом раскрытии сущности, могут быть применимыми к кодированию видео в целом и могут применяться к беспроводным и/или проводным вариантам применения. В каждом случае, захваченное, предварительно захваченное или компьютерно-генерируемое видео может быть кодировано посредством видеокодера 20. Кодированная видеоинформация затем может выводиться посредством интерфейса 22 вывода на компьютерно-читаемый носитель 16.
[0035] Компьютерно-читаемый носитель 16 может включать в себя энергозависимые среды, такие как беспроводная широковещательная передача или проводная сетевая передача, либо носители хранения данных (т.е. энергонезависимые носители хранения данных). В некоторых примерах, сетевой сервер (не показан) может принимать кодированные видеоданные из исходного устройства 12 и предоставлять кодированные видеоданные в целевое устройство 14, например, через сетевую передачу. Аналогично, вычислительное устройство оборудования для изготовления носителей, такого как оборудование для штамповки дисков, может принимать кодированные видеоданные из исходного устройства 12 и изготавливать диск, содержащий кодированные видеоданные. Следовательно, можно понимать, что компьютерно-читаемый носитель 16 включает в себя один или более компьютерно-читаемых носителей различных форм, в различных примерах.
[0036] Это раскрытие сущности, в общем, может ссылаться на видеокодер 20, "передающий в служебных сигналах" определенную информацию в другое устройство, к примеру, в видеодекодер 30. Следует понимать, что видеокодер 20 может передавать в служебных сигналах информацию посредством ассоциирования определенных элементов синтаксиса с различными кодированными частями видеоданных. Иными словами, видеокодер 20 может "передавать в служебных сигналах" данные посредством сохранения определенных элементов синтаксиса в заголовках или в рабочих данных различных кодированных частей видеоданных. В некоторых случаях, такие элементы синтаксиса могут кодироваться и сохраняться (например, сохраняться на компьютерно-читаемом носителе 16) до приема и декодирования посредством видеодекодера 30. Таким образом, термин "передача служебных сигналов", в общем, может означать передачу синтаксиса или других данных для декодирования сжатых видеоданных независимо от того, возникает эта связь в реальном или практически в реальном времени либо в пределах промежутка времени, к примеру, может возникать при сохранении на носителе во время кодирования элементов синтаксиса, которые затем могут быть извлечены посредством устройства декодирования в любое время после сохранения на этом носителе.
[0037] Интерфейс 28 ввода целевого устройства 14 принимает информацию из компьютерно-читаемого носителя 16. Информация компьютерно-читаемого носителя 16 может включать в себя синтаксическую информацию, заданную посредством видеокодера 20, которая также используется посредством видеодекодера 30, которая включает в себя элементы синтаксиса, которые описывают характеристики и/или обработку блоков и других кодированных единиц, например, GOP. Устройство 32 отображения отображает декодированные видеоданные пользователю и может содержать любое из множества устройств отображения, таких как дисплей на электронно-лучевой трубке (CRT), жидкокристаллический дисплей (LCD), плазменный дисплей, дисплей на органических светодиодах (OLED), проекционное устройство или другой тип устройства отображения.
[0038] Хотя не показано на фиг. 1, в некоторых аспектах, видеокодер 20 и видеодекодер 30 могут быть интегрированы с аудио-кодером и декодером, соответственно, и могут включать в себя соответствующие модули мультиплексора-демультиплексора либо другие аппаратные средства и программное обеспечение для того, чтобы обрабатывать кодирование как аудио, так и видео в общем потоке данных или в отдельных потоках данных. Если применимо, модули мультиплексора-демультиплексора могут соответствовать протоколу мультиплексора ITU H.223, в качестве одного примера, или другим протоколам, таким как протокол пользовательских дейтаграмм (UDP).
[0039] Видеокодер 20 и видеодекодер 30 могут быть реализованы как любая из множества надлежащих схем кодера или декодера при соответствующих условиях, к примеру, как один или более микропроцессоров, процессоров цифровых сигналов (DSP), специализированных интегральных схем (ASIC), программируемых пользователем вентильных матриц (FPGA), дискретная логическая схема, программное обеспечение, аппаратные средства, микропрограммное обеспечение либо любые комбинации вышеозначенного. Каждый из видеокодера 20 и видеодекодера 30 может быть включен в один или более кодеров или декодеров, любой из которых может быть интегрирован как часть комбинированного видеокодера/декодера (кодека). Устройство, включающее в себя видеокодер 20 и/или видеодекодер 30, может содержать интегральную схему, микропроцессор и/или устройство беспроводной связи, такое как сотовый телефон.
[0040] Примерные стандарты кодирования видео включают в себя ITU-T H.261, ISO/IEC MPEG-1 Visual, ITU-T H.262 или ISO/IEC MPEG-2 Visual, ITU-T H.263, ISO/IEC MPEG-4 Visual и ITU-T H.264 (также известный как ISO/IEC MPEG-4 AVC), включающий в себя расширения масштабируемого кодирования видео (SVC) и кодирования многовидового видео (MVC). ITU-T H.264 | ISO/IEC 14496-10 задает стандарт кодирования видео H.264/AVC. Конкретные приложения ITU-T H.264 | ISO/IEC 14496-10 задают расширения стандарта кодирования видео H.264/AVC. Например, приложение B ITU-T H.264 | ISO/IEC 14496-10 задает формат потока байтов для H.264/AVC. Приложение G ITU-T H.264 | ISO/IEC 14496-10 задает SVC-расширение H.264/AVC. Приложение H ITU-T H.264 | ISO/IEC 14496-10 задает MVC-расширение H.264/AVC.
[0041] Недавно завершено проектирование нового стандарта кодирования видео, а именно, стандарта высокоэффективного кодирования видео (HEVC), посредством Объединенной группы для совместной работы над видеостандартами (JCT-VC) Экспертной группы в области кодирования видео (VCEG) ITU-T и Экспертной группы по движущимся изображениям (MPEG) ISO/IEC. Видеокодер 20 и видеодекодер 30 могут работать согласно HEVC-стандарту, а более конкретно, расширений многовидового HEVC (MV-HEVC), масштабируемого HEVC (SHVC) или 3D-HEVC HEVC-стандарта, как упомянуто в этом раскрытии сущности. HEVC подразумевает несколько дополнительных характеристик устройств кодирования видео относительно устройств, выполненных с возможностью осуществлять выполнять кодирование согласно другим процессам, таким как, например, ITU-T H.264/AVC. Например, тогда как H.264 предоставляет девять режимов внутреннего прогнозирующего кодирования, эталонная модель HEVC может предоставлять всего тридцать пять режимов внутреннего прогнозирующего кодирования.
[0042] Спецификация HEVC-проекта, Wang и др., документ JCTVC-N1003_v1, Объединенная группа для совместной работы над видеостандартами (JCT-VC) ITU-T SG 16 WP 3 и ISO/IEC JTC 1/SC 29/WG 11, 14th Meeting: Вена, AT, 25 июля - 2 августа 2013 года, называется "HEVC WD" или "HEVC" в данном документе, доступна по адресу: http://phenix.int-evry.fr/jct/doc_end_user/documents/14_Vienna/wg11/JCTVC-N1003-v1.zip. Рекомендация ITU-T H.265 | ISO/IEC 23008-2 является окончательной версией HEVC-стандарта.
[0043] Объединенная группа для совместной работы по разработке расширения стандарта кодирования трехмерного видео (JCT-3V) разрабатывает многовидовое расширение в HEVC, а именно, MV-HEVC. Последний рабочий проект (WD) MV-HEVC, Tech и др., документ JCT3V-E1004-v6, Объединенная группа для совместной работы по разработке расширения стандарта кодирования трехмерного видео ITU-T SG 16 WP 3 и ISO/IEC JTC 1/SC 29/WG 11, 5th Meeting: Вена, AT, 27 июля - 2 августа 2013 года, называемый "MV-HEVC WD5" или "MV-HEVC" в данном документе, доступен по адресу: http://phenix.it-sudparis.eu/jct2/doc_end_user/documents/5_Vienna/wg11/JCT3V-E1004-v6.zip.
[0044] Tech и др., документ JCT3V-E1001-v3, Объединенная группа для совместной работы по разработке расширения стандарта кодирования трехмерного видео ITU-T SG 16 WP 3 и ISO/IEC JTC 1/SC 29/WG 11, 5th Meeting: Вена, AT, 27 июля - 2 августа 2013 года (в данном документе, "JCT3V-E1001" или "3D-HEVC"), является последним рабочим проектом трехмерного расширения HEVC, а именно, 3D-HEVC. JCT3V-E1001 доступен по адресу http://phenix.int-evry.fr/jct2/doc_end_user/documents/5_Vienna/wg11/JCT3V-E1001-v3.zip.
[0045] JCT-VC также разрабатывает масштабируемое расширение в HEVC, называемое SHVC. Chen и др., документ JCTVC-N1008_v3, Объединенная группа для совместной работы над видеостандартами (JCT-VC) ITU-T SG 16 WP 3 и ISO/IEC JTC 1/SC 29/WG 11, 14th Meeting: Вена, AT, 25 июля - 2 августа 2013 года (в данном документе, "SHVC WD3" или просто, "SHVC"), является последним рабочим проектом (WD) SHVC. SHVC WD3 доступен по адресу http://phenix.it-sudparis.eu/jct/doc_end_user/documents/14_Vienna/wg11/JCTVC-N1008-v3.zip.
[0046] Flynn и др., документ JCTVC-N1005_v1, Объединенная группа для совместной работы над видеостандартами (JCT-VC) ITU-T SG 16 WP 3 и ISO/IEC JTC 1/SC 29/WG 11, 13th Meeting: Инчхон, KR, 18-26 апреля 2013 года, документ JCTVC-N1005 (в данном документе, JCTVC-N1005), является последним рабочим проектом расширения диапазона HEVC. JCTVC-N1005 доступен по адресу http://phenix.int-evry.fr/jct/doc_end_user/documents/14_Vienna/wg11/JCTVC-N1005-v3.zip.
[0047] В общем, HEVC указывает то, что видеоизображение (или "кадр") может быть разделено на последовательность наибольших единиц кодирования, называемых в качестве единиц дерева кодирования (CTU). CTU может включать в себя соответствующие компоненты сигнала яркости и сигнала цветности, называемые "блоками дерева кодирования (CTB)", например, CTB сигнала яркости и CTB сигнала цветности, включающие в себя выборки сигнала яркости и сигнала цветности, соответственно. Синтаксические данные в потоке битов могут задавать размер для CTU, которая является наибольшей единицей кодирования с точки зрения числа пикселов. Серия последовательных макроблоков включает в себя определенное число CTB в порядке кодирования. Изображение может быть сегментировано на одну или более серий последовательных макроблоков. Каждый CTB может разбиваться на одну или более единиц кодирования (CU) согласно структуре сегментации на дерево квадрантов. В общем, структура данных в виде дерева квадрантов включает в себя один узел в расчете на CU, при этом корневой узел соответствует CTB. Если CU разбивается на четыре суб-CU, узел, соответствующий CU, включает в себя четыре концевых узла, каждый из которых соответствует одной из суб-CU. CU может содержать блок кодирования выборок сигнала яркости и два соответствующих блока кодирования выборок сигнала цветности изображения, которое имеет массив выборок сигнала яркости, массив Cb-выборок и массив Cr-выборок, и синтаксические структуры, используемые для того, чтобы кодировать выборки блоков кодирования. В монохромных изображениях или изображениях, имеющих три отдельных цветовых плоскости, CU может содержать один блок кодирования и синтаксические структуры, используемые для того, чтобы кодировать выборки блока кодирования.
[0048] Каждый узел структуры данных в виде дерева квадрантов может предоставлять синтаксические данные для соответствующей CU. Например, узел в дереве квадрантов может включать в себя флаг разбиения, указывающий то, разбивается ли CU, соответствующая узлу, на суб-CU. Элементы синтаксиса для CU могут быть заданы рекурсивно и могут зависеть от того, разбивается ли CU на суб-CU. Если CU не разбивается дополнительно, она называется "концевой CU". Четыре под-CU концевой CU также могут называться "концевыми CU", даже если отсутствует явное разбиение исходной концевой CU. Например, если CU размера 16x16 не разбивается дополнительно, четыре под-CU 8x8 могут называться "концевыми CU", хотя CU 16x16 вообще не разбивается.
[0049] CU в HEVC имеет назначение, аналогичное назначению макроблока стандарта H.264, за исключением того, что CU не имеет различения размера. Например, CTB может разбиваться на четыре дочерних узла (также называемые "под-CU"), и каждый дочерний узел, в свою очередь, может быть родительским узлом и разбиваться еще на четыре дочерних узла. Конечный неразбиваемый дочерний узел, называемый "концевым узлом дерева квадрантов", содержит узел кодирования, также называемый "концевой CU". Синтаксические данные, ассоциированные с кодированным потоком битов, могут задавать максимальное число раз, которое может разбиваться CTB, называемое "максимальной CU-глубиной", и также могут задавать минимальный размер узлов кодирования. Соответственно, в некоторых примерах, поток битов также может задавать наименьшую единицу кодирования.
[0050] CU включает в себя узел кодирования и одну или более единиц прогнозирования (PU) и одну или более единиц преобразования (TU), ассоциированных с узлом кодирования. Это раскрытие сущности может использовать термин "блок", чтобы ссылаться на любое из CU, единицы прогнозирования (PU), единицы преобразования (TU) или ее сегмента, в контексте HEVC или на аналогичные структуры данных в контексте других стандартов. Размер CU соответствует размеру узла кодирования. Размер CU может колебаться от 8x8 пикселов вплоть до размера CTB максимум в 64x64 пикселов или более.
[0051] Синтаксические данные, ассоциированные с CU, могут описывать сегментацию CU на одну или более PU. В общем, PU представляет пространственную область, соответствующую всей или части CU. Режимы сегментации могут отличаться между тем, CU кодируется в режиме пропуска или прямом режиме, кодируется в режиме внутреннего прогнозирования или кодируется в режиме взаимного прогнозирования. PU могут быть сегментированы с возможностью иметь неквадратную форму или включать в себя сегменты, которые имеют непрямоугольную форму, в случае кодирования глубины, как описано в этом раскрытии сущности. PU CU может содержать прогнозный блок выборок сигнала яркости, два соответствующих прогнозных блока выборок сигнала цветности и синтаксические структуры, используемые для того, чтобы прогнозировать прогнозные блоки. В монохромных изображениях или изображениях, имеющих три отдельных цветовых плоскости, PU может содержать один прогнозный блок и синтаксические структуры, используемые для того, чтобы прогнозировать прогнозный блок. Видеокодер 20 может формировать прогнозирующие блоки (например, прогнозирующие блоки сигналов яркости, прогнозирующие Cb-блоки и прогнозирующие Cr-блоки) для прогнозных блоков (например, прогнозных блоков сигналов яркости, прогнозных Cb-блоков и прогнозных Cr-блоков) каждой PU CU.
[0052] PU может включать в себя данные для извлечения опорных выборок для PU. Опорные выборки могут представлять собой пикселы из опорного блока. В некоторых примерах, опорные выборки могут получаться из опорного блока либо формироваться, например, посредством интерполяции или других технологий. PU также включает в себя данные, связанные с прогнозированием. Например, когда PU кодируется во внутреннем режиме, данные для PU могут быть включены в остаточное дерево квадрантов (RQT), которое может включать в себя данные, описывающие режим внутреннего прогнозирования для TU, соответствующей PU.
[0053] В качестве другого примера, когда PU кодируется во взаимном режиме, PU может включать в себя данные, задающие один или более векторов движения для PU. Данные, задающие вектор движения для PU, могут описывать, например, горизонтальный компонент вектора движения, вертикальный компонент вектора движения, разрешение для вектора движения (например, точность в одну четверть пиксела или точность в одну восьмую пиксела), опорное изображение, на которое указывает вектор движения, и/или список опорных изображений (например, RefPicList 0 или RefPicList 1) для вектора движения.
[0054] HEVC поддерживает прогнозирование для различных PU-размеров. При условии, что размер конкретной CU составляет 2Nx2N, HEVC поддерживает внутреннее прогнозирование для PU-размеров 2Nx2N или NxN и взаимное прогнозирование для симметричных PU-размеров 2Nx2N, 2NxN, Nx2N или NxN. PU, имеющая размер 2Nx2N, имеет размер, идентичный размеру CU, в которой постоянно размещается PU. HEVC поддерживает асимметричную сегментацию для взаимного прогнозирования для PU-размеров 2NxnU, 2NxnD, nLx2N и nRx2N. При асимметричной сегментации одно направление CU не сегментируется, в то время как другое направление сегментируется на 25% и 75%. Часть CU, соответствующая 25%-ому сегменту, указывается посредством "n", после чего идет индикатор относительно "вверх (Up)", "вниз (Down)", "влево (Left)" или "вправо (Right)". Таким образом, например, "2NxnU" ссылается на CU 2Nx2N, которая сегментируется горизонтально с PU 2Nx0,5N вверху и PU 2Nx1,5N внизу. Для кодирования глубины, JCT3V-E1001 дополнительно поддерживает сегментацию PU согласно режимам моделирования глубины (DMM), включающую в себя непрямоугольные сегменты, как описано.
[0055] В этом раскрытии сущности, "NxN" и "N на N" могут быть использованы взаимозаменяемо для того, чтобы ссылаться на размеры в пикселах видеоблока с точки зрения размеров по вертикали и горизонтали, например, 16x16 пикселов, или 16 на 16 пикселов. В общем, блок 16x16 должен иметь 16 пикселов в вертикальном направлении (y=16) и 16 пикселов в горизонтальном направлении (x=16). Аналогично, блок NxN, в общем, имеет N пикселов в вертикальном направлении и N пикселов в горизонтальном направлении, при этом N представляет неотрицательное целочисленное значение. Пикселы в блоке могут размещаться в строках и столбцах. Кроме того, блок не обязательно должен иметь совпадающее число пикселов в горизонтальном направлении и в вертикальном направлении. Например, блоки могут содержать NxM пикселов, причем M не обязательно равно N.
[0056] Синтаксические данные, ассоциированные с CU, также могут описывать сегментацию CU на одну или более TU согласно дереву квадрантов. TU может иметь квадратную или неквадратную (например, прямоугольную) форму. TU CU может содержать блок преобразования выборок сигнала яркости, два соответствующих блока преобразования выборок сигнала цветности и синтаксические структуры, используемые для того, чтобы преобразовывать выборки блоков преобразования. В монохромных изображениях или изображениях, имеющих три отдельных цветовых плоскости, TU может содержать один блок преобразования и синтаксические структуры, используемые для того, чтобы преобразовывать выборки блока преобразования. HEVC-стандарт предоставляет возможность преобразований согласно TU. Видеокодер 20 может преобразовывать значения пиксельных разностей, ассоциированные с TU, чтобы формировать коэффициенты преобразования.
[0057] В некоторых примерах, размеры TU CU основаны на размерах PU CU, хотя это не может всегда иметь место. Кроме того, в некоторых примерах, TU имеют размер, идентичный или меньший размера PU. Остаточные выборки (т.е. значения пиксельных разностей), соответствующие CU, могут подразделяться на меньшие единицы (т.е. блоки преобразования) с использованием структуры в виде дерева квадрантов, известной как "остаточное дерево квадрантов" (RQT). Другими словами, концевая CU может включать в себя дерево квадрантов, указывающее то, как концевая CU сегментируется на TU. Корневой узел дерева квадрантов TU (т.е. RQT), в общем, соответствует концевой CU. Концевые узлы RQT соответствуют TU. TU RQT, которые не разбиваются, называются "концевыми TU". В общем, это раскрытие сущности использует термины "CU" и "TU" для того, чтобы ссылаться на концевую CU и концевую TU, соответственно, если не указано иное.
[0058] TU могут указываться с использованием RQT (также называемой "структурой в виде дерева квадрантов TU"), как пояснено выше. Например, флаг разбиения может указывать то, разбивается ли концевая CU на четыре TU. Затем, каждая TU дополнительно может разбиваться на дополнительные под-TU. Когда TU не разбивается дополнительно, TU может называться "концевой TU". В некоторых примерах, для внутреннего кодирования, все концевые TU, принадлежащие концевой CU, совместно используют идентичный режим внутреннего прогнозирования. Иными словами, идентичный режим внутреннего прогнозирования, в общем, применяется для того, чтобы вычислять прогнозированные значения для всех TU концевой CU. Для внутреннего кодирования, видеокодер 20 может вычислять остаточное значение для каждой концевой TU с использованием режима внутреннего прогнозирования, в качестве разности между частью CU, соответствующей TU, и исходным блоком. TU не обязательно ограничивается размером PU. Таким образом, TU могут быть больше или меньше PU. Для внутреннего кодирования, PU может совместно размещаться с соответствующей концевой TU для идентичной CU. В некоторых примерах, максимальный размер концевой TU может соответствовать размеру соответствующей концевой CU.
[0059] После регулярного внутреннего прогнозирующего или взаимного прогнозирующего кодирования с использованием PU CU, видеокодер 20 может вычислять остаточные данные для TU CU. PU могут содержать синтаксические данные, описывающие способ или режим формирования прогнозирующих пиксельных данных в пространственной области (также называемой "пиксельной областью"), и TU, для регулярного остаточного кодирования, могут содержать коэффициенты в области преобразования после применения преобразования, например, дискретного косинусного преобразования (DCT), целочисленного преобразования, вейвлет-преобразования или концептуально аналогичного преобразования к остаточным видеоданным. Остаточные данные могут соответствовать пиксельным разностям между пикселами некодированного изображения и прогнозными значениями, соответствующими PU. Видеокодер 20 может формировать TU, включающую в себя остаточные данные для CU, и затем преобразовывать TU таким образом, чтобы формировать коэффициенты преобразования для CU.
[0060] После преобразований для того, чтобы формировать коэффициенты преобразования, видеокодер 20 может выполнять квантование коэффициентов преобразования. Квантование, в общем, означает процесс, в котором коэффициенты преобразования квантуются, чтобы, возможно, уменьшать объем данных, используемых для того, чтобы представлять коэффициенты, обеспечивая дополнительное сжатие. Процесс квантования может уменьшать битовую глубину, ассоциированную с некоторыми или всеми коэффициентами. Например, n-битовое значение может быть округлено в меньшую сторону до m-битового значения в ходе квантования, при этом n больше m.
[0061] После квантования видеокодер 200 может сканировать квантованные коэффициенты преобразования, формирующие одномерный вектор, из двумерной матрицы, включающей в себя квантованные коэффициенты преобразования. Сканирование может быть спроектировано с возможностью размещать коэффициенты с более высокой энергией (и, следовательно, более низкой частотой) в начале массива и размещать коэффициенты с более низкой энергией (и, следовательно, более высокой частотой) в конце массива.
[0062] В некоторых примерах, видеокодер 20 может использовать предварительно заданный порядок сканирования для того, чтобы сканировать квантованные коэффициенты преобразования, так чтобы формировать преобразованный в последовательную форму вектор, который может энтропийно кодироваться. В других примерах, видеокодер 20 может выполнять адаптивное сканирование. После сканирования квантованных коэффициентов преобразования, чтобы формировать одномерный вектор, видеокодер 20 может энтропийно кодировать одномерный вектор, например, согласно контекстно-адаптивному двоичному арифметическому кодированию (CABAC), используемому в HEVC. Примеры других процессов энтропийного кодирования включают в себя контекстно-адаптивное кодирование переменной длины (CAVLC), синтаксическое контекстно-адаптивное двоичное арифметическое кодирование (SBAC) и энтропийное кодирование на основе сегментации на интервалы вероятности (PIPE). Видеокодер 20 также может энтропийно кодировать элементы синтаксиса, ассоциированные с кодированными видеоданными, для использования посредством видеодекодера 30 при декодировании видеоданных.
[0063] Видеопоследовательность типично включает в себя последовательность изображений. Как описано в данном документе, "изображение" и "кадр" могут быть использованы взаимозаменяемо. Каждая серия последовательных макроблоков изображения может включать в себя синтаксические данные серии последовательных макроблоков, которые описывают режим кодирования для соответствующей серии последовательных макроблоков. Видеокодер 20 типично управляет видеоблоками в пределах отдельных серий последовательных видеомакроблоков для того, чтобы кодировать видеоданные. Видеоблок может соответствовать узлу кодирования в CU. Видеоблоки могут иметь фиксированные или варьирующиеся размеры и могут отличаться по размеру согласно указанному стандарту кодирования.
[0064] Видеокодер 20 и/или видеодекодер 30 могут выполнять внутрикадровое прогнозирующее кодирование данных глубины и взаимное прогнозирующее кодирование данных глубины. В HEVC, при условии, что размер CU составляет 2Nx2N, видеокодер 20 и видеодекодер 30 могут поддерживать PU-размеры 2Nx2N или NxN для внутреннего прогнозирования и симметричные PU-размеры 2Nx2N, 2NxN, Nx2N, NxN или аналогичные размеры для взаимного прогнозирования. Видеокодер и видеодекодер также могут поддерживать асимметричное сегментирование для PU-размеров 2NxnU, 2NxnD, nLx2N и nRx2N для взаимного прогнозирования.
[0065] Видеокодер 20 может выводить поток битов, который включает в себя последовательность битов, которая формирует представление кодированных изображений и ассоциированных данных. Термин "поток битов" может быть собирательным термином, используемым для того, чтобы означать либо поток единиц сетевого уровня абстракции (NAL) (например, последовательность NAL-единиц), либо поток байтов (например, инкапсуляцию потока NAL-единиц, содержащего префиксы начального кода и NAL-единицы, как указано посредством приложения B HEVC-стандарта). NAL-единица представляет собой синтаксическую структуру, содержащую индикатор относительно типа данных в NAL-единице, и байты, содержащие эти данные в форме первичной байтовой последовательности данных (RBSP), перемежаемой при необходимости битами предотвращения эмуляции.
[0066] Каждая из NAL-единиц может включать в себя заголовок NAL-единицы и может инкапсулировать RBSP. Заголовок NAL-единицы может включать в себя различные элементы синтаксиса, к примеру, элемент синтаксиса, который указывает код типа NAL-единицы. Любой элемент синтаксиса, содержащийся в заголовке NAL-единицы, может упоминаться в данном документе как элемент синтаксиса заголовка NAL-единицы. Код типа NAL-единицы, указываемый посредством заголовка NAL-единицы для NAL-единицы, указывает тип NAL-единицы. RBSP может представлять собой синтаксическую структуру, содержащую целое число байтов, которое инкапсулируется в NAL-единице. В некоторых случаях, RBSP включает в себя нулевые биты.
[0067] Различные типы NAL-единиц могут инкапсулировать различные типы RBSP. Например, первый тип NAL-единицы может инкапсулировать RBSP для набора параметров изображения (PPS), второй тип NAL-единицы может инкапсулировать RBSP для сегмента серии последовательных макроблоков, третий тип NAL-единицы может инкапсулировать RBSP для дополнительной улучшающей информации (SEI), и т.д. NAL-единицы, которые инкапсулируют RBSP для данных кодирования видео (в противоположность RBSP для наборов параметров и SEI-сообщений), могут упоминаться в качестве NAL-единиц слоя кодирования видео (VCL). NAL-единицы, которые содержат наборы параметров (например, наборы параметров видео (VPS), наборы параметров последовательности (SPS), PPS и т.д.) могут упоминаться в качестве NAL-единиц наборов параметров. NAL-единицы, которые содержат SEI-сообщения, могут упоминаться в качестве SEI NAL-единиц. Дополнительная улучшающая информация (SEI) содержит информацию, которая не является обязательной для того, чтобы декодировать выборки кодированных изображений из VCL NAL-единиц.
[0068] Видеодекодер 30 может принимать поток битов, сформированный посредством видеокодера 20. Помимо этого, видеодекодер 30 может синтаксически анализировать поток битов, чтобы получать элементы синтаксиса из потока битов. Видеодекодер 30 может восстанавливать изображения видеоданных, по меньшей мере, частично на основе элементов синтаксиса, полученных из потока битов. Процесс для того, чтобы восстанавливать видеоданные, в общем, может быть обратным по отношении к процессу, выполняемому посредством видеокодера 20 для того, чтобы кодировать видеоданные. Например, видеодекодер 30 может использовать векторы движения PU для того, чтобы определять прогнозирующие блоки для PU текущей CU. Помимо этого, видеодекодер 30 может обратно квантовать блоки коэффициентов TU текущей CU. Видеодекодер 30 может выполнять обратные преобразования для блоков коэффициентов, чтобы восстанавливать блоки преобразования TU текущей CU. Видеодекодер 30 может восстанавливать блоки кодирования текущей CU посредством суммирования выборок прогнозирующих блоков для PU текущей CU с соответствующими выборками блоков преобразования TU текущей CU. Посредством восстановления блоков кодирования для каждой CU изображения, видеодекодер 30 может восстанавливать изображение.
[0069] При многовидовом кодировании может быть предусмотрено несколько видов идентичной сцены с различных точек обзора. Термин "единица доступа" может использоваться для того, чтобы означать набор изображений, которые соответствуют идентичному моменту времени. Таким образом, видеоданные могут концептуализироваться в качестве последовательности единиц доступа, возникающих во времени. "Компонент вида" может быть кодированным представлением вида в одной единице доступа. В этом раскрытии сущности, "вид" может означать последовательность или набор компонентов видов, ассоциированных с идентичным идентификатором вида. Компонент вида может содержать компонент вида текстуры и компонент вида глубины.
[0070] Компонент вида текстуры (т.е. изображение текстуры) может быть кодированным представлением текстуры вида в одной единице доступа. Вид текстуры может быть последовательностью компонентов видов текстуры, ассоциированных с идентичным значением индекса порядка видов. Индекс порядка видов вида может указывать положение камеры вида относительно других видов. Компонент вида глубины (т.е. изображение глубины) может быть кодированным представлением глубины вида в одной единице доступа. Вид глубины может быть набором или последовательностью одного или более компонентов видов глубины, ассоциированных с идентичным значением индекса порядка видов.
[0071] В MV-HEVC, 3D-HEVC и SHVC, видеокодер может формировать поток битов, который содержит последовательность NAL-единиц. Различные NAL-единицы потока битов могут быть ассоциированы с различными слоями потока битов. Слой может задаваться как набор VCL NAL-единиц и ассоциированных не-VCL NAL-единиц, которые имеют идентичный идентификатор слоя. Слой может быть эквивалентным виду при кодировании многовидового видео. При кодировании многовидового видео, слой может содержать все компоненты видов идентичного слоя в различные моменты времени. Каждый компонент вида может представлять собой кодированное изображение видеосцены, принадлежащей конкретному виду в конкретный момент времени. В некоторых примерах кодирования трехмерного видео, слой может содержать либо все изображения кодированной глубины конкретного вида, либо кодированные изображения текстуры конкретного вида. В других примерах кодирования трехмерного видео, слой может содержать как компоненты видов текстуры, так и компоненты видов глубины конкретного вида. Аналогично, в контексте масштабируемого кодирования видео, слой типично соответствует кодированным изображениям, имеющим характеристики видео, отличающиеся от кодированных изображений в других слоях. Такие характеристики видео типично включают в себя пространственное разрешение и уровень качества (например, отношение "сигнал-шум"). В HEVC и его расширениях, временная масштабируемость может достигаться в одном слое посредством задания группы изображений с конкретным временным уровнем в качестве подслоя.
[0072] Для каждого соответствующего слоя потока битов, данные в нижнем слое могут декодироваться независимо от данных в любом верхнем слое. При масштабируемом кодировании видео, например, данные в базовом слое могут декодироваться независимо от данных в улучшающем слое. В общем, NAL-единицы могут инкапсулировать только данные одного слоя. Таким образом, NAL-единицы, инкапсулирующие данные наибольшего оставшегося слоя потока битов, могут удаляться из потока битов без влияния на декодируемость данных в оставшихся слоях потока битов. При многовидовом кодировании и 3D-HEVC, верхние слои могут включать в себя дополнительные компоненты видов. В SHVC, верхние слои могут включать в себя улучшающие данные отношения "сигнал-шум" (SNR), пространственные улучшающие данные и/или временные улучшающие данные. В MV-HEVC, 3D-HEVC и SHVC, слой может упоминаться в качестве "базового слоя", если видеодекодер может декодировать изображения в слое независимо от данных какого-либо другого слоя. Базовый слой может соответствовать базовой HEVC-спецификации (например, HEVC WD).
[0073] В SVC, слои, отличные от базового слоя, могут упоминаться в качестве "улучшающих слоев" и могут предоставлять информацию, которая повышает визуальное качество видеоданных, декодированных из потока битов. SVC может повышать пространственное разрешение, отношение "сигнал-шум" (т.е. качество) или временную скорость. При масштабируемом кодировании видео (например, SHVC), "представление слоя" может быть кодированным представлением пространственного слоя в одной единице доступа. Для простоты пояснения, это раскрытие сущности может называть компоненты видов и/или представления слоев в качестве "компонентов видов/представлений слоев" или просто "изображений".
[0074] Чтобы реализовывать слои, заголовки NAL-единиц могут включать в себя элементы nuh_reserved_zero_6bits синтаксиса. В HEVC WD, элемент nuh_reserved_zero_6bits синтаксиса зарезервирован. Тем не менее, в MV-HEVC, 3D-HEVC и SVC, элемент nuh_reserved_zero_6bits синтаксиса упоминается в качестве элемента nuh_layer_id синтаксиса. Элемент nuh_layer_id синтаксиса указывает идентификатор слоя. NAL-единицы потока битов, которые имеют элементы nuh_layer_id синтаксиса, которые указывают различные значения, принадлежат различным слоям потока битов.
[0075] В некоторых примерах, элемент nuh_layer_id синтаксиса NAL-единицы равен 0, если NAL-единица связана с базовым слоем при многовидовом кодировании (например, MV-HEVC), 3DV-кодировании (например, 3D-HEVC) или масштабируемом кодировании видео (например, SHVC). Если NAL-единица не связана с базовым слоем при многовидовом кодировании, 3DV-кодировании или масштабируемом кодировании видео, элемент nuh_layer_id синтаксиса NAL-единицы может иметь ненулевое значение.
[0076] Кроме того, некоторые компоненты видов/представления слоев в слое могут декодироваться независимо от других компонентов видов/представлений слоев в идентичном слое. Таким образом, NAL-единицы, инкапсулирующие данные определенных компонентов видов/представлений слоев для слоя, могут удаляться из потока битов без влияния на декодируемость других компонентов видов/представлений слоев в слое. Удаление NAL-единиц, инкапсулирующих данные таких компонентов видов/представлений слоев, может уменьшать частоту кадров потока битов. Поднабор компонентов видов/представлений слоев в слое, который может декодироваться независимо от других компонентов видов/представлений слоев в слое, может упоминаться в данном документе как "подслой" или "временной подслой".
[0077] NAL-единицы могут включать в себя элементы temporal_id синтаксиса, которые указывают временные идентификаторы (т.е. TemporalIds) NAL-единиц. Временной идентификатор NAL-единицы идентифицирует подслой, которому принадлежит NAL-единица. Таким образом, каждый подслой слоя может иметь различный временной идентификатор. В общем, если временной идентификатор первой NAL-единицы слоя меньше временного идентификатора второй NAL-единицы идентичного слоя, данные, инкапсулированные посредством первой NAL-единицы, могут декодироваться независимо от данных, инкапсулированных посредством второй NAL-единицы.
[0078] Поток битов может быть ассоциирован с множеством рабочих точек. Каждая рабочая точка потока битов ассоциирована с набором идентификаторов слоев (например, набором значений nuh_layer_id) и временным идентификатором. Набор идентификаторов слоев может обозначаться как OpLayerIdSet, и временной идентификатор может обозначаться как TemporalID. Если идентификатор слоя NAL-единицы находится в наборе идентификаторов слоев для рабочей точки, и временной идентификатор NAL-единицы меньше или равен временному идентификатору рабочей точки, NAL-единица ассоциирована с рабочей точкой. Таким образом, рабочая точка может соответствовать поднабору (например, строгому поднабору) NAL-единиц в потоке битов.
[0079] Спецификация MPEG-2-систем описывает то, как сжатые потоки мультимедийных (видео и аудио) данных могут мультиплексироваться с другими данными, чтобы формировать один поток данных, подходящий для цифровой передачи или хранения. Последняя спецификация MPEG-2 TS является рекомендацией ITU-T H.222.0, версия за июнь 2012 года (в данном документе, "MPEG-2 TS"), в которой предоставляется поддержка усовершенствованного кодирования видео (AVC) и AVC-расширений. Недавно разработано изменение MPEG-2 TS для HEVC. Последний документ является "Text of ISO/IEC 13818-1: 2013/Final Draft Amendment 3 - Transport of HEVC video over MPEG-2 Systems", в выходном документе N13656 по MPEG, июль 2013 года.
[0080] Спецификация MPEG-2-систем задает принцип элементарного потока. В частности, элементарный поток представляет собой один кодированный в цифровой форме (возможно MPEG-сжатый) компонент программы. Например, кодированная видео- или аудиочасть программы может представлять собой элементарный поток. Элементарный поток, во-первых, преобразуется в пакетизированный элементарный поток (PES) до мультиплексирования в программный поток или транспортный поток. В идентичной программе, stream_id используется для того, чтобы отличать PES-пакеты, принадлежащие одному элементарному потоку, от других.
[0081] Дополнительно, спецификация MPEG-2-систем задает принципы программного потока и транспортного потока. Программные потоки и транспортные потоки представляют собой два альтернативных мультиплексирования, нацеленные на различные варианты применения. Программные потоки смещаются для хранения и отображения одной программы из цифровой услуги хранения, и программный поток предназначен для использования в безошибочных окружениях, поскольку он довольно серьезно подвержен ошибкам. Напротив, транспортные потоки предназначены для одновременной доставки определенного числа программ по потенциально подверженным ошибкам каналам. В общем, транспортный поток представляет собой мультиплексирование, созданное для многопрограммных приложений, к примеру, передачи в широковещательном режиме, так что один транспортный поток может размещать множество независимых программ. Программный поток содержит только элементарные потоки, принадлежащие ему, и обычно содержит пакеты с пакетами переменной длины.
[0082] В программном потоке, PES-пакеты, которые извлекаются из способствующих элементарных потоков, организованы в "упаковки". Упаковка содержит заголовок упаковки, необязательный системный заголовок и любое число PES-пакетов, извлеченных из любого из способствующих элементарных потоков (т.е. элементарных потоков программного потока), в любом порядке. Системный заголовок содержит краткие сведения по характеристикам программного потока, такие как: максимальная скорость передачи данных программного потока, число способствующих элементарных видео- и аудиопотоков программного потока и дополнительную информацию синхронизации. Декодер, к примеру, декодер 30, может использовать информацию, содержащуюся в системном заголовке, чтобы определять то, допускает или нет декодер декодирование программного потока.
[0083] Транспортный поток содержит непрерывный ряд транспортных пакетов. Транспортные пакеты представляют собой тип PES-пакетов. Каждый из транспортных пакетов имеет длину в 188 байтов. Использование коротких пакетов фиксированной длины в транспортных потоках означает то, что транспортные потоки не настолько подвержены ошибкам, насколько программные потоки. Дополнительно, обработка транспортного пакета посредством стандартного процесса защиты от ошибок, такого как кодирование по Риду-Соломону, может обеспечивать каждому транспортному пакету длиной в 188 байтов дополнительную защиту от ошибок. Повышенная устойчивость к ошибкам транспортного потока означает то, что транспортный поток имеет лучшую вероятность продолжения существования в подверженных ошибкам каналах, таких как каналы, обнаруженные в окружении широковещательной передачи. С учетом повышенной устойчивости к ошибкам транспортных потоков и способности переносить множество одновременных программ в транспортном потоке, представляется, что транспортные потоки очевидно лучше из двух мультиплексирований (т.е. программных потоков и транспортных потоков). Тем не менее, транспортный поток является более сложным мультиплексированием, чем программный поток, и следовательно, его сложнее создавать и демультиплексировать.
[0084] Первый байт транспортного пакета является байтом синхронизации, который составляет 0x47. Один транспортный поток может переносить множество различных программ, содержащих множество пакетизированных элементарных потоков. Помимо этого, транспортный пакет включает в себя 13-битовое поле идентификатора пакета (PID). Поле PID используется для того, чтобы отличать транспортные пакеты, содержащие данные одного элементарного потока, от транспортных пакетов, переносящих данные других элементарных потоков. Мультиплексор управляет тем, чтобы обеспечивать то, что каждому элементарному потоку присваивается уникальное значение PID. Последний байт транспортного пакета является полем счетчика непрерывности. Значение поля счетчика непрерывности постепенно увеличивается между последовательными транспортными пакетами, принадлежащими идентичному элементарному потоку. Постепенное увеличение значения поля счетчика непрерывности позволяет декодеру, такому как декодер 30, обнаруживать потери или усиление транспортного пакета и потенциально маскировать ошибки, которые могут в ином случае получаться в результате потерь или усиления транспортного пакета.
[0085] Хотя элементарный поток, которому принадлежит транспортный пакет, может определяться на основе значения PID транспортного пакета, декодер, возможно, должен иметь возможность определять то, какие элементарные потоки принадлежат какой программе. Соответственно, конкретная для программ информация явно указывает взаимосвязь между программами и компонентными элементарными потоками. Например, конкретная для программ информация может указывать взаимосвязь между программой и элементарными потоками, принадлежащими программе. Конкретная для программ информация транспортного потока может включать в себя таблицу структуры программ (PMT), таблицу ассоциаций программ (PAT), таблицу условного доступа и таблицу информации сети.
[0086] Каждая программа, переносимая в транспортном потоке, ассоциирована с таблицей структуры программ (PMT). PMT разрешается включать в себя более одной программы. Например, несколько программ, переносимых в транспортном потоке, могут быть ассоциированы с идентичной PMT. PMT, ассоциированная с программой, предоставляет сведения относительно программы и элементарных потоков, которые содержат программу. Например, программа с номером 3 может содержать видео с PID 33, английское аудио с PID 57, китайское аудио с PID 60. Другими словами, в этом примере, PMT может указывать то, что элементарный поток, транспортные пакеты которого включают в себя поля PID со значениями, равными 33, содержит видео программы с номером (например, program_number), равным 3, то, что элементарный поток, транспортные пакеты которого включают в себя поля PID со значениями, равными 57, содержит английское аудио программы с номером 3, и то, что элементарный поток, транспортные пакеты которого включают в себя поля PID со значениями, равными 60, содержит китайское аудио программы с номером 3.
[0087] Базовая PMT может дополняться некоторыми из множества дескрипторов, указываемых в спецификации MPEG-2-систем. Другими словами, PMT может включать в себя один или более дескрипторов. Дескрипторы передают дополнительную информацию относительно программы или компонентных элементарных потоков программы. Дескрипторы могут включать в себя параметры кодирования видео, параметры кодирования аудио, идентификационную информацию языка, информацию панорамирования и сканирования, сведения по условному доступу, информацию об авторских правах и т.д. Широковещательное передающее устройство или другой пользователь при необходимости могут задавать дополнительные частные дескрипторы. В связанных с видео компонентных элементарных потоках, также имеется дескриптор иерархий. Дескриптор иерархий предоставляет информацию, идентифицирующую программные элементы, содержащие компоненты иерархически кодированных видео-, аудио- и частных потоков. Частные потоки могут включать в себя метаданные, такие как поток конкретной для программ информации. В общем, программный элемент представляет собой одно из потоков данных или элементарных потоков, которые включены в программу (т.е. компонентный элементарный поток программы). В транспортных MPEG-2-потоках, программные элементы обычно пакетизируются. В программных MPEG-2-потоках, программные элементы не пакетируются.
[0088] Конкретная для программ информация программного потока может включать в себя карту программного потока (PSM). PSM программного потока предоставляет описание элементарных потоков в программном потоке и взаимосвязи элементарных потоков между собой. Когда переносится в транспортном потоке, эта структура не должна модифицироваться. PSM присутствует в качестве PES-пакета, когда значение stream_id составляет 0xBC.
[0089] Как указано выше, конкретная для программ информация транспортного потока может включать в себя таблицу ассоциаций программ (PAT). PAT транспортного потока содержит полный список всех программ, доступных в транспортном потоке. PAT всегда имеет значение PID 0. Другими словами, транспортные пакеты, имеющие значения PID, равные 0, содержат PAT. PAT перечисляет каждую соответствующую программу транспортного потока вместе со значением PID транспортных пакетов, которые содержат таблицу структуры программ, ассоциированную с соответствующей программой. Например, в примерной PMT, описанной выше, PAT может включать в себя информацию, указывающую то, что PMT, которая указывает элементарные потоки номера 3 программы, имеет PID 1001, и может включать в себя информацию, указывающую то, что другая PMT имеет другой PID 1002. Другими словами, в этом примере, PAT может указывать то, что транспортные пакеты, поля PID которых имеют значения, равные 1001, содержат PMT номера 3 программы, и PAT может указывать то, что транспортные пакеты, поля PID которых имеют значения, равные 1002, содержат PMT другой программы.
[0090] Кроме того, как указано выше, конкретная для программ информация транспортного потока может включать в себя таблицу информации сети (NIT). Номер программы в нуль, указываемый в PAT транспортного потока, имеет специальное значение. В частности, номер программы в 0 указывает на NIT. NIT транспортного потока является необязательной, и когда присутствует, NIT предоставляет информацию относительно физической сети, переносящей транспортный поток. Например, NIT может предоставлять такую информацию, как частоты канала, сведения спутникового транспондера, модуляционные характеристики, инициатор услуги, имя услуги и сведения относительно доступных альтернативных сетей.
[0091] Как указано выше, конкретная для программ информация транспортного потока может включать в себя таблицу условного доступа (CAT). CAT должна присутствовать, если какой-либо элементарный поток в транспортном потоке скремблирован. CAT предоставляет сведения относительно используемых систем скремблирования и предоставляет значения PID транспортных пакетов, которые содержат управление условным доступом и информацию названий. MPEG-2 не указывает формат этой информации.
[0092] Как указано выше, PMT может включать в себя один или более дескрипторов, которые передают информацию относительно программы или компонентного элементарного потока программы. Один или более дескрипторов в PMT могут включать в себя дескриптор иерархий. В транспортном потоке (TS) MPEG-2, дескриптор иерархий спроектирован с возможностью передавать в служебных сигналах иерархию субпотоков битов в различных элементарных потоках. Дескриптор иерархий предоставляет информацию для того, чтобы идентифицировать программные элементы, содержащие компоненты иерархически кодированных видео-, аудио- и частных потоков. Нижеприведенная таблица 2-49 показывает синтаксис дескриптора иерархий. Параграфы после таблицы 2-49 описывают семантику полей дескриптора иерархий.
Дескриптор иерархий
[0093] temporal_scalability_flag - однобитовый флаг, который, когда задан равным 0, указывает то, что ассоциированный программный элемент повышает частоту кадров потока битов, получающегося в результате программного элемента, на который ссылается hierarchy_embedded_layer_index. Значение 1 для этого флага зарезервировано.
[0094] spatial_scalability_flag - однобитовый флаг, который, когда задан равным 0, указывает то, что ассоциированный программный элемент повышает пространственное разрешение потока битов, получающегося в результате программного элемента, на который ссылается hierarchy_embedded_layer_index. Значение 1 для этого флага зарезервировано.
[0095] quality_scalability_flag - однобитовый флаг, который, когда задан равным 0, указывает то, что ассоциированный программный элемент повышает качество SNR или точность воспроизведения потока битов, получающегося в результате программного элемента, на который ссылается hierarchy_embedded_layer_index. Значение 1 для этого флага зарезервировано.
[0096] hierarchy_type - иерархическая взаимосвязь между ассоциированным слоем иерархии и его встроенным в иерархию слоем задается в таблице 2-50 (показана ниже). Если масштабируемость применяется более чем в одном измерении, то это поле должно задаваться равным значению 8 ("комбинированная масштабируемость"), и флаги temporal_scalability_flag, spatial_scalability_flag и quality_scalability_flag должны задаваться соответствующим образом. Для MVC-субпотоков видеобитов, это поле должно задаваться равным значению 9 ("MVC-субпоток видеобитов"), и флаги temporal_scalability_flag, spatial_scalability_flag и quality_scalability_flag должны задаваться равными 1. Для MVC-субпотоков битов для воспроизведения базового вида, поле hierarchy_type должно задаваться равным значению 15, и флаги temporal_scalability_flag, spatial_scalability_flag и quality_scalability_flag должны задаваться равными 1.
[0097] hierarchy_layer_index - hierarchy_layer_index является 6-битовым полем, которое задает уникальный индекс ассоциированного программного элемента в таблице иерархий слоев кодирования. Индексы должны быть уникальными в одном программном определении. Для субпотоков видеобитов AVC-видеопотоков, соответствующих одному или более профилей, заданных в приложении G рекомендации ITU-T H.264 | ISO/IEC 14496-10, он представляет собой индекс программного элемента, который назначается таким способом, что порядок потока битов должен быть корректным, если ассоциированные представления SVC-зависимостей субпотоков видеобитов идентичной единицы доступа повторно собираются в порядке возрастания hierarchy_layer_index. Для MVC-субпотоков видеобитов AVC-видеопотоков, соответствующих одному или более профилей, заданных в приложении H рекомендации ITU-T H.264 | ISO/IEC 14496-10, он представляет собой индекс программного элемента, который назначается таким способом, что порядок потока битов должен быть корректным, если ассоциированные поднаборы компонента вида MVC MVC-субпотоков видеобитов идентичной единицы доступа повторно собираются в порядке возрастания hierarchy_layer_index.
[0098] tref_present_flag - однобитовый флаг, который, когда задан равным 0, указывает то, что поле TREF может присутствовать в заголовках PES-пакетов в ассоциированном элементарном потоке. Значение 1 для этого флага зарезервировано.
[0099] hierarchy_embedded_layer_index - hierarchy_embedded_layer_index является 6-битовым полем, которое задает hierarchy_layer_index (индекс слоя иерархии) программного элемента, который должен быть доступен и присутствовать в порядке декодирования до декодирования элементарного потока, ассоциированного с этим hierarchy_descriptor. Поле hierarchy_embedded_layer_index не определено, если значение hierarchy_type равно 15.
[0100] hierarchy_channel - hierarchy_channel является 6-битовым полем, которое указывает намеченный номер канала для ассоциированного программного элемента в упорядоченном наборе каналов передачи. Самый надежный канал передачи задается посредством наименьшего значения этого поля относительно определения общей иерархии передачи. Данный hierarchy_channel может одновременно назначаться нескольким программным элементам.
[0101] Нижеприведенная таблица 2-50 описывает смысл значений поля hierarchy_type дескриптора иерархий.
Значения полей hierarchy_type
[0102] Как указано выше, PMT может включать в себя один или более дескрипторов, которые передают информацию относительно программы или компонентного элементарного потока программы. В MPEG-2 TS, два дескрипторов передают в служебных сигналах характеристики субпотоков битов для SVC и MVC, соответственно: дескриптор SVC-расширения и дескриптор MVC-расширения. Помимо этого, имеется дескриптор рабочей MVC-точки, который описывает характеристики рабочих точек. Синтаксис и семантика трех дескрипторов предоставляются ниже.
[0103] Для субпотоков видеобитов AVC-видеопотоков, соответствующих одному или более профилей, заданных в приложении G рекомендации ITU-T H.264 | ISO/IEC 14496-10, дескриптор SVC-расширения предоставляет информацию относительно AVC-видеопотока, получающегося в результате повторной сборки (вплоть до) ассоциированного субпотока видеобитов, и предоставляет информацию относительно масштабируемости и повторной сборки ассоциированного субпотока видеобитов. Может быть предусмотрен один дескриптор SVC-расширения, ассоциированный с любым из субпотоков видеобитов AVC-видеопотока, соответствующего одному или более профилей, заданных в приложении G рекомендации ITU-T H.264 | ISO/IEC 14496-10. Таблица 2-96 описывает синтаксис дескриптора SVC-расширения. Параграфы после таблицы 2-96 описывают семантику полей дескриптора SVC-расширения.
Дескриптор SVC-расширения
descriptor_tag
descriptor_length
width
height
frame_rate
average_bitrate
maximum_bitrate
dependency_id
Зарезервировано
quality_id_start
quality_id_end
temporal_id_start
temporal_id_end
no_sei_nal_unit_present
Зарезервировано
}
8
16
16
16
16
16
3
5
4
4
3
3
1
1
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
[0104] width - это 16-битовое поле указывает максимальное разрешение ширины изображения в пикселах повторно собранного AVC-видеопотока.
[0105] height - это 16-битовое поле указывает максимальное разрешение высоты изображения в пикселах повторно собранного AVC-видеопотока.
[0106] frame_rate - это 16-битовое поле указывает максимальную частоту кадров, в кадрах/256 секунд, повторно собранного AVC-видеопотока.
[0107] average_bitrate - это 16-битовое поле указывает среднюю скорость передачи битов, в Кбит в секунду, повторно собранного AVC-видеопотока.
[0108] maximum_bitrate - это 16-битовое поле указывает максимальную скорость передачи битов, в Кбит в секунду, повторно собранного AVC-видеопотока.
[0109] dependency_id - это 3-битовое поле указывает значение dependency_id, ассоциированного с субпотоком видеобитов.
[0110] quality_id_start - это 4-битовое поле указывает минимальное значение quality_id элемента синтаксиса заголовка NAL-единицы для всех NAL-единиц, содержащихся в ассоциированном субпотоке видеобитов. quality_id указывает идентификатор качества для NAL-единицы.
[0111] quality_id_end - это 4-битовое поле указывает максимальное значение quality_id элемента синтаксиса заголовка NAL-единицы для всех NAL-единиц, содержащихся в ассоциированном субпотоке видеобитов.
[0112] temporal_id_start - это 3-битовое поле указывает минимальное значение элемента temporal_id синтаксиса заголовка NAL-единицы для всех NAL-единиц, содержащихся в ассоциированном субпотоке видеобитов.
[0113] temporal_id_end - это 3-битовое поле указывает максимальное значение элемента temporal_id синтаксиса заголовка NAL-единицы для всех NAL-единиц, содержащихся в ассоциированном субпотоке видеобитов.
[0114] no_sei_nal_unit_present - этот однобитовый флаг, когда задан равным 1, указывает то, что SEI NAL-единицы не присутствуют в ассоциированном субпотоке видеобитов. В случае если флаг no_sei_nal_unit_present задается равным 1 для всех субпотоков видеобитов SVC и не задается равным 1 или не присутствует для AVC-субпотока видеобитов SVC, все SEI NAL-единицы, если есть, включены в AVC-субпоток видеобитов SVC. Если дескриптор SVC-расширения отсутствует для всех субпотоков видеобитов, SEI NAL-единицы могут присутствовать в любом представлении SVC-зависимостей субпотока видеобитов SVC и могут требовать переупорядочения в порядок NAL-единиц в единице доступа, как задано в рекомендации ITU-T H.264 | ISO/IEC 14496-10, перед повторной сборкой единиц доступа.
[0115] Для MVC-субпотоков видеобитов AVC-видеопотоков, соответствующих одному или более профилей, заданных в приложении H рекомендации ITU-T H.264 | ISO/IEC 14496-10, дескриптор MVC-расширения предоставляет информацию относительно AVC-видеопотока, получающегося в результате повторной сборки (вплоть до) ассоциированного MVC-субпотока видеобитов, и предоставляет информацию относительно содержащегося MVC-субпотока видеобитов и для повторной сборки ассоциированного MVC-субпотока видеобитов. Может быть предусмотрен один дескриптор MVC-расширения, ассоциированный с любым из MVC-субпотоков видеобитов (с stream_type, равным 0x20) AVC-видеопотока, соответствующего одному или более профилей, заданных в приложении H рекомендации ITU-T H.264 | ISO/IEC 14496-10. Когда MVC-субпоток видеобитов представляет собой MVC-субпоток битов для воспроизведения базового вида, дескриптор MVC-расширения должен присутствовать в ассоциированной PMT или PSM для stream_type, равного 0x1B. Таблица 2-97 описывает синтаксис дескриптора MVC-расширения. Параграфы после таблицы 2-97 описывают семантику конкретных полей дескриптора MVC-расширения.
Дескриптор MVC-расширения
[0116] average_bitrate - это 16-битовое поле указывает среднюю скорость передачи битов, в Кбит в секунду, повторно собранного AVC-видеопотока. Когда задано равным 0, средняя скорость передачи битов не указывается.
[0117] maximum_bitrate - это 16-битовое поле указывает максимальную скорость передачи битов, в Кбит в секунду, повторно собранного AVC-видеопотока. Когда задано равным 0, максимальная скорость передачи битов не указывается.
[0118] view_order_index_min - это 10-битовое поле указывает минимальное значение индекса порядка видов всех NAL-единиц, содержащихся в ассоциированном MVC-субпотоке видеобитов.
[0119] view_order_index_max - это 10-битовое поле указывает максимальное значение индекса порядка видов всех NAL-единиц, содержащихся в ассоциированном MVC-субпотоке видеобитов.
[0120] temporal_id_start - это 3-битовое поле указывает минимальное значение элемента temporal_id синтаксиса заголовка NAL-единицы для всех NAL-единиц, содержащихся в ассоциированном MVC-субпотоке видеобитов.
[0121] temporal_id_end - это 3-битовое поле указывает максимальное значение элемента temporal_id синтаксиса заголовка NAL-единицы для всех NAL-единиц, содержащихся в ассоциированном MVC-субпотоке видеобитов.
[0122] no_sei_nal_unit_present - этот однобитовый флаг, когда задан равным 1, указывает то, что SEI NAL-единицы не присутствуют в ассоциированном субпотоке видеобитов. В случае если флаг no_sei_nal_unit_present задается равным 1 для всех MVC-субпотоков видеобитов и не задается равным 1 или не присутствует для AVC-субпотока видеобитов MVC, все SEI NAL-единицы, если есть, включены в AVC-субпоток видеобитов MVC. Если дескриптор MVC-расширения отсутствует для всех MVC-субпотоков видеобитов, SEI NAL-единицы могут присутствовать в любом поднаборе компонента вида MVC MVC-субпотока видеобитов и могут требовать переупорядочения в порядок NAL-единиц в единице доступа, как задано в рекомендации ITU-T H.264 | ISO/IEC 14496-10, перед повторной сборкой единиц доступа.
[0123] no_prefix_nal_unit_present - этот однобитовый флаг, когда задан равным 1, указывает то, что префиксные NAL-единицы не присутствуют в AVC-субпотоке видеобитов MVC или в MVC-субпотоках видеобитов. Когда этот бит задается равным 0, он указывает то, что префиксные NAL-единицы присутствуют только в AVC-субпотоке видеобитов MVC.
[0124] Дескриптор рабочей MVC-точки указывает информацию профиля и уровня для одной или более рабочих точек.
[0125] Каждая из одной или более рабочих точек состоит из набора из одного или более MVC-субпотоков видеобитов. Если присутствует, дескриптор рабочей MVC-точки должен быть включен в группу элементов данных сразу после поля program_info_length в program_map_section. Если дескриптор рабочей MVC-точки присутствует в программном описании, то, по меньшей мере, один дескриптор иерархий должен присутствовать для каждого MVC-субпотока видеобитов, присутствующего в идентичной программе. Чтобы указывать различные профили, требуется один дескриптор рабочей MVC-точки в расчете на профиль. Таблица 2-100 указывает синтаксис дескриптора рабочей MVC-точки. Параграфы после таблицы 2-100 описывают семантику полей дескриптора рабочей MVC-точки.
Дескриптор рабочей MVC-точки
descriptor_tag
descriptor_length
profile_idc
constraint_set0_flag
constraint_set1_flag
constraint_set2_flag
constraint_set3_flag
constraint_set4_flag
constraint_set5_flag
AVC_compatible_flags
level_count
for (recommendation=0; recommendation<level_count; i++) {
level_idc
operation_points_count
for (j=0; j<operation_points_count; j++) {
Зарезервировано
applicable_temporal_id
num_target_output_views
ES_count
for (k=0; k<ES_count; k++) {
Зарезервировано
ES_reference
}
}
}
}
8
8
1
1
1
1
1
1
2
8
8
8
5
3
8
8
2
6
uimsbf
uimsbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
uimsbf
bslbf
uimsbf
uimsbf
uimsbf
bslbf
uimsbf
[0126] profile_idc - это 8-битовое поле указывает профиль, как задано в рекомендации ITU-T H.264 | ISO/IEC 14496-10, всех рабочих точек, описанных в этом дескрипторе для MVC-потока битов.
[0127] constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag - эти поля должны кодироваться согласно семантике для этих полей, заданной в рекомендации ITU-T H.264 | ISO/IEC 14496-10.
[0128] AVC_compatible_flags - семантика AVC_compatible_flags точно равна семантике поля(ей), заданной для 2 битов между флагом constraint_set2 и полем level_idc в наборе параметров последовательности, как задано в рекомендации ITU-T H.264 | ISO/IEC 14496-10.
[0129] level_count - это 8-битовое поле указывает число уровней, для которых описываются рабочие точки.
[0130] level_idc - это 8-битовое поле указывает уровень, как задано в рекомендации ITU-T H.264 | ISO/IEC 14496-10, MVC-потока битов для рабочих точек, описанных посредством следующих групп элементов данных.
[0131] operation_points_count - это 8-битовое поле указывает число рабочих точек, описанных посредством списка, включенного в следующую группу элементов данных.
[0132] applicable_temporal_id - это 3-битовое поле указывает наибольшее значение temporal_id VCL NAL-единиц в повторно собранном AVC-видеопотоке.
[0133] num_target_output_views - это 8-битовое поле указывает значение числа видов, предназначенных для вывода для ассоциированной рабочей точки.
[0134] ES_count - это 8-битовое поле указывает число значений ES_reference, включенных в следующую группу элементов данных. Элементарные потоки, указываемые в следующей группе элементов данных, совместно формируют рабочую точку MVC-потока видеобитов. Значение 0xff зарезервировано.
[0135] ES_reference - это 6-битовое поле указывает значение индекса слоя иерархии, присутствующее в дескрипторе иерархий, который идентифицирует субпоток видеобитов. Профиль и уровень для одной рабочей точки, например, весь MVC-поток видеобитов, может быть передан в служебных сигналах с использованием AVC-видеодескриптора. Кроме того, MVC предоставляет возможность декодирования поднаборов различного вида, которые могут требовать различных профилей и/или уровней. Спецификация дескриптора рабочей MVC-точки поддерживает индикатор относительно различных профилей и уровней для нескольких рабочих точек.
[0136] Для HEVC-видеопотока, HEVC-видеодескриптор предоставляет базовую информацию для идентификации параметров кодирования, к примеру, параметров профиля и уровня, этого HEVC-видеопотока. Для временного HEVC-субпотока видеобитов или временного HEVC-видеоподнабора, HEVC-видеодескриптор предоставляет такую информацию, как ассоциированное HEVC-представление наивысшего временного подслоя, содержащееся в элементарном потоке, к которому оно применяется. Временной HEVC-субпоток видеобитов, который содержит все VCL NAL-единицы и ассоциированные не-VCL NAL-единицы временного подслоя, как указано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, ассоциированной с TemporalId, равным 0, и который дополнительно может содержать все VCL NAL-единицы и ассоциированные не-VCL NAL-единицы всех временных подслоев, ассоциированных с непрерывным диапазоном TemporalId от 1 до значения, равного или меньшего sps_max_sub_layers_minus1, включенного в активный набор параметров последовательности, как указано в рекомендации ITU-T H.265 | ISO/IEC 23008-2. Временной HEVC-видеоподнабор содержит все VCL NAL-единицы и ассоциированные не-VCL NAL-единицы одного или более временных подслоев, причем каждый временной подслой не присутствует в соответствующем временном HEVC-субпотоке видеобитов, и TemporalId, ассоциированной с каждым временным подслоем, формирует непрерывный диапазон значений.
[0137] Нижеприведенная таблица X-1 показывает синтаксис HEVC-видеодескриптора. Параграфы после таблицы X-1 предоставляют семантические определения полей в HEVC-видеодескрипторе.
HEVC-видеодескриптор
descriptor_tag
descriptor_length
profile_space
tier_flag
profile_idc
profile_compatibility_indication
progressive_source_flag
interlaced_source_flag
non_packed_constraint_flag
frame_only_constraint_flag
reserved_zero_44bits
level_idc
temporal_layer_subset_flag
HEVC_still_present_flag
HEVC_24hr_picture_present_flag
Зарезервировано
if (temporal_layer_subset_flag==1){
Зарезервировано
temporal_id_min
Зарезервировано
temporal_id_max
}
}
8
2
1
5
32
1
1
1
1
44
8
1
1
1
5
5
3
5
3
uimsbf
uimsbf
bslbf
uimsbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
uimsbf
bslbf
bslbf
bslbf
bslbf
bslbf
uimsbf
bslbf
uimsbf
[0138] Profile_space, tier_flag, profile_idc, profile_compatibility_indication, progressive_source_flag, interlaced_source_flag, non_packed_constraint_flag, frame_only_constraint_flag, reserved_zero_44bits, level_idc - когда HEVC-видеодескриптор должен применяться к HEVC-видеопотоку или к полному временному HEVC-представлению, эти поля должны кодироваться согласно семантике, заданной в рекомендации ITU-T H.265 | ISO/IEC 23008-2 для general_profile_space, general_tier_flag, general_profile_idc, general_profile_compatibility_flag[i], general_progressive_source_flag, general_interlaced_source_flag, general_non_packed_constraint_flag, general_frame_only_constraint_flag, general_reserved_zero_44bits, general_level_idc, соответственно, для соответствующего HEVC-видеопотока или полного временного HEVC-представления, и весь HEVC-видеопоток или полное временное HEVC-представление, с которым ассоциирован HEVC-видеодескриптор, должно соответствовать информации, передаваемой в служебных сигналах посредством этих полей.
[0139] Когда HEVC-видеодескриптор должен применяться к временному HEVC-субпотоку видеобитов или к временному HEVC-видеоподнабору, соответствующее HEVC-представление наивысшего временного подслоя которого не является полным временным HEVC-представлением (т.е. представлением подслоя, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, которая содержит все временные подслои вплоть до временного подслоя с TemporalId, равным sps_max_sub_layers_minus1+1, включенным в активный набор параметров последовательности, как указано в рекомендации ITU-T H.265 | ISO/IEC 23008-2), profile_space, tier_flag, profile_idc, profile_compatibility_indication, progressive_source_flag, interlaced_source_flag, non_packed_constraint_flag, frame_only_constraint_flag, reserved_zero_44bits, level_idc должны кодироваться согласно семантике, заданной в рекомендации ITU-T H.265 | ISO/IEC 23008-2 для sub_layer_profile_space, sub_layer_tier_flag, sub_layer_profile_idc, sub_layer_profile_compatibility_flag[i], sub_layer_progressive_source_flag, sub_layer_interlaced_source_flag, sub_layer_non_packed_constraint_flag, sub_layer_frame_only_constraint_flag, sub_layer_reserved_zero_44bits, sub_layer_level_idc, соответственно, для соответствующего HEVC-представления наивысшего временного подслоя, и все HEVC-представление наивысшего временного подслоя, с которым ассоциирован HEVC-видеодескриптор, должно соответствовать информации, передаваемой в служебных сигналах посредством этих полей. Полное временное HEVC-представление является представлением подслоя, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, которая содержит все временные подслои вплоть до временного подслоя с TemporalId, равным sps_max_sub_layers_minus1+1, включенным в активный набор параметров последовательности, как указано в рекомендации ITU-T H.265 | ISO/IEC 23008-2. HEVC-представление наивысшего временного подслоя является представлением подслоя временного подслоя с наибольшим значением TemporalId, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, в ассоциированном временном HEVC-субпотоке видеобитов или временном HEVC-видеоподнаборе.
Примечание X2. В одной или более последовательностей в HEVC-видеопотоке, уровень может быть ниже уровня, передаваемого в служебных сигналах в HEVC-видеодескрипторе, в то время как также может возникать профиль, который является поднабором профиля, передаваемого в служебных сигналах в HEVC-видеодескрипторе. Тем не менее, во всем HEVC-видеопотоке, должны использоваться только поднаборы всего синтаксиса потока битов, которые включены в профиль, передаваемый в служебных сигналах в HEVC-видеодескрипторе, если присутствует. Если наборы параметров последовательности в HEVC-видеопотоке передают в служебных сигналах различные профили, и дополнительные ограничения не передаются в служебных сигналах, то потоку, возможно, требуется анализ для того, чтобы определять то, какому профилю, если таковые имеются, соответствует весь поток. Если HEVC-видеодескриптор должен быть ассоциирован с HEVC-видеопотоком, который не соответствует одному профилю, то HEVC-видеопоток должен быть сегментирован на два или более субпотоков, так что HEVC-видеодескрипторы могут передавать в служебных сигналах один профиль для каждого такого субпотока.
[0140] temporal_layer_subset_flag - этот однобитовый флаг, когда задан равным 1, указывает то, что элементы синтаксиса, описывающие поднабор временных слоев, включены в этот дескриптор. Это поле должно задаваться равным 1 для временных HEVC-видеоподнаборов и для временных HEVC-субпотоков видеобитов. Когда задан равным 0, элементы temporal_id_min и temporal_id_max синтаксиса не включены в этот дескриптор.
[0141] HEVC_still_present_flag - это 1-битовое поле, когда задано равным 1, указывает то, что HEVC-видеопоток или HEVC-представление наивысшего временного подслоя может включать в себя неподвижные HEVC-изображения. Когда задано равным 0, то ассоциированный HEVC-видеопоток не должен содержать неподвижные HEVC-изображения.
Примечание X3. Согласно рекомендации ITU-T H.265 | ISO/IEC 23008-2, IDR-изображения всегда ассоциированы со значением TemporalId, равным 0, Следовательно, если HEVC-видеодескриптор применяется к временному HEVC-видеоподнабору, неподвижные HEVC-изображения могут присутствовать только в ассоциированном временном HEVC-субпотоке видеобитов.
[0142] HEVC_24_hour_picture_present_flag - этот однобитовый флаг, когда задан равным 1, указывает то, что ассоциированный HEVC-видеопоток или HEVC-представление наивысшего временного подслоя может содержать 24-часовые HEVC-изображения. Для получения информации по определению 24-часового HEVC-изображения следует обратиться к 2.1.97 "Information Technology - Generic Coding of Moving Pictures and Associated Audio Information: Systems, Amendment 3, Transport of HEVC video over MPEG-2 systems". Если этот флаг задается равным 0, то ассоциированный HEVC-видеопоток не должен содержать 24-часовое HEVC-изображение.
[0143] temporal_id_min - это 3-битовое поле указывает минимальное значение TemporalId, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, всех HEVC-единиц доступа в ассоциированном элементарном потоке.
[0144] temporal_id_max - это 3-битовое поле указывает максимальное значение TemporalId, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, всех HEVC-единиц доступа в ассоциированном элементарном потоке.
[0145] Chen и др., "Carriage of HEVC extension streams with MPEG-2 Systems", входной документ m31430 по MPEG, 106th MPEG Meeting, октябрь 2013 года, Женева, Швейцария, входной документ m31430 по MPEG (в данном документе, "входной документ m31430 по MPEG"), предлагает базовое проектное решение переноса потоков HEVC-расширения с помощью MPEG-2-систем. В частности, входной документ m31430 по MPEG предлагает то, что субпотоки битов должны собираться вместе с тем, чтобы формировать рабочие точки. Эта сборка субпотоков битов является стандартной и работает для любого стандарта многослойного HEVC-расширения, такого как SHVC, MV-HEVC или даже 3D-HEVC.
[0146] Некоторые базовые принципы проектирования входного документа m31430 по MPEG обобщаются следующим образом. Во-первых, дескриптор иерархий в Grüneberg и др., "Text of ISO/IEC 13818-1: 2013/Final Draft Amendment 3 - Transport of HEVC video over MPEG-2 Systems", ISO/IEC JTC1/SC29/WG11 MPEG105/N13656, июль 2013 года, Вена, Австрия (в данном документе, "n13656" или "FDAM 3") используется для того, чтобы формировать иерархию временных подслоев. Аналогично, дескриптор иерархий используется только для временной масштабируемости, когда вовлекаются несколько слоев.
[0147] Второй принцип проектирования содержит введение, во входном документе m31430 по MPEG, нового дескриптора, а именно, дескриптора расширения иерархий, для того чтобы формировать иерархию слоев (например, виды, базовые слои, улучшающие слои). В частности, дескриптор расширения иерархий предоставляет информацию для того, чтобы идентифицировать программные элементы, содержащие компоненты иерархически кодированных видео-, аудио- и частных потоков. Входной документ m31430 по MPEG предполагает то, что каждый элементарный поток содержит не более одного слоя. Следовательно, дескриптор расширения иерархий касается только элементарного потока, соответствующего одному уникальному слою. Ниже приводятся синтаксис и семантика дескриптора расширения иерархий, как представлено в документе m31430.
Дескриптор расширения иерархий
2.6.98. Семантическое определение полей в дескрипторе расширения иерархий
Когда дескриптор расширения иерархий присутствует, он используется для того, чтобы указывать зависимость слоев, присутствующих в различных элементарных потоках. Тем не менее, агрегирование временных подслоев реализуется посредством дескриптора иерархий, как указано в изменении 3 ISO/IEC 13818-1.
extension_dimension_bits - 16-битовое поле, указывающее возможное улучшение ассоциированного программного элемента из базового слоя, получающегося в результате программного элемента слоя с nuh_layer_id, равным 0.
Выделение битов для улучшающих размеров заключается в следующем.
I-ый бит, равный 1, указывает то, что соответствующий улучшающий размер присутствует.
hierarchy_layer_index - hierarchy_layer_index является 6-битовым полем, которое задает уникальный индекс ассоциированного программного элемента в таблице иерархий слоев кодирования. Индексы должны быть уникальными в одном программном определении. Для субпотоков видеобитов HEVC-видеопотоков, соответствующих одному или более профилей, заданных в приложении G или H рекомендации ITU-T H.265 | ISO/IEC 23008-2, он представляет собой индекс программного элемента, который назначается таким способом, что порядок потока битов должен быть корректным, если ассоциированные слои зависимостей субпотоков видеобитов идентичной единицы доступа повторно собираются в порядке возрастания hierarchy_layer_index.
tref_present_flag - однобитовый флаг, который, когда задан равным 0, указывает то, что поле TREF может присутствовать в заголовках PES-пакетов в ассоциированном элементарном потоке. Значение 1 для этого флага зарезервировано.
nuh_layer_id - 6-битовое поле указывает наибольший nuh_layer_id NAL-единиц в элементарном потоке, ассоциированном с этим hierarchy_extension_descriptor().
temporal_id - 3-битовое поле указывает наибольший TemporalId NAL-единиц в элементарном потоке, ассоциированном с этим hierarchy_extension_descriptor().
num_embedded_layers - 6-битовое поле, которое указывает число прямых зависимых программных элементов, которые должны быть доступными и присутствовать в порядке декодирования до декодирования элементарного потока, ассоциированного с этим hierarchy_extension_descriptor().
hierarchy_ext_embedded_layer_index - hierarchy_ext_embedded_layer_index является 6-битовым полем, которое задает hierarchy_layer_index программного элемента, который должен быть доступным и присутствовать в порядке декодирования до декодирования элементарного потока, ассоциированного с этим hierarchy_extension_descriptor. Это поле не определено, если значение hierarchy_type равно 15.
hierarchy_channel - hierarchy_channel является 6-битовым полем, которое указывает намеченный номер канала для ассоциированного программного элемента в упорядоченном наборе каналов передачи. Самый надежный канал передачи задается посредством наименьшего значения этого поля относительно определения общей иерархии передачи.
Примечание. Данный hierarchy_channel может одновременно назначаться нескольким программным элементам.
[0148] Третий принцип проектирования заключается в том, что дескриптор расширения иерархий содержит общее проектное решение для передачи в служебных сигналах типов масштабируемости, аналогично VPS-расширению спецификаций MV-HEVC/SHVC-кодирования. Помимо этого, несколько зависимых элементарных потоков могут передаваться в служебных сигналах для текущего элементарного потока.
[0149] Четвертый принцип проектирования заключается в предложении дескриптора HEVC-расширения. Дескриптор HEVC-расширения может быть включен в качестве части HEVC-видеодескриптора, аналогично FDAM 3. Дескриптор HEVC-расширения передает в служебных сигналах рабочие точки, каждая из которых соответствует набору выходных слоев в MV-HEVC/SHVC. Набор выходных слоев является набором слоев потока битов, которые должны выводиться. Поток битов также может включать в себя опорные слои, которые видеодекодер не выводит, но которые используются посредством видеодекодера, чтобы декодировать набор выходных слоев. Состав рабочих точек основывается на дескрипторе расширения иерархий посредством указания слоев, которые принадлежат набору выходных слоев. Характеристики каждой рабочей точки, включающие в себя профиль, ярус и уровень, а также скорость передачи битов и частоту кадров, передаются в служебных сигналах в этом дескрипторе.
[0150] В общем, "профиль" может означать поднабор синтаксиса потока битов. "Ярусы" и "уровни" могут указываться в каждом профиле. Уровень яруса может представлять собой указанный набор ограничений, налагаемых на значения элементов синтаксиса в потоке битов. Эти ограничения могут представлять собой простые пределы для значений. Альтернативно, ограничения могут принимать форму ограничений на арифметические комбинации значений (например, ширина изображения, умноженная на высоту изображения, умноженную на число изображений, декодированных в секунду). Типично, уровень, указываемый для нижнего яруса, является более ограниченным по сравнению с уровнем, указываемым для верхнего яруса.
[0151] Ниже приводится синтаксис дескриптора HEVC-расширения, как описано в m31430. Параграфы после таблицы X предоставляют семантику дескриптора HEVC-расширения.
Дескриптор HEVC-расширения
descriptor_tag
descriptor_length
num_operation_points
for(i=0; i<num_operation_points; i++) {
profile_space
tier_flag
profile_idc
profile_compatibility_indication
progressive_source_flag
interlaced_source_flag
non_packed_constraint_flag
frame_only_constraint_flag
reserved_zero_44bits
level_idc
max_temporal_id
reserved_zero_5bits
for (j=0 ; j<64 ; j++)
hevc_output_layer_flag
average_bit_rate
maximum_bitrate
frame_rate
}
}
8
8
2
1
5
32
1
1
1
1
44
8
3
5
1
16
16
16
uimsbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
uimsbf
[0152] num_operation_points - 8-битовое поле указывает число указанных рабочих точек в этом дескрипторе.
[0153] profile_space - 2-битовое поле указывает контекст для интерпретации profile_idc для всех значений i в диапазоне от 0 до 31, включительно; profile_space не должны назначаться значения, отличные от значений, указываемых в приложении A или подразделе G.11 или в подразделе H.11 рекомендации ITU-T H.265 | ISO/IEC 23008-2. Другие значения profile_idc зарезервированы для будущего использования посредством ITU-T | ISO/IEC.
[0154] tier_flag - 1-битовое поле указывает контекст яруса для интерпретации level_idc, как указано в приложении A либо в подразделе G.11 или подразделе H.11 рекомендации ITU-T H.265 | ISO/IEC 23008-2.
[0155] profile_idc - 5-битовое поле, которое, когда profile_space равен 0, указывает профиль, которому соответствует CVS, как указано в приложении A или рекомендации ITU-T H.265 | ISO/IEC 23008-2; profile_idc не должны назначаться значения, отличные от значений, указываемых в приложении A либо в G.11 или H.11 рекомендации ITU-T H.265 | ISO/IEC 23008-2. Другие значения profile_idc зарезервированы для будущего использования посредством ITU-T | ISO/IEC.
[0156] Profile_compatibility_indication, progressive_source_flag, interlaced_source_flag, non_packed_constraint_flag, frame_only_constraint_flag, reserved_zero_44bits, level_idc - когда видеодескриптор HEVC-расширения применяется к видеопотоку HEVC-расширения, эти поля должны кодироваться согласно семантике, заданной в рекомендации ITU-T H.265 | ISO/IEC 23008-2 для general_profile_space, general_tier_flag, general_profile_idc, general_profile_compatibility_flag[i], general_progressive_source_flag, general_interlaced_source_flag, general_non_packed_constraint_flag, general_frame_only_constraint_flag, general_reserved_zero_44bits, general_level_idc, соответственно, для соответствующего HEVC-видеопотока или видеопотока HEVC-расширения или полного временного HEVC-представления, и весь HEVC-видеопоток или полное временное HEVC-представление, с которым ассоциирован HEVC-видеодескриптор, должно соответствовать информации, передаваемой в служебных сигналах посредством этих полей.
[0157] level_idc - 8-битовое поле указывает уровень, которому соответствует CVS, как указано в приложении A, G.11 или H.11 рекомендации ITU-T H.265 | ISO/IEC 23008-2; level_idc не должны назначаться значения level_idc, отличные от значений, указываемых в приложении A, G.11 или H.11 рекомендации ITU-T H.265 | ISO/IEC 23008-2. Другие значения level_idc зарезервированы для будущего использования посредством ITU-T | ISO/IEC.
[0158] max_temporal_id - 3-битовое поле указывает наибольший TemporalId NAL-единиц слоев в i-ой рабочей точке.
[0159] reserved_zero_5bits - 5-битовое поле, зарезервированное со значением 0.
[0160] hevc_output_layer_flag - 1-битовое поле, когда ему назначено значение 1, указывает то, что слой с nuh_layer_id, равным i, принадлежит набору выходных слоев и требуется для вывода, когда i-ая рабочая точка декодируется. Когда ему назначено значение 0, слой с nuh_layer_id, равным i, не принадлежит набору выходных слоев. Когда i-ый hevc_output_layer_flag равен 1, значение i-ого hevc_layer_present_flag должно быть равно 1.
[0161] average_bitrate - 16-битовое поле указывает среднюю скорость передачи битов, в Кбит в секунду, видеопотока HEVC-расширения, соответствующего i-ой рабочей точке.
[0162] maximum_bitrate - 16-битовое поле указывает максимальную скорость передачи битов, в Кбит в секунду, видеопотока HEVC-расширения, соответствующего i-ой рабочей точке.
[0163] frame_rate - 16-битовое поле указывает максимальную частоту кадров в кадрах/256 секунд видеопотока HEVC-расширения, соответствующего i-ой рабочей точке.
[0164] Во входном документе m31430 по MPEG, не предоставлено управление буфером изображений из нескольких элементарных потоков, как задано в транспортном MPEG-2-потоке или программном потоке. Например, входной документ m31430 по MPEG не описывает модели на основе декодера системных целевых объектов транспортного потока (T-STD) или модели на основе декодера системных целевых объектов программного потока для многослойного HEVC (например, для SHVC, MV-HEVC или 3D-HEVC). Как результат, существующие модели буферизации могут быть несовместимыми с многослойным HEVC.
[0165] Это раскрытие сущности предоставляет технологии для переноса потоков битов HEVC-расширения на основе входного документа m31430 по MPEG. Технологии этого раскрытия сущности могут использоваться отдельно или совместно друг с другом.
[0166] В соответствии с первой технологией этого раскрытия сущности, буферные SHVC-, MV-HEVC- и 3D-HEVC-модели (включающие в себя модели на основе декодера системных целевых объектов транспортного потока (T-STD) и модели на основе декодера системных целевых объектов программного потока (P-STD)) являются унифицированными в идентичной модели на основе слоев. Другими словами, одна T-STD-модель может применяться к SHVC, MV-HEVC и 3D-HEVC, и одна P-STD-модель может применяться к SHVC, MV-HEVC и 3D-HEVC. В одной альтернативе, такие модели могут проектироваться аналогичным T-STD-модели и P-STD-модели, что характерно для MVC для H.264.
[0167] Таким образом, видеодекодер 30 может собирать, в буферной модели (например, в P-STD-модели или T-STD-модели), единицу доступа из множества элементарных потоков для потока данных (т.е. транспортного потока или программного потока). Видеодекодер 30 использует идентичную буферную модель независимо от того, содержат либо нет элементарные потоки SHVC-, MV-HEVC- или 3D-HEVC-потоки битов. Затем, видеодекодер 30 может декодировать единицу доступа. Другими словами, видеодекодер 30 может декодировать кодированные изображения единицы доступа.
[0168] Как указано выше, транспортные потоки и программные потоки содержат соответствующую последовательность PES-пакетов. Каждый соответствующий PES-пакет транспортного потока или программного потока ассоциирован с элементарным потоком во множестве элементарных потоков. Таким образом, можно сказать, что транспортный поток или программный поток содержит множество элементарных потоков. Элементарные потоки могут включать в себя видеопотоки, аудиопотоки и частные потоки. В соответствии с одной или более технологий этого раскрытия сущности, каждый соответствующий временной подслой каждого соответствующего слоя потока битов может соответствовать различному элементарному потоку. Это может позволять мультимедийно-ориентированному сетевому элементу (MANE) или другому устройству избирательно перенаправлять PES-пакеты, ассоциированные с конкретными слоями и конкретными временными подслоями, без синтаксического анализа или интерпретации HEVC-данных в рабочих данных PES-пакетов. Наоборот, MANE или другое устройство может иметь возможность определять то, следует ли перенаправлять конкретные PES-пакеты, на основе данных в заголовках PES-пакетов и данных в различных дескрипторах (например, дескрипторах иерархий HEVC, дескрипторах HEVC-расширения и т.д.) в конкретной для программ информации транспортного потока или программного потока.
[0169] Целевой декодер (например, видеодекодер 30), возможно, должен повторно собирать единицы доступа потока битов до декодирования изображений единицы доступа. Другими словами, целевой декодер, возможно, должен обеспечивать то, что данные, требуемые для того, чтобы декодировать изображения единицы доступа, доступны во время декодирования для единицы доступа. Транспортные потоки предназначены для доставки программ по потенциально подверженным ошибкам каналам (например, по Интернету), в которых могут быть ошибки (например, потерянные PES-пакеты, дрожание, повреждение и т.д.) в транспортных пакетах. Следовательно, когда целевой декодер декодирует видео из транспортного потока, целевой декодер не может предполагать, что данные, требуемые для того, чтобы декодировать изображения единицы доступа, сразу доступны. Вместо этого, целевой декодер может реализовывать модель буферизации для каждой программы транспортного потока. Модель буферизации для транспортного потока может включать в себя соответствующий набор буферов для каждого соответствующего элементарного видеопотока (т.е. элементарного потока, содержащего видеопоток), ассоциированного с программой.
[0170] В соответствии с примером первой технологии этого раскрытия сущности, набор буферов для элементарного видеопотока n может включать в себя транспортный буфер TBn для элементарного видеопотока, буфер MBn мультиплексирования для элементарного видеопотока и буфер VSBn поднаборов изображений HEVC-слоев для элементарного видеопотока. по мере того как целевой декодер принимает PES-пакеты транспортного потока, целевой декодер демультиплексирует транспортный поток таким образом, что PES-пакеты транспортного потока, принадлежащие различным элементарным потокам, сохраняются в различных транспортных буферах. Другими словами, для каждого соответствующего элементарного потока, ассоциированного с программой, видеокодер может, для каждого соответствующего PES-пакета транспортного потока, принадлежащего соответствующему элементарному потоку, сохранять соответствующий PES-пакет в буфере (например, в транспортном буфере) для соответствующего элементарного потока. Таким образом, транспортный буфер TBn для элементарного потока n принимает транспортные пакеты, принадлежащие элементарному видеопотоку n.
[0171] Целевой декодер удаляет транспортные пакеты из транспортного буфера на скорости Rxn. Если отсутствуют данные в транспортном буфере TBn, скорость Rxn равна 0. В противном случае, если имеются данные в транспортном буфере TBn, скорость Rxn равна скорости передачи битов. Как описано в другом месте в этом раскрытии сущности, целевой декодер может определять скорость передачи битов на основе первого фактора (т.е. CpbBrNalFactor), второго фактора (т.е. CpbBrVclFactor) и третьего фактора (т.е. BitRate[SchedSelIdx]). Первый, второй и третий факторы задаются в рекомендации ITU-T H.265 | ISO/IEC 23008-2.
[0172] Когда целевой декодер удаляет транспортный пакет из транспортного буфера TBn для элементарного потока n, целевой декодер добавляет транспортный пакет в буфер MBn мультиплексирования для элементарного потока n. Целевой декодер удаляет данные из буфера MBn мультиплексирования по одному байту за раз. Когда целевой декодер удаляет байт из буфера MBn мультиплексирования, целевой декодер вставляет байт в буфер VSBn поднаборов изображений HEVC-слоев для элементарного потока n, если байт не является байтом заголовка PES-пакета (например, транспортного пакета).
[0173] Таким образом, для каждого соответствующего элементарного потока, ассоциированного с программой, целевой декодер может удалять PES-пакеты из транспортного буфера для соответствующего элементарного потока. Кроме того, целевой декодер может сохранять, в буфере мультиплексирования для соответствующего элементарного потока, PES-пакеты, удаленные из транспортного буфера для соответствующего элементарного потока. Целевой декодер может удалять байты из буфера мультиплексирования для соответствующего элементарного потока. Кроме того, целевой декодер может сохранять, в буфере поднаборов изображений HEVC-слоев для соответствующего элементарного потока, байты, удаленные из буфера мультиплексирования для соответствующего элементарного потока.
[0174] Таким образом, буфер VSBn поднаборов изображений HEVC-слоев принимает байты рабочих данных транспортных пакетов. Буфер VSBn поднаборов изображений HEVC-слоев может служить в качестве точки сборки для поднаборов изображений HEVC-слоев. При использовании в этом раскрытии сущности, поднабор изображений HEVC-слоев является набором изображений HEVC-слоев единицы доступа, ассоциированной с набором идентификаторов слоев (т.е. набором значений идентификаторов слоев). Изображение HEVC-слоя представляет собой кодированное изображение, как задано в приложении F рекомендации ITU-T H.265 | ISO/IEC 23008-2, с ограничениями, указываемыми в разделе 2.17.1 N13656 (приведено ниже).
[0175] Целевой декодер удаляет данные, соответствующие единице доступа, из буфера VSBn поднаборов изображений HEVC-слоев во время декодирования для единицы доступа. Например, чтобы декодировать изображения единицы AH(j) доступа, целевой декодер может удалять, из буфера изображений HEVC-слоев VSBn для элементарного потока n, поднабор VSn(jn) изображений HEVC-слоев, соответствующий времени tdn(jn) декодирования; tdn(jn) указывает время декодирования, измеренное в секундах, в целевом декодере поднабора VSn(jn) изображений HEVC-слоев для элементарного потока n; jn является индексом для набора идентификаторов слоев, задающего поднабор VSn(jn) изображений HEVC-слоев. Дополнительно, целевой декодер удаляет, из буферов VSBn+1 - VSBn+m изображений HEVC-слоев для элементарных потоков n+1 - n+m, поднаборы VSn+1(jn+1) -VSn+m(jn+m) изображений HEVC-слоев, причем времена декодирования для поднаборов VSn+1(jn+1) -VSn+m(jn+m) изображений HEVC-слоев (т.е. tdn+1(jn+1) -tdn+m(jn+m)) равны tdn(jn). Единица доступа может представлять собой комбинацию поднаборов HEVC-слоев, удаленных из VSBn - VSBn+m.
[0176] Таким образом, для каждого соответствующего элементарного потока, ассоциированного с программой, буферная модель содержит буфер (например, буфер изображений HEVC-слоев) для соответствующего элементарного потока. Единица доступа содержит соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока. Соответствующий поднабор изображений HEVC-слоев содержит изображения HEVC-слоев единицы доступа, которые ассоциированы с соответствующим набором идентификаторов слоев. Каждое из изображений HEVC-слоев представляет собой кодированное изображение, как задано в приложении F рекомендации ITU-T H.265 | ISO/IEC 23008-2. Для каждого соответствующего элементарного потока, ассоциированного с программой, целевой декодер может удалять соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока из буфера для соответствующего элементарного потока. Целевой декодер может включать соответствующий поднабор изображений HEVC-слоев в единицу доступа.
[0177] Модель буферизации для программного потока (т.е. P-STD-модель) может быть проще модели буферизации для транспортного потока (т.е. T-STD-модели), поскольку целевой декодер может предполагать, что PES-пакеты в программном потоке доступны без ошибок (например, дрожания, потерь и т.д.), ассоциированных с транспортными потоками. В соответствии с одной или более технологий этого раскрытия сущности, каждый соответствующий временной подслой каждого соответствующего слоя потока битов может соответствовать различному элементарному потоку программного потока. Кроме того, P-STD-модель может включать в себя буфер поднаборов изображений HEVC-слоев для каждого соответствующего элементарного потока программного потока. Когда целевой декодер принимает PES-пакеты программного потока, целевой декодер демультиплексирует программный поток таким образом, что PES-пакеты, принадлежащие различным элементарным потокам, сохраняются в различных буферах поднаборов изображений HEVC-слоев. Целевой декодер может удалять данные, соответствующие единице доступа, из буферов поднаборов изображений HEVC-слоев, идентично вышеописанному относительно транспортных потоков.
[0178] В некоторых примерах, целевой декодер использует различные буферные модели, в зависимости от контента принимаемых транспортных потоков или программных потоков. Например, в ответ на определение того, что имеется набор HEVC-слоев в программе, и того, что имеется, по меньшей мере, один многослойный HEVC-субпоток видеобитов во множестве элементарных потоков, который представляет собой видеопоток HEVC-расширения, соответствующий одному или более профилей, как задано в приложении G или приложении H рекомендации ITU-T H.265 | ISO/IEC 23008-2, целевой декодер может выбирать буферную модель, описанную относительно первой технологии этого раскрытия сущности, которую следует использовать при сборке единицы доступа.
[0179] В соответствии со второй примерной технологией этого раскрытия сущности, каждый многослойный HEVC-видеопоток может иметь T-STD-модель и/или P-STD-модель. Многослойный HEVC-субпоток видеобитов может собираться из одного или более многослойных HEVC-видеосубпотоков и представляться в дескрипторе HEVC-расширения в качестве рабочей точки. Другими словами, многослойный HEVC-видеопоток соответствует рабочей точке и собирается из многослойных HEVC-субпотоков видеобитов. Многослойный HEVC-субпоток видеобитов содержит несколько субпотоков видеобитов HEVC-слоя, которые содержат VCL NAL-единицы с идентичным значением nuh_layer_id (идентификатором слоя) и их ассоциированные не-VCL NAL-единицы. Например, многослойный HEVC-субпоток видеобитов может задаваться в качестве всех VCL NAL-единиц с nuh_layer_id, принадлежащим набору HEVC-слоев видеопотока HEVC-расширения, и ассоциированных не-VCL NAL-единиц, которые соответствуют одному или более профилей, заданных в приложении F или приложении G рекомендации ITU-T H.265 | ISO/IEC 23008-2. T-STD и P-STD могут работать способом, описанным выше и в другом месте в этом раскрытии сущности. Таким образом, в некоторых примерах, видеодекодер 30 может собирать единицы доступа с использованием отдельных экземпляров буферной модели для каждого соответствующего многослойного HEVC-видеопотока для потока видеоданных. В таких примерах, каждый соответствующий многослойный HEVC-видеопоток содержит множество субпотоков видеобитов HEVC-слоя, и каждый соответствующий субпоток видеобитов HEVC-слоя из множества субпотоков видеобитов HEVC-слоя содержит VCL NAL-единицы с идентичным значением идентификатора слоя.
[0180] Как указано выше, дескриптор расширения иерархий представляет собой дескриптор, который предоставляет информацию для того, чтобы идентифицировать программные элементы, содержащие компоненты иерархически кодированных видео-, аудио- и частных потоков. Другими словами, дескриптор расширения иерархий предоставляет информацию относительно программного элемента, соответствующего дескриптору расширения иерархий. Дескриптор расширения иерархий может включать в себя поле hierarchy_ext_embedded_layer_index для каждого прямого зависимого программного элемента, который должен быть доступным и присутствовать в порядке декодирования до декодирования элементарного потока, ассоциированного с дескриптором расширения иерархий. Другими словами, дескриптор расширения иерархий может включать в себя множество полей hierarchy_ext_embedded_layer_index. Каждое соответствующее поле hierarchy_ext_embedded_layer_index дескриптора расширения иерархий идентифицирует соответствующий прямой зависимый программный элемент для соответствующего программного элемента (т.е. программного элемента, соответствующего дескриптору расширения иерархий). Соответствующий прямой зависимый программный элемент для соответствующего программного элемента представляет собой программный элемент, который должен быть доступным для целевого декодера до того, как целевой декодер может декодировать соответствующий программный элемент. Например, соответствующий программный элемент может включать в себя данные для небазового слоя, и соответствующий прямой зависимый программный элемент может включать в себя данные для базового слоя. Поскольку соответствующие программные элементы могут соответствовать соответствующим слоям, каждый соответствующий hierarchy_ext_embedded_layer_index дескриптора расширения иерархий может идентифицировать соответствующий опорный слой, требуемый для декодирования слоя, соответствующего дескриптору расширения иерархий. Таким образом, при сборке единицы доступа, целевой декодер может идентифицировать, на основе одного или более полей в дескрипторе, соответствующем выходному слою текущей рабочей точки, опорные слои, требуемые для того, чтобы декодировать выходной слой текущей рабочей точки.
[0181] В соответствии с третьей технологией этого раскрытия сущности, при сборке изображений HEVC-слоев в единице доступа из нескольких потоков в T-STD- или P-STD-модели, значения hierarchy_ext_embedded_layer_index, указываемые в ассоциированном дескрипторе расширения иерархий, используются для того, чтобы идентифицировать опорные слои, требуемые для декодирования выходных слоев текущей рабочей точки. Например, при повторной сборке j-ой единицы AH(j) доступа, целевой декодер может собирать поднаборы изображений HEVC-слоев из буферов поднаборов изображений HEVC-слоев для каждого программного элемента программы в транспортном потоке или программном потоке. Целевой декодер собирает поднаборы изображений HEVC-слоев таким образом, что применяется следующее:
- Значение y указывает идентификатор слоя. Значение y является большим или равным 0.
- Поднабор VSy+1(jy+1) изображений HEVC-слоев соответствует программному элементу для слоя y+1. Поскольку y≥0, слой с идентификатором слоя y+1 является небазовым слоем.
- tdy+1(jy+1) обозначает значение временной метки декодирования (DTS) для VSy+1(jy+1).
- Дескриптор расширения иерархий соответствует программному элементу для слоя y+1 (т.е. соответствующему программному элементу).
- Дескриптор расширения иерархий включает в себя нуль или более полей hierarchy_ext_embedded_layer_index.
Для каждого соответствующего поля hierarchy_ext_embedded_layer_index:
-- Соответствующее поле hierarchy_ext_embedded_layer_index имеет соответствующее значение, идентифицирующее соответствующий прямой зависимый программный элемент для надлежащего программного элемента.
-- VSy(jy) является поднабором изображений HEVC-слоев, соответствующим надлежащему прямому зависимому программному элементу.
-- tdy(jy) является DTS-значением для VSy(jy).
-- tdy(jy) равно tdy+1(jy+1).
[0182] В соответствии с четвертой технологией этого раскрытия сущности, HEVC-синхронизация и HRD-дескриптор, аналогично текущим HEVC MPEG-2-системам, могут присутствовать для каждой рабочей точки. Другими словами, для каждой соответствующей рабочей точки, могут присутствовать соответствующая HEVC-синхронизация и HRD-дескриптор. HEVC-синхронизация и HRD-дескриптор предоставляют синхронизацию и HRD-параметры, как задано в приложении C рекомендации ITU-T H.265 | ISO/IEC 23008-2, для ассоциированного HEVC-видеопотока либо его HEVC-представления наивысшего временного подслоя, соответственно. Примерный синтаксис HEVC-синхронизации и HRD-дескриптора предоставляется в нижеприведенном разделе 2.6.95.
[0183] В одном примере четвертой технологии этого раскрытия сущности, в HEVC_extension_descriptor, в цикле каждой рабочей точки, могут присутствовать HEVC-синхронизация и HRD-дескриптор. Как показано выше, дескриптор HEVC-расширения включает в себя цикл (т.е. "for (i=0; i<num_operation_points; i++){... }"), в котором каждая соответствующая итерация цикла соответствует последовательности элементов для соответствующей рабочей точки (например, profile_space, tier_flag, profile_idc и т.д.). В этом примере, элементы для соответствующей рабочей точки дополнительно включают в себя HEVC-синхронизацию и HRD-дескриптор.
[0184] В другом примере четвертой технологии этого раскрытия сущности, HEVC-синхронизация и HRD-дескриптор присутствуют только один раз для рабочих точек, совместно использующих идентичный набор идентификаторов слоев для слоев, которые должны быть декодированы. В другом примере, HEVC-синхронизация и HRD-дескриптор присутствуют только один раз для всех рабочих точек всех наборов выходных слоев.
[0185] Пятая технология этого раскрытия сущности заключает в себе NAL-единицу разделителя изображений слоя. NAL-единица разделителя изображений слоя может содержать синтаксическую структуру, идентичную синтаксической структуре заголовка NAL-единицы в HEVC, и может иметь следующие элементы синтаксиса: forbidden_zero_bit, nal_unit_type, nuh_layer_id и nuh_temporal_id_plus1. Элемент forbidden_zero_bit синтаксиса является 1-битовым элементом синтаксиса, который всегда равен 0. Элемент nal_unit_type синтаксиса указывает тип структуры RBSP-данных, содержащейся в NAL-единице. Элемент nuh_layer_id синтаксиса указывает идентификатор слоя, которому принадлежит NAL-единица. NAL-единицы, которые имеют элементы nuh_layer_id синтаксиса, которые указывают различные значения, принадлежат различным слоям потока битов. Элемент nuh_temporal_id_plus1 синтаксиса, минус 1, указывает временной идентификатор для NAL-единицы.
[0186] В соответствии с некоторыми примерами пятой технологии этого раскрытия сущности, элемент nal_unit_type синтаксиса NAL-единицы разделителя изображений слоя задается равным 0x30 (т.е. 48). В других примерах, элемент nal_unit_type синтаксиса NAL-единицы разделителя изображений слоя имеет значение в диапазоне 0x30-0x3F, включительно (т.е. 48-63, включительно). HEVC-спецификация помечает значения в диапазоне 0x30-0x3F как "неуказанные".
[0187] В соответствии с некоторыми примерами пятой технологии этого раскрытия сущности, элементы nuh_layer_id и nuh_temporal_id_plus1 синтаксиса в NAL-единице разделителя изображений слоя задаются как элементы nuh_layer_id и nuh_temporal_id_plus1 синтаксиса изображения, ассоциированного с VCL NAL-единицами, которые идут сразу после NAL-единицы разделителя изображений слоя. В каждом элементарном потоке с stream_type, равным 0x26 (т.е. элементарном потоке, содержащем видеопоток HEVC-расширения, соответствующий одному или более профилей, как задано в приложении G или приложении H рекомендации ITU-T H.264 | ISO/IEC 23008), точно один LPD_nal_unit (т.е. NAL-единица разделителя представлений слоев) может предшествовать всем NAL-единицам со значениями nuh_layer_id и nuh_temporal_id_plus1, равными значениям LPD_nal_unit. В других примерах, значения элементов nuh_layer_id и nuh_temporal_id_plus1 синтаксиса в NAL-единице разделителя изображений слоя задаются фиксированно равными 0 и 0. Кроме того, в некоторых примерах, элемент nuh_temporal_id_plus1 синтаксиса NAL-единицы разделителя изображений слоя задается равным 0, чтобы указывать то, что NAL-единица разделителя изображений слоя является NAL-единицей разделителя изображений слоя. В некоторых примерах, в каждом элементарном потоке с stream_type, равным 0x26, точно один LPD_nal_unit может предшествовать всем NAL-единицам со значением nuh_layer_id, равным значению LPD_nal_unit. В некоторых примерах, в каждом элементарном потоке с stream_type, равным 0x26, точно один LPD_nal_unit может предшествовать всем NAL-единицам со значением, принадлежащим набору идентификаторов HEVC-слоев, минимальное значение которого равно nuh_layer_id LPD_nal_unit.
[0188] Текст рабочего проекта предлагаемого решения изложен в этом раскрытии сущности в качестве примера в конце этого подробного описания (и озаглавлен "ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ - ОБЩЕЕ КОДИРОВАНИЕ ДВИЖУЩИХСЯ ИЗОБРАЖЕНИЙ И АССОЦИИРОВАННОЙ АУДИОИНФОРМАЦИИ: СИСТЕМЫ, Изменение 3, Транспортировка HEVC-видео по MPEG-2-системам"). Новый добавленный текст указывается полужирным курсивом. Для подраздела, который является абсолютно новым, только заголовок подраздела может указываться полужирным курсивом. Реализация текста спецификации основана на выходном документе N13656 по MPEG, который содержит транспортировку только HEVC-видео, но не многослойного HEVC-видео, к примеру, MV-HEVC, SHVC или 3D-HEVC. Следующий текст ссылается на фиг. X-1, X-2, 2-15 и X-4. Фиг. X-1 представлен в качестве фиг. 2 этого раскрытия сущности. Таким образом, фиг. 2 является концептуальной схемой, иллюстрирующей примерные расширения T-STD-модели для однослойного HEVC. Фиг. X-2 представлен в качестве фиг. 3 этого раскрытия сущности. Таким образом, фиг. 3 является концептуальной схемой, иллюстрирующей примерные расширения T-STD-модели для многослойной транспортировки временных HEVC-видеоподнаборов в соответствии с одной или более технологий этого раскрытия сущности. Фиг. 2-15 представлен в качестве фиг. 4 этого раскрытия сущности. Таким образом, фиг. 4 является концептуальной схемой, иллюстрирующей примерное расширение T-STD-модели для видео согласно рекомендации ITU-T H.265 | ISO/IEC 23008-2 с многослойными HEVC-субпотоками видеобитов, в соответствии с одной или более технологий этого раскрытия сущности. Фиг. X-4 представлен в качестве фиг. 5 этого раскрытия сущности. Таким образом, фиг. 5 является концептуальной схемой, иллюстрирующей примерные расширения P-STD-модели для видео согласно рекомендации ITU-T H.265 | ISO/IEC 23008-2 с многослойными HEVC-субпотоками видеобитов, в соответствии с одной или более технологий этого раскрытия сущности.
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ - ОБЩЕЕ КОДИРОВАНИЕ ДВИЖУЩИХСЯ ИЗОБРАЖЕНИЙ И АССОЦИИРОВАННОЙ АУДИОИНФОРМАЦИИ: СИСТЕМЫ
ИЗМЕНЕНИЕ 3
Транспортировка HEVC-видео по MPEG-2-системам
Раздел 1.2.2
Добавить следующие ссылки:
- Рекомендация ITU-T H.265, Стандарт высокоэффективного кодирования видео
- ISO/IEC 23008-2, Информационные технологии - Высокоэффективное кодирование и доставка мультимедиа в гетерогенных окружениях - Часть 2: Стандарт высокоэффективного кодирования видео
Раздел 2.1.95-2.1.109
Добавить следующие определения после 2.1.94:
2.1.95. HEVC-видеопоток: Поток байтов, как указано в приложении B, приложении F или приложении G рекомендации ITU-T H.265 | ISO/IEC 23008-2. Он является объединенным термином многослойного HEVC-видеопотока или субпотока видеобитов базового HEVC-слоя.
2.1.96. HEVC-единица доступа: Единица доступа, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2 с ограничениями, указываемыми в разделе 2.17.1.
2.1.97. 24-часовое HEVC-изображение (система): HEVC-единица доступа со временем представления, которое превышает 24 часа в будущем. В целях этого определения, HEVC-единица n доступа имеет время представления, которое превышает 24 часа в будущем, если разность между начальным временем tai(n) поступления и временем to,dpb(n) DPB-вывода превышает 24 часа.
2.1.98. HEVC-серия последовательных макроблоков: Независимый сегмент HEVC-серий последовательных макроблоков и нуль или более последующих зависимых сегментов HEVC-серий последовательных макроблоков, предшествующих следующему независимому сегменту HEVC-серий последовательных макроблоков (если таковые имеются) в идентичной HEVC-единице доступа.
2.1.99. Сегмент HEVC-серии последовательных макроблоков: Byte_stream_nal_unit с nal_unit_type в диапазоне 0-9 и 16-23, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2.
2.1.100. Зависимый сегмент HEVC-серий последовательных макроблоков: Сегмент HEVC-серии последовательных макроблоков с элементом синтаксиса dependent_slice_segment_flag в заголовке серии последовательных макроблоков, заданным равным значению в 1, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2.
2.1.101. Независимый сегмент HEVC-серий последовательных макроблоков: Сегмент HEVC-серии последовательных макроблоков с элементом синтаксиса dependent_slice_segment_flag в заголовке серии последовательных макроблоков, заданным равным значению 0 или логически выведенным как равным 0, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2.
2.1.102. Мозаичный HEVC-фрагмент серий последовательных макроблоков: Одна или более последовательных HEVC-серий последовательных макроблоков, которые формируют кодированное представление мозаичного фрагмента, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2.
2.1.103. Неподвижное HEVC-изображение (система): Неподвижное HEVC-изображение состоит из HEVC-единицы доступа, содержащей IDR-изображение, которой предшествуют VPS, SPS и PPS NAL-единицы, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, которые переносят достаточную информацию для того, чтобы корректно декодировать это IDR-изображение. В качестве предшествующего неподвижному HEVC-изображению, должно быть другое неподвижное HEVC-изображение или NAL-единица конца последовательности, завершающая предыдущую кодированную видеопоследовательность, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2.
2.1.104. HEVC-видеопоследовательность (система): кодированная видеопоследовательность, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2.
2.1.105. HEVC-субпоток видеобитов: Поднабор NAL-единиц HEVC-видеопотока в исходном порядке.
2.1.106. Временной HEVC-субпоток видеобитов: HEVC-субпоток видеобитов, который содержит все VCL NAL-единицы и ассоциированные не-VCL NAL-единицы временного подслоя, как указано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, ассоциированной с TemporalId, равным 0, и который дополнительно может содержать все VCL NAL-единицы и ассоциированные не-VCL NAL-единицы всех временных подслоев, ассоциированных с непрерывным диапазоном TemporalId от 1 до значения, равного или меньшего sps_max_sub_layers_minus1, включенного в активный набор параметров последовательности, как указано в рекомендации ITU-T H.265 | ISO/IEC 23008-2.
2.1.107. Временной HEVC-видеоподнабор: HEVC-субпоток видеобитов, который содержит все VCL NAL-единицы и ассоциированные не-VCL NAL-единицы одного или более временных подслоев, как указано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, причем каждый временной подслой не присутствует в соответствующем временном HEVC-субпотоке видеобитов, и TemporalId, ассоциированный с каждым временным подслоем, формирует непрерывный диапазон значений.
Примечание X1. Согласно ограничениям для транспортировки HEVC, указываемым в 2.17.1, каждый временной подслой HEVC-видеопотока присутствует либо во временном HEVC-субпотоке видеобитов, либо точно в одном временном HEVC-видеоподнаборе, которые переносятся в наборе элементарных потоков, которые ассоциированы посредством дескрипторов иерархий. Это предотвращает нескольких включение идентичного временного подслоя и дает возможность агрегирования временного HEVC-субпотока видеобитов с ассоциированными временными HEVC-видеоподнаборами согласно дескрипторам иерархий, как указано в 2.17.3.
2.1.108. HEVC-представление наивысшего временного подслоя: Представление подслоя временного подслоя с наибольшим значением TemporalId, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, в ассоциированном временном HEVC-субпотоке видеобитов или временном HEVC-видеоподнаборе.
2.1.109. Полное временное HEVC-представление: Представление подслоя, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, которое содержит все временные подслои вплоть до временного подслоя с TemporalId, равным sps_max_sub_layers_minus1+1, включенным в активный набор параметров последовательности, как указано в рекомендации ITU-T H.265 | ISO/IEC 23008-2.
[Ed. (CY): новые введенные определения должны быть переупорядочены.] 2.1.110. Изображение HEVC-слоя: Кодированное изображение, как задано в приложении F рекомендации ITU-T H.265 | ISO/IEC 23008-2, с ограничениями, указываемыми в разделе 2.17.1. Изображение HEVC-слоя ассоциировано с конкретным nuh_layer_id.
2.1.111. Поднабор изображений HEVC-слоев: Изображения HEVC-слоев единицы доступа, ассоциированной с набором идентификаторов слоев.
2.1.112. Видеопоток HEVC-расширения: Поток видеобитов, который соответствует одному или более профилей, заданных в рекомендации ITU-T H.265 | ISO/IEC 23008-2 G.11 или H.11. [Ed (CY): может быть заменен HEVC-видеопотоком или многослойным HEVC-видеопотоком].
2.1.113. HEVC-видеопоследовательность (система): кодированная видеопоследовательность, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2.
2.1.114. Базовый HEVC-слой: Слой с nuh_layer_id, равным 0 в видеопотоке HEVC-расширения.
2.1.115. Субпоток видеобитов базового HEVC-слоя: Субпоток видеобитов, который содержит все VCL и не-VCL NAL-единицы с nuh_layer_id, равным 0.
2.1.116. HEVC-слой: Слой видеопотока HEVC-расширения, включающего в себя все VCL NAL-единицы с конкретным значением nuh_layer_id и ассоциированные не-VCL NAL-единицы, как задано в приложении F приложения F рекомендации ITU-T H.265 | ISO/IEC 23008-2 в элементе синтаксиса заголовка NAL-единицы.
2.1.117. Набор идентификаторов HEVC-слоев: Набор значений nuh_layer_id.
2.1.118. Набор HEVC-слоев: Субпоток видеобитов, который содержит HEVC-слои со значениями nuh_layer_id, формирующими набор идентификаторов HEVC-слоев.
2.1.119. Многослойный HEVC-видеопоток: Многослойный HEVC-субпоток видеобитов, который, возможно, собран из одного или более многослойных HEVC-видеосубпотоков и представлен в дескрипторе HEVC-расширения в качестве рабочей точки.
2.1.120. Многослойный HEVC-субпоток видеобитов: Многослойный HEVC-субпоток видеобитов задается в качестве всех VCL NAL-единиц с nuh_layer_id, принадлежащим набору HEVC-слоев видеопотока HEVC-расширения, и ассоциированных не-VCL NAL-единиц, которые соответствуют одному или более профилей, заданных в приложении F (или приложении G) рекомендации ITU-T H.265 | ISO/IEC 23008-2.
2.1.121. Рабочая точка: Рабочая точка идентифицируется посредством значения temporal_id, представляющего целевой временной уровень, и набора значений nuh_layer_id, представляющих целевые выходные слои. Одна рабочая точка ассоциирована с многослойным HEVC-видеопотоком или субпотоком видеобитов базового HEVC-слоя, который соответствует одному или более профилей, заданных в приложении E или приложении G (приложении H) рекомендации ITU-T H.265 | ISO/IEC 23008-2.
Раздел 2.4.2.6
Заменить следующие 2 параграфа:
Заменить:
Задержка любых данных через буферы декодера системных целевых объектов должна быть меньше или равна одной секунде за исключением видеоданных неподвижных изображений и ISO/IEC 14496-потоков. В частности: tdn(j)-t(i)≤1 секунда для всех j и всех байтов i в единице An(j) доступа.
на:
Задержка любых данных через буферы декодера системных целевых объектов должна быть меньше или равна одной секунде за исключением видеоданных неподвижных изображений, ISO/IEC 14496- и ISO/IEC 23008-2-потоков. В частности: tdn(j)-t(i)≤1 секунда для всех j и всех байтов i в единице An(j) доступа.
Заменить:
Для ISO/IEC 14496-потоков задержка ограничивается посредством tdn(j)-t(i)≤10 секунд для всех j и всех байтов i в единице An(j) доступа.
на:
Для ISO/IEC 14496- и ISO/IEC 23008-2-потоков, задержка ограничивается посредством tdn(j)-t(i)≤10 секунд для всех j и всех байтов i в единице An(j) доступа.
Раздел 2.4.2.11
Добавить следующее сразу после 2.4.2.10 в качестве нового подраздела:
2.4.2.11. T-STD-расширения для переноса HEVC:
T-STD-расширения и T-STD-параметры для декодирования HEVC-видеопотоков задаются в 2.17.2 и 2.17.3. Поддержка программных потоков, включающих в себя P-STD-расширения и P-STD-параметры, не указывается для HEVC-видеопотоков.
Раздел 2.4.3.5
В разделе, указывающем discontinuity_indicator, добавить в конце маркированного списка с введением "В целях этого раздела, точка доступа элементарного потока задается следующим образом":
- HEVC-видеопотоки или временные HEVC-субпотоки видеобитов - первый байт HEVC-единицы доступа. Наборы VPS-, SPS- и PPS-параметров, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, упоминаемые в этой и во всех последующих HEVC-единицах доступа в HEVC-видеопоследовательности, должны предоставляться после этой точки доступа в потоке байтов и до их активации.
В разделе, указывающем elementary_stream_priority_indicator, добавить:
В случае HEVC-видеопотоков или временных HEVC-субпотоков видеобитов, или временных HEVC-видеоподнаборов, это поле может задаваться равным 1, только если рабочие данные содержат один или более байтов из серии последовательных макроблоков с slice_type, заданным равным 2. Значение 0 указывает то, что рабочие данные имеют приоритет, идентичный приоритету всех других пакетов, которые не имеют этого бита, заданного равным 1.
Раздел 2.4.3.7
В таблице 2-22. "Назначения Stream_id", заменить следующую строку:
на:
В разделе, указывающем PTS (временную метку представления), добавить:
Для HEVC-видеопотоков, временных HEVC-субпотоков видеобитов и временных HEVC-видеоподнаборов, если PTS присутствует в заголовке PES-пакета, он должен означать первую HEVC-единицу доступа, которая начинается в этом PES-пакете. Чтобы достигать согласованности между STD-моделью и HRD-моделью, заданной в приложении C рекомендации ITU-T H.265 | ISO/IEC 23008-2, для каждой HEVC-единицы доступа, PTS-значение в STD, в пределах точности соответствующих синхросигналов, должно указывать идентичный момент во времени с номинальным временем DPB-вывода в HRD, как задано в приложении C рекомендации ITU-T H.265 | ISO/IEC 23008-2.
В разделе, указывающем DTS(временная метка декодирования), добавить:
Для HEVC-видеопотоков, временных HEVC-субпотоков видеобитов и временных HEVC-видеоподнаборов, если DTS присутствует в заголовке PES-пакета, она должна означать первую HEVC-единицу доступа, которая начинается в этом PES-пакете. Чтобы достигать согласованности между STD-моделью и HRD-моделью, заданной в приложении C рекомендации ITU-T H.265 | ISO/IEC 23008-2, для каждой HEVC-единицы доступа, DTS-значение в STD, в пределах точности соответствующих синхросигналов, должно указывать идентичный момент во времени с номинальным временем tr удаления из CPB в HRD, как задано в приложении C рекомендации ITU-T H.265 | ISO/IEC 23008-2.
Раздел 2.4.4.9
В таблице 2-34. "Назначения типов потоков", заменить следующую строку:
на:
Раздел 2.6.1
Заменить таблицу 2-45 на:
Программа и дескрипторы программных элементов
Раздел 2.6.6
Заменить в таблице 2-50 описание для значения 15:
Значения полей hierarchy_type
Раздел 2.6.11
Добавить следующее сразу после таблицы 2-54:
Таблица 2-xx описывает тип совмещения для HEVC, когда data_alignment_indicator в заголовке PES-пакета имеет значение 1.
Значения совмещения HEVC-видеопотоков
Раздел 2.6.88
Заменить таблицу AMD8-1 на:
Дескриптор расширения
Зарезервировано
}
Раздел 2.6.89
Добавить следующее непосредственно перед таблицей AMD8-2:
HEVC_timing_and_HRD_descriptor - эта структура задается в 2.6.95 и 2.6.96.
Заменить таблицу AMD8-2 на:
Значения тега дескриптора расширения
Раздел 2.6.93-2.6.96
Добавить следующее сразу после раздела 2.6.92 в качестве новых подразделов:
2.6.93. HEVC-видеодескриптор
Для HEVC-видеопотока, HEVC-видеодескриптор предоставляет базовую информацию для идентификации параметров кодирования, к примеру, параметров профиля и уровня, этого HEVC-видеопотока. Для временного HEVC-субпотока видеобитов или временного HEVC-видеоподнабора, HEVC-видеодескриптор предоставляет такую информацию, как ассоциированное HEVC-представление наивысшего временного подслоя, содержащееся в элементарном потоке, к которому оно применяется.
HEVC-видеодескриптор
descriptor_tag
descriptor_length
profile_space
tier_flag
profile_idc
profile_compatibility_indication
progressive_source_flag
interlaced_source_flag
non_packed_constraint_flag
frame_only_constraint_flag
reserved_zero_44bits
level_idc
temporal_layer_subset_flag
HEVC_still_present_flag
HEVC_24hr_picture_present_flag
hevc_extension_present_flag
Зарезервировано
if (temporal_layer_subset_flag==1){
Зарезервировано
temporal_id_min
Зарезервировано
temporal_id_max
}
if (hevc_extension_present_flag)
HEVC_extension_descripor
}
8
2
1
5
32
1
1
1
1
44
8
1
1
1
1
4
5
3
5
3
uimsbf
uimsbf
bslbf
uimsbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
uimsbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
uimsbf
bslbf
uimsbf
2.6.94. Семантическое определение полей в HEVC-видеодескрипторе
Profile_space, tier_flag, profile_idc, profile_compatibility_indication, progressive_source_flag, interlaced_source_flag, non_packed_constraint_flag, frame_only_constraint_flag, reserved_zero_44bits, level_idc - когда HEVC-видеодескриптор должен применяться к HEVC-видеопотоку или к полному временному HEVC-представлению, эти поля должны кодироваться согласно семантике, заданной в рекомендации ITU-T H.265 | ISO/IEC 23008-2 для general_profile_space, general_tier_flag, general_profile_idc, general_profile_compatibility_flag[i], general_progressive_source_flag, general_interlaced_source_flag, general_non_packed_constraint_flag, general_frame_only_constraint_flag, general_reserved_zero_44bits, general_level_idc, соответственно, для соответствующего HEVC-видеопотока или полного временного HEVC-представления, и весь HEVC-видеопоток или полное временное HEVC-представление, с которым ассоциирован HEVC-видеодескриптор, должно соответствовать информации, передаваемой в служебных сигналах посредством этих полей.
Когда HEVC-видеодескриптор должен применяться к временному HEVC-субпотоку видеобитов или к временному HEVC-видеоподнабору, соответствующее HEVC-представление наивысшего временного подслоя которого не является полным временным HEVC-представлением, эти поля должны кодироваться согласно семантике, заданной в рекомендации ITU-T H.265 | ISO/IEC 23008-2 для sub_layer_profile_space, sub_layer_tier_flag, sub_layer_profile_idc, sub_layer_profile_compatibility_flag[i], sub_layer_progressive_source_flag, sub_layer_interlaced_source_flag, sub_layer_non_packed_constraint_flag, sub_layer_frame_only_constraint_flag, sub_layer_reserved_zero_44bits, sub_layer_level_idc, соответственно, для соответствующего HEVC-представления наивысшего временного подслоя, и все HEVC-представление наивысшего временного подслоя, с которым ассоциирован HEVC-видеодескриптор, должно соответствовать информации, передаваемой в служебных сигналах посредством этих полей.
Примечание X2. В одной или более последовательностей в HEVC-видеопотоке, уровень может быть ниже уровня, передаваемого в служебных сигналах в HEVC-видеодескрипторе, в то время как также может возникать профиль, который является поднабором профиля, передаваемого в служебных сигналах в HEVC-видеодескрипторе. Тем не менее, во всем HEVC-видеопотоке, должны использоваться только поднаборы всего синтаксиса потока битов, которые включены в профиль, передаваемый в служебных сигналах в HEVC-видеодескрипторе, если присутствует. Если наборы параметров последовательности в HEVC-видеопотоке передают в служебных сигналах различные профили, и дополнительные ограничения не передаются в служебных сигналах, то потоку, возможно, требуется анализ для того, чтобы определять то, какому профилю, если таковые имеются, соответствует весь поток. Если HEVC-видеодескриптор должен быть ассоциирован с HEVC-видеопотоком, который не соответствует одному профилю, то HEVC-видеопоток должен быть сегментирован на два или более субпотоков, так что HEVC-видеодескрипторы могут передавать в служебных сигналах один профиль для каждого такого субпотока.
temporal_layer_subset_flag - этот однобитовый флаг, когда задан равным 1, указывает то, что элементы синтаксиса, описывающие поднабор временных слоев, включены в этот дескриптор. Это поле должно задаваться равным 1 для временных HEVC-видеоподнаборов и для временных HEVC-субпотоков видеобитов. Когда задан равным 0, элементы temporal_id_min и temporal_id_max синтаксиса не включены в этот дескриптор.
HEVC_still_present_flag - это 1-битовое поле, когда задано равным 1, указывает то, что HEVC-видеопоток или HEVC-представление наивысшего временного подслоя может включать в себя неподвижные HEVC-изображения. Когда задано равным 0, то ассоциированный HEVC-видеопоток не должен содержать неподвижные HEVC-изображения.
Примечание X3. Согласно рекомендации ITU-T H.265 | ISO/IEC 23008-2, IDR-изображения всегда ассоциированы со значением TemporalId, равным 0, Следовательно, если HEVC-видеодескриптор применяется к временному HEVC-видеоподнабору, неподвижные HEVC-изображения могут присутствовать только в ассоциированном временном HEVC-субпотоке видеобитов.
HEVC_24_hour_picture_present_flag - этот однобитовый флаг, когда задан равным 1, указывает то, что ассоциированный HEVC-видеопоток или HEVC-представление наивысшего временного подслоя может содержать 24-часовые HEVC-изображения. Для получения информации по определению 24-часового HEVC-изображения следует обратиться к 2.1.97. Если этот флаг задается равным 0, то ассоциированный HEVC-видеопоток не должен содержать 24-часовое HEVC-изображение.
temporal_id_min - это 3-битовое поле указывает минимальное значение TemporalId, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, всех HEVC-единиц доступа в ассоциированном элементарном потоке.
temporal_id_max - это 3-битовое поле указывает максимальное значение TemporalId, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, всех HEVC-единиц доступа в ассоциированном элементарном потоке.
hevc_extension_present_flag - этот однобитовый флаг, когда задан равным 1, указывает то, что дескриптор HEVC-расширения присутствует в качестве части HEVC-видеодескриптора. Когда задан равным 0, дескриптор HEVC-расширения не присутствует.
2.6.95. HEVC-синхронизация и HRD-дескриптор
Для HEVC-видеопотока, временного HEVC-субпотока видеобитов или временного HEVC-видеоподнабора, HEVC-синхронизация и HRD-дескриптор предоставляет синхронизацию и HRD-параметры, как задано в приложении C рекомендации ITU-T H.265 | ISO/IEC 23008-2, для ассоциированного HEVC-видеопотока либо его HEVC-представления наивысшего временного подслоя, соответственно.
HEVC-синхронизация и HRD-дескриптор
hrd_management_valid_flag
Зарезервировано
picture_and_timing_info_present_flag
if (picture_and_timing_info_present_flag==1){
90kHz_flag
Зарезервировано
if (90kHz_flag==0){
N
K
}
num_units_in_tick
}
}
6
1
1
7
32
32
32
bslbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
uimsbf
2.6.96. Семантическое определение полей в HEVC-синхронизации и HRD-дескрипторе
hrd_management_valid_flag - этот однобитовый флаг задается только для использования в транспортных потоках. Когда HEVC-синхронизация и HRD-дескриптор ассоциированы с HEVC-видеопотоком или с HEVC-представлением наивысшего временного подслоя, переносимым в транспортном потоке, то следующее применимо.
Если hrd_management_valid_flag задается равным 1, то SEI периода буферизации и SEI-сообщения по синхронизации изображений, как задано в приложении C рекомендации ITU-T H.265 | ISO/IEC 23008-2, должны присутствовать в ассоциированном HEVC-видеопотоке или HEVC-представлении наивысшего временного подслоя. Эти SEI-сообщения по периоду буферизации должны переносить кодированные значения nal_initial_cpb_removal_delay и nal_initial_cpb_removal_delay_offset и дополнительно могут переносить значения nal_initial_alt_removal_delay и nal_initial_alt_cpb_removal_delay_offset для NAL HRD. Если hrd_management_valid_flag задается равным 1, то передача каждого байта из MBn в EBn в T-STD, как задано в 2.17.2, или передача из MBn,k в EBn в T-STD, как задано в 2.17.3, должна выполняться согласно расписанию доставки для этого байта в CPB в NAL HRD, как определено из кодированных значений nal_initial_cpb_removal_delay и nal_initial_cpb_removal_delay_offset или из кодированных значений nal_initial_alt_cpb_removal_delay и nal_initial_alt_cpb_removal_delay_offset для SchedSelIdx, равного cpb_cnt_minus1, как указано в приложении C рекомендации ITU-T H.265 | ISO/IEC 23008-2. Когда hrd_management_valid_flag задается равным 0, способ на основе утечки должен использоваться для передачи из MBn в EBn в T-STD, как задано в 2.17.2, или для передачи из MBn,k в EBn в T-STD, как задано в 2.17.3.
picture_and_timing_info_present_flag - этот однобитовый флаг, когда задан равным 1, указывает то, что 90kHz_flag и параметры для точного преобразования в системный синхросигнал в 90 кГц включены в этот дескриптор.
90kHz_flag - этот однобитовый флаг, когда задан равным 1, указывает то, что частота временной HEVC-базы составляет 90 кГц.
N, K для HEVC-видеопотока или HEVC-представления наивысшего временного подслоя, частота временной HEVC-базы задается посредством элемента vui_time_scale синтаксиса в VUI-параметрах, как задано в приложении E рекомендации ITU-T H.265 | ISO/IEC 23008-2. Взаимосвязь между HEVC time_scale и STC должна задаваться посредством параметров N и K в этом дескрипторе следующим образом.
time_scale=(N x system_clock_frequency)/K
Если 90kHz_flag задается равным 1, то N равен 1, и K равен 300. Если 90kHz_flag задается равным 0, то значения N и K предоставляются посредством кодированных значений полей N и K.
Примечание X4. Это дает возможность преобразования времени, выражаемого в единицах time_scale, в единицы в 90 кГц при необходимости для вычисления временных PTS- и DTS-меток, например, в декодерах для HEVC-единиц доступа, для которых PTS или DTS не кодируется в PES-заголовке.
num_units_in_tick - это 32-битовое поле кодируется совершенно идентично полю vui_num_units_in_tick в VUI-параметрах в приложении E рекомендации ITU-T H.265 | ISO/IEC 23008-2. Информация, предоставляемая посредством этого поля, должна применяться ко всему HEVC-видеопотоку или HEVC-представлению наивысшего временного подслоя, с которым ассоциированы HEVC-синхронизация и HRD-дескриптор.
2.6.97. Дескриптор расширения иерархий
Дескриптор расширения иерархий предоставляет информацию для того, чтобы идентифицировать программные элементы, содержащие компоненты иерархически кодированных видео-, аудио- и частных потоков. (См. таблицу 2-49).
Дескриптор расширения иерархий
2.6.98. Семантическое определение полей в дескрипторе расширения иерархий
Когда дескриптор расширения иерархий присутствует, он используется для того, чтобы указывать зависимость слоев, присутствующих в различных элементарных потоках. Тем не менее, агрегирование временных подслоев реализуется посредством дескриптора иерархий, как указано в изменении 3 ISO/IEC 13818-1.
extension_dimension_bits - 16-битовое поле, указывающее возможное улучшение ассоциированного программного элемента из базового слоя, получающегося в результате программного элемента слоя с nuh_layer_id, равным 0.
Выделение битов для улучшающих размеров заключается в следующем.
I-ый бит, равный 1, указывает то, что соответствующий улучшающий размер присутствует.
hierarchy_layer_index - 6-битовое поле, которое задает уникальный индекс ассоциированного программного элемента в таблице иерархий слоев кодирования. Индексы должны быть уникальными в одном программном определении. Для субпотоков видеобитов HEVC-видеопотоков, соответствующих одному или более профилей, заданных в приложении F рекомендации ITU-T H.265 | ISO/IEC 23008-2, он представляет собой индекс программного элемента, который назначается таким способом, что порядок потока битов должен быть корректным, если ассоциированные слои зависимостей субпотоков видеобитов идентичной единицы доступа повторно собираются в порядке возрастания hierarchy_layer_index.
tref_present_flag - однобитовый флаг, который, когда задан равным 0, указывает то, что поле TREF может присутствовать в заголовках PES-пакетов в ассоциированном элементарном потоке. Значение 1 для этого флага зарезервировано.
nuh_layer_id - 6-битовое поле указывает наибольший nuh_layer_id NAL-единиц в элементарном потоке, ассоциированном с этим hierarchy_extension_descriptor().
temporal_id - 3-битовое поле указывает наибольший TemporalId NAL-единиц в элементарном потоке, ассоциированном с этим hierarchy_extension_descriptor()
num_embedded_layers - 6-битовое поле, которое указывает число прямых зависимых программных элементов, которые должны быть доступными и присутствовать в порядке декодирования до декодирования элементарного потока, ассоциированного с этим hierarchy_extension_descriptor().
hierarchy_ext_embedded_layer_index - 6-битовое поле, которое задает hierarchy_layer_index программного элемента, который должен быть доступным и присутствовать в порядке декодирования до декодирования элементарного потока, ассоциированного с этим hierarchy_extension_descriptor(). Это поле не определено, если значение hierarchy_type равно 15.
hierarchy_channel - 6-битовое поле, которое указывает намеченный номер канала для ассоциированного программного элемента в упорядоченном наборе каналов передачи. Самый надежный канал передачи задается посредством наименьшего значения этого поля относительно определения общей иерархии передачи.
Примечание. Данный hierarchy_channel может одновременно назначаться нескольким программным элементам.
2.6.99. Дескриптор HEVC-расширения
Дескриптор HEVC-расширения
descriptor_tag
descriptor_length
num_operation_points
for(i=0; i<num_operation_points; i++) {
profile_space
tier_flag
profile_idc
profile_compatibility_indication
progressive_source_flag
interlaced_source_flag
non_packed_constraint_flag
frame_only_constraint_flag
reserved_zero_44bits
level_idc
max_temporal_id
reserved_zero_5bits
for (j=0 ; j<64 ; j++) {
hevc_output_layer_flag
hevc_layer_present_flag
}
average_bit_rate
maximum_bitrate
frame_rate
}
}
8
8
2
1
5
32
1
1
1
1
44
8
3
5
1
1
16
16
16
uimsbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
uimsbf
2.6.100. Семантическое определение полей в дескрипторе HEVC-расширения
num_operation_points - 8-битовое поле, которое указывает число рабочих точек, указываемых посредством этого дескриптора.
profile_space - 2-битовое поле указывает контекст для интерпретации profile_idc для всех значений i в диапазоне от 0 до 31, включительно; profile_space не должны назначаться значения, отличные от значений, указываемых в приложении A или подразделе G.11 или в подразделе H.11 рекомендации ITU-T H.265 | ISO/IEC 23008-2. Другие значения profile_idc зарезервированы для будущего использования посредством ITU-T | ISO/IEC.
tier_flag - 1-битовое поле указывает контекст яруса для интерпретации level_idc, как указано в приложении A либо в подразделе G.11 или подразделе H.11 рекомендации ITU-T H.265 | ISO/IEC 23008-2.
profile_idc - 5-битовое поле, которое, когда profile_space равен 0, указывает профиль, которому соответствует CVS, как указано в приложении A или рекомендации ITU-T H.265 | ISO/IEC 23008-2; profile_idc не должны назначаться значения, отличные от значений, указываемых в приложении A либо в G.11 или H.11 рекомендации ITU-T H.265 | ISO/IEC 23008-2. Другие значения profile_idc зарезервированы для будущего использования посредством ITU-T | ISO/IEC.
Profile_compatibility_indication, progressive_source_flag, interlaced_source_flag, non_packed_constraint_flag, frame_only_constraint_flag, reserved_zero_44bits, level_idc - когда видеодескриптор HEVC-расширения применяется к видеопотоку HEVC-расширения, эти поля должны кодироваться согласно семантике, заданной в рекомендации ITU-T H.265 | ISO/IEC 23008-2 для general_profile_space, general_tier_flag, general_profile_idc, general_profile_compatibility_flag[i], general_progressive_source_flag, general_interlaced_source_flag, general_non_packed_constraint_flag, general_frame_only_constraint_flag, general_reserved_zero_44bits, general_level_idc, соответственно, для соответствующего HEVC-видеопотока или видеопотока HEVC-расширения или полного временного HEVC-представления, и весь HEVC-видеопоток или полное временное HEVC-представление, с которым ассоциирован HEVC-видеодескриптор, должно соответствовать информации, передаваемой в служебных сигналах посредством этих полей.
level_idc - 8-битовое поле указывает уровень, которому соответствует CVS, как указано в приложении A, G.11 или H.11 рекомендации ITU-T H.265 | ISO/IEC 23008-2; level_idc не должны назначаться значения level_idc, отличные от значений, указываемых в приложении A, G.11 или H.11 рекомендации ITU-T H.265 | ISO/IEC 23008-2. Другие значения level_idc зарезервированы для будущего использования посредством ITU-T | ISO/IEC.
max_temporal_id - 3-битовое поле, которое указывает наибольший TemporalId NAL-единиц слоев в i-ой рабочей точке.
reserved_zero_5bits - 5-битовое поле, зарезервированное со значением 0.
hevc_output_layer_flag - 1-битовое поле, когда ему назначено значение 1, указывает то, что слой с nuh_layer_id, равным j, принадлежит набору выходных слоев и требуется для вывода, когда i-ая рабочая точка декодируется. Когда ему назначено значение 0, слой с nuh_layer_id, равным j, не требуется для вывода при i-той операции. Когда j-ый hevc_output_layer_flag равен 1, значение j-ого hevc_layer_present_flag должно быть равно 1.
hevc_layer_flag - 1-битовое поле, когда ему назначено значение 1, указывает то, что nuh_layer_id, равный j, принадлежит набору идентификаторов слоев, каждая запись которого идентифицирует слой, который должен декодироваться, когда i-ая рабочая точка декодируется. Когда ему назначено значение 0, nuh_layer_id, равный i, не принадлежит набору идентификаторов слоев.
average_bitrate - 16-битовое поле, которое указывает среднюю скорость передачи битов, в 1000 битов в секунду, видеопотока HEVC-расширения, соответствующего i-ой рабочей точке.
maximum_bitrate - 16-битовое поле, которое указывает максимальную скорость передачи битов, в Кбит в секунду, видеопотока HEVC-расширения, соответствующего i-ой рабочей точке.
frame_rate - 16-битовое поле указывает максимальную частоту кадров в изображениях в расчете на 256 секунд видеопотока HEVC-расширения, соответствующего i-ой рабочей точке.
Раздел 2.17
Добавить следующее после раздела 2.16 в качестве нового подраздела:
2.17. Перенос HEVC
2.17.1. Ограничения для транспортировки HEVC
Для HEVC-видеопотоков, временных HEVC-субпотоков видеобитов или временных HEVC-видеоподнаборов, дополнительно применяются следующие ограничения:
- Каждая HEVC-единица доступа должна содержать NAL-единицу разделителя единиц доступа;
Примечание X5. HEVC требует, чтобы NAL-единица разделителя единиц доступа, если есть, представляла собой первую NAL-единицу в HEVC-единице доступа. NAL-единицы разделителя единиц доступа упрощают способность обнаруживать границу между HEVC-единицами доступа.
- HEVC-видеопоток или временной HEVC-субпоток видеобитов должны быть элементом программы согласно рекомендации ITU-T H.222.0 | ISO/IEC 13818-1, и stream_type для этого элементарного потока должен быть равен 0x24.
- Наборы параметров видео, наборы параметров последовательности и наборы параметров изображения, как указано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, необходимые для декодирования HEVC-видеопотока или временного HEVC-субпотока видеобитов, должны присутствовать в элементарном потоке, переносящем этот HEVC-видеопоток или временной HEVC-субпоток видеобитов.
- Для каждого временного HEVC-видеоподнабора, который является элементом идентичной программы согласно рекомендации ITU-T H.222.0 | ISO/IEC 13818-1, stream_type для этого элементарного потока должен быть равен 0x25.
- Когда программа согласно рекомендации ITU-T H.222.0 | ISO/IEC 13818-1 включает в себя более одного временного HEVC-видеоподнабора или более одного временного HEVC-субпотока видеобитов и, по меньшей мере, один временной HEVC-видеоподнабор, дескриптор иерархий, как задано в 2.6.7, должен присутствовать для всех ассоциированных элементарных потоков с stream_type, равным 0x24 или 0x25. Дескрипторы иерархий должны использоваться для того, чтобы указывать зависимости всех временных HEVC-субпотоков видеобитов и всех временных HEVC-видеоподнаборов.
- В каждом элементарном потоке с stream_type, равным 0x24 с дескриптором иерархий, hierarchy_type в дескрипторе иерархий должен быть равен 15.
- В каждом элементарном потоке с stream_type, равным 0x25 с дескриптором иерархий, hierarchy_type в дескрипторе иерархий должен быть равен 3.
- Наборы параметров видео, наборы параметров последовательности и наборы параметров изображения, как указано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, необходимые для декодирования HEVC-представления наивысшего временного подслоя временного HEVC-видеоподнабора, должны присутствовать в элементарном потоке, переносящем временной HEVC-субпоток видеобитов, ассоциированный посредством дескриптора иерархий.
- Агрегирование временного HEVC-субпотока видеобитов с ассоциированными временными HEVC-видеоподнаборами согласно дескрипторам иерархий, как указано в разделе 2.17.3, должно приводить к допустимому HEVC-видеопотоку.
Примечание X6. Результирующий HEVC-видеопоток содержит набор временных подслоев, как указано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, причем значения TemporalId формируют непрерывный диапазон целых чисел.
- Каждое HEVC-изображение должно содержать NAL-единицу разделителя изображений слоя;
- Каждое HEVC-изображение с nuh_layer_id, большим 0, должно либо содержаться в элементарном потоке с stream_type, равным 0x26, либо содержаться в элементарном потоке, который имеет stream_type, равный 0x25, и содержит HEVC-изображения с nuh_layer_id, равным 0.
- В каждом элементарном потоке с stream_type, равным 0x26 с дескриптором иерархий, hierarchy_type в дескрипторе иерархий должен быть равен 3.
2.14.3.9. NAL-единица разделителя изображений слоя
См. таблицу X-1.
NAL-единица разделителя изображений слоя
2.14.3.10. Семантика NAL-единицы разделителя изображений слоя
forbidden_zero_bit - должно быть равно 0x0
nal_unit_type - должно быть равно 0x30
nuh_layer_id указывает идентификатор слоя NAL-единицы.
nuh_temporal_id_plus1-nuh_temporal_id_plus1 минус 1 указывает временной идентификатор для NAL-единицы. Значение nuh_temporal_id_plus1 не должно быть равно 0.
В каждом элементарном потоке с stream_type, равным 0x26, точно один LPD_nal_unit может предшествовать всем NAL-единицам со значением nuh_layer_id, равным значению LPD_nal_unit.
Перенос в PES-пакетах
Видео согласно рекомендации ITU-T H.265 | ISO/IEC 23008-2 переносится в PES-пакетах в качестве PES_packet_data_bytes, с использованием одного из 16 значений stream_id, назначаемых видео, при передаче служебных сигналов видеопотока согласно рекомендации ITU-T H.265 | ISO/IEC 23008-2 посредством назначенного значения типа потока в PMT (см. таблицу 2-34). Самый верхний уровень, который может возникать в HEVC-видеопотоке, а также профиль и ярус, которым соответствует весь поток, должны быть переданы в служебных сигналах с использованием HEVC-видеодескриптора. Другие уровни, которые могут возникать в HEVC-видеопотоке, а также профили и мозаичные фрагменты субпотоков битов, которым соответствует весь поток, должны быть переданы в служебных сигналах с использованием видеодескриптора HEVC-расширения. Если HEVC-видеодескриптор ассоциирован с HEVC-видеопотоком, временным HEVC-субпотоком видеобитов, временным HEVC-видеоподнабором, то этот дескриптор должен быть передан в цикле дескриптора для соответствующей записи элементарного потока в таблице структуры программ. Эта рекомендация | международный стандарт не указывает представление потоков согласно рекомендации ITU-T H.265 | ISO/IEC 23008-2 в контексте программы.
Для PES-пакетирования, не применяются конкретные ограничения на совмещение данных. Для синхронизации и STD-управления, PTS и при необходимости DTS кодируются в заголовке PES-пакета, который переносит данные элементарных видеопотоков согласно рекомендации ITU-T H.265 | ISO/IEC 23008-2. Для PTS- и DTS-кодирования, ограничения и семантика применяются так, как задано в 2.17.1.
Управление буфером DPB
Перенос HEVC-видеопотока, временных HEVC-видеосубпотоков или временной HEVC-видеоподнабор по рекомендации ITU-T H.222.0 | ISO/IEC 13818-1 не оказывает влияние на размер буфера DPB. Для декодирования HEVC-видеопотока, временного HEVC-субпотока видеобитов или временного HEVC-субпотока видеобитов и его ассоциированных временных HEVC-видеоподнаборов в STD, размер DPB является таким, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2. DPB должен управляться так, как указано в приложении C или разделе F.13 рекомендации ITU-T H.265 | ISO/IEC 23008-2 (разделы C.3 и C.5). Декодированная HEVC-единица доступа входит в DPB мгновенно при декодировании HEVC-единицы доступа, следовательно, во время удаления из CPB HEVC-единицы доступа. Декодированная HEVC-единица доступа представлена во время DPB-вывода. Если HEVC-видеопоток, временной HEVC-субпоток видеобитов, временной HEVC-видеоподнабор или видеопоток HEVC-расширения предоставляет недостаточную информацию для того, чтобы определять время удаления из CPB и время DPB-вывода HEVC-единиц доступа, то эти моменты времени должны определяться в STD-модели из временных PTS- и DTS-меток следующим образом:
1) Время удаления из CPB изображений HEVC-слоев HEVC-единицы n доступа является моментом времени, указываемым посредством DTS(n), где DTS(n) является DTS-значением HEVC-единицы n доступа. [Ed. (CY): MV-HEVC и SHVC поддерживают два режима работы HRD: первый предполагает идентичное время удаления из CPB для всех изображений HEVC-слоев в единице доступа, и второй может предполагать различные времена удаления из CPB для различных изображений HEVC-слоев. Первый режим является типичным и является идентичным MVC и SVC. В настоящее время только первый режим поддерживается в тексте текущей спецификации. Требуются дополнительные исследования для поддержки второго режима].
2) Время DPB-вывода изображений HEVC-слоев HEVC-единицы n доступа является моментом времени, указываемым посредством PTS(n), где PTS(n) является PTS-значением HEVC-единицы n доступа.
Примечание X7. HEVC-видеопоследовательности, в которых low_delay_hrd_flag в синтаксической структуре hrd_parameters() задается равным 1, переносят достаточную информацию для того, чтобы определять время DPB-вывода и время удаления из CPB каждой HEVC-единицы доступа. Следовательно, для HEVC-единиц доступа, для которых может возникать STD-опустошение, время удаления из CPB и время DPB-вывода задаются посредством HRD-параметров, а не посредством временных DTS- и PTS-меток.
Примечание X8. HEVC-видеопоток может переносить информацию для того, чтобы определять соответствие HEVC-видеопотока HRD, как указано в приложении C рекомендации ITU-T H.265 | ISO/IEC 23008-2. Присутствие этой информации может быть передано в служебных сигналах в транспортном потоке с использованием HEVC-синхронизации и HRD-дескриптора с hrd_management_valid_flag, заданным равным 1. Независимо от присутствия этой информации, соответствие HEVC-видеопотока T-STD обеспечивает то, что требования по управлению HRD-буфером для CPB удовлетворяются, когда каждый байт в HEVC-видеопотоке доставляется и удаляется из CPB в HRD в момент времени, полностью идентичный моменту времени, в который байт доставляется и удаляется из EBn в T-STD.
2.17.2. T-STD-расширения для однослойного HEVC
Когда имеется HEVC-видеопоток или временной HEVC-субпоток видеобитов в программе согласно рекомендации ITU-T H.222.0 | ISO/IEC 13818-1, и отсутствует временной HEVC-видеоподнабор, ассоциированный с этим элементарным потоком stream_type 0x24 в идентичной программе согласно рекомендации ITU-T H.222.0 | ISO/IEC 13818-1, T-STD-модель, как описано в 2.4.2, расширяется так, как проиллюстрировано на фиг. X-1 и как указано ниже.
Фиг. X-1. Расширения T-STD-модели для однослойного HEVC
Управление буфером TBn, MBn, EBn
Следующие дополнительные обозначения используются для того, чтобы описывать T-STD-расширения, и проиллюстрированы на фиг. X-1 выше.
t(i) указывает время в секундах, в которое i-ый байт транспортного потока входит в декодер системных целевых объектов
TBn является транспортным буфером для элементарного потока n
TBS является размером транспортного буфера TBn, измеренным в байтах
MBn является буфером мультиплексирования для элементарного потока n
MBSn является размером буфера MBn мультиплексирования, измеренным в байтах
EBn является буфером элементарных потоков для HEVC-видеопотока
j является индексом для HEVC-единицы доступа HEVC-видеопотока
An(j) является j-ой единицей доступа HEVC-потока видеобитов
tdn(j) является временем декодирования An(j), измеренным в секундах, в декодере системных целевых объектов
Rxn является скоростью передачи из транспортного буфера TBn в буфер MBn мультиплексирования, как указано ниже.
Rbxn является скоростью передачи из буфера MBn мультиплексирования в буфер EBn элементарных потоков, как указано ниже.
Применимо следующее:
- Предусмотрен точно один транспортный буфер TBn для принимаемого HEVC-видеопотока или временного HEVC-субпотока видеобитов, где размер TBS задается фиксированно равным 512 байтов.
- Предусмотрен точно один буфер MBn мультиплексирования для HEVC-видеопотока или временного HEVC-субпотока видеобитов, где размер MBSn буфера MB мультиплексирования ограничивается следующим образом:
MBSn=BSmux+BSoh+CpbBrNalFactor x MaxCPB[tier, level]-cpb_size,
где BSoh, буферизация служебной информации на передачу пакетов, задается следующим образом:
BSoh=(1/750) секунд*max{CpbBrNalFactor x MaxBR[tier, level], 2000000 бит/с}
и BSmux, дополнительная буферизация мультиплексирования, задается следующим образом:
BSmux=0,004 секунд*max{CpbBrNalFactor x MaxBR[tier, level], 2000000 бит/с}
MaxCPB[tier, level] и MaxBR[tier, level] извлекаются из приложения A рекомендации ITU-T H.265 | ISO/IEC 23008-2 для яруса и уровня HEVC-видеопотока или временного HEVC-субпотока видеобитов. cpb_size извлекается из HRD-параметров, как указано в приложении E рекомендации ITU-T H.265 | ISO/IEC 23008-2, включенных в HEVC-видеопоток или временной HEVC-субпоток видеобитов.
- Предусмотрен точно один буфер EBn элементарных потоков для всех элементарных потоков в наборе принимаемых элементарных потоков, ассоциированных посредством дескрипторов иерархий, с полным размером EBSn:
EBSn=cpb_size (измеряется в байтах),
где cpb_size извлекается из HRD-параметров, как указано в приложении E рекомендации ITU-T H.265 | ISO/IEC 23008-2, включенных в HEVC-видеопоток или временной HEVC-субпоток видеобитов.
- Передача из TBn в MBn применяется следующим образом:
Когда отсутствуют данные в TBn, то Rxn равен нулю. Иначе:
Rxn=bit_rate,
где bit_rate составляет CpbBrNalFactor/CpbBrVclFactor x BitRate[SchedSelIdx] потока данных в CPB для формата потока байтов, и BitRate[SchedSelIdx] является таким, как задано в приложении E рекомендации ITU-T H.265 | ISO/IEC 23008-2, когда NAL HRD-параметры присутствуют в VUI-параметрах HEVC-видеопотока.
Примечание X9. Приложение E также указывает значения по умолчанию для BitRate[SchedSelIdx] на основе профиля, яруса и уровня, когда NAL HRD-параметры не присутствуют в VUI.
- Передача из MBn в EBn применяется следующим образом:
Если HEVC_timing_and_HRD_descriptor присутствует с hrd_management_valid_flag, заданным равным 1 для элементарного потока, то передача данных из MBn в EBn должна соответствовать HRD-заданной схеме для поступления данных в CPB элементарного потока, как задано в приложении C рекомендации ITU-T H.265 | ISO/IEC 23008-2.
В противном случае, способ на основе утечки должен использоваться для того, чтобы передавать данные из MBn в EBn следующим образом:
Rbxn=CpbBrNalFactor x MaxBR[tier, level],
где MaxBR[tier, level] извлекается из приложения A рекомендации ITU-T H.265 | ISO/IEC 23008-2 для яруса и уровня HEVC-видеопотока или временного HEVC-субпотока видеобитов.
Если имеются рабочие данные PES-пакетов в MBn, и буфер EBn не является полным, рабочие данные PES-пакетов передаются из MBn в EBn на скорости, равной Rbxn. Если EBn является полным, данные не удаляются из MBn. Когда байт данных передается из MBn в EBn, все байты заголовка PES-пакета, которые находятся в MBn и предшествуют этому байту, мгновенно удаляются и отбрасываются. Когда не присутствуют рабочие данные PES-пакетов в MBn, данные не удаляются из MBn. Все данные, которые входят в MBn, выходят из него. Все байты рабочих данных PES-пакетов входят EBn мгновенно после выхода из MBn.
STD-задержка
STD-задержка любых данных согласно рекомендации ITU-T H.265 | ISO/IEC 23008-2, отличных от данных неподвижных HEVC-изображений через буферы TBn, MBn и EBn декодеров системных целевых объектов, должна ограничиваться посредством tdn(j)-t(i)≤10 секунд для всех j и всех байтов i в единице An(j) доступа.
Задержка любых данных неподвижных HEVC-изображений через декодеры TBn, MBn и EBn системных целевых объектов должна ограничиваться посредством tdn(j)-t(i)≤60 секунд для всех j и всех байтов i в единице An(j) доступа.
Условия управления буфером
Транспортные потоки должны иметь такую структуру, что следующие условия для управления буфером удовлетворяются:
- Каждый TBn не должен переполняться и должен быть пустым, по меньшей мере, один раз каждую секунду.
- Каждый MBn, EBn и DPB не должен переполняться.
- EBn не должен опустошаться, кроме тех случаев, когда VUI-параметры присутствуют для HEVC-видеопоследовательности с low_delay_hrd_flag, заданным равным 1. Опустошение EBn возникает для HEVC-единицы An(j) доступа, когда один или более байтов An(j) не присутствуют в EBn во время tdn(j) декодирования.
2.17.3. T-STD-расширения для многослойной транспортировки временных HEVC-видеоподнаборов
Когда имеется HEVC-субпоток видеобитов и, по меньшей мере, один ассоциированный элементарный поток типа 0x25 в программе согласно рекомендации ITU-T H.222.0 | ISO/IEC 13818-1, T-STD-модель, как описано в 2.4.2, расширяется так, как проиллюстрировано на фиг. X-2 и как указано ниже.
Фиг. X-2. Расширения T-STD-модели для многослойной транспортировки временных HEVC-видеоподнаборов
Следующие дополнительные обозначения используются для того, чтобы описывать T-STD-расширения, и проиллюстрированы на фиг. X-2 выше.
t(i) указывает время в секундах, в которое i-ый байт транспортного потока входит в декодер системных целевых объектов
H является числом принимаемых временных HEVC-видеоподнаборов, ассоциированных посредством дескрипторов иерархий с идентичным временным HEVC-субпотоком видеобитов.
k является индексом, идентифицирующим H+1 принимаемых элементарных потоков, которые содержат точно один временной HEVC-субпоток видеобитов и H временных HEVC-видеоподнаборов, ассоциированных посредством дескрипторов иерархий. Значение k индекса, равное 0, идентифицирует элементарный поток, который содержит временной HEVC-субпоток видеобитов, и значения k индекса в пределах от 1 до H идентифицируют ассоциированные временные HEVC-видеоподнаборы.
ESn,k является принимаемым элементарным потоком, который содержит k-ый временной HEVC-видеоподнабор или временной HEVC-субпоток видеобитов, если k равен 0
ESn,H является принимаемым элементарным потоком, содержащим наибольший временной HEVC-видеоподнабор, присутствующий в наборе принимаемых элементарных потоков
PIDH является значением идентификатора пакета, которое идентифицирует ESn,H
j является индексом для выходных единиц доступа
An(j) является j-ой единицей доступа полного временного HEVC-представления
tdn(j) является временем декодирования An(j) в декодере системных целевых объектов
TBn,k является транспортным буфером для элементарного потока k
TBSn,k является размером транспортного буфера TBn,k, измеренным в байтах
MBn,k является буфером мультиплексирования для элементарного потока k
MBSn,k является размером буфера MBn,k мультиплексирования, измеренным в байтах
EBn является буфером элементарных потоков для принимаемого временного HEVC-субпотока ESn,0 видеобитов и принимаемых временных HEVC-видеоподнаборов ESn,1 - ESn,H
EBSn является размером буфера EBn элементарных потоков, измеренным в байтах
Rxn,k является скоростью передачи из k-ого транспортного буфера TBn,k в k-ый буфера MBn,k мультиплексирования, как указано ниже
Rbxn,k является скоростью передачи из k-ого буфера MBn,k мультиплексирования в буфер EBn элементарных потоков, как указано ниже
Примечание X10. Индекс n при использовании указывает то, что принимаемые элементарные потоки и ассоциированные буферы принадлежат определенному временному HEVC-субпотоку видеобитов и его ассоциированным временным HEVC-видеоподнаборам, отличая эти элементарные потоки и ассоциированные буферы от других элементарных потоков и буферов, поддерживая согласованность с обозначениями на фиг. X-1.
Управление буфером TBn,k, MBn,k, EBn
Применимо следующее:
- Предусмотрен один транспортный буфер TBn,k для принимаемого элементарного потока ESn,k, где размер TBSn,k задается фиксированно равным 512 байтов.
- Предусмотрен один буфер MBn,k мультиплексирования для принимаемого элементарного потока ESn,k, где размер MBSn,k буфера MBn,k мультиплексирования ограничивается следующим образом:
MBSn,k=BSmux+BSoh+CpbBrNalFactor x MaxCPB[tier, level]-cpb_size (измеряется в байтах),
где:
BSoh, буферизация служебной информации на передачу пакетов, и BSmux, дополнительная буферизация мультиплексирования, являются такими, как указано в разделе 2.17.2;
MaxCPB[tier, level] и MaxBR[tier, level] извлекаются из спецификации яруса и уровня HEVC для яруса и уровня HEVC-представления наивысшего временного подслоя, ассоциированного с ESn,k;
cpb_size извлекается из HRD-параметров, как указано в приложении E рекомендации ITU-T H.265 | ISO/IEC 23008-2, включенных в HEVC-представление наивысшего временного подслоя, ассоциированное с ESn,k.
- Предусмотрен точно один буфер EBn элементарных потоков для H+1 элементарных потоков в наборе принимаемых элементарных потоков ESn,0 - ESn,H, с полным размером EBSn:
EBSn=cpb_size (измеряется в байтах),
где cpb_size извлекается из HRD-параметров, как указано в приложении E рекомендации ITU-T H.265 | ISO/IEC 23008-2, включенных в HEVC-представление наивысшего временного подслоя, ассоциированное с ESn,H.
- Передача из TBn,k в MBn,k применяется следующим образом:
Когда отсутствуют данные в TBn,k, то Rxn,k равен нулю. Иначе:
Rxn,k=bit_rate,
где bit_rate является таким, как указано в разделе 2.17.2.
- Передача из MBn,k в EBn применяется следующим образом:
Если HEVC_timing_and_HRD_descriptor присутствует с hrd_management_valid_flag, заданным равным 1 для HEVC-субпотока видеобитов, то передача данных из MBn,k в EBn должна соответствовать HRD-заданной схеме для поступления данных в CPB элементарного потока ESn,H, как задано в приложении C рекомендации ITU-T H.265 | ISO/IEC 23008-2.
В противном случае, способ на основе утечки должен использоваться для того, чтобы передавать данные из MBn,k в EBn следующим образом:
Rbxn,k=CpbBrNalFactor x MaxBR[tier, level],
где MaxBR[tier, level] задается для формата потока байтов в приложении A рекомендации ITU-T H.265 | ISO/IEC 23008-2 для яруса и уровня HEVC-видеопотока или HEVC-представления наивысшего временного подслоя, ассоциированного с ESn,k.
Если имеются рабочие данные PES-пакетов в MBn,k, и EBn не является полным, рабочие данные PES-пакетов передаются из MBn,k в EBn на скорости равной Rbxn,k. Если EBn является полным, данные не удаляются из MBn,k. Когда байт данных передается из MBn,k в EBn, все байты заголовка PES-пакета, которые находятся в MBn,k и предшествуют этому байту, мгновенно удаляются и отбрасываются. Когда не присутствуют рабочие данные PES-пакетов в MBn,k, данные не удаляются из MBn,k. Все данные, которые входят MBn,k, выходят из него. Все байты рабочих данных PES-пакетов входят в EBn мгновенно после выхода из MBn,k.
В выводе буфера EBn элементарных потоков, элементарные потоки агрегированы посредством удаления всех HEVC-единиц доступа в возрастающем DTS-порядке и их передачи в HEVC-декодер DH, независимо от того, какому элементарному потоку ESn,k принадлежит каждая HEVC-единица доступа.
STD-задержка
STD-задержка любых данных согласно рекомендации ITU-T H.265 | ISO/IEC 23008-2, отличных от данных неподвижных HEVC-изображений через буферы декодеров TBn,k, MBn,k и EBn системных целевых объектов, должна ограничиваться посредством tdn(j)-t(i)≤10 секунд для всех k, всех j и всех байтов i в единице An(j) доступа.
Задержка любых данных неподвижных HEVC-изображений через декодеры TBn,k, MBn,k и EBn системных целевых объектов должна ограничиваться посредством tdn(j)-t(i)≤60 секунд для всех k, всех j и всех байтов i в единице An(j) доступа.
Условия управления буфером
Транспортные потоки должны иметь такую структуру, что следующие условия для управления буфером удовлетворяются:
- Каждый TBn,k не должен переполняться и должен быть пустым, по меньшей мере, один раз каждую секунду.
- Каждый MBn,k, EBn и DPB не должен переполняться.
- EBn не должен опустошаться, кроме тех случаев, когда VUI-параметры присутствуют для HEVC-видеопоследовательности с low_delay_hrd_flag, заданным равным 1. Опустошение EBn возникает для HEVC-единицы An(j) доступа, когда один или более байтов An(j) не присутствуют в EBn во время tdn(j) декодирования.
2.17.4. T-STD-расширения для многослойной транспортировки многослойного HEVC-субпотока видеобитов
T-STD-модель, описанная в 2.17.2 или 2.17.3, применяется, если принимаемый элементарный поток является субпотоком видеобитов stream_type 0x24 или 0x25, т.е. принимается и декодируется только субпоток видеобитов базового HEVC-слоя или временной HEVC-видеоподнабор базового слоя.
Когда имеется набор многослойных HEVC-субпотоков видеобитов в программе согласно рекомендации ITU-T H.222.0 | ISO/IEC 13818-1, зависимости которого могут быть переданы в служебных сигналах в дескрипторе расширения иерархий, как задано в 2.6.97, и когда имеется, по меньшей мере, один из многослойных HEVC-субпотоков видеобитов в наборе принимаемых элементарных потоков, имеющих значение stream_type, равное 0x26, T-STD-модель, как описано в 2.14.3.1, расширяется так, как проиллюстрировано на фиг. X-3 и как указано ниже.
Фиг. 2-15. Расширения T-STD-модели для видео согласно рекомендации ITU-T H.265 | ISO/IEC 23008-2 с многослойными HEVC-субпотоками видеобитов
Следующие дополнительные обозначения используются для того, чтобы описывать T-STD-расширения, и проиллюстрированы на фиг. 2-15 выше.
ESn является принимаемым элементарным потоком, ассоциированным с n-ым многослойным HEVC-субпотоком видеобитов, где n является индексом для поднаборов идентификаторов HEVC-слоев, начиная со значения 0 для поднабора идентификаторов HEVC-слоев, содержащего базовый слой и упорядоченного согласно минимальному nuh_layer_id из поднаборов идентификаторов слоев
ESH является принимаемым элементарным потоком, ассоциированным с H-ым многослойным HEVC-субпотоком видеобитов, который включает в себя слои с наибольшим nuh_layer_id, присутствующим во всех многослойных HEVC-субпотоках видеобитов принимаемых элементарных потоков
j является индексом для повторно собранных единиц доступа
jn является индексом для наборов идентификаторов HEVC-слоев элементарного потока ESn, ассоциированного с n-ым многослойным HEVC-субпотоком видеобитов
VSn(jn) является jn-ым поднабором изображений HEVC-слоев многослойного HEVC-субпотока видеобитов, ассоциированного с ESn
AH(j) является j-ой единицей доступа, получающейся в результате повторной сборки (вплоть до) H-ого поднабора изображений HEVC-слоев, ассоциированного с ESH
tdn(jn) является временем декодирования, измеренным в секундах, в декодере системных целевых объектов поднабора VSn(jn) изображений HEVC-слоев
tdH(j) является временем декодирования, измеренным в секундах, в декодере системных целевых объектов j-ой единицы AH(j) доступа, получающейся в результате повторной сборки (вплоть до) поднабора VSH(jH) изображений HEVC-слоев
TBn является транспортным буфером для элементарного потока ESn
TBSn является размером транспортного буфера TBn, измеренным в байтах
MBn является буфером мультиплексирования для элементарного потока ESn
MBSn является размером буфера MBn мультиплексирования, измеренным в байтах
VSBn является буфером поднаборов изображений HEVC-слоев для элементарного потока ESn
VSBSn является размером буфера VSBn поднаборов изображений HEVC-слоев, измеренным в байтах
EBH является буфером элементарных потоков для многослойного HEVC-субпотока видеобитов, включающего в себя субпоток видеобитов базового HEVC-слоя
EBSH является размером буфера EBH элементарных потоков, измеренным в байтах
Rxn является скоростью передачи из TBn в MBn, как указано ниже
Rbxn является скоростью передачи из MBn в VSBn, как указано ниже
Перенос в PES-пакетах
Для корректной повторной сборки поднаборов изображений HEVC-слоев в HEVC-единицу доступа, следующее применимо:
- PES-пакет в расчете на начало поднабора изображений HEVC-слоев должен присутствовать, т.е. самое большее один поднабор изображений HEVC-слоев может начинаться в идентичном PES-пакете;
- PTS- и, если применимо, DTS-значение должно предоставляться в PES-заголовке каждого поднабора изображений HEVC-слоев
Управление буфером DPB
Управление буфером DPB для повторно собранного HEVC-видеопотока должно соответствовать 2.17.2 или 2.17.3 с использованием значений временной синхронизации HEVC-единицы доступа, в качестве DTS или времени удаления из CPB и PTS или времени удаления из DPB, ассоциированных с поднабором изображений HEVC-слоев многослойного HEVC-субпотока видеобитов в элементарном потоке ESH.
Управление буфером TBn, MBn, EBn
Применимо следующее:
- Предусмотрен точно один транспортный буфер TB, как задано в 2.14.3.1, для принимаемого элементарного потока в наборе принимаемых многослойных HEVC-субпотоков видеобитов, включающих в себя субпоток видеобитов базового HEVC-слоя, содержащийся в элементарных потоках, как показано на фиг. X-3.
- Предусмотрен точно один буфер мультиплексирования MB0 для субпотока видеобитов базового HEVC-слоя в элементарном потоке ES0, где размер буфера MBS0 мультиплексирования ограничивается следующим образом:
MBS0=BSmux,0+BSoh,0+CpbBrNalFactor x MaxCPB[tier, level]0-cpb_size0,
где BSmux,0, BSoh,0 задаются в 2.14.3.1 для субпотока видеобитов базового HEVC-слоя в элементарном потоке ES0,
где MaxCPB[tier, level]0 и cpb_size0 для элементарного потока ES0 задаются так, как указано 2.14.3.1.
Примечание 1. Если HRD-параметры присутствуют, по меньшей мере, в одном из многослойных HEVC-субпотоков видеобитов, эти параметры должны тщательно обрабатываться, чтобы не увеличивать без необходимости выделение буферов мультиплексирования.
- Предусмотрен точно один буфер MBn мультиплексирования для принимаемого элементарного потока, ассоциированного со значением nuh_layer_id, не равным 0, где размер каждого буфера MBSn мультиплексирования в наборе принимаемых элементарных потоков ограничивается следующим образом:
MBSn=BSmux,n+BSoh,n,
где BSmux,n, BSoh,n задаются в 2.14.3.1 для HEVC-видеопотока, получающегося в результате повторной сборки (вплоть до) многослойного HEVC-субпотока видеобитов в элементарном потоке ESn.
- Предусмотрен точно один буфер EBH элементарных потоков для всех элементарных потоков в наборе принимаемых элементарных потоков, как показано на фиг. X-3, размер EBSH которого имеет следующее значение:
EBSH=cpb_sizeH,
где cpb_sizeH составляет cpb_size для многослойного HEVC-субпотока видеобитов в элементарном потоке ESH, как задано в 2.14.3.1 для повторно собранного HEVC-видеопотока.
- Предусмотрен точно один буфер VSBn поднаборов изображений HEVC-слоев для каждого элементарного потока в наборе принимаемых элементарных потоков, как показано на фиг. X-3, причем каждый буфер VSBn поднаборов изображений HEVC-слоев в наборе принимаемых элементарных потоков выделяется в EBH. Даже если размер VSBSn отдельного VSBn не ограничивается, сумма размеров VSBSn ограничивается следующим образом:
EBSH=∑n(VSBSn)
- Передача из TBn в MBn применяется следующим образом:
Скорость Rxn:
Если отсутствуют данные в TBn, Rxn равен нулю.
Иначе: Rxn=bit_rate,
где bit_rate составляет CpbBrNalFactor/CpbBrVclFactor*BitRate[SchedSelIdx] потока данных в CPB для формата потока байтов, и BitRate[SchedSelIdx] является таким, как задано в рекомендации ITU-T H.265 | ISO/IEC 23008-2, когда NAL HRD-параметры присутствуют в VPS для многослойного HEVC-субпотока видеобитов.
- Передача из MBn в VSBn применяется следующим образом:
Если HEVC_timing_and_HRD_descriptor присутствует с hrd_management_valid_flag, заданным равным 1 для элементарного потока ESH, то передача данных из MBn в VSBn должна соответствовать HRD-заданной схеме для поступления данных в CPB элементарного потока ESH, как задано в приложении C рекомендации ITU-T H.265 | ISO/IEC 23008-2.
В противном случае, способ на основе утечки должен использоваться для того, чтобы передавать данные из MBn в VSBn следующим образом:
Скорость Rbxn:
Rbxn=CpbBrNalFactor x MaxBR[tier, level]n,
где MaxBR[tier, level]n задается для формата потока байтов в таблице A.1(пределы для уровня) в рекомендации ITU-T H.265 | ISO/IEC 23008-2 для уровня HEVC-видеопотока, получающегося в результате повторной сборки (вплоть до) ассоциированного многослойного HEVC-субпотока видеобитов n в элементарном потоке ESn. Если имеются рабочие данные PES-пакетов в MBn, и буфер EBH не является полным, рабочие данные PES-пакетов передаются из MBn в VSBn на скорости, равной Rbxn. Если EBH является полным, данные не удаляются из MBn. Когда байт данных передается из MBn в VSBn, все байты заголовка PES-пакета, которые находятся в MBn и предшествуют этому байту, мгновенно удаляются и отбрасываются. Когда не присутствуют рабочие данные PES-пакетов в MBn, данные не удаляются из MBn. Все данные, которые входят в MBn, выходят из него. Все байты рабочих данных PES-пакетов входят в VSBn мгновенно после выхода из MBn. [Ed (CY): должно быть обновлено на основе последней спецификации MV-HEVC].
Повторная сборка единиц доступа и удаление из EB
Далее указывается повторная сборка единиц доступа, которая приводит к HEVC-единице AH(j) доступа:
i) Сборка поднаборов изображений HEVC-слоев для j-ой единицы AH(j) доступа согласно нижеприведенному правилу:
для поднаборов VSy+1(jy+1) и каждого VSy(jy) изображений HEVC-слоев, собранных для единицы AH(j) доступа, где VSy ассоциирован с программным элементом, идентифицированным посредством каждого значения hierarchy_ext_embedded_layer_index, указываемого в ассоциированном дескрипторе расширения иерархий, DTS-значение tdy+1(jy+1) VSy+1(jy+1) должно быть равно DTS-значению tdy(jy) VSy(jy).
Примечание 3. Если дескриптор расширения иерархий не присутствует, VSy ассоциирован с субпотоком видеобитов базового HEVC-слоя, а VSy+1 ассоциирован с многослойным HEVC-субпотоком видеобитов.
[Ed. (CY): переупорядочение SEI-сообщений касательно MVC и SVC удаляется здесь].
Далее указывается удаление единицы AH(j) доступа из буфера EBH:
Во время tdH(j) декодирования, HEVC-единица AH(j) доступа должна повторно собираться и быть доступной для удаления из буфера EBH. Время tdH(j) декодирования указывается посредством DTS или посредством времени удаления из CPB, которое ассоциировано с поднаборами изображений HEVC-слоев в элементарном потоке ESH, извлеченного из информации в повторно собранном AVC-видеопотоке.
STD-задержка
STD-задержка для повторно собранных HEVC-единиц доступа должна соответствовать ограничениям, указываемым в 2.17.1.
Условия управления буфером
Транспортные потоки должны иметь такую структуру, что следующие условия для управления буфером удовлетворяются:
- Каждый TBn не должен переполняться и должен быть пустым, по меньшей мере, один раз каждую секунду.
- Каждый MBn, EBH и DPB не должен переполняться.
- EBH не должен опустошаться, кроме тех случаев, когда VUI-параметры присутствуют для видеопоследовательности AVC повторно собранного AVC-видеопотока с low_delay_hrd_flag, заданным равным 1. Опустошение EBH возникает для HEVC-единицы AH(j) доступа, когда один или более байтов AH(j) не присутствуют в EBH во время tdH(j) декодирования.
2.17.5. P-STD-расширения для многослойного HEVC-субпотока видеобитов
P-STD-модель применяется, если декодированный элементарный поток является субпотоком видеобитов stream_type 0x24 или 0x25, т.е. только субпоток видеобитов базового HEVC-слоя декодируется.
Когда имеется набор декодированных многослойных HEVC-субпотоков видеобитов в программе согласно рекомендации ITU-T H.222.0 | ISO/IEC 13818-1, значения поднаборов идентификаторов слоев которого могут быть переданы в служебных сигналах в HEVC_extension_descriptor, как задано в 2.6.99, и когда имеется, по меньшей мере, один из многослойных HEVC-субпотоков видеобитов в наборе декодированных элементарных потоков, имеющих значение stream_type, равное 0x26, P-STD-модель, как описано в 2.14.3.2, расширяется так, как проиллюстрировано на фиг. X-4 и как указано ниже.
Фиг. X-4. Расширения P-STD-модели для видео согласно рекомендации ITU-T H.265 | ISO/IEC 23008-2 с многослойными HEVC-субпотоками видеобитов
Следующие дополнительные обозначения используются для того, чтобы описывать P-STD-расширения, и проиллюстрированы выше на фиг. X-4.
ESn является принимаемым элементарным потоком, ассоциированным с n-ым многослойным HEVC-субпотоком видеобитов, где n является индексом для поднаборов идентификаторов HEVC-слоев, начиная со значения 0 для поднабора идентификаторов HEVC-слоев, содержащего основание, разделенное на слои, и упорядоченного согласно минимальному nuh_layer_id, содержащемуся в каждом поднаборе идентификаторов HEVC-слоев
ESH является принимаемым элементарным потоком, ассоциированным с H-ым многослойным субпотоком видеобитов, который включает в себя изображения HEVC-слоев с наибольшим nuh_layer_id, присутствующим во всех поднаборах идентификаторов HEVC-слоев принимаемых элементарных потоков
j является индексом для повторно собранных единиц доступа
jn является индексом для поднаборов изображений HEVC-слоев элементарного потока, ассоциированного с n-ым поднабором изображений HEVC-слоев
VSn(jn) является jn-ым поднабором изображений HEVC-слоев многослойного HEVC-субпотока видеобитов, ассоциированного с ESn
AH(j) является j-ой единицей доступа, получающейся в результате повторной сборки (вплоть до) H-ого поднабора изображений HEVC-слоев, ассоциированного с ESH
tdn(jn) является временем декодирования, измеренным в секундах, в декодере системных целевых объектов поднабора VSn(jn) изображений HEVC-слоев
tdH(j) является временем декодирования, измеренным в секундах, в декодере системных целевых объектов j-ой единицы AH(j) доступа, получающейся в результате повторной сборки (вплоть до) поднабора VSH(jH) изображений HEVC-слоев
BH является входным буфером для всех декодированных многослойных HEVC-субпотоков видеобитов
BSH является размером входного буфера BH, измеренным в байтах
VSBn является буфером поднаборов многослойных HEVC-изображений для элементарного потока ESn
VSBSn является размером буфера VSBn поднаборов многослойных HEVC-изображений, измеренным в байтах
Перенос в PES-пакетах
Для корректной повторной сборки поднаборов изображений HEVC-слоев в HEVC-единицу доступа, следующее применимо:
- PES-пакет в расчете на начало изображения HEVC-слоя должен присутствовать, т.е. самое большее один поднабор изображений HEVC-слоев может начинаться в идентичном PES-пакете;
- PTS- и, если применимо, DTS-значение должно предоставляться в PES-заголовке каждого поднабора изображений HEVC-слоев.
Управление буфером DPB
Управление буфером DPB для повторно собранного HEVC-видеопотока должно соответствовать 2.14.3.1 MPEG-2 TS с использованием значений временной синхронизации HEVC-единицы доступа, в качестве DTS или времени удаления из CPB и PTS или времени удаления из DPB, ассоциированных с поднаборами изображений HEVC-слоев многослойного HEVC-субпотока видеобитов в элементарном потоке ESH.
Управление буфером Bn
Применимо следующее:
- Предусмотрен точно один буфер BH элементарных потоков для всех элементарных потоков в наборе декодированных элементарных потоков, как показано на фиг. X-4, где размер BSH задается посредством поля P-STD_buffer_size в заголовке PES-пакета элементарного потока ESH.
- Предусмотрен точно один буфер VSBn поднаборов изображений HEVC-слоев для каждого элементарного потока в наборе декодированных элементарных потоков, как показано на фиг. X-4, причем каждый буфер VSBn поднаборов HEVC-слоев в наборе декодированных элементарных потоков выделяется для BSH. Даже если размер VSBSn отдельного VSBn не ограничивается, сумма размеров VSBSn ограничивается следующим образом:
BSH=∑n(VSBSn),
где BSH является размером входного буфера для MVC-субпотока видеобитов в элементарном потоке ESH, как задано в 2.14.3.2, для повторно собранного AVC-видеопотока.
Повторная сборка единиц доступа и удаление из B
Далее указывается повторная сборка единиц доступа, которая приводит к AVC-единице AH(j) доступа:
i) Сборка поднаборов изображений HEVC-слоев для j-ой единицы AH(j) доступа согласно нижеприведенному правилу:
для поднабора VSy+1(jy+1) и каждого VSy(jy) изображений HEVC-слоев, собранных для единицы AH(j) доступа, где VSy ассоциирован с программным элементом, идентифицированным посредством каждого значения hierarchy_ext_embedded_layer_index, указываемого в ассоциированном дескрипторе расширения иерархий, DTS-значение tdy+1(jy+1) VSy+1(jy+1) должно быть равно DTS-значению tdy(jy) VSy(jy).
Далее указывается удаление единицы AH(j) доступа из буфера BH:
Во время tdH(jH) декодирования, HEVC-единица AH(jH) доступа должна повторно собираться и быть доступной для удаления из буфера BH. Время tdH(j) декодирования указывается посредством DTS или посредством времени удаления из CPB, которое ассоциировано с поднаборами изображений HEVC-слоев в элементарном потоке ESH, извлеченного из информации в повторно собранном AVC-видеопотоке.
STD-задержка
STD-задержка для повторно собранных HEVC-единиц доступа должна соответствовать ограничениям, указываемым в 2.17.1.
Условия управления буфером
Программные потоки должны иметь такую структуру, что следующие условия для управления буфером удовлетворяются:
- BH не должен переполняться.
- BH не должен опустошаться, кроме тех случаев, когда VUI-параметры присутствуют для HEVC-видеопоследовательности повторно собранного HEVC-видеопотока с low_delay_hrd_flag, заданным равным 1, либо когда состояние trick_mode является истинным. Опустошение BH возникает для AVC-единицы AH(j) доступа, когда один или более байтов AH(j) не присутствуют в BH во время tdH(j) декодирования.
[0189] Технологии, описанные в этом раскрытии сущности, могут выполняться посредством любого множества устройств видеообработки, таких как видеокодер 20, видеодекодер 30, или других устройств, таких как механизмы сращивания, мультимедийно-ориентированные сетевые элементы (MANE), серверы потоковой передачи, маршрутизаторы и другие устройства, которые кодируют, декодируют, собирают, составляют, извлекают или иным образом обрабатывают кодированные потоки видеобитов.
[0190] Фиг. 6 является блок-схемой, иллюстрирующей примерный видеокодер 20, который может быть выполнен с возможностью реализовывать технологии этого раскрытия сущности, к примеру, технологии для переноса потоков битов многослойного HEVC-расширения, включающих в себя потоки битов расширения многовидового HEVC (MV-HEVC), масштабируемого HEVC (SHVC) и трехмерного HEVC (3D-HEVC), с помощью MPEG-2-систем.
[0191] Это раскрытие сущности описывает видеокодер 20 в контексте HEVC-кодирования, а более конкретно, расширений MV-HEVC-, SHVC- и 3D-HEVC-кодирования. Тем не менее, технологии этого раскрытия сущности могут быть применимыми к другим стандартам или способам кодирования видео. Соответственно, фиг. 6 предоставляется для целей пояснения и не должен считаться ограничением технологий, проиллюстрированных и описанных в общих чертах в этом раскрытии сущности.
[0192] В примере по фиг. 6, видеокодер 20 включает в себя процессор 100 прогнозирования, запоминающее устройство 101 видеоданных, модуль 102 формирования остатков, процессор 104 преобразования, модуль 106 квантования, модуль 108 обратного квантования, процессор 110 обратного преобразования, модуль 112 восстановления, модуль 114 фильтрации, буфер 116 декодированных изображений и модуль 118 энтропийного кодирования. Процессор 100 прогнозирования включает в себя процессор 120 взаимного прогнозирования и процессор 126 внутреннего прогнозирования. Процессор 120 взаимного прогнозирования включает в себя модуль 122 оценки движения (ME) и модуль 124 компенсации движения.
[0193] Компоненты процессора 100 прогнозирования описываются как выполняющие как кодирование текстуры, так и кодирование глубины. В некоторых примерах, кодирование текстуры и глубины может выполняться посредством идентичных компонентов процессора 100 прогнозирования или различных компонентов в процессоре 100 прогнозирования. Например, отдельные кодеры текстуры и глубины могут предоставляться в некоторых реализациях. Кроме того, несколько кодеров текстуры и глубины могут предоставляться для того, чтобы кодировать несколько видов, например, для многовидового кодирования с учетом глубины. Видеокодер 20 может включать в себя большее число, меньшее число или другие функциональные компоненты по сравнению с функциональными компонентами, показанными на фиг. 6.
[0194] В некоторых примерах, процессор 100 прогнозирования может работать практически в соответствии с MV-HEVC, SHVC или 3D-HEVC, например, согласно модификациям и/или добавлениям, описанным в этом раскрытии сущности. Процессор 100 прогнозирования может предоставлять синтаксическую информацию в модуль 118 энтропийного кодирования. Синтаксическая информация может указывать, например, то, какие режимы прогнозирования использованы, и информацию, связанную с такими режимами.
[0195] Видеокодер 20 принимает видеоданные, которые должны кодироваться. Запоминающее устройство 101 видеоданных может сохранять видеоданные, которые должны кодироваться посредством компонентов видеокодера 20. Видеоданные, сохраненные в запоминающем устройстве 101 видеоданных, могут получаться, например, из видеоисточника 18. Буфер 116 декодированных изображений может представлять собой запоминающее устройство опорных изображений, которое сохраняет опорные видеоданные для использования при кодировании видеоданных посредством видеокодера 20, например, в режимах внутреннего или взаимного кодирования. Запоминающее устройство 101 видеоданных и буфер 116 декодированных изображений могут формироваться посредством любого из множества запоминающих устройств, к примеру, как динамическое оперативное запоминающее устройство (DRAM), включающее в себя синхронное DRAM (SDRAM), магниторезистивное RAM (MRAM), резистивное RAM (RRAM) или другие типы запоминающих устройств. Запоминающее устройство 101 видеоданных и буфер 116 декодированных изображений могут предоставляться посредством идентичного запоминающего устройства или отдельных запоминающих устройств. В различных примерах, запоминающее устройство 101 видеоданных может быть внутрикристальным с другими компонентами видеокодера 20 или внекристальным относительно этих компонентов.
[0196] Видеокодер 20 может кодировать каждую из множества единиц дерева кодирования (CTU) в серии последовательных макроблоков изображения видеоданных. Каждая из CTU может быть ассоциирована с блоками дерева кодирования (CTB) сигнала яркости одинакового размера и соответствующими CTB сигнала цветности изображения. В качестве части кодирования CTU, процессор 100 прогнозирования может выполнять сегментацию на дерево квадрантов для того, чтобы разделять CTB CTU на постепенно меньшие блоки. Меньший блок может представлять собой блоки кодирования CU. Например, процессор 100 прогнозирования может сегментировать CTB, ассоциированный с CTU, на четыре субблока одинакового размера, сегментировать один или более субблоков на четыре субсубблока одинакового размера и т.д.
[0197] Видеокодер 20 может кодировать CU CTB, чтобы формировать кодированные представления CU (т.е. кодированные CU). В качестве части кодирования CU, процессор 100 прогнозирования может сегментировать блоки кодирования, ассоциированные с CU, из числа одной или более PU CU. Таким образом, каждая PU может быть ассоциирована с прогнозным блоком сигналов яркости и соответствующими прогнозными блоками сигнала цветности.
[0198] Видеокодер 20 и видеодекодер 30 могут поддерживать PU, имеющие различные размеры. Как указано выше, размер CU может означать размер блока кодирования сигналов яркости CU, и размер PU может означать размер прогнозного блока сигналов яркости PU. При условии, что размер конкретной CU составляет 2Nx2N, видеокодер 20 и видеодекодер 30 могут поддерживать PU-размеры 2Nx2N или NxN для внутреннего прогнозирования и симметричные PU-размеры 2Nx2N, 2NxN, Nx2N, NxN или аналогичные для взаимного прогнозирования. Видеокодер 20 и видеодекодер 30 также могут поддерживать асимметричное сегментирование для PU-размеров 2NxnU, 2NxnD, nLx2N и nRx2N для взаимного прогнозирования. В соответствии с аспектами этого раскрытия сущности, видеокодер 20 и видеодекодер 30 также поддерживают непрямоугольные сегменты PU для взаимного кодирования глубины.
[0199] Процессор 120 взаимного прогнозирования может формировать прогнозирующие данные для PU посредством выполнения взаимного прогнозирования для каждой PU CU. Прогнозирующие данные для PU могут включать в себя прогнозирующие блоки, которые соответствуют PU, и информацию движения для PU. Процессор 120 взаимного прогнозирования может выполнять различные операции для PU CU в зависимости от того, находится PU в серии последовательных I-макроблоков, серии последовательных P-макроблоков или серии последовательных B-макроблоков. В серии последовательных I-макроблоков все PU внутренне прогнозируются. Следовательно, если PU находится в серии последовательных I-макроблоков, процессор 120 взаимного прогнозирования не выполняет взаимное прогнозирование для PU. Таким образом, для блоков, кодированных в I-режиме, прогнозирующий блок формируется с использованием пространственного прогнозирования из ранее кодированных соседних блоков в идентичном изображении.
[0200] Если PU находится в серии последовательных P-макроблоков, модуль 122 оценки движения (ME) может выполнять поиск в опорных изображениях в списке опорных изображений (например, в RefPicList0) на предмет опорной области для PU. Опорные изображения могут сохраняться в буфере 116 декодированных изображений. Опорная область для PU может представлять собой область, в опорном изображении, которая содержит блоки выборок, которые наиболее близко соответствуют блокам выборок PU. Модуль 122 оценки движения (ME) может формировать опорный индекс, который указывает позицию в RefPicList0 опорного изображения, содержащего опорную область для PU.
[0201] Помимо этого, для внутреннего кодирования, модуль 122 оценки движения (ME) может формировать вектор движения (MV), который указывает пространственное смещение между блоком кодирования PU и опорным местоположением, ассоциированным с опорной областью. Например, MV может представлять собой двумерный вектор, который предоставляет смещение от координат в текущем изображении на координаты в опорном изображении. Модуль 122 оценки движения (ME) может выводить опорный индекс и MV в качестве информации движения PU. Модуль 124 компенсации движения (MC) может формировать прогнозирующие блоки выборок PU на основе фактических или интерполированных выборок в опорном местоположении, указываемом посредством вектора движения PU.
[0202] Если PU находится в серии последовательных B-макроблоков, модуль 122 оценки движения может выполнять унипрогнозирование или бипрогнозирование для PU. Чтобы выполнять унипрогнозирование для PU, модуль 122 оценки движения может выполнять поиск в опорных изображениях RefPicList0 или второго списка опорных изображений (RefPicList1) на предмет опорной области для PU. Модуль 122 оценки движения (ME) может выводить, в качестве информации движения PU, опорный индекс, который указывает позицию в RefPicList0 или RefPicList1 опорного изображения, которое содержит опорную область, MV, который указывает пространственное смещение между блоком выборок PU и опорным местоположением, ассоциированным с опорной областью, и один или более индикаторов направления прогнозирования, которые указывают то, находится опорное изображение в RefPicList0 или в RefPicList1. Модуль 124 компенсации движения (MC) может формировать прогнозирующие блоки PU, по меньшей мере, частично на основе фактических или интерполированных выборок в опорной области, указываемой посредством вектора движения PU.
[0203] Чтобы выполнять двунаправленное взаимное прогнозирование для PU, модуль 122 оценки движения может выполнять поиск в опорных изображениях RefPicList0 на предмет опорной области для PU, а также может выполнять поиск в опорных изображениях RefPicList1 на предмет другой опорной области для PU. Модуль 122 оценки движения (ME) может формировать индексы опорных изображений, которые указывают позиции в RefPicList0 и RefPicList1 опорных изображений, которые содержат опорные области. Помимо этого, модуль 122 оценки движения (ME) может формировать MV, которые указывают пространственные смещения между опорным местоположением, ассоциированным с опорными областями, и блоком выборок PU. Информация движения PU может включать в себя опорные индексы и MV PU. Модуль 124 компенсации движения (MC) может формировать прогнозирующие блоки PU, по меньшей мере, частично на основе фактических или интерполированных выборок в опорной области, указываемой посредством вектора движения PU.
[0204] Процессор 126 внутреннего прогнозирования может формировать прогнозирующие данные для PU посредством выполнения внутреннего прогнозирования для PU. Внутренние прогнозирующие данные для PU могут включать в себя прогнозирующие блоки для PU и различные элементы синтаксиса. Процессор 126 внутреннего прогнозирования может выполнять внутреннее прогнозирование для PU в сериях последовательных I-макроблоков, сериях последовательных P-макроблоков и сериях последовательных B-макроблоков. Чтобы выполнять внутреннее прогнозирование для PU, процессор 126 внутреннего прогнозирования может использовать несколько режимов внутреннего прогнозирования для того, чтобы формировать несколько наборов из прогнозирующих данных для PU, и затем выбирать один из режимов внутреннего прогнозирования, который дает в результате приемлемую или оптимальную производительность кодирования, например, с использованием технологий оптимизации искажения в зависимости от скорости передачи.
[0205] Чтобы использовать некоторые режимы внутреннего прогнозирования для того, чтобы формировать набор прогнозирующих данных для PU, процессор 126 внутреннего прогнозирования может расширять выборки из блоков выборок пространственно соседних PU через блоки выборок PU в направлении, ассоциированном с режимом внутреннего прогнозирования. Соседние PU могут располагаться выше, выше и справа, выше и слева или слева от PU, при условии порядка кодирования слева направо, сверху вниз для PU, CU и CTU. Процессор 126 внутреннего прогнозирования может использовать различные числа режимов внутреннего прогнозирования, например, 33 режима направленного внутреннего прогнозирования. В некоторых примерах, число режимов внутреннего прогнозирования может зависеть от размера области, ассоциированной с PU.
[0206] Процессор 100 прогнозирования может выбирать прогнозирующие данные для PU CU из числа прогнозирующих данных, сформированных посредством процессора 120 взаимного прогнозирования для PU, или прогнозирующих данных, сформированных посредством процессора 126 внутреннего прогнозирования для PU. В некоторых примерах, процессор 100 прогнозирования выбирает прогнозирующие данные для PU CU на основе показателей искажения в зависимости от скорости передачи наборов прогнозирующих данных. Прогнозирующие блоки выбранных прогнозирующих данных могут упоминаться в данном документе как выбранные прогнозирующие блоки.
[0207] Модуль 102 формирования остатков может формировать, на основе блока кодирования (например, блока кодирования сигналов яркости, Cb-блока кодирования или Cr-блока кодирования) CU и выбранного взаимного или внутреннего прогнозирующего блока (например, прогнозирующего блока сигналов яркости, прогнозирующего Cb-блока или прогнозирующего Cr-блока) PU CU, остаточный блок (например, остаточный блок сигналов яркости, остаточный Cb-блок или остаточный Cr-блок) CU. Например, модуль 102 формирования остатков может формировать остаточные блоки CU таким образом, что каждая выборка в остаточных блоках имеет значение, равное разности между выборкой в блоке кодирования CU и соответствующей выборкой, т.е. в пиксельном значении сигнала яркости или сигнала цветности, при соответствующих условиях, в соответствующем выбранном прогнозирующем блоке выборок PU CU.
[0208] Процессор 104 преобразования может выполнять сегментацию на дерево квадрантов для того, чтобы сегментировать остаточные блоки, ассоциированные с CU, на блоки преобразования, ассоциированные с TU CU. Таким образом, TU может быть ассоциирована с блоком преобразования сигналов яркости и двумя блоками преобразования сигналов цветности. Размеры и позиции блоков преобразования сигналов яркости и сигналов цветности TU CU могут быть основаны либо могут не быть основаны на размерах и позициях прогнозных блоков PU CU. Структура в виде дерева квадрантов, известная как "остаточное дерево квадрантов" (RQT), может включать в себя узлы, ассоциированные с каждой из областей. TU CU могут соответствовать концевым узлам RQT.
[0209] Для регулярного остаточного кодирования, процессор 104 преобразования может формировать блоки коэффициентов преобразования для каждой TU CU посредством применения одного или более преобразований к блокам преобразования TU. Процессор 104 преобразования может применять различные преобразования к блоку преобразования, ассоциированному с TU. Например, процессор 104 преобразования может применять дискретное косинусное преобразование (DCT), направленное преобразование или концептуально аналогичное преобразование к блоку преобразования. В некоторых примерах, процессор 104 преобразования не применяет преобразования к блоку преобразования. В таких примерах, блок преобразования может трактоваться в качестве блока коэффициентов преобразования.
[0210] Модуль 106 квантования, для регулярного остаточного кодирования, может квантовать остаточные коэффициенты преобразования в блоке коэффициентов. Процесс квантования может уменьшать битовую глубину, ассоциированную с некоторыми или всеми коэффициентами преобразования. Например, n-битовый коэффициент преобразования может округляться в меньшую сторону до m-битового коэффициента преобразования во время квантования, где n превышает m. Модуль 106 квантования может квантовать блок коэффициентов TU CU на основе значения параметра квантования (QP), ассоциированного с CU. Видеокодер 20 может регулировать степень квантования, применяемого к блокам коэффициентов, ассоциированным с CU, посредством регулирования QP-значения, ассоциированного с CU. Квантование может вводить потери информации, в силу чего квантованные коэффициенты преобразования могут иметь меньшую точность по сравнению с исходными коэффициентами преобразования.
[0211] Модуль 108 обратного квантования и процессор 110 обратного преобразования могут применять обратное квантование и обратные преобразования к блоку коэффициентов, соответственно, для того чтобы восстанавливать остаточный блок из блока коэффициентов. Модуль 112 восстановления может суммировать восстановленный остаточный блок с соответствующими выборками из одного или более прогнозирующих блоков выборок, сформированных посредством процессора 100 прогнозирования, для того чтобы формировать восстановленный блок преобразования, ассоциированный с TU. Посредством восстановления блоков преобразования для каждой TU CU таким способом, видеокодер 20 может восстанавливать блоки кодирования CU.
[0212] Модуль 114 фильтрации может выполнять одну или более операций фильтрации, чтобы уменьшать артефакты, к примеру, артефакты блочности, в блоках кодирования, ассоциированных с восстановленной CU. Операции фильтрации могут включать в себя одно или более из следующего: удаление блочности, чтобы удалять блочность на границах блоков, контурную фильтрацию, чтобы сглаживать пиксельные переходы, фильтрацию на основе дискретизированного адаптивного смещения, чтобы сглаживать пиксельные переходы, либо возможно другие типы операций или технологий фильтрации. Буфер 116 декодированных изображений может сохранять восстановленные блоки кодирования после того, как модуль 114 фильтрации выполняет одну или более операций удаления блочности для восстановленных блоков кодирования. Процессор 120 взаимного прогнозирования может использовать опорное изображение, которое содержит восстановленные блоки кодирования, для того чтобы выполнять взаимное прогнозирование для PU других изображений. Помимо этого, процессор 126 внутреннего прогнозирования может использовать восстановленные блоки кодирования в буфере 116 декодированных изображений для того, чтобы выполнять внутреннее прогнозирование для других PU в изображении, идентичном изображению CU.
[0213] Модуль 118 энтропийного кодирования может принимать данные из различных функциональных компонентов видеокодера 20. Например, модуль 118 энтропийного кодирования может принимать блоки коэффициентов из модуля 106 квантования и может принимать элементы синтаксиса из процессора 100 прогнозирования. Модуль 118 энтропийного кодирования может выполнять одну или более операций энтропийного кодирования для данных, чтобы формировать энтропийно кодированные данные. Например, модуль 118 энтропийного кодирования может выполнять CABAC-операцию. Примеры других процессов энтропийного кодирования включают в себя контекстно-адаптивное кодирование переменной длины (CAVLC), синтаксическое контекстно-адаптивное двоичное арифметическое кодирование (SBAC) и энтропийное кодирование на основе сегментации на интервалы вероятности (PIPE). В HEVC, используется CABAC. Видеокодер 20 может выводить поток битов, который включает в себя энтропийно кодированные данные, сформированные посредством модуля 118 энтропийного кодирования. Например, поток битов может включать в себя биты, которые представляют элементы выборки двоичных элементов синтаксиса или преобразованных в двоичную форму элементов синтаксиса.
[0214] Фиг. 7 является блок-схемой, иллюстрирующей примерный видеодекодер 30, который выполнен с возможностью осуществлять технологии этого раскрытия сущности, к примеру, технологии для переноса потоков битов многослойного HEVC-расширения, включающих в себя потоки битов расширения многовидового HEVC (MV-HEVC), масштабируемого HEVC (SHVC) и трехмерного HEVC (3D-HEVC), с помощью MPEG-2-систем. Фиг. 7 предоставляется в целях иллюстрации и не должен считаться ограничением технологий, проиллюстрированных и описанных в общих чертах в этом раскрытии сущности. Это раскрытие сущности описывает видеодекодер 30 в контексте расширений HEVC-кодирования и, в частности, расширений MV-HEVC-, SHVC- и 3D-HEVC-кодирования. Тем не менее, технологии этого раскрытия сущности могут быть применимыми к другим стандартам или способам кодирования видео. Соответственно, фиг. 7 предоставляется для целей пояснения и не должен считаться ограничением технологий, проиллюстрированных и описанных в общих чертах в этом раскрытии сущности.
[0215] В примере по фиг. 7, видеодекодер 30 включает в себя модуль 150 энтропийного декодирования, процессор 152 прогнозирования, модуль 154 обратного квантования, процессор 156 обратного преобразования, модуль 158 восстановления, модуль 160 фильтрации и буфер 162 декодированных изображений. Процессор 152 прогнозирования включает в себя модуль 164 компенсации движения (MC) для взаимного прогнозирования и процессор 166 внутреннего прогнозирования. Для простоты иллюстрации, компоненты процессора 152 прогнозирования описываются как выполняющие как декодирование текстуры, так и декодирование глубины. В некоторых примерах, декодирование текстуры и глубины может выполняться посредством идентичных компонентов процессора 152 прогнозирования или различных компонентов в процессоре 152 прогнозирования. Например, отдельные декодеры текстуры и глубины могут предоставляться в некоторых реализациях. Кроме того, несколько декодеров текстуры и глубины могут предоставляться для того, чтобы декодировать несколько видов, например, для многовидового кодирования с учетом глубины. В любом случае, процессор 152 прогнозирования может быть выполнен с возможностью внутренне или взаимно декодировать данные текстуры и данные глубины в качестве части процесса трехмерного кодирования, к примеру, 3D-HEVC-процесса.
[0216] Соответственно, процессор 152 прогнозирования может работать практически в соответствии с MV-HEVC, SHVC или 3D-HEVC согласно модификациям и/или добавлениям, описанным в этом раскрытии сущности. Процессор 152 прогнозирования может получать остаточные данные из кодированного потока видеобитов для внутренне декодированных или взаимно декодированных данных глубины через модуль 150 энтропийного декодирования и восстанавливать CU с использованием внутренне прогнозированных или взаимно прогнозированных данных глубины и остаточных данных. В некоторых примерах, видеодекодер 30 может включать в себя большее число, меньшее число или другие функциональные компоненты по сравнению с функциональными компонентами, показанными на фиг. 7.
[0217] Видеодекодер 30 принимает кодированный поток видеобитов. Буфер 151 кодированных изображений (CPB) может принимать и сохранять кодированные видеоданные (например, NAL-единицы) потока битов. Видеоданные, сохраненные в CPB 151, могут получаться, например, из компьютерно-читаемого носителя 16, например, из локального видеоисточника, к примеру, камеры, через передачу видеоданных по проводной или беспроводной сети или посредством осуществления доступа к физическим носителям хранения данных. CPB 151 может формировать запоминающее устройство видеоданных, которое сохраняет кодированные видеоданные из кодированного потока видеобитов. Буфер 162 декодированных изображений может представлять собой запоминающее устройство опорных изображений, которое сохраняет опорные видеоданные для использования при декодировании видеоданных посредством видеодекодера 30, например, в режимах внутреннего или взаимного кодирования. CPB 151 и буфер 162 декодированных изображений могут формироваться посредством любого из множества запоминающих устройств, к примеру, как динамическое оперативное запоминающее устройство (DRAM), включающее в себя синхронное DRAM (SDRAM), магниторезистивное RAM (MRAM), резистивное RAM (RRAM) или другие типы запоминающих устройств. CPB 151 и буфер 162 декодированных изображений могут предоставляться посредством идентичного запоминающего устройства или отдельных запоминающих устройств. В различных примерах, CPB 151 может быть внутрикристальным с другими компонентами видеодекодера 30 или внекристальным относительно этих компонентов.
[0218] Модуль 150 энтропийного декодирования синтаксически анализирует поток битов, чтобы декодировать энтропийно кодированные элементы синтаксиса из потока битов. В некоторых примерах, модуль 150 энтропийного декодирования может быть выполнен с возможностью использовать CABAC-кодер для того, чтобы декодировать, из битов в потоке битов, элементы выборки для элементы синтаксиса. Модуль 150 энтропийного декодирования может использовать CABAC-кодер для того, чтобы декодировать множество других элементов синтаксиса для различных режимов кодирования, включающих в себя режимы внутреннего или взаимного кодирования.
[0219] Процессор 152 прогнозирования, модуль 154 обратного квантования, процессор 156 обратного преобразования, модуль 158 восстановления и модуль 160 фильтрации могут формировать декодированные видеоданные на основе элементов синтаксиса, извлеченных из потока битов. Поток битов может содержать последовательность NAL-единиц. NAL-единицы потока битов могут включать в себя NAL-единицы кодированных серий последовательных макроблоков. В качестве части декодирования потока битов, модуль 150 энтропийного декодирования может извлекать и энтропийно декодировать элементы синтаксиса из NAL-единиц кодированных серий последовательных макроблоков. Некоторые элементы синтаксиса потока битов не кодируются или декодируются энтропийно.
[0220] Каждая из кодированных серий последовательных макроблоков может включать в себя заголовок серии последовательных макроблоков и данные серии последовательных макроблоков. Заголовок серии последовательных макроблоков может содержать элементы синтаксиса, связанные с серией последовательных макроблоков. Элементы синтаксиса в заголовке серии последовательных макроблоков могут включать в себя элемент синтаксиса, который идентифицирует PPS, ассоциированный с изображением, которое содержит серию последовательных макроблоков. PPS может означать SPS, который может, в свою очередь, означать VPS. Модуль 150 энтропийного декодирования также может энтропийно декодировать другие элементы, которые могут включать в себя синтаксическую информацию, к примеру, SEI-сообщения. Декодированные элементы синтаксиса в любом из заголовка серии последовательных макроблоков, наборов параметров или SEI-сообщений могут включать в себя информацию, описанную в данном документе как передаваемую в служебных сигналах в соответствии с примерными технологиями, описанными в этом раскрытии сущности. Такая синтаксическая информация может предоставляться в процессор 152 прогнозирования для декодирования и восстановления блоков текстуры или глубины.
[0221] Видеодекодер 30 может выполнять операцию восстановления для несегментированных CU и PU. Чтобы выполнять операцию восстановления, видеодекодер 30 может выполнять операцию восстановления для каждой TU CU. Посредством выполнения операции восстановления для каждой TU CU, видеодекодер 30 может восстанавливать блоки CU. В качестве части выполнения операции восстановления для TU CU, модуль 154 обратного квантования может обратно квантовать, т.е. деквантовать, блоки коэффициентов, ассоциированные с TU. Модуль 154 обратного квантования может использовать QP-значение, ассоциированное с CU TU, для того чтобы определять степень квантования и, аналогично, степень обратного квантования для модуля 154 обратного квантования, которое должно применяться. Иными словами, коэффициент сжатия, т.е. соотношение числа битов, используемых для того, чтобы представлять исходную последовательность и сжатую последовательность, может управляться посредством регулирования значения QP, используемого при квантовании коэффициентов преобразования. Коэффициент сжатия также может зависеть от используемого способа энтропийного кодирования.
[0222] После того, как модуль 154 обратного квантования обратно квантует блок коэффициентов, процессор 156 обратного преобразования может применять одно или более обратных преобразований к блоку коэффициентов, чтобы формировать остаточный блок, ассоциированный с TU. Например, процессор 156 обратного преобразования может применять обратное DCT, обратное целочисленное преобразование, обратное преобразование Карунена-Лоэва (KLT), обратное вращательное преобразование, обратное направленное преобразование или другое обратное преобразование к блоку коэффициентов.
[0223] Если PU кодируется с использованием внутреннего прогнозирования, процессор 166 внутреннего прогнозирования может выполнять внутреннее прогнозирование для того, чтобы формировать прогнозирующие блоки для PU. Процессор 166 внутреннего прогнозирования может использовать режим внутреннего прогнозирования для того, чтобы формировать прогнозирующие блоки (например, прогнозирующие блоки сигналов яркости, прогнозирующие Cb-блоки и прогнозирующие Cr-блоки) для PU на основе прогнозных блоков пространственно соседних PU. Процессор 166 внутреннего прогнозирования может определять режим внутреннего прогнозирования для PU на основе одного или более элементов синтаксиса, декодированных из потока битов.
[0224] Если PU кодируется с использованием взаимного прогнозирования, MC-модуль 164 может выполнять взаимное прогнозирование для того, чтобы формировать взаимный прогнозирующий блок для PU. MC-модуль 164 может использовать режим взаимного прогнозирования для того, чтобы формировать прогнозирующие блоки (например, прогнозирующие блоки сигналов яркости, прогнозирующие Cb-блоки и прогнозирующие Cr-блоки) для PU на основе блоков в других изображениях или видах. MC-модуль 164 может определять режим взаимного прогнозирования для PU на основе одного или более элементов синтаксиса, декодированных из потока битов, и может принимать или определять информацию движения, к примеру, векторы движения, направление прогнозирования и индексы опорных изображений.
[0225] Для взаимного прогнозирования, MC-модуль 164 может составлять первый список опорных изображений (RefPicList0) и второй список опорных изображений (RefPicList1) на основе элементов синтаксиса, извлеченных из потока битов. Кроме того, если PU кодируется с использованием взаимного прогнозирования, модуль 150 энтропийного декодирования может извлекать или определять информацию движения для PU. MC-модуль 164 может определять, на основе информации движения PU, один или более опорных блоков для PU. Модуль 164 компенсации движения (MC) может формировать, на основе блоков выборок в одном или более опорных блоков для PU, прогнозирующие блоки (например, прогнозирующие блоки сигналов яркости, прогнозирующие Cb-блоки и прогнозирующие Cr-блоки) для PU.
[0226] Модуль 158 восстановления может использовать блоки преобразования (например, блоки преобразования сигналов яркости, Cb-блоки преобразования и Cr-блоки преобразования) TU CU и прогнозирующие блоки (например, прогнозирующие блоки сигналов яркости, прогнозирующие Cb-блоки и прогнозирующие Cr-блоки) PU CU, т.е. либо данные внутреннего прогнозирования, либо данные взаимного прогнозирования, при соответствующих условиях, для того чтобы восстанавливать блоки кодирования (например, блоки кодирования сигналов яркости, Cb-блоки кодирования и Cr-блоки кодирования) CU. Например, модуль 158 восстановления может суммировать остаточные выборки блоков преобразования сигналов яркости, Cb-блоков преобразования и Cr-блоков преобразования с соответствующими выборками прогнозирующих блоков сигналов яркости, прогнозирующих Cb-блоков и прогнозирующих Cr-блоков, чтобы восстанавливать блоки кодирования сигналов яркости, Cb-блоки кодирования и Cr-блоки кодирования CU.
[0227] Модуль 160 фильтрации может выполнять операцию удаления блочности, чтобы уменьшать артефакты блочности, ассоциированные с блоками кодирования (к примеру, с блоками кодирования сигналов яркости, Cb-блоками кодирования и Cr-блоками кодирования) CU. Видеодекодер 30 может сохранять блоки кодирования (к примеру, блоки кодирования сигналов яркости, Cb-блоки кодирования и Cr-блоки кодирования) CU в буфере 162 декодированных изображений. Буфер 162 декодированных изображений может предоставлять опорные изображения для последующей компенсации движения, внутреннего прогнозирования и представления на устройстве отображения, к примеру, на устройстве 32 отображения по фиг. 1. Например, видеодекодер 30 может выполнять, на основе блоков сигналов яркости, Cb-блоков и Cr-блоков в буфере 162 декодированных изображений, операции внутреннего прогнозирования или взаимного прогнозирования для PU других CU.
[0228] Различные технологии, описанные в этом раскрытии сущности, могут выполняться посредством видеокодера 20 (фиг. 1 и 6) и/или видеодекодера 30 (фиг. 1 и 7), оба из которых, в общем, могут упоминаться в качестве видеокодера. Помимо этого, кодирование видео, в общем, может означать кодирование видео и/или декодирование видео при соответствующих условиях.
[0229] Хотя технологии этого раскрытия сущности, в общем, описываются относительно MV-HEVC, SHVC и 3D-HEVC, технологии не обязательно ограничены таким образом. Технологии, описанные выше, также могут быть применимыми к другим действующим стандартам или будущим стандартам.
[0230] Фиг. 8 является блок-схемой последовательности операций способа, иллюстрирующей примерную работу видеодекодера 30, в соответствии с одной или более технологий этого раскрытия сущности. Работа по фиг. 8 и операции других блок-схем последовательности операций способа этого раскрытия сущности предоставляются в качестве примеров. Другие операции в соответствии с технологиями этого раскрытия сущности могут включать в себя большее число, меньшее число или другие действия.
[0231] В примере по фиг. 8, видеодекодер 30 принимает поток видеоданных, содержащий множество элементарных потоков (200). Кроме того, видеодекодер 30 собирает, в буферной модели, единицу доступа из множества элементарных потоков для потока видеоданных (202). В этом примере, поток видеоданных может представлять собой транспортный поток или программный поток. Идентичная буферная модель используется для сборки единицы доступа независимо от того, содержат ли элементарные потоки потоки битов по стандарту масштабируемого высокоэффективного кодирования видео (SHVC), многовидового HEVC (MV-HEVC) или 3D-HEVC. Кроме того, в примере по фиг. 8, видеодекодер 30 может декодировать единицу доступа (204). Единица доступа может содержать одно или более изображений видеоданных.
[0232] Фиг. 9 является блок-схемой последовательности операций способа, иллюстрирующей примерную работу видеодекодера 30, чтобы собирать и декодировать единицу доступа в соответствии с одной или более технологий этого раскрытия сущности. В примере по фиг. 9, видеодекодер 30 может определять набор элементарных потоков (например, программных элементов) для единицы доступа (250). Видеодекодер 30 может определять набор элементарных потоков для единицы доступа различными способами.
[0233] Например, видеодекодер 30 может декодировать текущую рабочую точку. В этом примере, дескриптор HEVC-расширения может указывать hevc_output_layer_flags для текущей рабочей точки. Hevc_output_layer_flags указывают то, находятся ли конкретные слои в наборе выходных слоев для текущей рабочей точки. Таким образом, в этом примере, видеодекодер 30 может определять, на основе hevc_output_layer_flags для текущей рабочей точки, набор выходных слоев для текущей рабочей точки. В этом примере, для каждого соответствующего выходного слоя в наборе выходных слоев для текущей рабочей точки, видеодекодер 30 может определять набор элементарных потоков. Для простоты пояснения, это раскрытие сущности называет определенный набор элементарных потоков как "выходной набор элементарных потоков". Каждый соответствующий элементарный поток в выходном наборе элементарных потоков соответствует соответствующему выходному слою текущей рабочей точки.
[0234] Кроме того, в этом примере, каждый соответствующий элементарный поток выходного набора элементарных потоков ассоциирован с соответствующим дескриптором расширения иерархий, который включает в себя соответствующий набор полей hierarchy_ext_embedded_layer_index. Соответствующий набор полей hierarchy_ext_embedded_layer_index идентифицирует зависимые элементарные потоки для соответствующего элементарного потока. Видеодекодер 30 включает в себя выходной набор элементарных потоков и зависимые элементарные потоки для каждого элементарного потока выходного набора элементарных потоков в наборе элементарных потоков для единицы доступа.
[0235] Кроме того, в примере по фиг. 9, видеодекодер 30 определяет то, включает ли в себя набор элементарных потоков для единицы доступа какие-либо необработанные элементарные потоки (252). В ответ на определение того, что набор элементарных потоков для единицы доступа включает в себя один или более необработанных элементарных потоков ("Да", 252), видеодекодер 30 может удалять поднабор изображений HEVC-слоев из буфера поднаборов изображений HEVC-слоев для одного из необработанных элементарных потоков (т.е. текущего элементарного потока) (254). Каждое изображение из поднабора изображений HEVC-слоев имеет временную метку декодирования, равную временной метке декодирования единицы доступа. Видеодекодер 30 может включать поднабор изображений HEVC-слоев в повторно собранную единицу доступа (256). В таком случае считается, что текущий элементарный поток должен быть обработан. Видеодекодер 30 затем может снова определять то, включает ли в себя набор элементарных потоков для единицы доступа один или более необработанных элементарных потоков (252).
[0236] Если нет оставшихся необработанных элементарных потоков, видеодекодер 30 включает в повторно собранную единицу доступа поднабор изображений HEVC-слоев для каждого элементарного потока из набора элементарных потоков для единицы доступа. Таким образом, в ответ на определение того, что нет оставшихся необработанных элементарных потоков ("Нет", 252), видеодекодер 30 может декодировать изображения единицы доступа (258).
[0237] Следующие параграфы описывают различные примеры технологий этого раскрытия сущности.
[0238] Пример 1. Способ обработки видеоданных, при этом способ содержит, для переноса потоков HEVC-расширения в MPEG-2-системе, использование буферных SHVC-, MV-HEVC- и 3D-HEVC-моделей, которые являются унифицированными в идентичной модели на основе слоев.
[0239] Пример 2. Способ по п. 1, в котором буферные модели включают в себя T-STD-модели и P-STD-модели.
[0240] Пример 3. Способ по примеру 1, в котором буферные модели являются аналогичными T-STD-модели и P-STD-модели, используемым для MVC.
[0241] Пример 4. Способ обработки видеоданных, при этом способ содержит, для переноса потоков HEVC-расширения в MPEG-2-системе, использование T-STD-модели и/или P-STD-модели для каждого многослойного HEVC-видеопотока, при этом каждый многослойный HEVC-видеопоток соответствует рабочей точке, которая собирается из многослойных HEVC-субпотоков видеобитов.
[0242] Пример 5. Способ по примеру 4, в котором многослойный HEVC-субпоток видеобитов содержит несколько субпотоков видеобитов HEVC-слоя, которые содержат VCL NAL-единицы с идентичным значением nuh_layer_id (идентификатора слоя) и их ассоциированные не-VCL NAL-единицы.
[0243] Пример 6. Способ обработки видеоданных, при этом способ содержит, для переноса потоков HEVC-расширения в MPEG-2-системе, при сборке изображений HEVC-слоев в единице доступа из нескольких потоков в T-STD- или P-STD-модели, использование значений hierarchy_ext_embedded_layer_index, указываемых в ассоциированном дескрипторе расширения иерархий, для того чтобы идентифицировать опорные слои, требуемые для декодирования выходных слоев текущей рабочей точки.
[0244] Пример 7. Способ обработки видеоданных, при этом способ содержит, для переноса потоков HEVC-расширения в MPEG-2-системе, использование HEVC-синхронизации и HRD-дескриптора, аналогично текущим HEVC MPEG-2-системам, по меньшей мере, для некоторых рабочих точек.
[0245] Пример 8. Способ по примеру 7, в котором HEVC-синхронизация и HRD-дескриптор могут представляться для каждой рабочей точки.
[0246] Пример 9. Способ по примеру 7, дополнительно содержащий использование, в HEVC_extension_descriptor, в цикле каждой рабочей точки, HEVC-синхронизации и HRD-дескриптора.
[0247] Пример 10. Способ по любому из примеров 7-9, в котором такая HEVC-синхронизация и HRD-дескриптор присутствуют только один раз для рабочих точек, совместно использующих идентичный набор идентификаторов слоев для слоев, которые должны быть декодированы.
[0248] Пример 11. Способ по любому из примеров 7-9, в котором такая HEVC-синхронизация и HRD-дескриптор присутствуют только один раз для всех рабочих точек всех наборов выходных слоев.
[0249] Пример 12. Способ обработки видеоданных, при этом способ содержит, для переноса потоков HEVC-расширения в MPEG-2-системе, использование NAL-единицы разделителя изображений слоя.
[0250] Пример 13. Способ по примеру 12, в котором NAL-единица разделителя изображений слоя содержит синтаксическую структуру, идентичную синтаксической структуре заголовка NAL-единицы в HEVC, и имеет следующие элементы синтаксиса: forbidden_zero_bit, nal_unit_type, nuh_layer_id и nuh_temporal_id_plus1.
[0251] Пример 14. Способ по примеру 12, в котором nal_unit_type NAL-единицы разделителя изображений слоя задается равным 0x30 (т.е. 48).
[0252] Пример 15. Способ по примеру 12, в котором различный тип NAL-единицы в диапазоне 0x30-0x3F, включительно (т.е. 48-63, включительно), которые помечаются как "неуказанные" в HEVC-спецификации, используется для NAL-единицы разделителя изображений слоя.
[0253] Пример 16. Способ по примеру 12, в котором значения nuh_layer_id и nuh_temporal_id_plus1 задается равным значениям ассоциированного изображения, для которого VCL NAL-единицы идут сразу после NAL-единицы разделителя изображений слоя.
[0254] Пример 17. Способ по примеру 16, в котором, в каждом элементарном потоке с stream_type, равным 0x26, точно один LPD_nal_unit может предшествовать всем NAL-единицам со значениями nuh_layer_id и nuh_temporal_id_plus1, равными значениям LPD_nal_unit.
[0255] Пример 18. Способ по примеру 16, в котором значения nuh_layer_id и nuh_temporal_id_plus1 задаются фиксированно равными 0 и 0.
[0256] Пример 19. Способ по примеру 16, в котором nuh_temporal_id_plus1 задается равным 0, чтобы указывать то, что эта NAL-единица является NAL-единицей разделителя изображений слоя.
[0257] Пример 20. Способ по примеру 16, в котором, в каждом элементарном потоке с stream_type, равным 0x26, точно один LPD_nal_unit может предшествовать всем NAL-единицам со значением nuh_layer_id, равным значению LPD_nal_unit.
[0258] Пример 21. Способ по примеру 16, в котором, в каждом элементарном потоке с stream_type, равным 0x26, точно один LPD_nal_unit может предшествовать всем NAL-единицам со значением, принадлежащим набору идентификаторов HEVC-слоев, минимальное значение которого равно nuh_layer_id LPD_nal_unit.
[0259] Пример 22. Способ сборки видеоданных, содержащей любую комбинацию способов по примерам 1-21.
[0260] Пример 23. Способ, содержащий любую комбинацию способов по примерам 1-21.
[0261] Пример 24. Устройство для обработки видеоданных, при этом устройство содержит: запоминающее устройство, сохраняющее видеоданные; и один или более процессоров, выполненных с возможностью осуществлять способ по любому из примеров 1-23.
[0262] Пример 25. Устройство по примеру 24, при этом устройство представляет собой видеодекодер.
[0263] Пример 26. Устройство по примеру 24, при этом устройство представляет собой видеокодер.
[0264] Пример 27. Устройство по примеру 24, при этом устройство представляет собой устройство сращивания потоков битов.
[0265] Пример 28. Устройство по примеру 24, при этом устройство представляет собой мультимедийно-ориентированный сетевой элемент.
[0266] Пример 29. Устройство для обработки видеоданных, причем устройство содержит средство для осуществления способа по любому из примеров 1-23.
[0267] Пример 30. Устройство по примеру 29, при этом устройство содержит видеокодер или видеодекодер.
[0268] Пример 31. Энергонезависимый компьютерно-читаемый носитель хранения данных, содержащий инструкции, чтобы инструктировать одному или более процессоров устройства видеообработки осуществлять способ по любому из примеров 1-23.
[0269] В одном или более примеров, описанные функции могут быть реализованы в аппаратных средствах, программном обеспечении, микропрограммном обеспечении или в любой комбинации вышеозначенного. При реализации в программном обеспечении, функции могут быть сохранены или переданы, в качестве одной или более инструкций или кода, по компьютерно-читаемому носителю и выполнены посредством аппаратного процессора. Компьютерно-читаемые носители могут включать в себя компьютерно-читаемые носители хранения данных, которые соответствуют материальному носителю, такие как носители хранения данных, или среды связи, включающие в себя любой носитель, который упрощает перенос компьютерной программы из одного места в другое, например, согласно протоколу связи. Таким образом, компьютерно-читаемые носители, в общем, могут соответствовать (1) материальному компьютерно-читаемому носителю хранения данных, который является энергонезависимым, или (2) среде связи, такой как сигнал или несущая. Носители хранения данных могут представлять собой любые доступные носители, к которым может осуществляться доступ посредством одного или более компьютеров или одного или более процессоров, с тем чтобы извлекать инструкции, код и/или структуры данных для реализации технологий, описанных в этом раскрытии сущности. Компьютерный программный продукт может включать в себя компьютерно-читаемый носитель.
[0270] В качестве примера, а не ограничения, эти компьютерно-читаемые носители хранения данных могут содержать RAM, ROM, EEPROM, CD-ROM или другое устройство хранения на оптических дисках, устройство хранения на магнитных дисках или другие магнитные устройства хранения, флэш-память либо любой другой носитель, который может быть использован для того, чтобы сохранять требуемый программный код в форме инструкций или структур данных, и к которому можно осуществлять доступ посредством компьютера. Так же, любое подключение корректно называть компьютерно-читаемым носителем. Например, если инструкции передаются из веб-узла, сервера или другого удаленного источника с помощью коаксиального кабеля, оптоволоконного кабеля, "витой пары", цифровой абонентской линии (DSL) или беспроводных технологий, таких как инфракрасные, радиопередающие и микроволновые среды, то коаксиальный кабель, оптоволоконный кабель, "витая пара", DSL или беспроводные технологии, такие как инфракрасные, радиопередающие и микроволновые среды, включаются в определение носителя. Тем не менее, следует понимать, что компьютерно-читаемые носители хранения данных и носители хранения данных не включают в себя соединения, несущие, сигналы или другие энергозависимые носители, а вместо этого направлены на энергонезависимые материальные носители хранения данных. Диск (disk) и диск (disc) при использовании в данном документе включают в себя компакт-диск (CD), лазерный диск, оптический диск, универсальный цифровой диск (DVD), гибкий диск и диск Blu-Ray, при этом диски (disk) обычно воспроизводят данные магнитно, тогда как диски (disc) обычно воспроизводят данные оптически с помощью лазеров. Комбинации вышеперечисленного также следует включать в число компьютерно-читаемых носителей.
[0271] Инструкции могут выполняться посредством одного или более процессоров, например, одного или более процессоров цифровых сигналов (DSP), микропроцессоров общего назначения, специализированных интегральных схем (ASIC), программируемых пользователем вентильных матриц (FPGA) либо других эквивалентных интегральных или дискретных логических схем. Соответственно, термин "процессор" при использовании в данном документе может означать любую вышеуказанную структуру или другую структуру, подходящую для реализации технологий, описанных в данном документе. Помимо этого, в некоторых аспектах функциональность, описанная в данном документе, может быть предоставлена в рамках специализированных программных и/или аппаратных модулей, выполненных с возможностью кодирования или декодирования либо встроенных в комбинированный кодек. Кроме того, технологии могут быть полностью реализованы в одной или более схем или логических элементов.
[0272] Технологии этого раскрытия сущности могут быть реализованы в широком спектре устройств или приборов, в том числе в беспроводном переносном телефоне, в интегральной схеме (IC) или в наборе IC (к примеру, в наборе микросхем). Различные компоненты, модули или блоки описываются в этом раскрытии сущности для того, чтобы подчеркивать функциональные аспекты устройств, выполненных с возможностью осуществлять раскрытые технологии, но необязательно требуют реализации посредством различных аппаратных модулей. Наоборот, как описано выше, различные блоки могут быть комбинированы в аппаратный модуль кодека или предоставлены посредством набора взаимодействующих аппаратных модулей, включающих в себя один или более процессоров, как описано выше, в сочетании с надлежащим программным обеспечением и/или микропрограммным обеспечением.
[0273] Описаны различные примеры. Эти и другие примеры находятся в пределах объема прилагаемой формулы изобретения.
Изобретение относится к видеокодированию, в частности к передаче потоков битов многослойного расширения стандарта высокоэффективного кодирования видео (HEVC). Технический результат заключается в повышении эффективности декодирования. Предложен видеодекодер, который собирает в буферной модели единицу доступа из множества элементарных потоков для потока видеоданных. Поток видеоданных может представлять собой транспортный поток или программный поток. Идентичная буферная модель используется независимо от того, содержат ли элементарные потоки потоки битов по стандарту масштабируемого высокоэффективного кодирования видео (SHVC), многовидового HEVC (MV-HEVC) или 3D-HEVC. Кроме того, видеодекодер декодирует единицу доступа. 4 н. и 24 з.п. ф-лы, 20 табл., 9 ил.
1. Способ декодирования видеоданных, при этом способ содержит этапы, на которых:
- принимают поток видеоданных, содержащий множество элементарных потоков и таблицу структуры программ (PMT) отдельно от множества элементарных потоков, причем PMT содержит информацию о том, какой из элементарных потоков содержит программу, PMT включает в себя дескриптор расширения стандарта высокоэффективного кодирования видео (HEVC), и PMT включает в себя множество дескрипторов расширения иерархий, причем:
дескриптор HEVC-расширения сигнализирует о текущей рабочей точке, которая соответствует набору выходных слоев, дескриптор HEVC-расширения содержит элемент синтаксиса максимального временного идентификатора и набор флагов выходного слоя, элемент синтаксиса максимального временного идентификатора указывает наивысший временной идентификатор единиц сетевого уровня абстракции (NAL) в текущей рабочей точке, каждый флаг выходного слоя в наборе флагов выходного слоя указывает, находится ли соответствующий слой в наборе выходных слоев текущей рабочей точки, и набор флагов выходного слоя включает в себя по меньшей мере один флаг выходного слоя, который указывает, что соответствующий слой не находится в наборе выходных слоев текущей рабочей точки,
каждый соответствующий дескриптор расширения иерархий из множества дескрипторов расширения иерархий соответствует соответствующему элементарному потоку во множестве элементарных потоков, каждый соответствующий элементарный поток из множества элементарных потоков представляет собой видеопоток HEVC-расширения в MPEG-2-системе, дескрипторы расширения иерархий содержат соответствующие наборы значений, и
для каждого соответствующего дескриптора расширения иерархий из множества дескрипторов расширения иерархий каждое значение в соответствующем наборе значений задает индекс слоя иерархии элементарного потока, который должен быть доступен и присутствовать в порядке декодирования до декодирования элементарного потока, который соответствует соответствующему дескриптору расширения иерархий;
- собирают, в буферной модели, изображения HEVC-слоев в единице доступа из множества элементарных потоков для потока видеоданных, при этом:
буферная модель представляет собой модель на основе декодера системных целевых объектов транспортного потока или модель на основе декодера системных целевых объектов программного потока,
поток видеоданных представляет собой транспортный поток или программный поток, и
идентичная буферная модель используется для того, чтобы собирать изображения HEVC-слоев в единице доступа, независимо от того, содержат ли элементарные потоки во множестве элементарных потоков какие-либо из множества различных типов многослойных кодированных потоков битов, и
сборка изображений HEVC-слоев в единице доступа содержит этап, на котором идентифицируют, на основе упомянутых наборов значений в дескрипторах расширения иерархий, множество опорных слоев, требуемых для декодирования набора выходных слоев текущей рабочей точки; и
- декодируют единицу доступа.
2. Способ по п. 1, в котором множество различных типов многослойных кодированных потоков битов включают в себя потоки битов по стандарту масштабируемого высокоэффективного кодирования видео (SHVC), многовидового HEVC (MV-HEVC) и 3D-HEVC.
3. Способ по п. 1, дополнительно содержащий этап, на котором:
- собирают изображения HEVC-слоев в единицах доступа с использованием отдельных экземпляров буферной модели для каждого соответствующего многослойного HEVC-видеопотока для потока видеоданных, при этом:
- каждый соответствующий многослойный HEVC-видеопоток содержит множество субпотоков видеобитов HEVC-слоя, и
- каждый соответствующий субпоток видеобитов HEVC-слоя из множества субпотоков видеобитов HEVC-слоя содержит единицы сетевого уровня абстракции (NAL) слоя кодирования видео (VCL) с идентичным значением идентификатора слоя.
4. Способ по п. 1, в котором:
- для каждого соответствующего элементарного потока, ассоциированного с программой:
- буферная модель содержит буфер для соответствующего элементарного потока,
- единица доступа содержит соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока,
- соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока содержит изображения HEVC-слоев в единице доступа, которые ассоциированы с соответствующим набором идентификаторов слоев,
- каждое из изображений HEVC-слоев в единице доступа представляет собой кодированное изображение, и
- сборка изображений HEVC-слоев в единице доступа содержит, для каждого соответствующего элементарного потока, ассоциированного с программой, этапы, на которых:
- удаляют соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока из буфера для соответствующего элементарного потока; и
- включают соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока в единицу доступа.
5. Способ по п. 4, в котором:
- поток видеоданных представляет собой транспортный поток,
- для каждого соответствующего элементарного потока, ассоциированного с программой:
- буфер для соответствующего элементарного потока представляет собой первый буфер для соответствующего элементарного потока,
- буферная модель содержит второй буфер для соответствующего элементарного потока; и
- способ дополнительно содержит, для каждого соответствующего пакета пакетизированных элементарных потоков (PES) транспортного потока, принадлежащего соответствующему элементарному потоку, этап, на котором сохраняют соответствующий PES-пакет во втором буфере для соответствующего элементарного потока.
6. Способ по п. 5, в котором:
- для каждого соответствующего элементарного потока, ассоциированного с программой:
- буферная модель содержит третий буфер для соответствующего элементарного потока; и
- при этом способ дополнительно содержит этапы, на которых:
- удаляют PES-пакеты из второго буфера для соответствующего элементарного потока;
- сохраняют, в третьем буфере для соответствующего элементарного потока, PES-пакеты, удаленные из второго буфера для соответствующего элементарного потока;
- удаляют байты из третьего буфера для соответствующего элементарного потока; и
- сохраняют, в первом буфере для соответствующего элементарного потока, байты, удаленные из третьего буфера для соответствующего элементарного потока.
7. Способ по п. 1, причем:
- способ дополнительно содержит, в ответ на определение того, что имеется набор HEVC-слоев в программе, и того, что имеется, по меньшей мере, один многослойный HEVC-субпоток видеобитов во множестве элементарных потоков, который представляет собой видеопоток HEVC-расширения, соответствующий одному или более профилей, этап, на котором выбирают буферную модель, которую следует использовать при сборке изображений HEVC-слоев в единице доступа.
8. Устройство декодирования видео, содержащее:
- запоминающее устройство, выполненное с возможностью сохранять видеоданные; и
- один или более процессоров, выполненных с возможностью:
- принимать поток видеоданных, содержащий множество элементарных потоков и таблицу структуры программ (PMT) отдельно от множества элементарных потоков, причем PMT содержит информацию о том, какой из элементарных потоков содержит программу, PMT включает в себя дескриптор расширения стандарта высокоэффективного кодирования видео (HEVC), и PMT включает в себя множество дескрипторов расширения иерархий, причем:
дескриптор HEVC-расширения сигнализирует о текущей рабочей точке, которая соответствует набору выходных слоев, дескриптор HEVC-расширения содержит элемент синтаксиса максимального временного идентификатора и набор флагов выходного слоя, элемент синтаксиса максимального временного идентификатора указывает наивысший временной идентификатор единиц сетевого уровня абстракции (NAL) в текущей рабочей точке, каждый флаг выходного слоя в наборе флагов выходного слоя указывает, находится ли соответствующий слой в наборе выходных слоев текущей рабочей точки, и набор флагов выходного слоя включает в себя по меньшей мере один флаг выходного слоя, который указывает, что соответствующий слой не находится в наборе выходных слоев текущей рабочей точки,
каждый соответствующий дескриптор расширения иерархий из множества дескрипторов расширения иерархий соответствует соответствующему элементарному потоку во множестве элементарных потоков, каждый соответствующий элементарный поток из множества элементарных потоков представляет собой видеопоток HEVC-расширения в MPEG-2-системе, дескрипторы расширения иерархий содержат соответствующие наборы значений, и
для каждого соответствующего дескриптора расширения иерархий из множества дескрипторов расширения иерархий каждое значение в соответствующем наборе значений задает индекс слоя иерархии элементарного потока, который должен быть доступен и присутствовать в порядке декодирования до декодирования элементарного потока, который соответствует соответствующему дескриптору расширения иерархий;
- собирать, в буферной модели, изображения HEVC-слоев в единице доступа из множества элементарных потоков для потока видеоданных, при этом:
буферная модель представляет собой модель на основе декодера системных целевых объектов транспортного потока или модель на основе декодера системных целевых объектов программного потока,
поток видеоданных представляет собой транспортный поток или программный поток, и
идентичная буферная модель используется для того, чтобы собирать изображения HEVC-слоев в единице доступа, независимо от того, содержат ли элементарные потоки во множестве элементарных потоков какие-либо из множества различных типов многослойных кодированных потоков битов, и
сборка изображений HEVC-слоев в единице доступа содержит идентификацию, на основе упомянутых наборов значений в дескрипторах расширения иерархий, множества опорных слоев, требуемых для декодирования набора выходных слоев текущей рабочей точки; и
- декодировать единицу доступа.
9. Устройство декодирования видео по п. 8, в котором множество различных типов многослойных кодированных потоков битов включают в себя потоки битов по стандарту масштабируемого высокоэффективного кодирования видео (SHVC), многовидового HEVC (MV-HEVC) и 3D-HEVC.
10. Устройство декодирования видео по п. 8, в котором один или более процессоров выполнены с возможностью собирать изображения HEVC-слоев в единицах доступа с использованием отдельных экземпляров буферной модели для каждого соответствующего многослойного HEVC-видеопотока для потока видеоданных, при этом:
- каждый соответствующий многослойный HEVC-видеопоток содержит множество субпотоков видеобитов HEVC-слоя, и
- каждый соответствующий субпоток видеобитов HEVC-слоя из множества субпотоков видеобитов HEVC-слоя содержит единицы сетевого уровня абстракции (NAL) слоя кодирования видео (VCL) с идентичным значением идентификатора слоя.
11. Устройство декодирования видео по п. 8, в котором:
- для каждого соответствующего элементарного потока, ассоциированного с программой:
- буферная модель содержит буфер для соответствующего элементарного потока, единица доступа содержит соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока,
- соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока содержит изображения HEVC-слоев в единице доступа, которые ассоциированы с соответствующим набором идентификаторов слоев,
- каждое из изображений HEVC-слоев в единице доступа представляет собой кодированное изображение, и
- в качестве части сборки изображений HEVC-слоев в единице доступа, один или более процессоров, для каждого соответствующего элементарного потока, ассоциированного с программой, выполнены с возможностью:
- удалять соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока из буфера для соответствующего элементарного потока; и
- включать соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока в единицу доступа.
12. Устройство декодирования видео по п. 11, в котором:
- поток видеоданных представляет собой транспортный поток,
- для каждого соответствующего элементарного потока, ассоциированного с программой:
- буфер для соответствующего элементарного потока представляет собой первый буфер для соответствующего элементарного потока,
- буферная модель содержит второй буфер для соответствующего элементарного потока; и
- один или более процессоров выполнены с возможностью, для каждого соответствующего пакета пакетизированных элементарных потоков (PES) транспортного потока, принадлежащего соответствующему элементарному потоку, сохранять соответствующий PES-пакет во втором буфере для соответствующего элементарного потока.
13. Устройство декодирования видео по п. 12, в котором:
- для каждого соответствующего элементарного потока, ассоциированного с программой:
- буферная модель содержит третий буфер для соответствующего элементарного потока; и
- один или более процессоров выполнены с возможностью:
- удалять PES-пакеты из второго буфера для соответствующего элементарного потока;
- сохранять, в третьем буфере для соответствующего элементарного потока, PES-пакеты, удаленные из второго буфера для соответствующего элементарного потока;
- удалять байты из третьего буфера для соответствующего элементарного потока; и
- сохранять, в первом буфере для соответствующего элементарного потока, байты, удаленные из третьего буфера для соответствующего элементарного потока.
14. Устройство декодирования видео по п. 8, в котором:
- один или более процессоров дополнительно выполнены с возможностью, в ответ на определение того, что имеется набор HEVC-слоев в программе, и того, что имеется, по меньшей мере, один многослойный HEVC-субпоток видеобитов во множестве элементарных потоков, который представляет собой видеопоток HEVC-расширения, соответствующий одному или более профилей, выбирать буферную модель, которую следует использовать при сборке изображений HEVC-слоев в единице доступа.
15. Устройство декодирования видео, содержащее:
- средство для приема потока видеоданных, содержащего множество элементарных потоков и таблицу структуры программ (PMT) отдельно от множества элементарных потоков, причем PMT содержит информацию о том, какой из элементарных потоков содержит программу, PMT включает в себя дескриптор расширения стандарта высокоэффективного кодирования видео (HEVC), и PMT включает в себя множество дескрипторов расширения иерархий, причем:
дескриптор HEVC-расширения сигнализирует о текущей рабочей точке, которая соответствует набору выходных слоев, дескриптор HEVC-расширения содержит элемент синтаксиса максимального временного идентификатора и набор флагов выходного слоя, элемент синтаксиса максимального временного идентификатора указывает наивысший временной идентификатор единиц сетевого уровня абстракции (NAL) в текущей рабочей точке, каждый флаг выходного слоя в наборе флагов выходного слоя указывает, находится ли соответствующий слой в наборе выходных слоев текущей рабочей точки, и набор флагов выходного слоя включает в себя по меньшей мере один флаг выходного слоя, который указывает, что соответствующий слой не находится в наборе выходных слоев текущей рабочей точки,
каждый соответствующий дескриптор расширения иерархий из множества дескрипторов расширения иерархий соответствует соответствующему элементарному потоку во множестве элементарных потоков, каждый соответствующий элементарный поток из множества элементарных потоков представляет собой видеопоток HEVC-расширения в MPEG-2-системе, дескрипторы расширения иерархий содержат соответствующие наборы значений, и
для каждого соответствующего дескриптора расширения иерархий из множества дескрипторов расширения иерархий каждое значение в соответствующем наборе значений задает индекс слоя иерархии элементарного потока, который должен быть доступен и присутствовать в порядке декодирования до декодирования элементарного потока, который соответствует соответствующему дескриптору расширения иерархий;
- средство для сборки, в буферной модели, изображений HEVC-слоев в единице доступа из множества элементарных потоков для потока видеоданных, при этом:
буферная модель представляет собой модель на основе декодера системных целевых объектов транспортного потока или модель на основе декодера системных целевых объектов программного потока,
поток видеоданных представляет собой транспортный поток или программный поток, и
идентичная буферная модель используется для того, чтобы собирать изображения HEVC-слоев в единице доступа, независимо от того, содержат ли элементарные потоки во множестве элементарных потоков какие-либо из множества различных типов многослойных кодированных потоков битов, и
сборка изображений HEVC-слоев в единице доступа содержит идентификацию, на основе упомянутых наборов значений в дескрипторах расширения иерархий, множества опорных слоев, требуемых для декодирования набора выходных слоев текущей рабочей точки; и
- средство для декодирования единицы доступа.
16. Устройство декодирования видео по п. 15, в котором множество различных типов многослойных кодированных потоков битов включают в себя потоки битов по стандарту масштабируемого высокоэффективного кодирования видео (SHVC), многовидового HEVC (MV-HEVC) и 3D-HEVC.
17. Устройство декодирования видео по п. 15, дополнительно содержащее:
- средство для сборки изображений HEVC-слоев в единицах доступа с использованием отдельных экземпляров буферной модели для каждого соответствующего многослойного HEVC-видеопотока для потока видеоданных, при этом:
- каждый соответствующий многослойный HEVC-видеопоток содержит множество субпотоков видеобитов HEVC-слоя, и
- каждый соответствующий субпоток видеобитов HEVC-слоя из множества субпотоков видеобитов HEVC-слоя содержит единицы сетевого уровня абстракции (NAL) слоя кодирования видео (VCL) с идентичным значением идентификатора слоя.
18. Устройство декодирования видео по п. 15, в котором:
- для каждого соответствующего элементарного потока, ассоциированного с программой:
- буферная модель содержит буфер для соответствующего элементарного потока, единица доступа содержит соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока,
- соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока содержит изображения HEVC-слоев в единице доступа, которые ассоциированы с соответствующим набором идентификаторов слоев,
- каждое из изображений HEVC-слоев в единице доступа представляет собой кодированное изображение, и
- средство для сборки изображений HEVC-слоев в единице доступа содержит, для каждого соответствующего элементарного потока, ассоциированного с программой, средства для:
- удаления соответствующего поднабора изображений HEVC-слоев для соответствующего элементарного потока из буфера для соответствующего элементарного потока; и
- включения соответствующего поднабора изображений HEVC-слоев для соответствующего элементарного потока в единицу доступа.
19. Устройство декодирования видео по п. 18, в котором:
- поток видеоданных представляет собой транспортный поток,
- для каждого соответствующего элементарного потока, ассоциированного с программой:
- буфер для соответствующего элементарного потока представляет собой первый буфер для соответствующего элементарного потока,
- буферная модель содержит второй буфер для соответствующего элементарного потока; и
- устройство декодирования видео дополнительно содержит средство для сохранения, для каждого соответствующего пакета пакетизированных элементарных потоков (PES) транспортного потока, принадлежащего соответствующему элементарному потоку, соответствующего PES-пакета во втором буфере для соответствующего элементарного потока.
20. Устройство декодирования видео по п. 19, в котором:
- для каждого соответствующего элементарного потока, ассоциированного с программой:
- буферная модель содержит третий буфер для соответствующего элементарного потока; и
- устройство декодирования видео дополнительно содержит:
- средство для удаления PES-пакетов из второго буфера для соответствующего элементарного потока;
- средство для сохранения, в третьем буфере для соответствующего элементарного потока, PES-пакетов, удаленных из второго буфера для соответствующего элементарного потока;
- средство для удаления байтов из третьего буфера для соответствующего элементарного потока; и
- средство для сохранения, в первом буфере для соответствующего элементарного потока, байтов, удаленных из третьего буфера для соответствующего элементарного потока.
21. Устройство декодирования видео по п. 15, причем:
- устройство декодирования видео дополнительно содержит средство для выбора, в ответ на определение того, что имеется набор HEVC-слоев в программе, и того, что имеется, по меньшей мере, один многослойный HEVC-субпоток видеобитов во множестве элементарных потоков, который представляет собой видеопоток HEVC-расширения, соответствующий одному или более профилей, буферной модели, которую следует использовать при сборке изображений HEVC-слоев в единице доступа.
22. Компьютерно-читаемый носитель хранения данных, содержащий сохраненные на нем инструкции, которые, при выполнении, инструктируют устройству декодирования видео:
- принимать поток видеоданных, содержащий множество элементарных потоков и таблицу структуры программ (PMT) отдельно от множества элементарных потоков, причем PMT содержит информацию о том, какой из элементарных потоков содержит программу, PMT включает в себя дескриптор расширения стандарта высокоэффективного кодирования видео (HEVC), и PMT включает в себя множество дескрипторов расширения иерархий, причем:
дескриптор HEVC-расширения сигнализирует о текущей рабочей точке, которая соответствует набору выходных слоев, дескриптор HEVC-расширения содержит элемент синтаксиса максимального временного идентификатора и набор флагов выходного слоя, элемент синтаксиса максимального временного идентификатора указывает наивысший временной идентификатор единиц сетевого уровня абстракции (NAL) в текущей рабочей точке, каждый флаг выходного слоя в наборе флагов выходного слоя указывает, находится ли соответствующий слой в наборе выходных слоев текущей рабочей точки, и набор флагов выходного слоя включает в себя по меньшей мере один флаг выходного слоя, который указывает, что соответствующий слой не находится в наборе выходных слоев текущей рабочей точки,
каждый соответствующий дескриптор расширения иерархий из множества дескрипторов расширения иерархий соответствует соответствующему элементарному потоку во множестве элементарных потоков, каждый соответствующий элементарный поток из множества элементарных потоков представляет собой видеопоток HEVC-расширения в MPEG-2-системе, дескрипторы расширения иерархий содержат соответствующие наборы значений, и
для каждого соответствующего дескриптора расширения иерархий из множества дескрипторов расширения иерархий каждое значение в соответствующем наборе значений задает индекс слоя иерархии элементарного потока, который должен быть доступен и присутствовать в порядке декодирования до декодирования элементарного потока, который соответствует соответствующему дескриптору расширения иерархий;
- собирать, в буферной модели, изображения HEVC-слоев в единице доступа из множества элементарных потоков для потока видеоданных, при этом:
буферная модель представляет собой модель на основе декодера системных целевых объектов транспортного потока или модель на основе декодера системных целевых объектов программного потока,
поток видеоданных представляет собой транспортный поток или программный поток, и
идентичная буферная модель используется для того, чтобы собирать изображения HEVC-слоев в единице доступа, независимо от того, содержат ли элементарные потоки во множестве элементарных потоков какие-либо из множества различных типов многослойных кодированных потоков битов, и
сборка изображений HEVC-слоев в единице доступа содержит идентификацию, на основе упомянутых наборов значений в дескрипторах расширения иерархий, множества опорных слоев, требуемых для декодирования набора выходных слоев текущей рабочей точки; и
- декодировать единицу доступа.
23. Компьютерно-читаемый носитель хранения данных по п. 22, в котором множество различных типов многослойных кодированных потоков битов включают в себя потоки битов по стандарту масштабируемого высокоэффективного кодирования видео (SHVC), многовидового HEVC (MV-HEVC) и 3D-HEVC.
24. Компьютерно-читаемый носитель хранения данных по п. 22, в котором инструкции дополнительно инструктируют устройству декодирования видео:
- собирать изображения HEVC-слоев в единицах доступа с использованием отдельных экземпляров буферной модели для каждого соответствующего многослойного HEVC-видеопотока для потока видеоданных, при этом:
- каждый соответствующий многослойный HEVC-видеопоток содержит множество субпотоков видеобитов HEVC-слоя, и
- каждый соответствующий субпоток видеобитов HEVC-слоя из множества субпотоков видеобитов HEVC-слоя содержит единицы сетевого уровня абстракции (NAL) слоя кодирования видео (VCL) с идентичным значением идентификатора слоя.
25. Компьютерно-читаемый носитель хранения данных по п. 22, в котором:
- для каждого соответствующего элементарного потока, ассоциированного с программой:
- буферная модель содержит буфер для соответствующего элементарного потока, единица доступа содержит соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока,
- соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока содержит изображения HEVC-слоев в единице доступа, которые ассоциированы с соответствующим набором идентификаторов слоев,
- каждое из изображений HEVC-слоев в единице доступа представляет собой кодированное изображение, и
- в качестве части сборки изображений HEVC-слоев в единице доступа, для каждого соответствующего элементарного потока, ассоциированного с программой, инструкции инструктируют устройству декодирования видео:
- удалять соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока из буфера для соответствующего элементарного потока; и
- включать соответствующий поднабор изображений HEVC-слоев для соответствующего элементарного потока в единицу доступа.
26. Компьютерно-читаемый носитель хранения данных по п. 25, в котором:
- поток видеоданных представляет собой транспортный поток,
- для каждого соответствующего элементарного потока, ассоциированного с программой:
- буфер для соответствующего элементарного потока представляет собой первый буфер для соответствующего элементарного потока,
- буферная модель содержит второй буфер для соответствующего элементарного потока; и
- инструкции дополнительно инструктируют устройству декодирования видео сохранять, для каждого соответствующего пакета пакетизированных элементарных потоков (PES) транспортного потока, принадлежащего соответствующему элементарному потоку, соответствующий PES-пакет во втором буфере для соответствующего элементарного потока.
27. Компьютерно-читаемый носитель хранения данных по п. 26, в котором:
- для каждого соответствующего элементарного потока, ассоциированного с программой:
- буферная модель содержит третий буфер для соответствующего элементарного потока; и
- инструкции дополнительно инструктируют устройству декодирования видео:
- удалять PES-пакеты из второго буфера для соответствующего элементарного потока;
- сохранять, в третьем буфере для соответствующего элементарного потока, PES-пакеты, удаленные из второго буфера для соответствующего элементарного потока;
- удалять байты из третьего буфера для соответствующего элементарного потока; и
- сохранять, в первом буфере для соответствующего элементарного потока, байты, удаленные из третьего буфера для соответствующего элементарного потока.
28. Компьютерно-читаемый носитель хранения данных по п. 22, в котором:
- инструкции дополнительно инструктируют устройству декодирования видео выбирать, в ответ на определение того, что имеется набор HEVC-слоев в программе, и того, что имеется, по меньшей мере, один многослойный HEVC-субпоток видеобитов во множестве элементарных потоков, который представляет собой видеопоток HEVC-расширения, соответствующий одному или более профилей, буферную модель, которую следует использовать при сборке изображений HEVC-слоев в единице доступа.
SAM NARASIMHAN et al., Consideration of buffer management issues and layer management in HEVC scalability, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11, JCTVC-M0254, 13th Meeting: Incheon, 18-26 Apr | |||
Многоступенчатая активно-реактивная турбина | 1924 |
|
SU2013A1 |
US 2013128990 A1, 2013-05-23 | |||
US 2013182755 A1, 2013-07-18 | |||
WO 2008084184 A2, 2008-07-17 | |||
СИСТЕМА И СПОСОБ УКАЗАНИЯ ВЗАИМОСВЯЗЕЙ ТРЕКОВ В МУЛЬТИМЕДИЙНОМ ФАЙЛЕ | 2007 |
|
RU2435235C2 |
JILL BOYCE et al, VPS support for out-of-band signaling and hybrid codec scalability, Joint Collaborative Team on Video Coding (JCT-VC), of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11, JCTVC-K0206, 11th Meeting: Shanghai, 10-19 Oct | |||
Изложница с суживающимся книзу сечением и с вертикально перемещающимся днищем | 1924 |
|
SU2012A1 |
Авторы
Даты
2019-04-17—Публикация
2015-01-08—Подача