Можно ли отключить Jitter Buffer в WebRTC (Chrome/Chromium)

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

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

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


google-chrome chromium webrtc buffer jitter
person Chris M    schedule 30.10.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

person jesup    schedule 06.11.2015