Можно ли отключить буфер джиттера в WebRTC (Chrome/Chromium)

Question

Я пытаюсь максимально сократить задержку видеоролика Chromium WebRTC для удаленного приложения управления машиной. Поскольку передающий и принимающий ПК напрямую подключены через Ethernet (кроссоверный кабель), я предполагаю, что буферизация приема может не понадобиться, поскольку не должно быть никаких отложенных, нестандартных или потерянных пакетов.

Я восстановил Chromium после настройки значения kMaxVideoDelayMs в jitter_buffer_common.h. Это дало неоднозначные результаты, в том числе создание неустойчивого поведения с получением видео (прерывистое), а также постепенное повышение уровня googPlisSent. Кроме того, googJitterBufferMs и googTargetDelayMs перемещаются беспорядочно, когда kMaxVideoDelayMs устанавливается ниже определенного порога (около 60 мс). Кажется, что все работает хорошо с kMaxVideoDelayMs, установленным на 100 мс, но я хотел бы попытаться максимально уменьшить общую задержку.

Я хотел бы знать, можно ли вообще отключить или обойти приемник-джиттер, поскольку это может уменьшить общую задержку между захватом видео на передающем ПК и отображением его на принимающем ПК.

Answer 1

Вам по-прежнему нужен буфер дрожания для хранения пакетов до тех пор, пока у вас не будет всего кадра (и выполните другую связанную обработку, зависающую от буфера дрожания). Звуковые буферы шумоподавления обычно эффективно управляют вещами и управляют при отображении аудио/видео. Все это глубоко в NetEq и, вероятно, не может быть отключено.

Если вы запускаете аудио и видео как отдельные потоки (не синхронизированы или нет звука), тогда видео должно выполняться как можно быстрее, но если есть задержка, это связано с планированием ОС, и может также быть некоторой задержкой стимуляции в коде DeliverFrame (или, скорее, кодом, который заканчивается вызовом DeliverFrame).