Ответ 1
getUserMedia
ограничения влияют только на носители, запрашиваемые у браузера, на оборудование и возвращаются в виде потока. getUserMedia
ограничения не влияют на то, что делается с этим потоком после этого (то есть, когда он передается по каналу связи). Деградация, которую вы видите, находится на уровне PeerConnection
, а не на слое getUserMedia
. Деградация инициируется реализацией webrtc, когда статистика аппаратного обеспечения и полосы пропускания указывает на низкую производительность и согласовывается обеими сторонами.
[Hardware] <- getUserMedia -> [javascript client] <- PeerConnection -> [another client]
<- 640x480 captured -> <- 320x240 sent ->
Вам нужно будет найти исходный код для документации и доказательства того, как это делается в каждой реализации, но ссылки на поведение:
Хорошей новостью является то, что звуковые и видеомониторы WebRTC работают вместе с базовым сетевым транспортом, чтобы исследовать доступную пропускную способность и оптимизировать доставку медиапотоков. Однако передача данных DataChannel требует дополнительной логики приложения: приложение должно отслеживать количество буферизованных данных и быть готовым к настройке по мере необходимости.
...
Аудио- и видеомониторы WebRTC будут динамически настраивать битрейт медиа-потоков в соответствии с условиями сетевой связи между одноранговыми узлами. Приложение может устанавливать и обновлять ограничения на носители (например, разрешение видео, частоту кадров и т.д.), А двигатели делают все остальное - эта часть проста.