Я хотел бы знать, что означают эти строки SDP, поскольку я пытаюсь получить максимально плавную частоту кадров с потерями пакетов от 5% до 10%.
Линии, которые я не знаю:
a = rtcp-fb: 100 Гуг-Рем
a = rtcp-fb: 100 транспорт-куб
Я не знаю, почему Firefox (например) убирает возможность «transport-cc», это то, что я хочу сделать плавной частотой кадров, даже если мне нужно декодировать неполные видеокадры?
С наилучшими пожеланиями, я надеюсь, что кто-то может помочь мне в этом 🙂
Густаво Гарсия написал пост в блоге об этом под названием Оценка пропускной способности в WebRTC (и новом BWE на стороне отправителя).
Подвести итоги: GOOG-remb а также транспортно-куб.см оба механизма контроля заторов, GOOG-remb будучи старым методом и транспортно-куб.см будучи более новым методом.
Мое лучшее предположение, что Firefox удаляет транспортно-куб.см потому что Firefox не принял транспортно-куб.см изменений пока нет. По моему опыту, Chrome всегда опережает Firefox в изменениях webrtc.
В сети с потерями эти алгоритмы управления перегрузкой могут указывать отправителю снизить скорость передачи. Снижение скорости передачи может снизить потери (за счет качества). Однако, если сеть всегда с потерями 10%, как шумная сеть Wi-Fi, вы все равно можете столкнуться с проблемами декодирования видеокадров.
Обработка сбоев декодирования видео зависит от параметров кодирования видео vp8 / h264, а не от контроля перегрузки. Как я уже сказал, контроль перегрузки может помочь уменьшить потери (в случае, если вы перегружаете свою сеть пакетами WebRTC), но если у вас просто сеть с потерями (например, плохой Wi-Fi), алгоритмы управления перегрузкой просто снизят качество без улучшения ошибок декодирования. ,
google-remb и transport-cc могут справиться только с перегрузкой, если вы пытаетесь получить максимально плавную частоту кадров при потере пакетов от 5% до 10%, вы должны различать следующую ситуацию:
используя пространственную масштабируемость simulcast или svc, выберите низкое разрешение
используя NACK и FEC, увеличить избыточность