Трудный вопрос.
Я раньше думал, что в рамках одного кодека Н.264 всё решает профиль и пакетизация. Как казалось - зачем выдумывать? Пусть chan_sip напрямую кидает все эти непонятные параметры кодека от одного абонента другому, авось тот поймёт! Транскодинга то не должно быть? На деле было замечено следующее: Астериск отсекал в SDP всё, что ему было непонятно, и передавал таким образом неполный пакет SDP по части видеопараметров. А там фигурировали кроме вышеуказанных ещё и параметры полосы, b=TIAS:128000
и даже размеры картинки через передачу параметров в XML.
И каждый вендор их там насыпал не жалея картошки, по самые помидоры! Один только режим пакетизации в RFC 3984 RTP Payload Format for H.264 Video описывает три режима:
o Single NAL unit mode
o Non-interleaved mode
o Interleaved mode
или, формат кодирования слайсов в Network Abstract Layer
Код: Выделить всё
NAL Unit Type Content of NAL unit NRI (binary)
----------------------------------------------------------------
1 non-IDR coded slice 10
2 Coded slice data partition A 10
3 Coded slice data partition B 01
4 Coded slice data partition C 01
В общем, канал chan_sip был дописан соответственно, на прямую, транзитную передачу неизвестных ему параметров. Но это ничего не дало! Потому что в самом общем виде задача формулировалась так "Совместимость всего и вся", то есть все производители должны были добиваться видеосовместимости своих устройств и прошивок со всеми другим устройствами в мире (в рамках выбранного кодека Н.264). Что попросту невыполнимо. Вот процитирую:
The capabilities expressed in video codec parameters ‐ e.g., profile ‐ level / max ‐ br/max ‐ mbps etc. – should be considered as receive capability and not negotiated capability. As an illustration, if a UA receives offer with H.264 SDP a=fmtp:96 profile‐level‐id=42801d,
it would be legal for it to respond with a higher capability a=fmtp:96 profile‐level‐id=42801f in the answer. The bandwidth specified in an SDP answer can be different from the bandwidth appearing in the associated SDP offer. In such a case, the call may end up as the above UA receiving higher resolution (say HD) but transmitting only CIF
Исходя из таких сложностей по capabilities можно понять, что всё, что не вписывается в их рамки, всё что не декодирует NAK в соответствии с RFC будет на выходе выглядеть как чёрный квадрат Малевича.