[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] В одном аспекте, настоящее раскрытие описывает способ обработки многоуровневых видеоданных, содержащий генерацию файла, который содержит бокс медиа данных, который вмещает медиа контент, причем медиа контент содержит последовательность выборок, каждая из выборок является единицей доступа многоуровневых видеоданных, при этом генерация файла содержит, в ответ на определение, что по меньшей мере одна единица доступа битового потока многоуровневых видеоданных включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, использование по меньшей мере первого трека и второго трека для сохранения битового потока в файле, при этом, для каждого соответствующего трека из первого и второго треков, все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки; и картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
[0008] В другом аспекте, настоящее раскрытие описывает способ обработки многоуровневых видеоданных, содержащий получение, из файла, бокса первого трека и бокса второго трека, бокс первого трека содержит метаданные для первого трека в файле, бокс второго трека содержит метаданные для второго трека в файле, причем каждый из первого трека и второго трека содержит последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных, для каждого соответствующего трека из первого трека и второго трека, все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки, и картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
[0009] В другом аспекте, настоящее раскрытие описывает видео устройство, содержащее носитель хранения данных, сконфигурированный для хранения многоуровневых видеоданных; и один или более процессоров, сконфигурированных, чтобы генерировать файл, который содержит бокс медиа данных, который вмещает медиа контент, медиа контент содержит последовательность выборок, каждая из выборок является единицей доступа многоуровневых видеоданных, причем для генерации файла, один или более процессоров сконфигурированы, чтобы, в ответ на определение, что по меньшей мере одна единица доступа битового потока многоуровневых видеоданных включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, использовать по меньшей мере первый трек и второй трек для сохранения битового потока в файле, при этом, для каждого соответствующего трека из первого и второго треков, все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки; и картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
[0010] В другом аспекте, настоящее раскрытие описывает видео устройство, содержащее носитель хранения данных, сконфигурированный для хранения многоуровневых видеоданных; и один или более процессоров, сконфигурированных, чтобы получать, из файла, бокс первого трека и бокс второго трека, бокс первого трека содержит метаданные для первого трека в файле, бокс второго трека содержит метаданные для второго трека в файле, при этом каждый из первого трека и второго трека содержит последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных, для каждого соответствующего трека из первого трека и второго трека все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки, и картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
[0011] В другом аспекте, настоящее раскрытие описывает видео устройство, содержащее средство для генерации файла, который содержит бокс медиа данных, который вмещает медиа контент, причем медиа контент содержит последовательность выборок, каждая из выборок является единицей доступа многоуровневых видеоданных, причем генерация файла содержит, в ответ на определение, что по меньшей мере одна единица доступа битового потока многоуровневых видеоданных включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, использование по меньшей мере первого трека и второго трека для сохранения битового потока в файле, при этом, для каждого соответствующего трека из первого и второго треков, все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки; и картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
[0012] В другом аспекте, настоящее раскрытие описывает видео устройство, содержащее средство для получения, из файла, бокса первого трека и бокса второго трека, причем бокс первого трека содержит метаданные для первого трека в файле, бокс второго трека содержит метаданные для второго трека в файле, при этом каждый из первого трека и второго трека содержит последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных, для каждого соответствующего трека из первого трека и второго трека все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки, и картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
[0013] В другом аспекте, настоящее раскрытие описывает считываемый компьютером носитель хранения данных, имеющий инструкции, сохраненные на нем, которые, при исполнении, побуждают один или более процессоров генерировать файл, который содержит бокс медиа данных, который вмещает медиа контент, причем медиа контент содержит последовательность выборок, каждая из выборок является единицей доступа многоуровневых видеоданных, причем, для генерации файла, инструкции побуждают один или более процессоров, в ответ на определение, что по меньшей мере одна единица доступа битового потока многоуровневых видеоданных включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, использовать по меньшей мере первый трек и второй трек для сохранения битового потока в файле, при этом, для каждого соответствующего трека из первого и второго треков, все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки; и картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
[0014] В другом аспекте, настоящее раскрытие описывает считываемый компьютером носитель хранения данных, имеющий инструкции, сохраненные на нем, которые, при исполнении, побуждают один или более процессоров получать, из файла, бокс первого трека и бокс второго трека, причем бокс первого трека содержит метаданные для первого трека в файле, бокс второго трека содержит метаданные для второго трека в файле, при этом каждый из первого трека и второго трека содержит последовательность выборок, каждая из выборок является видео единицей доступа многоуровневых видеоданных, для каждого соответствующего трека из первого трека и второго трека, все кодированные картинки в каждой выборке соответствующего трека имеют то же самое значение флага вывода картинки, и картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
[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 пикселов до размера блока дерева максимум 64×64 пиксела или больше. Каждая 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 воспроизведена ниже.
Коды типов NAL-единицы и классы типов NAL-единицы
slice_segment_layer_rbsp()
slice_segment_layer_rbsp()
[0075] Одно различие между BLA-картинкой и CRA-картинкой состоит в следующем. Для CRA-картинки, ассоциированные передние картинки являются корректно декодируемыми, если дeкодирование начинается с 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 (исключая временные метаданные, которые всегда используются в другом треке):
Использование записей выборок для треков HEVC и SHVC
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:
Использование записей выборок для треков HEVC и MV-HEVC
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] Были описаны различные примеры. Эти и другие примеры находятся в пределах объема следующей формулы изобретения.
Изобретение относится к области видеокодирования. Технический результат – повышение эффективности обработки видеоданных. Способ обработки многоуровневых видеоданных содержит: генерацию файла, который содержит бокс фильма, содержащий метаданные для непрерывных медиапотоков, присутствующих в файле, при этом генерация файла содержит: в ответ на определение, что по меньшей мере одна единица доступа битового потока многоуровневых видеоданных включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, отличному от упомянутого первого значения, использование по меньшей мере первого трека и второго трека для сохранения битового потока в файле, для каждого соответствующего трека из первого и второго треков все кодированные картинки в каждой выборке соответствующего трека имеют одно и то же значение флага вывода картинки; и картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода; и для каждого соответствующего трека из файла включение соответствующего бокса трека в бокс фильма, причем соответствующий бокс трека вмещает метаданные для соответствующего трека, при этом каждый из медиапотоков, присутствующих в файле, представлен в файле как соответствующий трек файла, причем медиапоток для соответствующего трека содержит соответствующую последовательность выборок, причем соответствующая последовательность выборок включает в себя единицы доступа многоуровневых видеоданных, при этом медиапоток для соответствующего трека вложен в бокс медиаданных файла. 8 н. и 30 з.п. ф-лы, 12 ил., 3 табл.
1. Способ обработки многоуровневых видеоданных, причем способ содержит:
генерацию файла, который содержит бокс фильма, содержащий метаданные для непрерывных медиапотоков, присутствующих в файле, при этом генерация файла содержит:
в ответ на определение, что по меньшей мере одна единица доступа битового потока многоуровневых видеоданных включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, отличному от упомянутого первого значения, использование по меньшей мере первого трека и второго трека для сохранения битового потока в файле, при этом:
для каждого соответствующего трека из первого и второго треков все кодированные картинки в каждой выборке соответствующего трека имеют одно и то же значение флага вывода картинки; и
картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода; и
для каждого соответствующего трека из файла включение соответствующего бокса трека в бокс фильма, причем соответствующий бокс трека вмещает метаданные для соответствующего трека, при этом каждый из медиапотоков, присутствующих в файле, представлен в файле как соответствующий трек файла, причем медиапоток для соответствующего трека содержит соответствующую последовательность выборок, причем соответствующая последовательность выборок включает в себя единицы доступа многоуровневых видеоданных, при этом медиапоток для соответствующего трека вложен в бокс медиаданных файла.
2. Способ по п. 1, в котором генерация файла содержит:
в ответ на определение, что никакая единица доступа битового потока не включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, использование одного трека для сохранения битового потока в файле.
3. Способ по п. 1, в котором многоуровневые видеоданные являются данными масштабируемого высокоэффективного видеокодирования (SHVC).
4. Способ по п. 1, в котором многоуровневые видеоданные являются данными многовидового высокоэффективного видеокодирования (MV-HEVC).
5. Способ по п. 1, в котором многоуровневые видеоданные являются данными 3-мерного высокоэффективного видеокодирования (3D-HEVC).
6. Способ по п. 1, в котором первое значение равно 1, а второе значение равно 0.
7. Способ по п. 1, дополнительно содержащий кодирование многоуровневых видеоданных.
8. Способ обработки многоуровневых видеоданных, причем способ содержит:
получение из файла бокса первого трека и бокса второго трека, причем бокс первого трека и бокс второго трека находятся в боксе фильма, который содержит метаданные для непрерывных медиапотоков, присутствующих в файле, при этом:
для каждого соответствующего трека из файла каждый из медиапотоков, присутствующих в файле, представлен в файле как соответствующий трек файла, причем медиапоток для соответствующего трека содержит соответствующую последовательность выборок, причем соответствующая последовательность выборок включает в себя единицы доступа многоуровневых видеоданных, при этом медиапоток для соответствующего трека вложен в бокс медиаданных файла, причем бокс первого трека содержит метаданные для первого трека в файле, бокс второго трека содержит метаданные для второго трека в файле,
для каждого соответствующего трека из первого трека и второго трека все кодированные картинки в каждой выборке соответствующего трека имеют одно и то же значение флага вывода картинки, и
картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, отличному от упомянутого первого значения, разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
9. Способ по п. 8, в котором многоуровневые видеоданные являются данными масштабируемого высокоэффективного видеокодирования (SHVC).
10. Способ по п. 8, в котором многоуровневые видеоданные являются данными многовидового высокоэффективного видеокодирования (MV-HEVC).
11. Способ по п. 8, в котором многоуровневые видеоданные являются данными 3-мерного высокоэффективного видеокодирования (3D-HEVC).
12. Способ по п. 8, в котором первое значение равно 1, а второе значение равно 0.
13. Способ по п. 8, дополнительно содержащий:
для каждого соответствующего трека из первого и второго трека:
декодирование кодированных картинок в каждой выборке соответствующего трека; и
вывод декодированных картинок, имеющих флаги вывода картинок, равные первому значению.
14. Способ по п. 8, причем способ является исполняемым на устройстве беспроводной связи, причем устройство беспроводной связи содержит: память, сконфигурированную с возможностью хранения многоуровневых видеоданных; процессор, сконфигурированный с возможностью исполнения инструкций для обработки многоуровневых видеоданных, хранящихся в упомянутой памяти; приемник, сконфигурированный с возможностью приема файла.
15. Способ по п. 14, причем устройство беспроводной связи является сотовым телефоном, а файл принимают приемником и модулируют согласно стандарту сотовой связи.
16. Видеоустройство для обработки многоуровневых видеоданных, причем видеоустройство содержит:
носитель данных, сконфигурированный для хранения многоуровневых видеоданных; и
один или более процессоров, сконфигурированных, чтобы:
генерировать файл, который содержит бокс фильма, содержащий метаданные для непрерывных медиапотоков, присутствующих в файле, причем для генерации файла один или более процессоров сконфигурированы, чтобы:
в ответ на определение, что по меньшей мере одна единица доступа битового потока многоуровневых видеоданных включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, отличному от упомянутого первого значения, использовать по меньшей мере первый трек и второй трек для сохранения битового потока в файле, при этом:
для каждого соответствующего трека из первого и второго треков все кодированные картинки в каждой выборке соответствующего трека имеют одно и то же значение флага вывода картинки; и
картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода, и
для каждого соответствующего трека из файла включать соответствующий бокс трека в бокс фильма, причем соответствующий бокс трека вмещает метаданные для соответствующего трека, при этом каждый из медиапотоков, присутствующих в файле, представлен в файле как соответствующий трек файла, причем медиапоток для соответствующего трека содержит соответствующую последовательность выборок, причем соответствующая последовательность выборок включает в себя единицы доступа многоуровневых видеоданных, при этом медиапоток для соответствующего трека вложен в бокс медиаданных файла.
17. Видеоустройство по п. 16, в котором для генерации файла один или более процессоров сконфигурированы, чтобы:
в ответ на определение, что никакая единица доступа битового потока не включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, использовать один трек для сохранения битового потока в файле.
18. Видеоустройство по п. 16, в котором многоуровневые видеоданные являются одними из данных масштабируемого высокоэффективного видеокодирования (SHVC), данных многовидового высокоэффективного видеокодирования (MV-HEVC) или данных 3-мерного высокоэффективного видеокодирования (3D-HEVC).
19. Видеоустройство по п. 16, в котором первое значение равно 1, а второе значение равно 0.
20. Видеоустройство по п. 16, в котором один или более процессоров сконфигурированы, чтобы кодировать многоуровневые видеоданные.
21. Видеоустройство для обработки многоуровневых видеоданных, причем видеоустройство содержит:
носитель данных, сконфигурированный для хранения многоуровневых видеоданных; и
один или более процессоров, сконфигурированных, чтобы:
получать из файла бокс первого трека и бокс второго трека, причем бокс первого трека и бокс второго трека находятся в боксе фильма, который содержит метаданные для непрерывных медиапотоков, присутствующих в файле, при этом:
для каждого соответствующего трека из файла каждый из медиапотоков, присутствующих в файле, представлен в файле как соответствующий трек файла, причем медиапоток для соответствующего трека содержит соответствующую последовательность выборок, причем соответствующая последовательность выборок включает в себя единицы доступа многоуровневых видеоданных, при этом медиапоток для соответствующего трека вложен в бокс медиаданных файла, причем бокс первого трека содержит метаданные для первого трека в файле, бокс второго трека содержит метаданные для второго трека в файле,
для каждого соответствующего трека из первого трека и второго трека все кодированные картинки в каждой выборке соответствующего трека имеют одно и то же значение флага вывода картинки, и
картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, отличному от упомянутого первого значения, разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
22. Видеоустройство по п. 21, в котором многоуровневые видеоданные являются одними из данных масштабируемого высокоэффективного видеокодирования (SHVC), данных многовидового высокоэффективного видеокодирования (MV-HEVC) или данных 3-мерного высокоэффективного видеокодирования (3D-HEVC).
23. Видеоустройство по п. 21, в котором первое значение равно 1, а второе значение равно 0.
24. Видеоустройство по п. 21, в котором один или более процессоров сконфигурированы, чтобы:
для каждого соответствующего трека из первого и второго трека:
декодировать кодированные картинки в каждой выборке соответствующего трека; и
выводить декодированные картинки, имеющие флаги вывода картинок, равные первому значению.
25. Видеоустройство по п. 21, причем видеоустройство является устройством беспроводной связи, дополнительно содержащим: приемник, сконфигурированный с возможностью приема файла.
26. Видеоустройство по п. 25, причем устройство беспроводной связи является сотовым телефоном, а файл принимается приемником и модулируется согласно стандарту сотовой связи.
27. Видеоустройство для обработки многоуровневых видеоданных, причем видеоустройство содержит:
средство для хранения многоуровневых видеоданных; и
средство для генерации файла, который содержит бокс фильма, содержащий метаданные для непрерывных медиапотоков, присутствующих в файле, причем средство для генерации файла содержит:
средство для использования в ответ на определение, что по меньшей мере одна единица доступа битового потока многоуровневых видеоданных включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, отличному от упомянутого первого значения, по меньшей мере первого трека и второго трека для сохранения битового потока в файле, при этом:
для каждого соответствующего трека из первого и второго треков все кодированные картинки в каждой выборке соответствующего трека имеют одно и то же значение флага вывода картинки; и
картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода, и
для каждого соответствующего трека из файла средство для включения соответствующего бокса трека в бокс фильма, причем соответствующий бокс трека вмещает метаданные для соответствующего трека, при этом каждый из медиапотоков, присутствующих в файле, представлен в файле как соответствующий трек файла, причем медиапоток для соответствующего трека содержит соответствующую последовательность выборок, причем соответствующая последовательность выборок включает в себя единицы доступа многоуровневых видеоданных, при этом медиапоток для соответствующего трека вложен в бокс медиаданных файла.
28. Видеоустройство по п. 27, содержащее:
средство для использования в ответ на определение, что никакая единица доступа битового потока не включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, одного трека для сохранения битового потока в файле.
29. Видеоустройство по п. 27, в котором многоуровневые видеоданные являются одними из данных масштабируемого высокоэффективного видеокодирования (SHVC), данных многовидового высокоэффективного видеокодирования (MV-HEVC) или данных 3-мерного высокоэффективного видеокодирования (3D-HEVC).
30. Видеоустройство по п. 27, в котором первое значение равно 1, а второе значение равно 0.
31. Видеоустройство для обработки многоуровневых видеоданных, причем видеоустройство содержит:
средство для приема файла и
средство для получения из файла бокса первого трека и бокса второго трека, причем бокс первого трека и бокс второго трека находятся в боксе фильма, который содержит метаданные для непрерывных медиапотоков, присутствующих в файле, при этом:
для каждого соответствующего трека из файла каждый из медиапотоков, присутствующих в файле, представлен в файле как соответствующий трек файла, причем медиапоток для соответствующего трека содержит соответствующую последовательность выборок, причем соответствующая последовательность выборок включает в себя единицы доступа многоуровневых видеоданных, при этом медиапоток для соответствующего трека вложен в бокс медиаданных файла, причем бокс первого трека содержит метаданные для первого трека в файле, бокс второго трека содержит метаданные для второго трека в файле,
для каждого соответствующего трека из первого трека и второго трека все кодированные картинки в каждой выборке соответствующего трека имеют одно и то же значение флага вывода картинки, и
картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, отличному от упомянутого первого значения, разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
32. Видеоустройство по п. 31, в котором многоуровневые видеоданные являются одними из данных масштабируемого высокоэффективного видеокодирования (SHVC), данных многовидового высокоэффективного видеокодирования (MV-HEVC) или данных 3-мерного высокоэффективного видеокодирования (3D-HEVC).
33. Видеоустройство по п. 31, в котором первое значение равно 1, а второе значение равно 0.
34. Считываемый компьютером носитель, хранящий исполняемый компьютером код, содержащий инструкции, которые при исполнении побуждают один или более процессоров:
генерировать файл, который содержит бокс фильма, содержащий метаданные для непрерывных медиапотоков, присутствующих в файле, причем для генерации файла инструкции побуждают один или более процессоров:
в ответ на определение, что по меньшей мере одна единица доступа битового потока многоуровневых видеоданных включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, отличному от упомянутого первого значения, использовать по меньшей мере первый трек и второй трек для сохранения битового потока в файле, при этом:
для каждого соответствующего трека из первого трека и второго трека все кодированные картинки в каждой выборке соответствующего трека имеют одно и то же значение флага вывода картинки; и
картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, разрешены для использования в качестве опорных картинок, но не разрешены для вывода и
для каждого соответствующего трека из файла включать соответствующий бокс трека в бокс фильма, причем соответствующий бокс трека вмещает метаданные для соответствующего трека, при этом каждый из медиапотоков, присутствующих в файле, представлен в файле как соответствующий трек файла, причем медиапоток для соответствующего трека содержит соответствующую последовательность выборок, причем соответствующая последовательность выборок включает в себя единицы доступа многоуровневых видеоданных, при этом медиапоток для соответствующего трека вложен в бокс медиаданных файла.
35. Считываемый компьютером носитель по п. 34, в котором инструкции побуждают один или более процессоров:
использовать в ответ на определение, что никакая единица доступа битового потока не включает в себя кодированную картинку, которая имеет флаг вывода картинки, равный первому значению, и кодированную картинку, которая имеет флаг вывода картинки, равный второму значению, один трек для сохранения битового потока в файле.
36. Считываемый компьютером носитель по п. 34, в котором многоуровневые видеоданные являются одними из данных масштабируемого высокоэффективного видеокодирования (SHVC), данных многовидового высокоэффективного видеокодирования (MV-HEVC) или данных 3-мерного высокоэффективного видеокодирования (3D-HEVC).
37. Считываемый компьютером носитель, хранящий исполняемый компьютером код, содержащий инструкции, которые при исполнении побуждают один или более процессоров:
получать из файла бокс первого трека и бокс второго трека, причем бокс первого трека и бокс второго трека находятся в боксе фильма, который содержит метаданные для непрерывных медиапотоков, присутствующих в файле, при этом:
для каждого соответствующего трека из файла каждый из медиапотоков, присутствующих в файле, представлен в файле как соответствующий трек файла, причем медиапоток для соответствующего трека содержит соответствующую последовательность выборок, причем соответствующая последовательность выборок включает в себя единицы доступа многоуровневых видеоданных, при этом медиапоток для соответствующего трека вложен в бокс медиаданных файла, причем бокс первого трека содержит метаданные для первого трека в файле, бокс второго трека содержит метаданные для второго трека в файле,
для каждого соответствующего трека из первого трека и второго трека все кодированные картинки в каждой выборке соответствующего трека имеют одно и то же значение флага вывода картинки, и
картинки, имеющие флаги вывода картинки, равные первому значению, разрешены для вывода, а картинки, имеющие флаги вывода картинки, равные второму значению, отличному от упомянутого первого значения, разрешены для использования в качестве опорных картинок, но не разрешены для вывода.
38. Считываемый компьютером носитель по п. 37, в котором многоуровневые видеоданные являются одними из данных масштабируемого высокоэффективного видеокодирования (SHVC), данных многовидового высокоэффективного видеокодирования (MV-HEVC) или данных 3-мерного высокоэффективного видеокодирования (3D-HEVC).
| Приспособление для суммирования отрезков прямых линий | 1923 |
|
SU2010A1 |
| MISKA M | |||
| HANNUKSELA, "MV-HEVC/SHVC HLS: On non-HEVC base layer", Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11, 15th Meeting: Geneva, CH, 23 Oct | |||
| Печь для непрерывного получения сернистого натрия | 1921 |
|
SU1A1 |
| Многоступенчатая активно-реактивная турбина | 1924 |
|
SU2013A1 |
| Паровоз для отопления неспекающейся каменноугольной мелочью | 1916 |
|
SU14A1 |
| Пресс для выдавливания из деревянных дисков заготовок для ниточных катушек | 1923 |
|
SU2007A1 |
| Колосоуборка | 1923 |
|
SU2009A1 |
| Способ приготовления лака | 1924 |
|
SU2011A1 |
| МЕТОДИКИ МАСШТАБИРУЕМОСТИ НА ОСНОВЕ ИНФОРМАЦИИ СОДЕРЖИМОГО | 2006 |
|
RU2378790C1 |
