Одной из обязанностей WebRTC SFU является получение и отправка пакетов RTCP. Пакеты RTCP включают в себя различные типы отзывов об аудио- и видеопотоках, и наиболее важным пакетом RTCP является отчет приемника (RR).
Пакеты RR отправляются от получателя медиапотока отправителю этого медиапотока. В случае SFU RR генерируется SFU и отправляется отправителю медиапотока, а также от каждого получателя потока в SFU. (Рисунок 1).
Обратная связь, отправляемая в пакете RR, включает в себя задержку времени приема-передачи, дрожание и потерю информации, вносимые сетью.
Потеря пакетов, сообщаемая в этих пакетах RR, важна, поскольку отправляемые аудио и видео будут корректироваться в соответствии с этим параметром:
В случае потоковой передачи аудио потеря данных в сети изменяет уровень надежности кодека OPUS. В случаях большой потери данных передатчик увеличивает уровень избыточности прямого исправления ошибок (FEC), включенного в аудиопакеты. В случае потокового видео потеря данных изменяет скорость передачи видео для кодирования и передачи. В случае существенной потери данных отправитель снижает скорость передачи, чтобы снизить возможную перегрузку сети. Основываясь на этом поведении, возникает вопрос... как SFU вычисляет потерю пакетов, о которой сообщается в пакетах RR, отправляемых от SFU отправителю, для наилучшего взаимодействия с пользователем?
В следующих разделах вы можете найти советы о том, как справиться с этим в трех различных типах потоков: аудио, видео с одновременной передачей и видео без одновременной передачи.
аудио
Opus FEC отправляется внутриполосно, так как FEC от начала до конца (в SFU нельзя добавить/обновить), и каждая комната получит одинаковый уровень FEC.
Если мы хотим, чтобы аудио FEC работало хорошо для участника с самым слабым звеном, мы должны убедиться, что сообщаем отправителю о наихудшей потере пакетов.
Следовательно, потеря пакета, о которой SFU сообщает отправителю, должна быть плохим пакетом получателя (max(PL1, PL2)).
Например, если один из принимающих участников испытывает 20-процентную потерю данных в нисходящем канале, потеря данных, сообщаемая отправителю, составит 20 %, даже если отправитель и остальные получатели находятся в отличном состоянии сети.
видео с перепихон
При использовании одновременной передачи SFU может отправлять видео разного качества каждому участнику, поэтому нет необходимости адаптировать поток отправки для каждого конкретного участника.
Следовательно, потеря, сообщаемая SFU отправителю, должна быть потерей для этой связи (отправитель - SFU), какой бы ни была полученная потеря для получателей 1 и 2.
Например, если восходящая линия отправителя хорошая, даже если получатель столкнулся в нисходящей линии связи, потеря пакетов, отчет о потере пакетов на передающую сторону также будет перенаправлен на 0. Выбрав более низкое разрешение этих участников/уровня, можно исправить повторным -передача завершена и SFU в том, что адаптация битрейта.
нет секс видео
Без одновременного вещания SFU должен отправлять видео одинакового качества каждому участнику. Поэтому отправитель использует самое слабое звено, чтобы настроить битрейт отправки и отправить его участникам (и/или отключить видео для некоторых участников).
Эта адаптация битрейта в основном контролируется данными REMB RTCP, где SFU включает пропускную способность, доступную в плохих приемниках. Но потеря пакетов также влияет на скорость передачи данных в пакетах REMB, поэтому нам необходимо определить, какие потери пакетов следует включать в пакеты RR.
В этом случае, я думаю, оба метода, описанные в предыдущих разделах, будут работать хорошо. Либо a) SFU сообщает о наихудшей скорости потери пакетов получателя, либо b) использует потери пакетов каждого получателя для оценки его пропускной способности и сообщает только о потерях пакетов на стороне отправителя в пакетах RR.
ПРИМЕЧАНИЕ. Если вы используете соединение P2P, когда у вас есть 2 участника в комнате, и переключаетесь на SFU с одновременной передачей, когда в комнате 3 или более участников, вам никогда не следует использовать No-Simulcast в этом видео и случаях с несколькими участниками. .
Эта статья была впервые опубликована при поддержке AgoraКитайская сеть WebRTC