LINUX.ORG.RU

Как выбирается кодек в SDP

 , , ,


1

1

Как устанавливается связь между 2 клиентами. Они обмениваются SDP, в котором описаны все поддерживаемые ими аудио\видео кодеки, а также уточненными параметрами этих кодеков. Вопрос в том, как именно выбирается кодек, если их перечислено несколько.

Вот допустим такая схема: pc1(только передает sendonly), p2(только принимает). pc1 генерирует SDP(createOffer) и передает его pc2. Как pc2 понимает каким именно кодеком будет кодировать поток pc1?

Пример реального SDP, который генерирует Chrome

c=IN IP4 0.0.0.0
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
a=sendonly
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
...
m=video 9 UDP/TLS/RTP/SAVPF 108 96 98 100 102 104 106 110 112 97 99 101 103 105 107 109 111
...
a=rtpmap:108 H264/90000
a=rtpmap:96 VP8/90000
a=rtpmap:98 VP9/90000
a=rtpmap:100 VP9/90000
a=fmtp:100 profile-id=2
a=rtpmap:102 H264/90000


a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=fmtp:104 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
...
a=ssrc-group:FID 3916163788 593508736
a=ssrc:3916163788 cname:p2nRRSLsnzsCF8Xo
a=ssrc:3916163788 msid:9kHOR4nvbuRqbb0GWVQiybJbgMiOilZHabEW 69e2e9ce-ccc2-414c-8336-71e54f24fd62
a=ssrc:3916163788 mslabel:9kHOR4nvbuRqbb0GWVQiybJbgMiOilZHabEW
a=ssrc:3916163788 label:69e2e9ce-ccc2-414c-8336-71e54f24fd62
a=ssrc:593508736 cname:p2nRRSLsnzsCF8Xo
a=ssrc:593508736 msid:9kHOR4nvbuRqbb0GWVQiybJbgMiOilZHabEW 69e2e9ce-ccc2-414c-8336-71e54f24fd62
a=ssrc:593508736 mslabel:9kHOR4nvbuRqbb0GWVQiybJbgMiOilZHabEW
a=ssrc:593508736 label:69e2e9ce-ccc2-414c-8336-71e54f24fd62


Как видно из SDP, поддерживаемые аудио\видео кодеки перечислены в
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
m=video 9 UDP/TLS/RTP/SAVPF 108 96 98 100 102 104 106 110 112 97 99 101 103 105 107 109 111


В частности audio в порядке приоритета
opus/48000/2
ISAC/16000
ISAC/32000
...


Видео
H264/90000(level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f)
VP8/90000
VP9/90000
VP9/90000(profile-id=2)
H264/90000(level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f)
...


Как приемник (pc2) поймет какой именно кодек выбрал кодировщик(pc1)? В этом частном случае были выбраны первые кодеки (opus и H264). Но ведь перечислены и другие. Если кодек выбирается тупо первым из перечисления, то зачем тогда описывать другие? Не понятно

Почитал https://tools.ietf.org/html/rfc3264
   In all cases, the formats in the "m=" line MUST be listed in order of
   preference, with the first format listed being preferred.  In this
   case, preferred means that the recipient of the offer SHOULD use the
   format with the highest preference that is acceptable to it.

Предпочтительный формат означает, что получатель предложения ДОЛЖЕН использовать формат с наибольшим предпочтением, которое является приемлемым для него.

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

★★★★

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

m=audio 12345 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000

Если ответчик согласовал оба, то отправитель передавая аудио-поток посредством PCMU (PT=0), может временно переключиться на telephone-event (PT=96), когда сторона отправителя жмёт на кнопки телефона (тоны DTMF).

Можно усложнить пример:
m=audio 12345 RTP/AVP 0 96 97
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=rtpmap:97 CN/8000

Тут при определении отправителем тишины у своего источника, отправитель может переключиться на шум (Comfort Noise, PT=97) на это время.

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 3)
Ответ на: комментарий от gobot

Пакет RTP, несущий полезную нагрузку, имеет поле PT (Payload Type, младшие 7 бит второго байта пакета). Собственно по нему и определяется тип принятого закодированного буфера, и какому декодеру его отдать.

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 1)