УРОВЕНЬ ТЕХНИКИ
[001] Инженеры используют сжатие (также называемое кодированием источника), чтобы уменьшить частоту следования битов цифрового видео. Сжатие уменьшает стоимость хранения и передачи видеоинформации посредством преобразования информации в форму с более низкой частотой следования битов. Декомпрессия (также называемая декодированием) восстанавливает версию первоначальной информации из сжатой формы. "Кодек" является системой кодера/декодера.
[002] За прошлые два десятилетия были приняты различные стандарты кодеков видео, включая стандарты H.261, H.262 (MPEG-2 или ISO/IEC 13818-2), H.263 и H.264 (AVC или ISO/IEC 14496-10) и стандарты MPEG-1 (ISO/IEC 11172-2), Визуальный MPEG-4 (ISO/IEC 14496-2) и SMPTE 421M. В последнее время в разработке находится стандарт HEVC. Стандарт кодека видео обычно определяет варианты для синтаксиса кодированного потока битов видео, детализацию параметров в потоке битов, когда конкретные признаки используются при кодировании и декодировании. Во многих случаях стандарт кодека видео также обеспечивает детали об операциях декодирования, которые декодер должен выполнить, чтобы достигнуть правильных результатов при декодировании.
[003] Основная цель сжатия состоит в том, чтобы обеспечить хорошую эффективность «скорость передачи - искажение». Так, для конкретной частоты следования битов кодер пытается обеспечить наивысшее качество видео. Или, для конкретного уровня качества/соответствия первоначальному видео, кодер пытается обеспечить самую низкую частоту следования битов кодированного видео. На практике в зависимости от сценария использования учет параметров, таких как время кодирования, сложность кодирования, ресурсы кодирования, время декодирования, сложность декодирования, ресурсы декодирования, общая задержка, способность восстановления потерь и/или гладкость при воспроизведении также влияет на решения, принятые во время кодирования и декодирования.
[004] Как правило, кодер или декодер видео буферизуют ранее декодированные картинки, которые кодер или декодер видео могут использовать при кодировании или декодировании других картинок. Такие восстановленные и буферизованные картинки часто называют опорными картинками. Некоторые стандарты кодека видео описывают сложные правила для управления и обновления того, какие опорные картинки буферизованы и какие опорные картинки больше не используются для ссылок (на них). Это может позволить кодеру улучшить эффективность сжатия, принимая хорошие решения о том, какие опорные картинки использовать, но процессы управления и обновления опорных картинок могут быть сложными для кодера и декодера. Кроме того, декодер использует различную информацию в потоке битов закодированных видеоданных, чтобы отследить и обновить состояние своего буфера опорных картинок и списки опорных картинок. Потеря информации из потока битов (например, из-за потери пакета или повреждения) может неблагоприятно влиять на декодирование в течение существенного промежутка времени, если внутреннее состояние декодера для его буфера опорных картинок и/или списков опорных картинок отклоняется от ожидаемого состояния, и декодер больше не использует соответствующие опорные картинки.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
[005] В целом настоящее подробное описание представляет усовершенствования (новшества) для сигнализации состояния буфера декодированных картинок ("DPB") и списков опорных картинок. Упомянутые усовершенствования могут уменьшить скорость передачи в битах, ассоциированную с сигнализацией информации состояния для управления DPB и списком опорных картинок ("RPL"), и улучшить управление DPB и/или управление RPL в различных других отношениях, все еще обеспечивая надежность в отношении информации состояния, влияющей на потери.
[006] Вместо того чтобы полагаться на внутреннее состояние декодера, чтобы управлять и обновлять DPB и списки RPL, информация состояния о DPB и списках RPL сигнализируется явно. Это позволяет декодеру определять, какие картинки ожидаются доступными для ссылки в DPB из сигнализированной информации состояния, которая идентифицирует, какие картинки в настоящее время доступны для ссылки. Такая информация состояния может упоминаться как информация списка описания буфера ("BDL"), которая обычно ссылается на любую форму информации, которая явно указывает состояние DPB и/или списков RPL.
[007] Новшества, описанные в настоящем описании, включают в себя, но не ограничены ими, следующее.
- Использование флага будущей опорной ссылки для каждой опорной картинки в информации BDL, где флаг будущей опорной ссылки указывает, используется ли опорная картинка только для декодирования текущей картинки (ассоциированной с информацией BDL) или, вместо этого, используется для декодирования по меньшей мере одной последующей картинки в кодированном порядке. Использование этого флага может позволить хранение дополнительной опорной картинки в DPB.
- Использование флага решения вкл/выкл (включения/выключения) для использования флага будущей опорной ссылки. Например, флаг решения вкл/выкл может быть сигнализирован в качестве части набора параметра последовательности ("SPS") и указывать присутствие/отсутствие флагов будущей опорной ссылки в информации BDL. Это может позволить кодеру решать, использовать ли флаги будущей опорной ссылки в информации BDL.
- В информации BDL для картинки, ассоциированной с более высоким временным уровнем, обеспечение информации маркирования опорной картинки, чтобы отметить одну или более картинок в более низком временном уровне как неиспользуемых для ссылки. В то время как такое поведение может быть необычным на практике, в некоторых сценариях оно может быть полезным, чтобы обеспечить такие опции для управления опорными картинками для картинок в более высоком временном уровне. И, когда более поздняя информация BDL испытывает недостаток в информации статуса опорных картинок, ранее удаленных с информацией BDL для картинки в более высоком временном уровне, декодер может логически вывести удаление таких опорных картинок.
- Использование флага обозначения картинки более высокого уровня для каждой картинки более высокого временного уровня в информации BDL, где флаг обозначения картинки более высокого уровня обозначает картинку как относящуюся к более высокому временному уровню для целей информации BDL. Во многих сценариях картинки более высокого временного уровня имеют небольшое или никакого использования в качестве опорных картинок, и процесс управления и обновления DPB может быть упрощен для таких картинок. Когда информация BDL используется вообще для картинок более высокого временного уровня, простой флаг для каждой картинки в информации BDL может быть достаточным, чтобы обозначать картинку как ассоциированную с более высоким временным уровнем, где действия по управлению и обновлению DPB подразумеваются.
- Использование флага решения вкл/выкл для включения информации статуса о картинках более высоких временных уровней в информацию BDL. Например, флаг решения вкл/выкл может быть сигнализирован в качестве части SPS и указывать присутствие/отсутствие информации статуса о картинках более высоких временных уровней в информации BDL.
- Информация BDL может быть сигнализирована на уровне адаптивного набора параметров слайса (вырезки) ("APS"). Единственный набор информации BDL ассоциирован с APS.
- Упрощение сигнализации информации статуса для долгосрочной опорной картинки ("LTRP") в информации BDL. Картинки LTRP обеспечивают полезный конструктивный элемент для кодирования и декодирования видео, но учет управления и обновления картинок LTRP в информации BDL представляет проблемы. В частности, для LTRP, которая остается в DPB в течение длительного времени, сигнализация идентифицирующей информации для этой LTRP может потреблять большое количество битов и создать особые случаи для их разрешения при синтаксическом разборе и декодировании потока битов. Различные версии упрощенного синтаксиса для картинок LTRP в информации BDL предложены в настоящем описании, которые уменьшают скорость передачи в битах для информации статуса LTRP и упрощают управление DPB. Например, флаг LTRP для картинки в информации BDL помечает картинку как являющуюся LTRP для целей управления DPB.
- Использование решения вкл/выкл для флага для включения информации статуса о картинках LTRP в информацию BDL. Например, флаг решения вкл/выкл может быть сигнализирован в качестве части SPS и указывать присутствие/отсутствие информации статуса о картинках LTRP в информации BDL, что упрощает сигнализацию информации BDL, когда кодер решил не использовать картинки LTRP.
- Сокращение количества битов, используемых для идентификации картинок LTRP в информации BDL. Во многих сценариях использования количество опорных картинок (и картинок LTRP) является малым, и малое количество битов достаточно, чтобы идентифицировать картинки LTRP. Кодер может увеличить число битов, используемых для идентификации картинок LTRP для других сценариев использования.
- Организация информации BDL в порядке, использованном для конструирования RPL. Это упрощает синтаксис в целях конструирования RPL.
- Сигнализация, разрешены ли промежутки в значениях отсчета последовательности картинок ("POC"). Например, флаг в SPS указывает, разрешены ли промежутки в значениях POC. Если промежутки не разрешены, декодер может распознать потери картинок, когда он определяет, что значения POC отсутствуют, и декодер может принять решения о картинках, готовых для вывода, на основании значений POC.
- Синтаксические элементы в информации BDL могут быть закодированы, используя усеченное экспоненциальное кодирование Голомба (Exp-Golomb) (то есть te(v)) вместо беззнакового экспоненциального кодирования Голомба. Это является более эффективным для синтаксических элементов с малым количеством возможных значений.
[008] Согласно одному аспекту новшеств, описанных здесь, вычислительная система определяет информацию состояния, которая идентифицирует, какие картинки доступны для использования в качестве опорных картинок. Вычислительная система устанавливает синтаксические элементы, которые представляют информацию состояния. В частности, при этом вычислительная система устанавливает идентифицирующую информацию для LTRP, где идентифицирующая информация является значением наименьших значащих битов в POC ("LSB в POC") для LTRB. Вычислительная система затем выводит эти синтаксические элементы в качестве части потока битов.
[009] Согласно другому аспекту новшеств, описанных здесь, вычислительная система принимает по меньшей мере часть потока битов. Из этого потока битов вычислительная система синтаксически выделяет синтаксические элементы, которые представляют информацию состояния, идентифицирующую, какие картинки доступны для использования в качестве опорных картинок. В частности, синтаксические элементы включают в себя идентифицирующую информацию для LTRP, причем идентифицирующая информация является значением LSB в POC для упомянутой LTRB. Вычислительная система использует эту идентифицирующую информацию во время декодирования.
[010] Предшествующие и другие задачи, признаки и преимущества изобретения станут более очевидными из нижеследующего подробного описания, которое приводится со ссылками на сопроводительные чертежи.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
[011] Фиг. 1 является примерной диаграммой вычислительной системы, в которой могут быть реализованы некоторые описанные варианты осуществления.
[012] Фиг. 2a и 2b являются диаграммами примерной сетевой среды, в которой могут быть реализованы некоторые описанные варианты осуществления.
[013] Фиг. 3 является диаграммой примерного кодера, совместно с которым могут быть реализованы некоторые описанные варианты осуществления.
[014] Фиг. 4a является последовательностью операций обобщенного способа для вывода синтаксического элемента, как описано здесь, и Фиг. 4b является последовательностью операций примерного способа для сигнализации идентифицирующей информации для картинок LTRP в потоке битов.
[015] Фиг. 5 является диаграммой примерного декодера, совместно с которым могут быть реализованы некоторые описанные варианты осуществления.
[016] Фиг. 6a является последовательностью операций обобщенного способа для синтаксического разбора синтаксического элемента, как описано здесь, и Фиг. 6b является последовательностью операций примерного способа для синтаксического разбора идентифицирующей информации для LTRP из потока битов.
[017] Фиг. 7a является листингом на псевдокоде для выведения переменной PicOrderCntMsb, и Фиг. 7b является листингом на псевдокоде для выведения переменной PicOrderCntVal.
ПОДРОБНОЕ ОПИСАНИЕ
[018] Подробное описание представляет усовершенствования (новшества) для сигнализации состояния DPB и списки RPL. Усовершенствования могут помочь уменьшить скорость передачи в битах, ассоциированную с информацией BDL, и/или упростить процесс управления DPB или конструирование RPL, все еще поддерживая восстановление потерь.
[019] Некоторые из новшеств, описанных здесь, проиллюстрированы в отношении синтаксических элементов и операций, специфичных для стандарта H.264 и/или HEVC. Такие новшества могут также быть реализованы для других стандартов или форматов.
[020] Более широко, возможны различные альтернативы примерам, описанным здесь. Некоторые способы, описанные со ссылками на диаграммы последовательности операций, могут быть изменены посредством изменения порядка этапов, показанных в этих последовательностях операций, посредством разделения, повторения или пропуска некоторых этапов и т.д. Различные аспекты сигнализации состояния DPB и списков RPL могут использоваться в комбинации или отдельно. Различные варианты осуществления используют одно или более из описанных новшеств. Некоторые из новшеств, описанных здесь, направлены на решение одной или более проблем, отмеченных в разделе Уровень техники. Как правило, заданный способ/инструмент не решает все такие проблемы.
I. ПРИМЕРНЫЕ ВЫЧИСЛИТЕЛЬНЫЕ СИСТЕМЫ
[021] Фиг. 1 иллюстрирует обобщенный пример подходящей вычислительной системы (100), в которой могут быть реализованы несколько из описанных новшеств. Вычислительная система (100) не предназначена, чтобы предложить какое-либо ограничение относительно области использования или функциональных возможностей, поскольку новшества могут быть реализованы в разнообразных вычислительных системах специального назначения или общего назначения.
[022] Со ссылками на фиг. 1 вычислительная система (100) включает в себя один или более блоков (110, 115) обработки и памяти (120, 125). На фиг. 1 эта наиболее базовая конфигурация (130) включена в пределы пунктирной линии. Блоки (110, 115) обработки выполняют выполняемые компьютером инструкции. Блок обработки может быть центральным процессором общего назначения (ЦП, CPU), процессором в специализированной интегральной схеме (ASIC) или любым другим типом процессора. В системе множественной обработки множественные блоки обработки выполняют выполняемые компьютером инструкции, чтобы увеличить мощность обработки. Например, Фиг. 1 показывает центральный процессор (110), так же как графический блок обработки или блок (115) совместной обработки. Материальная память (120, 125) может быть энергозависимой памятью (например, регистры, кэш, RAM), энергонезависимой памятью (например, ROM, EEPROM, флэш-память, и т.д.) или некоторой комбинацией этих двух, доступной для блока(ов) обработки. Память (120, 125) хранит программное обеспечение (180), реализующее одно или более новшеств для сигнализации информации BDL, в форме выполняемых компьютером инструкций, подходящих для выполнения блоком(ами) обработки.
[023] Вычислительная система может иметь дополнительные особенности. Например, вычислительная система (100) включает в себя запоминающее устройство (140), одно или более устройств (150) ввода, одно или более устройств (160) вывода и одно или более соединений (170) связи. Механизм взаимосвязи (не показан), такой как шина, контроллер или сеть, связывает компоненты вычислительной системы (100). Как правило, программное обеспечение операционной системы (не показано) обеспечивает операционную среду для другого программного обеспечения, выполняющегося в вычислительной системе (100), и координирует действия компонентов вычислительной системы (100).
[024] Материальное запоминающее устройство (140) может быть сменным или несменным, и включает в себя магнитные диски, магнитные ленты или кассеты, CD-ROM, DVD или любой другой носитель, который может быть использован для хранения информации, к которой можно получить доступ в вычислительной системе (100). Запоминающее устройство (140) хранит инструкции для программного обеспечения (180), реализующего одно или более новшеств для сигнализации информации BDL.
[025] Устройство(а) (150) ввода может быть устройством ввода касанием, таким как клавиатура, мышь, ручка или трекбол, голосовое устройство ввода, устройство сканирования или другое устройство, которое обеспечивает ввод в вычислительную систему (100). Для кодирования видео устройство(а) (150) ввода может быть компонентом захвата видео, таким как камера, видеокарта, карта ТВ-блока настройки или подобное устройство, которое принимает ввод видео в аналоговой или цифровой форме, компонент захвата видео, такой как модуль захвата экрана, который захватывает генерируемые компьютером экранные изображения в качестве видео или подобный компонент, который захватывает генерируемый компьютером контент изображения, или CD-ROM, или CD-RW, который считывает видео выборки в вычислительную систему (100). Устройство(а) (160) вывода может быть дисплеем, принтером, громкоговорителем, блоком записи на CD или другим устройством, которое обеспечивает вывод из вычислительной системы (100).
[026] Соединение(я) (170) связи обеспечивают связь по коммуникационному носителю к другому вычислительному объекту. Коммуникационный носитель передает информацию, такую как выполняемые компьютером инструкции, ввод или вывод аудио, или видео, или другие данные в модулированном сигнале данных. Модулированный сигнал данных является сигналом, который имеет одну или более из его характеристик, установленную или измененную таким образом, чтобы кодировать информацию в сигнале. Посредством примера, а не ограничения, коммуникационные носители могут использовать электрический, оптический, РЧ или другой носитель.
[027] Новшества могут быть описаны в общем контексте считываемого компьютером носителя. Считываемый компьютером носитель - это любой доступный материальный носитель, к которому можно получить доступ в пределах вычислительной среды. Посредством примера, а не ограничения, с вычислительной системой (100), считываемый компьютером носитель включает в себя память (120, 125), запоминающее устройство (140) и комбинацию любого из вышеупомянутых.
[028] Новшества могут быть описаны в общем контексте выполняемых компьютером инструкций, таких как включенные в программные модули, выполняемые в вычислительной системе на целевом реальном или виртуальном процессоре. Обычно программные модули включают в себя подпрограммы, программы, библиотеки, объекты, классы, компоненты, структуры данных и т.д. которые выполняют конкретные задачи или реализуют конкретные абстрактные типы данных. Функциональные возможности программных модулей могут быть объединены или разделены между программными модулями, как желательно в различных вариантах осуществления. Выполняемые компьютером инструкции для программных модулей могут быть выполнены в локальной или распределенной вычислительной системе.
[029] Термины "система" и "устройство" использованы взаимозаменяемо в настоящем описании. Если контекст явно не указывает иначе, никакой термин не подразумевает ограничения на тип вычислительной системы или вычислительного устройства. Обычно вычислительная система или вычислительное устройство могут быть локальными или распределенными и могут включать в себя любую комбинацию аппаратного обеспечения специального назначения и/или аппаратного обеспечения общего назначения с программным обеспечением, реализующим функциональные возможности, описанные в настоящем описании.
[030] Для целей представления подробное описание использует термины подобные "определять" и "использовать", чтобы описать компьютерные операции в вычислительной системе. Эти термины являются абстракциями высокого уровня для операций, выполняемых компьютером, и не должны быть перепутаны с действиями, совершенными человеком. Фактические компьютерные операции, соответствующие этим терминам, изменяются в зависимости от реализации.
II. ПРИМЕРНЫЕ СЕТЕВЫЕ СРЕДЫ
[031] Фиг. 2a и 2b показывают примерные сетевые среды (201, 202), которые включают в себя видеокодеры (220) и видеодекодеры (270). Кодеры (220) и декодеры (270) связаны по сети (250), используя соответствующий протокол связи. Сеть (250) может включать в себя Интернет или другую компьютерную сеть.
[032] В сетевой среде (201), показанной на фиг. 2a, каждый инструмент (210) связи в реальном времени ("RTC") включает в себя как кодер (220), так и декодер (270) для двунаправленной связи. Заданный кодер (220) может сформировать вывод, совместимый со стандартом SMPTE 421M, стандартом ISO/IEC 14496-10 (также известным как H.264 или AVC), стандартом HEVC, другим стандартом или составляющим собственность форматом, с соответствующим декодером (270), принимающим кодированные данные от кодера (220). Двунаправленная связь может быть частью видеоконференции, видеотелефонного звонка или другого сценария двухсторонней связи. Хотя сетевая среда (201) на фиг. 2a включает в себя два инструмента (210) связи в реальном времени, сетевая среда (201) может вместо этого включать в себя три или более инструмента (210) связи в реальном времени, которые участвуют в многосторонней связи.
[033] Инструмент (210) связи в реальном времени управляет кодированием посредством кодера (220). Фиг. 3 показывает примерную систему (300) кодера, которая может быть включена в инструмент (210) связи в реальном времени. Альтернативно, инструмент (210) связи в реальном времени использует другую систему кодера. Инструмент (210) связи в реальном времени также управляет декодированием посредством декодера (270). Фиг. 5 показывает примерную систему (500) декодера, который может быть включен в инструмент (210) связи в реальном времени. Альтернативно, инструмент (210) связи в реальном времени использует другую систему декодера.
[034] В сетевой среде (202), показанной на фиг. 2b, инструмент (212) кодирования включает в себя кодер (220), который кодирует видео для доставки на множественные инструменты (214) воспроизведения, которые включают в себя декодеры (270). Однонаправленная связь может быть предоставлена для системы видеонаблюдения, системы мониторинга web-камеры, удаленного настольного представления конференц-связи или другого сценария, в котором видео кодируется и посылается от одного местоположения к одному или более другим местоположениям. Хотя сетевая среда (202) на фиг. 2b включает в себя два инструмента (214) воспроизведения, сетевая среда (202) может включать в себя больше или меньше инструментов (214) воспроизведения. Обычно инструмент (214) воспроизведения связывается с инструментом (212) кодирования, чтобы определить поток видео для инструмента (214) воспроизведения для приема. Инструмент (214) воспроизведения принимает поток, буферизует принятые кодированные данные в течение соответствующего периода и начинает декодирование и воспроизведение.
[035] Фиг. 3 показывает примерную систему (300) кодера, которая может быть включена в инструмент (212) кодирования. Альтернативно, инструмент (212) кодирования использует другую систему кодера. Инструмент (212) кодирования может также включать в себя логику контроллера стороны сервера для управления соединениями с одним или более инструментами (214) воспроизведения и/или инструментами передачи сетевого видео. Фиг. 5 показывает примерную систему (500) декодера, которая может быть включена в инструмент (214) воспроизведения. Альтернативно, инструмент (214) воспроизведения использует другую систему декодера. Инструмент (214) воспроизведения может также включать в себя логику контроллера стороны клиента для управления соединениями с инструментом (212) кодирования.
III. ПРИМЕРНЫЕ СИСТЕМЫ КОДЕРА
[036] Фиг. 3 является блок-схемой примерной системы (300) кодера, в соединении с которым могут быть реализованы некоторые описанные варианты осуществления. Система (300) кодера может быть инструментом кодирования общего назначения, способным к работе в любом из множественных режимов кодирования, таких как режим кодирования с малой задержкой для связи в реальном времени, режим транскодирования и режим регулярного кодирования для воспроизведения медиа из файла или потока, или это может быть инструмент кодирования специального назначения, приспособленный к одному такому режиму кодирования. Система (300) кодера может быть реализована как модуль операционной системы, в качестве части библиотеки приложений или как автономное приложение. В целом система (300) кодера принимает последовательность исходных кадров (311) видео из источника (310) видео и формирует кодированные данные в качестве вывода в канал (390). Закодированный вывод данных на канал может включать в себя один или более синтаксических элементов, которые описаны в разделе V.
[037] Источник (310) видео может быть камерой, картой тюнера, запоминающими носителями или другим источником цифрового видео. Источник (310) видео формирует последовательность видеокадров со скоростью передачи кадров, например, 30 кадров в секунду. Как используется здесь, термин "кадр" в целом относится к исходным, закодированным или восстановленным данным изображения. Для видео с прогрессивной разверткой кадр является кадром с прогрессивной разверткой видео. Для видео с чересстрочной разверткой в примерных вариантах осуществления видеокадр с чересстрочной разверткой деперемежается до кодирования. Альтернативно, два комплементарных видеополя с чересстрочной разверткой кодируются как видеокадр или отдельные поля с чересстрочной разверткой. Помимо указания видео кадра с прогрессивной разверткой, термин "кадр" может указывать единственное непарное поле видео, пару комплементарных видеополей, плоскость объекта видео, которая представляет видеообъект в заданный момент или область интереса в большем изображении. Плоскость объекта или область видео могут быть частью большего изображения, которое включает в себя множественные объекты или области сцены.
[038] Поступающий исходный кадр (311) сохраняется в запоминающей области (320) временной памяти исходных кадров, которая включает в себя множественные запоминающие области (321, 322,..., 32n) буфера кадров. Буфер (321, 322, и т.д.) кадров хранит один исходный кадр в запоминающей области (320) исходных кадров. После того как один или более исходных кадров (311) были сохранены в буферах (321, 322, и т.д.) кадров, селектор (330) кадров периодически выбирает отдельный исходный кадр из запоминающей области (320) исходных кадров. Порядок, в котором кадры выбираются селектором (330) кадров для ввода в кодер (340), может отличаться от порядка, в котором кадры сформированы видеоисточником (310), например, кадр может быть опережающим, чтобы облегчить обратное во времени предсказание. Перед кодером (340) система (300) кодера может включать в себя препроцессор (не показан), который выполняет предварительную обработку (например, фильтрацию) выбранного кадра (331) перед кодированием.
[039] Кодер (340) кодирует выбранный кадр (331), чтобы сформировать закодированный кадр (341) и также формирует сигналы управления администрированием памяти (342). Если текущий кадр не является первым кадром, который был закодирован при выполнении процесса его кодирования, кодер (340) может использовать один или более ранее закодированных/декодированных кадров (369), которые были сохранены в запоминающей области (360) временной памяти декодированных кадров. Такие сохраненные декодированные кадры (369) используются в качестве опорных кадров для межкадрового предсказания содержимого текущего исходного кадра (331). Обычно кодер (340) включает в себя множественные модули кодирования, которые выполняют задачи кодирования, такие как оценка движения и компенсация, преобразование частот, квантование и энтропийное кодирование. Точные операции, выполняемые кодером (340), могут изменяться в зависимости от формата сжатия. Формат закодированных данных вывода может быть форматом Windows Media Video, форматом VC-1, форматом MPEG-x (например, MPEG-1, MPEG-2 или MPEG-4), форматом H.26x (например, H.261, H.262, H.263, H.264), форматом HEVC или другим форматом.
[040] Кодированные кадры (341) и информация BDL (342) обрабатываются эмулятором (350) процесса декодирования. Эмулятор (350) процесса декодирования реализует некоторые из функциональных возможностей декодера, например, задачи декодирования для восстановления опорных кадров, которые используются кодером (340) при оценке и компенсации движения. Эмулятор (350) процесса декодирования использует информацию BDL (342), чтобы определить, должен ли заданный кодированный кадр (341) быть восстановлен и сохранен для использования в качестве опорного кадра при межкадровом предсказании последующих кадров, которые должны быть закодированы. Если информация BDL (342) указывает, что закодированный кадр (341) должен быть сохранен, эмулятор (350) процесса декодирования моделирует процесс декодирования, который мог бы быть проведен декодером, который принимает закодированный кадр (341) и формирует соответствующий декодированный кадр (351). При этом, когда кодер (340) использовал декодированный кадр(ы) (369), которые были сохранены в запоминающей области (360) декодированных кадров, эмулятор (350) процесса декодирования также использует декодированный кадр(ы) (369) из запоминающей области (360) в качестве части процесса декодирования.
[041] Запоминающая область (360) временной памяти декодированных кадров включает в себя множественные запоминающие области (361, 362,..., 36n) буфера кадров. Эмулятор (350) процесса декодирования использует информацию BDL (342), чтобы управлять содержимым запоминающей области (360), чтобы идентифицировать любые (361, 362, и т.д.) буферы кадров с кадрами, которые больше не являются необходимыми кодеру (340) для использования в качестве опорных кадров. После моделирования процесса декодирования эмулятор (350) процесса декодирования сохраняет недавно декодированный кадр (351) в буфере (361, 362, и т.д.) кадров, который был идентифицирован этим способом.
[042] Кодированные кадры (341) и информация BDL (342) также буферизуются в закодированной области (370) временных кодированных данных. Кодированные данные, которые агрегированы в области (370) кодированных данных, могут содержать, в качестве части синтаксиса элементарного кодированного потока битов видео, один или более синтаксических элементов, которые описаны в разделе V. Альтернативно, кодированные данные, которые агрегированы в области (370) кодированных данных, могут включать в себя синтаксический элемент(ы), такие как описаны в разделе V в качестве части метаданных медиа, относящихся к данным кодированного видео (например, в качестве одного или более параметров в одном или более сообщениях информации дополнительного расширения ("SEI") или сообщениях информации удобства и простоты использования видео ("VUI")).
[043] Агрегированные данные (371) из закодированной области (370) временных кодированных данных обрабатываются кодером (380) канала. Кодер (380) канала может пакетизировать агрегированные данные для передачи в качестве потока медиа, в этом случае кодер (380) канала может в некоторых случаях добавить, в качестве части синтаксиса потока передачи медиа, синтаксический элемент(ы), такие как описаны в разделе V. Или кодер (380) канала может организовать агрегированные данные для хранения в качестве файла, в этом случае кодер (380) канала может в некоторых случаях добавить, в качестве части синтаксиса файла хранения медиа, синтаксический элемент(ы), такие как описаны в разделе V. Или, более широко, кодер (380) канала может реализовать один или более протоколов мультиплексирования системы медиа или транспортных протоколов, этом случае кодер (380) канала может в некоторых случаях добавить, в качестве части синтаксиса протокола(ов), синтаксический элемент(ы), такие как описаны в разделе V. Кодер (380) канала обеспечивает выходной сигнал на канал (390), который представляет запоминающее устройство, соединение связей или другой канал для вывода.
[044] Фиг. 4a показывает примерный способ (400) для установки и вывода одного или более синтаксических элементов, которые описаны в разделе V. Например, инструмент связи в реальном времени или инструмент кодирования, описанный со ссылками на фиг. 2a и 2b, выполняет способ (400). Альтернативно, другой инструмент выполняет способ (400). В качестве начала инструмент (410) устанавливает один или более синтаксических элементов, которые описаны в разделе V. Инструмент затем выводит (420) эти один или более синтаксических элементов.
[045] Фиг. 4b показывает конкретный пример (401) способа (400), сосредотачиваясь на сигнализации идентифицирующей информации для долгосрочных опорных картинок ("картинок LTRP"). Например, инструмент связи в реальном времени или инструмент кодирования, описанный со ссылками на фиг. 2a и 2b, выполняют способ (401). Альтернативно, другой инструмент выполняет способ (401).
[046] В качестве начала инструмент определяет (405) информацию состояния, которая идентифицирует, какие картинки доступны для использования в качестве опорных картинок (то есть в настоящее время доступны для видеокодера для использования в качестве опорных картинок; ожидаются быть доступными для видеодекодера для использования в качестве опорных картинок в этот момент при декодировании). Инструмент затем устанавливает (411) синтаксические элементы, которые представляют информацию состояния. В частности, инструмент устанавливает идентифицирующую информацию для LTRP. Идентифицирующая информация для LTRP является значением наименьших значащих битов отсчета по порядку картинки ("LSB в POC") для этой LTRB. Картинки, доступные для использования в качестве опорных картинок, могут также включать в себя краткосрочную опорную картинку ("STRP"). В этом случае инструмент может снова использовать значение LSB в POC для LTRB в качестве значения LSB в POC для этой STRB, но отметить LTRB в качестве используемой для долгосрочной ссылки, чтобы различать LTRP и STRP.
[047] Синтаксические элементы, которые сигнализируются в потоке битов, могут включать в себя другие и/или дополнительные синтаксические элементы. Например, инструмент определяет, включать ли информацию статуса о картинках LTRP в поток битов для картинок последовательности, и выводит, в качестве части набора параметра последовательности, флаг, который указывает, присутствует ли информация статуса о картинках LTRP в потоке битов для картинок последовательности. Или инструмент устанавливает количество битов для LSB в POC, чтобы использовать для значений LSB POC для картинок LTRB, затем выводит синтаксический элемент, который указывает количество битов для LSB POC (например, синтаксический элемент, который представляет логарифм по основанию 2 точки свертывания для LSB в POC относительно постоянного значения, такой как синтаксический элемент log2_max_pic_order_cnt_lsb_minus4). Или инструмент использует и сигнализирует другие синтаксические элементы, описанные в разделе V.
[048] Инструмент затем выводит (421) синтаксические элементы в качестве части потока битов. Например, инструмент сигнализирует синтаксические элементы в элементарном кодированном потоке битов видео для текущей картинки. Альтернативно, синтаксические элементы сигнализируются на некотором другом уровне синтаксиса потока битов.
IV. ПРИМЕРНЫЕ СИСТЕМЫ ДЕКОДЕРА
[049] Фиг. 5 является блок-схемой примерной системы (500) декодера в соединении с которой могут быть реализованы некоторые описанные варианты осуществления. Система (500) декодера может быть инструментом декодирования общего назначения, способным работать в любом из множественных режимов декодирования, таких как режим декодирования с низким временем ожидания для связи в реальном времени и режим регулярного декодирования для воспроизведения медиа из файла или потока, или он может быть инструментом декодирования специального назначения, приспособленным к одному такому режиму декодирования. Система (500) декодера может быть реализована как модуль операционной системы, в качестве части библиотеки приложений или как автономное приложение. В целом система (500) декодера принимает кодированные данные из канала (510) и формирует восстановленные кадры в качестве вывода для адресата (590) вывода. Кодированные данные могут включать в себя один или более синтаксических элементов, которые описаны в разделе V.
[050] Система (500) декодера включает в себя канал (510), который может представлять запоминающее устройство, соединение для связи или другой канал для закодированных данных в качестве вывода. Канал (510) формирует кодированные данные, которые были закодированным каналом. Декодер (520) канала может обрабатывать кодированные данные. Например, декодер (520) канала де-пакетизирует данные, которые были агрегированы для передачи в качестве потока медиа, в этом случае декодер (520) канала может синтаксически разобрать, в качестве части синтаксиса потока передачи медиа, синтаксический элемент(ы), такие как описаны в разделе V. Или декодер (520) канала отделяет закодированные видеоданные, которые были агрегированы для сохранения в качестве файла, когда декодер (520) канала может синтаксически разобрать, в качестве части синтаксиса файла хранения медиа, синтаксический элемент(ы), такие как описаны в разделе V. Или, более широко, декодер (520) канала может реализовать один или более протоколов демультиплексирования системы медиа или транспортных протоколов, когда декодер (520) канала может синтаксически разобрать, в качестве части синтаксиса протокола(ов), синтаксический элемент(ы), такие как описаны в разделе V.
[051] Кодированные данные (521), которые выведены из декодера (520) канала, сохраняются в области (530) временных кодированных данных, пока достаточное количество таких данных не будет принято. Кодированные данные (521) включают в себя кодированные кадры (531) и информацию BDL (532). Кодированные данные (521) в области (530) кодированных данных могут содержать, в качестве части синтаксиса элементарного кодированного потока битов видео, один или более синтаксических элементов, таких как таковые в разделе V. Или кодированные данные (521) в области (530) кодированных данных могут включать в себя синтаксический элемент(ы), такие как описаны в разделе V, в качестве части метаданных медиа, относящихся к кодированным данным видео (например, в качестве одного или более параметров в одном или более сообщениях SEI или сообщениях VUI). Обычно область (530) кодированных данных временно хранит кодированные данные (521), пока такие кодированные данные (521) не будут использованы декодером (550). В этот момент кодированные данные для кодированного кадра (531) и информация BDL (532) передаются из области (530) кодированных данных к декодеру (550). Поскольку декодирование продолжается, новые кодированные данные добавляются к области (530) кодированных данных, и самые старые кодированные данные, остающиеся в области (530) кодированных данных, передают декодеру (550).
[052] Декодер (550) периодически декодирует кодированный кадр (531), чтобы сформировать соответствующий декодированный кадр (551). Как является подходящим, при выполнении своего процесса декодирования декодер (550) может использовать один или более ранее декодированных кадров (569) в качестве опорных кадров для межкадрового предсказания. Декодер (550) считывает такие ранее декодированные кадры (569) из запоминающей области (560) временной памяти декодированных кадров. Обычно декодер (550) включает в себя множественные модули декодирования, которые выполняют задачи декодирования, такие как энтропийное декодирование, обратное квантование, обратное частотное преобразование и компенсацию движения. Точные операции, выполненные декодером (550), могут изменяться в зависимости от формата сжатия.
[053] Запоминающая область (560) временной памяти декодированных кадров включает в себя множественные запоминающие области (561, 562,..., 56n) буфера кадров. Запоминающая область (560) декодированных кадров является примером DPB. Декодер (550) использует информацию BDL (532), чтобы идентифицировать буфер (561, 562, и т.д.) кадров, в котором он может сохранить декодированный кадр (551). Декодер (550) сохраняет декодированный кадр (551) в этом буфере кадров.
[054] Блок (580) упорядочения вывода использует информацию BDL (532), чтобы идентифицировать, когда следующий кадр, который должен быть сформирован в порядке вывода, является доступным в запоминающей области (560) декодированных кадров. Когда следующий кадр (581), который должен быть сформирован в порядке вывода, доступен в запоминающей области (560) декодированных кадров, он считывается блоком (580) упорядочения вывода и выводится к адресату (590) вывода (например, дисплею). Обычно порядок, в котором кадры выводятся из запоминающей области (560) декодированных кадров блоком (580) упорядочения вывода, может отличаться от порядка, в котором кадры декодируются декодером (550).
[055] Фиг. 6a показывает примерный способ (600) для приема и синтаксического разбора синтаксических элементов, которые описаны в разделе V. Например, инструмент связи в реальном времени или инструмент воспроизведения, описанный со ссылками на фиг. 2a и 2b, выполняет способ (600). Альтернативно, другой инструмент выполняет способ (600). В начале инструмент принимает (610) один или более синтаксических элементов, которые описаны в разделе V. Инструмент затем синтаксически разбирает (620) эти один или более синтаксических элементов. Инструмент может затем использовать синтаксические элементы, которые описаны в разделе V.
[056] Фиг. 6b показывает конкретный пример (601) способа (600), сосредотачиваясь на том, чтобы синтаксически разбирать идентифицирующую информацию для картинок LTRP. Например, инструмент связи в реальном времени или инструмент воспроизведения, описанный со ссылками на фиг. 2a и 2b, выполняет способ (601). Альтернативно, другой инструмент выполняет способ (601).
[057] В начале инструмент принимает (611) по меньшей мере часть потока битов. Например, поток битов является элементарным кодированным потоком битов видео. Инструмент синтаксически разбирает (621) (выделяет) синтаксические элементы из потока битов. Синтаксические элементы представляют информацию состояния, которая идентифицирует, какие картинки доступны для использования в качестве опорных картинок (то есть в настоящее время доступны для видеокодера для использования в качестве опорных картинок; ожидаются быть доступными для видеодекодера для использования в качестве опорных картинок в этот момент при декодировании). Например, синтаксические элементы, которые представляют информацию состояния, сигнализируются в потоке битов для текущей картинки. Альтернативно, синтаксические элементы сигнализируются на некотором другом уровне синтаксиса потока битов.
[058] В частности, синтаксические элементы включают в себя идентифицирующую информацию для LTRP. Идентифицирующая информация для LTRP является значением LSB в POC для этой LTRB. Картинки, доступные для использования в качестве опорных картинок, могут также включать в себя STRP. В этом случае инструмент может снова использовать значение LSB в POC для LTRB в качестве значения LSB в POC для этой STRB, но отметить LTRB как используемую для долгосрочной ссылки, чтобы различать LTRP и STRP.
[059] Синтаксические элементы, которые сигнализируются в потоке битов, могут включать в себя другие и/или дополнительные синтаксические элементы. Например, инструмент синтаксически выделяет, из набора параметров последовательности, флаг, который указывает, присутствует ли информация статуса о картинках LTRP в потоке битов для картинок последовательности. Или инструмент синтаксически разбирает синтаксический элемент, который указывает количество битов для LSB POC, чтобы использовать для значений LSB в POC для картинок LTRB, используя количество битов для LSB в POC при синтаксическом разборе идентифицирующей информации для этой LTRP.
[060] Инструмент (631) использует идентифицирующую информацию во время декодирования. Например, инструмент использует информацию состояния, чтобы управлять запоминающей областью декодированных картинок в видеодекодере в качестве части декодирования.
V. УСОВЕРШЕНСТВОВАНИЯ В СИГНАЛИЗАЦИИ СОСТОЯНИЯ DBP И СПИСКИ RPL
[061] Различные подходы были представлены для того, чтобы использовать информацию BDL в соединении со стандартом HEVC. Один подход описан в документе JCTVC-F493, названном "Absolute signaling of Reference Pictures" и включая "Proposed Changes to the HEVC Working Draft." Другие подходы описаны в JCTVC-F803_dl_Buffer_Descriptions_r0, названном "WD4: Working Draft 4 of High-Efficiency Video Coding" и JCTVC-F803_dl_Buffer_Descriptions_display_process_suggestion_rl, также названном "WD4: Working Draft 4 of High-Efficiency Video Coding". Этот раздел описывает конкретные изменения относительно подходов, показанных в документации для JCTVC-F803_dl. Эти изменения расширяют некоторые из понятий, предложенных в JCTVC-F493. Различные новшества, описанные в этом разделе, могут использоваться в комбинации или отдельно.
A. ФЛАГ БУДУЩЕЙ ОПОРНОЙ ССЫЛКИ
[062] Согласно одному новшеству, описанному в настоящем описании, кодер и декодер используют флаг будущей опорной ссылки для каждой опорной картинки информации BDL, где флаг будущей опорной ссылки указывает, используется ли опорная картинка только для декодирования текущей картинки или используется для декодирования по меньшей мере одной будущей картинки в кодированном порядке. Флаг будущей опорной ссылки таким образом указывает, сохраняется ли опорная картинка после того, как текущая картинка декодирована. В примерных реализациях флаг будущей опорной ссылки является новым синтаксическим элементом, названным mark_unused_after_decoding_flag, который добавляется для каждой картинки в BDL. Этот синтаксический элемент допускает использование полного размера DPB в соединении с информацией BDL.
[063] Если местоположение операции маркировки опорной картинки перемещается ранее в процессе декодирования, это может сократить количество опорных картинок, которые могут быть сохранены в буфере. Если емкость DPB равна N картинок и текущая картинка является опорной картинкой, то не будет пространства, чтобы сохранить текущую картинку в буфере, если только полный размер BDL не превышает N-1 картинок. Это является на одну картинку меньше, чем это возможно при использовании синтаксиса AVC, так как в синтаксисе AVC (1) сначала на картинки, которые находятся в буфере, ссылаются для процесса декодирования, (2) затем любые картинки, которые больше не являются необходимыми, отвергаются (то есть отмечаются как "неиспользуемые для ссылки", что создает пространство в буфере для новой картинки), и (3) затем текущая картинка сохраняется в буфере для потенциального использования в процессе декодирования последующих картинок. Перемещая процесс маркировки к моменту перед использованием картинок в качестве ссылок, количество картинок, на которые можно сослаться для заданной полной емкости буфера, сокращается на 1. Уменьшение полной емкости буфера очень нежелательно.
[064] Флаг будущей опорной ссылки может быть использован для разрешения этого ограничения на использование емкости DPB. В примерных реализациях однобитовый флаг, называемый mark_unused_after_decoding_flag, сигнализируется в BDL для каждой перечисленной картинки. Этот mark_unused_after_decoding_flag указывает, используется ли опорная картинка только для декодирования текущей картинки (ассоциированной с информацией BDL), или также используется для декодирования по меньшей мере одной более поздней картинки в порядке кодирования. Если опорная картинка используется для декодирования только текущей картинки, она может быть перезаписана декодированной текущей картинкой. Маркировка картинок посредством mark_unused_after_decoding_flag, равного 1 в качестве "неиспользуемой для ссылки", выполняется после процесса декодирования текущей картинки и перед сохранением текущей картинки в DPB. Например, если DPB хранит самое большее пять опорных картинок и является полным, если одна из этих пяти опорных картинок не используется для декодирования будущих картинок (как обозначено посредством mark_unused_after_decoding_flag), эта опорная картинка может быть перезаписана декодированной текущей картинкой. Таким образом, полная буферная емкость DPB может использоваться - кодер и декодер не должны резервировать пустое пространство в DPB для декодированной текущей картинки.
B. ФЛАГ РЕШЕНИЯ ВКЛ/ВЫКЛ ДЛЯ ФЛАГОВ БУДУЩЕЙ ОПОРНОЙ ССЫЛКИ
[065] Согласно другому новшеству, описанному в настоящем описании, флаг решения вкл/выкл сигнализируют для флагов будущей опорной ссылки. Кодер может не хотеть использовать флаги будущей опорной ссылки. Чтобы избежать посылки ненужных битов, кодер может использовать флаг решения вкл/выкл для флагов будущей опорной ссылки. Если флаг решения вкл/выкл "включен", то флаги будущей опорной ссылки используются. Иначе, если флаг решения вкл/выкл "выключен", то флаги будущей опорной ссылки не используются.
[066] Например, в примерных реализациях некоторые кодеры могут не хотеть использовать mark_unused_after_decoding_flag. Чтобы избежать посылки ненужных битов такими кодерами, на уровне SPS добавляют флаг, названный no_final_referencing_flag. Когда no_final_referencing_flag равен 1, синтаксический элемент mark_unused_after_decoding_flag опускается из потока битов. В этом случае декодер не принимает, синтаксически не разбирает, не использует и т.д. синтаксические элементы mark_unused_after_decoding_flag. Иначе, декодер принимает, синтаксически разбирает, использует и т.д. синтаксические элементы mark_unused_after_decoding_flag.
C. МАРКИРОВКА КАРТИНОК БОЛЕЕ НИЗКИХ ВРЕМЕННЫХ УРОВНЕЙ
[067] Согласно другому новшеству, описанному в настоящем описании, в информации BDL для картинки, ассоциированной с более высоким временным уровнем, информация маркировки опорной картинки может отметить одну или более картинок в более низком временном уровне как неиспользуемую для ссылки. В некоторых сценариях может быть полезно разрешить такие опции для управления опорными картинками для картинок в более высоком временном уровне. И когда более поздняя информация BDL испытывает недостаток в информации статуса опорных картинок, ранее удаленных с информацией BDL для картинки в более высоком временном уровне, декодер может логически вывести удаление таких опорных картинок.
[068] В некоторых подходах к сигнализации состояния DPB картинки в более высоких временных уровнях запрещаются от пометки картинки в более низких временных уровнях как "неиспользуемые для ссылки". Используя BDL-тип синтаксиса, как описано здесь, однако такие запрещения не имеют смысла. Как только картинка была опущена из BDL, она не появляется ни в каком-либо из последующих BDL, таким образом нет никакой опасности для декодера, пропускающего уведомление, пометить картинку как "неиспользуемую для ссылки."
D. ФЛАГ ОБОЗНАЧЕНИЯ КАРТИНКИ БОЛЕЕ ВЫСОКОГО УРОВНЯ
[069] Согласно другому новшеству, описанному в настоящем описании, кодер и декодер используют флаг обозначения картинки более высокого уровня для каждой картинки более высокого временного уровня в информации BDL, где флаг обозначения картинки более высокого уровня определяет картинку как относящуюся к более высокому временному уровню в целях информации BDL. Во многих сценариях картинки более высокого временного уровня не используются в качестве опорных картинок. Процесс управления и обновления DPB может быть упрощен для таких картинок. Когда информация BDL используется вообще для картинок более высокого временного уровня, простой флаг для каждой картинки в информации BDL может быть достаточным, чтобы определить картинку как ассоциированную с более высоким временным уровнем, где действия по управлению и обновлению DPB подразумеваются.
[070] В примерных реализациях простой higher_layer_picture_flag может быть послан для каждой картинки в BDL, чтобы указывать, находится или нет эта картинка в более высоком временном уровне. В некоторых сценариях может быть желательно включать информацию для картинок в более высоких временных уровнях в информацию BDL, чтобы быть в состоянии явно указывать, что некоторые такие картинки должны быть отмечены как "неиспользуемые для ссылки." Даже если эти картинки перечислены в BDL информации, однако посылка деталей, таких как фактический номер уровня, не является необходимой. Вместо этого простой higher_layer_picture_flag посылают для каждой картинки в BDL, чтобы указывать, находится ли картинка в более высоком временном уровне. Когда higher_layers_not_listed_flag равен 1, любые картинки в более высоких временных уровнях предлагаются быть оставленными незатронутыми процессом декодирования текущей картинки - просто оставляя их существующий статус маркировки.
E. ФЛАГ РЕШЕНИЯ ВКЛ/ВЫКЛ ДЛЯ ФЛАГОВ ОБОЗНАЧЕНИЯ КАРТИНОК БОЛЕЕ ВЫСОКОГО УРОВНЯ
[071] Согласно другому новшеству, описанному в настоящем описании, кодер и декодер используют флаг решения вкл/выкл для включения информации статуса о картинках более высоких временных уровней в информацию BDL. Например, флаг решения вкл/выкл может быть сигнализирован в качестве части SPS и указывать присутствие/отсутствие информации статуса о картинках более высоких временных уровней в информации BDL.
[072] В примерных реализациях флаг, называемый higher_layers_not_listed_flag, добавляется на уровне SPS. Когда этот флаг равен 1, картинки более высоких временных уровней не включаются в BDLs в CVS. В предшествующих предложениях картинки более высоких временных уровней включаются в BDLs. На такие картинки фактически никогда не ссылаются в процессе декодирования текущей картинки, и это известно декодеру. Так как эти картинки являются нерелевантными декодированию текущей картинки и любых последующих картинок в текущем временном уровне и любом более низком временном уровне, есть сомнительное значение включения их в BDL во многих случаях использования, и поэтому желательно избежать обременять синтаксис этими дополнительными данными, которые являются нерелевантными процессу декодирования декодируемых уровней.
F. ИНФОРМАЦИЯ BDL НА УРОВНЕ APS
[073] Согласно другому новшеству, описанному в настоящем описании, информация BDL сигнализируется на уровне адаптивного набора параметров слайса ("APS"). Единственный набор информации BDL ассоциирован с APS.
[074] Идея наличия множественных списков буферов в наборе параметров не является изящной и не является необходимой. Понятие множественных списков с индексом для идентификации выбранного BDL является отчасти новым гибридным уровнем синтаксиса, который кажется излишне сложным и предвосхищает конструкцию кодера, которая предварительно планирует свои структуры BDL заранее способом, который кажется ненужным. Кроме того, с BDL, постоянно находящимся в APS, не может быть никакой необходимости в способности не принимать во внимание APS-уровень BDL в уровне заголовка слайса (вырезки). Таким образом, при отсутствии соответствующих оснований, информация BDL сигнализируется только на уровне APS или выше.
G. УПРОЩЕННЫЙ СИНТАКСИС ДЛЯ LTRP В ИНФОРМАЦИИ BDL
[075] Согласно другому новшеству, описанному в настоящем описании, кодер и декодер используют информацию статуса для картинок LTRP в информации BDL. Картинки LTRP обеспечивают полезный элемент решения для кодирования и декодирования видео. Управление и обновление картинками LTRP в информации BDL представляют вызовы, как бы то ни было. Различные версии упрощенного синтаксиса для картинок LTRP в информации BDL предложены в настоящем описании, которые уменьшают скорость передачи в битах для информации статуса LTRP и упрощают управление DPB.
[076] Картинки LTRP являются полезным элементом решения, который фактически используется в некоторых продуктах специально для надежной связи в реальном времени. Аспекты картинок LTRP, как найдено в AVC, включают в себя не только способность хранить картинку в DPB в течение длительного времени, но также и в использовании различной обработки масштабирования вектора движения и вычислений с взвешенным предсказанием.
[077] В примерных реализациях функциональные возможности LTRP сохраняются и информация BDL учитывает управление LTRP. Некоторые существующие подходы к сигнализации информации статуса LTRP в информации BDL являются чрезмерно сложными в том, что они вовлекают полностью отдельное перечисление картинок LTRP и сигнализацию полных разностей POC, что не является подходящим. Например, LTRP идентифицируется ее полной разностью POC. Для LTRP, которая остается в DPB в течение очень длительного времени, длина кодового слова, необходимого для посылки ее разности POC, может стать чрезвычайно большой, что является тратой битов и вызывает проблемы синтаксического разбора декодером и в конечном счете ограничивает продолжительность, в течение которой LTRP может быть сохранена, используя этот синтаксис.
[078] Напротив, в примерных реализациях кодер и декодер используют информацию BDL с упрощенным синтаксисом для информации статуса LTRP, в которой только разность между младшими значащими битами ("LSBs") значений POC по модулю точки свертывания старших значащих битов ("MSB"), посылают, чтобы идентифицировать LTRP, а не полную разность POC. Не имеется реальной необходимости отслеживать значения MSB для значений POC - только относительный порядок действительно необходим для установления, и уход от указания отслеживания MSB может облегчить интерпретацию для таких намеченных функциональных возможностей в качестве декодирования произвольного доступа. Кроме того, избегая представления битов MSB этой разности, разность POC, посланная, чтобы идентифицировать LTRP, не должна становиться все большей и большей с течением времени. При соответствующих выборах структуры кодер не должен даже быть обеспокоен случаем посылки новой картинки, которая повторно использует те же самые LSB POC, которые используются существующей LTRP.
[079] Ниже представлены два возможных подхода в рамках этого рассмотрения. Оба включают в себя посылку для каждой картинки в информации BDL синтаксического элемента long_term_reference_flag. Второй подход (Схема B ниже) является несколько более простым. Первый подход (Схема А ниже) обеспечивает большую гибкость кодера.
[080] Согласно Схеме A, когда значение синтаксического элемента long_term_reference_flag изменяется от 0 до 1 для заданного значения LSB POC, оно помечает картинку как "используемая для долгосрочной ссылки" как в AVC. То же самое значение LSB в POC может снова использоваться для краткосрочной опорной картинки позже без введения в заблуждение. Для тех же LSB в POC картинка с long_term_reference_flag, равным 1, остается явно идентифицированной по сравнению с картинкой с long_term_reference_flag, равным 0. Только после маркировки LTRP как "неиспользуемая для ссылки" кодер (или декодер) может быть в состоянии заменить ее другой LTRP с тем же самым значением LSB POC.
[081] Для Схемы A патологические и переходные случаи, вовлекающие картинки LTRP и краткосрочные опорные картинки (STRP), обрабатываются следующим образом:
- Если до декодирования новой картинки буфер содержит только STRP для некоторых значений LSB POC и затем принимается информация BDL, которая содержит только LTRP для этого значения, STRP помечают как "используемая для долгосрочной ссылки" до декодирования текущей картинки.
- Если до декодирования новой картинки буфер содержит только LTRP для некоторого значения LSB POC и затем принимается информация BDL, которая содержит только STRP для этого значения, поток битов является неправомерным.
- Если до декодирования новой картинки буфер содержит и LTRP и STRP для одних и тех же значений LSB POC, и затем принимается информация BDL, которая содержит только STRP для этого значения, LTRP помечают как "неиспользуемая для ссылки".
- Если до декодирования новой картинки буфер содержит и LTRP и STRP для одних и тех же значений LSB POC и затем принимается информация BDL, которая содержит только LTRP для этого значения, STRP помечают как "неиспользуемая для ссылки".
[082] Согласно Схеме B картинка помечается как "используемая для долгосрочной ссылки" только посредством установки флага, который посылают, когда он декодируется (например, флаг, названный used_for_long_term_flag). Все последующие включения этой картинки в информацию BDL имеют long_term_reference_flag, равный 1, и значение long_term_reference_flag может быть использовано для различения LTRP и любой гипотетической краткосрочной опорной картинки, которая имеет одно и то же значение LSB POC.
H. ФЛАГ РЕШЕНИЯ ВКЛ/ВЫКЛ ДЛЯ ФЛАГОВ LTRP
[083] Согласно другому новшеству, описанному в настоящем описании, кодер и декодер используют решение вкл/выкл для флага для включения информации статуса о картинках LTRP в информацию BDL. Например, флаг решения вкл/выкл сигнализируется в качестве части SPS и указывает присутствие/отсутствие информации статуса о картинках LTRP в информации BDL.
[084] Так как некоторые кодеры могут не желать использовать картинки LTRP, в примерных реализациях посылают на уровне SPS флаг, названный no_long_term_pictures_flag. Когда этот флаг равен нулю, значения long_term_pictures_flag (и, в случае Схемы B, описанной выше, used_for_long_term_flag) не присутствуют в синтаксисе.
I. СОКРАЩЕНИЕ БИТОВ, ИСПОЛЬЗУЕМЫХ ДЛЯ ИДЕНТИФИЦИРУЮЩЕЙ ИНФОРМАЦИИ LTRP
[085] Согласно другому новшеству, описанному в настоящем описании, количество битов, использованных для идентификации картинок LTRP в информации BDL, уменьшается. Во многих сценариях использования количество картинок LTRP является малым и малое количество битов достаточно, чтобы идентифицировать картинки LTRP. Кодер может увеличить число битов, использованных для идентификации картинок LTRP для других сценариев использования.
[086] В примерных реализациях для схемы A или B синтаксис может стать еще более эффективным в случаях, когда количество LSB в POC, которые посылают, является малым. Например, если количество битов для LSB POC, которые должны быть посланы, равно 4 (как с log2_max_pic_order_cnt_lsb_minus4 в POC AVC типа 0), вместо некоторого большего количества, такого как 8, скорость передачи в битах, ассоциированная с информацией идентификации LTRB в информации BDL, может быть сокращена. Использование большего количества битов, чем 4, может быть ненужной нагрузкой во многих сценариях использования. В сценариях, где большее количество битов является подходящим, однако кодер может просто использовать большее значение, чем log2_max_pic_order_cnt_lsb_minus4 (или его эквивалент).
J. ЭФФЕКТИВНАЯ ОРГАНИЗАЦИЯ ИНФОРМАЦИИ BDL
[087] Согласно другому новшеству, описанному в настоящем описании, информация BDL организуется и посылается в порядке, используемом для конструирования RPL. Этот упрощает синтаксис в целях конструирования RPL.
[088] В примерных реализациях, так как сама информация BDL является списком картинок, она потенциально может быть послана в порядке, необходимом для прямого конструирования списка 0 из первых перечисленных картинок переданного списка. Если картинки перечислены в порядке списка 0, нет реальной необходимости в синтаксисе модификации списка опорных картинок для списка 0.
K. СИГНАЛИЗАЦИЯ, РАЗРЕШЕНЫ ЛИ ПРОМЕЖУТКИ ДЛЯ ЗНАЧЕНИЙ POC
[089] Согласно другому новшеству, описанному в настоящем описании, кодер сигнализирует, разрешены ли промежутки в значениях POC. Если промежутки не разрешены, декодер может распознать потери картинок, когда он определяет, что значения POC отсутствуют, и декодер может принять решения о картинках, являющихся готовым к выводу, на основании значений POC.
[090] В примерных реализациях флаг, названный poc_gaps_allowed_flag, посылают на уровне SPS. Когда этот флаг равен 0, все последовательные картинки в порядке вывода имеют последовательные значения LSB в POC без промежутков. Таким образом, декодер может распознать потери картинок посредством распознавания недостающих значений POC. Кроме того, использование синтаксических элементов poc_gaps_allowed_flag кодером позволят декодерам распознать последовательности картинок, которые готовы для вывода из порядка вывода, соответствующего декодеру. Если картинка с некоторым значением K POC была уже выведена, и картинка с значением K + 1 POC присутствует в DPB, декодер будет в состоянии обнаружить, что эта картинка с значением K+1 LSB в POC будет следующей картинкой, которая должна быть выведена. И если такая картинка с значением K+1 LSB в POC не присутствует в DPB, то декодер будет знать, что некоторая более поздняя картинка прибудет с этим значением LSB POC, если что-то пошло не так, как надо.
L. ЭНТРОПИЙНОЕ КОДИРОВАНИЕ И ДЕКОДИРОВАНИЕ СИНТАКСИЧЕСКИХ ЭЛЕМЕНТОВ ДЛЯ ИНФОРМАЦИИ BDL
[091] Согласно другому новшеству, описанному в настоящем описании, синтаксические элементы в информации BDL могут быть закодированы, используя усеченное экспоненциальное кодирование по Голомбу (то есть te(v)) вместо беззнакового экспоненциального кодирования по Голомбу. Различные синтаксические элементы для информации BDL были предложены для посылки в качестве кодированных значений ue(v). Часто количество выборов, доступных для этих синтаксических элементов, является малым. Таким образом, кодируя такие синтаксические элементы как значения te(v), можно улучшить эффективность. Декодер выполняет соответствующее энтропийное декодирование.
VI. ДОПОЛНИТЕЛЬНЫЕ УСОВЕРШЕНСТВОВАНИЯ В СИГНАЛИЗАЦИИ СОСТОЯНИЯ DBP И RPL
[092] В некоторых реализациях видеокодер и видеодекодер могут следовать дополнительным ограничениям, чтобы упростить и улучшить надежность вычисления POC. С или без таких ограничений в различных сценариях использования видеокодер и видеодекодер могут использовать сигнализированную информацию состояния, которая идентифицирует, какие картинки доступны для использования в качестве опорных картинок.
A. ПЕРВЫЕ ПОДХОДЫ К ПОВЫШЕНИЮ НАДЕЖНОСТИ ВЫЧИСЛЕНИЯ POC
[093] В первом наборе примерных подходов вводится ограничение, что все картинки, которые используются в качестве опорных ссылок или ожидают вывода, имеют относительные позиции POC, которые могут быть вычислены однозначно относительно POC текущей картинки. Это разрешает потенциальные проблемы надежности способом, которым отслеживаются значения MSB в POC.
[094] Например, предположим, что значение свертывания POC равно 16 (и размер DPB является достаточно большим для вывода картинки, который должен быть отсрочен, и все картинки являются опорными картинками). Если значения LSB в POC для последовательных картинок в порядке декодирования являются 5, 11, 2, то, когда картинка с значением LSB в POC, равным 2, декодируется, позиция картинки с значением LSB в POC, равным 5, является неоднозначной относительно текущей картинки с значением LSB в POC, равным 2. Если картинка с значением LSB в POC, равным 11, будет потеряна, то другие две картинки будут выведены в неправильном относительном порядке. (Кроме того, временное масштабирование векторов движения будет неправильным, конструирование списка опорных картинок будет неправильным, и временное взвешенное предсказание станет неправильным.)
[095] Налагая ограничение и соотнося все относительные значения POC к значению POC для текущей картинки, необходимость отслеживать фактические MSB в POC для картинок в буфере устраняется. В этом подходе относительные позиции POC остаются правильными пока картинки остаются в буфере. Это облегчает некоторые вопросы о проблемах, которые могут произойти при использовании небольшого количества LSB для POC, но это решает проблему более полным способом, чем посредством установления в качестве обязательного большее минимальное количество LSB в POC.
B. ВТОРЫЕ ПОДХОДЫ К ПОВЫШЕНИЮ НАДЕЖНОСТИ ВЫЧИСЛЕНИЯ POC
[096] Когда декодер логически выводит значения MSB для POC, ассоциированные с каждой декодированной картинкой, может иметь место несколько проблем. Значения MSB логически выводятся из истории процесса декодирования из «от картинки к картинке» по всей кодированной видеопоследовательности, и удаление одной или более картинок из потока битов может привести к искажению значений MSB. Это в свою очередь может вызвать воспроизведение остающихся картинок не по порядку, неправильное построение списка опорных картинок и неправильное временное взвешенное предсказание. Указание значений MSB посредством логического вывода может также вызывать трудности для произвольного доступа, так как декодер, который выполняет произвольный доступ в поток битов, не имеет доступа к предыдущим картинкам в закодированной последовательности видео.
[097] Во втором наборе примерных подходов, подобных первому набору примерных подходов, ограничение на относительное вычисление POC вводится в отношении значений LSB в POC для картинок в потоке битов (где значения LSB в POC выражены синтаксическим элементом pic_order_cnt_lsb). Следование этому ограничению может иметь незначительный эффект на эффективность кодирования, упрощение процесса декодирования для установления относительного порядка POC, устранение необходимости логического вывода значений MSB в POC и улучшение надежности в отношении потерь картинок. Таким образом, чтобы решить проблему надежности и избавиться от необходимости отслеживать фактические значения MSB в POC, вводится ограничение, что все картинки, которые используются в качестве опорных ссылок или ожидают вывода, имеют относительные позиции POC, которые могут быть вычислены однозначно относительно POC текущей картинки.
[098] Например, предположим, что количество LSB в POC, которые посылаются, равно 4, и поэтому значение свертывания POC равно 16 (и размер DPB является достаточно большим для вывода картинки, который должен быть отсрочен, и все картинки являются опорными картинками). Если значениями LSB в POC для последовательных картинок в порядке декодирования являются 5, 11, 2, то, когда картинка с значением LSB в POC, равным 2, декодируется, позиция картинки с значением LSB в POC, равным 5, является неоднозначной относительно текущей картинки с значением LSB в POC, равным 2. Если картинка с значением LSB в POC, равным 11, будет потеряна, то другие две картинки будут выведены в неправильном относительном порядке, временное масштабирование векторов движения будет неправильным, конструирование списка опорных картинок будет неправильным и временное взвешенное предсказание станет неправильным.
[099] Налагая это ограничение и соотнося все относительные значения POC к значению LSB в POC для текущей картинки, необходимость отслеживать фактические MSB в POC для картинок в буфере устраняется. В этом подходе относительные позиции POC остаются корректными, пока картинки остаются в буфере для целей краткосрочной ссылки или порядка вывода. Это облегчает некоторые вопросы о проблемах, которые могут произойти при использовании малого количества LSB для POC, но это решает проблему более полным способом, чем посредством установления в качестве обязательного большего минимального количества LSB в POC.
[0100] В комбинации с этим ограничением для относительного вычисления POC или в комбинации с другим подходом к вычислению значений POC, кодер может применить ограничение в отношении диапазона значений POC. Например, кодер устанавливает значения POC во время кодирования таким образом, что диапазон значений POC (разность между максимумом и минимумом для заданной картинки и ее опорных картинок) ограничен порогом, который зависит от максимального значения, возможного для LSB в POC. Примеры этого ограничения описаны ниже.
[0101] Инструмент связи в реальном времени или инструмент кодирования, описанный со ссылками на фиг. 2a и 2b, может выполнить кодирование, подвергая одному или обоим из этих ограничений в отношении значений POC. Альтернативно, другой инструмент выполняет способ. В начале инструмент устанавливает значения POC для картинок, подлежащих ограничению(ям). Например, ограничение ограничивает диапазон значений LSB в POC для текущей картинки и ее опорных картинок, как описано ниже. Инструмент затем кодирует видео для картинок, производя совместимый поток битов. В этом потоке битов инструмент может сигнализировать значения POC (например, используя синтаксические элементы, которые указывают LSB в POC), которые совместимы с примененным ограничением(ями).
1. ПРИМЕРНЫЙ ПОДХОД БЕЗ ОТНОСИТЕЛЬНОГО ВЫЧИСЛЕНИЯ POC
[0102] В примерном подходе без относительного вычисления POC значения POC декодируют следующим образом. Выходными данными этого процесса является PicOrderCntVal, POC текущей картинки. POC используются для идентификации картинок, для получения параметров движения во временном или пространственном прямом режиме, для представления разностей порядка картинок между кадрами для выведения вектора движения, для взвешенного предсказания неявного режима в слайсах B и для проверки соответствия декодера. Каждая закодированная картинка ассоциирована с одной POC, названной PicOrderCntVal, которая указывает порядок картинки соответствующей картинки относительно предыдущей картинки IDR в порядке декодирования.
[0103] Переменные prevPicOrderCntLsb и prevPicOrderCntMsb получают следующим образом. Если текущей картинкой является картинка IDR, обе prevPicOrderCntLsb и prevPicOrderCntMsb устанавливают равными 0. Иначе (текущая картинка не является картинкой IDR): (a) пусть prevRefPic является предыдущей опорной картинкой в порядке декодирования, которая имеет temporal_id равный 0; (b) переменная prevPicOrderCntLsb установлена равной pic_order_cnt_lsb для prevRefPic, и переменная prevPicOrderCntMsb установлена равной PicOrderCntMsb prevRefPic.
[0104] PicOrderCntMsb текущей картинки получают так, как определено в соответствии с листингом (700) на псевдокоде, показанной на фиг. 7a. Альтернативно, эквивалентная логика может быть использована для получения PicOrderCntMsb текущей картинки. Затем значение PicOrderCntVal выводят как:
PicOrderCntVal=PicOrderCntMsb+pic_order_cnt_lsb
[0105] В этом примерном подходе картинки IDR имеют PicOrderCntVal, равную 0, так как pic_order_cnt_lsb был логически выведен равным 0 для картинок IDR и prevPicOrderCntLsb, и prevPicOrderCntMsb оба установлены равными 0. В заданной кодированной видеопоследовательности значения PicOrderCntVal для любых двух кодированных картинок должны быть различными.
[0106] В комбинации с этим примерным подходом кодер может применить ограничение на диапазон значений POC. Например, кодер устанавливает значения POC во время кодирования таким образом, что диапазон значений POC (разность между максимумом и минимумом для заданной картинки и ее опорных картинок) ограничен порогом, который зависит от максимального значения, возможного для LSB POC.
2. ПРИМЕРНЫЙ ПОДХОД С ОТНОСИТЕЛЬНЫМ ВЫЧИСЛЕНИЕМ POC
[0107] В другом примерном подходе значения POC декодируют следующим образом. Выходными данными процесса является PicOrderCntVal для текущей картинки и для каждой картинки в DPB, которая помечена как "используемая для краткосрочной ссылки" или "нуждается в выводе". Значения POC используются для идентификации картинок, для получения параметров движения во временном или пространственном прямом режиме, для представления разностей порядка картинок между кадрами для выведения вектора движения, для взвешенного предсказания неявного режима в слайсах B и для проверки соответствия декодера.
[0108] Переменная currPicOrderCntLsb устанавливается в значение синтаксического элемента pic_order_cnt_lsb, ассоциированного с текущей картинкой. Для текущей картинки и для каждой картинки в DPB, которая в настоящее время помечена как «используемая для краткосрочной ссылки" или "нуждается в выводе", ассоциированная переменная thatPicOrderCntLsb установлена в значение синтаксического элемента pic_order_cnt_lsb, ассоциированного с этой картинкой, и ассоциированная переменная PicOrderCntVal установлена, как показано в листинге (701) на псевдокоде, показанном на фиг. 7b.
[0109] Переменная maxPicOrderCnt установлена равной максимальному значению PicOrderCntVal среди ассоциированных значений для текущей картинки и всех картинок в DPB, которые в настоящее время помечены как «используемая для краткосрочной ссылки" или "нуждается в выводе". Переменная minPicOrderCnt установлена равной минимальному значению PicOrderCntVal среди ассоциированных значений для текущей картинки и всех картинок в DPB, которые в настоящее время помечены как «используемая для краткосрочной ссылки" или "нуждается в выводе". Ограничение в этом подходе зависит от переменных maxPicOrderCnt и minPicOrderCnt, рассматривая максимальное значение, возможное для LSBs в POC. Например, имеется требование согласования потока битов, что значение maxPicOrderCnt - minPicOrderCnt должно быть меньше чем MaxPicOrderCntLsb/2. Альтернативно, это ограничение реализуется в некоторой другой форме таким образом, что диапазон значений POC (разность между максимумом и минимумом) ограничен порогом, который зависит от максимального значения, возможного для LSBs в POC.
[0110] Функция PicOrderCnt(picX) определена как PicOrderCnt (picX)=PicOrderCntVal картинки picX. Функция DiffPicOrderCnt (picA, picB) определена как DiffPicOrderCnt (picA, picB)=PicOrderCnt (picA) - PicOrderCnt (picB). Например, пусть picX является текущей картинкой и picY и picZ являются двумя другими картинками в той же самой последовательности; picY и picZ рассматриваются находящимися в одном и том же направлении порядка вывода относительно picX, когда DiffPicOrderCnt (picX, picY) и DiffPicOrderCnt (picX, picZ) обе положительны или оба отрицательны. Многие кодеры назначают значения синтаксического элемента pic_order_cnt_lsb таким образом, что значения DiffPicOrderCnt (picA, picB), которые используются в процессе декодирования, (точно или приблизительно) пропорциональны разностям времени между временами осуществления выборки ассоциированных картинок picA и picB.
[0111] В этом примерном подходе значение PicOrderCntVal не имеет зависимостей от синтаксиса или процесса декодирования любых данных в потоке битов ниже уровня SPS, кроме pic_order_cnt_lsb текущей картинки и pic_order_cnt_lsb соответствующей картинки(ок), ассоциированных с переменной(ыми) PicOrderCntVal. Кроме того, нет необходимости накладывать ограничение на диапазон PicOrderCntVal, так как он естественно имеет ограниченный диапазон (в пределах диапазона - MaxPicOrderCntLsb до 2*MaxPicOrderCntLsb).
C. СЦЕНАРИИ ИСПОЛЬЗОВАНИЯ
[0112] В различных сценариях использования видеокодер и видеодекодер могут использовать сигнализированную информацию состояния, которая идентифицирует, какие картинки доступны для использования в качестве опорных картинок. Для однонаправленной связи, как в целом описано со ссылками на фиг. 2b, видеокодер может обеспечить закодированное видео в системе видеонаблюдения, системе мониторинга с web-камерой, удаленном настольном представлении конференц-связи или другом сценарии. Для двунаправленной связи, как в целом описано со ссылками на фиг. 2a, видеокодер может обеспечить закодированное видео для видеоконференции, видеотелефонного звонка или другого сценария двухсторонней связи.
[0113] Видеокодер может выбрать одну или более картинок LTRP, которые изображают элементы сцены, которые повторяются в видеопоследовательности. Например, для системы видеонаблюдения или системы мониторинга с web-камерой, видеокодер выбирает одну или более картинок LTRP, которые изображают второстепенные элементы сцены, которые последовательно появляются всюду в последовательности. Или для удаленного настольного представления конференц-связи видеокодер выбирает одну или более картинок LTRP, которые изображают элементы настольного пользовательского интерфейса или программного обеспечения приложений. Или для видеоконференции или видеотелефонного звонка видеокодер выбирает одну или более картинок LTRP, которые изображают второстепенные элементы сцены или относительно статические элементы участника (например, признаки сидящего человека). Во время кодирования видеокодер может определить, какие картинки LTRP сохранить как доступные опорные картинки на основании частоты, с которой картинки LTRP используются для компенсации движения, какие картинки LTRP были успешно восстановлены видеодекодером и/или другими факторами.
[0114] Видеокодер может периодически устанавливать картинки LTRP в исходное состояние (сбрасывать), чтобы облегчить воспроизведение, если клиентское вычислительное устройство переключает потоки (например, после изменения канала на другой поток или после переключения к потоку той же последовательности с отличной скоростью передачи в битах/качеством). Такая периодическая установка в исходное состояние картинок LTRP может также помочь клиентскому вычислительному устройству восстанавливаться после потерь или повреждения пакетов, которое может препятствовать тому, чтобы видеодекодер имел опорные картинки, которые, как он предполагает, имеются для правильного декодирования. Когда он устанавливает картинки LTRP в исходное состояние, видеокодер может использовать внутренне кодированные картинки, которые могут помочь обеспечить произвольный доступ и функциональные возможности восстановления, но также и иметь тенденцию иметь более высокую скорость передачи в битах, чем картинки с компенсацией движения.
[0115] В сценариях видеосвязи в реальном времени (например, видеоконференция, телефонный видеозвонок, удаленное настольное представление конференц-связи) видеокодер и видеодекодер могут взаимодействовать, чтобы облегчить восстановление после ошибок и сокрытие ошибок с более быстрым восстановлением и улучшенной эффективностью кодирования. Например, в серверном вычислительном устройстве видеокодер определяет информацию состояния, которая идентифицирует, какие картинки доступны для использования в качестве опорных картинок в видеокодере. (Такие картинки, как также ожидается, будут доступны для использования в качестве опорных картинок видеодекодером, когда декодирование достигает этой точки, принимая, что потери или повреждение пакетов неблагоприятно и не затрагивают реконструкцию для любой из опорных картинок). Затем серверное вычислительное устройство устанавливает синтаксические элементы, которые представляют информацию состояния, и выводит эти синтаксические элементы.
[0116] В клиентском вычислительном устройстве видеодекодер принимает и синтаксически разбирает синтаксические элементы, которые представляют информацию состояния, идентифицирующую, какие картинки доступны для использования в качестве опорных картинок в видеокодере (которые, как также ожидается, будут доступны для использования в качестве опорных картинок видеодекодером, когда декодирование достигает этой точки). Декодер может использовать эту информацию состояния во время декодирования, чтобы определить наборы опорных картинок. Или, декодер может использовать эту информацию состояния, чтобы инициализировать восстановление после ошибок и сокрытие ошибок. Потеря или повреждение пакетов могут предотвратить правильную реконструкцию одного или более указанных опорных картинок видеодекодером. Видеодекодер определяет информацию состояния (которую можно назвать новой информацией состояния, информацией состояния декодера, и т.д.), которая идентифицирует, какие картинки фактически доступны для использования в качестве опорных картинок видеодекодером. Видеодекодер устанавливает синтаксические элементы для информации обратной связи, которая представляет информацию состояния декодера. Видеодекодер посылает эту информацию обратной связи для использования видеокодером во время последующего кодирования. Это позволяет видеокодеру определять, какие картинки фактически доступны для ссылки в видеодекодере, используя ранее сигнализированную информацию состояния, так же как и информацию обратной связи от видеодекодера.
[0117] В серверном вычислительном устройстве видеокодер принимает информацию обратной связи, которая представляет информацию состояния декодера, и использует эту информацию обратной связи во время кодирования. Например, видеокодер использует информацию обратной связи, чтобы удалить одну или более картинок LTRP, которые видеодекодер правильно не восстановил. Или видеокодер в ином случае использует информацию обратной связи при решении, как кодировать одну или более последующих картинок относительно картинок LTRP, о которых информация обратной связи подтверждает, что будет доступной в видеодекодере. Видеокодер определяет информацию состояния, совместимую с информацией обратной связи, устанавливает синтаксические элементы, которые представляют информацию состояния, и выводит эти синтаксические элементы в битовом потоке. Таким образом, видеокодер может помочь видеодекодеру оправиться от потери или искажения пакетов более быстро способом, который является совместимым с базовыми особенностями кодирования и декодирования, с высокой эффективностью кодирования из-за использования картинок LTRP.
[0118] Видеодекодер может выдавать информацию обратной связи к видеокодеру периодически (например, для каждой картинки, для каждой группы из x картинок). Или видеодекодер может выдавать информацию обратной связи по требованию (например, когда видеодекодер идентифицирует несоответствие между принятой информацией состояния и опорными картинками, которые фактически доступны для видеодекодера). Видеодекодер может предоставить информацию обратной связи в отдельном канале обратной связи или для двунаправленной связи, мультиплексированной с закодированными видеоданными в исходящем потоке медиа.
[0119] Ввиду многих возможных вариантов осуществления, к которым могут быть применены принципы раскрытого изобретения, должно быть признано, что иллюстрированные варианты осуществления являются только предпочтительными примерами изобретения и не должны быть приняты как ограничивающие объем изобретения. Вместо этого объем изобретения определяется нижеследующей формулой изобретения. Поэтому заявляется в качестве изобретения все, что подпадает под объем и форму, как заявлено ниже.
Изобретение относится к технологиям кодирования/декодирования видеоданных. Техническим результатом является повышение эффективности кодирования/декодирования видео за счет принятия решений о том, какие опорные картинки больше не используются для ссылок. Предложен способ кодирования видео. Способ содержит этап, на котором осуществляют определение информации состояния, которая идентифицирует, какие картинки из последовательности видео доступны для использования в качестве опорных картинок для текущей картинки. Далее, устанавливают синтаксические элементы, которые представляют упомянутую информацию состояния, включая установку идентифицирующей информации для долгосрочной опорной картинки ("LTRP"), причем идентифицирующая информация для LTRP является значением младших значащих битов отсчета по порядку картинки ("LSB в РОС") для LTRP для текущей картинки. Осуществляют выведение синтаксических элементов в качестве части потока битов для дальнейшего использования при кодировании. 4 н. и 6 з.п. ф-лы, 11 ил.
1. Способ кодирования видео, при этом способ содержит:
определение информации состояния, которая идентифицирует, какие картинки из последовательности видео доступны для использования в качестве опорных картинок для текущей картинки;
установление синтаксических элементов, которые представляют упомянутую информацию состояния, включая установку идентифицирующей информации для долгосрочной опорной картинки ("LTRP"), причем идентифицирующая информация для LTRP является значением младших значащих битов отсчета по порядку картинки ("LSB в РОС") для LTRP для текущей картинки; и
выведение синтаксических элементов в качестве части потока битов для дальнейшего использования при кодировании;
использование флага будущей опорной ссылки для каждой опорной картинки в информации списка описания буфера (BDL), причем упомянутый флаг будущей опорной ссылки указывает, используется ли опорная картинка только для декодирования текущей картинки или, вместо этого, для декодирования по меньшей мере одной последующей картинки в кодированном порядке.
2. Способ по п. 1, причем способ дополнительно содержит:
определение, включать ли информацию статуса о картинках LTRP в поток битов для картинок последовательности; и
вывод, в качестве части набора параметра последовательности, флага, который указывает, присутствует ли информация статуса о картинках LTRP в потоке битов для картинок упомянутой последовательности.
3. Способ по п. 1, в котором картинки из упомянутой последовательности, доступные для использования в качестве опорных картинок, включают в себя краткосрочную опорную картинку ("STRP") и в котором способ дополнительно содержит:
повторное использование значения LSB в РОС для LTRP в качестве значения LSB в РОС для STRP; и
маркировку LTRP как используемую для долгосрочной ссылки, чтобы различать LTRP и STRP.
4. Способ по п. 1, причем способ дополнительно содержит:
установку количества битов для LSB в РОС, чтобы использовать для значений LSB в РОС для картинок LTRP; и
вывод синтаксического элемента, который указывает количество битов для LSB в РОС.
5. Способ декодирования видео, при этом способ содержит:
прием по меньшей мере части потока битов;
синтаксический разбор синтаксических элементов из потока битов, причем синтаксические элементы представляют информацию состояния, которая идентифицирует, какие картинки из последовательности видео доступны для использования в качестве опорных картинок для текущей картинки, причем синтаксические элементы включают в себя идентифицирующую информацию для долгосрочной опорной картинки ("LTRP"), при этом упомянутая идентифицирующая информация для LTRP является значением младших значащих битов отсчета по порядку картинки ("LSB в РОС") для LTRP для текущей картинки; и
использование идентифицирующей информации во время декодирования,
использование флага будущей опорной ссылки для каждой опорной картинки в информации списка описания буфера (BDL), причем упомянутый флаг будущей опорной ссылки указывает, используется ли опорная картинка только для декодирования текущей картинки или, вместо этого, для декодирования по меньшей мере одной последующей картинки в кодированном порядке.
6. Способ по п. 5, дополнительно содержащий:
синтаксический разбор, из набора параметра последовательности, флага, который указывает, присутствует ли информация статуса о картинках LTRP в потоке битов для картинок последовательности.
7. Способ по п. 5, в котором картинки, доступные для использования в качестве опорных картинок, включают в себя краткосрочную опорную картинку ("STRP") и в котором способ дополнительно содержит:
повторное использование значения LSB в РОС для LTRP в качестве значения LSB в РОС для STRP; и
маркировку LTRP как используемую для долгосрочной ссылки, чтобы различать LTRP и STRP.
8. Способ по п. 5, дополнительно содержащий:
синтаксический разбор синтаксического элемента, который указывает количество битов для LSB в РОС, чтобы использовать для значений LSB в РОС для картинок LTRP; и
использование упомянутого количества битов для LSB в РОС при синтаксическом разборе идентифицирующей информации для LTRP.
9. Один или более считываемых компьютером запоминающих носителей, хранящих выполнимые компьютером инструкции для того, чтобы вынудить вычислительную систему, запрограммированную ими, чтобы выполнять способ кодирования видео, содержащий:
прием по меньшей мере части потока битов;
синтаксический разбор синтаксических элементов из потока битов, причем синтаксические элементы представляют информацию состояния, которая идентифицирует, какие картинки из последовательности видео доступны для использования в качестве опорных картинок для текущей картинки, причем упомянутые синтаксические элементы включают в себя идентифицирующую информацию для долгосрочной опорной картинки ("LTRP"), при этом идентифицирующая информация для LTRP является значением младших значащих битов отсчета по порядку картинки ("LSB в РОС") для LTRP для текущей картинки; и
использование идентифицирующей информации во время декодирования,
использование флага будущей опорной ссылки для каждой опорной картинки в информации списка описания буфера (BDL), причем упомянутый флаг будущей опорной ссылки указывает, используется ли опорная картинка только для декодирования текущей картинки или, вместо этого, для декодирования по меньшей мере одной последующей картинки в кодированном порядке.
10. Средство обработки видео в реальном времени, содержащее кодер видео, декодер видео, устройство ввода голоса, громкоговоритель, компонент захвата видео, дисплей, и средство связи;
в котором средство обработки в реальном времени приспособлено, чтобы обрабатывать синтаксические элементы, которые представляют информацию состояния в потоке битов, при этом упомянутая информация состояния идентифицирует, какие картинки из последовательности видео доступны для использования в качестве опорных картинок для текущей картинки, упомянутые синтаксические элементы включают в себя идентифицирующую информацию для долгосрочной опорной картинки ("LTRP"), причем идентифицирующая информация для LTRP является значением младших значащих битов отсчета по порядку картинки ("LSB в РОС") для LTRP для текущей картинки, и
выполнять кодирование и декодирование последовательности видео, используя флаг будущей опорной ссылки для каждой опорной картинки в информации списка описания буфера (BDL), причем упомянутый флаг будущей опорной ссылки указывает, используется ли опорная картинка только для декодирования текущей картинки или, вместо этого, для декодирования по меньшей мере одной последующей картинки в кодированном порядке.
| Колосоуборка | 1923 |
|
SU2009A1 |
| Приспособление для суммирования отрезков прямых линий | 1923 |
|
SU2010A1 |
| Колосоуборка | 1923 |
|
SU2009A1 |
| Колосоуборка | 1923 |
|
SU2009A1 |
| Приспособление для суммирования отрезков прямых линий | 1923 |
|
SU2010A1 |
| СПОСОБ И УСТРОЙСТВО ДЛЯ ВЗВЕШЕННОГО ПРЕДСКАЗАНИЯ ДЛЯ МАСШТАБИРУЕМОГО КОДИРОВАНИЯ ВИДЕОСИГНАЛА | 2006 |
|
RU2406253C2 |
