изменение эталонного программного обеспечения HM для отображения некоторой информации о битовом потоке - PullRequest
Новая
       87

изменение эталонного программного обеспечения HM для отображения некоторой информации о битовом потоке

0 голосов
/ 11 июня 2018

Я очень плохо знаком с эталонным программным обеспечением HM HEVC (и JEM), и в настоящее время я пытаюсь понять исходный код.Я хочу добавить несколько строк для отображения для каждого компонента: имя алгоритма (т. Е. Inter / intra Algos) + длина потока битов + позиция в выходном bin-файле.Знать, какой компонент стоит больше битов для кода и как работает кодек.Я хочу сделать то же самое для JEM и после этого.Во-первых, моя проблема в том, что я не могу понять многие функции, комментариев недостаточно, поэтому есть ли ссылки для понимания кода ?? !!(Я уже читал Мануэль, не помогает).2-й, я не знаю, где и как именно добавить эти строки;это в TEncGOP, TEncSlice или TEncCU.PS: Я не думаю, что в TEncGOP.compressGOP, так что, может быть, в 2 других классах.

Ответы [ 2 ]

0 голосов
/ 12 июня 2018

(я поставил ответ, чтобы прокомментировать, что @Mourad поместил здесь четыре часа назад, потому что это будет долго)

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

Теперь вам нужно найти точную функцию в xEncodeCU, которая отвечает за вашу цельинструмент кодека.

Например, если вы хотите посчитать количество битов для кодирования коэффициентов, вы должны посмотреть на m_pcEntropyCoder->encodeCoeff() (это функция JEM и может иметь другое имя в HM).Когда вы найдете эту строку в xEncodeCU, вы можете сделать это и получить количество битов, записанных внутри функции encodeCoeff(): 

UInt b_before = m_pcEntropyCoder->getNumberOfWrittenBits();
m_pcEntropyCoder->encodeCoeff( ... );
UInt b_after = m_pcEntropyCoder->getNumberOfWrittenBits();
UInt writtenBitsCoeff = b_after - b_before;

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

0 голосов
/ 11 июня 2018

Пункт 1: Существует одно правило, согласно которому протоколирование решений по кодированию (например, режим pred, MV, IPM, размер блока) намного проще на стороне декодера, чем на кодере.Это из-за того, что у вас очень сложный процесс RDO на стороне кодера, который может легко запутаться в циклах.Но на стороне декодера все появляется только один раз.Однако, если вы настаиваете на том, чтобы делать это на стороне кодера, вы можете найти несколько советов здесь: Получить некоторую информацию из эталонного программного обеспечения HEVC

Пункт 2: В отличие от решений по кодированию, скорость регистрации (т.е.количество записанных битов для различных элементов синтаксиса) сложнее на стороне декодера, чем на кодере.Это особенно верно для дробных битов, связанных с чем-либо, что закодировано в не-EP режиме (то есть с контекстами CABAC).Так что вы можете выполнить эту часть на стороне экодера.Но я боюсь, что это нелегко.

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

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

...