КОНЦЕПЦИЯ ПОТОКА ВИДЕОДАННЫХ Российский патент 2017 года по МПК H04N19/46 H04N19/70 H04N19/68 

Изобретение относится к концепциям потока видеоданных, которые, в частности, выгодны в связи с приложениями с малой задержкой.

HEVC [2] допускает различные средства сигнализации Синтаксиса Высокого Уровня прикладному уровню. Такие средства представляют собой заголовок блока NAL, Наборы Параметров и Сообщения Дополнительной Информации Улучшения (SEI). Последние не используются в процессе декодирования. Другие средства сигнализации Синтаксиса Высокого Уровня происходят из соответствующих спецификаций транспортного протокола, таких как Транспортный Протокол MPEG2 [3] или Транспортный Протокол Реального Времени [4], и их определенных спецификаций полезной нагрузки, например, рекомендаций для H.264/AVC [5], масштабируемого кодирования видеосигнала (SVC) [6] или HEVC [7]. Такие транспортные протоколы могут представить сигнализацию Высокого Уровня, которая использует подобные структуры и механизмы, что и сигнализация Высокого Уровня соответствующей спецификации кодека прикладного уровня, например HEVC [2]. Одним из примеров такой сигнализации является блок NAL Информации Масштабируемости Контента Полезной Нагрузки (PACSI), как описано в [6], который предоставляет дополнительную информацию для транспортного уровня.

Для наборов параметров, HEVC включает в себя Набор Параметров Видео (VPS), который собирает наиболее важную информацию потока, которая должна быть использована прикладным уровнем, в одном и центральном местоположении. В более ранних подходах было необходимо, чтобы эта информация собиралась из нескольких Наборов Параметров и заголовков блоков NAL.

До настоящей заявки статус стандарта по отношению к операциям Буфера Кодированного Изображения (CPB) Гипотетического Эталонного Декодера (HRD) и всего связанного синтаксиса, предоставленного в Наборе Параметров Последовательности (SPS)/Информации Применимости Видео (VUI), Тайминга Изображения SEI, Периода Буферизации SEI, а также определения блока декодирования, описывающего под-изображение и синтаксис Зависимых Слайсов как присутствующих в заголовке слайса, а также Наборы Параметров Изображений (PPS), были следующими.

Для того чтобы позволить операции с малой задержкой CPB на уровне под-изображения, операции под-изображений CPB были предложены и интегрированы в проект стандарта HEVC 7 JCTVC-11003 [2]. Здесь особенно, блок декодирования был определен в разделе 3 в [2] как:

блок декодирования: Блок доступа или подмножество блока доступа. Если SubPicCpbFlag равен 0, блок декодирования представляет собой блок доступа. В противном случае, блок декодирования состоит из одного или более блоков VCL NAL в блоке доступа и связанных не-VCL NAL блоков. Для первого блока VCL NAL в блоке доступа связанные не-VCL NAL блоки являются блоками NAL данных заполнения, если таковые имеются, непосредственно следующими за первым блоком VCL NAL и не-VCL NAL блоками в блоке доступа, которые предшествуют первому блоку VCL NAL. Для блока VCL NAL, который не является первым блоком VCL NAL в блоке доступа, связанные не-VCL NAL блоки являются блоком NAL данных заполнения, если таковые имеются, непосредственно следующим за блоком VCL NAL.

В стандарте, определенном до того времени, «Тайминг удаления блока декодирования и декодирование блока декодирования» было описано и добавлено в Приложение C «Гипотетический Эталонный Декодер». Чтобы сигнализировать тайминг под-изображения, сообщение SEI периода буферизации и сообщение SEI тайминга изображения, а также параметры HRD в VUI были расширены, чтобы поддерживать блоки декодирования в качестве блоков под-изображения.

Синтаксис [2] сообщения SEI периода буферизации показан на Фиг. 1.

Когда NalHrdBpPresentFlag или VclHrdBpPresentFlag равны 1, сообщение SEI периода буферизации может быть связано с любым блоком доступа в битовом потоке, и сообщение SEI периода буферизации будет связано с каждым блоком доступа RAP и с каждым блоком доступа, связанным с сообщением SEI точки восстановления.

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

Период буферизации был задан как набор блоков доступа между двумя объектами сообщения SEI периода буферизации в порядке декодирования.

Семантика была следующая:

seq_parameter_set_id определяет набор параметров последовательности, который содержит атрибуты HRD последовательности. Значение seq_parameter_set_id будет равно значению seq_parameter_set_id в наборе параметров изображения, на который ссылается первичное закодированное изображение, связанное с сообщением SEI периода буферизации. Значение seq_parameter_set_id должно быть в диапазоне от 0 до 31, включительно.

rap_cpb_params_present_flag, равный 1, определяет присутствие синтаксических элементов initial_alt_cpb_removal_delay[ SchedSelIdx ] и initial_alt_cpb_removal_delay_offset[ SchedSelIdx ]. В случае, когда не присутствует, значение rap_cpb_params_present_flag подразумевается равным 0. Когда связанное изображение не является ни изображением CRA, ни изображением BLA, значение rap_cpb_params_present_flag будет равно 0.

initial_cpb_removal_delay[ SchedSelIdx ] и initial_alt_cpb_removal_delay[ SchedSelIdx ] определяют исходные задержки удаления CPB для SchedSelIdx-го CPB. Синтаксические элементы имеют длину в битах, заданную посредством initial_cpb_removal_delay_length_minus1 + 1, и выражены в единицах 90 кГц тактового сигнала. Значения синтаксических элементов не будут равны 0 и не будут превышать 90000 * ( CpbSize[ SchedSelIdx ] ÷ BitRate[ SchedSelIdx ]), временной эквивалент размера CPB в единицах 90 кГц тактового сигнала.

initial_cpb_removal_delay_offset[ SchedSelIdx ] и initial_alt_cpb_removal_delay_offset[ SchedSelIdx ] используются для SchedSelIdx-го CBP для задания исходного времени доставки закодированных блоков данных в CPB. Синтаксические элементы имеют длину в битах, заданную посредством initial_cpb_removal_delay_length_minus1 + 1, и выражены в единицах 90 кГц тактового сигнала. Эти синтаксические элементы не используются декодерами и могут быть нужны лишь для планировщика доставки (HSS).

По всей закодированной видеопоследовательности сумма initial_cpb_removal_delay[ SchedSelIdx ] и initial_cpb_removal_delay_offset[ SchedSelIdx ] должна быть постоянной для каждого значения SchedSelIdx, и сумма initial_alt_cpb_removal_delay[ SchedSelIdx ] и initial_alt_cpb_removal_delay_offset[ SchedSelIdx ] должна быть постоянной для каждого значения SchedSelIdx.

Синтаксис сообщения SEI тайминга изображения из [2] показан на Фиг. 2.

Синтаксис сообщения SEI тайминга изображения был зависим от контента набора параметров последовательности, который является активным для закодированного изображения, связанного с сообщением SEI тайминга изображения. Однако, если сообщению SEI тайминга изображения блока доступа IDR или BLA не предшествует сообщение SEI периода буферизации в том же блоке доступа, активация связанного набора параметров последовательности (и, для изображений IDR или BLA, которые не являются первым изображением в битовом потоке, определение, что закодированное изображение является изображением IDR или изображением BLA) не происходит до декодирования первого закодированного блока NAL слайса закодированного изображения. Поскольку закодированный блок NAL слайса закодированного изображения следует за сообщением SEI тайминга изображения в порядке блока NAL, могут быть случаи, в которых необходимо для декодера хранить RBSP, содержащий сообщение SEI тайминга изображения, до определения параметров параметра последовательности, который будет активен для закодированного изображения, и затем выполнить синтаксический анализ сообщения SEI тайминга изображения.

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

- Если CpbDpbDelaysPresentFlag равен 1, одно сообщение SEI тайминга изображения будет присутствовать в каждом блоке доступа закодированной видеопоследовательности.

- В противном случае (CpbDpbDelaysPresentFlag равен 0), сообщение SEI тайминга изображения не будет присутствовать в каждом блоке доступа закодированной видеопоследовательности.

Семантика была определена следующим образом:

cpb_removal_delay определяет, сколько тактов синхронизации ждать после удаления из CPB блока доступа, связанного с самым недавним сообщением SEI периода буферизации в предшествующем блоке доступа, перед удалением из буфера данных блока доступа, связанных с сообщением SEI тайминга изображения. Это значение также используется для вычисления самого раннего возможного времени прибытия данных блока доступа в CPB для HSS. Синтаксический элемент представляет собой код фиксированной длины, чья длина в битах задана посредством cpb_removal_delay_length_minus1 + 1. cpb_removal_delay представляет собой остаток от счетчика по модулю 2^(cpb_removal_delay_length_minus1 + 1).

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

dpb_output_delay используется для вычисления времени вывода DBP изображения. Он определяет, сколько тактов синхронизации ждать после удаления последнего блока декодирования в блоке доступа из CPB до того, как декодированное изображение будет выведено из DPB.

Изображение не удаляется из DBP в его время вывода, когда оно все еще помечено как «используется для краткосрочной ссылки» или «используется для долгосрочной ссылки».

Только один dpb_putput_delay определяется для декодированного изображения.

Длина синтаксического элемента dpb_output_delay задана в битах посредством dpb_output_delay_length_minus1 + 1. Когда sps_max_dec_pic_buffering[ max_temporal_layers_minus1 ] равно 0, dpb_output_delay shall будет равно 0.

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

Порядок вывода изображений, установленный значениями этого синтаксического элемента, будет таким же порядком, который установлен значениями PicOrderCntVal.

Для изображений, которые не выводятся процессом «резкого изменения параметров» из-за того, что они предшествуют в порядке декодирования изображению IDR или BLA с no_output_of_prior_pics_flag, равным 1 или подразумевающимся равным 1, моменты времени вывода, полученные из dpb_output_delay, будут увеличивающимися с увеличивающимся значением PicOrderCntVal по отношению ко всем изображениям в одной и той же закодированной видеопоследовательности.

num_decoding_units_minus1 плюс 1 определяет количество блоков декодирования в блоке доступа, с которым связано сообщение SEI тайминга изображения. Значение num_decoding_units_minus1 должно быть в диапазоне от 0 до PicWidthInCtbs * PicHeightInCtbs - 1, включительно.

num_nalus_in_du_minus1[ i ] plus 1 определяет количество блоков NAL в i-м блоке декодирования блока доступа, с которым связано сообщение SEI тайминга изображения. Значение num_nalus_in_du_minus1[ i ] plus 1 должно быть в диапазоне от 0 до PicWidthInCtbs * PicHeightInCtbs - 1, включительно.

Первый блок декодирования блока доступа состоит из первых num_nalus_in_du_minus1[ 0 ] + 1 последовательных блоков NAL в порядке декодирования в блоке доступа. i-й (где i больше, чем 0) блок декодирования блока доступа состоит из num_nalus_in_du_minus1[ i ] + 1 последовательных блоков NAL, непосредственно следующих за последним блоком NAL в предшествующем блоке декодирования блока доступа, в порядке декодирования. В каждом блоке декодирования будет по меньшей мере один блок VCL NAL. Все не-VCL NAL блоки, связанные с блоком VCL NAL, будут включены в тот же блок декодирования.

du_cpb_removal_delay[ i ] задает, сколько тактов синхронизации под-изображения ждать после удаления из CPB первого блока декодирования в блоке доступа, связанном с самым недавним сообщением SEI периода буферизации в предшествующем блоке доступа, перед удалением из CPB i-го блока декодирования в блоке доступа, связанном с сообщением SEI тайминга изображения. Это значение также используется для вычисления самого раннего возможного времени прибытия данных блока декодирования в CPB для HSS. Синтаксический элемент представляет собой код фиксированной длины, чья длина в битах задана посредством cpb_removal_delay_length_minus1 + 1. du_cpb_removal_delay[ i ] представляет собой остаток от счетчика по модулю 2^(cpb_removal_delay_length_minus1 + 1).

Значение cpb_removal_delay_length_minus1, которое определяет длину (в битах) синтаксического элемента du_cpb_removal_delay[ i ], представляет собой значение cpb_removal_delay_length_minus1, закодированное в наборе параметров последовательности, который является активным для закодированного изображения, связанного с сообщением SEI тайминга изображения, хотя du_cpb_removal_delay[ i ] определяет количество тактов синхронизации под-изображения по отношению ко времени удаления первого блока декодирования в предшествующем блоке доступа, содержащем сообщение SEI периода буферизации, который может быть блоком доступа другой закодированной видеопоследовательности.

Некоторая информация содержалась в синтаксисе VUI [2]. Синтаксис параметров VUI из [2] показан на Фиг. 3. Синтаксис параметров HDR из [2] показан на Фиг. 4. Семантика была определена следующим образом:

sub_pic_cpb_params_present_flag, равный 1, определяет, что параметры задержки удаления CPB уровня под-изображения присутствуют, и CPB может работать на уровне блока доступа или уровне под-изображения. sub_pic_cpb_params_present_flag, равный 0, определяет, что параметры задержки удаления CPB уровня под-изображения не присутствуют, и что CPB работает на уровне блока доступа. Когда sub_pic_cpb_params_present_flag не присутствует, его значение подразумевается равным 0.

num_units_in_sub_tick представляет собой количество временных единиц тактового генератора, работающего на частотной временной шкале Гц, которая соответствует одному инкременту (называемому тактом синхронизации под-изображения) счетчика тактов синхронизации под-изображения. num_units_in_sub_tick будет больше, чем 0. Такт синхронизации под-изображения представляет собой минимальный интервал времени, который может быть представлен в закодированных данных, когда sub_pic_cpb_params_present_flag равен 1.

sub_pic_cpb_params_present_flag, равный 1, указывает, что каждый набор параметров изображения, который является активным в закодированной видеопоследовательности, имеет одно и то же значение синтаксических элементов num_tile_columns_minus1, num_tile_rows_minus1, uniform_spacing_flag, column_width[ i ], row_height[ i ] и loop_filter_across_tiles_enabled_flag, когда они присутствуют. tiles_fixed_structure_flag, равный 0, указывает, что синтаксические элементы фрагмента изображения в разных наборах параметров изображения могут иметь, а могут и не иметь одно и то же значение. Когда синтаксический элемент tiles_fixed_structure_flag не присутствует, его значение подразумевается равным 0.

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

Данные заполнения в [2] сигнализировались с использованием синтаксиса RBSP данных фильтра, показанного на Фиг. 5.

Гипотетический Эталонный Декодер из [2], используемый для проверки битового потока и соответствия декодера, был определен следующим образом:

Два типа битовых потоков являются предметом проверки соответствия HRD для этой Рекомендации | Международного Стандарта. Первый такой тип битового потока, называемый битовым потоком Типа I, представляет собой поток блоков NAL, содержащий только блоки VCL NAL и блоки NAL данных заполнения для всех блоков доступа в битовом потоке. Второй тип битового потока, называемый битовым потоком Типа II, содержит, в дополнение к блокам VCL NAL и блокам NAL данных заполнения для всех блоков доступа в битовом потоке, по меньшей мере одно из следующего:

- дополнительные не-VCL NAL блоки, отличные от блоков NAL данных заполнения,

- все синтаксические элементы leading_zero_8bits, zero_byte, start_code_prefix_one_3bytes, и trailing_zero_8bits, которые формируют байтовый поток из потока блоков NAL.

Фиг. 6 показывает точки соответствия типов битового потока, проверяемые HRD в [2].

Используются два типа наборов параметров HRD (параметры NAL HRD и параметры VCL HRD). Наборы параметров HRD сигнализируются через информацию применимости видео, которая является частью синтаксической структуры набора параметров последовательности.

Все наборы параметров последовательности и наборы параметров изображения, упомянутые в блоках VCL NAL, и соответствующие сообщения SEI периода буферизации и тайминга изображения должны быть своевременно переданы в HRD либо в битовом потоке, либо с помощью других средств.

Спецификация для «присутствия» не-VCL NAL блоков также удовлетворяется, когда эти блоки NAL (или лишь некоторые из них) передаются в декодеры (или в HRD) с помощью других средств, не определенных этой Рекомендацией | Международным Стандартом. В целях подсчета битов, считаются только соответствующие биты, которые фактически присутствуют в битовом потоке.

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

Когда контент не-VCL NAL блока передается для применения некоторыми средствами, отличными от присутствия в битовом потоке, представление контента не-VCL NAL блока не требуется для использования того же синтаксиса, определенного в этом приложении.

Следует отметить, что когда информация содержится внутри битового потока, возможно проверить соответствие битового потока требованиям этого подпункта исключительно на основе информации, содержащейся в битовом потоке. Когда информация HRD не присутствует в битовом потоке, как это характерно для всех «автономных» битовых потоков Типа I, соответствие может быть проверено лишь когда данные HRD подаются некоторыми другими средствами, не указанными в этой Рекомендации | Международном Стандарте.

HRD содержит буфер кодированного изображения (CPB), процесс мгновенного декодирования, буфер декодированного изображения (DPB) и кадрирование выходного сигнала, как показано на Фиг. 7.

Размер CPB (количество битов) представляет собой CpbSize[ SchedSelIdx ]. Размер DBP (количество буферов хранения изображения) для временного уровня X представляет собой sps_max_dec_pic_buffering[ X ] для каждого X в диапазоне от 0 до sps_max_temporal_layers_minus1, включительно.

Переменная SubPicCpbPreferredFlag либо задана внешними средствами, или, когда не задана внешними средствами, установлена в 0.

Переменная SubPicCpbFlag получается следующим образом:

SubPicCpbFlag = SubPicCpbPreferredFlag && sub_pic_cpb_params_present_flag

Если SubPicCpbFlag равен 0, CPB работает на уровне блока доступа, и каждый блок декодирования представляет собой блок доступа. В противном случае CPB работает на уровне под-изображения, и каждый блок декодирования представляет собой подмножество блока доступа.

HRD работает следующим образом. Данные, связанные с блоками декодирования, которые прибывают в CPB в соответствии с установленным графиком прибытия, доставляются посредством HSS. Данные, связанные с каждым блоком декодирования, удаляются и мгновенно декодируются посредством процесса мгновенного декодирования в моменты времени удаления CPB. Каждое декодированное изображение помещается в DPB. Декодированное изображение удаляется из DBP в более позднее из времени вывода DPB или времени, когда одно становится больше не нужным для ссылки взаимного прогнозирования.

HRD инициализируется, как указано периодом буферизации SEI. Тайминг удаления блоков декодирования из CPB и тайминг вывода декодированных изображений из DPB указаны в сообщении SEI тайминга изображения. Вся информация тайминга, относящаяся к определенному блоку декодирования, должна прибыть до времени удаления CPB блока декодирования.

HRD используется для проверки соответствия битовых потоков и декодеров.

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

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

Переменная tc получается следующим образом и называется тактом синхронизации:

tc = num_units_in_tick ÷ time_scale

Переменная tc_sub получается следующим образом и называется тактом синхронизации под-изображения:

tc_sub = num_units_in_sub_tick ÷ time_scale

Следующее определено для выражения ограничений:

- Пусть блок n доступа будет n-м блоком доступа в порядке декодирования, при этом первый блок доступа является блоком 0 доступа.

- Пусть изображение n будет закодированным изображением или декодированным изображением блока n доступа.

- Пусть блок m декодирования будет m-м блоком декодирования в порядке декодирования, при этом первый блок декодирования является блоком 0 декодирования.

В [2] синтаксис заголовка слайса допускает так называемые зависимые слайсы.

Фиг. 8 показывает синтаксис заголовка слайса в [2].

Семантика заголовка слайса была определена следующим образом:

dependent_slice_flag, равный 1, указывает, что значение каждого синтаксического элемента заголовка слайса, который не присутствует, подразумевается равным значению соответствующего синтаксического элемента заголовка слайса в предшествующем слайсе, содержащем блок дерева кодирования, для которого адрес блока дерева кодирования является SliceCtbAddrRS - 1. В случае, когда не присутствует, значение dependent_slice_flag подразумевается равным 0. Значение dependent_slice_flag должно быть равным 0, когда SliceCtbAddrRS равно 0.

slice_address указывает адрес в разрешении детализации слайса, в котором слайс начинается. Длина синтаксического элемента slice_address равна ( Ceil( Log2( PicWidthInCtbs * PicHeightInCtbs ) ) + SliceGranularity ) бит.

Переменная SliceCtbAddrRS, определяющая блок дерева кодирования, в котором начинается слайс в растровом порядке сканирования блока дерева кодирования, получается следующим образом.

SliceCtbAddrRS = ( slice_address >> SliceGranularity )

Переменная SliceCtbAddrZS, определяющая адрес первого блока кодирования в слайсе в минимальной детализации блока кодирования в z-порядке сканирования, получается следующим образом.

SliceCbAddrZS = slice_address

<< ( ( log2_diff_max_min_coding_block_size - SliceGranularity ) << 1 )

Декодирование слайса начинается с самым большим, насколько это возможно, блоком кодирования в координате начала слайса.

first_slice_in_pic_flag указывает, является ли слайс первым слайсом изображения. Если first_slice_in_pic_flag равен 1, переменные SliceCbAddrZS и SliceCtbAddrRS обе устанавливаются в 0, и декодирование начинается с первого блока дерева кодирования в изображении.

pic_parameter_set_id определяет набор параметров изображения в использовании. Значение pic_parameter_set_id должно быть в диапазоне от 0 до 255, включительно.

num_entry_point_offsets определяет номер синтаксического элемента entry_point_offset[ i ] в заголовке слайса. Когда tiles_or_entropy_coding_sync_idc равно 1, значение num_entry_point_offsets должно быть в диапазоне от 0 до ( num_tile_columns_minus1 + 1 ) * ( num_tile_rows_minus1 + 1) - 1, включительно. Когда tiles_or_entropy_coding_sync_idc равно 2, значение num_entry_point_offsets должно быть в диапазоне от 0 до PicHeightInCtbs - 1, включительно. В случае, когда не присутствует, значение num_entry_point_offsets подразумевается равным 0.

Offset_len_minus1 плюс 1 определяет длину, в битах, синтаксических элементов entry_point_offset[ i ].

entry_point_offset[ i ] определяет i-е смещение точки входа, в байтах, и должно быть представлено offset_len_mmusl плюс 1 битами. Закодированные данные слайса после заголовка слайса состоят из num_entry_point_offsets + 1 подмножеств, при этом значения индекса подмножества находятся в диапазоне от 0 до num_entry_point_offsets, включительно. Подмножество 0 состоит из байтов от 0 до entry_point_offset[ 0 ] - 1, включительно, закодированных данных слайса, подмножество k, где k находится в диапазоне от 1 до num_entry_point_offsets - 1, включительно, состоит из байтов от entry_point_offset[ k-1 ] до entry _point_offset[ k ] + entry_point_offset[ k-1 ] - 1, включительно, закодированных данных слайса, и последнее подмножество (с индексом подмножества, равным num_entry_point_offsets) состоит из оставшихся байт закодированных данных слайса.

Когда tiles_or_entropy_coding_sync_idc равно 1, и num_entry_point_offsets больше, чем 0, каждое подмножество должно содержать все закодированные биты ровно одного фрагмента изображения, и количество подмножеств (т.е. значение num_entry_point_offsets + 1) должно быть равно или меньше, чем количество фрагментов изображения в слайсе.

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

Когда tiles_or_entropy_coding_sync_idc равно 2, и num_entry_pomt_offsets больше, чем 0, каждое подмножество k, где k находится в диапазоне от 0 до num_entry_point_offsets - 1, включительно, должно содержать все закодированные биты ровно одной строки блоков дерева кодирования, последнее подмножество (с индексом подмножества, равным num_entry_point_offsets), должно содержать все закодированные биты оставшихся блоков кодирования, включенных в слайс, где оставшиеся блоки кодирования состоят либо из ровно одной строки блоков дерева кодирования, либо из подмножества одной строки блоков дерева кодирования, и количество подмножеств (т.е. значение num_entry_point_offsets + 1) должно быть равно количеству строк блоков дерева кодирования в слайсе, где подмножество одной строки блоков дерева кодирования в слайсе также считается.

Когда tiles_or_entropy_coding_sync_idc равно 2, слайс может включать в себя ряд блоков дерева кодирования и подмножество строки блоков дерева кодирования. Например, если слайс включает в себя две с половиной строки блоков дерева кодирования, количество подмножеств (т.е. значение num_entry_point_offsets + 1) должно быть равно 3.

Фиг. 9 показывает синтаксис RBSP набора параметров изображения в [2], при этом семантика RBSP набора параметров изображения в [2] определена как:

dependent_slice_enabled_flag, равный 1, определяет присутствие синтаксического элемента dependent_slice_flag в заголовке слайса для закодированных изображений, относящихся к набору параметров изображения. dependent_slice_enabled_flag, равный 0, указывает на отсутствие синтаксического элемента dependent_slice_flag в заголовке изображения для закодированных изображений, относящихся к набору параметров изображения. Когда tiles_or_entropy_coding_sync_idc равно 3, значение dependent_slice_enabled_flag должно быть равно 1.

tiles_or_entropy_coding_sync_idc, равное 0, указывает, что должен быть только один фрагмент изображения в каждом изображении, относящемся к набору параметров изображения, не будет никакого определенного процесса синхронизации для контекстных переменных, вызванного до декодирования первого блока дерева кодирования строки блоков дерева кодирования в каждом изображении, относящемся к набору параметров изображения, и значения cabac_independent_flag и dependent_slice_flag для закодированных изображений, относящихся к набору параметров изображения, не должны быть оба равны 1.

Когда cabac_independent_flag и dependent_slice_flag оба равны 1 для слайса, слайс представляет собой энтропийный слайс.

tiles_or_entropy_coding_sync_idc, равное 1, указывает, что может быть больше одного фрагмента изображения в каждом изображении, относящемся к набору параметров изображения, не будет никакого определенного процесса синхронизации для контекстных переменных, вызванного до декодирования первого блока дерева кодирования строки блоков дерева кодирования в каждом изображении, относящемся к набору параметров изображения, и значения cabac_independent_flag и dependent_slice_flag для закодированных изображений, относящихся к набору параметров изображения, не должны быть оба равны 1.

tiles_or_entropy_coding_sync_idc, равное 2, указывает, что должен быть только один фрагмент изображения в каждом изображении, относящемся к набору параметров изображения, определенный процесс синхронизации для контекстных переменных должен быть вызван до декодирования первого блока дерева кодирования строки блоков дерева кодирования в каждом изображении, относящемся к набору параметров изображения, и определенный процесс запоминания для контекстных переменных должен быть вызван после декодирования двух блоков дерева кодирования строки блоков дерева кодирования в каждом изображении, относящемся к набору параметров изображения, и значения cabac_independent_flag и dependent_slice_flag для закодированных изображений, относящихся к набору параметров изображения, не должны быть оба равны 1.

tiles_or_entropy_coding_sync_idc, равное 3, указывает, что должен быть только один фрагмент изображения в каждом изображении, относящемся к набору параметров изображения, не будет никакого определенного процесса синхронизации для контекстных переменных, вызванного до декодирования первого блока дерева кодирования строки блоков дерева кодирования в каждом изображении, относящемся к набору параметров изображения, и значения cabac_independent_flag и dependent_slice_flag для закодированных изображений, относящихся к набору параметров изображения, оба могут быть равны 1.

Когда dependent_slice_enabled_flag shall должно быть равно 0, tiles_or_entropy_coding_sync_idc не должно быть равно 3.

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

Для каждого слайса, относящегося к набору параметров изображения, когда tiles_of_entropy_coding_sync_idc равно 2, и первый блок кодирования в слайсе не является первый блоком кодирования в первом блоке дерева кодирования строки блоков дерева кодирования, последний блок кодирования в слайсе должен принадлежать той же строке блоков дерева кодирования, что и первый блок кодирования в слайсе.

num_tile_columns_minus1 плюс 1 определяет количество столбцов фрагментов изображения, разделяющих изображение.

num_tile_rows_minus1 плюс 1 определяет количество строк фрагментов изображения, разделяющих изображение. Когда num_tile_columns_minus1 равно 0, num_tile_rows_minus1 не должно быть равно 0.

uniform_spacing_flag, равный 1, указывает, что границы столбцов и подобным образом границы строк распределены равномерно по изображению. uniform_spacing_flag, равный 0, указывает, что границы столбцов и подобным образом границы строк не распределены равномерно по изображению, но сигнализируются явно с использованием синтаксических элементов column_width[ i ] и row_height[ i ].

column_width[ i ] определяет ширину i-го столбца фрагмента изображения в единицах блоков дерева кодирования.

row_height[ i ] определяет высоту i-й строки фрагмента изображения в единицах блоков дерева кодирования.

Вектор colWidth[ i ] определяет ширину i-го столбца фрагмента изображения в единицах CTB, при этом столбец i находится в диапазоне от 0 до num_tile_columns_minus1, включительно.

Вектор CtbAddrRStoTS[ ctbAddrRS ] определяет преобразование из адреса CTB в растровом порядке сканирования в адрес CTB в порядке сканирования с индексом ctbAddrRS, находящемся в диапазоне от 0 до (picHeightInCtbs * picWidthInCtbs) - 1, включительно.

Вектор CtbAddrTStoRS[ ctbAddrTS ] определяет преобразование из адреса CTB в порядке сканирования фрагментов изображения в адрес CTB в растровом порядке сканирования с индексом ctbAddrTS, находящемся в диапазоне от 0 до (picHeightInCtbs * picWidthInCtbs) - 1, включительно.

Вектор TileId[ ctbAddrTS ] определяет преобразование из адреса CTB в порядке сканирования фрагментов изображения в id фрагмента изображения с ctbAddrTS, находящемся в диапазоне от 0 до (picHeightInCtbs * picWidthInCtbs) - 1, включительно.

Значения colWidth, CtbAddrRStoTS, CibAudrTSloRS и TileId получены путем вызова процесса преобразования растра CTB и сканирования фрагментов изображения, как определено в подпункте 6.5.1, с PicHeightInCtbs and PicWidthInCtbs в качестве входных данных, а выходные данные присваиваются colWidth, CtbAddrRStoTS и TileId.

Значения ColumnWidthInLumaSamples[ i ], определяющие ширину i-го столбца фрагмента изображения в единицах выборки яркости, устанавливаются равными colWidth[ i ] << Log2CtbSize.

Массив MinCbAddrZS[ x ][ y ], определяющий преобразование из местоположения ( x, y ) в единицах минимальных CB в минимальный адрес CB в z-порядке сканирования с x, находящимся в диапазоне от 0 до picWidthInMinCbs - 1, включительно, и y, находящимся в диапазоне от 0 до picHeightInMinCbs - 1, включительно, получен путем вызова процесса инициализации массива Z порядка сканирования, как определено в подпункте 6.5.2, с Log2MinCbSize, Log2CtbSize, PicHeightInCtbs, PicWidthInCtbs, и вектором CtbAddrRStoTS в качестве входных данных, а выходные данные присваиваются MinCbAddrZS.

loop_filter_across_tiles_enabled_flag, равное 1, указывает, что операции внутрицикловой фильтрации выполняются через границы фрагмента изображения. loop_filter_across_tiles_enabled_flag, равное 0, указывает, что операции внутрицикловой фильтрации не выполняются через границы фрагмента изображения. Операции внутрицикловой фильтрации включают в себя операции деблокирующего фильтра, адаптивного смещения образца и адаптивного контурного фильтра. В случае, когда не присутствует, значение loop_filter_across_tiles_ enabled_flag подразумевается равным 1.

cabac_independent_flag, равное 1, определяет, что декодирование CABAC блоков кодирования в слайсе независимо от любого состояния ранее декодированного слайса. cabac_independent_flag, равное 0, определяет, что декодирование CABAC блоков кодирования в слайсе зависит от состояний ранее декодированного слайса. В случае, когда не присутствует, значение cabac_independent_flag подразумевается равным 0.

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

Входные данные для этого процесса следующие

- минимальный адрес minCbAddrZS блока кодирования в z-порядке сканирования

- текущий минимальный адрес currMinCBAddrZS блока кодирования в z-порядке сканирования

Выходными данными этого процесса является доступность блока кодирования с минимальным адресом cbAddrZS блока кодирования в z-порядке сканирования cbAvailable.

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

Следует отметить, что любой блок кодирования, вне зависимости от его размера, связан с минимальным адресом блока кодирования, который представляет собой адрес блока кодирования с минимальным разрмером блока кодирования в z-порядке сканирования.

- Если одно или более из следующих условий верно, cbAvailable устанавливается в ЛОЖНО.

- minCbAddrZS меньше, чем 0

- minCbAddrZS больше, чем currMinCBAddrZS

- блок кодирования с минимальным адресом minCBAddrZS блока кодирования принадлежит другому слайсу, чем блок кодирования с текущим минимальным адресом currMinCBAddrZS блока кодирования, и dependent_slice_flag слайса, содержащего блок кодирования с текущим минимальным адресом currMinCBAddrZS блока кодирования, равен 0.

- блок кодирования с минимальным адресом minCBAddrZS блока кодирования содержится в другом фрагменте изображения, чем блок кодирования с текущим минимальным адресом currMinCBAddrZS блока кодирования.

- В противном случае, cbAvailable устанавливается в ИСТИННО.

Процесс синтаксического анализа CABAC для данных слайса в [2] был следующим:

Процесс вызывается при синтаксическом анализе синтаксических элементов с дескриптором ae(v).

Входными данными для этого процесса являются запрос значения синтаксического элемента и значения ранее синтаксически проанализированных синтаксических элементов.

Выходные данные этого процесса представляют собой значение синтаксического элемента.

При запуске синтаксического анализа данных слайса вызывается процесс инициализации процесса синтаксического анализа CABAC.

Минимальный адрес блока кодирования блока дерева кодирования, содержащего пространственный соседний блок T (Фиг. 10a), ctbMinCbAddrT, получается с использованием местоположения ( x0, y0 ) верхней левой выборки яркости текущего блока дерева кодирования следующим образом.

x = x0 + 2 << Log2CtbSize – 1

y = y0 - 1

ctbMinCbAddrT = MinCbAddrZS[ x >> Log2MinCbSize ][ y >> Log2MinCbSize ]

Переменная availableFlagT получена путем вызова процесса получения доступности блока кодирования с CtbMinCbAddrT в качестве входных данных.

При запуске синтаксического анализа дерева кодирования применяются следующие упорядоченные шаги.

1. Движок арифметического декодирования инициализируется следующим образом.

- Если CtbAddrRS равно slice_address, dependent_slice_flag равен 1, и entropy_coding_reset_flag равно 0, применяется следующее.

- Вызывается процесс синхронизации процесса синтаксического анализа CABAC с TableStateIdxDS и TableMPSValDS в качестве входных данных.

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

- В противном случае, если tiles_or_entropy_coding_sync_idc равно 2, и CtbAddrRS % PicWidthInCtbs равно 0, применяется следующее.

- Когда availableFlagT равно 1, вызывается процесс синхронизации процесса синтаксического анализа CABAC с TableStateIdxWPP и TableMPSValWPP в качестве входных данных.

- Вызывается процесс декодирования для двоичных решений перед вызовом завершения, за которым следует процесс инициализации для движка арифметического декодирования.

2. Когда cabac_independent_flag равен 0, и dependent_slice_flag равен 1, или когда tiles_or_entropy_coding_sync_idc равно 2, процесс запоминания применяется следующим образом.

- Когда tiles_or_entropy_coding_sync_idc равно 2, и CtbAddrRS % PicWidthInCtbs равно 2, вызывается процесс запоминания процесса синтаксического анализа CABAC с TableStateIdxWPP и TableMPSValWPP в качестве выходных данных.

- Когда cabac_independent_flag равен 0, dependent_slice_flag равен 1, и end_of_slice_flag равен 1, вызывается процесс запоминания процесса синтаксического анализа CABAC с TableStateIdxDS and TableMPSValDS в качестве выходных данных.

Синтаксический анализ синтаксических элементов продолжается следующим образом:

Для каждого запрошенного значения синтаксического элемента получают бинаризацию (преобразование в двоичное представление).

Бинаризация синтаксического элемента и последовательности синтаксически проанализированных контейнеров определяет течение процесса декодирования.

Для каждого контейнера бинаризации синтаксического элемента, который проиндексирован переменной binIdx, получают индекс ctxIdx.

Для каждого ctxIdx вызывается процесс арифметического декодирования.

Результирующая последовательность (b₀..b_binIdx) синтаксически проанализированных контейнеров сравнивается с набором контейнерных строк, заданным процессом бинаризации после декодирования каждого контейнера. Когда последовательность соответствует контейнерной строке в заданном наборе, соответствующее значение присваивается синтаксическому элементу.

В случае если запрос значения синтаксического элемента обрабатывается для синтаксического элемента pcm-flag, и декодированное значение pcm-flag равно 1, движок декодирования инициализируется после декодирования любого pcm_alignment_zero_bit, num_subsequent_pcm, и всех данных pcm_sample_luma и pcm_sample_chroma.

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

Необходимо знать тайминг блоков декодирования до кодирования и отправки данных в сценарии с малой задержкой, где блоки NAL будут уже отправлены декодером, тогда как декодер все еще кодирует части изображения, т.е. другие блоки декодирования под-изображения. Это из-за того, что порядок блоков NAL в блоке доступа позволяет лишь сообщениям SEI предшествовать VCL (блокам NAL Кодирования Видеосигнала) в блоке доступа, но в таком сценарии с малой задержкой не-VCL NAL блоки должны быть уже в проводе, т.е. отправлены, если кодер начинает кодирования блоков декодирования. Фиг. 10b иллюстрирует структуру блока доступа, как определено в [2]. [2] еще не определило окончание последовательности потока, поэтому их присутствие в блоке доступа было предварительным.

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

Дополнительные недостатки проекта спецификации [2] включают в себя многочисленные сигнализации уровня под-изображения, которые требуются для определенных приложений, такие как сигнализация ROI или сигнализация измерений фрагментов изображений.

Изложенные выше проблемы не являются специфическими для стандарта HEVC. Скорее, эта проблема происходит также в связи с другими видеокодеками. Фиг. 11 показывает, более широко, пейзаж передачи видео, где пара кодера 10 и декодера 12 соединены через сеть 14, чтобы передать видео 16 из кодера 10 в декодер 12 с короткой сквозной задержкой. Проблема, уже обрисованная в общих чертах выше, заключается в следующем. Кодер 10 кодирует последовательность кадров 18 видео 16 в соответствии с определенным порядком декодирования, который, по существу, но не обязательно, следует порядку 20 воспроизведения кадров 18, и каждый кадр 18 проходит через кадровую область кадров 18 некоторым определенным образом, таким как, например, растровым способом сканирования с или без секционирования фрагментов изображения кадров 18. Порядок декодирования управляет доступностью информации для методов кодирования, используемых кодером 19, таких как, например предсказательное и/или энтропийное кодирование, т.е. доступностью информации, относящейся к пространственно и/или временно соседним частям видео 16, доступным, чтобы служить в качестве основы для предсказания или выбора контекста. Даже хотя кодер 10 может быть в состоянии использовать параллельную обработку, чтобы закодировать кадры 18 видео 16, кодеру 10 обязательно нужно некоторое время, чтобы закодировать определенный кадр 18, такой как текущий кадр. Фиг. 11, например, иллюстрирует момент времени, когда кодер 10 уже закончил кодирование части 18a текущего кадра 18, тогда как другая часть 18b текущего кадра 18 еще не была закодирована. Поскольку кодер 10 еще не закодировал часть 18b, кодер 10 может не предвидеть, как доступная скорость передачи данных для кодирования текущего кадра 18 должна быть распределена пространственно по текущему кадру 18, чтобы достичь оптимального с точки зрения, например, скорости/искажения, значения. Соответственно, кодер 10 имеет лишь два варианта: либо кодер 10 оценивает близкое к оптимальному распределение доступной скорости передачи данных для текущего кадра 18 на слайсы, на которые текущий кадр 18 пространственно подразделен заранее, соответственно, допуская, что оценка может быть неверной, либо кодер 10 завершает кодирование текущего кадра 18 до передачи пакетов, содержащих слайсы, из кодера 10 в декодер 12. В любом случае, для того, чтобы иметь возможность воспользоваться преимуществом любой передачи слайсовых пакетов текущего закодированного кадра 18 до завершения его кодирования, сеть 14 должна быть проинформирована о скоростях передачи данных, связанных с каждым слайсовым пакетом, в форме времен извлечения буфера кодированного изображения. Однако, как указано выше, хотя декодер 10, в соответствии с текущей версией HEVC, имеет возможность менять скорость передачи данных, распределенную по кадрам 18, путем использования определения времен извлечения буфера кодированного изображения для областей под-изображения отдельно, кодеру 10 необходимо передавать или отправлять такую информацию через сеть 14 в декодер 12 в начале каждого блока доступа, собирая все данные, относящиеся к текущему кадру 18, тем самым заставляя кодер 10 выбирать из только что описанных в общих чертах двух альтернатив, одна из которых приводит в более низкой задержке, но более плохому соотношению скорость/искажение, другая приводит к оптимальному соотношению скорость/искажения, но с увеличенной сквозной задержкой.

Таким образом, до сих пор не существует видеокодека, делающего возможным достижение такой низкой задержки, что кодер имел бы возможность начинать передачу пакетов, относящихся к частям 18a текущего кадра, до кодирования оставшейся части 18b текущего кадра, при этом декодер способен использовать эту промежуточную передачу пакетов, относящихся к предварительным частям 18a, посредством сети 16, которая подчиняется таймингу извлечения буфера декодирования, переданному в потоке видеоданных, отправленном из кодера 12 в декодер 14. Применения, которые бы, например, воспользовались бы такой низкой задержкой, примерно охватывают промышленные применения, такие как, например, обрабатываемая деталь или наблюдение за производством в целях автоматизации или проверки или тому подобного. До сих пор также нет удовлетворительного решения для информирования стороны декодирования о связи пакетов с фрагментами изображения, на которые текущий кадр структурирован, и интересными областями (областями интереса) текущего кадра, так чтобы промежуточные сетевые объекты в сети 16 имели возможность собирать такую информацию из потока данных без необходимости глубоко изучать внутренности пакетов, т.е. синтаксис кадров.

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

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

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

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

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

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

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

Фиг. 1-10b показывают текущий статус HEVC, при этом Фиг. 1 показывает синтаксис сообщения SEI периода буферизации, Фиг. 2 показывает синтаксис сообщения SEI тайминга изображения, Фиг. 3 показывает синтаксис параметра VUI, Фиг. 4 показывает синтаксис параметра HRD, Фиг. 5 показывает синтаксис данных заполнения RBSP, Фиг. 6 показывает структуру потоков байтов и потоков блоков NAL для проверок соответствия HRD. Фиг. 7 показывает модель буфера HRD, Фиг. 8 показывает синтаксис заголовка слайса, Фиг. 9 показывает синтаксис набора RBSP параметров изображения, Фиг. 10a показывает схематическую иллюстрацию пространственно соседнего блока T дерева кодирования, возможно используемого для вызова процесса получения доступности блока дерева кодирования относительно текущего блока дерева кодирования, и Фиг. 10b показывает определение структуры блока доступа;

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

Фиг. 12 показывает схематическую структурную схему кодера в соответствии с вариантом осуществления, использующим пакеты управления таймингом;

Фиг. 13 показывает блок-схему, иллюстрирующую режим работы кодера на Фиг. 12 в соответствии с вариантом осуществления;

Фиг. 14 показывает структурную схему варианта осуществления декодера таким образом, чтобы объяснить его функциональность в связи с потоком видеоданных, сгенерированных кодером согласно Фиг. 12;

Фиг. 15 показывает схематическую структурную схему, иллюстрирующую кодер, сетевой объект и поток видеоданных в соответствии с дополнительным вариантом осуществления, использующим пакеты ROI;

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

Фиг. 17 показывает структуру блока доступа в соответствии с вариантом осуществления. Пунктирная линия отражает случай необязательного блока NAL префикса слайса;

Фиг. 18 показывает использование фрагментов изображения в сигнализации области интереса;

Фиг. 19 показывает первый простой синтаксис/версию 1;

Фиг. 20 показывает расширенный синтаксис/версию 2, включающий в себя сигнализацию tile_id, идентификатор начала блока декодирования, ID префикса слайса и данные заголовка слайса, за исключением концепции сообщения SEI;

Фиг. 21 показывает код типа блока NAL и классы типа блока NAL;

Фиг. 22 показывает возможный синтаксис для заголовка слайса, где определенные синтаксические элементы, присутствующие в заголовке слайса в соответствии с текущей версией, сдвинуты к синтаксическому элементу более низкой иерархии, называемому slice_header_data();

Фиг. 23 показывает таблицу, где все синтаксические элементы, удаленные из заголовка слайса, сигнализируются через данные заголовка слайса синтаксического элемента;

Фиг. 24 показывает синтаксис сообщения дополнительной расширенной информации;

Фиг. 25 показывает адаптированный синтаксис полезной нагрузки SEI, чтобы представить новые типы сообщения SEI слайса или под-изображения;

Фиг. 26 показывает пример для сообщения SEI буферизации под-изображения;

Фиг. 27 показывает пример для сообщения SEI тайминга под-изображения;

Фиг. 28 показывает, как может выглядеть сообщение SEI информации слайса под-изображения.

Фиг. 29 показывает пример для сообщения SEI информации фрагмента под-изображения;

Фиг. 30 показывает пример синтаксиса для сообщения SEI информации размера фрагмента под-изображения;

Фиг. 31 показывает первый вариант примера синтаксиса для области интереса сообщения SEI, где каждый ROI сигнализируется в отдельном сообщении SEI;

Фиг. 32 показывает второй вариант примера синтаксиса для области интереса сообщения SEI, где все ROI сигнализируются в одном сообщении SEI;

Фиг. 33 показывает возможный синтаксис для пакета управления таймингом в соответствии с дополнительным вариантом осуществления;

Фиг. 34 показывает возможный синтаксис для пакета идентификации фрагмента изображения в соответствии с вариантом осуществления;

Фиг. 35-38 показывают возможные подразделения изображения в соответствии с различными настройками подразделения в соответствии с вариантом осуществления; и

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

На Фиг. 12 описан кодер 10 в соответствии с вариантом осуществления настоящего изобретения и его режим работы. Кодер 10 выполнен с возможностью кодирования видеоконтента 16 в поток 22 видеоданных. Кодер выполнен с возможностью делать это в блоках под-частей кадров/изображений 18 видеоконтента 16, где под-части могут, например, быть слайсами 24, на которые изображения 18 разделены, или некоторыми другими пространственными сегментами, такими как, например, фрагменты 26 изображений или подпотоки 28 WPP, все из которых проиллюстрированы на Фиг. 12 только ради иллюстративных целей, а не предположения, что кодер 10 должен иметь возможность поддерживать параллельную обработку WPP, например, или что под-части должны быть слайсами.

В кодировании видеоконтента 16 в блоках под-частей 24 кодер 10 может подчиняться порядку декодирования - или порядку кодирования - определенному среди под-частей 24, который, например, обходит изображения 18 видео 16 в соответствии с порядком декодирования изображения, который, например, не обязательно совпадает с порядком 20 воспроизведения, определенным среди изображений 18, и обходит в каждом изображении 18 блоки, на которые изображения 18 разделены, в соответствии с растровым порядком сканирования, при этом под-части 24 представляют непрерывные проходы таких блоков в соответствии с порядком декодирования. В частности, декодер 10 может быть выполнен с возможностью подчинения порядку в определении доступности пространственно и/или временно соседних частей, которые должны быть закодированы в настоящее время, чтобы использовать атрибуты, описывающие части в предсказательном кодировании и/или энтропийном кодировании, таком как, например, чтобы определить предсказательный и/или энтропийный контекст: Доступны только посещенные ранее (закодированные/декодированные) части видео. В противном случае, только что упомянутые атрибуты устанавливаются в значения по умолчанию, или берутся какие-либо другие меры по замене.

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

Чтобы сформировать закодированные версии под-частей 24, подходящих для передачи по сети, кодер 10 кодирует каждую под-часть 24 в один или более пакетов полезной нагрузки последовательностей пакетов потока 22 видеоданных. В случае, если под-части 24 являются слайсами, декодер 10 может, например, быть выполнен с возможностью помещать данные каждого слайса, т.е. каждый закодированный слайс, в один пакет полезной нагрузки, такой как блок NAL. Это пакетирование может служить для формирования потока 22 видеоданных, подходящего для передачи через сеть. Соответственно, пакеты могут представлять самые маленькие блоки, при которых поток 22 видеоданных может иметь место, т.е. самые маленькие блоки, которые могут быть отдельно отправлены кодером 10 для передачи через сеть получателю.

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

Кодер выполняет кодирование в пакеты полезной нагрузки таким образом, что последовательность пакетов разделена на последовательность блоков 30 доступа, и каждый блок доступа собирает пакеты 32 полезной нагрузки, относящиеся к одному изображению 18 видеоконтента 16. То есть, последовательность 34 пакетов, формирующих поток 22 видеоданных, подразделена на неперекрывающиеся части, называемые блоками 30 доступа, при этом каждый связан с соответствующим одним из изображений 18. Последовательность блоков 30 доступа может следовать за порядком декодирования изображений 18, к которым относятся блоки 30 доступа. Фиг. 12 иллюстрирует, например, что блок 30 доступа, расположенный в середине части проиллюстрированного потока 22 данных, содержит один пакет 32 полезной нагрузки на под-часть 24, на которые изображение 18 подразделено. То есть, каждый пакет 32 полезной нагрузки переносит соответствующую под-часть 24. Кодер 10 выполнен с возможностью помещать в последовательность 34 пакетов пакеты 36 управления таймингом, так что пакеты управления таймингом подразделяют блоки 30 доступа на блоки 38 декодирования, так что по меньшей мере некоторые блоки 30 доступа, такие как средний, показанный на Фиг. 12, подразделены на два или более блока 38 декодирования, при этом каждый пакет управления таймингом сигнализирует время извлечения буфера декодера для блока 38 декодирования, пакеты 32 полезной нагрузки которого следуют за соответствующими пакетами управления таймингом в последовательности 34 пакетов. Другими словами, кодер 10 формирует префикс у подпоследовательностей последовательности пакетов 32 полезной нагрузки в одном блоке 30 доступа с соответствующим пакетом 36 управления таймингом, сигнализирующим для соответствующей подпоследовательности пакетов полезной нагрузки, снабженных префиксом в виде соответствующего пакета 36 управления таймингом и формирующим блок 38 декодирования, время извлечения буфера декодера. Фиг. 12, например, иллюстрирует случай, где каждую секунду пакет 32 представляет первый пакет полезной нагрузки блока 38 декодирования блока 30 доступа. Как проиллюстрировано на Фиг. 12, количество данных или скорость передачи данных, потраченная для каждого блока 38 декодирования, меняется, и времена извлечения буфера декодера могут коррелировать с этим изменением скорости передачи данных среди блоков 38 декодирования в том, что время извлечения буфера декодера блока 38 декодирования может следовать за временем извлечения буфера декодера, сигнализированным пакетом 36 управления таймингом непосредственно предшествующего блока 38 декодирования, сложенным с временным интервалом, соответствующим скорости передачи данных, потраченной для этого непосредственно предшествующего блока 38.

То есть, кодер 10 может работать, как показано на Фиг. 13. В частности, как упомянуто выше, кодер 10 может, на шаге 40, подвергнуть текущую под-часть 24 текущего изображения 18 кодированию. Как уже было отмечено, кодер 10 может последовательно проходить через под-части 24 в вышеупомянутом порядке декодирования, как проиллюстрировано стрелкой 42, или кодер 10 может использовать некоторую параллельную обработку, такую как WPP и/или обработку фрагментов изображений, чтобы одновременно кодировать несколько «текущих под-частей» 24. Вне зависимости от того, используется параллельная обработка или нет, кодер 10 формирует блок декодирования из одной или нескольких под-частей, только что закодированных на шаге 40, и переходит на шаг 44, где кодер 10 устанавливает время извлечения буфера декодера для этого блока декодирования и передает этот блок декодирования, снабженный префиксом в виде пакета управления временем, сигнализирующим только что установленное время извлечения буфера декодера для этого блока декодирования. Например, кодер 10 может определить время извлечения буфера декодера на шаге 44 на основе скорости передачи данных, потраченной для кодирования под-частей, закодированных в пакеты полезной нагрузки, формирующие текущий блок декодирования, включающий в себя, например, все дополнительные промежуточные пакеты в этом блоке декодирования, если таковые есть, т.е. «снабженные префиксом пакеты».

Затем на шаге 46 кодер 10 может адаптировать доступную скорость передачи данных на основе скорости передачи данных, потраченной для блока декодирования, только что переданного на шаге 44. Если, например, контент изображения в блоке декодирования, только что переданном на шаге 44, был достаточно сложным с точки зрения скорости сжатия, то кодер 10 может уменьшить доступную скорость передачи данных для следующего блока декодирования, с тем чтобы подчиниться некоторой внешне установленной скорости передачи данных, определенной, например, на основе текущей ситуации с пропускной способностью, с которой сталкиваются в связи с сетью, передающей поток 22 видеоданных. Затем шаги 40-46 повторяются. С помощью этой меры изображения 18 кодируются и передаются, т.е. отправляются, в единицах блоков декодирования, при этом каждый снабжается префиксом в виде соответствующего пакета управления временем.

Другими словами, кодер 10, во время кодирования текущего изображения 18 видеоконтента 16, кодирует 40 текущую под-часть 24 текущего изображения 18 в текущий пакет 32 полезной нагрузки текущего блока 38 декодирования, передает 44, в потоке данных, текущий блок 38 декодирования, снабженный префиксом в виде текущего пакета 36 управления таймингом, вместе с установкой времени извлечения буфера декодера, сигнализируемого текущим пакетом (36) управления таймингом, в первый момент времени, и кодирует 44, путем возврата к началу цикла с шага 46 на шаг 40, дополнительную под-часть 24 текущего изображения 18 во второй момент времени - второй раз посещая шаг 40 -, позже, чем первый момент времени - первый раз посещая шаг 44.

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

С другой стороны, промежуточные сетевые объекты, ответственные за передачу потока 22 видеоданных дополнительно из кодера в декодер, способны использовать пакеты 36 управления таймингом, с тем чтобы гарантировать, что любой декодер, принимающий поток 22 видеоданных, принимает блоки декодирования вовремя, с тем чтобы иметь возможность получить преимущество декодирования по-пакетного кодирования и передачи кодером 10. См., например, Фиг. 14, показывающую пример для декодера для декодирования потока 22 видеоданных. Декодер 12 принимает поток 22 видеоданных в буфере 48 закодированного изображения CPB с помощью сети, через которую кодер 10 передал поток 22 видеоданных в декодер 12. В частности, поскольку предполагается, что сеть 14 способна поддерживать приложения с малой задержкой, сеть 10 проверяет времена извлечения буфера декодера, с тем чтобы переслать последовательность 34 пакетов потока 22 видеоданных в буфер 48 закодированного изображения декодера 12, так что каждый блок декодирования присутствует в буфере 48 закодированного изображения до времени извлечения буфера декодера, сигнализированного пакетом управления таймингом, являющимся префиксом соответствующего блока декодирования. С помощью этой меры декодер способен, без остановки, т.е. не исчерпывая доступные пакеты полезной нагрузки в буфере 48 закодированного изображения, использовать времена извлечения буфера декодера в пакетах управления таймингом, с тем чтобы опустошить буфер 48 закодированного изображения декодера в единицах блоков декодирования, вместо того чтобы заполнить блоки доступа. Фиг. 14, например, показывает в иллюстративных целях блок 50 обработки соединенным с выходом буфера 48 закодированного изображения, вход которого принимает поток 22 видеоданных. Подобно кодеру 10, декодер 12 может быть способен выполнять параллельную обработку, такую как, например, c использованием параллельной обработки/декодирования фрагментов изображений и/или параллельной обработки/декодирования WPP.

Как будет описано более подробно ниже, времена извлечения буфера декодера, упомянутые до сих пор, не обязательно относятся к временам извлечения, касающимся буфера 48 закодированного изображения декодера 12. Скорее, пакеты управления таймингом могут дополнительно, или альтернативно, управлять извлечением уже декодированных данных изображения соответствующего буфера декодированного изображения декодера 12. Фиг. 14 показывает, например, декодер 12 содержащим буфер изображения декодера, в котором декодированная версия видеоконтента, полученного блоком 50 обработки путем декодирования потока 22 видеоданных, буферизуется, т.е. сохраняется и выводится, в единицах декодированных версий блоков декодирования. Буфер 22 декодированного изображения декодера, таким образом, может быть подключен между выходом декодера 12 и выходом блока 50 обработки. Путем обладания возможностью установить времена извлечения для выводимых декодированных версий блоков декодирования из буфера 52 декодированного изображения, кодеру 10 предоставлена возможность, на лету, т.е. во время кодирования текущего изображения, управлять воспроизведением, или сквозной задержкой воспроизведения видеоконтента на стороне декодирования даже при детализации меньшей, чем частота изображений или частота кадров. Очевидно, что чрезмерная сегментация каждого изображения 18 на огромное количество под-частей 24 на стороне кодирования негативно повлияла бы на скорость передачи данных для передачи потока 22 видеоданных, хотя, с другой стороны, сквозная задержка может быть минимизирована, поскольку время, необходимое для кодирования и передачи и декодирования и вывода такого блока декодирования было бы минимизировано. С другой стороны, увеличение под-частей 24 увеличивает сквозную задержку. Соответственно, должен быть найден компромисс. Использование только что упомянутых времен извлечения буфера декодера, с тем чтобы управлять выходным таймингом декодированных версий под-частей 24 в единицах блоков декодирования, дает возможность кодеру 10 или какому-либо другому блоку на стороне кодирования адаптировать этот компромисс пространственно по контенту текущего изображения. С помощью этой меры было бы возможно управлять сквозной задержкой таким образом, что она меняется пространственно в зависимости от контента текущих изображений.

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

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

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

Фиг. 15 показывает кодер 10, который работает подобно кодеру, объясненному выше по отношению к Фиг. 12, за исключением помещения пакетов управления таймингом и функциональности, описанной выше по отношению к Фиг. 13, которая является опциональной для кодера 10 на Фиг. 15. Однако, кодер 10 на Фиг. 15 выполнен с возможностью кодирования видеоконтента 16 в поток 22 видеоданных в единицах под-частей 24 изображений 18 видеоконтента 16 так же, как это было объяснено выше по отношению к Фиг. 11. В кодировании видеоконтента 16 кодер 10 заинтересован в передаче, вместе с потоком 22 видеоданных, информации об области интереса ROI 60 на сторону декодирования. ROI 60 представляет собой пространственную под-область текущего изображения 18, которой декодер должен, например, уделить особое внимание. Пространственное положение ROI 60 может быть входными данными для кодера 10 снаружи, как проиллюстрировано пунктирной линией 62, например, посредством пользовательского ввода, или может быть определено автоматически кодером 10 или каким-либо другим объектом, на лету во время кодирования текущего изображения 18. В любом случае, кодер 10 сталкивается со следующей проблемой: указание местоположения ROI 60 в принципе не является проблемой для кодера 10. Чтобы сделать это, кодер 10 может легко указать местоположение ROI 60 в потоке 22 видеоданных. Однако, чтобы сделать эту информацию легко доступной, кодер 10 на Фиг. 15 использует помещение пакетов ROI между пакетами полезной нагрузки блоков доступа, так что кодер 10 свободен, на онлайновой основе, выбрать сегментацию текущего изображения 18 на под-части 24 и/или количество пакетов полезной нагрузки, на которые под-части 24 пакетированы, пространственно снаружи и пространственно внутри ROI 60. Используя помещенные пакеты ROI, любой сетевой объект может легко идентифицировать пакеты полезной нагрузки, которые принадлежат ROI. С другой стороны, в случае использования пакетов удаляемого типа для этих пакетов ROI, то же самое может быть легко проигнорировано любым сетевым объектом.

Фиг. 15 показывает пример для помещения пактов 64 ROI между пакетами 32 полезной нагрузки блока 30 доступа. Пакет 64 ROI указывает, где в последовательности 34 пакетов потока 22 видеоданных содержатся закодированные данные, которые относятся, т.е. кодируют, ROI 60. Как пакет 64 ROI указывает местоположение ROI 60 может быть реализовано различными вариантами. Например, чистое существование/возникновение пакета 64 ROI может указывать на включение закодированных данных, относящихся к ROI 60, в один или более из следующих пакетов 32 полезной нагрузки, следующих в последовательном порядке последовательности 34, т.е. принадлежащих снабженным префиксом пакетам полезной нагрузки. Альтернативно, синтаксический элемент внутри пакета 64 ROI может указывать, относится ли один или более из следующих пакетов 32 полезной нагрузки, т.е., по меньшей мере частично кодирует, к ROI 60, или нет. Большое количество колебаний также исходит из возможных изменений, касающихся «области действия» соответствующего пакета 64 ROI, т.е. количества снабженных префиксом пакетов полезной нагрузки, снабженных префиксом в виде одного пакета 64 ROI. Например, указание включения или не-включения любых закодированных данных, относящихся к ROI 60, в один пакет ROI, может относиться ко всем пакетам 32 полезной нагрузки, следующим в последовательном порядке последовательности 34 до возникновения следующего пакета 64 ROI, или может только относиться к непосредственно следующему пакету 32 полезной нагрузки, т.е. пакету 32 полезной нагрузки, непосредственно следующему за соответствующим пакетом 64 ROI в последовательном порядке последовательности 34. На Фиг. 15 график 66 примерно иллюстрирует случай, в котором пакеты 64 ROI указывают релевантность ROI, т.е. включение любых закодированных данных, относящихся к ROI 60, или не-релевантность-ROI, т.е. отсутствие любых закодированных данных, относящихся к ROI 60, в отношении всех пакетов 32 полезной нагрузки, возникающих ниже по потоку от соответствующего пакета 64 ROI до возникновения следующего пакета 64 ROI или окончания текущего блока 30 доступа, что произойдет ранее по последовательности 34 пакетов. В частности, Фиг. 15 иллюстрирует случай, в котором пакет 64 ROI имеет синтаксический элемент внутри, который указывает, имеют или нет пакеты 32 полезной нагрузки, следующие в последовательном порядке последовательности 34 пакетов, какие-либо закодированные данные, относящиеся к ROI 60, внутри. Такой вариант осуществления также описан ниже. Однако, другая возможность, как только что было упомянуто, заключается в том, что каждый пакет 64 ROI указывает лишь своим присутствием в последовательности 34 пакетов, что пакет(ы) 34 полезной нагрузки, принадлежащие «области действия» соответствующего пакета 64 ROI, имеют относящиеся к ROI 60 данные внутри, т.е. данные, относящиеся к ROI 60. В соответствии с вариантом осуществления, описанным ниже более подробно, пакет 64 ROI даже указывает местоположение части ROI 60, закодированной в пакете(ах) 32 полезной нагрузки, принадлежащих его «области действия».

Любой сетевой объект 68, принимающий поток 22 видеоданных, может использовать указание релевантности ROI, как реализовано путем использования пакетов 64 ROI, с тем чтобы обрабатывать, например, релевантные ROI части последовательности 34 пакетов с более высоким приоритетом, чем другие части последовательности 34 пакетов, например. Альтернативно, сетевой объект 68 мог бы использовать информацию релевантности ROI для того, чтобы выполнять другие задачи, относящиеся, например, к передаче потока 22 видеоданных. Сетевой объект 68 может представлять собой, например, MANE или декодер для декодирования и воспроизведения видеоконтента 60, по мере того как он передается через поток 22 видеоданных. 28. Другими словами, сетевой объект 68 может использовать результат идентификации пакетов ROI для того, чтобы выбрать задачи передачи, относящиеся к потоку видеоданных. Задачи передачи могут содержать запросы повторной передачи, касающиеся дефектных пакетов. Сетевой объект 68 может быть выполнен с возможностью обработки области интереса 70 с увеличенным приоритетом и назначения более высокого приоритета пакетам 72 ROI и их связанным пакетам полезной нагрузки, т.е. пакетам, для которых он является префиксом, которые сигнализируются как перекрывающие область интереса, по сравнению с пакетами ROI и их связанными пакетами полезной нагрузки, которые сигнализируются как не перекрывающие ROI. Сетевой объект 68 может сначала запросить повторную передачу пакетов полезной нагрузки, имеющих более высокий приоритет, назначенный им, до запрашивания какой-либо повторной передачи пакетов полезной нагрузки, имеющих более низкий приоритет, назначенный им.

Вариант осуществления на Фиг. 15 может быть легко объединен с вариантом осуществления, описанным ранее по отношению к Фиг. 12-14. Например, пакеты 64 ROI, упомянутые выше, также могут быть пакетами SEI, имеющими определенный тип сообщения SEI, содержащегося в нем, а именно, сообщение SEI ROI. То есть, пакет SEI может, например, быть пакетом управления таймингом и одновременно пакетом ROI, а именно, если соответствующий пакет SEI содержит как информацию управления таймингом, так и информацию указания ROI. Альтернативно, пакет SEI может быть одним из пакета управления таймингом и пакета ROI, а не другим, или может не быть ни пакетом ROI, ни пакетом управления таймингом.

В соответствии с вариантом осуществления, показанным на Фиг. 16, помещение пакетов между пакетами полезной нагрузки блоков доступа используется для указания, способом, легко доступным для сетевых объектов 68, обрабатывающих поток 22 видеоданных, какой фрагмент изображения или фрагменты изображения текущего изображения 18, к которому относится текущий блок 30 доступа, перекрыт какой-либо под-частью, закодированной в любой из пакетов 32 полезной нагрузки, для которых соответствующие пакеты служат в качестве префикса. На Фиг. 16, например, текущее изображение 18, как показано, подразделено на четыре фрагмента 70 изображения, здесь примерно сформированное четырьмя квадрантами текущего изображения 18. Подразделение текущего изображения 18 на фрагменты 70 изображения может, например, быть сигнализировано в потоке видеоданных в блоках, содержащих последовательности изображений, как, например, в пакетах VPS или SPS, также помещенных в последовательность 34 пакетов. Как будет описано более подробно ниже, подразделение на фрагменты изображения текущего изображения 18 может быть стандартным подразделением изображения 18 в столбцы и строки фрагментов изображения. Количество столбцов и количество строк, а также ширина столбцов и высота строк фрагментов изображения могут варьироваться. В частности, ширина и высота столбцов/строк фрагментов изображения могут быть различными для различных строк и различных столбцов, соответственно. Фиг. 16 дополнительно показывает пример, где под-части 24 являются слайсами изображения 18. Слайсы 24 подразделяют изображение 18. Как будет описано более подробно ниже, подразделение изображения 18 на слайсы 24 может быть предметом ограничений, в соответствии с которыми каждый слайс 24 может либо полностью содержаться к одном единственном фрагменте 70 изображения, либо полностью покрывать два или более фрагментов 70 изображения. Фиг. 16 иллюстрирует случай, в котором изображение 18 подразделено на пять слайсов 24. Первые четыре из этих слайсов 24 в вышеупомянутом порядке декодирования покрывают первые два фрагмента 70 изображения, тогда как пятый слайс полностью покрывает третий и четвертый фрагменты 70 изображения. Кроме того, Фиг. 16 иллюстрирует случай, когда каждый слайс 24 отдельно закодирован в соответствующий пакет 32 полезной нагрузки. Кроме того, Фиг. 16 в качестве примера иллюстрирует случай, когда каждый пакет 32 полезной нагрузки снабжен префиксом в виде предшествующего пакета 72 идентификации фрагмента изображения. Каждый пакет 72 идентификации фрагмента изображения, в свою очередь, указывает на следующий непосредственно за ним пакет 32 полезной нагрузки, как на какой из фрагментов 70 изображения под-часть 24, закодированная в этот пакет 32 полезной нагрузки, перекрывает. Соответственно, тогда как первые два пакета 72 идентификации фрагмента изображения в блоке 30 доступа, относящемся к текущему изображению 18, указывают первый фрагмент изображения, третий и четвертый пакеты 72 идентификации фрагмента изображения указывают второй фрагмент 70 изображения 18, а пятый пакет 72 идентификации фрагмента изображения указывает третий и четвертый фрагменты 70 изображения. Что касается варианта осуществления на Фиг. 16, возможны те же самые варианты, как описаны выше по отношению к Фиг. 15, например. То есть, «область действия» пакетов 72 идентификации фрагмента изображения может, например, лишь включать первый непосредственно следующий пакет 32 полезной нагрузки или непосредственно следующие пакеты 32 полезной нагрузки до появления следующего пакета идентификации фрагмента изображения.

Что касается фрагментов изображения, кодер 10 может быть выполнен с возможностью кодирования каждого фрагмента изображения 70 так, что через границы никакого пространственного предсказания или никакого контекстного выбора не имеет места. Кодер 10 может, например, кодировать фрагмент 70 изображения параллельно. Подобным образом, любой декодер, такой как сетевой объект 68, может декодировать фрагменты 70 изображения параллельно.

Сетевой объект 68 может представлять собой MANE или декодер или какое-либо другое устройство между кодером 10 и декодером, и может быть выполнен с возможностью использования информации, переданной пакетами 72 идентификации фрагмента изображения, чтобы выбрать определенные задачи передачи. Например, сетевой объект 68 может обрабатывать определенный фрагмент изображения текущего изображения 18 видео 16 с более высоким приоритетом, т.е. может переслать соответствующие пакеты полезной нагрузки, указанные как относящиеся к такому фрагменту изображения ранее или с использованием более безопасной защиты FEC или подобной. Другими словами, сетевой объект 68 может использовать результат идентификации для того, чтобы выбрать задачи передачи, относящиеся к потоку видеоданных. Задачи передачи могут содержать запросы повторной передачи, касающиеся пакетов, принятых в дефектном состоянии - т.е. с превышением любой защиты FEC потока видеоданных, если таковая имеется. Сетевой объект может обрабатывать, например, различные фрагменты изображения 70 с различным приоритетом. С этой целью сетевой объект может назначить более высокий приоритет пакетам 72 идентификации фрагмента изображения и их пакетам полезной нагрузки, т.е. пакетам, имеющим префикс в виде них, относящимся к фрагментам изображения более высокого приоритета по сравнению с пакетами 72 идентификации фрагмента изображения и их пакетами полезной нагрузки, относящимся к фрагментам изображения более низкого приоритета. Сетевой объект 68 может, например, сначала запросить повторную передачу пакетов полезной нагрузки, имеющих более высокий приоритет, назначенный им, до запрашивания какой-либо повторной передачи пакетов полезной нагрузки, имеющих более низкий приоритет, назначенный им.

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

В частности, сообщения SEI могут быть назначены слайсам блоков декодирования в случае под-изображения CPB/HRD. То есть, период буферизации и сообщения SEI тайминга могут быть назначены блокам NAL, содержащим слайсы блока декодирования. Это может быть достигнуто за счет нового типа блока NAL, который представляет собой не-VCL NAL блок, которому разрешено непосредственно предшествовать одному или более блокам слайса/VCL NAL блока декодирования. Этот новый блок NAL может быть назван блоком NAL префикса слайса. Фиг. 17 иллюстрирует структуру блока доступа, опуская любые предварительные блоки NAL для окончания последовательности и потока.

В соответствии с Фиг. 17, блок 30 доступа объясняется следующим образом: в последовательном порядке пакетов последовательности 34 пакетов блок 30 доступа может начинаться с возникновения специального типа пакета, а именно, разделителя 80 блока доступа. Затем один или более пакетов 82 SEI типа пакета SEI, относящиеся ко всему блоку доступа, могут следовать в блоке 30 доступа. Оба типа 80 и 82 пакетов являются опциональными. То есть, пакетов этого типа может не возникнуть в блоке 30 доступа. Затем следует последовательность блоков 38 декодирования. Каждый блок 38 декодирования опционально начинается с блока 84 NAL префикса слайса, включающего в себя, например, информацию управления таймингом или, в соответствии с вариантом осуществления на Фиг. 15 или 16, информацию ROI или информацию фрагмента изображения или, даже в более широком смысле, соответствующее сообщение 86 SEI под-изображения. Затем следуют фактические данные 88 слайса в соответствующих пакетах полезной нагрузки или блоках VCL NAL, как показано в 88. Таким образом, каждый блок 38 декодирования содержит последовательность блока 84 NAL префикса слайса, за которым следует соответствующий блок(и) 88 NAL данных слайса. Обходная стрелка 90 на Фиг. 17, обходящая блок NAL префикса слайса, указывает, что в случае отсутствия подразделения на блоки декодирования текущего блока 30 доступа может не быть блока 84 NAL префикса слайса.

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

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

Как обсуждено выше по отношению к Фиг. 16, дополнительно или альтернативно, сообщение SEI ID фрагмента изображения/сигнализация ID фрагмента изображения могут быть реализованы в синтаксисе высокого уровня. В более ранних проектах HEVC заголовок слайса/данные слайса содержали идентификатор для фрагмента изображения, содержащегося в соответствующем слайсе. Например, семантика данных слайса считывала:

tile_idx_minus_l определяет TileID в растровом порядке сканирования. Первый фрагмент изображения в изображении должен иметь TileID, равный 0. Значение tile_idx_minus_1 должно быть в диапазоне от 0 до ( num_tile_columns_minus1 + 1 ) * ( num_tile_rows_minus1 + 1) - 1.

Этот параметр, однако, не считается полезным, поскольку этот ID может быть легко получен из адреса слайса и размеров слайса, как просигнализировано в наборе параметров изображения, если tiles_or_entropy_coding_sync_idc равно 1.

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

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

Как описано выше по отношению к Фиг. 15, сообщения SEI области интереса могут также быть дополнительно или альтернативно предоставлены. Такое сообщение SEI могло бы разрешить сигнализацию области интереса (ROI), в частности, сигнализацию ROI, к которой принадлежит определенный tile_id/фрагмент изображения. Сообщение могло бы разрешить задавать ID области интереса плюс приоритет области интереса.

Фиг. 18 иллюстрирует использование фрагментов изображения в сигнализации области интереса;

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

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

Далее описан возможный синтаксис для реализации описанной выше концепции префиксов слайса. В частности, описано, каких изменений может быть достаточно на уровне слайса при использовании статуса HEVC, как описано в вводной части описания настоящей заявки в качестве основы.

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

В качестве предварительного примечания, Фиг. 19 показывает возможную реализацию для реализации любых из вариантов осуществления, описанных выше по отношению к Фиг. 11-16. помещенные пакеты, показанные там, могут быть истолкованы, как показано на Фиг. 19, и в дальнейшем это описано более подробно с конкретными примерами реализации.

Расширенный синтаксис/версия 2, включающий в себя сигнализацию tile_id, идентификатор начала блока декодирования, ID префикса слайса и данные заголовка слайса, за исключением концепции передачи сообщений SEI, приведен в таблице на Фиг. 20.

Семантика могла бы быть определена следующим образом:

rap_flag со значением 1 указывает, что блок доступа, содержащий префикс слайса, представляет собой изображение RAP. rap_flag со значением 0 указывает, что блок доступа, содержащий префикс слайса, не является изображением RAP.

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

single_slice_flag со значением 0 указывает, что информация, предоставленная в блоке NAL заголовка слайса, и связанные сообщения SEI под-изображения действительны для всех последующих блоков VCL-NAL до начала следующего блока доступа, появления префикса другого слайса или другого полного заголовка слайса. single_slice_flag со значением 1 указывает, что вся информация, предоставленная в блоке NAL префикса слайса и связанных сообщениях SEI под-изображения, действительна только для следующего блока VCL-NAL в порядке декодирования.

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

prefix_slice_header_data_present_flag указывает, что данные заголовка слайса, соответствующего слайсам, следующим в порядке декодирования, сигнализируются в заданном префиксе слайса.

slice_header_data() определено далее в тексте. Он содержит релевантную информацию заголовка слайса, которая не покрыта заголовком слайса, если dependent_slice_flag установлен равным 1.

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

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

first_tile_id_in_prefixed_slices указывает идентификатор фрагмента изображения первого фрагмента изображения в следующем блоке декодирования.

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

- decoding_unit_start равен 1, т.е. префикс слайса всегда указывает начало блока декодирования.

- single_slice_flag равен 0, т.е. префикс слайса действителен для всех слайсов в блоке декодирования.

Предложено, чтобы блок NAL префикса слайса имел тип 24 блока NAL, и таблица обзора типа блока NAL была расширена в соответствии с Фиг. 21.

То есть, кратко подводя итог по Фиг. 19-21, подробности синтаксиса, показанные там, показывают, что определенный тип пакета может быть приписан к идентифицированным выше помещенным пакетам, здесь в качестве примера тип 24 блока NAL. Кроме того, особенно пример синтаксиса на Фиг. 20 делает понятным, что описанные выше альтернативы, касающиеся «области действия» помещенных пакетов, механизма переключения, управляемого соответствующим синтаксическим элементом в самих этих помещенных пакетах, здесь в качестве примера single_slice_flag, могут быть использованы, чтобы управлять этой областью действия, т.е. переключать между различными альтернативами для определения этой области действия, соответственно. Кроме того, было сделано понятным, что описанные выше варианты осуществления на Фиг. 1-16 могут быть расширены в том, что помещенные пакеты также содержат общие данные заголовка слайса для слайсов 24, содержащихся в пакетах, принадлежащих «области действия» соответствующих помещенных пакетов. То есть, может быть механизм, управляемый соответствующим флагом внутри этих помещенных пакетов, который указывает, содержатся ли общие данные заголовка слайса в соответствующем помещенном пакете, или нет.

Конечно, концепция, которая только что представила, в соответствии с какой частью заголовка слайса данные сдвигаются в префикс заголовка слайса, требует изменений в заголовках слайса, как определено в текущей версии HEVC. Таблица на Фиг. 22 показывает возможный синтаксис для такого заголовка слайса, где определенные синтаксические элементы, присутствующие в заголовке слайса в соответствии с текущей версией, сдвинуты к синтаксическому элементу более низкой иерархии, называемому slice_header_data(). Синтаксис заголовка слайса и данные заголовка слайса применяются только к опции, в соответствии с которой используется расширенный блок NAL префикса заголовка слайса.

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

Все синтаксические элементы, удаленные из заголовка слайса, сигнализируются через данные заголовка слайса синтаксического элемента, как задано в таблице на Фиг. 23.

То есть, перенося концепцию на Фиг. 22 и Фиг. 23 на варианты осуществления на Фиг. 12-16, помещенные пакеты, описанные в материалах настоящей заявки, могут быть расширены посредством концепции включения в эти помещенные пакеты части синтаксиса заголовка слайса слайсов (под-частей) 24, закодированных в пакеты полезной нагрузки, т.е. блоки VCL NAL. Включение может быть опциональным. То есть, соответствующий синтаксический элемент в помещенном пакете может указывать, содержится ли такой синтаксис заголовка слайса в соответствующем помещенном пакете, или нет. Если содержится, соответствующие данные заголовка слайса, включенные в соответствующий помещенный пакет, могут применяться ко всем слайсам, содержащимся в пакете, принадлежащем «области действия» соответствующего помещенного пакета. Адаптированы ли данные заголовка слайса, содержащиеся в помещенном пакете, слайсом, закодированным в любой из пакетов полезной нагрузки, принадлежащий области действия этого помещенного пакета, может быть сигнализировано соответствующим флагом, таким как slice_header_data_present_flag на Фиг. 22. С помощью этой меры заголовки слайсов, закодированных в пакеты, принадлежащие «области действия» соответствующего помещенного пакета, могут быть уменьшены в размерах соответственно с использованием только что упомянутого флага в заголовке слайса, и любой декодер, принимающий поток видеоданных, такой как сетевые объекты, показанные на приведенных выше Фиг. 12-16, реагировал бы на только что упомянутый флаг в заголовке слайса, с тем чтобы скопировать данные заголовка слайса, включенные во помещенный пакет, в заголовок слайса, закодированного в пакет полезной нагрузки, принадлежащий области действия этого помещенного пакета, в случае соответствующего флага в этом слайсе, сигнализирующего смещение данных заголовка слайса к префиксу слайса, т.е. соответствующему помещенному пакету.

Продолжая дальше с примером синтаксиса для реализации вариантов осуществления на Фиг. 12-16, синтаксис сообщения SEI может быть таким, как показано на Фиг. 24. Чтобы представить типы сообщения SEI слайса или под-изображения, синтаксис полезной нагрузки SEI может быть адаптирован, как представлено в таблице на Фиг. 25. Только сообщение SEI с payloadType в диапазоне от 180 до 184 может быть отправлено исключительно на уровне под-изображения в блоке NAL префикса слайса. Кроме того, сообщения SEI области интереса с payloadType, равным 140, могут быть отправлены либо в блоке NAL префикса слайса на уровне под-изображения, либо в обычном сообщении SEI на уровне блока доступа.

То есть, в переносе подробностей, показанных на Фиг. 25 и 24, на варианты осуществления, описанные выше, по отношению к Фиг. 12-16, помещенные пакеты, показанные в этих вариантах осуществления на Фиг. 12-16, могут быть реализованы путем использования блоков NAL префикса слайса с определенным типом блока NAL, например, 24, содержащим определенный тип сообщения SEI, сигнализированного посредством payloadType в начале каждого сообщения SEI в блоке NAL префикса слайса, например. В определенном варианте осуществления синтаксиса, описанном сейчас, payloadType = 180 и payloadType = 181 имеет результатом пакет управления таймингом в соответствии с вариантом осуществления на Фиг. 11-14, тогда как payloadType = 140 имеет результатом пакет ROI в соответствии с вариантом осуществления на Фиг. 15, а payloadType = 182 имеет результатом пакет идентификации фрагмента изображения в соответствии с вариантом осуществления на Фиг. 16. Пример конкретного синтаксиса, описанный в материалах настоящей заявки ниже, может содержать лишь одну или подмножество только что упомянутых опций payloadType. Помимо этого, Фиг. 25 показывает, что любые из описанных выше вариантов осуществления на Фиг. 11-16 могут быть объединены друг с другом. Еще дополнительно, Фиг. 25 показывает, что любой из приведенных выше вариантов осуществления на Фиг. 12-16, или любая их комбинация может быть расширена посредством дополнительного помещенного пакета, впоследствии объясненного с payloadType = 184. Как уже было описано выше, расширение, описанное ниже по отношению к payloadType = 183, заканчивается возможностью, что любые помещенные пакеты могли включить туда общие данные заголовка слайса для заголовков слайсов, закодированных в любой пакет полезной нагрузки, принадлежащий его области действия.

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

Фиг. 26, например, показывает пример для сообщения SEI буферизации под-изображения, возникающего всякий раз когда блок NAL префикса слайса типа 24 блока NAL имеет тип 180 сообщения SEI, включенного туда, таким образом формируя пакет управления таймингом.

Семантика могла бы быть определена следующим образом:

seq_parameter_set_id определяет набор параметров последовательности, который содержит атрибуты HRD последовательности. Значение seq_parameter_set_id будет равно значению seq_parameter_set_id в наборе параметров изображения, на который ссылается первичное закодированное изображение, связанное с сообщением SEI периода буферизации. Значение seq_parameter_set_id должно быть в диапазоне от 0 до 31, включительно.

initial_cpb_removal_delay[ SchedSelIdx ] и initial_alt_cpb_removal_delay[ SchedSelIdx ] определяют исходные задержки удаления CPB для SchedSelIdx-го CPB блока декодирования (под-изображения). Синтаксические элементы имеют длину в битах, заданную посредством initial_cpb_removal_delay_length_minus1 + 1, и выражены в единицах 90 кГц тактового сигнала. Значения синтаксических элементов не будут равны 0 и не будут превышать 90000 * ( CpbSize[ SchedSelIdx ] ÷ BitRate[ SchedSelIdx ]), временной эквивалент размера CPB в единицах 90 кГц тактового сигнала.

По всей закодированной видеопоследовательности сумма initial_cpb_removal_delay[ SchedSelIdx ] и initial_cpb_removal_delay_offset[ SchedSelIdx ] на блок декодирования (под-изображения) должна быть постоянной для каждого значения SchedSelIdx, и сумма initial_alt_cpb_removal_delay[ SchedSelIdx ] и initial_alt_cpb_removal_delay_offset[ SchedSelIdx ] должна быть постоянной для каждого значения SchedSelIdx.

Фиг. 27 показывает также пример для сообщения SEI тайминга под-изображения, где семантика могла бы быть описана следующим образом:

du_cpb_removal_delay определяет, сколько тактов синхронизации ждать после удаления из CPB блока декодирования (под-изображения), связанного с самым недавним сообщением SEI периода буферизации под-изображения в предшествующем блоке доступа в том же блоке декодирования (под-изображении), если таковой присутствует, в противном случае связанного с самым недавним сообщением SEI периода буферизации в предшествующем блоке доступа, перед удалением из буфера данных блока декодирования (под-изображения), связанных с сообщением SEI тайминга под-изображения. Это значение также используется для вычисления самого раннего возможного времени прибытия данных блока декодирования (под-изображения) в CPB для HSS (Гипотетический Планировщик Потока [2]0). Синтаксический элемент представляет собой код фиксированной длины, чья длина в битах задана посредством cpb_removal_delay_length_minus1 + 1. cpb_removal_delay представляет собой остаток от счетчика по модулю 2^(cpb_removal_delay_length_minus1 + 1).

du_dpb_output_delay используется для вычисления времени вывода DBP блока декодирования (под-изображения). Он определяет, сколько тактов синхронизации ждать после удаления декодированного блока декодирования (под-изображения) из CPB до того, как блок декодирования (под-изображение) будет выведен из DPB.

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

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

Фиг. 28 показывает, как может выглядеть сообщение SEI информации слайса под-изображения. Семантика могла бы быть определена следующим образом:

slice_header_data_flag со значением 1 указывает, что данные заголовка слайса присутствуют в сообщении SEI. Данные заголовка слайса, предоставленные в SEI, являются действительными для всех слайсов, следующих в порядке декодирования до окончания блока доступа, появления данных слайса в другом сообщении SEI, блока NAL слайса или блока NAL префикса слайса.

Фиг. 29 показывает пример для сообщения SEI информации фрагмента под-изображения, где семантика могла бы быть определена следующим образом:

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

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

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

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

То есть, вариант осуществления на Фиг. 16 мог бы быть реализован с использованием синтаксиса на Фиг. 29 для реализации пакетов идентификации фрагмента изображения, упомянутых на Фиг. 16. Как там показано, определенный флаг, здесь multiple_tiles_in_prefixed_slices_flag, может быть использован для сигнализации в помещенном пакете идентификации фрагмента изображения того, покрыт ли только один фрагмент изображения или больше, чем один фрагмент изображения любой под-частью текущего изображения 18, закодированного в любой из пакетов полезной нагрузки, принадлежащий области действия соответствующего помещенного пакета идентификации фрагмента изображения. Если флаг сигнализирует перекрытие более, чем одного, фрагмента изображения, дополнительный синтаксический элемент содержится в соответствующем помещенном пакете, здесь в качестве примера num_tiles_in_prefixed_slices_minus1, указывающий количество фрагментов изображения, перекрытых любой под-частью любого пакета полезной нагрузки, принадлежащего области действия соответствующего помещенного пакета идентификации фрагмента изображения. Наконец, дополнительный синтаксический элемент, здесь в качестве примера first_tile_id_in_prefixed_slices, указывает ID фрагмента изображения среди ряда фрагментов изображения, указанных текущим помещенным пакетом идентификации фрагмента изображения, который является первым в соответствии с порядком декодирования. Перенося синтаксис Фиг. 29 на вариант осуществления на Фиг. 16, пакет 72 идентификации фрагмента изображения, являющийся префиксом для пятого пакета 32 полезной нагрузки, мог бы, например, иметь все три только что обсужденных синтаксических элемента с multiple_tiles_in_prefixed_slices_flag, установленным в 1, num_tiles_in_prefixed_slices_minus1, установленным в 1, тем самым указывая, что два фрагмента изображения принадлежат текущей области действия, и пакет 72 идентификации фрагмента изображения начинается на третьем фрагменте изображения (имеющем tile_id = 2).

Фиг. 29 также показывает, что пакет 72 идентификации фрагмента изображения может, возможно, указывать tile_priority, т.е. приоритет фрагментов изображения, принадлежащих его области действия. Подобно аспекту ROI, сетевой объект 68 может использовать такую информацию приоритета для управления задачами передачи, такими как запрос повторной передачи определенных пакетов полезной нагрузки.

Фиг. 30 показывает пример синтаксиса для сообщения SEI информации размера фрагмента под-изображения, где семантика могла бы быть определена как:

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

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

tile_horz_start[ i ] указывает начало в горизонтальном направлении i-го фрагмента изображения внутри изображения.

tile_width[ i ] указывает ширину i-го фрагмента изображения в пикселях внутри изображения.

tile_vert_start[ i ] указывает начало в горизонтальном направлении i-го фрагмента изображения внутри изображения.

tile_height[ i ] указывает высоту i-го фрагмента изображения в пикселях внутри изображения.

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

Фиг. 30, таким образом, показывает, что пример реализации синтаксиса на Фиг. 29 по отношению к пакетам идентификации фрагмента изображения на Фиг. 16 может варьироваться в том, что фрагменты изображения, принадлежащие области действия соответствующего пакета идентификации фрагмента изображения, указываются их местоположением внутри текущего изображения 18, а не их ID фрагмента изображения. То есть, вместо сигнализирования ID фрагмента изображения первого фрагмента изображения в порядке декодирования, покрытого соответствующими под-частями, закодированными в любой из пакетов полезной нагрузки, принадлежащий области действия соответствующего помещенного пакета идентификации фрагмента изображения, для каждого фрагмента изображения, принадлежащего текущему пакету идентификации фрагмента изображения, его положение могло бы быть сигнализировано путем сигнализирования, например, положения верхнего левого угла каждого фрагмента i изображения, здесь в качестве примера посредством tile_horz_start и tile_vert_start, и ширины и высоты фрагмента i изображения, здесь в качестве примера посредством tile_width и tile_height.

Пример синтаксиса для сообщения SEI области интереса показан на Фиг. 31. Чтобы быть более точными, Фиг. 32 показывает первый вариант. В частности, сообщение SEI области интереса может, например, использоваться на уровне блока доступа или уровне под-изображения для сигнализации одной или более областей интереса. В соответствии с первым вариантом Фиг. 32, отдельная ROI сигнализируется один раз на сообщение SEI ROI, вместо сигнализации всех ROI области действия соответствующего пакета ROI внутри одного сообщения SEI ROI, если несколько ROI находятся в текущей области действия.

В соответствии с Фиг. 31, сообщение SEI области интереса сигнализирует каждую ROI отдельно. Семантика могла бы быть определена следующим образом:

roi_id указывает идентификатор области интереса.

roi_priority указывает приоритет всех фрагментов изображения, которые принадлежат области интереса в снабженных префиксом слайсах или всех слайсах, следующих в порядке декодирования в зависимости от того, отправлено ли сообщение SEI на уровне под-изображения или на уровне блока доступа. Значение roi_priority должно быть в диапазоне от 0 до 7 включительно, где 7 указывает наивысший приоритет. Если оба, roi_priority в сообщении SEI roi_info и tile_priority в сообщениях SEI информации фрагмента изображения под-изображения заданы, наивысшее значение обоих действительно для приоритета отдельных фрагментов изображения.

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

roi_tile_id[ i ] указывает tile_id i-го фрагмента изображения, который принадлежит области интереса в снабженных префиксом слайсах, следующих в порядке декодирования.

То есть, Фиг. 31 показывает, что пакет ROI, как показано на Фиг. 15, мог бы сигнализировать в нем ID области интереса, к которой относятся соответствующий пакет ROI и пакет полезной нагрузки, принадлежащий его области действия. Опционально, индекс приоритета ROI мог бы сигнализироваться вместе с ID ROI. Однако, оба синтаксических элемента являются опциональными. Далее, синтаксический элемент num_tiles_in_roi_minus1 может указывать количество фрагментов изображения в области действия соответствующего пакета ROI, принадлежащего соответствующей ROI 60. Далее, roi_tile_id указывает ID фрагмента изображения i-х фрагментов изображений, принадлежащих ROI 60. Представим, например, что изображение 18 было бы подразделено на фрагменты 70 изображения способом, показанным на Фиг. 16, и что ROI 60 на Фиг. 15 соответствовала бы левой половине изображения 18, было бы сформировано первым и третьим фрагментом изображения в порядке декодирования. Далее, пакет ROI может быть помещен перед первым пакетом 32 полезной нагрузки блока 30 доступа на Фиг. 16, за которым следует дополнительный пакет ROI между четвертым и пятым пакетами 32 полезной нагрузки этого блока 30 доступа. Затем первый пакет ROI имел бы num_tile_in_roi_minus1, установленный в 0, с roi_tile_id[0], равным 0 (тем самым ссылаясь на первый фрагмент изображения в порядке декодирования), где второй пакет ROI перед пятым пакетом 32 полезной нагрузки имел бы num_tiles_in_roi_minus1, установленный в 0, с roi_tile_id[0], установленным в 2 (тем самым обозначая третий фрагмент изображения в порядке декодирования в левой нижней четверти изображения 18).

В соответствии со вторым вариантом, синтаксис сообщения SEI области интереса мог бы быть таким, как показано на Фиг. 32. Здесь все ROI сигнализируются в одном сообщении SEI. В частности, использовался бы тот же синтаксис, что и обсужденный выше по отношению к Фиг. 31, но умножая синтаксические элементы для каждой из ROI из числа ROI, к которым относится соответствующее сообщение SEI ROI или пакет ROI, на число, сигнализируемое синтаксическим элементом, здесь в качестве примера num_rois_minus1. Опционально, дополнительный синтаксический элемент, здесь в качестве примера roi_presentation_on_separate_screen, мог бы сигнализировать для каждой ROI, подходит ли соответствующая ROI для того, чтобы быть представленной на отдельном экране.

Семантика могла бы быть следующей:

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

roi_id[ i ] указывает идентификатор i-й области интереса.

roi_priority[ i ] указывает приоритет всех фрагментов изображения, которые принадлежат области интереса в снабженных префиксом слайсах или всех слайсах, следующих в порядке декодирования в зависимости от того, отправлено ли сообщение SEI на уровне под-изображения или на уровне блока доступа. Значение roi_priority должно быть в диапазоне от 0 до 7 включительно, где 7 указывает наивысший приоритет. Если оба, roi_priority в сообщении SEI roi_info и tile_priority в сообщениях SEI информации фрагмента изображения под-изображения заданы, наивысшее значение обоих действительно для приоритета отдельных фрагментов изображения.

num_tiles_in_roi_minus1[ i ] указывает количество фрагментов изображения в снабженных префиксом слайсах, следующих в порядке декодирования, которые принадлежат i-й области интереса.

roi_tile_id[ i ][ n ] указывает tile_id n-го фрагмента изображения, который принадлежит i-й области интереса в снабженных префиксом слайсах, следующих в порядке декодирования.

roi_presentation_on_seperate_screen [ i ] указывает, что область интереса, связанная с i-м roi_id, подходит для представления на отдельном экране.

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

Для полноты картины, Фиг. 33 показывает дополнительные пример для синтаксиса, который мог бы быть использован для пакета управления таймингом в соответствии с вариантом осуществления на Фиг. 12-14. Семантика могла бы быть:

du_spt_cpb_removal_delay_increment определяет продолжительность, в единицах под-тактов синхронизации, между номинальным временем CPB последнего блока декодирования в порядке декодирования в текущем блоке доступа и блока декодирования, связанного с сообщением SEI информации блока декодирования. Это значение также используется для вычисления самого раннего возможного времени прибытия данных блока декодирования в CPB для HSS, как определено в Приложении C. Синтаксический элемент представлен кодом фиксированной длины, чья длина в битах задана посредством du_cpb_removal_delay_increment_length_minus1 + 1. Когда блок декодирования, связанный с сообщением SEI информации блока декодирования, является последним блоком декодирования в текущем блоке доступа, значение du_spt_cpb_removal_delay_increment должно быть равным 0.

dpb_output_du_delay_present_flag, равный 1, определяет присутствие синтаксического элемента pic_spt_dpb_output_du_delay в сообщении SEI информации блока декодирования. dpb_output_du_delay_present_flag, равный 0, определяет отсутствие синтаксического элемента pic_spt_dpb_output_du_delay в сообщении SEI информации блока декодирования.

pic_spt_dpb_output_du_delay используется для вычисления времени вывода DPB изображения, когда SubPicHrdFlag равен 1. Он определяет, сколько под-тактов синхронизации ждать после удаления последнего блока декодирования в блоке доступа из CPB до того, как декодированное изображение будет выведено из DPB. В случае, когда не присутствует, значение pic_spt_dpb_output_du_delay подразумевается равным pic_dpb_output_du_delay. Длина синтаксического элемента pic_spt_dpb_output_du_delay задана в битах посредством dpb_output_delay_du_length_minus1 + 1.

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

Порядок вывода изображений, установленный значениями этого синтаксического элемента, будет таким же порядком, который установлен значениями PicOrderCntVal.

Для изображений, которые не выводятся процессом «резкого изменения параметров» из-за того, что они предшествуют в порядке декодирования изображению IRAP с NoRaslOutputFlag, равным 1, который имеет no_output_of_prior_pics_flag, равный 1 или подразумевающийся равным 1, моменты времени вывода, полученные из pic_spt_dpb_output_du_delay, должны быть увеличивающимися с увеличивающимся значением PicOrderCntVal по отношению ко всем изображениям в одной и той же CVS. Для любых двух изображений в CVS разница между моментами времени вывода двух изображений, когда SubPicHrdFlag равен 1, должна быть идентична той же самой разнице, когда SubPicHrdFlag равен 0.

Кроме того, Фиг. 34 показывает дополнительный пример для сигнализации области ROI с использованием пакетов ROI. В соответствии с Фиг. 34, синтаксис пакета ROI содержит только один флаг, указывающий, все ли под-части изображения 18, закодированные в какой-либо пакет 32 полезной нагрузки, принадлежащий его области действия, принадлежат ROI, или нет. «Область действия» расширяется до появления пакета ROI или сообщения SEI region_refresh_info. Если флаг равен 1, область указывается как закодированная в соответствующий последующий пакет(ы) полезной нагрузки, а если 0, применяется обратное, т.е. соответствующие под-части изображения 18 не принадлежат ROI 60.

Перед обсуждением некоторых из описанных выше вариантов осуществления снова другими словами с дополнительным объяснением некоторых терминов, использованных выше, таких как фрагмент изображения, слайс и подразделение под-потока WPP, следует отметить, что приведенная выше сигнализация Высокого Уровня варианта осуществления может альтернативно быть определена в транспортных спецификациях, таких как [3-7]. Другими словами, пакеты, упомянутые выше и формирующие последовательность 34, могут быть транспортными пакетами, некоторые из которых имеют подчасти прикладного уровня, такие как слайсы, включенные, например, пакетированные полностью или фрагментированные, туда, некоторые будучи помещенными между последними способом и с целью, обсужденной ниже. Другими словами, вышеупомянутые помещенные пакеты не ограничены, чтобы быть определенными как сообщения SEI других типов блоков NAL, определенных в видеокодеке прикладного уровня, но могли бы альтернативно быть дополнительным транспортным пакетом, определенным в транспортных протоколах.

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

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

Как описано выше, пакеты полезной нагрузки каждый может включать в себя один или более слайсов (полностью, соответственно). Слайсы могут быть независимо декодируемыми или могут показывать взаимоотношения, которые препятствуют их независимому декодированию. Например, энтропийные слайсы могут быть независимо энтропийно декодируемыми, но предсказание за пределами границ слайса может быть запрещено. Зависимые слайсы могут допускать обработку WPP, т.е. кодирование/декодирование с использованием энтропийного и предсказательного кодирования за границами слайса с возможностью параллельного кодирования/декодирования зависимых слайсов способом перекрытия во времени, однако, со ступенчатым началом процедуры кодирования/декодирования отдельных зависимых слайсов и слайса/слайсов, на которые ссылаются зависимые слайсы.

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

См., например, фигуру ниже. Закодированное/декодированное в настоящее время изображение 100 может быть разделено на фрагменты изображения, которые на Фиг. 35 и 36, например, в качестве примера соответствуют четырем квадрантам изображения 110 и указаны ссылочными позициями 112a-112d. То есть, целое изображение 110 может формировать один фрагмент изображения, как в случае на Фиг. 37, или может быть сегментировано на более, чем один, фрагмент изображения. Сегментация фрагмента изображения может быть ограничена обычной сегментацией, в которой фрагменты изображения расположены только в столбцах и строках. Различные примеры представлены ниже.

Как видно, изображение 110 дополнительно подразделено на блоки 114 (дерева) кодирования (маленькие прямоугольники на фигуре и называемые CTB выше), среди которых определен порядок 116 кодирования (здесь, растровый порядок сканирования, но также может быть другим). Подразделение изображения на фрагменты 112a-d изображения может быть ограничено так, что фрагменты изображения представляют собой непересекающиеся наборы блоков 114. Кроме того, как блоки 114, так и фрагменты 112a-d изображения могут быть ограничены стандартным расположением в столбцах и строках.

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

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

Изображение 110 может быть дополнительно подразделено на слайсы 118a-d, 180, ранее указанные с использованием ссылочной позиции 24. Слайс может содержать лишь часть фрагмента изображения, один полный фрагмент изображения или более, чем один, фрагмент изображения полностью. Таким образом, разделение на слайсы также может подразделять фрагменты изображения, как в случае на Фиг. 35. Каждый слайс содержит по меньшей мере один блок 114 кодирования полностью и состоит из последовательных блоков 114 кодирования в порядке 116 кодирования, так что порядок определен среди слайсов 118a-d, после чего индексы на фигуре были назначены. Разделение на слайсы на Фиг. 35-37 было выбрано только в целях иллюстрации. Границы фрагментов изображения могут быть сигнализированы в потоке данных. Изображение 110 может формировать единственный фрагмент изображения, как изображено на Фиг. 37.

Кодер 10 и декодер 12 могут быть выполнены с возможностью удовлетворять условиям границ фрагмента изображения в том, что пространственное предсказание не применяется через границы фрагмента изображения. Адаптация контекста, т.е. вероятностные адаптации различных энтропийных (арифметических) контекстов, может продолжаться по целым частям. Однако, всякий раз когда слайс пересекает - в соответствии с порядком 116 кодирования - границу фрагмента изображения (если присутствует внутри слайса), как, например, на Фиг. 36 по отношению к слайсам 118a,b, то слайс, в свою очередь, подразделяется на подсекции (подпотоки или фрагменты изображения) с слайсом, содержащим указатели (c.p. entry_point_pffset), указывающие на начала каждой подсекции. В цикле декодера фильтрам может быть разрешено пересекать границы фрагмента изображения. Такие фильтры могут включать в себя один или более из деблокирующего фильтра, фильтра Адаптивного Сдвига Сэмпла (SAO) и Адаптивного контурного фильтра (ALF). Последний может быть применен по границам фрагмента изображения/слайса, если активирован.

Каждая опциональная вторая и последующие подсекции могут иметь свои начала, расположенные с байтовым выравниванием в слайсе с указателем, указывающим сдвиг от начала одной подсекции к началу следующей подсекции. Подсекции расположены внутри слайсов в порядке 116 сканирования. Фиг. 38 показывает пример с слайсов 180c на Фиг. 37, который в качестве примера подразделен на подсекции 119i.

Что касается фигур, следует отметить, что слайсы, формирующие подчасти фрагментов изображения, не должны заканчиваться со строкой во фрагменте 112a изображения. См., например, слайс 118a на Фиг. 37 и 38.

Фигура ниже показывает примерную часть потока данных, относящуюся к блоку данных, связанному с изображением 110 приведенной выше Фиг. 38. Здесь каждый пакет 122a-d полезной нагрузки - ранее указанные ссылочной позицией 32 - в качестве примера включает в себя только один слайс 118a. Два пакета 124a,b - ранее указанные ссылочной позицией 36 - показаны как помещенные в блок 120 доступа в иллюстративных целях: 124a предшествует пакету 122a в порядке 126 пакета (соответствующем временной оси де/кодирования), а 124b предшествует пакету 122c. Соответственно, блок 120 доступа разделен на два блока 128a,b декодирования - ранее указанные ссылочной позицией 38 - первый из которых содержит пакеты 122a,b (наряду с опциональными пакетами данных заполнения (следующими за первым и вторым пакетами 122a,b, соответственно) и опциональными ведущими пакетами SEI блока доступа (предшествующими первому пакету 122a)), и второй из которых содержит пакеты 118c,d (наряду с опциональными пакетами данных заполнения (следующими за пакетами 122c,d, соответственно)).

Как было описано выше, каждый пакет последовательности пакетов может быть назначен точно одному типу пакета из множества типов пакетов (nal_unit_type). Пакеты полезной нагрузки и пакеты управления таймингом (и опциональные пакеты данных заполнения и SEI) имеют, например, разный тип пакета. Экземпляры пакетов определенного типа пакета в последовательности пакетов могут быть предметом определенных ограничений. Эти ограничения могут определять порядок среди типов пакета (см. Фиг. 17), которому должны подчиняться пакеты в каждом блоке доступа, так что границы 130a,b блока доступа являются обнаруживаемыми, и остаются в той же позиции в последовательности пакетов, даже если пакеты любого удаляемого типа пакета удалены из потока видеоданных. Например, пакеты полезной нагрузки представляют собой пакеты неудаляемого типа пакета. Однако, пакеты управления таймингом, пакеты данных заполнения и пакеты SEI могут, как обсуждено выше, быть удаляемого типа пакета, т.е. они могут представлять собой не-VCL NAL блоки.

В приведенном выше примере пакеты управления таймингом были явно приведены выше в качестве примера посредством синтаксиса slice_prefix_rbsp().

Используя такое помещение пакетов управления таймингом, кодер имеет возможность регулировать планирование буферизации на стороне декодера в ходе кодирования отдельных изображений видеоконтента. Например, кодер имеет возможность оптимизировать планирование буфера, чтобы минимизировать сквозную задержку. В связи с этим, кодер имеет возможность учитывать отдельное распределение сложности кодирования по области изображения видеоконтента для отдельных изображений видеоконтента. В частности, кодер может непрерывно выводить последовательность пакетов 22, 122a-d, 122a-d_1-3 на по-пакетной основе (т.е. как только текущий пакет был завершен, он выводится). Путем использования пакетов управления таймингом, кодер имеет возможность регулировать планирование буфера на декодирующей стороне в моменты, когда некоторые из под-частей текущего изображения уже были закодированы в соответствующие пакеты полезной нагрузки с оставшимися под-частями, однако, еще не были закодированы.

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

Любой декодер, принимающий только что описанный поток видеоданных, может свободно использовать информацию планирования, содержащуюся к пакете управления таймингом, или нет. Однако, тогда как декодер может свободно использовать информацию, декодер, соответствующий уровню кодека, должен иметь возможность декодировать данные, следующие за указанным таймингом. Если имеет место использование, декодер питает свой буфер декодера и опустошает буфер декодера в единицах блоков декодирования. «Буфер декодера» может, как описано выше, включать в себя буфер декодированного изображения и/или буфер закодированного изображения.

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

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

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

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

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

См., например, непосредственно предшествующую фигуру, показывающую поток данных. Пакеты 124a и 124b теперь представят пакеты идентификации фрагмента изображения. Либо посредством явной сигнализации (сравните single_slice_flag = 1), либо по соглашению, пакет идентификации фрагмента изображения может лишь идентифицировать фрагменты изображения, которые перекрыты слайсами, пакетированными в непосредственно следующий пакет 122a полезной нагрузки. Альтернативно, путем явной сигнализации или по соглашению, пакет 124a идентификации фрагмента изображения может идентифицировать фрагменты изображения, которые перекрыты слайсами, пакетированными в один или более пакетов полезной нагрузки, непосредственно следующие за соответствующим пакетом 124a идентификации фрагмента изображения в последовательности пакетов, до более раннего из окончания 130b текущего блока 120 доступа и начала следующего блока 128b декодирования, соответственно. См., например, Фиг. 35: если каждый слайс 118a-d_1-3 был отдельно пакетирован в соответствующий пакет 122a-d_1-3, с подразделением на блоки декодирования такие, что пакеты сгруппированы в три блока декодирования в соответствии с {122a_1-3}, {122b_1-3} и {122c_1-3, 122d_1-3}, то слайсы {118c_1-3, 118d_1-3} пакетируются в пакеты {122c_1-3, 122d_1-3} третьего блока декодирования, например, фрагменты 112c и 112d изображения перекрытия и соответствующий префикс слайса указывали бы, например, при обращении к полному блоку декодирования, «c» и «d», т.е. эти фрагменты 112c и 112d изображения

Таким образом, сетевой объект, упомянутый дополнительно ниже, может использовать эту явную сигнализацию или соглашение, чтобы корректно связать каждый пакет идентификации фрагмента изображения с одним или более пакетами полезной нагрузки, непосредственно следующими за пакетом идентификации в последовательности пакетов. Способ, с помощью которого идентификация может быть сигнализирована, был примерно описан выше с помощью subpic_tile_info псевдо-кода. Связанные пакеты полезной нагрузки были упомянуты выше как «снабженные префиксом слайсы». Естественно, пример может быть изменен. Например, синтаксические элементы «tile_priority» могут быть оставлены в стороне. Кроме того, порядок среди синтаксических элементов может быть переключен, и дескриптор, касающийся возможных длин в битах, и принципы кодирования синтаксических элементов являются лишь иллюстративными.

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

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

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

Что касается пакетов ROI, подобные комментарии действительны, как и те, предоставленные ранее по отношению к пакетам идентификации фрагмента изображения: пакеты ROI могут идентифицировать фрагменты изображений, принадлежащих ROI изображения, лишь среди тех фрагментов изображения, которые перекрыты слайсами, содержащимися в одном или более пакетах полезной нагрузки, к которым соответствующий пакет ROI относится путем непосредственного предшествования одному или более пакетам полезной нагрузки, как описано выше по отношению к «снабженным префиксом слайсам».

Пакеты ROI могут допускать идентификацию более чем одной ROI на снабженный префиксом слайс с идентификацией связанных фрагментов изображения для каждой из этих ROI (c.p. num_rois_minus1)). Затем для каждой ROI может быть передан приоритет, разрешающий размещение ROI в терминах приоритета (c.p. roi_priority[ i ]). Чтобы разрешить «отслеживание» ROI с течением времени в ходе последовательности изображений видео, каждая ROI может быть проиндексирована индексом ROI, так что ROI, указанные в пакетах ROI, могут быть связаны друг с другом за/через границы изображения, т.е. во времени (c.p. roi_id[ i ]).

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

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

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

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

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

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

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

Хотя некоторые аспекты были описаны в контексте устройства, ясно, что эти аспекты также представляют описание соответствующего способа, где блок или устройство соответствует шагу способа или отличительному признаку шага способа. Аналогично, аспекты, описанные в контексте шага способа, также представляют описание соответствующего блока или элемента или отличительного признака соответствующего устройства. Некоторые или все из шагов способа могут быть выполнены посредством (или с использованием) аппаратного устройства, как например, микропроцессора, программируемого компьютера или электронной схемы. В некоторых вариантах осуществления некоторый один или более из наиболее важных шагов способа могут быть выполнены таким устройством.

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

В зависимости от определенных требований реализации, варианты осуществления изобретения могут быть реализованы аппаратно или программно. Реализация может быть выполнена с использованием цифровой запоминающей среды, например, дискеты, DVD, Blu-Ray, PROM (ППЗУ, программируемое постоянное запоминающее устройство), EPROM (СППЗУ, стираемое программируемое постоянное запоминающее устройство), EEPROM (ЭСППЗУ, электрически стираемое программируемое постоянное запоминающее устройство) или ФЛЭШ памяти, имеющей электронно считываемые управляющие сигналы, хранящиеся на ней, которая взаимодействует (или способна взаимодействовать) с программируемой компьютерной системой, так что соответствующий способ выполняется. Следовательно, цифровая запоминающая среда может быть машиночитаемой.

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

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

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

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

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

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

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

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

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

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

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

Библиографический список

[1] Thomas Wiegand, Gary J. Sullivan. Gisle Bjontegaard, Ajay Luthra, «Обзор Стандарта Видеокодирования H.264/AVC», IEEE Trans. Circuits Syst. Video Technol., vol. 13, N7, Июль 2003.

[2] JCT-VC, «Текстовая спецификация Высокоэффективного Видеокодирования (HEVC) Рабочий Проект 7», JCTVC-I1003, Май 2012.

[3] ISO/IEC 13818-1: Спецификация систем MPEG-2.

[4] IETF RFC 3550 - Транспортный Протокол Реального Времени.

[5] Y.-K. Wang и другие. «Формат Полезной Нагрузки RTP для Видео H.264», IETF RFC 6184, http://tools.ietf.org/html/

[6] S. Wenger и другие. «Формат Полезной Нагрузки RTP для Масштабируемого Видеокодирования», IETF RFC 6190, http://tools.ietf.org/html/rfc6190

[6] T. Schierl и другие. «Формат Полезной Нагрузки RTP для Высокоэффективного Видеокодирования», IETF интернет черновик, http://datatracker.ietf.org/doc/draft-schierl-payload-rtp-h265/

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

1. Цифровой носитель данных, хранящий поток видеоданных, имеющий видеоконтент (16), закодированный в нем, в единицах под-частей (24) изображений (18) видеоконтента (16), при этом каждая под-часть (24) соответственно закодирована в один или более пакетов (32) полезной нагрузки последовательности (34) пакетов потока (22) видеоданных, при этом последовательность (34) пакетов разделена на последовательность блоков (30) доступа, так что каждый блок (30) доступа собирает пакеты (32) полезной нагрузки, относящиеся к соответствующему изображению (18) видеоконтента (16), причем последовательность (34) пакетов содержит помещенные в нее пакеты (36) управления таймингом, так что пакеты (36) управления таймингом подразделяют блоки (30) доступа на блоки (38) декодирования, так что по меньшей мере некоторые блоки (30) доступа подразделены на два или более блоков (38) декодирования, при этом каждый пакет (38) управления таймингом сигнализирует время извлечения буфера декодера для блока (38) декодирования, пакеты (32) полезной нагрузки которого следуют за соответствующим пакетом (38) управления таймингом в последовательности (34) пакетов.

2. Цифровой носитель данных по п. 1, в котором под-части (24) представляют собой слайсы и каждый пакет (32) полезной нагрузки включает в себя один или более слайсов.

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

4. Цифровой носитель данных по п. 1, в котором каждый пакет последовательности (34) пакетов может быть назначен точно одному типу пакета из множества типов пакета, при этом пакеты (32) полезной нагрузки и пакеты (36) управления таймингом имеют различные типы пакета, причем появления пакетов из множества типов пакета в последовательности (34) пакетов являются предметом определенных ограничений, которые определяют порядок среди типов пакета, которому должны подчиняться пакеты в каждом блоке (30) доступа, так что границы блока доступа являются обнаруживаемыми с использованием ограничений посредством обнаружения экземпляров, где есть возражения ограничениям, и остаются в том же положении в последовательности пакетов, даже если пакеты любого удаляемого типа пакета удалены из потока видеоданных, причем пакеты (32) полезной нагрузки являются неудаляемым типом пакета, а пакеты (36) управления таймингом являются удаляемым типом пакета.

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

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

7. Кодер для кодирования в поток (22) видеоданных видеоконтента (16) в единицах под-частей (24) изображений (18) видеоконтента (16) с соответствующим кодированием каждой под-части (24) в один или более пакетов (32) полезной нагрузки последовательности (34) пакетов потока (22) видеоданных, так что последовательность (34) пакетов разделена на последовательность блоков (30) доступа и каждый блок (30) доступа собирает пакеты (32) полезной нагрузки, относящиеся к соответствующему изображению (18) видеоконтента (16), при этом кодер выполнен с возможностью помещать в последовательность (34) пакетов пакеты (36) управления таймингом, так что пакеты (36) управления таймингом подразделяют блоки (30) доступа на блоки (38) декодирования, так что по меньшей мере некоторые блоки (30) доступа подразделены на два или более блоков (38) декодирования, при этом каждый пакет (36) управления таймингом сигнализирует время извлечения буфера декодера для блока (38) декодирования, пакеты (32) полезной нагрузки которого следуют за соответствующим пакетом (36) управления таймингом в последовательности (34) пакетов.

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

кодировать текущую под-часть (24) текущего изображения (18) в текущий пакет (32) полезной нагрузки текущего блока (38) декодирования,

передавать в потоке данных текущий блок (38) декодирования, снабженный префиксом в виде текущего пакета (36) управления таймингом, с установкой времени извлечения буфера декодера, сигнализируемого текущим пакетом (36) управления таймингом, в первый момент времени; и

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

9. Способ кодирования в поток (22) видеоданных видеоконтента (16) в единицах под-частей (24) изображений (18) видеоконтента (16) с соответствующим кодированием каждой под-части (24) в один или более пакетов (32) полезной нагрузки последовательности (34) пакетов потока (22) видеоданных, так что последовательность (34) пакетов разделена на последовательность блоков (30) доступа и каждый блок (30) доступа собирает пакеты (32) полезной нагрузки, относящиеся к соответствующему изображению (18) видеоконтента (16), при этом способ содержит этап, на котором помещают в последовательность (34) пакетов пакеты (36) управления таймингом, так что пакеты (36) управления таймингом подразделяют блоки (30) доступа на блоки (38) декодирования, так что по меньшей мере некоторые блоки (30) доступа подразделены на два или более блоков (38) декодирования, при этом каждый пакет (36) управления таймингом сигнализирует время извлечения буфера декодера для блока (38) декодирования, пакеты (32) полезной нагрузки которого следуют за соответствующим пакетом (36) управления таймингом в последовательности (34) пакетов.

10. Декодер для декодирования потока (22) видеоданных, имеющего видеоконтент (16), закодированный в нем в единицах под-частей (24) изображений (18) видеоконтента (16), при этом каждая под-часть соответственно закодирована в один или более пакетов (32) полезной нагрузки последовательности (34) пакетов потока (22) видеоданных, последовательность (34) пакетов разделена на последовательность блоков (30) доступа, так что каждый блок (30) доступа собирает пакеты (32) полезной нагрузки, относящиеся к соответствующему изображению (18) видеоконтента (16), при этом декодер содержит буфер для буферизации потока видеоданных или восстановления видеоконтента, полученного оттуда посредством декодирования потока видеоданных, и выполненный с возможностью поиска пакетов (36) управления таймингом, помещенных в последовательность пакетов, подразделения блоков (30) доступа на блоки (38) декодирования в пакетах (36) управления таймингом, так что по меньшей мере некоторые блоки доступа подразделены на два или более блоков декодирования, и опустошения буфера в единицах блоков декодирования.

11. Декодер по п. 10, в котором декодер выполнен с возможностью при поиске пакетов (36) управления таймингом проверять в каждом пакете указывающую тип пакета часть синтаксического элемента и, если значение указывающей тип пакета части синтаксического элемента равно предопределенному значению, распознавать соответствующий пакет как пакет (36) управления таймингом.

12. Способ декодирования потока (22) видеоданных, имеющего видеоконтент (16), закодированный в нем в единицах под-частей (24) изображений (18) видеоконтента (16), при этом каждая под-часть соответственно закодирована в один или более пакетов (32) полезной нагрузки последовательности (34) пакетов потока (22) видеоданных, последовательность (34) пакетов разделена на последовательность блоков (30) доступа, так что каждый блок (30) доступа собирает пакеты (32) полезной нагрузки, относящиеся к соответствующему изображению (18) видеоконтента (16), при этом способ использует буфер для буферизации потока видеоданных или восстановления видеоконтента, полученного из него посредством декодирования потока видеоданных, и содержит этапы, на которых осуществляют поиск пакетов (36) управления таймингом, помещенных в последовательность пакетов, подразделяют блоки (30) доступа на блоки (38) декодирования в пакетах (36) управления таймингом, так что по меньшей мере некоторые блоки доступа подразделены на два или более блоков декодирования, и опустошают буфер в единицах блоков декодирования.

13. Сетевой объект для передачи потока (22) видеоданных, имеющего видеоконтент (16), закодированный в нем в единицах под-частей (24) изображений (18) видеоконтента (16), при этом каждая под-часть соответственно закодирована в один или более пакетов (32) полезной нагрузки последовательности (34) пакетов в потоке (22) видеоданных, при этом последовательность (34) пакетов разделена на последовательность блоков (30) доступа, так что каждый блок (30) доступа собирает пакеты (32) полезной нагрузки, относящиеся к соответствующему изображению (18) видеоконтента (16), при этом декодер выполнен с возможностью поиска пакетов (36) управления таймингом, помещенных в последовательность пакетов, подразделения блоков доступа на блоки декодирования в пакетах (36) управления таймингом, так что по меньшей мере некоторые блоки (30) доступа подразделены на два или более блоков (38) декодирования, получения из каждого пакета (36) управления таймингом времени извлечения буфера декодера для блока (38) декодирования, пакеты (32) полезной нагрузки которого следуют за соответствующим пакетом (36) управления таймингом в последовательности (34) пакетов, и выполнения передачи потока видеоданных, зависимого от времен извлечения буфера декодера для блоков (38) декодирования.

14. Способ передачи потока (22) видеоданных, имеющего видеоконтент (16), закодированный в нем в единицах под-частей (24) изображений (18) видеоконтента (16), при этом каждая под-часть соответственно закодирована в один или более пакетов (32) полезной нагрузки последовательности (34) пакетов в потоке (22) видеоданных, при этом последовательность (34) пакетов разделена на последовательность блоков (30) доступа, так что каждый блок (30) доступа собирает пакеты (32) полезной нагрузки, относящиеся к соответствующему изображению (18) видеоконтента (16), при этом способ содержит этапы, на которых осуществляют поиск пакетов (36) управления таймингом, помещенных в последовательность пакетов, подразделяют блоки доступа на блоки декодирования в пакетах (36) управления таймингом, так что по меньшей мере некоторые блоки (30) доступа подразделены на два или более блоков (38) декодирования, получают из каждого пакета (36) управления таймингом время извлечения буфера декодера для блока (38) декодирования, пакеты (32) полезной нагрузки которого следуют за соответствующим пакетом (36) управления таймингом в последовательности (34) пакетов, и выполняют передачу потока видеоданных, зависимого от времен извлечения буфера декодера для блоков (38) декодирования.

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

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

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