Итак, у меня есть два сверстника, Алиса и Боб. Алиса хочет получить видео от Боба, но не отправлять ее самостоятельно. Боб не поддерживает VP8 / 9, только h.264. В настоящее время соединение webrt c установлено без ошибок, но Алиса видит пурпурный беспорядок для видео. Видео корректно отображается после изменения строки предложения m.
Подробнее ... Алиса создает предложение со следующей строкой m и отправляет ее Бобу. Для потоковых идентификаторов 96 - 101 используются кодеки vp8 или vp9. идентификаторы> 101 используют h.264.
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116
Поскольку Боб не поддерживает vp8 или vp9, его ответ содержит следующую строку m:
m=video 9 UDP/TLS/RTP/SAVPF 102 122 127 121 125 107 108 109 114 115 116
Алиса получает ответ от Боба, вызывает setRemoteDescription, затем получает обратный вызов ontrack, а затем обратный вызов setRemoteDescriptionFinished.
Я бы ожидал, что браузер Алисы (Chrome 79.0.3945.130, Ma c) выберет 102 и использует декодер h.264. Фиолетовое искаженное видео выглядит подозрительно, как видеоданные, декодируемые неправильным декодером.
Поэтому в качестве эксперимента я удалил записи в диапазоне 96 - 101 из предложения Алисы перед setLocalDescription и перед отправкой Бобу. С этим изменением видео отображается правильно.
Есть ли у кого-то более осведомленного о webrt c идея, что может заставить Chrome выбрать поток, отсутствующий в ответе равноправного участника?
I Я нахожусь в процессе тестирования этого в других браузерах и упрощаю код для дальнейшего тестирования.
Также стоит отметить, что нужно изменить только предложение, переданное setLocalDescription. Если немодифицированное предложение затем отправляется Бобу, видео по-прежнему отображается правильно.
В соответствии с webrt c -internals, Алиса Chrome действительно выбирает 96 (VP8) в качестве формата входящего-rtp поток, хотя это H264.