RU2676876C2 - Структуры формата файла многоуровневого видео - Google Patents
Структуры формата файла многоуровневого видео Download PDFInfo
- Publication number
- RU2676876C2 RU2676876C2 RU2016115539A RU2016115539A RU2676876C2 RU 2676876 C2 RU2676876 C2 RU 2676876C2 RU 2016115539 A RU2016115539 A RU 2016115539A RU 2016115539 A RU2016115539 A RU 2016115539A RU 2676876 C2 RU2676876 C2 RU 2676876C2
- Authority
- RU
- Russia
- Prior art keywords
- video
- samples
- sample
- picture
- irap
- Prior art date
Links
- 238000013461 design Methods 0.000 title description 2
- 238000000034 method Methods 0.000 claims description 104
- 238000012545 processing Methods 0.000 claims description 68
- 238000003860 storage Methods 0.000 claims description 48
- 238000005070 sampling Methods 0.000 claims description 40
- 238000004891 communication Methods 0.000 abstract description 21
- 239000000126 substance Substances 0.000 abstract 1
- 239000010410 layer Substances 0.000 description 40
- 239000013598 vector Substances 0.000 description 28
- FMYKJLXRRQTBOR-UBFHEZILSA-N (2s)-2-acetamido-4-methyl-n-[4-methyl-1-oxo-1-[[(2s)-1-oxohexan-2-yl]amino]pentan-2-yl]pentanamide Chemical group CCCC[C@@H](C=O)NC(=O)C(CC(C)C)NC(=O)[C@H](CC(C)C)NC(C)=O FMYKJLXRRQTBOR-UBFHEZILSA-N 0.000 description 20
- 238000013139 quantization Methods 0.000 description 20
- 230000008569 process Effects 0.000 description 19
- 241000894007 species Species 0.000 description 16
- 230000002123 temporal effect Effects 0.000 description 14
- 230000000007 visual effect Effects 0.000 description 14
- 230000006835 compression Effects 0.000 description 12
- 238000007906 compression Methods 0.000 description 12
- 230000009471 action Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 11
- 238000011084 recovery Methods 0.000 description 10
- 230000003044 adaptive effect Effects 0.000 description 8
- 238000000605 extraction Methods 0.000 description 8
- 208000037170 Delayed Emergence from Anesthesia Diseases 0.000 description 7
- 101150049515 bla gene Proteins 0.000 description 6
- 230000004044 response Effects 0.000 description 6
- 238000000926 separation method Methods 0.000 description 6
- 238000012546 transfer Methods 0.000 description 6
- 238000003491 array Methods 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 5
- 238000001914 filtration Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 230000009466 transformation Effects 0.000 description 5
- 238000003032 molecular docking Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000001419 dependent effect Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000007480 spreading Effects 0.000 description 3
- 230000001052 transient effect Effects 0.000 description 3
- 101100477498 Caenorhabditis elegans shc-1 gene Proteins 0.000 description 2
- 230000004913 activation Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000005538 encapsulation Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 239000012634 fragment Substances 0.000 description 2
- 239000011229 interlayer Substances 0.000 description 2
- 230000001788 irregular Effects 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000000750 progressive effect Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 238000000844 transformation Methods 0.000 description 2
- 241000282326 Felis catus Species 0.000 description 1
- 241000023320 Luma <angiosperm> Species 0.000 description 1
- 230000004931 aggregating effect Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 239000000945 filler Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000012432 intermediate storage Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- OSWPMRLSEDHDFF-UHFFFAOYSA-N methyl salicylate Chemical compound COC(=O)C1=CC=CC=C1O OSWPMRLSEDHDFF-UHFFFAOYSA-N 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000012805 post-processing Methods 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/46—Embedding additional information in the video signal during the compression process
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T1/00—General purpose image data processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T9/00—Image coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/136—Incoming video signal characteristics or properties
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
- H04N19/51—Motion estimation or motion compensation
- H04N19/513—Processing of motion vectors
- H04N19/517—Processing of motion vectors by encoding
- H04N19/52—Processing of motion vectors by encoding by predictive encoding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
- H04N19/51—Motion estimation or motion compensation
- H04N19/573—Motion compensation with multiple frame prediction using two or more reference frames in a given prediction direction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
- H04N19/51—Motion estimation or motion compensation
- H04N19/58—Motion compensation with long-term prediction, i.e. the reference frame for a current frame not being the temporally closest one
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/59—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial sub-sampling or interpolation, e.g. alteration of picture size or resolution
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
- H04N19/91—Entropy coding, e.g. variable length coding [VLC] or arithmetic coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
- H04N21/8453—Structuring of content, e.g. decomposing content into time segments by locking or enabling a set of features, e.g. optional functionalities in an executable program
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/85—Assembly of content; Generation of multimedia applications
- H04N21/854—Content authoring
- H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N5/00—Details of television systems
- H04N5/76—Television signal recording
- H04N5/91—Television signal processing therefor
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Management Or Editing Of Information On Record Carriers (AREA)
- Television Signal Processing For Recording (AREA)
- Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
Abstract
Изобретение относится к области видеокодирования. Технический результат заключается в повышении эффективности видеокодирования. Технический результат достигается за счет получения определения группы выборок, которая документирует все из выборок, содержащих по меньшей мере одну картинку внутренней точки произвольного доступа (IRAP); при этом группа выборок определена, чтобы включать запись группы выборок, которая включает в себя: значение, указывающее, все ли кодированные картинки в конкретной выборке в последовательности выборок являются IRAP-картинками, значение, указывающее число IRAP-картинок в конкретной выборке, и значения, указывающие идентификаторы уровня IRAP-картинок в конкретной выборке, при этом по меньшей мере одна из видеоединиц доступа в сгенерированном файле содержит IRAP-картинку в базовом уровне, а также содержит одну или более не-IRAP-картинок в других уровнях. 8 н. и 26 з.п. ф-лы, 12 ил.
Description
[0001] Настоящая заявка испрашивает приоритет Предварительной патентной заявки США № 61/894,886, поданной 23 октября 2013, все содержание которой включено в настоящий документ посредством ссылки.
ОБЛАСТЬ ТЕХНИКИ
[0002] Настоящее раскрытие относится к видео кодированию.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
[0003] Возможности цифрового видео могут быть включены в широкий спектр устройств, включая цифровые телевизоры, системы цифрового прямого вещания, системы беспроводного вещания, персональные цифровые помощники (PDA), портативные или настольные персональные компьютеры, планшетные компьютеры, устройства для чтения электронных книг, цифровые камеры, цифровые записывающие устройства, цифровые мультимедийные плееры, видеоигровые устройства, видеоигровые приставки, сотовые или спутниковые радиотелефоны, так называемые ʺсмартфоныʺ, устройства видео телеконференц-связи, устройства потоковой передачи видео и тому подобное. Цифровые видео устройства реализуют методы сжатия видео, такие как описанные в стандартах, определенных MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, Part 10, Расширенное видео кодирование (AVC), стандарт Высокоэффективного видео кодирования (HEVC), находящийся в настоящее время в стадии разработки, и расширения этих стандартов. Видео устройства могут передавать, принимать, кодировать, декодировать и/или сохранять информацию цифрового видео более эффективно путем реализации таких методов сжатия видео.
[0004] Методы сжатия видео выполняют пространственное (внутрикадровое) предсказание и/или временное (межкадровое) предсказание для уменьшения или устранения избыточности, внутренне присущей видео последовательностям. Для блочного видео кодирования, видео вырезка (т.е., видео кадр или часть видео кадра) может быть подразделена на видео блоки, которые могут упоминаться как блоки дерева, единицы кодирования (CU) и/или узлы кодирования. Видео блоки во внутренне (интра-) кодированной (I) вырезке картинки (изображения) кодируются с использованием пространственного предсказания по отношению к опорным выборкам в соседних блоках в той же самой картинке. Видео блоки взаимно (интер-) кодированной (P или B) вырезки картинки могут использовать пространственное предсказание по отношению к опорным выборкам в соседних блоках в той же картинке или временное предсказание по отношению к опорным выборкам в других опорных картинках. Картинки могут упоминаться как кадры, и опорные картинки могут упоминаться как опорные кадры.
[0005] Пространственное или временное предсказание приводит в результате к блоку предсказания для блока, подлежащего кодированию. Остаточные данные представляют пиксельные разности между исходным блоком, подлежащим кодированию, и блоком предсказания. Интер-кодированный блок кодируется в соответствии с вектором движения, который указывает на блок опорных выборок, формирующий блок предсказания, и остаточными данными, указывающими на разность между кодированным блоком и блоком предсказания. Интра-кодированный блок кодируется в соответствии с режимом интра-кодирования и остаточными данными. Для дальнейшего сжатия, остаточные данные могут быть преобразованы из пиксельной области в область преобразования, что приводит в результате к остаточным коэффициентам преобразования, которые затем могут быть квантованы. Квантованные коэффициенты преобразования, первоначально упорядоченные в двумерный массив, могут сканироваться для генерации одномерного вектора коэффициентов преобразования, и энтропийное кодирование может быть применено для достижения большего сжатия.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
[0006] В общем, настоящее раскрытие относится к сохранению видео контента в файле на основе базового формата медиа файла Международной организации по стандартизации (ISO) (ISOBMFF). Некоторые примеры настоящего раскрытия относятся к способам хранения потоков видео, содержащих множество кодированных уровней, где каждый уровень может быть масштабируемым уровнем, представлением (видом) текстуры, представлением глубины и т.д., и упомянутые способы могут применяться для хранения видеоданных многовидового высокоэффективного видео кодирования (MV-HEVC), масштабируемого HEVC (SHVC), 3-мерного HEVC (3D-HEVC) и других типов видеоданных.
[0007] В одном аспекте, настоящее раскрытие описывает способ обработки многоуровневых видеоданных, причем способ содержит генерацию файла, который содержит бокс трека, который содержит метаданные для трека в файле, причем медиа данные для трека содержат последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных, и генерация файла содержит генерацию, в файле, дополнительного бокса, который документирует все выборки, содержащие по меньшей мере одну картинку внутренней точки произвольного доступа (IRAP).
[0008] В другом аспекте, настоящее раскрытие описывает способ обработки многоуровневых видеоданных, причем способ содержит получение, из файла, бокса трека, который содержит метаданные для трека в файле, причем медиа данные для трека содержат последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных; получение, из файла, дополнительного бокса, который документирует все выборки, содержащие по меньшей мере одну IRAP-картинку; и определение, на основе информации в дополнительном боксе, одной или более выборок, содержащих по меньшей мере одну IRAP-картинку.
[0009] В другом аспекте, настоящее раскрытие описывает видео устройство, содержащее: носитель хранения данных, сконфигурированный для хранения многоуровневых видеоданных; и один или более процессоров, сконфигурированных, чтобы генерировать файл, который содержит бокс трека, который содержит метаданные для трека в файле, причем медиа данные для трека содержат последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных, и генерация файла содержит генерацию, в файле, дополнительного бокса, который документирует все выборки, содержащие по меньшей мере одну IRAP-картинку.
[0010] В другом аспекте, настоящее раскрытие описывает видео устройство, содержащее: носитель хранения данных, сконфигурированный для хранения многоуровневых видеоданных; и один или более процессоров, сконфигурированных, чтобы получать, из файла, бокс трека, который содержит метаданные для трека в файле, причем медиа данные для трека содержат последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных; получать, из файла, дополнительный бокс, который документирует все выборки, содержащие по меньшей мере одну IRAP-картинку; и определять, на основе информации в дополнительном боксе, одну или более выборок, содержащих по меньшей мере одну IRAP-картинку.
[0011] В другом аспекте, настоящее раскрытие описывает видео устройство, содержащее средство для генерации файла, который содержит бокс трека, который содержит метаданные для трека в файле, причем медиа данные для трека содержат последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных, и генерация файла содержит генерацию, в файле, дополнительного бокса, который документирует все выборки, содержащие по меньшей мере одну IRAP-картинку.
[0012] В другом аспекте, настоящее раскрытие описывает видео устройство, содержащее средство для получения, из файла, бокса трека, который содержит метаданные для трека в файле, причем медиа данные для трека содержат последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных; средство для получения, из файла, дополнительного бокса, который документирует все выборки, содержащие по меньшей мере одну IRAP-картинку; и средство для определения, на основе информации в дополнительном боксе, одной или более выборок, содержащих по меньшей мере одну IRAP-картинку.
[0013] В другом аспекте, настоящее раскрытие описывает считываемый компьютером носитель хранения данных, имеющий инструкции, сохраненные на нем, которые, при исполнении, побуждают один или более процессоров генерировать файл, который содержит бокс трека, который содержит метаданные для трека в файле, причем медиа данные для трека содержат последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных, чтобы генерировать файл, один или более процессоров генерируют, в файле, дополнительный бокс, который документирует все выборки, содержащие по меньшей мере одну IRAP-картинку.
[0014] В другом аспекте, настоящее раскрытие описывает считываемый компьютером носитель хранения данных, имеющий инструкции, сохраненные на нем, которые, при исполнении, побуждают один или более процессоров получать, из файла, бокс трека, который содержит метаданные для трека в файле, причем медиа данные для трека содержат последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных; получать из файла дополнительный бокс, который документирует все выборки, содержащие по меньшей мере одну IRAP-картинку; и определять на основе информации в дополнительном боксе одну или более выборок, содержащих по меньшей мере одну IRAP-картинку.
[0015] Детали одного или более примеров раскрытия изложены на приложенных чертежах и в нижеследующем описании. Другие признаки, объекты и преимущества будут очевидны из описания, чертежей и формулы изобретения.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
[0016] Фиг. 1 является блок-схемой, иллюстрирующей примерную систему видео кодирования и декодирования, которая может использовать методы, описанные в настоящем раскрытии.
[0017] Фиг. 2 является блок-схемой, иллюстрирующей примерный видео кодер, который может реализовать методы, описанные в настоящем раскрытии.
[0018] Фиг. 3 является блок-схемой, иллюстрирующей примерный видео декодер, который может реализовать методы, описанные в настоящем раскрытии.
[0019] Фиг. 4 является блок-схемой, иллюстрирующей примерный набор устройств, которые формируют часть сети.
[0020] Фиг. 5 является концептуальной схемой, иллюстрирующей примерную структуру файла в соответствии с одним или более методами настоящего раскрытия.
[0021] Фиг. 6 является концептуальной схемой, иллюстрирующей примерную структуру файла в соответствии с одним или более методами настоящего раскрытия.
[0022] Фиг. 7 является блок-схемой последовательности действий, иллюстрирующей примерную работу устройства генерации файла, в соответствии с одним или более методами настоящего раскрытия.
[0023] Фиг. 8 является блок-схемой последовательности действий, иллюстрирующей примерную операцию, в которой вычислительное устройство выполняет произвольный доступ и/или переключение уровня в соответствии с одним или более методами настоящего раскрытия.
[0024] Фиг. 9 является блок-схемой последовательности действий, иллюстрирующей примерную работу устройства генерации файла, в соответствии с одним или более методами настоящего раскрытия.
[0025] Фиг. 10 является блок-схемой последовательности действий, иллюстрирующей примерную работу вычислительного устройства, в соответствии с одним или более методами настоящего раскрытия.
[0026] Фиг. 11 является блок-схемой последовательности действий, иллюстрирующей примерную работу устройства генерации файла, в соответствии с одним или более методами настоящего раскрытия.
[0027] Фиг. 12 является блок-схемой последовательности действий, иллюстрирующей примерную работу устройства-получателя, в соответствии с одним или более методами настоящего раскрытия.
ДЕТАЛЬНОЕ ОПИСАНИЕ
[0028] Базовый формат медиа файла ISO (ISOBMFF) является форматом файла для хранения медиа данных. ISOBMFF является расширяемым для поддержки хранения видеоданных, соответствующих конкретным стандартам видео кодирования. Например, ISOBMFF был ранее расширен для поддержки хранения видеоданных, соответствующих стандартам видео кодирования H.264/AVC и Высокоэффективного видео кодирования (HEVC). Кроме того, ISOBMFF был ранее расширен для поддержки хранения видеоданных, соответствующих расширениям многовидового кодирования (MVC) и масштабируемого видео кодирования (SVC) H.264/AVC. MV-HEVC, 3D-HEVC и SHVC являются расширениями стандарта видео кодирования HEVC, который поддерживает многоуровневые видеоданные. Признаки, добавленные к ISOBMFF для хранения видеоданных, соответствующих MVC- и SVC-расширениям H.264/AVC, не достаточны для эффективного хранения видеоданных, соответствующих MV-HEVC, 3D-HEVC и SHVC. Иными словами, различные проблемы могут возникать, если бы попытались использовать расширение ISOBMFF для хранения видеоданных, соответствующих MVC- и SVC-расширениям H.264/AVC, для хранения видеоданных, соответствующих MV-HEVC, 3D-HEVC и SHVC.
[0029] Например, в отличие от битового потока, который соответствует MVC- или SVC-расширениям H.264/AVC, битовый поток, который соответствует MV-HEVC, 3D-HEVC или SHVC, может включать в себя единицы доступа, которые содержат картинки внутренней (интра) точки произвольного доступа (IRAP) и не-IRAP-картинки. Единица доступа, содержащая IRAP-картинки и не-IRAP-картинки, может быть использована для произвольного доступа в MV-HEVC, 3D-HEVC и SHVC. Однако ISOBMFF и его существующие расширения не обеспечивают способа идентификации таких единиц доступа. Это может воспрепятствовать способности вычислительного устройства выполнять произвольный доступ и переключение уровня.
[0030] Таким образом, в соответствии с одним примером настоящего раскрытия, вычислительное устройство может генерировать файл, который содержит бокс (контейнер) трека, который содержит метаданные для трека в файле. Медиа данные для трека содержат последовательность выборок. Каждая из выборок может быть видео единицей доступа многоуровневых видеоданных (например, видеоданных MV-HEVC, 3D-HEVC или SHVC). В качестве части генерации файла, вычислительное устройство может генерировать, в файле, дополнительный бокс, который документирует все выборки, содержащие по меньшей мере одну IRAP-картинку. Способность определять выборки, содержащие IRAP-картинки, на основе информации в дополнительном боксе может позволить вычислительным устройствам, принимающим файл, выполнять произвольный доступ и переключение уровня без синтаксического анализа и интерпретации NAL-единиц. Это может сократить сложность и время обработки.
[0031] Кроме того, многоуровневые видеоданные, такие как видеоданные MV-HEVC, 3D-HEVC и SHVC, могут включать в себя множество кодированных картинок для каждой единицы доступа. Однако ISOBMFF и его существующие расширения не обеспечивают информацию относительно индивидуальных кодированных картинок в единице доступа, если имеется множество кодированных картинок в единице доступа. Таким образом, в примерах, где вычислительное устройство (например, сервер потоковой передачи) определяет, следует ли отправлять NAL-единицы в файле, вычислительному устройству может потребоваться синтаксически анализировать и интерпретировать информацию, сохраненную в NAL-единицах, чтобы определить, следует ли отправлять NAL-единицы. Синтаксический анализ и интерпретация информации, сохраненной в NAL-единицах, может увеличить сложность вычислительного устройства и может увеличить задержку потоковой передачи.
[0032] Таким образом, в соответствии с одним примером настоящего раскрытия, вычислительное устройство может генерировать файл, который содержит бокс трека, который содержит метаданные для трека в файле. Медиа данные для трека содержат последовательность выборок. Каждая из выборок является видео единицей доступа многоуровневых видеоданных. В качестве части генерации файла, вычислительное устройство генерирует, в файле, бокс информации подвыборки, который содержит флаги, которые специфицируют тип информации подвыборки, заданной в боксе информации подвыборки. Когда флаги имеют конкретное значение, подвыборка, соответствующая боксу информации подвыборки, содержит точно одну кодированную картинку и нуль или более не относящихся к уровню видео кодирования (VCL) NAL-единиц, ассоциированных с кодированной картинкой. Таким путем, вычислительные устройства, которые принимают файл, могут использовать информацию подвыборки, заданную в боксе информации подвыборки, чтобы выполнить определение относительно индивидуальных кодированных картинок в выборке файла. Не-VCL NAL-единицы, ассоциированные с кодированной картинкой, могут включать в себя NAL-единицы для наборов параметров (например, PPS, SPS, VPS) и SEI, применимую к кодированной картинке.
[0033] В многоуровневых видеоданных, единица доступа может включать в себя кодированные картинки, которые маркированы как предназначенные для вывода, и кодированные картинки, которые маркированы как не предназначенные для вывода. Видео декодер может использовать кодированные картинки, которые маркированы как не предназначенные для вывода, в качестве опорных картинок для декодирования картинок, которые маркированы как предназначенные для вывода. Заголовок NAL-единицы для NAL-единицы вырезки картинки может включать в себя флаг вывода картинки (например, pic_output_flag в HEVC), который указывает, маркирована ли картинка как предназначенная для вывода. В ISOBMFF-файле, каждая выборка должна быть ассоциирована с временем вывода (например, временем композиции), которое указывает, когда выборка должна выводиться. Однако картинки, которые маркированы как не предназначенные для вывода, не имеют времен вывода. Таким образом, наличие картинок, которые маркированы как не предназначенные для вывода, может нарушить это требование ISOBMFF или может потребовать нестандартных методов обхода ошибок.
[0034] Таким образом, в соответствии с одним или более методами настоящего раскрытия, вычислительное устройство может генерировать файл, который содержит бокс медиа данных, который вмещает медиа контент. Медиа контент содержит последовательность выборок. Каждая из выборок содержит единицу доступа многоуровневых видеоданных. В качестве части генерации файла, вычислительное устройство может, в ответ на определение, что по меньшей мере одна единица доступа битового потока многоуровневых видеоданных включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению (например, 1), и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению (например, 0), использовать по меньшей мере два трека для хранения битового потока в файле. Для каждого соответствующего трека из по меньшей мере двух треков, все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки. Картинки, имеющие флаги вывода картинки, равные первому значению (например, 1), разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению (например, 0), разрешены для использования в качестве опорных картинок, но не разрешены для вывода. Использование по меньшей мере двух треков может разрешить проблему, описанную выше, так как каждой выборке в каждом треке может быть присвоено соответствующее время вывода, и видео декодер не может выводить картинки в треке, содержащем выборки, которые не разрешены для вывода.
[0035] Хотя большая часть описания методов настоящего раскрытия описывает MV-HEVC, 3D-HEVC и SHVC, понятно, что методы настоящего раскрытия могут применяться к другим стандартам видео кодирования и/или их расширениям.
[0036] Фиг. 1 является блок-схемой, иллюстрирующей пример системы 10 видео кодирования и декодирования, которая может использовать методы, описанные в настоящем раскрытии. Как показано на фиг. 1, система 10 включает в себя устройство-источник 12, которое генерирует кодированные видеоданные, подлежащие декодированию позже устройством-получателем 14. Устройство-источник 12 и устройство-получатель 14 могут содержать любое из широкого спектра устройств, включая настольные компьютеры, ноутбуки (т.е., портативные компьютеры), планшетные компьютеры, приставки, телефонные трубки, такие как так называемые смартфоны, так называемые смарт-планшеты, телевизоры, камеры, устройства отображения, цифровые медиа плееры, видеоигровые приставки, устройства потокового видео и т.п. В некоторых случаях устройство-источник 12 и устройство-получатель 14 могут быть выполнены с возможностью беспроводной связи. Устройство-источник 12 и устройство-получатель 14 могут рассматриваться как видео устройства.
[0037] В примере по фиг. 1, устройство-источник 12 включает в себя источник 18 видео, видео кодер 20 и выходной интерфейс 22. В некоторых случаях, выходной интерфейс 22 может включать в себя модулятор/демодулятор (модем) и/или передатчик. В устройстве-источнике 12, источник 18 видео может включать в себя такой источник, как устройство съемки видео, например, видео камеру, архив видео, содержащий ранее отснятое видео, интерфейс получения видео для приема видео от провайдера видео контента и/или систему компьютерной графики для генерации данных компьютерной графики, таких как исходное видео, или комбинацию таких источников. Однако методы, описанные в настоящем раскрытии, могут быть применены к видео кодированию в общем и могут быть применены к беспроводным и/или проводным приложениям.
[0038] Видео кодер 20 может кодировать снимаемое, предварительно отснятое или сгенерированное компьютером видео. Устройство-источник 12 может передавать кодированные видеоданные непосредственно на устройство-получатель 14 через выходной интерфейс 22 устройства-источника 12. Кодированные видеоданные могут также (или альтернативно) сохраняться в устройстве 33 хранения для последующего доступа устройством-получателем 14 или другими устройствами для декодирования и/или воспроизведения.
[0039] Устройство-получатель 14 включает в себя входной интерфейс 28, видео декодер 30 и устройство 32 отображения. В некоторых случаях входной интерфейс 28 может включать в себя приемник и/или модем. Входной интерфейс 28 устройства-получателя 14 принимает кодированные видеоданные по линии связи 16. Кодированные видеоданные, переданные по линии связи 16 или предоставленные на устройстве 33 хранения, могут включать в себя различные синтаксические элементы, сгенерированные видео кодером 20 для использования видео декодером, таким как видео декодер 30, при декодировании видеоданных. Такие синтаксические элементы могут быть включены в кодированные видеоданные, передаваемые по среде связи, сохраненные на носителе хранения или сохраненные на файловом сервере.
[0040] Устройство 32 отображения может быть встроенным в устройство-получатель 14 или может быть внешним по отношению к нему. В некоторых примерах, устройство-получатель 14 может включать в себя встроенное устройство отображения и может также быть сконфигурировано, чтобы взаимодействовать с внешним устройством отображения. В других примерах, устройство-получатель 14 может быть устройством отображения. В общем, устройство 32 отображения отображает декодированные видеоданные пользователю и может содержать любое из разнообразных устройств отображения, таких как жидкокристаллический дисплей (LCD), плазменный дисплей, дисплей на органических светоизлучающих диодах (OLED) или устройство отображения другого типа.
[0041] Видео кодер 20 и видео декодер 30 могут быть реализованы, каждый, как любая из разнообразных подходящих схем кодера, таких как один или более микропроцессоров, процессоров цифровых сигналов (DSP), специализированных интегральных схем (ASIC), программируемых вентильных матриц (FPGA), дискретная логика, программное обеспечение, аппаратные средства, программно-аппаратные средства или их комбинации. Когда методы реализованы частично в программном обеспечении, устройство может хранить инструкции для программного обеспечения на подходящем не-транзиторном (не-временном) считываемом компьютером носителе и исполнять инструкции в аппаратных средствах с использованием одного или более процессоров, чтобы выполнять методы настоящего раскрытия. Каждый из видео кодера 20 и видео декодера 30 может быть включен в один или более кодеров или декодеров, каждый из которых может быть встроен как часть комбинированного кодера/декодера (кодека) в соответствующее устройство.
[0042] Устройство-получатель 14 может принимать кодированные видеоданные, подлежащие декодированию, через линию связи 6. Линия связи 16 может содержать любой тип носителя или устройства, способного перемещать кодированные видеоданные от устройства-источника 12 к устройству-получателю 14. В одном примере, линия связи 16 может содержать среду связи, позволяющую устройству-источнику 12 передавать кодированные видеоданные непосредственно к устройству-получателю 14 в реальном времени. Кодированные видеоданные могут быть модулированы в соответствии со стандартом связи, таким как протокол беспроводной связи, и переданы к устройству-получателю 14. Среда связи может содержать любую беспроводную или проводную среду связи, такую как радиочастотный (RF) спектр или одна или более физических линий передачи. Среда связи может формировать часть пакетной сети, такой как локальная сеть, сеть широкого охвата или глобальная сеть, такая как Интернет. Среда связи может включать в себя маршрутизаторы, коммутаторы, базовые станции или любое другое оборудование, которое может быть полезным для обеспечения связи от устройства-источника 12 к устройству-получателю 14.
[0043] Альтернативно, выходной интерфейс 22 может выводить кодированные данные на устройство 33 хранения. Аналогично, входной интерфейс 28 может получать доступ к устройству 33 хранения кодированных данных. Устройство 33 хранения может включать в себя любые из различных распределенных или локально доступных носителей хранения данных, таких как накопитель на жестком диске, Blu-ray диски, DVD, CD-ROM, флэш-память, энергозависимая или энергонезависимая память или любые другие подходящие цифровые носители хранения для хранения кодированных видеоданных. В другом примере, устройство 33 хранения может соответствовать файловому серверу или другому промежуточному устройству хранения, которое может хранить кодированное видео, сгенерированное устройством-источником 12. Устройство-получатель 14 может получать доступ к сохраненным видеоданным с устройства 33 хранения посредством потоковой передачи или загрузки. Файловый сервер может быть любым типом сервера, способным хранить кодированные видеоданные и передавать эти кодированные видеоданные на устройство-получатель 14. Примеры файловых серверов включают в себя веб-сервер (например, для веб-сайта), FTP сервер, подключенные к сети устройства хранения (NAS) или накопитель на локальном диске. Устройство-получатель 14 может получать доступ к кодированным видеоданным через любое стандартное соединение передачи данных, включая Интернет-соединение. Это может включать в себя беспроводный канал (например, Wi-Fi соединение), проводное соединение (например, DSL, кабельный модем и т.д.) или комбинацию того и другого, которая подходит для доступа к кодированным видеоданным, сохраненным на файловом сервере. Передача кодированных видеоданных от устройства 33 хранения может быть потоковой передачей, передачей загрузки или их комбинацией.
[0044] Методы настоящего раскрытия не обязательно ограничены беспроводными приложениями или настройками. Методы могут быть применены к видео кодированию при поддержке любых из различных мультимедийных приложений, таких как беспроводное телевизионное вещание, передачи кабельного телевидения, передачи спутникового телевидения, передачи потокового видео, например, через Интернет, кодирование цифрового видео для хранения на носителе хранения данных, декодирование цифрового видео, сохраненного на носителе хранения данных, или других приложений. В некоторых примерах, система 10 может быть сконфигурирована для поддержки однонаправленной или двунаправленной передачи видео для поддержки приложений, таких как потоковое видео, видео воспроизведение, видео вещание и/или видео телефония.
[0045] Кроме того, в примере на фиг. 1, система 10 видео кодирования включает в себя устройство 34 генерации файла. Устройство 34 генерации файла может принимать кодированные видеоданные, сгенерированные устройством-источником 12. Устройство 34 генерации файла может генерировать файл, который включает в себя кодированные видеоданные. Устройство-получатель 14 может принимать файл, сгенерированный устройством 34 генерации файла. В различных примерах, устройство 34 генерации файла может включать в себя различные типы вычислительных устройств. Например, устройство 34 генерации файла может содержать медиа-информированный сетевой элемент (MANE), серверное вычислительное устройство, персональное вычислительное устройство, специализированное вычислительное устройство, коммерческое вычислительное устройство или любой другой тип вычислительного устройства. В некоторых примерах, устройство 34 генерации файла является частью сети доставки контента. Устройство 34 генерации файла может принимать кодированные видеоданные от устройства-источника 12 через канал, такой как линия связи 16. Кроме того, устройство-получатель 14 может принимать файл от устройства 34 генерации файла через канал, такой как линия связи 16. Устройство 34 генерации файла может рассматриваться как видео устройство.
[0046] В других примерах, устройство-источник 12 или другое вычислительное устройство может генерировать файл, который включает в себя кодированные видеоданные. Однако для простоты объяснения, настоящее раскрытие описывает устройство 34 генерации файла как генерирующее файл. Тем не менее, должно быть понятно, что такие описания применимы к вычислительным устройствам в общем.
[0047] Видео кодер 20 и видео декодер 30 могут работать в соответствии со стандартом сжатия видео, таким как стандарт Высокоэффективного видео кодирования (HEVC) или его расширение. Стандарт HEVC может также упоминаться как ISO/IEC 23008-2. Недавно структура HEVC была финализирована Объединенной группой по сотрудничеству в области видео кодирования (JCT-VC) Группы экспертов по видео кодированию (VCEG) ITU-T и Группой экспертов по движущимся изображениям (MPEG) ISO/IEC. Последняя проектная спецификация HEVC, упоминаемая далее как HEVC WD, доступна из http://phenix.int-evry.fr/jct/doc_end_user/documents/14_Vienna/wg11/JCTVC-N1003-v1.zip. Многовидовое расширение HEVC, а именно, MV-HEVC, также разрабатывается JCT-3V. Последний рабочий проект (WD) MV-HEVC, озаглавленный ʺMV-HEVC Draft Text 5ʺ и упоминаемый далее как MV-HEVC WD5, доступен из http://phenix.it-sudparis.eu/jct2/doc_end_user/documents/5_Vienna/wg11/JCT3V-E1004-v6.zip. Масштабируемое расширение HEVC, называемое SHVC, также разрабатывается JCT-VC. Последний рабочий проект (WD) SHVC, озаглавленный ʺHigh efficiency video coding (HEVC) scalable extension draft 3ʺ и упоминаемый далее как SHVC WD3, доступен из http://phenix.it-sudparis.eu/jct/doc_end_user/documents/14_Vienna/wg11/JCTVC-N1008-v3.zip. Последний рабочий проект (WD) расширения диапазона HEVC доступен из http://phenix.int-evry.fr/jct/doc_end_user/documents/14_Vienna/wg11/JCTVC-N1005-v3.zip. Последний рабочий проект (WD) 3D-расширения HEVC, а именно, 3D-HEVC, озаглавленный ʺ3D-HEVC Draft Text 1ʺ, доступен из http://phenix.int-evry.fr/jct2/doc_end_user/documents/5_Vienna/wg11/JCT3V-E1001-v3.zip. Видео кодер 20 и видео декодер 30 могут работать в соответствии с одним или более из этих стандартов.
[0048] Альтернативно, видео кодер 20 и видео декодер 30 могут работать в соответствии с другими проприетарными или промышленными стандартами, такими как стандарт ITU-T H.264, альтернативно упоминаемый как MPEG 4, часть 10, Расширенное видео кодирование (AVC) или расширения этих стандартов. Методы настоящего раскрытия, однако, не ограничены каким-либо конкретным стандартом кодирования. Другие примеры стандартов сжатия видео включают в себя 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).
[0049] Хотя не показано на фиг. 1, в некоторых аспектах, видео кодер 20 и видео декодер 30 могут быть интегрированы, каждый, в аудио кодер и декодер и могут включать в себя соответствующие блоки мультиплексирования-демультиплексирования (MUX-DEMUX) или другие аппаратные средства и программное обеспечение, чтобы обрабатывать кодирование как аудио, так и видео в общем потоке данных или отдельных потоках данных. Если применимо, в некоторых примерах, блоки MUX-DEMUX могут соответствовать протоколу мультиплексора ITU H.223 или другим протоколам, таким как протокол пользовательских дейтаграмм (UDP).
[0050] JCT-VC работает над развитием стандарта HEVC. Усилия по стандартизации HEVC основаны на развитой модели устройства видео кодирования, упоминаемой как тестовая модель HEVC (HM). HM предполагает различные дополнительные функциональные возможности устройств видео кодирования относительно существующих устройств в соответствии, например, с ITU-T H.264/AVC. Например, в то время как H.264/AVC обеспечивает девять режимов кодирования с интра-предсказанием, HM может обеспечивать тридцать три режима кодирования с интра-предсказанием.
[0051] В общем, рабочая модель HM описывает, что видео кадр или картинка может быть разделена на последовательность блоков дерева или наибольших единиц кодирования (LCU), которые включают в себя выборки яркости и цветности. Блоки дерева могут также упоминаться как единицы дерева кодирования (CTU). Блок дерева имеет сходное назначение, как и у макроблока H.264/AVC. Вырезка включает в себя ряд последовательных блоков дерева в порядке кодирования. Видео кадр или картинка могут быть разделены на одну или более вырезок. Каждый блок дерева может быть разбит на единицы кодирования (CU) в соответствии с квадродеревом. Например, блок дерева, такой как корневой узел квадродерева, может быть разбит на четыре дочерних узла, и каждый дочерний узел может, в свою очередь, быть родительским узлом и может быть разбит на другие четыре дочерних узла. В итоге, неразбитый дочерний узел, в качестве листового узла квадродерева, содержит узел кодирования, т.е. кодированный видео блок. Синтаксические данные, ассоциированные с кодированным битовым потоком, могут определять максимальное число раз разбиения блока дерева и могут также определять минимальный размер узлов кодирования.
[0052] CU включает в себя узел кодирования и единицы предсказания (PU) и единицы преобразования (TU), ассоциированные с узлом кодирования. Размер CU соответствует размеру узла кодирования и должен быть квадратной формы. Размер CU может находиться в пределах от 8×8 пикселов до размера блока дерева максимум 64x64 пиксела или больше. Каждая CU может содержать одну или более PU и одну или более TU. Синтаксические данные, ассоциированные с CU, могут описывать, например, разделение CU на одну или более PU. Режимы разделения могут различаться в соответствии с тем, кодирована ли CU в режиме пропуска или в прямом режиме, кодирована в режиме интра-предсказания или кодирована в режиме интер-предсказания. PU могут быть разделены в неквадратную форму. Синтаксические данные, ассоциированные с CU, могут также описывать, например, разделение CU на одну или более TU в соответствии с квадродеревом. TU может быть квадратной или неквадратной формы.
[0053] Стандарт HEVC позволяет осуществлять преобразования в соответствии с TU, которые могут быть различными для различных CU. TU типично выбираются с размерами на основе размера PU в данной CU, определенной для разделенной LCU, хотя это может не всегда иметь место. TU типично имеют тот же размер или меньше, чем PU. В некоторых примерах, остаточные выборки, соответствующие CU, могут быть подразделены на меньшие единицы с использованием структуры квадродерева, известного как ʺостаточное квадродеревоʺ (RQT). Листовые узлы RQT могут упоминаться как TU. Пиксельные разностные значения, ассоциированные с TU, могут быть преобразованы для получения коэффициентов преобразования, которые могут быть квантованы.
[0054] В общем, PU включает в себя данные, относящиеся к процессу предсказания. Например, если PU кодирована в интра-режиме, PU может включать в себя данные, описывающие режим интра-предсказания для PU. В качестве другого примера, когда PU является кодированной в интер-режиме, PU может включать в себя данные, определяющие вектор движения для PU. Данные, определяющие вектор движения для PU, могут описывать, например, горизонтальный компонент вектора движения, вертикальный компонент вектора движения, разрешение для вектора движения (например, точность в одну четвертую пиксела или точность в одну восьмую пиксела), опорную картинку, на которую указывает вектор движения, и/или список опорных картинок (например, список 0, список 1 или список C) для вектора движения.
[0055] В общем, TU используется для процессов преобразования и квантования. Данная CU, имеющая одну или более PU, может также включать в себя одну или более единиц преобразования (TU). Следуя предсказанию, видео кодер 20 может вычислять остаточные значения, соответствующие PU. Остаточные значения содержат пиксельные разностные значения, которые могут быть преобразованы в коэффициенты преобразования, квантованы и просканированы с использованием TU, чтобы получить преобразованные в последовательную форму коэффициенты преобразования для энтропийного кодирования. Настоящее раскрытие типично использует термин ʺвидео блокʺ, чтобы ссылаться на узел кодирования (т.е., блок кодирования) CU. В некоторых специальных случаях, настоящее раскрытие может также использовать термин ʺвидео блокʺ, чтобы ссылаться на блок дерева, т.е., LCU или CU, что включает в себя узел кодирования и PU и TU.
[0056] Видео последовательность обычно включает в себя последовательность видео кадров или картинок. Группа картинок (GOP) в общем случае содержит последовательность из одной или более видео картинок. GOP может включать в себя синтаксические данные в заголовке GOP, заголовке одной или более из картинок или еще где-либо, которые описывают ряд картинок, включенных в GOP. Каждая вырезка картинки может включать в себя синтаксические данные вырезки, которые описывают режим кодирования для соответствующей вырезки. Видео кодер 20 обычно работает на видео блоках в пределах отдельных видео вырезок, чтобы кодировать видеоданные. Видео блок может соответствовать узлу кодирования в CU. Видео блоки могут иметь фиксированные или переменные размеры и могут отличаться по размерам в соответствии с конкретным стандартом кодирования.
[0057] В качестве примера, HM поддерживает предсказание в различных размерах PU. Предполагая, что размер конкретной CU равен 2N×2N, HM поддерживает интра-предсказание в размерах PU 2N×2N или N×N и интер-предсказание в размерах симметричной PU 2N×2N, 2N×N, N×2N или N×N. HM также поддерживает асимметричное разделение для интер-предсказания в размерах PU 2N×nU, 2N×nD, nL×2N и nR×2N. В асимметричном разделении, одно направление CU не разделяется, в то время как другое направление разделяется на 25% и 75%. Часть CU, соответствующая части 25%, указывается посредством ʺnʺ с последующим указанием ʺВверхʺ, ʺВнизʺ, ʺВлевоʺ или ʺВправоʺ. Таким образом, например, ʺ2N×nUʺ относится к 2N×2N CU, которая разделена горизонтально с 2N×0,5N PU сверху и 2N×1,5N PU снизу.
[0058] В настоящем раскрытии, ʺN×Nʺ и ʺN на Nʺ может быть использовано взаимозаменяемым образом для ссылки на пиксельные размеры видео блока в терминах вертикального и горизонтального размеров, например, 16×16 пикселов или 16 на 16 пикселов. В общем, блок 16×16 имеет 16 пикселов в вертикальном направлении (y=16) и 16 пикселов в горизонтальном направлении (x=16). Аналогичным образом, блок N×N в общем содержит N пикселов в вертикальном направлении и N пикселов в горизонтальном направлении, где N представляет неотрицательное целое значение. Пикселы в блоке могут быть упорядочены в строки и столбцы. Кроме того, блоки не обязательно должны иметь то же самое число пикселов в горизонтальном направлении, что и в вертикальном направлении. Например, блоки могут содержать N×M пикселов, где M не обязательно равно N.
[0059] Следуя кодированию с интра-предсказанием или интер-предсказанием с использованием PU для CU, видео кодер 20 может вычислить остаточные данные для TU в CU. PU могут содержать пиксельные данные в пространственной области (также упоминается как пиксельная область), и TU могут содержать коэффициенты в области преобразования в соответствии с применением преобразования, например, дискретного косинусного преобразования (DCT), целочисленного преобразования, вейвлетного преобразования или концептуально подобного преобразования к остаточным видеоданным. Остаточные данные могут соответствовать пиксельным разностям между пикселами не кодированной картинки и значениями предсказания, соответствующими PU. Видео кодер 20 может формировать TU, включающие в себя остаточные данные для CU, и затем преобразовывать TU для получения коэффициентов преобразования для CU.
[0060] Вслед за любыми преобразованиям для получения коэффициентов преобразования, видео кодер 20 может выполнять квантование коэффициентов преобразования. Квантование, в общем, относится к процессу, в котором коэффициенты преобразования квантуются, чтобы по возможности уменьшить количество данных, используемых для представления коэффициентов, обеспечивая дополнительное сжатие. Процесс квантования может уменьшить битовую глубину, ассоциированную с некоторыми или всеми из коэффициентов. Например, n-битовое значение может быть округлено вниз до m-битового значения при квантовании, где n больше, чем m.
[0061] В некоторых примерах, видео кодер 20 может использовать предопределенный порядок сканирования, чтобы сканировать квантованные коэффициенты преобразования для получения преобразованного в последовательную форму вектора, который может энтропийно кодироваться. В других примерах, видео кодер 20 может выполнять адаптивное сканирование. После сканирования квантованных коэффициентов преобразования для формирования одномерного вектора, видео кодер 20 может энтропийно кодировать одномерный вектор, например, в соответствии с контекстно-адаптивным кодированием переменной длины (CAVLC), контекстно-адаптивным бинарным арифметическим кодированием (CABAC), основанным на синтаксисе контекстно-адаптивным бинарным арифметическим кодированием (SBAC), энтропийным кодированием с разделением интервалов вероятности (PIPE) или другой методологией энтропийного кодирования. Видео кодер 20 может также энтропийно кодировать синтаксические элементы, ассоциированные с кодированными видеоданными, для использования видео декодером 30 в дeкодировании видеоданных.
[0062] Для выполнения CABAC, видео кодер 20 может назначить контекст в контекстной модели для символа, подлежащего передаче. Контекст может относиться, например, к тому, являются ли соседние значения символа ненулевыми или нет. Для выполнения CAVLC, видео кодер 20 может выбрать код переменной длины для символа, подлежащего передаче. Кодовые слова в кодировании переменной длины (VLC) могут конструироваться так, что относительно более короткие коды соответствуют более вероятным символам, в то время как более длинные коды соответствуют менее вероятным символам. Таким путем, использование VLC может обеспечить экономию битов по сравнению, например, с использованием кодовых слов равной длины для каждого символа, подлежащего передаче. Определение вероятности может быть основано на контексте, назначенном символу.
[0063] Видео кодер 20 может выводить битовый поток, который включает в себя последовательность битов, которая формирует представление кодированных картинок и ассоциированных данных. Термин ʺбитовый потокʺ может быть обобщенным термином, используемым, чтобы ссылаться либо на поток единиц уровня сетевой абстракции (NAL) (например, последовательность NAL-единиц), либо битовый поток (например, инкапсулирование потока NAL-единиц, содержащего префиксы начального кода и NAL-единицы, как определено в Приложении B стандарта HEVC). NAL-единица является синтаксической структурой, содержащей указание типа данных в NAL-единице и байты, содержащие эти данные в форме полезной нагрузки последовательности исходных байтов (RBSP), рассеянной, как необходимо, с битами предотвращения эмуляции. Каждая из NAL-единиц может включать в себя заголовок NAL-единицы и может инкапсулировать RBSP. Заголовок NAL-единицы может включать в себя синтаксический элемент, который указывает код типа NAL-единицы. Код типа NAL-единицы, заданный заголовком NAL- единицы для NAL-единицы, указывает тип NAL-единицы. RBSP может быть синтаксической структурой, содержащей целое число байтов, которые инкапсулированы в NAL-единице. В некоторых случаях RBSP включает в себя нуль битов.
[0064] Различные типы NAL-единиц могут инкапсулировать различные типы RBSP. Например, первый тип NAL-единицы может инкапсулировать RBSP для набора параметров картинки (PPS), второй тип NAL-единицы может инкапсулировать RBSP для сегмента вырезки, третий тип NAL-единицы может инкапсулировать RBSP для информации дополнительного расширения (SEI) и т.д. NAL-единицы, которые инкапсулируют RBSP для данных видео кодирования (в противоположность RBSP для наборов параметров и сообщений SEI), могут упоминаться как NAL-единицы уровня видео кодирования (VCL). NAL-единицы, которые содержат наборы параметров (например, наборы параметров видео (VPS), наборы параметров последовательности (SPS), PPS и т.д.), могут упоминаться как NAL- единицы набора параметров.
[0065] Настоящее раскрытие может ссылаться на NAL-единицу, которая инкапсулирует RBSP для вырезки сегмента, как на NAL-единицу кодированной вырезки. Как определено в HEVC WD, сегмент вырезки является целым числом CTU, упорядоченных последовательно в скане элемента мозаичного изображения и содержащихся в одной NAL-единице. В противоположность этому, в HEVC WD, вырезка может быть целым числом CTU, содержащихся в одном независимом сегменте вырезки и всех последующих зависимых сегментах вырезки (если имеются), которые предшествуют следующему независимому сегменту вырезки (если имеется) в пределах той же самой единицы доступа. Независимый сегмент вырезки является сегментом вырезки, для которого значения синтаксических элементов заголовка сегмента вырезки не выводятся из значений для предшествующего сегмента вырезки. Зависимый сегмент вырезки является сегментом вырезки, для которого значения некоторых синтаксических элементов заголовка сегмента вырезки выводятся из значений для предшествующего независимого сегмента вырезки в порядке декодирования. RBSP NAL-единицы кодированной вырезки может включать в себя заголовок сегмента вырезки и данные вырезки. Заголовок сегмента вырезки является частью сегмента кодированной вырезки, содержащего элементы данных, относящиеся к первой или всем CTU, представленным в сегменте вырезки. Заголовок вырезки является заголовком сегмента вырезки независимого сегмента вырезки, который является текущим сегментом вырезки или самым последним независимым сегментом вырезки, который предшествует текущему зависимому сегменту вырезки в порядке декодирования.
[0066] VPS является синтаксической структурой, содержащей синтаксические элементы, которые применяются к нулю или более всех последовательностей кодированного видео (CVS). SPS является синтаксической структурой, содержащей синтаксические элементы, которые применяются к нулю или более всех CVS. SPS может включать в себя синтаксический элемент, который идентифицирует VPS, который является активным, когда SPS активен. Таким образом, синтаксические элементы VPS могут применяться в большей степени, чем синтаксические элементы SPS.
[0067] Набор параметров (например, VPS, SPS, PPS и т.д.) может содержать идентификацию для ссылки, прямо или косвенно, из заголовка вырезки. Процесс ссылки известен как ʺактивацияʺ. Таким образом, когда видео декодер 30 декодирует конкретную вырезку, набор параметров, на который ссылается, прямо или косвенно, синтаксический элемент в заголовке вырезки конкретной вырезки, становится ʺактивированнымʺ. В зависимости от типа набора параметров, активация может происходить на основе по каждой картинке или на основе по каждой последовательности. Например, заголовок вырезки может включать в себя синтаксический элемент, который идентифицирует PPS. Таким образом, когда видео кодер кодирует вырезку, PPS может быть активирован. Кроме того, PPS может включать в себя синтаксический элемент, который идентифицирует SPS. Таким образом, когда PPS, который идентифицирует SPS, активирован, SPS может быть активирован. SPS может включать в себя синтаксический элемент, который идентифицирует VPS. Таким образом, когда SPS, который идентифицирует VPS, активирован, VPS активируется.
[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] В HEVC WD, CVS может начинаться из картинки мгновенного обновления декодирования (IDR) или картинки доступа прерванной связи (BLA) или картинки чисто произвольного доступа (CRA), которая является первой картинкой в битовом потоке, включая все последующие картинки, которые не являются IDR- или BLA-картинками. IDR-картинка содержит только I-вырезки (т.е., вырезки, в которых используется только интра-предсказание). IDR-картинка может быть первой картинкой в битовом потоке в порядке декодирования или может появиться позже в битовом потоке. Каждая IDR-картинка является первой картинкой CVS в порядке декодирования. В HEVC WD, IDR-картинка может быть картинкой внутренней точки произвольного доступа (IRAP), для которой каждая VCL NAL-единица имеет nal_unit_type, равный IDR_W_RADL или IDR_N_LP.
[0070] IDR-картинки могут быть использованы для произвольного доступа. Однако картинки, следующие за IDR-картинкой в порядке декодирования, не могут использовать картинки, декодированные перед IDR-картинкой, в качестве опоры. Соответственно, битовые потоки, основывающиеся на IDR-картинках произвольного доступа, могут иметь значительно более низкую эффективность кодирования, чем битовые потоки, которые используют дополнительные типы картинок произвольного доступа. В по меньшей мере некоторых примерах, IDR-единица доступа является единицей доступа, которая содержит IDR-картинку.
[0071] Понятие CRA-картинки было введено в HEVC, чтобы позволить картинкам, которые следуют за CRA-картинкой в порядке декодирования, но предшествуют CRA-картинке в порядке вывода, использовать картинки, декодированные перед CRA-картинкой, в качестве опоры. Картинки, которые следуют за CRA-картинкой в порядке декодирования, но предшествуют CRA-картинке в порядке вывода, упоминаются как передние картинки, ассоциированные с CRA-картинкой (или передние картинки CRA-картинки). То есть, чтобы улучшить эффективность кодирования, понятие CRA-картинки было введено в HEVC, чтобы позволить картинкам, которые следуют за CRA-картинкой в порядке декодирования, но предшествуют CRA-картинке в порядке вывода, использовать картинки, декодированные перед CRA-картинкой, в качестве опоры. CRA-единица доступа является единицей доступа, в которой кодированная картинка является CRA-картинкой. В HEVC WD, CRA-картинка является внутренней картинкой произвольного доступа, для которой каждая VCL NAL-единица имеет nal_unit_type, равный CRA_NUT.
[0072] Передние картинки CRA-картинки могут корректно декодироваться, если декодирование начинается из IDR-картинки или CRA-картинки, появляющейся перед CRA-картинкой в порядке декодирования. Однако передние картинки CRA-картинки могут быть не декодируемыми, если возникает произвольный доступ из CRA-картинки. Таким образом, видео декодер типично декодирует передние картинки CRA-картинки при декодировании произвольного доступа. Чтобы предотвратить распространение ошибок из опорных картинок, которые могут быть недоступными, в зависимости от того, где начинается декодирование, никакая картинка, которая следует за CRA-картинкой как в порядке декодирования, так и в порядке вывода, не может использовать никакую картинку, которая предшествует CRA-картинке как в порядке декодирования, так и в порядке вывода (что включает в себя передние картинки) в качестве опоры.
[0073] Понятие BLA-картинки было введено в HEVC после введения CRA-картинок и основано на идее CRA-картинок. BLA-картинка типично происходит из битового потока, состыкованного в позиции CRA-картинки, и в состыкованном битовом потоке, CRA-картинка точки стыковки изменяется на BLA-картинку. Таким образом, BLA-картинки могут быть CRA-картинками в исходных битовых потоках, и CRA-картинка заменяется на BLA-картинку средством стыковки битового потока после стыковки битового потока в местоположении CRA-картинки. В некоторых случаях, единица доступа, которая содержит RAP-картинку, может упоминаться здесь как RAP-единица доступа. BLA-единица доступа является единицей доступа, которая содержит BLA-картинку. В HEVC WD, BLA-картинка может быть внутренней картинкой произвольного доступа, для которой каждая VCL NAL-единица имеет nal_unit_type, равный BLA_W_LP, BLA_W_RADL или BLA_N_LP.
[0074] Как правило, IRAP-картинка содержит только I-вырезки и может быть BLA-картинкой, CRA-картинкой или IDR-картинкой. Например, HEVC WD указывает, что IRAP-картинка может быть кодированной картинкой, для которой VCL NAL-единица имеет nal_unit_type в диапазоне от BLA_W_LP до RSV_IRAP_VCL23, включительно. Кроме того, HEVC WD указывает, что первая картинка в битовом потоке в порядке декодирования должна быть IRAP-картинкой. Таблица 7-1 HEVC WD показывает коды типов NAL-единицы и классы типов NAL-единицы. Таблица 7-1 HEVC WD воспроизведена ниже.
| Таблица 7-1 Коды типов NAL-единицы и классы типов NAL-единицы |
|||
| nal_unit_type | Имя nal_unit_type | Содержимое NAL-единицы и структура синтаксиса RBSP | Класс типа NAL-единицы |
| 0 1 | TRAIL_N TRAIL_R | Кодированный сегмент вырезки не-TSA, не-STSA замыкающей картинки slice_segment_layer_rbsp() | VCL |
| 2 3 | TSA_N TSA_R | Кодированный сегмент вырезки TSA- картинки slice_segment_layer_rbsp() | VCL |
| 4 5 | STSA_N STSA_R | Кодированный сегмент вырезки STSA-картинки slice_segment_layer_rbsp() |
VCL |
| 6 7 | RADL_N RADL_R | Кодированный сегмент вырезки RADL-картинки slice_segment_layer_rbsp() |
VCL |
| 8 9 | RASL_N RASL_R | Кодированный сегмент вырезки RASL-картинки slice_segment_layer_rbsp() | VCL |
| 10 12 14 | RSV_VCL_N10 RSV_VCL_N12 RSV_VCL_N14 | Зарезервированные типы неопорной VCL NAL-единицы не-IRAP-подуровня | VCL |
| 11 13 15 | RSV_VCL_R11 RSV_VCL_R13 RSV_VCL_R15 | Зарезервированные типы опорной VCL NAL-единицы не-IRAP-подуровня | VCL |
| 16 17 18 | BLA_W_LP BLA_W_RADL BLA_N_LP | Кодированный сегмент вырезки BLA-картинки slice_segment_layer_rbsp() | VCL |
| 19 20 | IDR_W_RADL IDR_N_LP | Кодированный сегмент вырезки IDR- картинки slice_segment_layer_rbsp() | VCL |
| 21 | CRA_NUT | Кодированный сегмент вырезки CRA-картинки slice_segment_layer_rbsp() | VCL |
| 22 23 | RSV_IRAP_VCL22 RSV_IRAP_VCL23 | Зарезервированные типы IRAP VCL NAL-единицы | VCL |
| 24..31 | RSV_VCL24.. RSV_VCL31 | Зарезервированные типы не-IRAP VCL NAL-единицы | VCL |
| 32 | VPS_NUT | Набор параметров видео video_parameter_set_rbsp() | не-VCL |
| 33 | SPS_NUT | Набор параметров последовательности seq_parameter_set_rbsp() | не-VCL |
| 34 | PPS_NUT | Набор параметров картинки pic_parameter_set_rbsp() | не-VCL |
| 35 | AUD_NUT | Разделитель единицы доступа access_unit_delimiter_rbsp() | не-VCL |
| 36 | EOS_NUT | Конец последовательности end_of_seq_rbsp() | не-VCL |
| 37 | EOB_NUT | Конец битового потока end_of_bitstream_rbsp() | не-VCL |
| 38 | FD_NUT | Данные заполнителя filler_data_rbsp() | не-VCL |
| 39 40 | PREFIX_SEI_NUT SUFFIX_SEI_NUT | Дополнительная инфорация расширения sei_rbsp() | не-VCL |
| 41..47 | RSV_NVCL41.. RSV_NVCL47 | Зарезервировано | не-VCL |
| 48..63 | UNSPEC48.. UNSPEC63 | Не определено | не-VCL |
[0075] Одно различие между BLA-картинкой и CRA-картинкой состоит в следующем. Для CRA-картинки, ассоциированные передние картинки являются корректно декодируемыми, если декодирование начинается с RAP-картинки перед CRA-картинкой в порядке декодирования. Однако передние картинки, ассоциированные с CRA-картинкой, могут не быть корректно декодируемыми, если возникает произвольный доступ из CRA-картинки (т.е., когда декодирование начинается из CRA-картинки, или, иными словами, когда CRA-картинка является первой картинкой в битовом потоке). Напротив, может не быть сценария, где передние картинки, ассоциированные с BLA-картинкой, являются декодируемыми, даже если декодирование начинается из RAP-картинки перед BLA-картинкой в порядке декодирования.
[0076] Некоторые из передних картинок, ассоциированных с конкретной CRA-картинкой или конкретной BLA-картинкой, могут быть корректно декодируемыми, даже если конкретная CRA-картинка или конкретная BLA-картинка является первой картинкой в битовом потоке. Эти передние картинки могут упоминаться как декодируемые передние картинки (DLP) или декодируемые передние картинки произвольного доступа (RADL). В HEVC WD, RADL-картинка может быть кодированной картинкой, для которой каждая VCL NAL-единица имеет nal_unit_type, равный RADL_R или RADL_N. Кроме того, HEVC WD указывает, что все RADL-картинки являются передними картинками, и что RADL-картинки не используются как опорные картинки для процесса декодирования замыкающих картинок той же самой ассоциированной IRAP-картинки. В случае присутствия, все RADL-картинки предшествуют, в порядке декодирования, всем замыкающим картинкам той же самой ассоциированной IRAP-картинки. HEVC WD указывает, что RADL-единица доступа может быть единицей доступа, в которой кодированная картинка является RADL-картинкой. Замыкающая картинка может быть картинкой, которая следует за ассоциированной IRAP-картинкой (т.е., предыдущей IRAP-картинкой в порядке декодирования) в порядке вывода.
[0077] Другие передние картинки могут упоминаться как не-декодируемые передние картинки (NLP) или пропущенные передние картинки произвольного доступа (RASL). В HEVC WD, RASL-картинка может быть кодированной картинкой, для которой каждая VCL NAL-единица имеет nal_unit_type, равный RASL_R или RASL_N. Все RASL-картинки являются передними картинками ассоциированной BLA- или CRA-картинки.
[0078] При условии, что необходимые наборы параметров доступны, когда они должны быть активированы, IRAP-картинка и все последующие не-RASL-картинки в порядке декодирования могут быть корректно декодированы без выполнения процесса декодирования любой картинки, которая предшествует IRAP-картинке в порядке декодирования. Могут иметься картинки в битовом потоке, которые содержат только I-вырезки, которые не являются IRAP-картинками.
[0079] В многовидовом кодировании, может иметься множество видов (изображений) той же самой сцены с различных точек наблюдения. Термин ʺединица доступаʺ может быть использован для ссылки на набор картинок, которые соответствуют тому же самому моменту времени. Таким образом, видеоданные могут быть концептуализированы как последовательность единиц доступа, возникающих во времени. ʺВидовой компонентʺ может быть кодированным представлением вида в одной единице доступа. В настоящем раскрытии, ʺвидʺ может относиться к последовательности или набору видовых компонентов, ассоциированных с тем же самым видовым идентификатором. Видовой компонент может содержать видовой компонент текстуры и видовой компонент глубины. В настоящем раскрытии, ʺвидʺ может относиться к набору или последовательности из одного или более видовых компонентов, ассоциированных с тем же самым видовым идентификатором.
[0080] Видовой компонент текстуры (т.е., картинка текстуры) может быть кодированным представлением текстуры вида в одной единице доступа. Вид текстуры может быть последовательностью видовых компонентов текстуры, ассоциированных с идентичным значением порядкового индекса вида. Порядковый индекс вида может указывать позицию камеры данного вида относительно других видов. Видовой компонент глубины (т.е., картинка глубины) может быть кодированным представлением глубины вида в одной единице доступа. Вид глубины может быть набором или последовательностью одного или более видовых компонентов, ассоциированных с идентичным значением порядкового индекса вида.
[0081] В MV-HEVC, 3D-HEVC и SHVC, видео кодер может генерировать битовый поток, который содержит последовательность NAL-единиц. Различные NAL-единицы битового потока могут быть ассоциированы с различными уровнями битового потока. Уровень может быть определен как набор VCL NAL-единиц и ассоциированных не-VCL NAL-единиц, которые имеют тот же самый идентификатор уровня. Уровень может быть эквивалентен виду в многовидовом видео кодировании. В многовидовом видео кодировании, уровень может содержать все видовые компоненты того же самого уровня с различными моментами времени. Каждый видовой компонент может быть кодированной картинкой видео сцены, принадлежащей к конкретному виду в конкретный момент времени. В некоторых примерах 3D видео кодирования, уровень может содержать либо все кодированные картинки глубины конкретного вида, либо кодированные картинки текстуры конкретного вида. В других примерах 3D видео кодирования, уровень может содержать как видовые компоненты текстуры, так и видовые компоненты глубины конкретного вида. Аналогично, в контексте масштабируемого видео кодирования, уровень обычно соответствует кодированным картинкам, имеющим характеристики видео, отличающиеся от кодированных картинок в других уровнях. Такие характеристики видео обычно включают в себя пространственное разрешение и уровень качества (например, отношение сигнал/шум). В HEVC и его расширениях, временная масштабируемость может быть достигнута в пределах одного уровня путем определения группы картинок с конкретным временным уровнем в качестве подуровня.
[0082] Для каждого соответствующего уровня битового потока, данные на более низком уровне могут быть декодированы без ссылки на данные в каком-либо более высоком уровне. В масштабируемом видео кодировании, например, данные на базовом уровне могут быть декодированы без ссылки на данные на уровне расширения. В общем, NAL-единицы могут только инкапсулировать данные одного уровня. Таким образом, NAL-единицы, инкапсулирующие данные наивысшего из остальных уровней битового потока, могут быть удалены из битового потока без влияния на возможность декодирования данных на остальных уровнях битового потока. В многовидовом кодировании и 3D-HEVC, более высокие уровни могут включать в себя дополнительные видовые компоненты. В SHVC, более высокие уровни могут включать в себя данные расширения отношения сигнал/шум (SNR), данные пространственного расширения и/или данные временного расширения. В MV-HEVC, 3D-HEVC и SHVC, уровень может упоминаться как ʺбазовый уровеньʺ, если видео декодер может декодировать картинки на данном уровне без ссылки на данные любого другого уровня. Базовый уровень может соответствовать базовой спецификации HEVC (например, HEVC WD).
[0083] В SVC, уровни иные, чем базовый уровень, могут упоминаться как ʺуровни расширенияʺ и могут предоставлять информацию, которая улучшает визуальное качество видеоданных, декодированных из битового потока. SVC может улучшать пространственное разрешение, отношение сигнал/шум (т.е., качество) или временной показатель. В масштабируемом видео кодировании (например, SHVC), ʺпредставление уровняʺ может быть кодированным представлением пространственного уровень в одной единице доступа. Для простоты объяснения, настоящее раскрытие может ссылаться на видовые компоненты и/или представления уровня как на ʺвидовые компоненты/представления уровняʺ или просто ʺкартинкиʺ.
[0084] Для реализации уровней, заголовки 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, которые определяют различные значения, принадлежат к различным уровням битового потока.
[0085] В некоторых примерах, синтаксический элемент nuh_layer_id NAL-единицы равен 0, если NAL-единица относится к базовому уровню в многовидовом кодировании (например, MV-HEVC), 3DV кодировании (например, 3D-HEVC) или масштабируемом видео кодировании (например, SHVC). Данные на базовом уровне битового потока могут быть декодированы без ссылки на данные на каком-либо другом уровне битового потока. Если NAL-единица не относится к базовому уровню в многовидовом кодировании, 3DV или масштабируемом видео кодировании, синтаксический элемент nuh_layer_id NAL-единицы может иметь ненулевое значение.
[0086] Кроме того, некоторые видовые компоненты/представления уровня в пределах уровня могут быть декодированы без ссылки на другие видовые компоненты/представления уровня в пределах того же самого уровня. Таким образом, NAL-единицы, инкапсулирующие данные некоторых видовых компонентов/представлений уровня некоторого уровня, могут быть удалены из битового потока без влияния на возможность декодирования других видовых компонентов/представлений уровня на данном уровне. Удаление NAL-единиц, инкапсулирующих данные таких видовых компонентов/представлений уровня, может снизить частоту кадров битового потока. Поднабор видовых компонентов/представлений уровня в пределах уровня, который может быть декодирован без ссылки на другие видовые компоненты/представления уровня в пределах уровня, может упоминаться здесь как ʺподуровеньʺ или ʺвременной подуровеньʺ.
[0087] NAL-единицы могут включать в себя синтаксические элементы temporal_id, которые определяют временные идентификаторы (т.е., TemporalId) NAL-единиц. Временной идентификатор NAL-единицы идентифицирует подуровень, которому принадлежит NAL-единица. Таким образом, каждый подуровень битового потока может иметь отличающийся временной идентификатор. В общем, если временной идентификатор первой NAL-единицы уровня меньше, чем временной идентификатор второй NAL-единицы того же уровня, данные, инкапсулированные первой NAL-единицей, могут быть декодированы без ссылки на данные, инкапсулированные второй NAL-единицей.
[0088] Битовый поток может быть ассоциирован с множеством рабочих точек. Каждая рабочая точка битового потока ассоциирована с набором идентификаторов уровня (например, набором значений nuh_layer_id) и временным идентификатором. Набор идентификаторов уровня может быть обозначен как OpLayerIdSet, и временной идентификатор может быть обозначен как TemporalID. Если идентификатор уровня NAL-единицы находится в наборе идентификаторов уровня рабочей точки, и временной идентификатор NAL-единицы меньше или равен временному идентификатору рабочей точки, NAL-единица ассоциирована с рабочей точкой. Таким образом, рабочая точка может соответствовать поднабору NAL-единиц в битовом потоке.
[0089] Как изложено выше, настоящее раскрытие относится к сохранению видео контента в файле на основе базового формата медиа файла ISO (ISOBMFF). В частности, настоящее раскрытие описывает различные методы для сохранения потоков видео, содержащих множество кодированных уровней, причем каждый уровень может быть масштабируемым уровнем, видом текстуры, видом глубины или другими типами уровней или видов. Методы настоящего раскрытия могут быть применены, например, к хранению видеоданных MV-HEVC, видеоданных SHVC, видеоданных 3D-HEVC и/или других типов видеоданных.
[0090] Форматы файлов и стандарты форматов файлов будут кратко описаны ниже. Стандарты форматов файлов включают в себя базовый формат медиа файла ISO (ISOBMFF, ISO/IEC 14496-12, далее ʺISO/IEC 14996-12ʺ) и другие стандарты форматов файлов, полученные из ISOBMFF, включая формат файла MPEG-4 (ISO/IEC 14496-14), формат файла 3GPP (3GPP TS 26.244) и формат файла AVC (ISO/IEC 14496-15, далее ʺISO/IEC 14996-15ʺ). Таким образом, ISO/IEC 14496-12 определяет базовый формат медиа файла ISO. Другие документы расширяют базовый формат медиа файла ISO для конкретных приложений. Например, ISO/IEC 14496-15 описывает перенос структурированного видео NAL-единицы в базовом формате медиа файла ISO. H.264/AVC и HEVC, а также их расширения, являются примерами структурированного видео NAL-единицы. ISO/IEC 14496-15 включает в себя секции, описывающие перенос NAL-единиц H.264/AVC. Дополнительно, секция 8 ISO/IEC 14496-15 описывает перенос NAL-единиц HEVC.
[0091] ISOBMFF используется в качестве базы для многих форматов инкапсуляции кодека, таких как формат файла AVC, а также для многих форматов мультимедийных контейнеров, таких как формат файла MPEG-4, формат файла 3GPP (3GP) и формат файла DVB. В дополнение к непрерывным медиа, таким как аудио и видео, статические медиа, такие как изображения, а также метаданные, могут быть сохранены в файле, соответствующем ISOBMFF. Файлы, структурированные в соответствии с ISOBMFF, могут быть использованы для многих целей, включая локальное воспроизведение медиа файла, прогрессивную загрузку удаленного файла, сегментов для динамической потоковой передачи по HTTP (DASH), контейнеров для контента для потоковой передачи и его инструкций пакетирования, и запись принятых медиа потоков реального времени. Таким образом, хотя ISOBMFF первоначально предназначался для хранения, он оказался полезным для потоковой передачи, например, для прогрессивной загрузки или DASH. Для целей потоковой передачи, фрагменты фильмов, определенные в ISOBMFF, могут быть использованы.
[0092] Файл, соответствующий формату файла HEVC, может содержать последовательность объектов, называемых боксами. Бокс может быть объектно-ориентированным компоновочным блоком, определенным идентификатором уникального типа и длиной. Например, бокс может быть элементарной синтаксической структурой в ISOBMFF, включающей в себя четырех-символьный кодированный тип бокса, байтовый отсчет бокса и полезную нагрузку. Иными словами, бокс может быть синтаксической структурой, содержащей кодированный тип бокса, байтовый отсчет бокса и полезную нагрузку. В некоторых случаях, все данные в файле, соответствующем формату файла HEVC, могут содержаться в боксах, и может не иметься никаких данных в файле, которые не находятся в боксе. Таким образом, файл ISOBMFF может состоять из последовательности боксов, и боксы могут содержать другие боксы. Например, полезная нагрузка бокса может включать в себя один или более дополнительных боксов. Фиг. 5 и фиг. 6, описанные детально в настоящем раскрытии, показывают примеры боксов в файле, в соответствии с одним или более методами настоящего раскрытия.
[0093] Файл, соответствующий ISOBMFF, может включать в себя различные типы боксов. Например, файл, соответствующий ISOBMFF, может включать в себя бокс типа файла, бокс медиа данных, бокс фильма, бокс фрагмента фильма и т.д. В этом примере, бокс типа файла включает в себя тип файла и информацию совместимости. Бокс медиа данных может содержать выборки (например, кодированные картинки). Бокс фильма (ʺmoovʺ) содержит метаданные для непрерывных медиа потоков, присутствующих в файле. Каждый из непрерывных медиа потоков может быть представлен в файле как трек (дорожка). Например, бокс фильма может содержать метаданные относительно фильма (например, логические и временные соотношения между выборками, а также указатели на местоположения выборок). Боксы фильма могут включать в себя различные типы под-боксов. Под-боксы в боксе фильма могут включать в себя один или более боксов треков. Бокс трека может включать в себя информацию об индивидуальном треке фильма. Бокс трека может включать в себя бокс заголовка трека, который определяет общую информацию одного трека. Кроме того, бокс трека может включать в себя бокс медиа, который содержит бокс медиа информации. Бокс медиа информации может включать в себя бокс таблицы выборок, который содержит данные, индексирующие медиа выборки в треке. Информация в боксе таблицы выборок может быть использована для локализации выборок во времени и, для каждой из выборок трека, типа, размера, контейнера и смещения в этот контейнер выборки. Таким образом, метаданные для трека вложены в бокс трека (ʺtrakʺ), в то время как медиа контент трека вложен в бокс медиа данных (ʺmdatʺ) или непосредственно в отдельный файл. Медиа контент для треков содержит (например, состоит из) последовательность(и) выборок, таких как аудио или видео единицы доступа.
[0094] ISOBMFF определяет следующие типы треков: медиа трек, который содержит элементарный медиа поток, хинт трек, который либо включает в себя инструкции по передаче медиа, либо представляет принятый пакетный поток, и трек временных метаданных, который содержит синхронизированные во времени метаданные. Метаданные для каждого трека включают в себя список элементов описания выборок, причем каждый обеспечивает формат кодирования или инкапсуляции, используемый в треке, и данные инициализации, необходимые для обработки этого формата. Каждая выборка ассоциирована с одним из элементов описания выборки трека.
[0095] ISOBMFF позволяет определять специфические для выборки метаданные с различными механизмами. Конкретные боксы в боксе таблицы выборок (ʺstblʺ) были стандартизованы с учетом общих потребностей. Например, бокс синхро-выборки (ʺstssʺ) является боксом в боксе таблицы выборок. Бокс синхро-выборки используется для перечисления выборок произвольного доступа трека. Настоящее раскрытие может ссылаться на выборку, перечисленную в боксе синхро-выборки, как на синхро-выборку. В другом примере, механизм группирования выборок позволяет отображать выборки соответствии с четырех-символьным типом группирования на группы выборок, совместно использующих то же самое свойство, специфицированное как элемент описания группы выборок в файле. Различные типы группирования были специфицированы в ISOBMFF.
[0096] Бокс таблицы выборок может включать в себя один или более боксов SampleToGroup и один или более боксов описания группы выборок (т.е., боксов SampleGroupDescription). Бокс SampleToGroup может быть использован, чтобы определять группу выборок, к которой принадлежит данная выборка, вместе с ассоциированным описанием группы выборок. Иными словами, бокс SampleToGroup может указывать группу, к которой принадлежит выборка. Бокс SampleToGroup может иметь тип бокса ʺsbgp.ʺ Бокс SampleToGroup может включать в себя элемент типа группирования (например, grouping_type). Элемент типа группирования может быть целым числом, которое идентифицирует тип (т.е., критерий, используемый для формирования групп выборок) группирования выборок. Кроме того, бокс SampleToGroup может включать в себя одну или более записей. Каждая запись в боксе SampleToGroup может быть ассоциирована с различной, неперекрывающейся последовательностью последовательных выборок в треке. Каждая запись может указывать элемент счета выборки (например, sample_count) и элемент индекса описания группы (например, group_description_index). Элемент счета выборки записи может указывать число выборок, ассоциированных с записью. Иными словами, элемент счета выборок записи может быть целым числом, которое дает число последовательных выборок с тем же самым дескриптором группы выборок. Элемент индекса описания группы может идентифицировать бокс SampleGroupDescription, который содержит описание выборок, ассоциированных с записью. Элементы индекса описания группы множества записей могут идентифицировать тот же самый бокс SampleGroupDescription.
[0097] Современные структуры формата файла могут иметь одну или более проблем. Для сохранения видео контента конкретного видео кодека, основанного на ISOBMFF, может быть необходимой спецификация формата файла для данного видео кодека. Для сохранения потоков видео, содержащих множество уровней, таких как MV-HEVC и SHVC, можно повторно использовать некоторые из идей форматов файла SVC и MVC. Однако многие части не могут быть непосредственно использованы для SHVC и MV-HEVC потоков видео. Прямое применение формата файла HEVC имеет по меньшей мере следующие недостатки: битовые потоки SHVC и MV-HEVC могут начинаться с единицы доступа, которая содержит IRAP-картинку на базовом уровне, но может также содержать другие не-IRAP-картинки в других уровнях, или наоборот. Синхро-выборка в настоящее время не обеспечивает возможность указания такой точки для произвольного доступа.
[0098] Настоящее раскрытие описывает возможные решения вышеуказанных проблем, а также обеспечивает другие потенциальные усовершенствования, чтобы обеспечить возможность эффективного и гибкого сохранения потоков видео, содержащих множество уровней. Методы, описанные в настоящем раскрытии, потенциально применимы к любому формату файла для сохранения такого видео контента, кодированного любым видео кодеком, хотя описание конкретизировано для хранения потоков видео SHVC и MV-HEVC на основе формата файла HEVC, который специфицирован в статье 8 ISO/IEC 14496-15.
[0099] Детальная реализация методов настоящего раскрытия будет описана ниже. Методы настоящего раскрытия могут быть кратко описаны в следующих примерах. Следующие примеры могут быть использованы отдельно. Альтернативно, различные комбинации следующих примеров могут быть использованы вместе.
[0100] В первом примере, Compressorname является значением, специфицированным в боксе VisualSampleEntry. Как описано в разделе 8.5.2.1 ISO/IEC 14496-12, бокс VisualSampleEntry является типом бокса таблицы выборок для видео треков, который хранит детальную информацию об используемом типе кодирования и любую информацию инициализации, необходимую для этого кодирования. Compressorname указывает имя компрессора, используемого для генерации медиа данных. Видео декодер может использовать значение Compressorname, чтобы определять, каким образом и/или следует ли декодировать видеоданные в файле. Как определено в разделе 8.5.3 ISO/IEC 14496-12, Compressorname сформатировано как фиксированное 32-байтовое поле, с первым байтом, установленным на число байтов, подлежащих отображению, за которым следует это число байтов отображаемых данных, и затем заполнение для получения в целом 32 байтов (включая байт размера).
[0101] Первый пример допускает два новых значения Compressorname. Первым новым значением Compressorname является ʺ\013SHVC Codingʺ для файла, содержащего потоки видео SHVC. Вторым новым значением Compressorname является ʺ\016MV-HEVC Codingʺ для файла, содержащего потоки видео MV-HEVC. Этот первый пример может быть реализован, как показано в разделах 9.5.3.1.3 и 10.5.3.2 ниже.
[0102] Как кратко описано выше, файл может включать в себя бокс фильма, который содержит метаданные для треков файла. Бокс фильма может включать в себя бокс трека для каждого трека файла. Кроме того, бокс трека может включать в себя бокс медиа информации, который содержит все объекты, которые описывают характеристическую информацию о медиа трека. Бокс медиа информации может включать в себя бокс таблицы выборок. Бокс таблицы выборок может специфицировать специфические для выборки метаданные. Например, бокс таблицы выборок может включать в себя множество боксов описания выборки. Каждый из боксов описания выборки может быть экземпляром записи выборки. В ISO/IEC 14496-12, экземпляры класса VisualSampleEntry могут быть использованы как записи выборок. Классы записей выборок, специфических для конкретных стандартов видео кодирования, могут расширять класс VisualSampleEntry. Например, класс записей выборок, специфических для HEVC, может расширять класс VisualSampleEntry. Таким образом, настоящее раскрытие может ссылаться на различные классы, расширяющие класс VisualSampleEntry, как различные типы записи выборки.
[0103] Во втором примере, два новых типа записи выборки (т.е., ʺsampleʺ), ʺhev2ʺ и ʺhvc2ʺ, определены для треков HEVC. Эти два новых типа записи выборки обеспечивают возможность использования агрегаторов и экстракторов. В принципе, агрегатор агрегирует множество NAL-единиц в форме одной агрегированной единицы данных. Например, агрегатор может содержать множество NAL-единиц и/или может виртуально конкатенировать множество NAL-единиц. В принципе, экстрактор указывает тип данных, полученных из других треков. Например, хранение медиа данных (например, данных HEVC) по множеству треков может привести в результате к компактным файлам, поскольку можно избежать дублирования данных путем ссылок на данные по медиа трекам с использованием относительно малых единиц данных, называемых экстракторами, которые встроены как NAL-единица в медиа данные. Данный второй пример может быть реализован, как показано в разделах 9.5.3.1.1, 9.5.3.1.2, 9.5.4, 9.5.6, 10.4.5, 10.5.3.1.1.1 и 10.5.3.2 ниже.
[0104] В третьем примере, определение записи выборки, которая ассоциирована с конкретным требованием к хранению наборов параметров для многоуровневого битового потока, модифицировано, чтобы обеспечить возможность удобного произвольного доступа к конкретному уровню или конкретной рабочей точке. Например, когда трек SHVC, MV-HEVC или 3D-HEVC имеет запись выборки и когда выборка содержит по меньшей мере oдну IRAP-картинку, все параметры, необходимые для декодирования этой выборки, должны быть включены в запись выборки или в собственно эту выборку. В этом примере, когда выборка не содержит никакой IRAP-картинки, все наборы параметров (например, VPS, SPS, PPS), необходимые для декодирования данной выборки, должны быть включены либо в запись выборки, либо в любую из выборок, начиная с предыдущей выборки, содержащей по меньшей мере одну IRAP- картинку, до собственно той выборки, включительно. Этот третий пример может быть реализован, как показано в разделе 9.5.3.1.1 ниже.
[0105] В одной альтернативной версии третьего примера, когда SHVC, MV-HEVC или 3D-HEVC трек имеет запись выборки и когда картинкой в выборке является IRAP картинка, все наборы параметров, необходимые для декодирования этой картинки, должны быть включены запись выборки или в собственно эту выборку. Кроме того, в этой альтернативе, когда выборка не содержит IRAP картинки, все наборы параметров, необходимые для декодирования картинки, должны быть включены либо в запись выборки, либо в любую из выборок, следующих за предыдущей выборкой, содержащей по меньшей мере IRAP-картинку на том же уровне, до собственно той выборки, включительно.
[0106] В четвертом примере, определены следующие случаи для существующих типов записи выборки. В этом примере, выборки, принадлежащие к типам ʺhev1ʺ и ʺhvc1ʺ записи выборки, содержат конфигурации HEVC, SHVC и MV-HEVC для треков SHVC и MV-HEVC с VCL NAL-единицами HEVC. Кроме того, типы ʺhev1ʺ и ʺhvc1ʺ записи выборки, содержащие конфигурации SHVC и MV-HEVC, определены для треков SHVC и MV-HEVC без NAL-единиц HEVC, но с VCL NAL-единицами с nuh_layer_id большим, чем 0, где экстракторы не разрешены. Этот четвертый пример может быть реализован, как показано в разделе 9.5.3.1.1 ниже.
[0107] В пятом примере, синхро-выборка в треке SHVC, MV-HEVC или 3D-HEVC определена как выборка, которая содержит картинки, которые все являются IRAP-картинками. Этот пятый пример может быть реализован, как показано в разделах 9.5.5 и 10.4.3 ниже. Как специфицировано в разделе 9.5.5 ниже, выборка SHVC рассматривается как синхро-выборка, если каждая кодированная картинка в единице доступа является IRAP-картинкой, как определено в HEVC WD. Кроме того, как специфицировано в разделе 10.4.3 ниже, выборка MV-HEVC рассматривается как синхро-выборка, если каждая кодированная картинка в единице доступа является IRAP-картинкой без RASL-картинки, как определено в HEVC WD.
[0108] Таким образом, в пятом примере, в качестве части генерации файла, устройство 34 генерации файла может генерировать бокс синхро-выборки, который включает в себя таблицу синхро-выборок, которая документирует синхро-выборки трека многоуровневых видеоданных. Каждая синхро-выборка трека является выборкой произвольного доступа трека. Выборка масштабируемого видео кодирования является синхро-выборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой. Выборка многовидового видео кодирования является синхро-выборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой без RASL-картинок.
[0109] В альтернативной версии пятого примера, синхро-выборка в треке SHVC, MV-HEVC или 3D-HEVC определяется как выборка, которая содержит картинки, которые все являются IRAP- картинки без RASL-картинок. Таблица синхро-выборок документирует синхро-выборки. Опционально, группа синхро-выборок документирует синхро-выборки. Иными словами, группа синхро-выборок включает в себя информацию, идентифицирующую синхро-выборки.
[0110] В шестом примере, определена группа выборок ʺrapʺ, содержащая те выборки, которые содержат картинки, которые все являются IRAP-картинками (с RASL-картинками или без них). Этот шестой пример может быть реализован, как показано в разделе 9.5.5 ниже. Альтернативно, в шестом примере, определена группа выборок ʺrapʺ, содержащая те выборки, которые содержат картинки, которые все являются IRAP-картинками, но исключают те выборки, которые указаны как синхро-выборки.
[0111] В седьмом примере, определена новая группа выборок или новый бокс, которые документируют все выборки, содержащие по меньшей мере одну IRAP-картинку, тип NAL-единицы VCL NAL-единиц в IRAP-картинках в выборке, если все кодированные картинки в выборке являются IRAP-картинками, а если нет, число IRAP-картинок в выборке, и значения ID уровня этих IRAP-картинок в выборке.
[0112] Таким образом, в этом седьмом примере, устройство 34 генерации файла может генерировать файл, который содержит бокс трека, который содержит метаданные для трека в файле. Медиа данные для трека содержат последовательность выборок. Каждая из выборок может быть единицей доступа многоуровневых видеоданных. В качестве части генерации файла, устройство 34 генерации файла генерирует, в файле, дополнительный бокс, который документирует все из выборок, содержащих по меньшей мере одну IRAP-картинку.
[0113] Этот седьмой пример может быть реализован частично, как показано в разделе 9.5.5.1 ниже. Как показано в разделе 9.5.5.1 ниже, класс записи выборки произвольного доступа расширяет класс VisualSampleGroupEntry. Экземпляры класса записи выборки произвольного доступа (т.е., боксы записи выборки произвольного доступа) соответствуют выборкам, содержащим по меньшей мере одну IRAP-картинку. Кроме того, бокс записи выборки произвольного доступа включает в себя значение all_pics_are_IRAP, которое специфицирует, являются ли все кодированные картинки в соответствующей выборке IRAP-картинками.
[0114] Таким образом, в седьмом примере, устройство 34 генерации файла может генерировать запись выборки, которая включает в себя значение (например, all_pics_are_IRAP). Значение равное 1, специфицирует, что каждая кодированная картинка в выборке является IRAP-картинкой. Значение, равное 0, специфицирует, что не все кодированные картинки в выборке являются IRAP-картинками.
[0115] Кроме того, в соответствии с седьмым примером, когда не все кодированные картинки выборки являются IRAP-картинками, устройство 34 генерации файла может включать, в записи выборки, соответствующей выборке, значение, указывающее число IRAP-картинок в каждой выборке группы выборок. Дополнительно, когда не все кодированные картинки в выборке являются IRAP-картинками, устройство 34 генерации файла может включать, в записи выборки, соответствующей выборке, значения, указывающие идентификаторы уровня IRAP-картинок в выборке.
[0116] Альтернативно, в седьмом примере, новая группа выборок или новый бокс документируют такие выборки, но исключая те, которые указаны как синхро-выборки или члены группы выборок ʺrapʺ.
[0117] Этот седьмой пример может разрешить одну или более проблем, которые могут возникать, когда многоуровневые видеоданные сохранены с использованием ISOBMFF или существующих его расширений. Например, в одноуровневом видео кодировании, обычно имеется только одна кодированная картинка на каждую единицу доступа. Однако в многоуровневом видео кодировании обычно имеется более чем одна кодированная картинка на каждую единицу доступа. ISOBMFF и его существующие расширения не обеспечивают способа указания, какие выборки включают в себя одну или более IRAP-картинок. Это может препятствовать способности вычислительного устройства локализовать точки произвольного доступа в файле или выполнять переключение уровня. Например, в отсутствие информации, указывающей, какие из выборок содержат одну или более IRAP-картинок, вычислительному устройству может потребоваться синтаксически анализировать и интерпретировать NAL-единицы, чтобы определять, может ли единица доступа использоваться как точка произвольного доступа и/или для переключения уровня. Синтаксический анализ и интерпретация NAL-единиц может добавлять сложность к вычислительному устройству и может потреблять время и ресурсы обработки. Кроме того, некоторые вычислительные устройства, которые выполняют произвольный доступ и/или переключение уровня, такие как серверы потоковой передачи, не сконфигурированы, чтобы синтаксически анализировать или интерпретировать NAL-единицы.
[0118] В восьмом примере, вводится новый тип подвыборки, причем каждая подвыборка содержит одну кодированную картинку и ее ассоциированные не-VCL NAL-единицы. Этот восьмой пример может быть реализован, как показано в разделе 9.5.8 ниже. Таким образом, в этом восьмом примере, устройство 34 генерации файла может генерировать файл, который содержит бокс трека, который содержит метаданные для трека в файле. Медиа данные для трека содержат последовательность выборок. Каждая из выборок является единицей доступа многоуровневых видеоданных. В качестве части генерации файла, устройство 34 генерации файла генерирует, в файле, бокс информации подвыборки, которые содержат флаги, которые специфицируют тип информации подвыборки, приведенной в боксе информации подвыборки. Когда флаги имеют конкретное значение, подвыборка, соответствующая боксу информации подвыборки, содержит точно одну кодированную картинку и нуль или более не-VCL NAL-единиц, ассоциированных с кодированной картинкой.
[0119] Этот восьмой пример может разрешить одну или более проблем, которые могут возникнуть, когда многоуровневые видеоданные сохранены с использованием ISOBMFF или его существующих расширений. Например, в многоуровневом видео кодировании, может иметься множество кодированных картинок на каждую выборку. Например, может иметься одна или более картинок в выборке для каждого уровня. Однако в расширении ISOBMFF для H.264/AVC и HEVC, бокс информации подвыборки не обеспечивает информацию об индивидуальных картинках в пределах выборки, когда выборка включает в себя множество картинок. Методы этого восьмого примера могут разрешить эту проблему путем обеспечения нового типа бокса информации подвыборки, который обеспечивает информацию о подвыборке, которая содержит только одну кодированную картинку и не-VCL NAL-единицы, ассоциированные с кодированной картинкой. Обеспечение информацию об индивидуальной кодированной картинке в структуре файла, в противоположность только обеспечению такой информации в NAL-единицах, ассоциированных с кодированной картинкой, может обеспечить возможность вычислительному устройству определять информацию о кодированной картинке, не требуя интерпретации NAL-единиц. В некоторых случаях, чтобы снизить сложность вычислительного устройства и/или увеличить пропускную способность вычислительного устройства, вычислительное устройство не конфигурируется, чтобы интерпретировать NAL-единицы. В некоторых примерах, где вычислительное устройство выполняет потоковую передачу NAL-единиц, сохраненных в файле, вычислительное устройство может использовать информацию в боксе информации подвыборки, чтобы определять, следует ли пересылать NAL-единицы подвыборки на клиентское устройство.
[0120] Девятый пример относится к обработке не выводимых выборок в многоуровневом контексте. В частности, в девятом примере, когда единица доступа содержит некоторые кодированные картинки, которые имеют pic_output_flag, равный 1, и некоторые другие кодированные картинки, которые имеют pic_output_flag, равный 0, по меньшей мере два трека должны использоваться для сохранения потока, так что в пределах каждого трека все кодированные картинки в каждой выборке имеют то же самое значение pic_output_flag. Этот девятый пример может быть реализован, как показано в разделе 9.5.9 ниже.
[0121] Таким образом, в этом девятом примере, устройство 34 генерации файла может генерировать файл, который содержит бокс медиа данных, который вмещает медиа контент. Медиа контент содержит последовательность выборок. Каждая из выборок является единицей доступа многоуровневых видеоданных. В ответ на определение, что по меньшей мере одна единица доступа битового потока многоуровневых видеоданных включает в себя кодированную картинку, которая имеет флаг вывода картинки (например, pic_output_flag), равный 1, и кодированную картинку, которая имеет флаг вывода картинки, равный 0, устройство 34 генерации файла может использовать по меньшей мере два трека, чтобы хранить битовый поток в файле. Для каждого соответствующего трека из по меньшей мере двух треков, все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки.
[0122] Этот девятый пример может разрешить одну или более проблем, которые могут возникнуть, когда многоуровневые видеоданные сохранены с использованием ISOBMFF или его существующих расширений. Например, если бы один трек использовался для хранения кодированных картинок, которые имели флаги вывода картинки, равные 0, и флаги вывода картинок, равные 1, то были бы нарушены различные правила форматирования файла. Например, правила форматирования файла обычно требуют, чтобы имелась только одна выборка в треке в каждый момент времени. Если один трек хранил кодированные картинки, которые имели флаги вывода картинок, равные 0, и флаги вывода картинок, равные 1, то имелось бы несколько выборок в треке в каждый момент времени. Вынуждение кодированных картинок, которые имеют различные значения флага вывода картинки, находиться в различных треках файла может разрешить эту проблему.
[0123] Примерная реализация некоторых методов настоящего раскрытия описана ниже. Примерная реализация, описанная ниже, основана на последней интегрированной спецификации 14496-15 в выходном документе W13478 MPEG. Ниже включены изменения к Приложению A (показаны с подчеркиванием) и добавленные разделы (Раздел 9 для SHVC и раздел 10 для MV-HEVC). Иными словами, конкретные примеры настоящего раскрытия могут модифицировать Приложение A к ISO/IEC 14496-15 и могут добавить разделы 9 и/или 10 к ISO/IEC 14496-15. Текст, показанный с подчеркиванием и двойным подчеркиванием, может иметь особую релевантность для примеров настоящего раскрытия. Хотя термин SHVC используется в различных местах в примерах, описываемых здесь, структура согласно настоящему раскрытию в действительности поддерживает не только кодек SHVC, но, напротив, может поддерживаться любой многоуровневый кодек, включая MV-HEVC, 3D-HEVC, если только явно не указано иное.
9 Определения элементарных потоков и выборок SHVC
9.1 Введение
Эта статья специфицирует форма хранения данных SHVC. Она расширяет определения формата хранения HEVC в статье 8.
Формат файла для хранения контента SHVC, как определено в этой статье и приложениях A-D, использует существующие возможности базового формата медиа файла ISO и простого формата файла HEVC (т.е. формата файла, специфицированного в статье 8). Кроме того, использованы следующие структуры или расширения, среди прочего, для поддержки SHVC-специфических функций.
Агрегатор:
Структура для обеспечения возможности эффективного масштабируемого группирования NAL-единиц путем замены нерегулярных шаблонов (паттернов) NAL-единиц на регулярные шаблоны агрегированных единиц данных.
Экстрактор:
Структура для обеспечения возможности эффективного извлечения NAL-единиц из других треков, чем тот, который содержит медиа данные.
Операторы временных метаданных:
Структуры для хранения выровненной по времени информации медиа выборок.
HEVC-совместимость:
Предоставление возможности хранения битового потока SHVC совместимым с HEVC способом, так что HEVC-совместимый базовый уровень может быть использован любым считывателем, совместимым с простым форматом файла HEVC.
9.2 Структура элементарного потока
Потоки SHVC сохранены в соответствии с 8.2, со следующим определением элементарного потока видео SHVC:
- Элементарные потоки видео SHVC должны содержать все относящиеся к видео кодированию NAL-единицы (т.е. те NAL-единицы, которые содержат видеоданные или сигнализируют структуру видео) и могут содержать не относящиеся к видео кодированию NAL-единицы, такие как SEI-сообщения и NAL-единицы ограничителя единицы доступа. Также могут присутствовать агрегаторы (см. A.2) или экстракторы (см. A.3). Агрегаторы и экстракторы должны обрабатываться, как определено в этом Международном стандарте (например, не должны непосредственно помещаться в выходной буфер при доступе к файлу). Другие NAL-единицы, которые явно не запрещены, могут присутствовать, и если они являются нераспознаваемыми, они должны игнорироваться (например, не помещаться в выходной буфер при доступе к файлу).
Потоки SHVC не должны сохраняться с использованием ассоциированных потоков наборов параметров. Могут иметься VCL NAL-единицы с nuh_layer_id, равным 0, VCL NAL-единицы с nuh_layer_id, большим, чем 0, и не-VCL NAL-единицы в элементарном потоке видео SHVC. Дополнительно, могут иметься NAL-единицы агрегатора и NAL-единицы экстрактора в элементарном потоке видео SHVC.
9.3 Использование простого формата файла HEVC
Формат файла SHVC является расширением простого формата файла HEVC, определенного в статье 8.
9.4 Определения выборки и конфигурации
9.4.1 Введение
Выборка SHVC: выборка SHVC является также единицей доступа, как определено в Приложении H к ISO/IEC 23008-2.
9.4.2 Канонический порядок и ограничения
9.4.2.1 Ограничения
Следующие ограничения применяются к данным SHVC в дополнение к требованиям в 8.3.2.
- VCL NAL-единицы: Все VCL NAL-единицы в одной единице доступа должны содержаться в выборке, время композиции которой является таковым для картинки, представленной единицей доступа. Выборка SHVC должна содержать по меньшей мере одну VCL NAL-единицу.
- Агрегаторы/Экстракторы: Порядок всех NAL-единиц, включенных в агрегатор или отсылаемых экстрактором, является точно порядком декодирования, как если бы эти NAL-единицы присутствовали в выборке, не содержащей агрегаторы/экстракторы. После обработки агрегатором или экстрактором, все NAL-единицы должны находиться в действительном порядке декодирования, как специфицировано в ISO/IEC 23008-2.
9.4.2.2 Запись конфигурации декодера
Если запись конфигурации декодера, определенная в 8.3.3.1, используется для потока, который может быть интерпретирован как поток SHVC или HEVC, запись конфигурации декодера HEVC должна отражать свойства HEVC-совместимого базового уровня, например, она должна содержать только наборы параметров, требуемые для декодирования базового уровня HEVC.
SHVCDecoderConfigurationRecord является структурно идентичной HEVCDecoderConfigurationRecord. Синтаксис является следующим:
aligned(8) class SHVCDecoderConfigurationRecord {
// те же поля, что и в структуре синтаксиса HEVCDecoderConfigurationRecord
}
Семантика полей в SHVCDecoderConfigurationRecord является той же самой, как определено для HEVCDecoderConfigurationRecord.
9.5 Вывод из базового формата медиа файла ISO
9.5.1 Структура трека SHVC
Масштабируемый видео поток представлен одним или более видео треками в файле. Каждый трек представляет одну или более рабочих точек масштабируемого потока. Масштабируемый поток может, разумеется, быть дополнительно прорежен, если желательно.
Пусть самая низкая рабочая точка является одной из всех рабочих точек, которая содержит NAL-единицы с nuh_layer_id, равным только 0, и TemporalId, равным только 0. Трек, который содержит самую низкую рабочую точку, должен быть определен как ʹмасштабируемый базовый трекʹ. Все другие треки, которые являются частью той же самой масштабируемой кодированной информации, должны быть связаны с этим базовым треком посредством ссылки трека типа ʹsbasʹ (масштабируемая база).
Все треки, совместно использующие тот же самый масштабируемый базовый трек, должны совместно использовать ту же самую временную шкалу, что и масштабируемый базовый трек.
9.5.2 Совместное использование и извлечение данных
Различные треки могут логически совместно использовать данные. Это совместное использование может принимать одну из следующих двух форм:
a) Данные выборки копируются из одного трека в другой трек (и, возможно, компонуются и повторно перемежаются с другими данными, такими как аудио). Это создает более крупные общие файлы, но данные с низкой битовой скоростью могут компоноваться и/или перемежаться с другим материалом, для простоты извлечения.
b) Могут иметься инструкции, как выполнять это копирование, в момент, когда файл считывается.
Для второго случая, используются экстракторы (определенные в A.3).
9.5.3 Определение видео потока SHVC
9.5.3.1 Имя и формат записи выборки
9.5.3.1.1 Определение
Типы: ʹhvc2ʹ, 'hev2', ʹshc1ʹ,ʹshv1',ʹ shcCʹ
Контейнер: Бокс описания выборки (ʹstsdʹ)
Обязательно: Запись выборки 'hvc1', 'hev1', 'hvc2', 'hev2', 'shc1' или 'shv1' является обязательной.
Количество: Одна или более записей выборок может присутствовать.
Если именем записи выборки является ʹshc1ʹ, установленным по умолчанию и обязательным значением array_completeness является 1 для массивов всех типов наборов параметров и 0 для всех других массивов. Если именем записи выборки является ʹshv1ʹ, значением по умолчанию array_completeness является 0 для всех массивов.
Когда именем записи выборки является 'shv1', применимо следующее:
- Если выборка содержит по меньшей мере одну IRAP-картинку, как определено в ISO/IEC 23008-2, все наборы параметров, необходимые для декодирования данной выборки, должны быть включены запись выборки или в собственно выборку.
- В противном случае (выборка не содержит IRAP-картинок), все наборы параметров, необходимые для декодирования данной выборки, должны быть включены в запись выборки или в любую из выборок, начиная с предыдущей выборки, содержащей по меньшей мере одну IRAP-картинку, до собственно той выборки, включительно.
Альтернативно, если именем записи выборки является 'shv1', то применимо следующее:
- Если кодированная картинка в выборке является IRAP- картинкой, как определено в ISO/IEC 23008-2, все наборы параметров, необходимые для декодирования данной кодированной картинки, должны быть включены в запись выборки или в собственно эту выборку.
- В противном случае (кодированная картинка в выборке не является IRAP-картинкой), все наборы параметров, необходимые для декодирования данной кодированной картинки, должны быть включены в запись выборки или в любую из выборок, начиная с предыдущей выборки, содержащей IRAP-картинку на том же уровне, что и кодированная картинка, до собственно данной выборки, включительно.
Если элементарный поток SHVC содержит используемый HEVC-совместимый базовый уровень, то должна использоваться запись визуальной выборки HEVC (ʹhvc1ʹ или ʹhev1ʹ). Здесь запись должна содержать первоначально бокс конфигурации HEVC, возможно, с последующим боксом конфигурации SHVC, как определено ниже. Бокс конфигурации HEVC документирует профиль, слой, уровень и, возможно, также наборы параметров, касающиеся HEVC-совместимого базового уровня, как определено посредством HEVCDecoderConfigurationRecord. Бокс конфигурации SHVC документирует профиль, слой, уровень и, возможно, также наборы параметров, касающиеся всего потока, содержащего SHVC-совместимые уровни расширения, как определено посредством HEVCDecoderConfigurationRecord, сохраненного в SHVCConfigurationBox.
Если элементарный поток SHVC не содержит используемого базового уровня HEVC, то должна использоваться запись визуальной выборки SHVC (ʹshc1ʹ или 'shv1'). Запись визуальной выборки SHVC должна содержать бокс конфигурации SHVC, как определено ниже. Это включает в себя SHVCDecoderConfigurationRecord, как определено в данном Международном стандарте.
Поле lengthSizeMinusOne в конфигурациях SHVC и HEVC в любой данной записи выборки должно иметь то же самое значение.
Экстракторы или агрегаторы могут быть использованы для NAL-единиц с nuh_layer_id большим, чем 0, в треках 'hvc1', 'hev1', 'hvc2', 'hev2', 'shc1' или 'shv1'. ʹextra_boxesʹ в записи выборки 'hvc2' или 'hev2' могут быть SHVCConfigurationBox или другими боксами расширения.
Примечание. Если HEVC-совместимость указана, может быть необходимым указывать нереалистичный уровень для базового уровня HEVC, с учетом битовой скорости всего потока, поскольку все NAL-единицы рассматриваются как включенные в базовый уровень HEVC и, таким образом, могут быть введены в декодер, который может отбросить те NAL-единицы, которые он не распознает. Этот случай имеет место, когда используется запись выборки 'hvc1' или 'hev1', и присутствуют конфигурации как HEVC, так и SHVC.
SHVCConfigurationBox может присутствовать в записи выборки 'hvc1' или 'hev1'. В этом случае применяется приведенное ниже определение HEVCSHVCSampleEntry.
Последующая таблица показывает для видео трека все возможные использования записей выборок, конфигураций и инструментов SHVC (исключая временные метаданные, которые всегда используются в другом треке):
| Таблица 10 Использование записей выборок для треков HEVC и SHVC |
||
| Имя записи выборки | с записями конфигурации | Значение |
| 'hvc1' или 'hev1' | Только конфигурация HEVC | Простой трек HEVC без NAL- единиц с nuh_layer_id больше, чем 0; экстракторы и агрегаторы не должны присутствовать. |
| 'hvc1' или 'hev1' | Конфигурации HEVC и SHVC | Трек SHVC с NAL-единицами с nuh_layer_id, равным 0, и NAL-единицами с nuh_layer_id больше, чем 0; экстракторы и агрегаторы могут присутствовать; экстракторы не должны ссылаться на NAL-единицы с nuh_layer_id больше, чем 0; агрегаторы не должны содержать, но могут ссылаться на NAL-единицы с nuh_layer_id, равным 0. |
| 'hvc2' или 'hev2' | Только конфигурация HEVC | Простой трек HEVC без NAL- единиц с nuh_layer_id больше, чем 0; экстракторы могут присутствовать и использоваться для ссылки на NAL-единицы; агрегаторы могут присутствовать, чтобы содержать и ссылаться на NAL-единицы. |
| 'hvc2' или 'hev2' | Конфигурации HEVC и SHVC | Трек SHVC с NAL-единицами с nuh_layer_id, равным 0, и NAL-единицами с nuh_layer_id больше, чем 0; экстракторы и агрегаторы могут присутствовать; экстракторы могут ссылаться на любые NAL-единицы; агрегаторы могут содержать и ссылаться на любые NAL-единицы. |
| ʹshc1ʹ или 'shv1' | Конфигурация SHVC | Трек SHVC без NAL-единиц с nuh_layer_id, равным 0; экстракторы могут присутствовать и используются для ссылки на NAL-единицы; агрегаторы могут присутствовать и содержать и ссылаться на любые NAL-единицы. |
9.5.3.1.2 Синтаксис
9.5.3.1.3 Семантика
Когда поток, к которому применяется запись выборки, содержит NAL-единицы с nuh_layer_id больше, чем 0, Compressorname в базовом классе VisualSampleEntry указывает имя компрессора, используемого с рекомендуемым значением "\013SHVC Coding" (\013 равно 11, длина строки ʺSHVC Codingʺ в байтах).
9.5.4 Визуальная ширина и высота SHVC
Визуальная ширина и высота, документированные в VisualSampleEntry потока, содержащего NAL-единицы с nuh_layer_id больше, чем 0, являются визуальной шириной и высотой базового уровня HEVC, если поток описывается записью выборки типа ʹhvc1ʹ, ʹhev1ʹ, ʹhvc2ʹ, ʹhev2ʹ; в противном случае они являются визуальной шириной и высотой декодируемых картинок наивысшего уровня при декодировании всего потока.
9.5.5 Синхро-выборка
Выборка SHVC рассматривается в качестве синхро-выборки, если каждая кодированная картинка в единице доступа является IRAP-картинкой, как определено в ISO/IEC 23008-2. Синхро-выборки документированы таблицей синхро-выборок и могут быть дополнительно документированы группой выборок синхро-выборок и группой выборок 'rap'.
9.5.5.1 Группа выборок произвольно доступных выборок
9.5.5.1.1 Определение
Типы группы: ʹrasʹ
Контейнер: Поле описания группы выборок (ʹrasʹ)
Обязательно: Отсутствует
Количество: Нуль или более
Группа выборок произвольно доступных выборок идентифицирует выборки, содержащие по меньшей мере одну IRAP-картинку.
9.5.5.1.2 Syntax
9.5.5.1.3 Семантика
all_pics_are_IRAP, равный 1, специфицирует, что все кодированные картинки в каждой выборке группы являются IRAP-картинками. Когда значение равно 0, вышеуказанное ограничение может применяться или может не применяться.
IRAP_nal_unit_type специфицирует тип NAL-единицы IRAP-картинки в каждой выборке группы. Значение IRAP_nal_unit_type должно быть в диапазоне от 16 до 23, включительно.
num_IRAP_pics специфицирует число IRAP-картинок в каждой выборке группы.
IRAP_pic_layer_id специфицирует значение nuh_layer_id i-ой IRAP-картинки в каждой выборке группы.
9.5.6 Группы выборок точек восстановления произвольного доступа и точек произвольного доступа
Для видеоданных, описываемых записью выборки типа ʹhvc1ʹ, ʹhev1ʹ, ʹhvc2ʹ или ʹhev2ʹ, группа выборок восстановления произвольного доступа и группа выборок точек произвольного доступа идентифицируют точки восстановления произвольного доступа и точки произвольного доступа, соответственно, как для HEVC-декодера, так и SHVC-декодера (если имеются), работающих над всем битовым потоком. Для видеоданных, описываемых записью выборки типа ʹshc1ʹ или 'shv1ʹ, группа выборок восстановления произвольного доступа идентифицирует восстановление произвольного доступа всего битового потока SHVC, и группа выборок точек произвольного доступа идентифицирует точки произвольного доступа во всем битовом потоке SHVC.
Выборка SHVC рассматривается как точка произвольного доступа, если каждая кодированная картинка в единице доступа является IRAP-картинкой (с RASL-картинками или без них), как определено в ISO/IEC 23008-2, и передние выборки в ISO/IEC 14496-2 являются выборками, в которых все картинки являются RASL-картинками, как определено в ISO/IEC 23008-2.
9.5.7 Бокс независимых доступных выборок
Если он используется в треке, который является HEVC- и SHVC- совместимым, то следует учитывать, что операторы являются истинными, независимо от того, какой действительный поднабор данных SHVC (возможно, только данные HEVC) используется. ʹНеизвестныеʹ значения (значение 0 полей sample-depends-on, sample-is-depended-on и sample-has-redundancy) могут потребоваться, если информация изменяется.
9.5.8 Определение подвыборки для SHVC
Эта подстатья расширяет определение подвыборки HEVC в 8.4.8.
Для использования бокса информации подвыборки (8.7.7 в ISO/IEC 14496-12) в потоке SHVC, подвыборка определена на основе значения флагов бокса информации подвыборки, как специфицировано ниже. Присутствие этого бокса является опциональным; однако если он присутствует в треке, содержащем данные SHVC, он будет иметь семантику, определенную здесь.
Флаги специфицируют тип информации подвыборки, приведенной в этом боксе, следующим образом:
0: Подвыборки, основанные на NAL-единицах. Подвыборка содержит одну или более непрерывных NAL-единиц.
1: Подвыборки, основанные на единице декодирования. Подвыборка содержит точно одну единицу декодирования.
2: Подвыборки, основанные на мозаичных элементах. Подвыборка либо содержит один мозаичный элемент и ассоциированные не-VCL NAL-единицы, если имеются, из VCL NAL-единиц, содержащих мозаичный элемент, либо содержит одну или более не-VCL NAL-единиц.
3: Подвыборки, основанные на CTU-строке. Подвыборка либо содержит одну CTU-строку в вырезке и ассоциированные не-VCL NAL-единицы, если имеются, из VCL NAL-единиц, содержащих CTU-строку, либо содержит одну или более не-VCL NAL-единиц. Этот тип информации подвыборки не должен использоваться, если entropy_coding_sync_enabled_flag равен 0.
4: Подвыборки, основанные на вырезке. Подвыборка либо содержит одну вырезку (где каждая вырезка может содержать один или более сегментов вырезки, каждый из которых является NAL-единицей) и ассоциированные не-VCL NAL-единицы, если имеются, либо содержит одну или более не-VCL NAL-единиц.
5: Подвыборки, основанные на картинке. Подвыборка содержит одну кодированную картинку и ассоциированные не-VCL NAL-единицы.
Другие значения флагов зарезервированы.
Поле subsample_priority должно быть установлено на значение в соответствии со спецификацией этого поля в ISO/IEC 14496-12.
Поле исключения должно быть установлено на 1, только если эта выборка должна все же декодироваться, если эта подвыборка отбрасывается (например, подвыборка состоит из SEI NAL-единицы).
Если первый байт NAL-единицы включен в подвыборку, предшествующее поле длины должно также быть включено в ту же подвыборку.
SubLayerRefNalUnitFlag равный 0, указывает, что все NAL-единицы в подвыборке являются VCL NAL-единицами не опорной картинки подуровня, как специфицировано в ISO/IEC 23008-2. Значение 1 указывает, что все NAL-единицы в подвыборке являются VCL NAL-единицами опорной картинки подуровня, как специфицировано в ISO/IEC 23008-2.
RapNalUnitFlag, равный 0, указывает, что ни одна из NAL- единиц в подвыборке не имеет nal_unit_type, равный IDR_W_RADL, IDR_N_LP, CRA_NUT, BLA_W_LP, BLA_W_RADL, BLA_N_LP, RSV_IRAP_VCL22 или RSV_IRAP_VCL23, как специфицировано в ISO/IEC 23008-2. Значение 1 указывает, что все NAL-единицы в подвыборке имеют nal_unit_type, равный IDR_W_RADL, IDR_N_LP, CRA_NUT, BLA_W_LP, BLA_W_RADL, BLA_N_LP, RSV_IRAP_VCL22 или RSV_IRAP_VCL23, как специфицировано в ISO/IEC 23008-2.
VclNalUnitFlag, равный 0, указывает, что все NAL-единицы в подвыборке являются не-VCL NAL-единицами. Значение 1 указывает, что все NAL-единицы в подвыборке являются VCL NAL-единицами.
DiscardableFlag указывает значение флага исключения VCL NAL-единиц в подвыборке. Все VCL NAL-единицы в подвыборке должны иметь то же самое значение флага исключения.
Примечание. Это не является тем же самым определением, что и для флага исключения в боксе информации подвыборки.
NoInterLayerPredFlag указывает значение inter_layer_pred_enabled_flag VCL NAL-единиц в подвыборке. Все VCL NAL-единицы в подвыборке должны иметь то же самое значение inter_layer_pred_enabled_flag.
LayerId указывает значение nuh_layer_id NAL-единиц в подвыборке. Все NAL-единицы в подвыборке должны иметь то же самое значение nuh_layer_id.
TempId указывает значение TemporalId NAL-единиц в подвыборке. Все NAL-единицы в подвыборке должны иметь то же самое значение TemporalId.
vcl_idc указывает, содержит ли подвыборка данные уровня видео кодирования (VCL), не-VCL данные или и то и другое, следующим образом:
0: Подвыборка содержит VCL-данные и не содержит не-VCL-данных
1: Подвыборка не содержит VCL-данных и содержит не-VCL-данные
2: Подвыборка может содержать как VCL-, так и не-VCL-данные, которые должны быть ассоциированы друг с другом. Например, подвыборка может содержать SEI-сообщение информации блока декодирования, за которым следует набор NAL-единиц, ассоциированных с SEI-сообщением.
3: Зарезервировано
log2_min_luma_ctb указывает единицу ctb_x и ctb_y, специфицированные следующим образом:
0: 8 выборок яркости
1: 16 выборок яркости
2: 32 выборок яркости
3: 64 выборок яркости
ctb_x специфицирует координату с 0-базой самых правых выборок яркости мозаичного элемента, ассоциированного с подвыборкой, когда флаги равны 2 и vcl_idc равно 1 или 2, в единицах, полученных из log2_min_luma_ctb, как специфицировано выше.
ctb_y специфицирует координату с 0-базой самых нижних выборок яркости мозаичного элемента, ассоциированного с подвыборкой, когда флаги равны 2 и vcl_idc is равно 1 или 2, в единицах, полученных из log2_min_luma_ctb как специфицировано выше.
VclNalUnitType указывает значение nal_unit_type VCL NAL-единиц в подвыборке. Все VCL NAL-единицы в подвыборке должны иметь то же самое значение nal_unit_type.
9.5.9 Обработка не выводимых выборок
Спецификация в 8.4.9 применяется с ʺHEVCʺ замененным на ʺSHVC,ʺ и не выводимая выборка определяется как выборка, в которой картинка(и) целевых уровней вывода имеет(ют) pic_output_flag, равный 0. Когда единица доступа содержит некоторые кодированные картинки, которые имеют pic_output_flag, равный 1, и некоторые другие кодированные картинки, которые имеют pic_output_flag, равный 0, по меньшей мере два трека должны быть использованы для хранения потока, так что в каждом треке все кодированные картинки в каждой выборке имеют то же самое значение pic_output_flag.
10 10 Определения элементарного потока и выборки MV-HEVC
10.1 Введение
Настоящая статья специфицирует формат хранения данных MV-HEVC. Она расширяет определения формата хранения HEVC в статье 8.
Формат файла для хранения контента MV-HEVC, как определено в этой статье и приложениях A-D, использует существующие возможности базового формата медиа файла ISO и простого формата файла HEVC (т.е. формата файла, специфицированного в статье 8). Кроме того, используются следующие структуры и расширения, среди прочего, чтобы поддерживать функции, специфические для MV-HEVC.
Агрегатор:
Структура для обеспечения возможности эффективного масштабируемого группирования NAL-единиц путем замены нерегулярных шаблонов (паттернов) NAL-единиц на регулярные шаблоны агрегированных единиц данных.
Экстрактор:
Структура для обеспечения возможности эффективного извлечения NAL-единиц из других треков, чем тот, который содержит медиа данные.
HEVC-совместимость:
Предоставление возможности хранения битового потока MV-HEVC совместимым с HEVC способом, так что HEVC-совместимый базовый уровень может быть использован любым считывателем, совместимым с простым форматом файла HEVC.
Поддержка для MV-HEVC включает в себя ряд инструментов, и имеются различные ʹмоделиʹ, как они могут быть использованы. В частности, поток MV-HEVC может быть помещен в треки с помощью ряда способов, среди которых имеется следующее:
1. все виды в одном треке, маркированные группами выборок;
2. каждый вид в его собственном треке, маркированный в записях выборок;
3. гибрид, один трек, содержащий все виды, и один или более одновидовых треков, каждый из которых содержит вид, который может быть независимо кодирован;
4. ожидаемые рабочие точки, каждая в одном треке (например, база HEVC, стерео пара, многовидовая сцена).
Формат файла MV-HEVC обеспечивает возможность сохранения одного или более видов в треке, аналогично поддержке для SHVC в статье 9. Сохранение множества видов на каждый трек может быть использовано, например, когда контент-провайдер желает предоставлять многовидовой битовый поток, который не предназначается для разбиения, или когда битовый поток создан для предопределенных наборов выводимых видов (таких как 1, 2, 5, или 9 видов), где треки могут быть созданы соответственно. Если более одного вида сохранено в треке, и имеется несколько треков (более одного), представляющих битовый поток MV-HEVC, рекомендуется использование механизма группирования выборок.
Когда битовый поток MV-HEVC представлен множеством треков, и плеер использует рабочую точку, которая содержит данные во множестве треков, плеер должен реконструировать единицы доступа MV-HEVC перед пропусканием их на декодер MV-HEVC. Рабочая точка MV-HEVC может быть явно представлена треком, т.е., единица доступа реконструируется просто разрешением всех NAL-единиц экстрактора и агрегатора выборки. Если число рабочих точек велико, то создание трека для каждой рабочей точки может быть связано с высокими потребностями пространства и оказаться непрактичным. В таком случае единицы доступа MV-HEVC реконструируются, как специфицировано в 10.5.2. Запись конфигурации декодера MV-HEVC содержит поле, указывающее, используют ли ассоциированные выборки реконструкцию явных или неявных единиц доступа (см. поле explicit_au_track).
10.2 Структура трека MV-HEVC
Потоки MV-HEVC сохраняются в соответствии с 8.2, со следующим определением элементарного потока видео MV-HEVC:
- Элементарные потоки видео MV-HEVC должны содержать все связанные с видео кодированием NAL-единицы (т.е. те NAL-единицы, которые содержат видеоданные или сигнализируют о структуре видео) и могут содержать не относящиеся к видео кодированию NAL-единицы, такие как SEI-сообщения и NAL-единицы ограничителя единиц доступа. Также могут присутствовать агрегаторы (см. A.2) или экстракторы (см. A.3). Агрегаторы и экстракторы должны обрабатываться, как определено в этом Международном стандарте (например, не должны непосредственно помещаться в выходной буфер при доступе к файлу). Другие NAL-единицы, которые явно не запрещены, могут присутствовать, и если они являются нераспознаваемыми, они должны игнорироваться (например, не помещаться в выходной буфер при доступе к файлу).
Потоки MV-HEVC не должны сохраняться с использованием ассоциированных потоков наборов параметров, если требуется.
Могут быть VCL NAL-единицы с nuh_layer_id, равным 0, VCL NAL-единицы с nuh_layer_id большим, чем 0, и другие не-VCL NAL-единицы, присутствующие в элементарном потоке видео MV-HEVC. Дополнительно, могут быть NAL-единицы агрегатора или экстрактора, присутствующие в элементарном потоке видео MV-HEVC.
10.3 Использование простого формата файла HEVC
Формат файла MV-HEVC является расширением простого формата файла HEVC, определенного в статье 8.
10.4 Определение выборки и конфигурации
10.4.1 Введение
Выборка MV-HEVC: Выборка MV-HEVC является также единицей доступа, как определено в Приложении F к ISO/IEC 23008-2.
10.4.2 Канонический порядок и ограничение
10.4.2.1 Ограничения
Следующие ограничения применяются к данным MV-HEVC в дополнение к требованиям в статье 8.3.2.
- VCL NAL-единицы: Все VCL NAL-единицы в одной единице доступа должны содержаться в выборке, время композиции которой соответствует таковому картинки, представленной единицей доступа. Выборка MV-HEVC должна содержать по меньшей мере одну VCL NAL-единицу.
- Агрегаторы/экстракторы: Порядок всех NAL-единиц, включенных в агрегатор или отсылаемых экстрактором, является точно порядком декодирования, как если бы эти NAL-единицы присутствовали в выборке, не содержащей агрегаторы/экстракторы. После обработки агрегатором или экстрактором, все NAL-единицы должны находиться в действительном порядке декодирования, как специфицировано в ISO/IEC 23008-2.
10.4.2.2 Запись конфигурации декодера
Когда запись конфигурации декодера, определенная в статье 8.3.3.1, используется для потока, который может быть интерпретирован как поток MV-HEVC или HEVC, запись конфигурации декодера HEVC должна отражать свойства HEVC-совместимого базового вида, например, она должна содержать только набор параметров, необходимых для декодирования базового вида HEVC.
MVHEVCDecoderConfigurationRecord является структурно идентичным HEVCDecoderConfigurationRecord. Синтаксис является следующим:
Семантика полей в MVHEVCDecoderConfigurationRecord является той же самой, как определено для HEVCDecoderConfigurationRecord.
10.4.3 Синхро-выборка
Выборка MV-HEVC рассматривается как синхро-выборка, если каждая кодированная картинка в единице доступа является IRAP-картинкой без RASL-картинок, как определено в ISO/IEC 23008-2. Синхро-выборки документированы посредством таблицы синхро-выборок и могут быть дополнительно документированы группой выборок синхро-выборок и группой выборок 'rap', определенной подобно тому, как в SHVC.
10.4.4 Поле независимых и доступных выборок
Если оно используется в треке, который является HEVC и MV-HEVC-совместимым, то должно учитываться, что операторы являются истинными, независимо от того, какой действительный поднабор данных MV-HEVC (возможно, только данные HEVC) используется. ʹНеизвестныеʹ значения (значение 0 полей sample-depends-on, sample-is-depended-on и sample-has-redundancy) могут потребоваться, если информация изменяется.
10.4.5 Группы выборок точек восстановления произвольного доступа и точек произвольного доступа
Для видеоданных, описываемых записью выборки типа ʹhvc1ʹ, ʹhev1ʹ, ʹhvc2ʹ или ʹhev2ʹ, группа выборок восстановления произвольного доступа и группа выборок точек произвольного доступа идентифицируют точки восстановления произвольного доступа и точки произвольного доступа, соответственно, как для декодера HEVC, так и декодера MV-HEVC (если имеются), работающих над всем битовым потоком.
Для видеоданных, описываемых типом записи выборки MV-HEVC, группа выборок восстановления произвольного доступа идентифицирует восстановление произвольного доступа во всем битовом потоке MV-HEVC, и группа выборок точек произвольного доступа идентифицирует точки произвольного доступа во всем битовом потоке MV-HEVC.
10.5 Вывод из базового формата медиа файла ISO
10.5.1 Структура трека MV-HEVC
Многовидовой видео поток представлен одним или более видео треками в файле. Каждый трек представляет один или более видов потока.
Имеется минимальный набор из одного или более треков, которые, взятые вместе, содержат полный набор кодированной информации. Все эти треки должны иметь флаг ʺcomplete_representationʺ, установленный во всех их записях выборок. Эта группа треков, которые формируют полную кодированную информацию, называется ʺполным поднаборомʺ.
Пусть самая низкая рабочая точка является одной из всех рабочих точек, которая содержит NAL-единицы с nuh_layer_id, равным только 0, и TemporalId, равным только 0. Трек, который содержит самую низкую рабочую точку, должен быть определен как ʹбазовый трек видаʹ. Все другие треки, которые являются частью того же самого потока, должны быть связаны с этим базовым треком посредством ссылки на трек типа ʹsbasʹ (база вида).
Все треки, совместно используемые тем же самым базовым треком вида, должны совместно использовать ту же самую временную шкалу, что и базовый трек вида.
Если вид, представленный треком, использует другой вид, представленный другим треком, в качестве опоры (ссылки для) межвидового предсказания, ссылка на трек типа 'scal' должна быть включена в трек, ссылающийся на исходный трек для межвидового предсказания.
Если редактирования применяются к трекам, которые содержат видовые компоненты битового потока MV-HEVC, списки редактирований должны быть совместимы по всем трекам, на которые воздействуют редактирования.
10.5.2 Реконструкция единицы доступа
Чтобы реконструировать единицу доступа из выборок одного или более треков MV-HEVC, может потребоваться сначала определить целевые выводимые виды.
Виды, которые требуются для декодирования определенных целевых выводимых видов, могут быть определены из идентификаторов опорных (ссылочных) видов, включенных в поле идентификатора вида или ссылки на трек ʹscalʹ.
Если несколько треков содержат данные для единицы доступа, выравнивание соответствующих выборок в треках выполняется по времени декодирования, т.е. с использованием только таблицы время-выборка без учета списков редактирований.
Единица доступа реконструируется из соответствующих выборок в требуемых треках путем упорядочения их NAL-единиц в порядке, соответствующем ISO/IEC 23008-02. Следующий порядок обеспечивает схему процедуры для формирования удовлетворяющей требованиям единицы доступа:
- Все NAL-единицы наборов параметров (из ассоциированных треков наборов параметров и из ассоциированных треков элементарных потоков).
- Все SEI NAL-единицы (из ассоциированных треков наборов параметров и из ассоциированных треков элементарных потоков).
- Видовые компоненты в нисходящем порядке индексных значений порядка видов. NAL-единицы в видовом компоненте находятся в порядке их появления в выборке.
10.5.3 Запись выборки
10.5.3.1 Боксы для записи выборки
10.5.3.1.1 Бокс идентификатора вида
10.5.3.1.1.1 Определение
Тип поля: ʹvwidʹ
Контейнер: Запись выборки (ʹhev1ʹ, ʹhvc1ʹ, ʹhev2ʹ, ʹhvc2ʹ, ʹmhc1ʹ, ʹmhv1ʹ)
или MultiviewGroupEntry
Обязательно: Да (для записей выборок)
Количество: Точно одна (для записей выборок)
При включении в запись выборки, этот бокс указывает виды, включенные в трек. Этот бокс также указывает индекс порядка видов для каждого перечисленного вида. Дополнительно, бокс включает в себя минимальное и максимальное значение temporal_id, включенное в трек, когда бокс идентификатора вида включен в запись выборки. Кроме того, бокс указывает опорные виды, требуемые для декодирования видов, включенных в трек.
10.5.3.1.1.2 Синтаксис
10.5.3.1.1.3 Семантика
min_temporal_id, max_temporal_id принимают минимальное и максимальное значение, соответственно, из синтаксического элемента temporal_id, который присутствует в расширении заголовка NAL-единицы NAL-единиц, отображенных на трек или слой, когда бокс идентификатора вида включен в запись выборки, соответственно. Для AVC потоков это принимает значение, которое находится или должно быть в префиксной NAL-единице.
num_views, когда бокс идентификатора вида присутствует в записи выборки, указывает число видов, включенных в трек.
layer_id[i] указывает значение синтаксического элемента nuh_layer_id в заголовке NAL-единицы уровня, включенного в трек, когда бокс идентификатора включен в запись выборки.
view_id указывает идентификатор вида i-го уровня с nuh_layer_id, равным layer_id[i], как специфицировано в Приложении F к ISO/IEC 23008-2.
base_view_type указывает, является ли вид базовым видом (виртуальным или нет). Он принимает следующие значения:
0 указывает, что вид не является ни базовым видом, ни виртуальным базовым видом.
1 должно использоваться для обозначения не виртуального базового вида битового потока MV-HEVC.
2 является зарезервированным значением и не должно использоваться.
3 указывает, что вид с view_id[i] является виртуальным базовым видом. Соответствующий независимо кодированный не базовый вид с view_id[i] находится в другом треке. Если base_view_type равен 3, последующие num_ref_views должны быть равны 0.
depdent_layer[i][j] указывает, может ли j-ый уровень с nuh_layer_id, равным j, быть прямым или косвенным опорным уровнем уровня с nuh_layer_id, равным layer_id[i]. Если бокс идентификатора включен в запись выборки, то рекомендовано указывать опорные виды в той же самой записи выборки.
10.5.3.2 Определение записи выборки
Типы записи выборки: ʹhvc2ʹ, 'hev2', ʹmhc1ʹ,ʹmhv1',ʹ mhcCʹ,
Контейнер: Бокс описания выборки (ʹstsdʹ)
Обязательно: Одно из полей 'hvc1', 'hev1', 'hvc2', 'hev2', 'mhc1' или 'mhv1' является обязательным
Количество: Может присутствовать одна или более записей выборки
Если элементарный поток MV-HEVC содержит используемый HEVC-совместимый базовый вид, то должна использоваться запись визуальной выборки HEVC ('hvc1', 'hev1', 'hvc2', 'hev2'). Здесь запись должна содержать первоначально бокс конфигурации HEVC, за которым, возможно, следует бокс конфигурации MV-HEVC, как определено ниже. Бокс конфигурации HEVC документирует профиль, уровень и, возможно, также наборы параметров, относящихся к HEVC-совместимому базовому виду, как определено посредством HEVCDecoderConfigurationRecord. Поле конфигурации MV-HEVC документирует профиль, уровень и информацию набора параметров, относящуюся ко всему потоку, содержащему не базовые виды, как определено посредством MVHEVCDecoderConfigurationRecord, сохраненного в MVHEVCConfigurationBox.
Для всех записей выборок ʹhvc1,ʹ ʹhev1,ʹ ʹhvc2,ʹ ʹhev2,ʹ поля ширины и высоты в записи выборки документируют базовый уровень HEVC. Для записи выборки MV-HEVC (ʹmhc1ʹ, ʹmhv1ʹ) ширина и высота документируют разрешение, достигаемое путем дeкодирования любого одного вида всего потока.
Если элементарный поток MV-HEVC не содержит используемый базовый вид HEVC, то должна использоваться запись визуальной выборки MV-HEVC (ʹmhc1ʹ, ʹmhv1ʹ). Запись визуальной выборки MV-HEVC должна содержать бокс конфигурации MV-HEVC, как определено ниже. Это включает в себя MVHEVCDecoderConfigurationRecord, как определено в данном Международном стандарте.
Поле lengthSizeMinusOne в конфигурации MV-HEVC и HEVC в любой данной записи выборки должно иметь то же самое значение.
Это требование для типов записи выборки ʹhvc1ʹ и ʹhev1ʹ, как документировано в 6.5.3.1.1, также применимо здесь.
MVHEVCConfigurationBox может присутствовать в записи выборки 'hvc1', 'hev1', 'hvc2', 'hev2'. В этих случаях применяется определение HEVCMVHEVCSampleEntry или HEVC2MVHEVCSampleEntry приведенное ниже, соответственно.
Compressorname в базовом классе VisualSampleEntry указывает имя используемого компрессора, с рекомендованным значением ʺ\014MV-HEVC Codingʺ (\016 соответствует 14, длина строки ʺMV-HEVC Codingʺ в байтах).
Наборы параметров, требуемые для декодирования NAL-единицы, которая присутствует в данных выборки видео потока, либо непосредственно, либо по ссылке из экстрактора, должны присутствовать в конфигурации декодера этого видео потока или в ассоциированном потоке набора параметров (если используется).
Последующая таблица показывает для видео трека все возможные использования записей выборок, когда элементарный поток MV-HEVC сохранен в одном или более треков, конфигураций и инструментов MV-HEVC:
| Таблица 14 Использование записей выборок для треков HEVC и MV-HEVC |
||
| Имя записи выборки | с записями конфигурации | Значение |
| 'hvc1' или 'hev1' | Только конфигурация HEVC | Простой трек HEVC без NAL-единиц с nuh_layer_id больше, чем 0; экстракторы и агрегаторы не должны присутствовать. |
| 'hvc1' или 'hev1' | Конфигурации HEVC и MV-HEVC | Трек MV-HEVC с NAL-единицами с nuh_layer_id, равным 0, и NAL-единицами с nuh_layer_id больше, чем 0; Экстракторы и агрегаторы могут присутствовать; экстракторы не должны ссылаться на NAL-единицы с nuh_layer_id, равным 0; агрегаторы не должны содержать, но могут ссылаться на NAL-единицы с nuh_layer_id, равным 0. |
| 'hvc2' или 'hev2' | Только конфигурация HEVC | Простой трек HEVC без NAL-единиц с nuh_layer_id больше, чем 0; экстракторы могут присутствовать и использоваться для ссылки на NAL-единицы; агрегаторы могут присутствовать, чтобы содержать и ссылаться на NAL-единицы. |
| 'hvc2' или 'hev2' | Конфигурации HEVC и MV-HEVC | Трек MV-HEVC с NAL-единицами с nuh_layer_id, равным 0, и NAL-единицами с nuh_layer_id больше, чем 0; экстракторы и агрегаторы могут присутствовать; экстракторы могут ссылаться на любые NAL-единицы; агрегаторы могут содержать и ссылаться на любые NAL-единицы. |
| ʹmhc1ʹ или 'mhv1' | Конфигурация MV-HEVC | Трек MV-HEVC без NAL-единиц с nuh_layer_id, равным 0; экстракторы могут присутствовать и используются для ссылки на NAL-единицы; агрегаторы могут присутствовать и содержать и ссылаться на любые NAL-единицы. |
mvhevc-тип записи выборки в последующем является одним из {mhv1, mhc1}.
10.5.3.3 Синтаксис
10.5.4 Определение подвыборки для MV-HEVC
Определение подвыборки для MV-HEVC определено аналогично определению для SHVC.
10.5.5 Обработка не выводимых выборок
Обработка не выводимых выборок для MV-HEVC определена аналогично определению для SHVC.
[0124] Изменения в Приложении А показаны ниже.
Приложение A (нормативно)
Потоковые структуры
A.1 Введение
Агрегаторы и экстракторы являются внутренними структурами формата файла, обеспечивающими эффективное группирование NAL- единиц или извлечение NAL-единиц из других треков.
Агрегаторы и экстракторы используют синтаксис NAL-единиц. Эти структуры наблюдаются как NAL-единицы в контексте структуры выборки. При доступе к выборке, агрегаторы должны удаляться (оставляя их содержащиеся или ссылочные NAL-единицы), а экстракторы должны заменяться данными, на которые они ссылаются. Агрегаторы и экстракторы не должны присутствовать в потоке вне формата файла.
Эти структуры используют типы NAL-единиц, зарезервированные для прикладного/транспортного уровня посредством ISO/IEC 14496-10 или ISO/IEC 23008-2.
Примечание. Следующее цитируется из ISO/IEC 14496-10:
ʺПримечание. Типы 0 и 24…31 NAL-единиц могут быть использованы, как определено приложением. Никакой процесс декодирования для этих значений nal_unit_type не специфицирован в этой Рекомендации | Международном стандарте.ʺ
Примечание. Следующее цитируется из ISO/IEC 23008-2:
ʺПримечание 1. Типы NAL-единиц в диапазоне NSPEC48…UNSPEC63 могут быть использованы, как определено приложением. Никакой процесс декодирования для этих значений nal_unit_type не специфицирован в этой Спецификации. Поскольку различные приложения могут использовать эти типы NAL-единиц для разных целей, особое внимание должно быть уделено проектированию кодеров, которые генерируют NAL-единицы с этими значениями nal_unit_type, и проектированию декодеров, которые интерпретируют содержимое NAL-единиц с этими значениями nal_unit_type.ʺ
A.2 Агрегаторы
A.2.1 Определение
Эта подстатья описывает агрегаторы, которые позволяют записям группы отображения NALU быть непротиворечивыми и воспроизводимыми. (См. Приложение B).
Агрегаторы используются для группирования NAL-единиц, принадлежащих той же самой выборке.
Для хранения видео ISO/IEC 14496-10, применимы следующие правила:
- Агрегаторы используют тот же самый заголовок NAL-единицы, что и SVC VCL NAL-единицы или MVC VCL NAL-единицы, но с отличающимся значением типа NAL-единицы.
- Если svc_extension_flag синтаксиса NAL-единицы (специфицирован в 7.3.1 ISO/IEC 14496-10) агрегатора равен 1, то заголовок NAL-единицы SVC VCL NAL-единиц используется для агрегатора. В противном случае, заголовок NAL-единицы VCL NAL-единиц используется для агрегатора.
Для хранения видео ISO/IEC 23008-2, агрегаторы используют заголовок NAL-единицы, как определено в ISO/IEC 23008-2, который имеет тот же самый синтаксис для простого HEVC, SHVC и MV-HEVC.
Агрегаторы могут агрегировать, по включению, NAL-единицы в себе (в пределах размера, указанного их длиной), а также агрегировать, по ссылке, NAL-единицы, которые следуют за ними (в пределах области, указанной полем additional_bytes в них). Если поток сканируется посредством считывателя файла AVC или HEVC, только включенные NAL-единицы рассматриваются как ʺвнутриʺ агрегатора. Это позволяет считывателю файла AVC или HEVC пропускать целый набор ненужных NAL-единиц, если они агрегированы по включению. Это также позволяет считывателю AVC или HEVC не пропускать нужные NAL-единицы, но оставлять их в потоке, когда они агрегированы по ссылке.
Агрегаторы могут использоваться для группирования NAL-единиц базового уровня или базового вида. Если эти агрегаторы используются в треке ʹavc1ʹ, 'hvc1' или 'hev1', то агрегатор не должен использовать включение, а ссылаться на NAL-единицы базового уровня или базового вида (длина агрегатора включает в себя только его заголовок, а NAL-единицы, на которые ссылается агрегатор, специфицируются посредством additional_bytes).
Когда на агрегатор ссылается экстрактор с data_length, равным нулю, или группа отображения выборок, агрегатор интерпретируется в качестве агрегирующего как включенные, так и ссылочные байты.
Агрегатор может включать в себя или ссылаться на экстракторы. Экстрактор может выполнять извлечение из агрегаторов. Агрегатор не должен включать или ссылаться на другой агрегатор непосредственно, однако агрегатор может включать в себя или ссылаться на экстрактор, который ссылается на агрегатор.
При сканировании потока:
a) если агрегатор не распознан (например, посредством считывателя или декодера AVC или HEVC), он просто отбрасывается с его включенным содержимым;
b) если агрегатор не требуется (т.е. он принадлежит нежелательному уровню), то он и его содержимое, как по включению, так и по ссылке, просто отбрасываются (используя его поля длины и additional_bytes);
c) если агрегатор требуется, его заголовок просто отбрасывается, а его содержимое сохраняется.
Агрегатор сохраняется в выборке подобно любой другой NAL-единице.
Все NAL-единицы остаются в порядке декодирования в агрегаторе.
A.2.2 Синтаксис
A.2.3 Семантика
Значение переменной AgregatorSize равно размеру NAL-единицы агрегатора, и функция sizeof(X) возвращает размер поля X в байтах.
NALUnitHeader(): первые четыре байта SVC и MVC VCL NAL-единиц, или первые два байта ISO/IEC 23008-2 NAL-единиц.
nal_unit_type должен быть установлен на тип NAL-единицы агрегатора (тип 30 для видео ISO/IEC 14496-10 и тип 48 для видео ISO/IEC 23008-2).
Для агрегатора, включающего в себя или ссылающегося на SVC NAL-единицы, будет применяться следующее.
forbidden_zero_bit и reserved_three_2bits должны быть установлены, как специфицировано в ISO/IEC 14496-10.
Другие поля (nal_ref_idc, idr_flag, priority_id, no_inter_layer_pred_flag, dependency_id, quality_id, temporal_id, use_ref_base_pic_flag, discardable_flag и output_flag) должны быть установлены, как специфицировано в A.4.
Для агрегатора, включающего в себя или ссылающегося на MVC NAL-единицы, должно применяться следующее.
Forbidden_zero_bit и reserved_one_bit должны быть установлены, как специфицировано в ISO/IEC 14496-10.
Другие поля (nal_ref_idc, non_idr_flag, priority_id, view_id, temporal_id, anchor_pic_flag и inter_view_flag) должны быть установлены, как специфицировано в A.5.
Для агрегатора, включающего в себя или ссылающегося на NAL-единицы ISO/IEC 23008-2, должно применяться следующее.
forbidden_zero_bit должен быть установлен, как специфицировано в ISO/IEC 23008-2.
Другие поля (nuh_layer_id и nuh_temporal_id_plus1) должны быть установлены, как специфицировано в A.6.
additional_bytes: Число байтов, следующих за этой NAL-единицей агрегатора, которые должны рассматриваться как агрегированные этим агрегатором, если на этот агрегатор ссылается экстрактор с data_length, равный нулю или группе выборок отображения.
NALUnitLength: Специфицирует размер, в байтах, следующей NAL-единицы. Размер этого поля специфицирован полем lengthSizeMinusOne.
NALUnit: NAL-единица, как специфицировано в ISO/IEC 14496-10 или ISO/IEC 23008-2, включающая в себя заголовок NAL-единицы. Размер NAL-единицы специфицирован посредством NALUnitLength.
A.3 Экстракторы
A.3.1 Определение
Эта подстатья описывает экстракторы, которые обеспечивают возможность компактного формирования треков, которые извлекают, по ссылке, данные NAL-единиц из других треков.
Агрегатор может включать в себя или ссылаться на экстракторы. Экстрактор может ссылаться на агрегаторы. Когда экстрактор обрабатывается считывателем файла, который требует это, экстрактор логически заменяется байтами, на которые он ссылается. Эти байты не должны содержать экстракторы; экстрактор не должен ссылаться, прямо или косвенно, на другие экстракторы.
Примечание. Данный трек, на который дается ссылка, может содержать экстракторы, даже если данные, на которые ссылается экстрактор, не должны.
Экстрактор содержит инструкцию извлечь данные из другого трека, который связан с данным треком, в котором находится экстрактор, посредством ссылки трека типа 'scal'.
Копируемые байты должны быть одним из следующего:
a) Полная NAL-единица; отметим, что когда дается ссылка на агрегатор, копируются как включенные байты, так и те, на которые дается ссылка.
b) Более чем одна полная NAL-единица.
В обоих случаях извлекаемые байты начинаются с поля действительной длины и заголовка NAL-единицы.
Байты копируются только из одной идентифицированной выборки в треке, на который дается ссылка, через указанную ссылку трека ʹscalʹ. Выравнивание реализуется во время декодирования, то есть с использованием только таблицы время-выборка, с последующим отсчитанным смещением в номере выборки. Экстракторы являются понятием медиа-уровня и, таким образом, применяются к предназначенному треку, прежде чем будет рассматриваться какой-либо список редактирований. (Однако обычно можно полагать, что списки редактирований в обоих треках будут идентичными).
A.3.2 Синтаксис
A.3.3 Семантика
NALUnitHeader(): первые четыре байта SVC и MVC VCL NAL-единиц или первые два байта NAL-единиц ISO/IEC 23008-2.
nal_unit_type должен быть установлен на тип NAL-единицы экстрактора (тип 31 для видео ISO/IEC 14496-10 и тип 49 для видео ISO/IEC 23008-2).
Для экстрактора, ссылающегося на SVC NAL-единицы, должно применяться следующее.
forbidden_zero_bit и reserved_three_2bits должны быть установлены, как специфицировано в ISO/IEC 14496-10.
Другие поля (nal_ref_idc, idr_flag, priority_id, no_inter_layer_pred_flag, dependency_id, quality_id, temporal_id, use_ref_base_pic_flag, discardable_flag и output_flag) должны быть установлены, как специфицировано в A.4.
Для экстрактора, ссылающегося на MVC NAL-единицы, должно применяться следующее.
forbidden_zero_bit и reserved_one_bit должны быть установлены, как специфицировано в ISO/IEC 14496-10.
Другие поля (nal_ref_idc, non_idr_flag, priority_id, view_id, temporal_id, anchor_pic_flag и inter_view_flag) должны быть установлены, как специфицировано в A.5.
Для экстрактора, ссылающегося на NAL-единицы ISO/IEC 23008-2, должно применяться следующее.
forbidden_zero_bit должно быть установлено, как специфицировано в ISO/IEC 23008-2.
Другие поля (nuh_layer_id и nuh_temporal_id_plus1) должны быть установлены, как специфицировано в A.6.
track_ref_index специфицирует индекс ссылки на трек типа ʹscalʹ, чтобы найти трек, из которого извлекать данные. Выборка в том треке, из которого извлекаются данные, является выровненной по времени или ближайшей предшествующей на временной шкале декодирования медиа, т.е. используется только таблица время-выборка, настроенная посредством смещения, специфицированного посредством sample_offset с выборкой, содержащей экстрактор. Первая ссылка на трек имеет значение индекса 1; значение 0 зарезервировано.
sample_offset задает относительный индекс выборки в связанном треке, который будет использоваться в качестве источника информации. Выборка 0 (нуль) является выборкой с тем же самым, или ближайшим предшествующим, временем декодирования по сравнению с временем декодирования выборки, содержащей экстрактор; выборка 1 (один) является следующей выборкой, выборка -1 (минус 1) является предшествующей выборкой и т.д.
data_offset: Смещение первого байта в ссылочной выборке для копирования. Если извлечение начинается с первого байта данных в той выборке, смещение принимает значение 0. Смещение должно ссылаться на начало поля длины NAL-единицы.
data_length: Число байтов для копирования. Если это поле принимает значение 0, то копируется полная одна NAL-единица, на которую дается ссылка (т.е. длина для копирования берется из поля длины, на которое ссылается смещение данных, расширенная на поле additional_bytes в случае агрегаторов).
Примечание. Если два трека используют разные значения lengthSizeMinusOne, то извлекаемые данные будут требовать переформатирования, чтобы соответствовать размеру поля длины трека-места назначения.
A.4 Значения заголовка NAL-единицы для SVC
Как экстракторы, так и агрегаторы используют SVC-расширение заголовка NAL-единицы. NAL-единицы, извлеченные экстрактором или агрегированные агрегатором, являются всеми такими NAL-единицами, на которые дается ссылка или которые включены, путем рекурсивной проверки содержимого NAL-единиц агрегатора или экстрактора.
Поля nal_ref_idc, idr_flag, priority_id, temporal_id, dependency_id, quality_id, discardable_flag, output_flag, use_ref_base_pic_flag и no_inter_layer_pred_flag должны принимать следующие значения:
nal_ref_idc должен быть установлен на наивысшее значение поля во всех извлеченных или агрегированных NAL-единицах.
idr_flag должен быть установлен на наивысшее значение поля во всех извлеченных или агрегированных NAL-единицах.
priority_id, temporal_id, dependency_id и quality_id должны быть установлены на самые низкие значения полей, соответственно, во всех извлеченных или агрегированных NAL-единицах.
discardable_flag должен быть установлен на 1, если и только если все извлеченные или агрегированные NAL-единицы имеют discardable_flag, установленный на 1 и установленный на 0 в противном случае.
output_flag должен быть установлен на 1, если по меньшей мере одна из агрегированных и извлеченных NAL-единиц имеет этот флаг, установленный на 1 и в противном случае установленный на 0.
use_ref_base_pic_flag должен быть установлен на 1, если и только если по меньшей мере одна из извлеченных или агрегированных VCL NAL-единиц имеет use_ref_base_pic_flag, установленный на 1 и установленный на 0 в противном случае.
no_inter_layer_pred_flag должен быть установлен на 1, если и только если все извлеченные или агрегированные VCL NAL-единицы имеют no_inter_layer_pred_flag, установленный на 1 и установленный на 0 в противном случаен.
Если набор извлеченных или агрегированных NAL-единиц пустой, то каждое из этих полей принимает значение, соответствующее описанию отображаемого слоя.
Примечание. Агрегаторы могут группировать NAL-единицы с различной информацией масштабируемости.
Примечание. Агрегаторы могут быть использованы для группирования NAL-единиц, принадлежащих уровню масштабируемости, который может не сигнализироваться заголовком NAL-единицы (например, NAL-единиц, принадлежащих области, представляющей интерес). Описание таких агрегаторов может быть дано с описанием слоя и группами отображения NAL-единиц. В таком случае более чем один агрегатор с той же самой информацией масштабируемости может появиться в одной выборке.
Примечание. Если несколько масштабируемых треков ссылаются на те же самые медиа данные, то агрегатор должен группировать NAL-единицы только с идентичной информацией масштабируемости. Это обеспечивает то, что результирующий шаблон может быть доступным для каждого из треков.
Примечание. Если ни одна NAL-единица конкретного уровня не существует в единице доступа, то может существовать пустой агрегатор (в котором длина агрегатора включает в себя только заголовок, и additional_bytes является нулем).
A.5 Значения заголовка NAL-единицы для MVC
Как агрегаторы, так и экстракторы используют MVC-расширение заголовка NAL-единицы. NAL-единицы, извлеченные экстрактором или агрегированные агрегатором, являются всеми такими NAL-единицами, на которые дается ссылка или которые включены, путем рекурсивной проверки содержимого NAL-единиц агрегатора или экстрактора.
Поля nal_ref_idc, non_idr_flag, priority_id, view_id, temporal_id, anchor_pic_flag и inter_view_flag должны принимать следующие значения:
nal_ref_idc должен быть установлен на наивысшее значение поля во всех извлеченных или агрегированных NAL-единицах.
non_idr_flag должен быть установлен на самое низкое значение поля во всех извлеченных или агрегированных NAL-единицах.
priority_id и temporal_id должны быть установлены на самые низкие значения полей, соответственно, во всех извлеченных или агрегированных NAL-единицах.
anchor_pic_flag и inter_view_flag должны быть установлены на наивысшее значение полей, соответственно, во всех агрегированных или извлеченных VCL NAL-единицах.
Если набор извлеченных или агрегированных NAL-единиц пустой, то каждое из этих полей принимает значение, соответствующее описанию отображаемого слоя.
A.6 Значения заголовка NAL-единицы для ISO/IEC 23008-2
Как агрегаторы, так и экстракторы используют заголовок NAL-единицы, как специфицировано в ISO/IEC 23008-2. NAL-единицы, извлеченные экстрактором или агрегированные агрегатором, являются всеми такими NAL-единицами, на которые дается ссылка или которые включены, путем рекурсивной проверки содержимого NAL-единиц агрегатора или экстрактора.
Поля nuh_layer_id и nuh_temporal_id_plus1 должны быть установлены следующим образом:
nuh_layer_id должен быть установлен на самое низкое значение поля во всех агрегированных и извлеченных NAL-единицах.
nuh_temporal_id_plus1 должен быть установлен на самое низкое значение поля во всех агрегированных и извлеченных NAL-единицах.
[0125] В одном альтернативном примере, новая структура, таблица или группа выборок определена, чтобы документировать все IRAP-единицы доступа, как определено в Приложении F MV-HEVC WD5 или SHVC WD3. Альтернативно, новая структура, таблица или группа выборок определена, чтобы документировать все IRAP-единицы доступа, как определено в Приложении F MV-HEVC WD5 или SHVC WD3, но исключая те единицы доступа, где все кодированные картинки являются IRAP-картинками. В другом альтернативном примере, запись группы выборок синхро-выборок SyncSampleEntry переопределена, чтобы включать aligned_sync_flag в один из зарезервированных битов, который специфицирует, что все картинки в выборке, которые принадлежат этой группе, являются IDR-картинками, CRA-картинками или BLA-картинками. В другом альтернативном примере, определен общий формат файла для SHVC и MV-HEVC, включающий в себя все общие аспекты из форматов файлов SHVC и MV-HEVC, и только форматы файлов SHVC и MV-HEVC переопределены, чтобы включать в себя только аспекты, относящиеся к такому расширению. В другом альтернативном примере, определены запись выборки метаданных SHVC SHVCMetadataSampleEntry и SHVCMetadataSampleConfigBox, и также определен тип оператора выборки метаданных scalabilityInfoSHVCStatement.
[0126] Фиг. 2 является блок-схемой, иллюстрирующей примерный видео кодер 20, который реализует методы, описанные в настоящем раскрытии. Видео кодер 20 может быть сконфигурирован, чтобы выводить одновидовые, многовидовые, масштабируемые, 3D и другие типы видеоданных. Видео кодер 20 может быть сконфигурирован, чтобы выводить видео на средство 27 пост-процессорной обработки. Средство 27 пост-процессорной обработки предназначено для того, чтобы представлять пример видео средства, такого как MANE или стыкующее/редактирующее устройство, которое может обрабатывать кодированные видеоданные с видео кодера 20. В некоторых случаях средство пост-процессорной обработки может быть примером сетевого объекта. В некоторых системах видео кодирования, средство 27 пост-процессорной обработки и видео кодер 20 могут быть частями отдельных устройств, в то время как в других случаях, функциональность, описанная по отношению к средству 27 пост-процессорной обработки, может выполняться тем же самым устройством, которое содержит видео кодер 20. Средство 27 пост-процессорной обработки может быть видео устройством. В некоторых примерах, средство 27 пост-процессорной обработки может быть тем же самым, что и устройство 34 генерации файла по фиг. 1.
[0127] Видео кодер 20 может выполнять интра- и интер-кодирование видео блоков внутри видео вырезок. Интра-кодирование основывается на пространственном предсказании, чтобы сокращать или устранять пространственную избыточность в видео в пределах данного видео кадра или картинки. Интер-кодирование основывается на временном предсказании, чтобы сокращать или устранять временную избыточность в видео в пределах смежных кадров или картинок видео последовательности. Интра-режим (I-режим) может относиться к любому из различных режимов сжатия на пространственной основе. Интер-режимы, такие как однонаправленное предсказание (P-режим) или двунаправленное предсказание (B-режим), могут относиться к любому из различных режимов сжатия на временной основе.
[0128] В примере по фиг. 2, видео кодер 20 включает в себя компонент 35 разделения, компонент 41 обработки предсказания, компонент 63 фильтрации, память 64 опорных картинок, сумматор 50, компонент 52 обработки преобразования, компонент 54 квантования и компонент 56 энтропийного кодирования. Компонент 41 обработки предсказания включает в себя компонент 42 оценки движения, компонент 44 компенсации движения и компонент 46 обработки интра-предсказания. Для реконструкции видео блока видео кодер 20 также включает в себя компонент 58 обратного квантования, компонент 60 обратного преобразования и сумматор 62. Компонент 63 фильтрации предназначен для представления одного или более контурных фильтров, таких как фильтр деблокирования, адаптивный контурный фильтр (ALF) и фильтр адаптивного к выборке смещения (SAO). Хотя компонент 63 фильтрации показан на фиг. 2 как контурный фильтр, в другой конфигурации, компонент 63 фильтрации может быть реализован как пост-контурный фильтр.
[0129] Память видеоданных видео кодера 20 может хранить видеоданные, подлежащие кодированию компонентами видео кодера 20. Видеоданные, сохраненные в памяти видеоданных, могут быть получены, например, от источника 18 видео. Память 64 опорных картинок может быть памятью опорных картинок, которая хранит опорные видеоданные для использования в кодировании видеоданных видео кодером 20, например, в режимах интра- или интер-кодирования. Память видеоданных и память 64 опорных картинок может быть образована любым из множества устройств памяти, таких как динамическая память произвольного доступа (DRAM), включая синхронную DRAM (SDRAM), магниторезистивную RAM (MRAM), резистивную RAM (RRAM) или другие типы устройств памяти. Память видеоданных и память 64 опорных картинок может быть обеспечена тем же самым устройством памяти или отдельными устройствами памяти. В различных примерах, память видеоданных может быть расположена на том же кристалле вместе с другими компонентами видео кодера 20 или быть внешней по отношению к этим компонентам.
[0130] Как показано на фиг. 2, видео кодер 20 принимает видеоданные, и компонент 35 разделения разделяет эти данные на видео блоки. Это разделение может также включать в себя разделение на вырезки, мозаичные элементы или другие крупные единицы, а также разделение видео блока, например, в соответствии со структурой квадродерева LCU и CU. Видео кодер 20 обобщенно иллюстрирует компоненты, которые кодируют видео блоки в видео вырезке, подлежащей кодированию. Вырезка может быть разделена на множество видео блоков (и, возможно, в наборы видео блоков, называемых мозаичными элементами). Компонент 41 обработки предсказания может выбрать один из множества возможных режимов кодирования, такой как один из множества режимов интра-кодирования или один из множества режимов интер-кодирования, для текущего видео блока результатов погрешностей (например, скорости кодирования и уровня искажения). Компонент 41 обработки предсказания может предоставлять результирующий интра- или интер-кодированный блок на сумматор 50, чтобы генерировать остаточный блок данных, и на сумматор 62, чтобы реконструировать кодированный блок для использования в качестве опорной картинки.
[0131] Компонент 46 обработки интра-предсказания в компоненте 41 обработки предсказания может выполнять кодирование с интра-предсказанием текущего видео блока относительно одного или более соседних блоков в том же самом кадре или вырезке, что и текущий блок, подлежащий кодированию, чтобы обеспечить пространственное сжатие. Компонент 42 оценки движения и компонент 44 компенсации движения в компоненте 41 обработки предсказания выполняют кодирование с интер-предсказанием текущего видео блока относительно одного или более блоков предсказания в одной или более опорных картинках, чтобы обеспечить временное сжатие.
[0132] Компонент 42 оценки движения может быть сконфигурирован, чтобы определять режим интер-предсказания для видео вырезки в соответствии с предопределенным шаблоном для видео последовательности. Предопределенный шаблон может указывать видео вырезки в последовательности как P-вырезки, B-вырезки или GPB-вырезки. Компонент 42 оценки движения и компонент 44 компенсации движения могут быть в высокой степени интегрированными, но иллюстрируются по отдельности для концептуальных целей. Оценивание движения, выполняемое компонентом 42 оценки движения, является процессом генерации векторов движения, которые оценивают движение для видео блоков. Вектор движения, например, может указывать смещение PU видео блока внутри текущего видеокадра или картинки относительно блока предсказания в опорной картинке.
[0133] Блок предсказания является блоком, который обнаружен как близко совпадающий с PU видео блока, подлежащего кодированию, в терминах пиксельной разности, что может определяться суммой абсолютной разности (SAD), суммой квадратичной разности (SSD) или другими разностными метриками. В некоторых примерах, видео кодер 20 может вычислять значения для суб-целочисленных пиксельных позиций опорных картинок, сохраненных в памяти 64 опорных картинок. Например, видео кодер 20 может интерполировать значения 1/4-пиксельных позиций, 1/8-пиксельных позиций и других дробных пиксельных позиций опорной картинки. Поэтому компонент 42 оценки движения может выполнять поиск движения относительно полно-пиксельных позиций и дробно-пиксельных позиций и выводить вектор движения с дробно-пиксельной точностью.
[0134] Компонент 42 оценки движения вычисляет вектор движения для PU видео блока в интер-кодированной вырезке путем сравнения позиции PU с позицией блока предсказания опорной картинки. Опорная картинка может быть выбрана из первого списка опорных картинок (Списка 0) или второго списка опорных картинок (Списка 1), каждый из которых идентифицирует одну или более опорных картинок, сохраненных в памяти 64 опорных картинок. Компонент 42 оценки движения посылает вычисленный вектор движения на компонент 56 энтропийного кодирования и компонент 44 компенсации движения.
[0135] Компенсация движения, выполняемая компонентом 44 компенсации движения, может предусматривать выборку или генерацию блока предсказания на основе вектора движения, определенного оцениванием движения, возможно, выполняя интерполяции до суб-пиксельной точности. После приема вектора движения для PU текущего видео блока, компонент 44 компенсации движения может локализовать блок предсказания, на который указывает вектор движения, в одном из списков опорных картинок. Видео кодер 20 может формировать остаточный видео блок путем вычитания пиксельных значений блока предсказания из пиксельных значений текущего кодируемого видео блока, формируя пиксельные разностные значения. Пиксельные разностные значения образуют остаточные данные для блока и могут включать в себя разностные компоненты как яркости, так и цветности. Сумматор 50 представляет компонент или компоненты, которые выполняют эту операцию вычитания. Компонент 44 компенсации движения может также генерировать синтаксические элементы, ассоциированные с видео блоками и видео вырезками, для использования видео декодером 30 при декодировании видео блоков видео вырезки.
[0136] Компонент 46 обработки интра-предсказания может выполнять интра-предсказание текущего блока, в качестве альтернативы интер-предсказанию, выполняемому компонентом 42 оценки движения и компонентом 44 компенсации движения, как описано выше. В частности, компонент 46 обработки интра-предсказания может определять режим интра-предсказания, чтобы использовать для кодирования текущего блока. В некоторых примерах, компонент 46 обработки интра-предсказания может кодировать текущий блок с использованием различных режимов интра-предсказания, например, в течение отдельных проходов кодирования, и компонент 46 обработки интра-предсказания (или компонент 40 выбора режима, в некоторых примерах) может выбрать подходящий режим интра-предсказания для использования из тестированных режимов. Например, компонент 46 обработки интра-предсказания может вычислять значения скорости-искажения с использованием анализа скорости-искажения для различных тестируемых режимов интра-предсказания и выбрать режим интра-предсказания, имеющий наилучшие характеристики скорости-искажения среди тестированных режимов. Анализ скорости-искажения обычно определяет величину искажения (или погрешность) между кодированным блоком и исходным, не кодированным блоком, который был кодирован для формирования кодированного блока, а также битовую скорость (то есть, число битов), используемую для формирования кодированного блока. Компонент 46 обработки интра-предсказания может вычислять отношения из искажений и скоростей для различных кодированных блоков, чтобы определить, какой режим интра-предсказания демонстрирует наилучшее значение скорости- искажения для блока.
[0137] В любом случае, после выбора режима интра-предсказания для блока, компонент 46 обработки интра-предсказания может предоставлять информацию, показательную для выбранного режима интра-предсказания для блока, на компонент 56 энтропийного кодирования. Компонент 56 энтропийного кодирования может кодировать информацию, указывающую выбранный режим интра-предсказания, в соответствии с методами настоящего раскрытия. Видео кодер 20 может включать в передаваемый битовый поток данные конфигурации, которые могут включать в себя множество индексных таблиц режима интра-предсказания и множество модифицированных индексных таблиц режима интра-предсказания (также упоминаемых как таблицы отображения кодовых слов), определения контекстов кодирования для различных блоков и указания наиболее вероятного режима интра-предсказания, индексной таблицы режима интра-предсказания и модифицированной индексной таблицы режима интра-предсказания, чтобы использовать для каждого из контекстов.
[0138] После того как компонент 41 обработки предсказания генерирует блок предсказания для текущего видео блока посредством либо интер-предсказания, либо интра-предсказания, видео кодер 20 может формировать остаточный видео блок путем вычитания блока предсказания из текущего видео блок. Остаточные видеоданные в остаточном блоке могут быть включены в один или более TU и применены к компоненту 52 обработки преобразования. Компонент 52 обработки преобразования преобразует остаточные видеоданные в остаточные коэффициенты преобразования с использованием преобразования, такого как дискретное косинусное преобразование (DCT) или концептуально подобное преобразование. Компонент 52 обработки преобразования может преобразовать остаточные видеоданные из пиксельной области в область преобразования, такую как частотная область.
[0139] Компонент 52 обработки преобразования может послать результирующие коэффициенты преобразования на компонент 54 квантования. Компонент 54 квантования квантует коэффициенты преобразования, чтобы дополнительно снизить битовую скорость. Процесс квантования может снизить битовую глубину, ассоциированную с некоторыми или всеми из коэффициентов. Степень квантования может быть модифицирована посредством настройки параметра квантования. В некоторых примерах, компонент 54 квантования может затем выполнять сканирование матрицы, включающей в себя квантованные коэффициенты преобразования. Альтернативно, компонент 56 энтропийного кодирования может выполнять сканирование.
[0140] После квантования, компонент 56 энтропийного кодирования может энтропийно кодировать синтаксические элементы, представляющие квантованные коэффициенты преобразования. Например, компонент 56 энтропийного кодирования может выполнять контекстно-адаптивное кодирование переменной длины (CAVLC), контекстно-адаптивное бинарное арифметическое кодирование (CABAC), основанное на синтаксисе контекстно-адаптивное бинарное арифметическое кодирование (SBAC), энтропийное кодирование с разделением интервалов вероятности (PIPE) или другую методологию энтропийного кодирования или метод. После энтропийного кодирования компонентом 56 энтропийного кодирования, кодированный битовый поток может быть передан на видео декодер 30 или архивирован для последующей передачи или извлечения видео декодером 30. Компонент 56 энтропийного кодирования может также энтропийно кодировать вектора движения и другие синтаксические элементы для текущей видео вырезки, которая кодируется.
[0141] Компонент 58 обратного квантования и компонент 60 обработки обратного преобразования применяют обратное квантование и обратное преобразование, соответственно, чтобы реконструировать остаточный блок в пиксельной области для последующего использования в качестве опорного блока опорной картинки. Компонент 44 компенсации движения может вычислить опорный блок путем добавления остаточного блока к блоку предсказания одной из опорных картинок в одном из списков опорных картинок. Компонент 44 компенсации движения может также применять один или более фильтров интерполяции к реконструированному остаточному блоку, чтобы вычислять суб-целочисленные пиксельные значения для использования в оценивании движения. Сумматор 62 суммирует реконструированный остаточный блок со скомпенсированным по движению блоком предсказания, сформированным компонентом 44 компенсации движения, чтобы сформировать опорный блок для сохранения в памяти 64 опорных картинок. Опорный блок может быть использован компонентом 42 оценки движения и компонентом 44 компенсации движения в качестве опорного блока, чтобы выполнять интер-предсказание блока в последующем видеокадре или картинке.
[0142] Видео кодер 20 представляет пример видео кодера, сконфигурированного, чтобы генерировать видеоданные, которые могут быть сохранены с использованием методов файлового формата, описанных в настоящем раскрытии.
[0143] Фиг. 3 является блок-схемой, иллюстрирующей примерный видео декодер 30, который может реализовать методы, описанные в настоящем раскрытии. Видео декодер 30 может быть сконфигурирован, чтобы декодировать одновидовые, многовидовые, масштабируемые, 3D и другие типы видеоданных. В примере на фиг. 3 видео декодер 30 включает в себя компонент 80 энтропийного декодирования, компонент 81 обработки предсказания, компонент 86 обратного квантования, компонент 88 обработки обратного преобразования, сумматор 90, компонент 91 фильтрации и память 92 опорных картинок. Компонент 81 обработки предсказания включает в себя компонент 82 компенсации и движения и компонент 84 обработки интра-предсказания. Видео декодер 30 может, в некоторых примерах, выполнять проход декодирования, в общем обратный проходу кодирования, описанному в отношении видео кодера 20 по фиг. 2.
[0144] Буфер 79 кодированных картинок (CPB) может принимать и сохранять кодированные видеоданные (например, NAL-единицы) битового потока. Видеоданные, сохраняемые в CPB 79, могут быть получены, например, из линии связи 16, например, от локального источника видео, такого как камера, посредством проводной или беспроводной сетевой передачи видеоданных или путем доступа к физическим носителям хранения данных. CPB 79 может образовывать память видеоданных, которая хранит кодированные видеоданные из битового потока кодированного видео. CPB 79 может быть памятью опорных картинок, которая хранит опорные видеоданные для использования в дeкодировании видеоданных видео декодером 30, например, в режимах интра- или интер-кодирования. CPB 79 и память 92 опорных картинок могут быть образованы любыми из множества устройств памяти, такими как динамическая память произвольного доступа (DRAM), включая синхронную DRAM (SDRAM), магниторезистивную RAM (MRAM), резистивную RAM (RRAM) или другие типы устройств памяти. CPB 79 и память 92 опорных картинок могут быть обеспечены тем же самым устройством памяти или отдельными устройствами памяти. В различных примерах, CPB 79 может быть расположен на том же кристалле вместе с другими компонентами видео декодера 30 или быть внешним по отношению к этим компонентам.
[0145] Во время процесса декодирования, видео декодер 30 принимает битовый поток кодированного видео, который представляет видео блоки кодированной видео вырезки и ассоциированные синтаксические элементы, от видео кодера 20. Видео декодер 30 может принимать битовый поток кодированного видео от сетевого объекта 29. Сетевой объект 29 может, например, быть сервером, MANE, видео редактором/средством стыковки, или другим таким устройством, сконфигурированным, чтобы реализовать один или более методов, описанных выше. Сетевой объект 29 может или не может включать в себя видео кодер, такой как видео кодер 20. Некоторые из методов, описанных в настоящем раскрытии, могут быть реализованы сетевым объектом 29 перед передачей сетевым объектом 29 битового потока кодированного видео на видео декодер 30. В некоторых системах видео декодирования, сетевой объект 29 и видео декодер 30 могут быть частями отдельных устройств, в то время как в других случаях, функциональность, описанная в отношении сетевого объекта 29, может выполняться тем же самым устройством, которое содержит видео декодер 30. Сетевой объект 29 может рассматриваться как видео устройство. Кроме того, в некоторых примерах, сетевой объект 29 является устройством 34 генерации файла по фиг. 1.
[0146] Компонент 80 энтропийного декодирования видео декодера 30 энтропийно декодирует конкретные синтаксические элементы битового потока, чтобы генерировать квантованные коэффициенты, вектора движения и другие синтаксические элементы. Компонент 80 энтропийного декодирования направляет вектора движения и другие синтаксические элементы на компонент 81 обработки предсказания. Видео декодер 30 может принимать синтаксические элементы на уровне видео вырезки и/или уровне видео блока.
[0147] Когда видео вырезка кодирована как интра-кодированная (I) вырезка, компонент 84 обработки интра-предсказания компонента 81 обработки предсказания может генерировать данные предсказания для видео блока текущей видео вырезки на основе сигнализированного режима интра-предсказания и данных из ранее декодированных блоков текущего кадра или картинки. Когда видеокадр кодирован как интер-кодированная (т.е., B, P или GPB) вырезка, компонент 82 компенсации движения компонента 81 обработки предсказания формирует блоки предсказания для видео блока текущей видео вырезки на основе векторов движения и других синтаксических элементов, полученных из компонента 80 энтропийного декодирования. Блоки предсказания могут быть сформированы из одной из опорных картинок в одном из списков опорных картинок. Видео декодер 30 может формировать списки опорных кадров, Список 0 и Список 1, используя установленные по умолчанию методы конструирования на основе опорных картинок, сохраненных в памяти 92 опорных картинок.
[0148] Компонент 82 компенсации движения определяет информацию предсказания для видео блока текущей видео вырезки путем синтаксического анализа векторов движения и других синтаксических элементов и использует информацию предсказания информацию для формирования блоков предсказания для текущего декодируемого видео блока. Например, компонент 82 компенсации движения использует некоторые из принятых синтаксических элементов, чтобы определять режим предсказания (например, интра- или интер-предсказание), использованный для кодирования видео блоков видео вырезки, тип интер-предсказания вырезки (например, B-вырезка, P-вырезка или GPB-вырезка), конструкционную информацию для одного или более из списков опорных картинок для вырезки, вектора движения для каждого интер-кодированного видео блока вырезки, статус интер-предсказания для каждого интер-кодированного видео блока вырезки и другую информацию, чтобы декодировать видео блоки в текущей видео вырезке.
[0149] Компонент 82 компенсации движения может также выполнять интерполяцию на основе фильтров интерполяции. Компонент 82 компенсации движения может использовать фильтры интерполяции, как использовалось видео кодером 20 при кодировании видео блоков, чтобы вычислять интерполированные значения для суб-целочисленных пикселов опорных блоков. В этом случае, компонент 82 компенсации движения может определять фильтры интерполяции, использованные видео кодером 20, из принятых синтаксических элементов и может использовать фильтры интерполяции для формирования блоков предсказания.
[0150] Компонент 86 обратного квантования обратно квантует, т.е., деквантует, квантованные коэффициенты преобразования, предоставленные в битовом потоке и декодированные компонентом 80 энтропийного декодирования. Процесс обратного квантования может включать в себя использование параметра квантования, вычисленного видео кодером 20 для каждого видео блока в видео вырезке, чтобы определять степень квантования и, аналогично, степень обратного квантования, которое должно быть применено. Компонент 88 обработки обратного преобразования применяет обратное преобразование, например, обратное DCT, обратное целочисленное преобразование или концептуально подобный процесс обратного преобразования к коэффициентам преобразования, чтобы сформировать остаточные блоки в пиксельной области.
[0151] После того как компонент 82 компенсации движения генерирует блок предсказания для текущего видео блока на основе векторов движения и других синтаксических элементов, видео декодер 30 формирует декодированный видео блок путем суммирования остаточных блоков с компонента 88 обработки обратного преобразования с соответствующими блоками предсказания, сгенерированными компонентом 82 компенсации движения. Сумматор 90 представляет компонент или компоненты, которые выполняют эту операцию суммирования. Если желательно, также могут использоваться контурные фильтры (либо в контуре кодирования, либо после контура кодирования), чтобы сгладить пиксельные переходы или иным образом улучшить качество видео. Компонент 91 фильтрации предназначен для представления одного или более контурных фильтров, таких как фильтр деблокирования, адаптивный контурный фильтр (ALF) и фильтр адаптивного к выборке смещения (SAO). Хотя компонент 91 фильтрации показан на фиг. 3 как контурный фильтр, в других конфигурациях, компонент 91 фильтрации может быть реализован как пост-контурный фильтр. Декодированные видео блоки в данном кадре или картинке затем сохраняются в памяти 92 опорных картинок, которая хранит опорные картинки, используемые для последующей компенсации движения. Память 92 опорных картинок также хранит декодированное видео для последующего представления на устройстве отображения, таком как устройство 32 отображения на фиг. 1.
[0152] Видео декодер 30 по фиг. 3 представляет пример видео декодера, сконфигурированного, чтобы декодировать видеоданные, которые могут быть сохранены с использованием методов файлового формата, описанных в настоящем раскрытии.
[0153] Фиг. 4 является блок-схемой, иллюстрирующей примерный набор устройств, которые образуют часть сети 100. В этом примере, сеть 100 включает в себя маршрутизирующие устройства 104A, 104B (маршрутизирующие устройства 104) и устройство 106 транскодирования. Маршрутизирующие устройства 104 и устройство 106 транскодирования предназначены для представления небольшого числа устройств, которые могут формировать часть сети 100. Другие сетевые устройства, такие как коммутаторы, концентраторы, шлюзы, брандмауэры, мосты и другие такие устройства могут также быть включены в сеть 100. Кроме того, дополнительные сетевые устройства могут быть обеспечены вдоль сетевого канала между серверным устройством 102 и клиентским устройством 108. Серверное устройство 102 может соответствовать устройству-источнику 12 (фиг. 1), в то время как клиентское устройство 108 может соответствовать устройству-получателю 14 (фиг. 1), в некоторых примерах.
[0154] В общем, маршрутизирующие устройства 104 реализуют один или более протоколов маршрутизации, чтобы производить обмен сетевыми данными через сеть 100. В некоторых примерах, маршрутизирующие устройства 104 могут быть сконфигурированы, чтобы выполнять операции прокси и кэширования. Поэтому, в некоторых примерах, маршрутизирующие устройства 104 могут упоминаться как прокси-устройства. В общем, маршрутизирующие устройства 104 исполняют протоколы маршрутизации, чтобы обнаруживать маршруты через сеть 100. Путем выполнения таких протоколов маршрутизации, маршрутизирующее устройство 104B может определять сетевой маршрут от самого себя к серверному устройству 102 через маршрутизирующее устройство 104A.
[0155] Методы настоящего раскрытия могут быть реализованы сетевыми устройствами, такими как маршрутизирующие устройства 104 и устройство 106 транскодирования, но также могут быть реализованы клиентским устройством 108. Таким способом, маршрутизирующие устройства 104, устройство 106 транскодирования и клиентское устройство 108 представляют примеры устройств, сконфигурированных, чтобы выполнять методы настоящего раскрытия. Кроме того, устройства по фиг. 1 и кодер 20, показанный на фиг. 2, и декодер 30, показанный на фиг. 3, также являются примерами устройств, которые могут быть сконфигурированы, чтобы выполнять один или более методов настоящего раскрытия.
[0156] Фиг. 5 является концептуальной диаграммой, иллюстрирующей примерную структуру файла 300, в соответствии с одним или более методами настоящего раскрытия. В примере по фиг. 5, файл 300 включает в себя бокс 302 фильма и множество боксов 304 медиа данных. Хотя в примере по фиг. 5 они показаны как находящиеся в том же самом файле, в других примерах бокс 302 фильма 302 и бокс 304 медиа данных могут находиться в различных файлах. Как указано выше, бокс может быть объектно-ориентированным компоновочным блоком, определенным идентификатором уникального типа и длиной. Например, бокс может быть элементарной синтаксической структурой в ISOBMFF, включающей в себя четырех-символьный кодированный тип бокса, байтовый отсчет бокса и полезную нагрузку.
[0157] Бокс 302 фильма может содержать метаданные для треков файла 300. Каждый трек файла 300 может содержать непрерывный поток медиа данных. Каждый из боксов 304 медиа данных может включать в себя одну или более выборок 305. Каждая выборка 305 может содержать аудио или видео единицу доступа. Как описано в настоящем раскрытии, каждая единица доступа может содержать множество кодированных картинок в многовидовом кодировании (например, MV-HEVC и 3D-HEVC) и масштабируемом видео кодировании (например, SHVC). Например, единица доступа может включать в себя одну или более кодированных картинок для каждого уровня.
[0158] Кроме того, в примере по фиг. 5, бокс 302 фильма включает в себя бокс 306 трека. Бокс 306 трека может вмещать метаданные для трека файла 300. В других примерах, бокс 302 фильма может включать в себя множество боксов треков для различных треков файла 300. Бокс 306 трека включает в себя бокс 307 медиа. Бокс 307 медиа может содержать все объекты, которые декларируют информацию о медиа данных в треке. Бокс 307 медиа включает в себя бокс 308 медиа информации. Бокс 308 медиа информации может содержать все объекты, которые декларируют характеристическую информацию о медиа трека. Бокс 308 медиа информации включает в себя бокс 309 таблицы выборок. Бокс 309 таблицы выборок может специфицировать специфические для выборки метаданные.
[0159] В примере на фиг. 5, бокс 309 таблицы выборок включает в себя бокс 310 SampleToGroup и бокс 312 SampleGroupDescription. В других примерах, бокс 309 таблицы выборок может включать в себя другие боксы кроме бокса 310 SampleToGroup и бокса 312 SampleGroupDescription и/или может включать в себя множество боксов SampleToGroup и боксов SampleGroupDescription. Бокс 310 SampleToGroup может отображать выборки (например, конкретные из выборок 305) на группу выборок. Бокс 312 SampleGroupDescription может специфицировать свойство, совместно используемое выборками в группе выборок (т.е., группой выборок). Кроме того, бокс 309 таблицы выборок может включать в себя множество боксов 311 записей выборок. Каждый из боксов 311 записей выборок может соответствовать выборке в группе выборок. В некоторых примерах, боксы 311 записей выборок являются экземплярами класса записи произвольно доступной выборки, который расширяет базовый класс описания группы выборок, как определено в разделе 9.5.5.1.2 выше.
[0160] В соответствии с одним или более методами настоящего раскрытие, бокс 312 SampleGroupDescription может специфицировать, что каждая выборка группы выборок содержит по меньшей мере одну IRAP-картинку. Таким путем устройство 34 генерации файла может генерировать файл, который содержит бокс 306 трека, который содержит метаданные для трека в файле 300. Медиа данные для трека содержат последовательность выборок 305. Каждая из выборок может быть видео единицей доступа многоуровневых видеоданных (например, видеоданных SHVC, MV-HEVC или 3D-HEVC). Кроме того, как часть генерации файла 300, устройство 34 генерации файла может генерировать, в файле 300, дополнительный бокс (т.е., бокс 309 таблицы выборок), который документирует все выборки 305, содержащие по меньшей мере одну IRAP-картинку. Иными словами, дополнительный бокс идентифицирует все выборки 305, содержащие по меньшей мере одну IRAP-картинку. В примере на фиг. 5, дополнительный бокс определяет группу выборок, которая документирует (например, идентифицирует) все выборки 305, содержащие по меньшей мере одну IRAP-картинку. Иными словами, дополнительный бокс специфицирует, что выборки 305, содержащие по меньшей мере одну IRAP-картинку, принадлежат к группе выборок.
[0161] Кроме того, в соответствии с одним или более методами настоящего раскрытия, каждый из боксов 311 записей выборок может включать в себя значение (например, all_pics_are_IRAP), указывающее, являются ли все кодированные картинки в соответствующей выборке IRAP-картинками. В некоторых примерах, значение, равное 1, специфицирует, что не все кодированные картинки в выборке являются IRAP-картинками. Значение, равное 0, специфицирует, что не требуется, чтобы каждая кодированная картинка в каждой выборке группы выборок была IRAP-картинкой.
[0162] В некоторых примерах, если не все кодированные картинки в конкретной выборке являются IRAP-картинками, устройство 34 генерации файла может включать в себя, в одном из боксов 311 записи выборки для конкретной выборки, значение (например, num_IRAP_pics), указывающее число IRAP-картинок в конкретной выборке. Дополнительно, устройство 34 генерации файла может включать в себя, в записи выборки для конкретной выборки, значения, указывающие идентификаторы уровней IRAP-картинок в конкретной выборке. Устройство 34 генерации файла может также включать в себя, в записи выборки для конкретной выборки, значение, указывающее тип NAL-единицы для VCL NAL-единиц в IRAP-картинке конкретной выборки.
[0163] Кроме того, в примере на фиг. 5, бокс 309 таблицы выборок включает в себя бокс 314 информации подвыборки. Хотя в примере на фиг. 5 показан только один бокс информации подвыборки, бокс 309 таблицы выборок может включать в себя множество боксов информации подвыборок. В общем, бокс информации подвыборки предназначен для того, чтобы содержать информацию о подвыборке. Подвыборка является непрерывным интервалом байтов выборки. ISO/IEC 14496-12 указывает, что конкретное определение подвыборки должно быть обеспечено для данной системы кодирования, такой как H.264/AVC или HEVC.
[0164] Раздел 8.4.8 ISO/IEC 14496-15 специфицирует определение подвыборки для HEVC. В частности, раздел 8.4.8 ISO/IEC 14496-15 специфицирует, что для использования бокса информации подвыборки (8.7.7 в ISO/IEC 14496-12) в потоке HEVC, подвыборка определяется на основе значения поля флагов бокса информации подвыборки. В соответствии с одним или более методами настоящего раскрытия, если поле флагов в боксе 314 информации подвыборки равно 5, подвыборка, соответствующая боксу 314 информации подвыборки, содержит одну кодированную картинку и ассоциированные не-VCL NAL-единицы. Ассоциированные не-VCL NAL-единицы могут включать в себя NAL-единицы, содержащие SEI-сообщения, применимые к кодированной картинке, и NAL-единицы, содержащие наборы параметров (например, VPS, SPS, PPS и т.д.), применимые к кодированной картинке.
[0165] Таким образом, в одном примере, устройство 34 генерации файла может генерировать файл (например, файл 300) который содержит бокс трека (например, бокс 306 трека), который содержит метаданные для трека в файле. В этом примере, медиа данные для трека содержат последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных (например, видеоданных SHVC, MV-HEVC или 3D-HEVC). Кроме того, в этом примере, в качестве части генерации файла устройством 34 генерации файла, устройство 34 генерации файла может генерировать, в файле, бокс информации подвыборки (например, бокс 314 информации подвыборки), который содержит флаги, которые специфицируют тип информации подвыборки, заданный в боксе информации подвыборки. Когда флаги имеют конкретное значение, подвыборка, соответствующая боксу информации подвыборки, содержит точно одну кодированную картинку и нуль или более не-VCL NAL-единиц, ассоциированных с кодированной картинкой.
[0166] Кроме того, в соответствии с одним или более методами настоящего раскрытия, если поле флагов бокса 314 информации подвыборки равно 0, бокс 314 информации подвыборки дополнительно включает в себя значение DiscardableFlag, значение NoInterLayerPredFlag, значение LayerId и значение TempId. Если поле флагов бокса 314 информации подвыборки равно 5, бокс 314 информации подвыборки может включать в себя значение DiscardableFlag, значение VclNalUnitType, значение LayerId, значение TempId, значение NoInterLayerPredFlag, значение SubLayerRefNalUnitFlag и зарезервированное значение.
[0167] SubLayerRefNalUnitFlag, равный 0, указывает, что все NAL-единицы в подвыборке являются VCL NAL-единицами не опорной картинки подуровня, как специфицировано в ISO/IEC 23008-2 (т.е., HEVC). SubLayerRefNalUnitFlag равный 1, указывает, что все NAL-единицы в подвыборке являются VCL NAL-единицами опорной картинки подуровня, как специфицировано в ISO/IEC 23008-2 (т.е., HEVC). Таким образом, когда устройство 34 генерации файла генерирует бокс 314 информации подвыборки, и флаги имеют конкретное значение (например, 5), устройство 34 генерации файла включает, в бокс 314 информации подвыборки, дополнительный флаг, который указывает, являются ли все NAL-единицы в подвыборке VCL NAL-единицами не опорной картинки подуровня.
[0168] Значение DiscardableFlag указывает значение discardable_flag VCL NAL-единиц в подвыборке. Как специфицировано в разделе A.4 ISO/IEC 14496-15, значение discardable_flag должно быть установлено в 1, если и только если все извлеченные и агрегированные NAL-единицы имеют discardable_flag, установленный в 1 и установленный в 0 в противном случае. NAL-единица может иметь discardable_flag, установленный в 1, если битовый поток, содержащий NAL-единицу, может быть корректно декодирован без NAL-единицы. Таким образом, NAL-единица может быть ʺотбрасываемойʺ, если битовый поток, содержащий NAL-единицу, может быть корректно декодирован без NAL-единицы. Все VCL NAL-единицы в подвыборке должны иметь то же самое значение discardable_flag. Таким образом, когда устройство 34 генерации файла генерирует бокс 314 информации подвыборки, и флаги имеют конкретное значение (например, 5), устройство 34 генерации файла включает, в бокс 314 информации подвыборки, дополнительный флаг (например, discardable_flag), который указывает, являются ли все из VCL NAL-единиц подвыборки отбрасываемыми.
[0169] Значение NoInterLayerPredFlag указывает значение inter_layer_pred_enabled_flag VCL NAL-единиц в подвыборке. inter_layer_pred_enabled_flag должен быть установлен в 1, если и только если все извлеченные или агрегированные VCL NAL-единицы имеют inter_layer_pred_enabled_flag, установленный в 1 и установленный в 0 в противном случае. Все VCL NAL-единицы в подвыборке должны иметь то же самое значение inter_layer_pred_enabled_flag. Таким образом, когда устройство 34 генерации файла генерирует бокс 314 информации подвыборки, и флаги имеют конкретное значение (например, 5), устройство 34 генерации файла включает, в бокс 314 информации подвыборки, дополнительное значение (например, inter_layer_pred_enabled_flag), которое указывает, разрешено ли межуровневое предсказание для всех VCL NAL-единиц подвыборки.
[0170] LayerId указывает значение nuh_layer_id NAL-единиц в подвыборке. Все NAL-единицы в подвыборке должны иметь то же самое значение nuh_layer_id. Таким образом, когда устройство 34 генерации файла генерирует бокс 314 информации подвыборки, и флаги имеют конкретное значение (например, 5), устройство 34 генерации файла включает, в бокс 314 информации подвыборки, дополнительное значение (например, LayerId), которое указывает идентификатор уровня каждой NAL-единицы подвыборки.
[0171] TempId указывает значение TemporalId NAL-единиц в подвыборке. Все NAL-единицы в подвыборке должны иметь то же самое значение TemporalId. Таким образом, когда устройство 34 генерации файла генерирует бокс 314 информации подвыборки, и флаги имеют конкретное значение (например, 5), устройство 34 генерации файла включает, в бокс 314 информации подвыборки, дополнительное значение (например, TempId), которое указывает временной идентификатор каждой NAL-единицы подвыборки.
[0172] VclNalUnitType указывает синтаксический элемент nal_unit_type VCL NAL-единиц в подвыборке. Синтаксический элемент nal_unit_type является синтаксическим элементом в заголовке NAL-единицы соответствующей NAL-единицы. Синтаксический элемент nal_unit_type специфицирует тип RBSP, содержащейся в NAL-единице. Все VCL NAL-единицы nal_unit_type в подвыборке должны иметь то же самое значение nal_unit_type. Таким образом, когда устройство 34 генерации файла генерирует бокс 314 информации подвыборки, и флаги имеют конкретное значение (например, 5), устройство 34 генерации файла включает, в бокс 314 информации подвыборки, дополнительное значение (например, VclNalUnitType), которое указывает тип NAL-единицы для VCL NAL-единиц подвыборки. Все VCL NAL-единицы подвыборки имеют тот же самый тип NAL-единицы.
[0173] Фиг. 6 является концептуальной диаграммой, иллюстрирующей примерную структуру файла 300, в соответствии с одним или более методами настоящего раскрытия. Как специфицировано в разделе 8.4.9 ISO/IEC 14496-15, HEVC допускает выборки файлового формата, которые используются только для ссылки, но не вывода. Например, HEVC допускает неотображаемую опорную картинку в видео.
[0174] Кроме того, секция 8.4.9 ISO/IEC 14496-15 специфицирует, что когда любая такая не выводимая выборка присутствует в треке, файл должен быть ограничен следующим образом.
1. Не выводимой выборке должно задаваться время композиции, которое находится вне временного диапазона выборок, которые выводятся.
2. Список редактирования должен использоваться, чтобы исключать времена композиции не выводимых выборок.
3. Когда трек включает в себя CompositionOffsetBox (ʹcttsʹ),
a. версия 1 CompositionOffsetBox должна использоваться
b. значение sample_offset должно быть установлено равным -231 для каждой не выводимой выборки.
c. CompositionToDecodeBox (ʹcslgʹ) должен содержаться в SampleTableBox (ʹstblʹ) трека, и
d. когда CompositionToDecodeBox присутствует для трека, значение поля leastDecodeToDisplayDelta в боксе должно быть равно наименьшему смещению композиции в CompositionOffsetBox, исключающем значения sample_offset для не выводимых выборок.
Примечание. Таким образом, leastDecodeToDisplayDelta больше, чем -231.
[0175] Как специфицировано в ISO/IEC 14496-12, CompositionOffsetBox обеспечивает смещение между временем декодирования и временем композиции. CompositionOffsetBox включает в себя набор значений sample_offset. Каждое из значений sample_offset является неотрицательным целым числом, которое задает смещение между временем композиции и временем декодирования. Время композиции относится к времени, в которое выборка должна выводиться. Время декодирования относится к времени, в которое выборка должна декодироваться.
[0176] Как указано выше, NAL-единица кодированной вырезки может включать в себя заголовок сегмента вырезки. Заголовок сегмента вырезки может быть частью сегмента кодированной вырезки и может содержать элементы данных, относящиеся к первой или всем CTU в сегменте вырезки. В HEVC, заголовок сегмента вырезки включает в себя синтаксический элемент pic_output_flag. В общем, синтаксический элемент pic_output_flag включен в заголовок первого сегмента вырезки картинки. Таким образом, настоящее раскрытие может ссылаться на pic_output_flag заголовка первого сегмента вырезки картинки в качестве pic_output_flag картинки.
[0177] Как специфицировано в разделе 7.4.7.1 HEVC WD, синтаксический элемент pic_output_flag влияет на процессы вывода и удаления декодированной картинки, как специфицировано в Приложении C к HEVC WD. В общем, если синтаксический элемент pic_output_flag заголовка сегмента вырезки для сегмента вырезки равен 1, то выводится картинка, которая включает в себя вырезку, соответствующую заголовку сегмента вырезки. В противном случае, если синтаксический элемент pic_output_flag заголовка сегмента вырезки для сегмента вырезки равен 0, то картинка, которая включает в себя вырезку, соответствующую заголовку сегмента вырезки, может быть декодирована для использования в качестве опорной картинки, но не выводится.
[0178] В соответствии с одним или более методами настоящего раскрытия, ссылки в разделе 8.4.9 ISO/IEC 14496-15 на HEVC могут быть заменены соответствующими ссылками на SHVC, MV-HEVC или 3D-HEVC. Кроме того, в соответствии с одним или более методами настоящего раскрытия, когда единица доступа содержит некоторые кодированные картинки, которые имеют pic_output_flag, равный 1, и некоторые другие кодированные картинки, которые имеют pic_output_flag, равный 0, по меньшей мере два трека должны использоваться для сохранения потока. Для каждого соответствующего одного из треков, все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение pic_output_flag. Таким образом, все кодированные картинки в первом одном из треков имеют pic_output_flag, равный 0, и все кодированные картинки во втором одном из треков имеют pic_output_flag, равный 1.
[0179] Соответственно, в примере на фиг. 6, устройство 34 генерации файла может генерировать файл 400. Подобно файлу 300 в примере на фиг. 5, файл 400 включает в себя бокс 402 фильма и один или более боксов 404 медиа данных. Каждый из боксов 404 медиа данных может соответствовать различному треку файла 400. Бокс 402 фильма может содержать метаданные для треков файла 400. Каждый трек файла 400 может содержать непрерывный поток медиа данных. Каждый из боксов 404 медиа данных может включать в себя одну или более выборок 405. Каждая выборка 405 может содержать аудио и видео единицы доступа.
[0180] Как указано выше, в некоторых примерах, когда единица доступа содержит некоторые кодированные картинки, которые имеют pic_output_flag, равный 1, и некоторые другие кодированные картинки, которые имеют pic_output_flag, равный 0, по меньшей мере два трека должны быть использованы для сохранения потока. Соответственно, в примере на фиг. 6, бокс 402 фильма включает в себя бокс 406 трека и бокс 408 трека. Каждый из боксов 406 и 408 треков вмещает метаданные для различного трека файла 400. Например, бокс 406 трека может вмещать метаданные для трека, имеющего кодированные картинки с pic_output_flag, равным 0, и ни одной картинки с pic_output_flag, равным 1. Бокс 408 трека может вмещать метаданные для трека, имеющего кодированные картинки с pic_output_flag, равным 1, и ни одной картинки с pic_output_flag, равным 0.
[0181] Таким образом, в одном примере, устройство 34 генерации файла может генерировать файл (например, файл 400), который содержит бокс медиа данных (например, бокс 404 медиа данных), который вмещает (например, содержит) медиа контент. Медиа контент содержит последовательность выборок (например, выборки 405). Каждая из выборок может быть единицей доступа многоуровневых видеоданных. В этом примере, когда устройство 34 генерации файла генерирует файл, в ответ на определение, что по меньшей мере одна единица доступа битового потока включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный 1, и кодированную картинку, которая имеет флаг вывода картинки, равный 0, устройство 34 генерации файла может использовать по меньшей мере два трека для сохранения битового потока в файле. Для каждого соответствующего трека из по меньшей мере двух треков, все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки. Картинки, имеющие флаг вывода картинки, равный 1, могут быть выведены, а картинки, имеющие флаг вывода картинки, равный 0, могут быть использованы как опорные картинки, но не могут быть выведены.
[0182] Фиг. 7 является блок-схемой последовательности действий, иллюстрирующей примерную работу устройства 34 генерации файла, в соответствии с одним или более методами настоящего раскрытия. Операция в соответствии с фиг. 7, вместе с операциями, иллюстрируемыми на других блок-схемах последовательностей действий настоящего раскрытия, приведены в качестве примеров. Другие примерные операции в соответствии с методами настоящего раскрытия могут включать в себя больше или меньше действий, или другие действия.
[0183] В примере на фиг. 7, устройство 34 генерации файла генерирует файл (500). В качестве части генерации файла, устройство 34 генерации файла генерирует бокс трека, который содержит метаданные для трека в файле (502). Таким путем, устройство 34 генерации файла генерирует файл, который содержит бокс трека, который содержит метаданные для трека в файле. Медиа данные для трека содержат последовательность выборок. Каждая из выборок является видео единицей доступа многоуровневых видеоданных. В некоторых примерах, устройство 34 генерации файла кодирует многоуровневые видеоданные.
[0184] Кроме того, в качестве части генерации файла, устройство 34 генерации файла идентифицирует все из выборок, которые содержат по меньшей мере одну IRAP-картинку (504). Кроме того, устройство 34 генерации файла может генерировать, в файле, дополнительный бокс, который документирует все выборки, содержащие по меньшей мере одну IRAP-картинку (506). В некоторых примерах, дополнительный бокс является новым боксом, который не определен в ISOBMFF или его существующих расширениях. В некоторых примерах, дополнительный бокс определяет группу выборок, которая документирует все из выборок, содержащих по меньшей мере одну IRAP-картинку. Например, дополнительный бокс может быть или содержать бокс таблицы выборок, который включает в себя бокс SampleToGroup и бокс SampleGroupDescription. Бокс SampleToGroup идентифицирует выборки, которые содержат по меньшей мере одну IRAP-картинку. Бокс SampleGroupDescription указывает, что группа выборок является группой выборок, содержащих по меньшей мере одну IRAP-картинку.
[0185] Кроме того, в примере на фиг. 7, устройство 34 генерации файла может генерировать запись выборки для конкретной одной из выборок, которая включает в себя по меньшей мере одну IRAP-картинку (508). В некоторых примерах, устройство 34 генерации файла может генерировать запись выборки для каждой соответствующей одной из выборок, которая включает в себя по меньшей мере одну IRAP-картинку. Запись выборки может быть RandomAccessibleSampleEntry, как определено в разделе 9.5.5.1.2 выше.
[0186] Как иллюстрируется в примере на фиг. 7, в качестве части генерации записи выборки для конкретной выборки, устройство 34 генерации файла может включать, в запись выборки для конкретной выборки, значение, указывающее, являются ли все кодированные картинки в конкретной выборке IRAP-картинками (510). Таким путем, устройство 34 генерации файла может генерировать, в файле, запись выборки, которая включает в себя значение, указывающее, являются ли все кодированные картинки в конкретной выборке в последовательности выборок IRAP-картинками. Кроме того, устройство 34 генерации файла может включать, в запись выборки для конкретной выборки, значение, указывающее тип NAL-единицы для VCL NAL-единиц в IRAP-картинках конкретной выборки (512).
[0187] Кроме того, устройство 34 генерации файла может определять, являются ли все кодированные картинки в конкретной выборке IRAP-картинками (514). Если не все кодированные картинки в конкретной выборке являются IRAP картинками (ʺНетʺ в 514), устройство 34 генерации файла может включать, в запись выборки для конкретной выборки, значение, указывающее количество IRAP-картинок в конкретной выборке (516). Дополнительно, устройство 34 генерации файла может включать, в запись выборки для конкретной выборки, значения, указывающие идентификаторы уровня (например, nuh_layer_id) IRAP-картинок в конкретной выборке.
[0188] Как указано выше, фиг. 7 приведена в качестве примера. Другие примеры не включают каждое действие согласно фиг. 7. Например, некоторые примеры исключают этапы 502, 504 и 508. Кроме того, некоторые примеры исключают другие из этапов 510-518. Более того, некоторые примеры включают одно или более дополнительных действий. Например, некоторые примеры включают дополнительное действие генерации, в качестве части генерации файла, бокса синхронизации выборки, который включает в себя таблицу синхро-выборок, которая документирует синхро-выборки трека многоуровневых видеоданных. Каждая синхро-выборка трека является выборкой произвольного доступа трека. В этом примере, выборка масштабируемого видео кодирования является синхро-выборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой. Кроме того, в этом примере, выборка многовидового видео кодирования является синхро-выборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой без RASL-картинок.
[0189] Фиг. 8 является блок-схемой последовательности действий, иллюстрирующей примерную операцию, в которой вычислительное устройство выполняет произвольный доступ и/или переключение уровня, в соответствии с одним или более методами настоящего раскрытия. В примере на фиг. 8, вычислительное устройство принимает файл (550). В примере на фиг. 8, вычислительное устройство может быть промежуточным сетевым устройством (например, MANE, сервером потоковой передачи), устройством декодирования (например, устройством-получателем 14) или другим типом видео устройства. В некоторых примерах, вычислительное устройство может быть частью сети доставки контента.
[0190] В примере на фиг. 8, вычислительное устройство может получать, из файла, бокс трека, который содержит метаданные для трека в файле (552). Медиа данные для трека содержат последовательность выборок. В примере на фиг. 8, каждая из выборок является видео единицей доступа многоуровневых видеоданных.
[0191] Кроме того, в примере на фиг. 8, вычислительное устройство может получать дополнительный бокс из файла (554). Дополнительный бокс документирует все выборки, содержащие по меньшей мере одну IRAP-картинку. Таким образом, вычислительное устройство может определять, на основе информации в дополнительном боксе, все выборки, содержащие по меньшей мере одну IRAP-картинку (556).
[0192] Кроме того, в некоторых примерах, вычислительное устройство может получать, из файла, запись выборки, которая включает в себя значение, указывающее, являются ли все кодированные картинки в конкретной выборке в последовательности выборок IRAP-картинками. Если не все кодированные картинки в конкретной выборке являются IRAP-картинками, вычислительное устройство может получать, из записи выборки, значение, указывающее, количество IRAP-картинок в конкретной выборке. Дополнительно, вычислительное устройство может получать, из записи выборки, значения, указывающие идентификаторы уровня IRAP-картинок в конкретной выборке. Кроме того, в некоторых примерах, вычислительное устройство может получать, из записи выборки, значение, указывающее тип NAL-единицы для VCL NAL-единиц в IRAP-картинках конкретной выборки. Дополнительно, в некоторых примерах, вычислительное устройство может получать, из файла, бокс синхро-выборки, который включает в себя таблицу синхро-выборок, которая документирует синхро-выборки трека видеоданных. В таких примерах, каждая синхро-выборка трека является выборкой произвольного доступа трека, выборка масштабируемого видео кодирования является синхро-выборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой, и выборка многовидового видео кодирования является синхро-выборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой без RASL-картинок.
[0193] Дополнительно, в примере на фиг. 8, вычислительное устройство может запускать пересылку или декодирование NAL- единиц выборки, содержащей по меньшей мере одну IRAP-картинку, без пересылки или декодирования NAL-единиц файла сначала в порядке декодирования в выборку (558). Таким путем, вычислительное устройство может выполнять произвольный доступ или переключение уровня. Например, вычислительное устройство может начать декодирование многоуровневых видеоданных в одной из одной или более выборок, содержащих по меньшей мере одну IRAP-картинку.
[0194] Фиг. 9 является блок-схемой последовательности действий, иллюстрирующей примерную работу устройства 34 генерации файла, в соответствии с одним или более методами настоящего раскрытия. В примере на фиг. 9, устройство 34 генерации файла может генерировать файл, который содержит бокс трека, который содержит метаданные для трека в файле (600). Медиа данные для трека содержат последовательность выборок. В примере на фиг. 9, каждая из выборок является видео единицей доступа многоуровневых видеоданных. В некоторых примерах, устройство 34 генерации файла кодирует многоуровневые видеоданные.
[0195] В качестве части генерации файла, устройство 34 генерации файла может определять, содержит ли подвыборка содержит точно одну кодированную картинку и нуль или более не-VCL NAL-единиц, ассоциированных с кодированной картинкой (602). В ответ на определение, что подвыборка содержит точно одну кодированную картинку и нуль или более не-VCL NAL-единиц, ассоциированных с кодированной картинкой (ʺДаʺ в 602), устройство 34 генерации файла может генерировать, в файле, бокс информации подвыборки, который содержит флаги, которые имеют значение (например, 5), указывающее, что подвыборка содержит точно одну кодированную картинку и нуль или более не-VCL NAL-единиц, ассоциированных с кодированной картинкой (604). В противном случае (ʺНетʺ в 602), устройство 34 генерации файла может генерировать, в файле, бокс информации подвыборки, который содержит флаги, имеющие другое значение (например, 0, 1, 2, 3, 4) (606).
[0196] Таким путем, устройство 34 генерации файла может генерировать файл, который содержит бокс трека, который содержит метаданные для трека в файле. Медиа данные для трека содержат последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных. В качестве части генерации файла, устройство 34 генерации файла генерирует, в файле, бокс информации подвыборки, который содержит флаги, которые специфицируют тип информации подвыборки, заданной в боксе информации подвыборки. Когда флаги имеют конкретное значение, подвыборка, соответствующая боксу информации подвыборки, содержит точно одну кодированную картинку и нуль или более не-VCL NAL-единиц, ассоциированных с кодированной картинкой.
[0197] Фиг. 10 является блок-схемой последовательности действий, иллюстрирующей примерную работу вычислительного устройства, в соответствии с одним или более методами настоящего раскрытия. В примере на фиг. 10, вычислительное устройство принимает файл (650). В примере на фиг. 10, вычислительное устройство может быть промежуточным сетевым устройством, таким как MANE или сервер потоковой передачи. В некоторых примерах, вычислительное устройство может быть частью сети доставки контента. Кроме того, в примере по фиг. 10, вычислительное устройство может получать бокс трека из файла (651). Бокс трека содержит метаданные для трека в файле. Медиа данные для трека содержат последовательность выборок. В примере на фиг. 10, каждая из выборок является видео единицей доступа многоуровневых видеоданных.
[0198] Кроме того, в примере на фиг. 10, вычислительное устройство может получать бокс информации подвыборки из файла (652). Вычислительное устройство использует информацию в боксе информации подвыборки, чтобы извлекать суб-битовый поток (654). Суб-битовый поток может содержать каждую NAL-единицу рабочей точки битового потока, сохраненного в файле. Иными словами, NAL-единицы суб-битового потока могут быть поднабором NAL-единиц, сохраненных в файле. Вычислительное устройство может получать бокс информации подвыборки из файла и может извлекать суб-битовый поток без синтаксического анализа и интерпретации NAL-единиц, включенных в последовательность выборок. Исключение синтаксического анализа или интерпретации NAL-единиц при извлечении суб-битового потока может снизить сложность вычислительного устройства и/или может ускорить процесс извлечения суб-битового потока.
[0199] Кроме того, в некоторых примерах, вычислительное устройство может получать, когда флаги имеют конкретное значение, из бокса информации подвыборки, одно или более из следующего:
- дополнительный флаг, который указывает, являются ли отбрасываемыми все из VCL NAL-единиц подвыборки,
- дополнительное значение, которое указывает тип NAL-единицы для VCL NAL-единиц подвыборки, причем все VCL NAL-единицы подвыборки имеют тот же самый тип NAL-единицы,
- дополнительное значение, которое указывает идентификатор уровня каждой NAL-единицы подвыборки,
- дополнительное значение, которое указывает временной идентификатор каждой NAL-единицы подвыборки,
- дополнительный флаг, который указывает, разрешено ли межуровневое предсказание для всех VCL NAL-единиц подвыборки, или
- дополнительный флаг, который указывает, являются ли все NAL-единицы в подвыборке VCL NAL-единицами не опорной картинки подуровня.
[0200] В примере на фиг. 10, в качестве части извлечения суб-битового потока, вычислительное устройство может определять, имеет ли значение ʺflagsʺ бокса информации подвыборки конкретное значение (например, 5), указывающее, что бокс информации подвыборки соответствует точно одной кодированной картинке и нулю или более не-VCL NAL-единицам, ассоциированным с кодированной картинкой (656). Когда значение ʺflagsʺ бокса информации подвыборки имеет конкретное значение (ʺДаʺ в 656), вычислительное устройство может определять, на основе информации, специфицированной в боксе информации подвыборки, требуется ли кодированная картинка, чтобы декодировать рабочую точку (658). Например, вычислительное устройство может определять, на основе флага отбрасывания, указателя типа VCL NAL-единицы, идентификатора уровня, временного идентификатора, флага отсутствия межуровневого предсказания и/или флага опорной NAL-единицы подуровня, требуется ли кодированная картинка, чтобы декодировать рабочую точку. Если кодированная картинка требуется, чтобы декодировать рабочую точку (ʺДаʺ в 658), вычислительное устройство может включать NAL-единицы подвыборки в суб-битовый поток (660). В противном случае, в примере на фиг. 10, если кодированная картинка не требуется, чтобы декодировать рабочую точку (ʺНетʺ в 658), вычислительное устройство не включает NAL-единицы подвыборки в суб-битовый поток (662).
[0201] Кроме того, в примере на фиг. 10, вычислительное устройство может выводить суб-битовый поток (664). Например, вычислительное устройство может сохранить суб-битовый поток на считываемом компьютером носителе или передать суб-битовый поток на другое вычислительное устройство.
[0202] Как указано выше, фиг. 10 является примером. Другие примеры могут включать в себя или опускать конкретные действия, показанные на фиг. 10. Например, некоторые примеры опускают действия 650, 651, 654 и/или 664. Кроме того, некоторые примеры опускают действия из одного или более действий 656-662.
[0203] Фиг. 11 является блок-схемой последовательности действий, иллюстрирующей примерную работу устройства 34 генерации файла, в соответствии с одним или более методами настоящего раскрытия. В примере на фиг. 11, устройство 34 генерации файла может генерировать файл, который содержит бокс медиа данных, который вмещает медиа контент (700). Медиа контент может содержать последовательность выборок, причем каждая из выборок является единицей доступа многоуровневых видеоданных. В различных примерах, многоуровневые видеоданные могут быть данными SHVC, данными MV-HEVC или данными 3D-HEVC. В некоторых примерах, устройство 34 генерации файла кодирует многоуровневые видеоданные.
[0204] В примере на фиг. 11, в качестве части генерации файла, устройство 34 генерации файла может определять, включает ли по меньшей мере одна единица доступа битового потока многоуровневых видеоданных кодированную картинку, которая имеет флаг вывода картинки, равный первому значению (например, 1), и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению (например, 0) (702). Картинки, имеющие флаги вывода картинки, равные первому значению (например, 1), разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению (например, 0), разрешены для использования в качестве опорных картинок, но не разрешены для вывода. В других примерах, другие устройства могут определять, включает ли по меньшей мере одна единица доступа битового потока многоуровневых видеоданных кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению.
[0205] В ответ на определение, что по меньшей мере одна единица доступа битового потока многоуровневых видеоданных включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению (ʺДаʺ в 702), устройство 34 генерации файла использует по меньшей мере первый трек и второй трек, чтобы сохранять битовый поток в файле (704). Для каждого соответствующего трека из первого и второго треков, все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки.
[0206] Кроме того, в примере на фиг. 11, в ответ на определение, что никакая единица доступа битового потока не включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению (например, 1), и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению (например, 0) (ʺНетʺ в 702), устройство 34 генерации файла может использовать один трек, чтобы сохранять битовый поток в файле (706). В других примерах, устройство 34 генерации файла может генерировать файл с множеством треков, даже если ни одна единица доступа битового потока не включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению (например, 1), и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению (например, 0).
[0207] Как указано выше, фиг. 11 является примером. Другие примеры могут включать в себя меньше действий. Например, некоторые примеры опускают действия 702 и 706.
[0208] Фиг. 12 является блок-схемой последовательности действий, иллюстрирующей примерную работу устройства-получателя 14, в соответствии с одним или более методами настоящего раскрытия. В примере на фиг. 12, устройство-получатель 14 принимает файл (750). Файл может содержать бокс медиа данных, который вмещает медиа контент, причем медиа контент содержит последовательность выборок. Каждая из выборок может быть единицей доступа многоуровневых видеоданных. В различных примерах, многоуровневые видеоданных могут быть данными SHVC, данными MV-HEVC или данными 3D-HEVC. Кроме того, в примере на фиг. 12, устройство-получатель 14 может получать, из файла, бокс первого трека и бокс второго трека (751). Бокс первого трека содержит метаданные для первого трека в файле. Бокс второго трека содержит метаданные для второго трека в файле. Для каждого соответствующего трека из первого трека и второго трека, все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки. Картинки, имеющие флаги вывода картинки, равные первому значению (например, 1), разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению (например, 0), разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
[0209] Видео декодер 30 устройства-получателя 14 может декодировать картинки в треке для картинок с флагами вывода картинки, равными первому значению (например, 1), и может декодировать картинки в треке для картинок с флагами вывода картинки, равными второму значению (например, 0) (752). В некоторых случаях, видео декодер 30 может использовать картинки с флагами вывода картинки, равными 1, чтобы декодировать картинки с флагами вывода картинки, равными 0, и наоборот. Устройство-получатель 14 может выводить картинки с флагами вывода картинки, равными первому значению (754). Устройство-получатель 14 не выводит картинки с флагами вывода картинки, равными второму значению (756). Таким путем, для каждого соответствующего трека из первого и второго трека, устройство-получатель 14 может декодировать кодированные картинки в каждой выборке соответствующего трека и выводить декодированные картинки, имеющие флаги вывода картинки, равные первому значению.
[0210] Как указано выше, фиг. 12 приведена в качестве примера. Другие примеры могут опускать конкретные действия на фиг. 12, такие как действия 752-756.
[0211] В одном или более примерах, описанные функции могут быть реализованы в аппаратных средствах, программном обеспечении, программно-аппаратных средствах или любой их комбинации. При реализации в программном обеспечении, функции могут быть сохранены или могут передаваться, как одна или более инструкций или код, посредством считываемого компьютером носителя и исполняться основанным на аппаратных средствах блоком обработки. Считываемые компьютером носители могут включать в себя считываемые компьютером носители хранения данных, которые соответствуют материальному носителю, такому как носители хранения данных, или коммуникационным средам, включающим в себя любую среду, которая способствует переносу компьютерной программы с одного места в другое, например, в соответствии с коммуникационным протоколом. Таким образом, считываемые компьютером среды могут, в общем, соответствовать: (1) материальным считываемым компьютером носителям хранения данных, которые являются нетранзиторными (невременными) или (2) коммуникационной среде, такой как сигнал или несущая волна. Носители хранения данных могут быть любыми доступными носителями, к которым могут получать доступ один или более компьютеров или один или более процессоров для извлечения инструкций, кода и/или структур данных для реализации методов, описанных в настоящем раскрытии. Компьютерный программный продукт может включать в себя считываемый компьютером носитель.
[0212] В качестве примера, но не ограничения, такие считываемые компьютером носители хранения данных могут содержать RAM, ROM, EEPROM, CD-ROM или другие запоминающие устройства на оптических дисках, запоминающие устройства на магнитных дисках, или другие магнитные устройства памяти, флэш-память или любой другой носитель, который может использоваться для хранения желательного программного кода в форме инструкций или структур данных и к которому может получать доступ компьютер. Также любое соединение может надлежащим образом определяться как считываемый компьютером носитель. Например, если инструкции передаются с веб-сайта, сервера или из другого удаленного источника с использованием коаксиального кабеля, волoконно-оптического кабеля, скрученной пары, цифровой абонентской линии (DSL) или беспроводных технологий, таких как инфракрасная, радио и микроволновая, то коаксиальный кабель, волoконно-оптический кабель, скрученная пара, DSL или беспроводные технологии, такие как инфракрасная, радио и микроволновая, включаются в определение носителя. Однако должно быть понятно, что считываемые компьютером носители и носители хранения данных не включают в себя соединения, несущие волны и сигналы и другие переходные (непостоянные) среды, но вместо этого направлены на невременные, материальные носители хранения данных. Магнитный диск (disk) и оптический диск (disc), как используется здесь, включают в себя компакт-диск (CD), лазерный диск, оптический диск, цифровой многофункциональный диск (DVD), гибкий диск и Blu-ray диск, где магнитные диски обычно воспроизводят данные магнитным способом, а оптические диски воспроизводят данные оптически посредством лазеров. Комбинации вышеуказанного также должны быть включены в объем считываемых компьютером носителей.
[0213] Инструкции могут исполняться одним или более процессорами, такими как один или более процессоров цифровых сигналов (DSP), микропроцессоры общего назначения, специализированные интегральные схемы (ASIC), программируемые логические матрицы (FPGA) или другие эквивалентные интегральные или дискретные логические схемы. Соответственно, термин ʺпроцессорʺ, как используется здесь, может относиться к любой из вышеуказанных структур или любой другой структуре, пригодной для реализации методов, описанных здесь. Кроме того, в некоторых аспектах, функциональность, описанная здесь, может быть обеспечена в специализированных аппаратных и/или программных модулях, сконфигурированных для кодирования и декодирования или встроенных в комбинированный кодек. Таким образом, методы могут быть полностью реализованы в одной или более схемах или логических элементах.
[0214] Методы настоящего раскрытия могут быть реализованы в широком спектре приборов или устройств, включая беспроводную трубку, интегральную схему (IC) или набор IC (например, набор микросхем). Различные компоненты, модули или блоки описаны в настоящем раскрытии, чтобы подчеркнуть функциональные аспекты устройств, сконфигурированных, чтобы выполнять раскрытые методы, но не обязательно требуют реализации различными блоками аппаратных средств. Напротив, как описано выше, различные блоки могут быть скомбинированы в блок аппаратных средств кодека или обеспечиваться совокупностью взаимодействующих блоков аппаратных средств, включая один или более процессоров, как описано выше, во взаимосвязи с соответствующим программным обеспечением и/или программно-аппаратными средствами.
[0215] Были описаны различные примеры. Эти и другие примеры находятся в пределах объема следующей формулы изобретения.
Claims (148)
1. Способ обработки многоуровневых видеоданных, причем способ содержит:
генерацию файла, который содержит бокс трека, который содержит метаданные для трека в файле, при этом:
медиаданные для трека содержат последовательность выборок, каждая из выборок является видеоединицей доступа из множества видеоединиц доступа многоуровневых видеоданных, и
генерация файла содержит определение, в файле, группы выборок, которая документирует все из выборок, содержащих по меньшей мере одну картинку внутренней точки произвольного доступа (IRAP), при этом:
группа выборок определена, чтобы включать запись группы выборок, которая включает в себя:
значение, указывающее, все ли кодированные картинки в конкретной выборке в последовательности выборок являются IRAP-картинками,
значение, указывающее число IRAP-картинок в конкретной выборке, и
значения, указывающие идентификаторы уровня IRAP-картинок в конкретной выборке, и
при этом по меньшей мере одна из видеоединиц доступа в сгенерированном файле содержит IRAP-картинку в базовом уровне, а также содержит одну или более не-IRAP-картинок в других уровнях.
2. Способ по п. 1, в котором генерация файла содержит:
включение, в запись группы выборок, значения, указывающего тип единицы уровня сетевой абстракции (NAL) для NAL-единиц уровня видеокодирования (VCL) в IRAP-картинках конкретной выборки.
3. Способ по п. 1, в котором:
генерация файла содержит генерацию, в файле, бокса синхровыборки, который включает в себя таблицу синхровыборок, которая документирует синхровыборки трека,
каждая синхровыборка трека является выборкой произвольного доступа трека,
выборка масштабируемого видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой, и
выборка многовидового видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой без пропущенных передних картинок произвольного доступа (RASL).
4. Способ по п. 1, дополнительно содержащий кодирование многоуровневых видеоданных.
5. Способ обработки многоуровневых видеоданных, причем способ содержит:
получение, из файла, бокса трека, который содержит метаданные для трека в файле, причем медиаданные для трека содержат последовательность выборок, каждая из выборок является видеоединицей доступа из множества видеоединиц доступа многоуровневых видеоданных,
получение, из файла, определения группы выборок, которая документирует все из выборок, содержащих по меньшей мере одну картинку внутренней точки произвольного доступа (IRAP), при этом
группа выборок определена, чтобы включать запись группы выборок, которая включает в себя:
значение, указывающее, все ли кодированные картинки в конкретной выборке в последовательности выборок являются IRAP-картинками,
значение, указывающее число IRAP-картинок в конкретной выборке, и
значения, указывающие идентификаторы уровня IRAP-картинок в конкретной выборке, и
при этом по меньшей мере одна из видеоединиц доступа в сгенерированном файле содержит IRAP-картинку в базовом уровне, а также содержит одну или более не-IRAP-картинок в других уровнях, и
определение, на основе группы выборок, одной или более выборок, содержащих по меньшей мере одну IRAP-картинку.
6. Способ по п. 5, содержащий:
получение, из записи группы выборок, значения, указывающего тип единицы уровня сетевой абстракции (NAL) для NAL-единиц уровня видеокодирования (VCL) в IRAP-картинках конкретной выборки.
7. Способ по п. 5, дополнительно содержащий:
получение, из файла, бокса синхровыборки, который включает в себя таблицу синхровыборок, которая документирует синхровыборки трека,
каждая синхровыборка трека является выборкой произвольного доступа трека,
выборка масштабируемого видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой, и
выборка многовидового видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой без пропущенных передних картинок произвольного доступа (RASL).
8. Способ по п. 5, дополнительно содержащий запуск декодирования многоуровневых видеоданных в одной из одной или более выборок, содержащих по меньшей мере одну IRAP-картинку.
9. Устройство обработки видеоданных, содержащее:
носитель хранения данных, сконфигурированный для хранения многоуровневых видеоданных, и
один или более процессоров, сконфигурированных, чтобы:
генерировать файл, который содержит бокс трека, который содержит метаданные для трека в файле, при этом:
медиаданные для трека содержат последовательность выборок, каждая из выборок является видеоединицей доступа из множества видеоединиц доступа многоуровневых видеоданных, и
генерация файла содержит определение, в файле, группы выборок, которая документирует все из выборок, содержащих по меньшей мере одну картинку внутренней точки произвольного доступа (IRAP), при этом:
группа выборок определена, чтобы включать запись группы выборок, которая включает в себя:
значение, указывающее, все ли кодированные картинки в конкретной выборке в последовательности выборок являются IRAP-картинками,
значение, указывающее число IRAP-картинок в конкретной выборке, и
значения, указывающие идентификаторы уровня IRAP-картинок в конкретной выборке, и
при этом по меньшей мере одна из видеоединиц доступа в сгенерированном файле содержит IRAP-картинку в базовом уровне, а также содержит одну или более не-IRAP-картинок в других уровнях.
10. Устройство обработки видеоданных по п. 9, в котором один или более процессоров сконфигурированы, чтобы:
включать, в запись группы выборок, значение, указывающее тип единицы уровня сетевой абстракции (NAL) для NAL-единиц уровня видеокодирования (VCL) в IRAP-картинках конкретной выборки.
11. Устройство обработки видеоданных по п. 9, в котором один или более процессоров сконфигурированы, чтобы генерировать бокс синхровыборки в файле, который включает в себя таблицу синхровыборок, которая документирует синхровыборки трека,
каждая синхровыборка трека является выборкой произвольного доступа трека,
выборка масштабируемого видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой, и
выборка многовидового видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой без пропущенных передних картинок произвольного доступа (RASL).
12. Устройство обработки видеоданных по п. 9, в котором один или более процессоров сконфигурированы, чтобы кодировать многоуровневые видеоданные.
13. Устройство обработки видеоданных по п. 9, причем устройство реализовано как по меньшей мере одно из:
интегральной схемы,
микропроцессора или
беспроводного телефона.
14. Устройство обработки видеоданных по п. 9, дополнительно содержащее одну или более камер, сконфигурированных для захвата многоуровневых видеоданных.
15. Устройство обработки видеоданных, содержащее:
носитель хранения данных, сконфигурированный для хранения многоуровневых видеоданных, и
один или более процессоров, сконфигурированных, чтобы:
получать, из файла, бокс трека, который содержит метаданные для трека в файле, причем медиаданные для трека содержат последовательность выборок, каждая из выборок является видеоединицей доступа из множества видеоединиц доступа многоуровневых видеоданных,
получать, из файла, определение группы выборок, которая документирует все из выборок, содержащих по меньшей мере одну картинку внутренней точки произвольного доступа (IRAP), при этом:
группа выборок определена, чтобы включать запись группы выборок, которая включает в себя:
значение, указывающее, все ли кодированные картинки в конкретной выборке в последовательности выборок являются IRAP-картинками,
значение, указывающее число IRAP-картинок в конкретной выборке, и
значения, указывающие идентификаторы уровня IRAP-картинок в конкретной выборке, и
при этом по меньшей мере одна из видеоединиц доступа в сгенерированном файле содержит IRAP-картинку в базовом уровне, а также содержит одну или более не-IRAP-картинок в других уровнях, и
определять, на основе информации в дополнительном боксе, одну или более выборок, содержащих по меньшей мере одну IRAP-картинку.
16. Устройство обработки видеоданных по п. 15, в котором один или более процессоров сконфигурированы, чтобы:
получать, из записи группы выборок, значение, указывающее тип единицы уровня сетевой абстракции (NAL) для NAL-единиц уровня видеокодирования (VCL) в IRAP-картинках конкретной выборки.
17. Устройство обработки видеоданных по п. 15, в котором один или более процессоров сконфигурированы, чтобы:
получать, из файла, бокс синхровыборки, который включает в себя таблицу синхровыборок, которая документирует синхровыборки трека,
каждая синхровыборка трека является выборкой произвольного доступа трека,
выборка масштабируемого видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой, и
выборка многовидового видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой без пропущенных передних картинок произвольного доступа (RASL).
18. Устройство обработки видеоданных по п. 15, в котором один или более процессоров сконфигурированы, чтобы запускать декодирование многоуровневых видеоданных в одной из одной или более выборок, содержащих по меньшей мере одну IRAP-картинку, для получения декодированных видеоданных.
19. Устройство обработки видеоданных по п. 15, причем устройство реализовано как по меньшей мере одно из:
интегральной схемы,
микропроцессора или
беспроводного телефона.
20. Устройство обработки видеоданных по п. 18, дополнительно содержащее устройство отображения, сконфигурированное для отображения упомянутых декодированных видеоданных.
21. Устройство обработки видеоданных, содержащее:
средство для хранения кодированных многовидовых видеоданных и
средство для генерации файла, который содержит бокс трека, который содержит метаданные для трека в файле, при этом:
медиаданные для трека содержат последовательность выборок, каждая из выборок является видеоединицей доступа из множества видеоединиц доступа многоуровневых видеоданных, и
генерация файла содержит определение, в файле, группы выборок, которая документирует все из выборок, содержащих по меньшей мере одну картинку внутренней точки произвольного доступа (IRAP), при этом:
группа выборок определена, чтобы включать запись группы выборок, которая включает в себя:
значение, указывающее, все ли кодированные картинки в конкретной выборке в последовательности выборок являются IRAP-картинками,
значение, указывающее число IRAP-картинок в конкретной выборке, и
значения, указывающие идентификаторы уровня IRAP-картинок в конкретной выборке, и
при этом по меньшей мере одна из видеоединиц доступа в сгенерированном файле содержит IRAP-картинку в базовом уровне, а также содержит одну или более не-IRAP-картинок в других уровнях.
22. Устройство обработки видеоданных по п. 21, содержащее:
средство для включения, в запись группы выборок, значения, указывающего тип единицы уровня сетевой абстракции (NAL) для NAL-единиц уровня видеокодирования (VCL) в IRAP-картинках конкретной выборки.
23. Устройство обработки видеоданных по п. 21, в котором:
генерация файла содержит генерацию, в файле, бокса синхровыборки, который включает в себя таблицу синхровыборок, которая документирует синхровыборки трека,
каждая синхровыборка трека является выборкой произвольного доступа трека,
выборка масштабируемого видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой, и
выборка многовидового видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой без пропущенных передних картинок произвольного доступа (RASL).
24. Устройство обработки видеоданных по п. 21, дополнительно содержащее средство для кодирования многоуровневых видеоданных.
25. Устройство обработки видеоданных, содержащее:
средство для получения, из файла, бокса трека, который содержит метаданные для трека в файле, причем медиаданные для трека содержат последовательность выборок, каждая из выборок является видеоединицей доступа из множества видеоединиц доступа многоуровневых видеоданных,
средство для получения, из файла, определения группы выборок, которая документирует все из выборок, содержащих по меньшей мере одну картинку внутренней точки произвольного доступа (IRAP), при этом:
группа выборок определена, чтобы включать запись группы выборок, которая включает в себя:
значение, указывающее, все ли кодированные картинки в конкретной выборке в последовательности выборок являются IRAP-картинками,
значение, указывающее число IRAP-картинок в конкретной выборке, и
значения, указывающие идентификаторы уровня IRAP-картинок в конкретной выборке, и
при этом по меньшей мере одна из видеоединиц доступа в сгенерированном файле содержит IRAP-картинку в базовом уровне, а также содержит одну или более не-IRAP-картинок в других уровнях, и
средство для определения, на основе группы выборок, одной или более выборок, содержащих по меньшей мере одну IRAP-картинку.
26. Устройство обработки видеоданных по п. 25, содержащее:
средство для получения, из записи группы выборок, значения, указывающего тип единицы уровня сетевой абстракции (NAL) для NAL-единиц уровня видеокодирования (VCL) в IRAP-картинках конкретной выборки.
27. Устройство обработки видеоданных по п. 25, дополнительно содержащее:
средство для получения, из файла, бокса синхровыборки, который включает в себя таблицу синхровыборок, которая документирует синхровыборки трека,
каждая синхровыборка трека является выборкой произвольного доступа трека,
выборка масштабируемого видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой, и
выборка многовидового видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой без пропущенных передних картинок произвольного доступа (RASL).
28. Устройство обработки видеоданных по п. 25, дополнительно содержащее средство для запуска декодирования многоуровневых видеоданных в одной из одной или более выборок, содержащих по меньшей мере одну IRAP-картинку.
29. Считываемый компьютером носитель хранения данных, имеющий инструкции, сохраненные на нем, которые, при исполнении, побуждают один или более процессоров:
генерировать файл, который содержит бокс трека, который содержит метаданные для трека в файле, при этом:
медиаданные для трека содержат последовательность выборок, каждая из выборок является видеоединицей доступа из множества видеоединиц доступа многоуровневых видеоданных,
чтобы генерировать файл, один или более процессоров определяют, в файле, группу выборок, которая документирует все из выборок, содержащих по меньшей мере одну картинку внутренней точки произвольного доступа (IRAP), при этом:
группа выборок определена, чтобы включать запись группы выборок, которая включает в себя:
значение, указывающее, все ли кодированные картинки в конкретной выборке в последовательности выборок являются IRAP-картинками,
значение, указывающее число IRAP-картинок в конкретной выборке, и
значения, указывающие идентификаторы уровня IRAP-картинок в конкретной выборке, и
при этом по меньшей мере одна из видеоединиц доступа в сгенерированном файле содержит IRAP-картинку в базовом уровне, а также содержит одну или более не-IRAP-картинок в других уровнях.
30. Считываемый компьютером носитель хранения данных по п. 29, в котором инструкции побуждают один или более процессоров:
включать, в запись группы выборок, значение, указывающее тип единицы уровня сетевой абстракции (NAL) для NAL-единиц уровня видеокодирования (VCL) в IRAP-картинках конкретной выборки.
31. Считываемый компьютером носитель хранения данных по п. 29, в котором инструкции дополнительно побуждают один или более процессоров:
генерировать, в файле, бокс синхровыборки, который включает в себя таблицу синхровыборок, которая документирует синхровыборки трека,
каждая синхровыборка трека является выборкой произвольного доступа трека,
выборка масштабируемого видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой, и
выборка многовидового видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой без пропущенных передних картинок произвольного доступа (RASL).
32. Считываемый компьютером носитель хранения данных, имеющий инструкции, сохраненные на нем, которые, при исполнении, побуждают один или более процессоров:
получать, из файла, бокс трека, который содержит метаданные для трека в файле, причем медиаданные для трека содержат последовательность выборок, каждая из выборок является видеоединицей доступа из множества видеоединиц доступа многоуровневых видеоданных,
получать, из файла, определение группы выборок, которая документирует все из выборок, содержащих по меньшей мере одну картинку внутренней точки произвольного доступа (IRAP), при этом:
группа выборок определена, чтобы включать запись группы выборок, которая включает в себя:
значение, указывающее, все ли кодированные картинки в конкретной выборке в последовательности выборок являются IRAP-картинками,
значение, указывающее число IRAP-картинок в конкретной выборке, и
значения, указывающие идентификаторы уровня IRAP-картинок в конкретной выборке, и
при этом по меньшей мере одна из видеоединиц доступа в сгенерированном файле содержит IRAP-картинку в базовом уровне, а также содержит одну или более не-IRAP-картинок в других уровнях, и
определять, на основе группы выборок, одну или более выборок, содержащих по меньшей мере одну IRAP-картинку.
33. Считываемый компьютером носитель хранения данных по п. 32, в котором инструкции побуждают один или более процессоров:
получать, из записи группы выборок, значение, указывающее тип единицы уровня сетевой абстракции (NAL) для NAL-единиц уровня видеокодирования (VCL) в IRAP-картинках конкретной выборки.
34. Считываемый компьютером носитель хранения данных по п. 32, в котором инструкции побуждают один или более процессоров:
получать, из файла, бокс синхровыборки, который включает в себя таблицу синхровыборок, которая документирует синхровыборки трека,
каждая синхровыборка трека является выборкой произвольного доступа трека,
выборка масштабируемого видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой, и
выборка многовидового видеокодирования является синхровыборкой, если каждая кодированная картинка в единице доступа является IRAP-картинкой без пропущенных передних картинок произвольного доступа (RASL).
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201361894886P | 2013-10-23 | 2013-10-23 | |
| US61/894,886 | 2013-10-23 | ||
| US14/521,099 | 2014-10-22 | ||
| US14/521,099 US9648348B2 (en) | 2013-10-23 | 2014-10-22 | Multi-layer video file format designs |
| PCT/US2014/061955 WO2015061561A1 (en) | 2013-10-23 | 2014-10-23 | Multi-layer video file format designs |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| RU2016115539A RU2016115539A (ru) | 2017-11-28 |
| RU2016115539A3 RU2016115539A3 (ru) | 2018-08-28 |
| RU2676876C2 true RU2676876C2 (ru) | 2019-01-11 |
Family
ID=52826146
Family Applications (3)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2016115539A RU2676876C2 (ru) | 2013-10-23 | 2014-10-23 | Структуры формата файла многоуровневого видео |
| RU2016115534A RU2667048C2 (ru) | 2013-10-23 | 2014-10-23 | Структуры формата файла многоуровневого видео |
| RU2016115350A RU2678517C2 (ru) | 2013-10-23 | 2014-10-23 | Структуры формата файла многоуровневого видео |
Family Applications After (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2016115534A RU2667048C2 (ru) | 2013-10-23 | 2014-10-23 | Структуры формата файла многоуровневого видео |
| RU2016115350A RU2678517C2 (ru) | 2013-10-23 | 2014-10-23 | Структуры формата файла многоуровневого видео |
Country Status (24)
| Country | Link |
|---|---|
| US (3) | US9621919B2 (ru) |
| EP (3) | EP3061249B1 (ru) |
| JP (3) | JP6559663B2 (ru) |
| KR (3) | KR20160075554A (ru) |
| CN (3) | CN105659607B (ru) |
| AU (3) | AU2014340056B2 (ru) |
| CA (3) | CA2926141C (ru) |
| CL (3) | CL2016000958A1 (ru) |
| DK (2) | DK3061249T3 (ru) |
| ES (2) | ES2765462T3 (ru) |
| HK (3) | HK1220062A1 (ru) |
| HU (2) | HUE042230T2 (ru) |
| IL (3) | IL244614A0 (ru) |
| MX (3) | MX353217B (ru) |
| MY (3) | MY174120A (ru) |
| NZ (3) | NZ718303A (ru) |
| PH (3) | PH12016500536B1 (ru) |
| PT (1) | PT3061250T (ru) |
| RU (3) | RU2676876C2 (ru) |
| SA (2) | SA516371001B1 (ru) |
| SG (3) | SG11201601901XA (ru) |
| SI (1) | SI3061250T1 (ru) |
| TW (3) | TWI645709B (ru) |
| WO (3) | WO2015061561A1 (ru) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2775739C1 (ru) * | 2019-12-30 | 2022-07-07 | Тенсент Америка Ллс | Способ поуровневого произвольного доступа в кодированном видеопотоке |
| US12041249B2 (en) | 2019-07-08 | 2024-07-16 | Huawei Technologies Co., Ltd. | Mixed NAL unit picture constraints in video coding |
| US12081784B2 (en) | 2019-09-24 | 2024-09-03 | Huawei Technologies Co., Ltd. | Support of mixed IRAP and non-IRAP pictures within an access unit in multi-layer video bitstreams |
Families Citing this family (53)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| HUE026534T2 (en) * | 2010-07-15 | 2016-06-28 | Ge Video Compression Llc | Hybrid video encoding to support intermediate view synthesis |
| EP2992683A1 (en) * | 2013-04-30 | 2016-03-09 | Dolby Laboratories Licensing Corporation | System and method of outputting multi-lingual audio and associated audio from a single container |
| US10085034B2 (en) * | 2013-07-12 | 2018-09-25 | Sony Corporation | Image coding apparatus and method |
| US9621919B2 (en) | 2013-10-23 | 2017-04-11 | Qualcomm Incorporated | Multi-layer video file format designs |
| EP3092796B1 (en) * | 2014-01-07 | 2020-06-17 | Canon Kabushiki Kaisha | Method, device, and computer program for encoding inter-layer dependencies |
| US20150264404A1 (en) * | 2014-03-17 | 2015-09-17 | Nokia Technologies Oy | Method and apparatus for video coding and decoding |
| JP5836424B2 (ja) * | 2014-04-14 | 2015-12-24 | ソニー株式会社 | 送信装置、送信方法、受信装置および受信方法 |
| JP2017522792A (ja) * | 2014-06-18 | 2017-08-10 | シャープ株式会社 | スライス・タイプおよびデコーダ適合性 |
| GB2527786B (en) * | 2014-07-01 | 2016-10-26 | Canon Kk | Method, device, and computer program for encapsulating HEVC layered media data |
| GB2539461B (en) * | 2015-06-16 | 2020-01-08 | Canon Kk | Image data encapsulation |
| US20180213216A1 (en) * | 2015-06-16 | 2018-07-26 | Lg Electronics Inc. | Media data transmission device, media data reception device, media data transmission method, and media data rececption method |
| CA2988451C (en) * | 2015-06-23 | 2021-01-19 | Mediatek Singapore Pte. Ltd. | Method and apparatus for transform coefficient coding of non-square blocks |
| US20170026653A1 (en) * | 2015-07-21 | 2017-01-26 | Shengli Xie | Method for scalable transmission of video tract |
| US10034010B2 (en) * | 2015-10-14 | 2018-07-24 | Qualcomm Incorporated | Alignment of operation point sample group in multi-layer bitstreams file format |
| US10306253B2 (en) | 2015-10-14 | 2019-05-28 | Qualcomm Incorporated | Signaling of parameter sets in files of multi-layer bitstreams |
| US20170111642A1 (en) * | 2015-10-14 | 2017-04-20 | Qualcomm Incorporated | Support of random access and switching of layers and sub-layers in multi-layer video files |
| TWI750072B (zh) | 2016-02-09 | 2021-12-11 | 弗勞恩霍夫爾協會 | 用於圖像/視訊資料串流而允許有效可縮減性或有效隨機存取之技術 |
| FI20165115A (fi) * | 2016-02-17 | 2017-08-18 | Nokia Technologies Oy | Laitteisto, menetelmä ja tietokoneohjelma videokoodausta ja videokoodauksen purkua varten |
| US10623755B2 (en) * | 2016-05-23 | 2020-04-14 | Qualcomm Incorporated | End of sequence and end of bitstream NAL units in separate file tracks |
| US10652631B2 (en) * | 2016-05-24 | 2020-05-12 | Qualcomm Incorporated | Sample entries and random access |
| GB2550604A (en) * | 2016-05-24 | 2017-11-29 | Canon Kk | Method, device, and computer program for encapsulating and parsing timed media data |
| US10652630B2 (en) * | 2016-05-24 | 2020-05-12 | Qualcomm Incorporated | Sample entries and random access |
| US20200322406A1 (en) * | 2016-05-24 | 2020-10-08 | Sharp Kabushiki Kaisha | Systems and methods for signaling scalable video in a media application format |
| RU2743732C2 (ru) | 2016-05-30 | 2021-02-25 | Сони Корпорейшн | Способ и устройство для обработки видео- и аудиосигналов и программа |
| EP3514486B1 (en) * | 2016-09-16 | 2021-10-06 | Panasonic Intellectual Property Corporation of America | Method for creating three-dimensional data and device for creating three-dimensional data |
| US11197040B2 (en) * | 2016-10-17 | 2021-12-07 | Mediatek Inc. | Deriving and signaling a region or viewport in streaming media |
| US11062738B2 (en) * | 2017-03-23 | 2021-07-13 | Qualcomm Incorporated | Signalling of video content including sub-picture bitstreams for video coding |
| US11532128B2 (en) | 2017-03-23 | 2022-12-20 | Qualcomm Incorporated | Advanced signaling of regions of interest in omnidirectional visual media |
| GB2560921B (en) | 2017-03-27 | 2020-04-08 | Canon Kk | Method and apparatus for encoding media data comprising generated content |
| US10587904B2 (en) * | 2017-07-10 | 2020-03-10 | Qualcomm Incorporated | Processing media data using an omnidirectional media format |
| CN113170238B (zh) * | 2018-09-12 | 2023-08-01 | 诺基亚技术有限公司 | 用于视频编码和解码的装置、方法和计算机程序 |
| WO2020058567A1 (en) * | 2018-09-18 | 2020-03-26 | Nokia Technologies Oy | Method and apparatus for non-binary profile constraint signaling for video coding |
| GB2579389B (en) * | 2018-11-29 | 2022-07-27 | Canon Kk | Method, device and computer program for encapsulating media data into a media file |
| CN113545099B (zh) * | 2019-03-11 | 2024-07-09 | 索尼集团公司 | 信息处理设备、再现处理设备、信息处理方法和再现处理方法 |
| CN114009032A (zh) * | 2019-06-21 | 2022-02-01 | 瑞典爱立信有限公司 | 视频编码层上切换指示 |
| GB2585052B (en) * | 2019-06-26 | 2023-07-26 | Canon Kk | Method and apparatus for encapsulating panorama images in a file |
| US11122102B2 (en) * | 2019-07-03 | 2021-09-14 | Lg Electronics Inc. | Point cloud data transmission apparatus, point cloud data transmission method, point cloud data reception apparatus and point cloud data reception method |
| US11265357B2 (en) * | 2019-10-10 | 2022-03-01 | Microsoft Technology Licensing, Llc | AV1 codec for real-time video communication |
| US11563947B2 (en) * | 2019-12-31 | 2023-01-24 | Tencent America LLC | Signaling output picture size for reference picture resampling |
| TWI731579B (zh) * | 2020-02-11 | 2021-06-21 | 日商東芝股份有限公司 | 傳輸裝置、通訊系統、傳輸方法及電腦程式產品 |
| US11405649B2 (en) * | 2020-02-18 | 2022-08-02 | Mediatek Inc. | Specifying slice chunks of a slice within a tile |
| CN115668938A (zh) * | 2020-03-18 | 2023-01-31 | Lg电子株式会社 | 点云数据发送装置、点云数据发送方法、点云数据接收装置和点云数据接收方法 |
| CN113434715B (zh) * | 2020-03-23 | 2024-06-21 | 瑞昱半导体股份有限公司 | 用于针对图像进行搜索的方法以及图像处理电路 |
| GB2593897B (en) * | 2020-04-06 | 2024-02-14 | Canon Kk | Method, device, and computer program for improving random picture access in video streaming |
| KR20230013055A (ko) | 2020-05-22 | 2023-01-26 | 바이트댄스 아이엔씨 | 비디오 비트스트림들에서 픽처 순서 카운트의 코딩 |
| KR20230021664A (ko) | 2020-06-12 | 2023-02-14 | 바이트댄스 아이엔씨 | 다중 계층 비디오 코딩에 대한 픽처 헤더 제약들 |
| US20220086387A1 (en) | 2020-09-17 | 2022-03-17 | Lemon Inc. | Subpicture entity groups in video coding |
| JP7202429B2 (ja) * | 2020-09-17 | 2023-01-11 | レモン インコーポレイテッド | 符号化映像におけるクロマフォーマット及びビット深度のインジケーション |
| US11671627B2 (en) | 2020-09-17 | 2023-06-06 | Lemon Inc. | Operating point entity group signaling in coded video |
| US11711518B2 (en) | 2020-09-17 | 2023-07-25 | Lemon Inc. | Decoding capability information storage in video coding |
| US11770498B2 (en) | 2020-09-29 | 2023-09-26 | Lemon Inc. | Supplemental enhancement information for multi-layer video streams |
| US11611752B2 (en) | 2020-10-07 | 2023-03-21 | Lemon Inc. | Adaptation parameter set storage in video coding |
| WO2022131754A1 (ko) * | 2020-12-14 | 2022-06-23 | 엘지전자 주식회사 | 샘플 단위의 랜덤 액세스를 지원하는 미디어 파일 생성/수신 방법, 장치 및 미디어 파일 전송 방법 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2378790C1 (ru) * | 2005-09-27 | 2010-01-10 | Квэлкомм Инкорпорейтед | Методики масштабируемости на основе информации содержимого |
| EP2521366A1 (en) * | 2009-02-19 | 2012-11-07 | Panasonic Corporation | Recording medium, playback device, and integrated circuit |
| US20130094834A1 (en) * | 2011-10-12 | 2013-04-18 | Vixs Systems, Inc. | Video processing device for embedding authored metadata and methods for use therewith |
| WO2013130478A1 (en) * | 2012-02-29 | 2013-09-06 | Dolby Laboratories Licensing Corporation | Image metadata creation for improved image processing and content delivery |
| RU2492585C2 (ru) * | 2008-07-16 | 2013-09-10 | Нокиа Корпорейшн | Способ и устройство для группирования треков и подмножеств треков |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE60223483T2 (de) * | 2001-10-29 | 2008-09-18 | Humax Co. Ltd., Yougin | Verfahren zum aufzeichenen eines digitalen Rundfunkprogramms und zeitbasierter Wiedergabe eines aufgezeichneten Rundfunkprogramms und zugehörige Vorrichtung |
| CN101695116B (zh) * | 2004-06-02 | 2013-01-02 | 松下电器产业株式会社 | 图像编码装置、图像解码装置、图像编码方法、图像解码方法、以及记录方法 |
| MX2007012564A (es) * | 2005-04-13 | 2007-11-15 | Nokia Corp | Codificacion, almacenamiento y senalizacion de informacion de escalabilidad. |
| US7725593B2 (en) | 2005-07-15 | 2010-05-25 | Sony Corporation | Scalable video coding (SVC) file format |
| US7956930B2 (en) * | 2006-01-06 | 2011-06-07 | Microsoft Corporation | Resampling and picture resizing operations for multi-resolution video coding and decoding |
| KR20070108433A (ko) * | 2006-01-09 | 2007-11-12 | 한국전자통신연구원 | 청크 디스크립터를 이용한 ｓｖｃ 파일포맷에서의 비디오데이터 공유방법 |
| US7991236B2 (en) * | 2006-10-16 | 2011-08-02 | Nokia Corporation | Discardable lower layer adaptations in scalable video coding |
| WO2010032636A1 (ja) * | 2008-09-17 | 2010-03-25 | シャープ株式会社 | スケーラブルビデオストリーム復号装置およびスケーラブルビデオストリーム生成装置 |
| KR101233627B1 (ko) * | 2008-12-23 | 2013-02-14 | 한국전자통신연구원 | 스케일러블 부호화 장치 및 방법 |
| CN102714715B (zh) * | 2009-09-22 | 2016-01-20 | 高通股份有限公司 | 用于文件格式轨迹选择的媒体提取器轨迹 |
| US9131033B2 (en) * | 2010-07-20 | 2015-09-08 | Qualcomm Incoporated | Providing sequence data sets for streaming video data |
| US9456015B2 (en) * | 2010-08-10 | 2016-09-27 | Qualcomm Incorporated | Representation groups for network streaming of coded multimedia data |
| US9124895B2 (en) * | 2011-11-04 | 2015-09-01 | Qualcomm Incorporated | Video coding with network abstraction layer units that include multiple encoded picture partitions |
| EP2805490A1 (en) * | 2012-01-20 | 2014-11-26 | Telefonaktiebolaget LM Ericsson (Publ) | Output of decoded reference pictures |
| US10958915B2 (en) * | 2012-01-30 | 2021-03-23 | Qualcomm Incorporated | Method of coding video and storing video content |
| RU2016140556A (ru) * | 2012-09-28 | 2018-12-14 | Телефонактиеболагет Лм Эрикссон (Пабл) | Декодирование и кодирование изображений видеопоследовательности |
| WO2014163467A1 (ko) | 2013-04-05 | 2014-10-09 | 삼성전자 주식회사 | 랜덤 엑세스를 위한 멀티 레이어 비디오 부호화 방법 및 그 장치, 랜덤 엑세스를 위한 멀티 레이어 비디오 복호화 방법 및 그 장치 |
| TW201517597A (zh) * | 2013-07-31 | 2015-05-01 | Nokia Corp | 用於視訊編碼及解碼之方法及裝置 |
| WO2015056158A1 (en) * | 2013-10-14 | 2015-04-23 | Nokia Technologies Oy | Multi-layer hypothetical reference decoder |
| US9621919B2 (en) | 2013-10-23 | 2017-04-11 | Qualcomm Incorporated | Multi-layer video file format designs |
| US10148969B2 (en) | 2015-02-11 | 2018-12-04 | Qualcomm Incorporated | Of sample entry and operation point signalling in a layered video file format |
-
2014
- 2014-10-22 US US14/521,042 patent/US9621919B2/en active Active
- 2014-10-22 US US14/521,153 patent/US9712843B2/en active Active
- 2014-10-22 US US14/521,099 patent/US9648348B2/en active Active
- 2014-10-23 MX MX2016005108A patent/MX353217B/es active IP Right Grant
- 2014-10-23 MX MX2016005098A patent/MX353208B/es active IP Right Grant
- 2014-10-23 SG SG11201601901XA patent/SG11201601901XA/en unknown
- 2014-10-23 KR KR1020167011821A patent/KR20160075554A/ko not_active Application Discontinuation
- 2014-10-23 MX MX2016005084A patent/MX353228B/es active IP Right Grant
- 2014-10-23 CN CN201480056699.1A patent/CN105659607B/zh active Active
- 2014-10-23 MY MYPI2016700900A patent/MY174120A/en unknown
- 2014-10-23 PT PT14795743T patent/PT3061250T/pt unknown
- 2014-10-23 MY MYPI2016700902A patent/MY172351A/en unknown
- 2014-10-23 HU HUE14795743A patent/HUE042230T2/hu unknown
- 2014-10-23 DK DK14795742.7T patent/DK3061249T3/da active
- 2014-10-23 CA CA2926141A patent/CA2926141C/en not_active Expired - Fee Related
- 2014-10-23 CA CA2925674A patent/CA2925674C/en not_active Expired - Fee Related
- 2014-10-23 DK DK14795743.5T patent/DK3061250T3/en active
- 2014-10-23 JP JP2016524066A patent/JP6559663B2/ja active Active
- 2014-10-23 AU AU2014340056A patent/AU2014340056B2/en not_active Ceased
- 2014-10-23 CN CN201480056411.0A patent/CN105637884B/zh active Active
- 2014-10-23 WO PCT/US2014/061955 patent/WO2015061561A1/en active Application Filing
- 2014-10-23 MY MYPI2016700898A patent/MY177745A/en unknown
- 2014-10-23 RU RU2016115539A patent/RU2676876C2/ru active
- 2014-10-23 AU AU2014340046A patent/AU2014340046B2/en not_active Ceased
- 2014-10-23 ES ES14795742T patent/ES2765462T3/es active Active
- 2014-10-23 KR KR1020167011820A patent/KR20160074522A/ko not_active Application Discontinuation
- 2014-10-23 CA CA2926126A patent/CA2926126C/en not_active Expired - Fee Related
- 2014-10-23 WO PCT/US2014/061988 patent/WO2015061580A1/en active Application Filing
- 2014-10-23 JP JP2016524061A patent/JP6419803B2/ja not_active Expired - Fee Related
- 2014-10-23 TW TW103136696A patent/TWI645709B/zh not_active IP Right Cessation
- 2014-10-23 KR KR1020167011819A patent/KR20160075553A/ko active IP Right Grant
- 2014-10-23 TW TW103136698A patent/TWI645710B/zh not_active IP Right Cessation
- 2014-10-23 EP EP14795742.7A patent/EP3061249B1/en active Active
- 2014-10-23 TW TW103136694A patent/TWI645721B/zh not_active IP Right Cessation
- 2014-10-23 EP EP14795743.5A patent/EP3061250B1/en active Active
- 2014-10-23 ES ES14795743T patent/ES2720662T3/es active Active
- 2014-10-23 SI SI201431145T patent/SI3061250T1/sl unknown
- 2014-10-23 WO PCT/US2014/061941 patent/WO2015061551A1/en active Application Filing
- 2014-10-23 CN CN201480056622.4A patent/CN105637885B/zh active Active
- 2014-10-23 HU HUE14795742A patent/HUE046798T2/hu unknown
- 2014-10-23 NZ NZ71830314A patent/NZ718303A/en not_active IP Right Cessation
- 2014-10-23 SG SG11201601954PA patent/SG11201601954PA/en unknown
- 2014-10-23 SG SG11201601902VA patent/SG11201601902VA/en unknown
- 2014-10-23 AU AU2014339980A patent/AU2014339980B2/en not_active Ceased
- 2014-10-23 RU RU2016115534A patent/RU2667048C2/ru active
- 2014-10-23 JP JP2016523977A patent/JP6434008B2/ja not_active Expired - Fee Related
- 2014-10-23 NZ NZ71820014A patent/NZ718200A/en not_active IP Right Cessation
- 2014-10-23 EP EP14795741.9A patent/EP3061248B1/en active Active
- 2014-10-23 NZ NZ71815814A patent/NZ718158A/en not_active IP Right Cessation
- 2014-10-23 RU RU2016115350A patent/RU2678517C2/ru active
-
2016
- 2016-03-16 IL IL244614A patent/IL244614A0/en active IP Right Grant
- 2016-03-16 IL IL244612A patent/IL244612B/en active IP Right Grant
- 2016-03-16 IL IL244613A patent/IL244613B/en active IP Right Grant
- 2016-03-21 PH PH12016500536A patent/PH12016500536B1/en unknown
- 2016-04-07 PH PH12016500637A patent/PH12016500637A1/en unknown
- 2016-04-21 PH PH12016500745A patent/PH12016500745B1/en unknown
- 2016-04-21 CL CL2016000958A patent/CL2016000958A1/es unknown
- 2016-04-21 CL CL2016000956A patent/CL2016000956A1/es unknown
- 2016-04-22 CL CL2016000963A patent/CL2016000963A1/es unknown
- 2016-04-23 SA SA516371001A patent/SA516371001B1/ar unknown
- 2016-04-23 SA SA516371000A patent/SA516371000B1/ar unknown
- 2016-07-08 HK HK16108012.9A patent/HK1220062A1/zh unknown
- 2016-07-13 HK HK16108252.8A patent/HK1220307A1/zh unknown
- 2016-07-29 HK HK16109090.2A patent/HK1221102A1/zh unknown
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2378790C1 (ru) * | 2005-09-27 | 2010-01-10 | Квэлкомм Инкорпорейтед | Методики масштабируемости на основе информации содержимого |
| RU2492585C2 (ru) * | 2008-07-16 | 2013-09-10 | Нокиа Корпорейшн | Способ и устройство для группирования треков и подмножеств треков |
| EP2521366A1 (en) * | 2009-02-19 | 2012-11-07 | Panasonic Corporation | Recording medium, playback device, and integrated circuit |
| US20130094834A1 (en) * | 2011-10-12 | 2013-04-18 | Vixs Systems, Inc. | Video processing device for embedding authored metadata and methods for use therewith |
| WO2013130478A1 (en) * | 2012-02-29 | 2013-09-06 | Dolby Laboratories Licensing Corporation | Image metadata creation for improved image processing and content delivery |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2822452C2 (ru) * | 2019-07-08 | 2024-07-05 | Хуавэй Текнолоджиз Ко., Лтд. | Ограничения изображений смешанных единиц nal при кодировании/декодировании видео |
| US12041249B2 (en) | 2019-07-08 | 2024-07-16 | Huawei Technologies Co., Ltd. | Mixed NAL unit picture constraints in video coding |
| RU2822714C1 (ru) * | 2019-09-24 | 2024-07-11 | Хуавэй Текнолоджиз Ко., Лтд. | Поддержка смешанных снимков irar и he-irar в пределах единицы доступа в многослойных битовых видеопотоках |
| US12081784B2 (en) | 2019-09-24 | 2024-09-03 | Huawei Technologies Co., Ltd. | Support of mixed IRAP and non-IRAP pictures within an access unit in multi-layer video bitstreams |
| RU2822714C9 (ru) * | 2019-09-24 | 2024-10-02 | Хуавэй Текнолоджиз Ко., Лтд. | Поддержка смешанных снимков irar и he-irar в пределах единицы доступа в многослойных битовых видеопотоках |
| US12126823B2 (en) | 2019-09-24 | 2024-10-22 | Huawei Technologies Co., Ltd. | Support of mixed IRAP and non-IRAP pictures within an access unit in multi-layer video bitstreams |
| RU2775739C1 (ru) * | 2019-12-30 | 2022-07-07 | Тенсент Америка Ллс | Способ поуровневого произвольного доступа в кодированном видеопотоке |
| RU2809562C1 (ru) * | 2020-03-27 | 2023-12-12 | TEНСЕНТ АМЕРИКА ЭлЭлСи | Способ выведения на основе набора выходных слоев по субслою |
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2676876C2 (ru) | Структуры формата файла многоуровневого видео | |
| KR102604891B1 (ko) | 별도의 파일 트랙들에서의 시퀀스 종단 및 비트스트림 종단 nal 유닛들 | |
| JP6637613B2 (ja) | Ｌ−ｈｅｖｃファイルフォーマットにおけるビットストリーム終了ｎａｌユニットの処理、ならびにｈｅｖｃおよびｌ−ｈｅｖｃタイルトラックの改善 |