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

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

Иллюстрации

Показать все

Реферат

Настоящее изобретение относится к принципам кодирования, делающим возможным параллельную обработку, такую как в развивающемся стандарте HEVC (высокоэффективное видеокодирование), транспортному демультиплексору и битовому потоку видео.

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

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

Были предложены некоторые принципы распараллеливания, а именно волновая обработка, использующая энтропийные слайсы [3], операции волновой параллельной обработки (WPP), использующие подпотоки [2] [4], [11], или тайлы [5]. Последние не требуют обязательного объединения с волновой обработкой, для того чтобы сделать возможным распараллеливание в декодере или кодере. С этой точки зрения тайлы подобны подпотокам WPP. Первоначальным мотиватором изобретателей для дальнейшего исследования принципа энтропийных слайсов является выполнение методов, которые уменьшают потери эффективности кодирования и, таким образом, уменьшают нагрузку на битовый поток для подходов распараллеливания в кодере и декодере.

Чтобы обеспечить лучшее понимание, в частности использования LCU, можно сначала рассмотреть структуру H.264/AVC [1].

Кодированная видеопоследовательность в H.264/AVC состоит из последовательности единиц доступа, которые собраны в поток единиц уровня сетевой абстракции (NAL), и они используют только один набор параметров последовательности. Каждая видеопоследовательность может декодироваться независимо. Кодированная последовательность состоит из последовательности кодированных изображений. Кодированным кадром может быть целый кадр или единственное поле. Каждое изображение разделяется на макроблоки фиксированного размера (в HEVC [5]: LCU). Несколько макроблоков или LCU могут объединяться вместе в один слайс. Изображение, поэтому, представляет собой совокупность из одного или нескольких слайсов. Целью этого разделения данных является получение возможности независимого декодирования отсчетов в области изображения, которая представлена слайсом, без использования данных из других слайсов.

Методом, который часто упоминается как «энтропийные слайсы» [3], является разделение традиционного слайса на дополнительные подслайсы. Конкретно, это означает разделение энтропийно кодированных данных единственного слайса. Размещение энтропийных слайсов в слайсе может быть разнообразным. Самым простейшим является использование каждой строки LCU/макроблоков в кадре в качестве одного энтропийного слайса. Альтернативно, столбцы или отдельные области могут использоваться в качестве энтропийных слайсов, которые даже могут прерываться и переключаться друг с другом, например, слайс 1 на фиг. 1.

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

Принцип энтропийных слайсов был дополнительно расширен до волновой обработки подпотоков (WPP), как предложено в [2], [10], [11] и частично интегрировано в [5]. В данном случае определяется схема повторения подпотоков. Что действительно имеет улучшенную инициализацию энтропийного состояния на строку по сравнению с энтропийными слайсами.

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

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

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

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

В потоковом видео обеспечение более высоких разрешений (Full-HD, QUAD-HD и т.д.) приводит к большему количеству данных, которые должны передаваться. Для чувствительных к времени сценариев, так называемому варианту использования с малой задержкой, такому как видеоконференция (<145 мс), или игровые приложения (<40 мс), требуются очень малые сквозные задержки. Поэтому, время передачи становится критическим фактором. Изобретатели рассматривают линию загрузки в асимметричной цифровой абонентской линии (ADSL) для применения в видеоконференции. В данном случае, так называемые точки произвольного доступа потока, обычно они ссылаются на I-кадры, будут кандидатами на то, чтобы вызвать узкое место во время передачи.

HEVC допускает так называемую волновую обработку, а также обработку тайлов на стороне кодера, а также декодера. Это делается возможным посредством использования энтропийных слайсов, подпотоков WPP или даже их объединения. Параллельная обработка также допускается параллельным кодированием и декодированием тайлов.

В случае «цели без распараллеливания» данные всего слайса доставляются одновременно, таким образом последняя CU слайсов является доступной для декодера, если она была передана. Это не является проблемой, если имеется декодер с единственным потоком.

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

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

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

Эта задача достигается объектом прилагаемых зависимых пунктов формулы изобретения.

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

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

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

фиг. 1 изображает схему, иллюстрирующую возможные соединения энтропийных слайсов;

фиг. 2 изображает схему, иллюстрирующую три тайла, распределенные по трем слайсам;

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

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

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

фиг. 6 изображает таблицу псевдокода, иллюстрирующего синтаксис единицы NAL;

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

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

фиг. 9 изображает таблицу псевдокода, иллюстрирующего синтаксис заголовка слайса;

фиг. 10 изображает таблицу псевдокода, иллюстрирующего синтаксис маркера подпотока;

фиг. 11 изображает схему, иллюстрирующую пример простой инкапсуляции данных энтропийного слайса (AF представляет собой поле адаптации TS MPEG-2);

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

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

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

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

фиг. 16 изображает блок-схему, изображающую кодер;

фиг. 17 изображает блок-схему, изображающую декодер;

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

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

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

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

Так как транши меньше полного подпотока WPP или тайла и/или могут адаптироваться к фактической максимальной единице передачи (MTU) тракта передачи, так что транши многочисленных подпотоков WPP или тайлов могут размещаться в единице передачи между кодером и декодером перед завершением полной единицы доступа, декодирование на стороне декодера может начинаться существенно раньше, чем при использовании последовательной передачи полных подпотоков WPP или тайлов единицы доступа.

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

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

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

Чтобы сделать возможной обработку на стороне декодера перед или после каждого транша, может вставляться код маркера. Соответствующим кодом маркера для HEVC может быть «0x00 00 02», который будет даже пропускать предотвращение эмуляции кода начала. После приема пакета, включающего в себя многочисленные транши, приемник или декодер может выполнять синтаксический анализ фактически содержащегося битового потока во время процесса предотвращения эмуляции кода начала, чтобы не требовался дополнительный этап синтаксического анализа. Может быть, например, два режима для идентификации транша. Может быть всегда циклическое размещение траншей, начиная с транша с tranche_id (идентификатор транша), равного 1, до транша с tranche_id, равным n. Это может безопасно сигнализировать данные для второго общего способа. Альтернативным способом может быть конкретный заголовок, следующий за маркером, указывающий tranche_id, например, в виде 8-битового значения.

Деперемежение данных перемеженных траншей может применяться на основе сведения о количестве траншей на пакет, которым может быть пакет единиц NAL. Поэтому может быть дополнительно отображение подпотоков WPP или тайлов на транши. Это отображение может неявно выводиться из количества тайлов/количества подпотоков WPP, или может сигнализироваться непосредственно в наборе параметров последовательности (SPS). Отображение является важным для процесса деперемежения, так что данные некоторых подпотоков WPP или тайлов могут идентифицироваться и предоставляться потоку волнового или параллельного декодера, ответственного за декодирование данного подпотока WPP или тайла.

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

Другим режимом может быть перемежение и деперемежение на транспортном уровне, т.е. вне процесса декодирования может быть на уровне RTP [8] [9] [13] или транспортного потока MPEG-2 [7].

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

Заголовок переменной длины может использоваться на дополнительном уровне мультиплексирования. Этот уровень мультиплексирования также может представлять собой часть кодека и может вводиться перед фактическим обращением к данным последовательности необработанных байтов (RBSP) в декодере. Одну схему заголовка можно найти на фиг. 3. Но может быть также заголовок непосредственно перед каждым траншем, указывающий длину, а также его индикатор. Где все еще имеется необходимость в отображении индикатора на структуры битового потока, уже указано выше.

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

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

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

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

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

Схема передачи показана на фиг. 4.

Другой интересный способ использует коды завершения или коды маркера в конце набора траншей в пакете, таком как NAL или пакет слайсов. В данном случае возможны сегменты переменной длины, таким образом, требуется полный синтаксический анализ битового потока. Чтобы ограничить в данном случае обращение к памяти, этот дополнительный процесс синтаксического анализа для мультиплексирования может объединяться с синтаксическим анализом предотвращения эмуляции кода начала, требуемого в качестве первого этапа перед обращением к данным RBSP, содержащимся в единице NAL. Такая схема маркера показана на фиг. 5.

Идея в данном случае заключается в разбиении перемежающим образом структуры более высокого уровня, такой как фактический слайс, энтропийный слайс или подобные, на содержащиеся в ней структуры данных более низкого уровня, такие как подпотоки WPP или тайлы, при перемежении данных в транши. Эти транши, причем каждый принадлежит к структуре более низкого уровня, например, конкретному подпотоку WPP или тайлу, перемежаются в пакете с малой задержкой, которым может быть конкретная единица NAL, единица NAL с дополнительной сигнализацией флагом перемежения с малой задержкой или даже слайс или легковесный заголовок слайса, указывающий подход перемежения с малой задержкой посредством флага или типа слайса, как показано для «единица #1 NAL» на фигуре, таким образом декодер информируется для применения функции переупорядочения для декодера с «единственным» потоком, который использует последовательную обработку траншей в исходном/деперемеженном порядке в декодере. Чтобы разделить данные фактического слайса в виде перемеженных траншей по многочисленным пакетам, чтобы получить выигрыш в признаке малой задержки, транспортный уровень может фрагментировать единицу NAL, содержащую перемеженные данные с малой задержкой, в сетевые пакеты максимального размера MTU. Фрагментирование данных фактического слайса в многочисленные единицы NAL также может непосредственно применяться уровнем кодирования, таким образом, существует потребность в сигнализации такого типа единицы NAL, содержащей продолжение слайса, как показано на фиг. 5 для «единицы #2 NAL». Чтобы обнаруживать завершение перемеженных данных в многочисленных пакетах, таких как единицы NAL. Может быть необходимость в конкретном коде завершения, также показанном для «единицы #2 NAL» на фигуре, или флаге, который указывает завершение в слайсе или заголовка NAL.

В случае потери пакетов NAL также существует потребность в обнаружении потерь. Это может применяться посредством дополнительной информации в заголовке, например, легковесного заголовка слайса, такого как первые макроблоки (MB) содержащихся траншей, или только конкретного транша #1. Имея информацию, такую как смещения для подпотоков WPP или фактический размер транша, кто-нибудь также может использовать эти значения размера (значения смещения для конкретного подпотока WPP или тайла), чтобы выполнить проверку работоспособности после приема единицы NAL с кодом завершения и предшествующими единицами NAL.

Т.е, как описано, транши могут пакетироваться в пакеты 300 таким образом, что каждый пакет 300 содержит один транш T# каждого подпотока WPP или тайла изображения или поднабора подпотоков WPP или тайлов изображения (так как, например, некоторый подпоток WPP или тайл уже был полностью передан посредством предыдущих пакетов), расположенных в порядке #, заданном среди подпотоков WPP или тайлов, причем каждый пакет содержит заголовок 302, содержащий информацию, выявляющую позиции и/или длительности траншей T#, упакованных в соответствующий пакет 300, или маркеры 304, разделяющие транши T# в соответствующем пакете 300 друг от друга, причем декодер может быть выполнен с возможностью, при приеме полезных данных последовательности необработанных байтов, использования информации, содержащейся в заголовках 302 или маркерах 304, для обращения к траншам в пакетах. Пакеты 300a, которые содержат первые - в соответствии с порядком, определенным среди подпотоков WPP или тайлов - транши подпотоков WPP или тайлы изображения, могут содержать индикатор 306 признака малой задержки, и пакеты 300b, содержащие вторые или последующие - в соответствии с порядком, определенным среди подпотоков WPP или тайлов - тайлы T# подпотоков WPP или тайлов изображения, могут содержать индикатор 308 продолжения. Пакетами 300 могут быть единицы NAL или слайсы.

Ниже предоставляется пример для сигнализации синтаксиса и семантики для перемежения с малой задержкой в транши.

Тем не менее разделение данных транша, таких как данные подпотока WPP или тайла, также может применяться на уровне слайса или ниже, как указано выше.

Ниже показан подход, который может быть объединен с синтаксическим анализом для предотвращения эмуляции кода начала, чтобы уменьшить количество дополнительных этапов процесса. Поэтому, перемежение применяется на уровне RBSP кодека HEVC.

Транш может рассматриваться как разделяющий данные RBSP на секции, подлежащие перемежению в секции полезных данных единиц NAL для доступа к данным с малой задержкой. Завершение транша может указываться кодом 0x000002 и за которым может следовать 8-битовый идентификатор транша tranche_id. Транши могут перемежаться циклическим образом, так что за кодом окончания транша не следует tranche_id, который выводится неявным образом. Данные RBSP в единственном транше соответствуют или данным тайла, данным подпотока, данным слайса или данным энтропийного слайса.

В синтаксисе единицы NAL могут учитываться два режима для перемежения с малой задержкой, как указано посредством «low delay encapsulation_flag» (флаг инкапсуляции с малой задержкой), который представляет собой циклическое размещение траншей, а также указание транша посредством дополнительного идентификатора «tranche_id», следующий за кодом маркера посредством флага, такого как «low delay cyclic_flag» (флаг циклического размещения малой задержки) в заголовке единицы NAL. Эти два флага также могут представляться в наборах параметров последовательности или даже APS. Для циклического размещения траншей все же может требоваться знание количества траншей во время синтаксического анализа, такого как предусмотренного в SPS в виде «num_low_delay_tranches» (количество траншей с малой задержкой).

В единице NAL перемеженные «LD_rbsp_byte» считываются блоком синтаксического анализа и переупорядочиваются в фактический последовательный порядок RBSP в последнем for-цикле в синтаксисе NAL:

Также может быть явная сигнализация в SPS или APS для фиксированного размера циклически размещенных траншей, что указывается в «low-delay_tranche_length_minus1» (длительность транша с малой задержкой минус 1). Последний не использовался в примере синтаксиса единицы NAL, но является прямым, подразумевая пакетирование, показанное на фиг. 4. В синтаксисе единицы NAL на фиг. 6 было базовым пакетирование, показанное на фиг. 5 и описанное выше.

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

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

Важным требованием к подпотокам WPP, расположенным в перемеженных траншах с малой задержкой, является то, что посредством транша n+1 выполняется обращение только к данным из транша n, которые уже предоставлены в транше n и уже сохранены или доступны в декодере.

Синтаксис RBSP уровня слайса с малой задержкой для переупорядочения/деперемежения на уровне слайса может быть разработан следующим образом. В частности, синтаксис в данном случае должен иметь почти такое же поведение, что и на уровне единиц NAL, но переупорядочение должно определяться на уровне слайса. Фиг. 8 изображает синтаксис RBSP уровня слайса с малой задержкой.

В случае использования заголовка слайса для пакетирования перемеженных траншей может быть требование к указанию на уровне кодека, если принимается новый слайс, не сбрасывать состояние CABAC, так как энтропийное кодирование траншей, например, подпотока WPP, не должно прерываться. Не сбрасывать CABAC в слайсе указывается как «no_cabac_reset_flag» в заголовке слайса. Показанный заголовок слайса подходит для слайсов с малой задержкой, таким образом, также должны присутствовать признаки entropy_slice (энтропийный слайс). Соответствующий синтаксис заголовка слайса показан на фиг. 9.

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

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

Чтобы учитывать такое использование/оптимизацию, разная информация сигнализируется по транспортному уровню.

Общая дополнительная информация сигнализируется с использованием дескритпоров:

- количество подпотоков/тайлов, где «1» означает, что имеется только один поток/тайл, который содержит весь кадр видео;

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

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

- количество этапов постепенного обновления декодера, где «1» означает, что не используется постепенное обновление декодера;

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

Если количество подпотоков/тайлов>1, элементы синтаксиса вставляются в поток перед каждым блоком данных, который содержит некоторый подпоток/тайл. Эти элементы синтаксиса придерживаются синтаксиса единиц NAL, но используют уникальный тип единицы NAL, который не используется уровнем кодирования (например, nal_unit_type=0x19 или nal_unit_type=0x1F), ниже упоминаемый как маркеры подпотока.

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

Если количество этапов постепенного обновления декодера >1, эти элементы синтаксиса также переносят флаг, который указывает, имеет ли подпоток/тайл с внутренним кодированием (делает возможным постепенное обновление декодера).

Соответствующий синтаксис показан на фиг. 10. Могут применяться следующие ограничения:

forbidden_zero_bit должен быть равен 0.

nal_ref_flag должен быть равен 0.

nal_unit_type должен быть равен 0x19.

substream_ID: значение счетчика, начинающееся с 0 для первого слайса, которое принадлежит изображению, увеличиваемое на 1 каждым следующим слайсом или энтропийным слайсом, который принадлежит этому же изображению.

is_intra: если равен «1», следующая единица NAL содержит слайс с внутренним кодированием или энтропийный слайс с внутренним кодированием.

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

Необходимо отметить, что подобное поведение элементарного потока транспортного потока MPEG-2 также может обеспечиваться сеансом RTP или потоком RTP транспортного протокола реального времени, как показано на фиг. 19. В RTP [8] поток RTP (идентифицированный типом мультимедиа и типом полезных данных, как указано в SDP [12]) может содержаться в своем собственном сеансе RTP, где сеанс RTP идентифицируется сетевым адресом (IP (протокола Интернета)), портом (протокола передачи дейтаграмм пользователя (UDP)), а также идентификатором источника (SSRC). Мультимедийный сеанс, как указывается в SDP, может содержать многочисленные сеансы RTP, причем каждый содержит разный тип мультимедиа. Но также возможно транспортировать один и тот же поток мультимедиа (например, видео) в разных потоках RTP, где потоки RTP могут содержаться в одном и том же сеансе RTP (аналогично 1 ниже) или могут содержаться в своих собственных сеансах RTP (аналогично 2 ниже). Фиг. 19 иллюстрирует случай 2.

Форматы полезных данных RTP [9] [13] имеют номер порядка декодирования (DON), который позволяет восстанавливать порядок декодирования единиц NAL в приемнике в случае, когда они намеренно передаются вне порядка декодирования с целью устойчивости к ошибкам, как описано в [9] [13]. Дополнительные маркеры MKR, поэтому, не являются необходимыми. В случае транспортировки траншей подпотоков WPP или тайлов в порядке, в котором они становятся доступными из процессов кодирования, DON также может использоваться для восстановления порядка декодирования траншей перед предоставлением их единственному декодеру. Но в этом случае дополнительная задержка вводится в декодере из-за отдельного процесса деперемежения перед процессом декодирования. Описанная здесь система может предоставлять кодированные транши непосредственно процессам декодирования разных подпотоков WPP или тайлов, в то время как данные поступают в приемник. Идентификация траншей, ассоциированных с подпотоком WPP или тайлом, может извлекаться посредством адреса слайса в заголовке сегмента слайса и порядка передачи пакетов, как указывается номером последовательности RTP в заголовке RTP. При таком сценарии DON используется только для обратной совместимости, т.е. для декодеров, не обеспечивающих улучшенную возможность декодирования траншей подпотоков WPP или тайлов, посылаемых вне порядка декодирования, когда они поступают. Посылка данных транша вне порядка декодирования как раз применяется в отношении уровня подпотоков WPP и тайлов, т.е. в передаваемых данных, причем транши единственного подпотока WPP или тайла передаются в порядке декодирования, где перемежаются данные разных подпотоков WPP или тайлов.

Существует два возможных варианта:

1. Все слайсы и энтропийные слайсы содержатся в одном и том же элементарном потоке, т.е. один и тот же PID (идентификатор пакета) назначается всем пакетам TS этого видеопотока; в последующем тексте этот способ ссылается на инкапсуляцию единственного ES.

2. Разные PID назначаются слайсам и энтропийным слайсам одного и того же битового потока видео; в нижеследующем тексте этот способ ссылается на инкапсуляцию многочисленных ES.

Фиг. 11 действительна для обоих вариантов, если первый вариант рассматривается как специальный случай более общей структуры посредством установки одного и того же PID для всех ES.

Более эффективный способ инкапсуляции в единственном ES показан на фиг. 12. В данном случае требуется максимум одно поле адаптации на изображение.

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

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