Как декодер определяет размер Single NAL Unit в декодировании H264

Как указано в RFC 6184 https://tools.ietf.org/html/rfc6184#section-5.6, раздел 5.6, что единичный пакет NAL может содержать только один блок NAL.Как декодер определяет размер Single NAL Unit в декодировании H264

Мой вопрос в том, как декодер теперь на принимающей стороне идентифицирует размер этого Единичного блока NAL или знает конец блока NAL в единичном пакете Single NAL.

Однако в другом режиме пакетирования, таком как STAP и другие, размер блока NAL присутствует как часть полезной нагрузки RTP.

источник

2015-12-07 darth_coder

Если есть один NAL/пакет, тогда его размер является размером полезной нагрузки. Что именно вы спрашиваете? – aergistal

@aergistal Я надеюсь, что мы оба находимся на одной странице, связанной с единичным пакетным форматом Single NAL, который упоминается в RFC 6184. Теперь, касаясь моего вопроса, меня смущает единица Single NAL, инкапсулированная в пакет RTP раз заголовок RTP удаляется декодером, а полезная нагрузка RTP имеет единый блок NAL, теперь здесь первые 8 бит являются заголовком блока NAL, а остальное является данными блока NAL, то есть информацией, связанной с фреймом. Как мы узнаем, что информация, связанная с фреймом, заканчивается, и до какой точки я должен предположить, что есть данные NAL, также может быть заполнение RTP. –

Наличие и длина прогона RTP указаны в [заголовке RTP] (http://www.siptutorial.net/RTP/images/header.gif). Когда бит P установлен, последний октет RTP padding - это количество байтов, которое следует игнорировать в конце. – aergistal

Мой вопрос в том, как декодер теперь на принимающей стороне идентифицирует размер этого Единичного блока NAL или знает конец блока NAL в единичном пакете Single NAL.

API-интерфейс OS/socket сообщает вам, какой размер принимаемого пакета UDP (RTP). В случае потоковой передачи TCP размер пакета RTP обычно добавляется к пакету RTP (как в RTSP, так и в RFC4571). После обработки RTP header полезная нагрузка равна единицам NAL в single nal unit mode.

Хотя типичный заголовок RTP составляет 12 байтов, вы должны проанализировать его в соответствии с RFC3550, поскольку размер зависит от расширений заголовков CSRC и RTP.

В случае STAP вам необходимо знать размер, поскольку в одном пакете RTP имеется несколько NALU. Следовательно, вы должны разбирать каждый, читая размер.

источник

2015-12-07 16:00:57 Ralf

Согласовано, что в случае STAP, MTAP и FU - A/B всегда существуют способы определения размера блока NAL с использованием длины или бит начала/конца. Вероятно, я буду читать больше о RTP в случае TCP и UDP. Но перед этим еще несколько сомнений: 1) размер RTP-пакета по размеру полезной нагрузки UDP, но после удаления из него заголовка RTP, что остается единственным блоком NAL. Теперь этот единственный блок NAL имеет 8-битный заголовок, а остальные - данные NAL, которые могут даже содержать отступы RTP, теперь вот как декодер определяет длину, до которой он должен учитывать данные NAL. –

Также я хотел бы добавить, что мы говорим, что в случае TCP в качестве транспортного механизма размер RTP-пакета обычно добавляется к пакету RTP, но откуда я знаю, что пакет RTP не заполнен байтом. Значит, есть данные NAL вместе с заполнением байтов в полезной нагрузке RTP в этом случае, как узнать конец блока NAL. –

Как правило, блок NAL, который вы получаете от кодировщика, - это то, что вы ставили как полезную нагрузку в режиме SNU, аналогично полезная нагрузка RTP - это то, что вы подаете обратно в декодер. Если вам нужно заполнить панель, см. Раздел по заполнению: https://tools.ietf.org/html/rfc3550#section-5.1 – Ralf

Как декодер определяет размер Single NAL Unit в декодировании H264

ответ

Смежные вопросы