Несколько видеопотоков H.264 на одной сессии RTP
Совпадение [, захватывает что угодно, кроме ] с использованием отрицательного набора символов ([^\]]+), затем сопоставляет ]. Затем вы можете извлечь каждую захваченную группу, которая будет содержать подстроку, сопоставленную между [] с:
const a = 'info.name[0][1][5].data[0]';
const collect = [];
const re = /\[([^\]]+)\]/g;
let match;
while (match = re.exec(a)) {
collect.push(match[1]);
}
collect.reverse();
console.log(collect);4 ответа
Параметры в Ваших двух sdp примерах очень близки - потоковое название и sprop-parameter-sets отличаются. Я предполагаю, что Вы не заботитесь о потоковом названии. Если Вы должны разделить sprop-parameter-sets, и клиенты поддерживают стандарт хорошо, можно использовать отдельные динамические типы полезной нагрузки для каждого разрешения и иметь единственный SDP следующим образом:
v=0
o=VideoServer 305419896 9876543210 IN IP4 192.168.0.2
s=VideoStream640x480
t=0 0
c=IN IP4 192.168.0.2
m=video 8000/2 RTP/AVP 96 97
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=0; profile-level-id=4D4033; sprop-parameter-sets=Z01AM5ZkBQHtCAAAAwAIAAADAYR4wZU=,aO48gJ==
a=rtpmap:97 H264/90000
a=fmtp:97 packetization-mode=0; profile-level-id=4D4033; sprop-parameter-sets=J01AM5WwPA9sBAIA,KO4G8gA=
a=control:trackID=1
Подобный другим ответам, если Вам на самом деле не нужны различные потоковые названия или другой sprop-parameter-sets, необходимо смочь использовать первый SDP и формат переключателя середина потока. Я не знаю, что фактическая полезная нагрузка H.264 или Вашего конкретного декодера достаточно хорошо гарантирует, что это будет работать в Ваших приложениях, но очень распространено в приложениях проведения видеоконференций позволить динамично переключаться между разрешениями, не сигнализируя об изменении или требуя отдельного динамического типа полезной нагрузки.
Хотя можно связать два документа SDP, как упомянуто в другом ответе, я не думаю, что он поможет в этом случае. Декодеры H.264 могут только работать с единственным sprop-parameter-sets параметром за один раз, я верю. Начиная с обоих SDPs имел бы тот же тип полезной нагрузки, исходный порт, и т.д. получатель не будет знать, когда использовать который sprop-parameter-sets параметр. ОБНОВЛЕНИЕ: Обратите внимание, что некоторые реализации получают свое sprops внутриполосное а не от SDP (или только первоначально от SDP). Если это применяется в Вашей среде, SDP sprop-parameter-sets может быть обновлен внутриполосный
Ссылки:
- RFC 3984 формат полезной нагрузки RTP для видео H.264
- Новый предложил Формат RFC 6184 Полезной нагрузки RTP H.264
- RFC 4566 SDP: протокол описания сеанса
[Извините за не предоставление полного цитируют - не стесняются исправлять]
Я пробежался через RFC (RFC2327 - SDP: Протокол описания сеанса) и кажется, что можно просто связать два документа SDP. Документ указывает явно:
Когда SDP передается скрытно, только одно описание сессии позволяется на пакет. Когда SDP передается другими средствами, много описаний сессии SDP могут быть связаны вместе ('v =' строка, указывающая, что запуск описания сессии завершает предыдущее описание).
Я думаю, что это зависит от Вашего декодера. Если это поддерживает изменение параметров в потоке, то, если можно сказать кодеру помещать соответствующий заголовок при изменении разрешения, декодер должен автоматически переключиться.
Каков Ваш вопрос точно? Это: Как я могу изменить разрешение, не останавливаясь / перезапуск потока?
Я не Думаю, что можно сказать заранее декодеру, вот потенциальное разрешение, которое Вы будете видеть с некоторым sdp волшебством. Или Ваш декодер может понять изменение параметра H264, и затем Вы в порядке, или необходимо остановиться, перезапускают все это, и затем динамический sdp достаточен.
Я знаю, что, например, VLC может обнаружить изменение кодирования MP4 (например, перемещающийся от переменной скорости передачи до постоянной скорости передачи), но откажет при изменении разрешения единственная вещь, можно сделать с sdp, должен объединить другое описание носителя, например, с другим динамическим типом полезной нагрузки и другим атрибутом идентификатора управления.
Вы можете выполнить динамическое изменение полезной нагрузки, изменение набора параметров в потоке или SIP re-INVITE.
При изменении полезной нагрузки возникает проблема, если вы не управляете кодировщиком и декодер, вам необходимо убедиться, что другой конец принимает обе полезные нагрузки, и что они будут переключать полезные нагрузки правильно (и достаточно быстро для вас - в этом нет требований).
изменения в потоке вызывают проблемы, если параметр - установленные пакеты теряются. Вы можете использовать другой набор наборов параметров (переключитесь с набора параметров 1 на 2 при изменении), чтобы избежать неправильного декодирования - если наборы потеряны, вы должны просто получить неподвижное или пустое изображение. Я бы посоветовал повторно передать их несколько раз (не в слишком быстрой последовательности).
SIP re-INVITE внеполосный и подтвержденный, и поэтому безопасный,