Получите webrtc-подобные задержки с ffmpeg?

11

Я использовал это между Chrome и моим телефоном:

http://www.webrtc.org/demo

И задержка действительно хорошая - менее 1 секунды.

Я пытался повторить это на моем компьютере, но безуспешно.

ffmpeg -f video4linux2 -i /dev/video0  -s 320x200 -r 50 -deadline realtime -vcodec libvpx -f webm -fflags nobuffer udp://10.0.0.55:9002

А затем с помощью ffplay на другой стороне.

У него все еще есть пара секунд задержки.

В конце концов, я бы хотел транслировать с моего компьютера на телефон Android, но задержка должна быть хорошей.

Редактировать - это работает значительно лучше. Если бы я мог немного побриться от этого, я был бы счастлив:

ffmpeg -vcodec rawvideo -f video4linux2 -i /dev/video0  -s 320x200 -r 25 -vcodec libvpx -f rtp -deadline realtime rtp://10.0.0.55:9002
Дэвид Н. Уэлтон
источник
1
Ссылка мертва. В основном вы хотите конвертировать видео и транслировать его на свой телефон? На вайфай или внешний?
Jiggunjer
То, что я хочу сделать, это поток с камеры, подключенной к устройству, и показать его на планшете Android (Nexus 10), который подключен через USB.
Дэвид Н. Уэлтон
1
Я не очень разбираюсь в этих кодеках, но проверяли ли вы их аппаратное ускорение, где это возможно? Это было бы мое предположение о том, почему вы видите задержку более 1 секунды.
snoopen
vpx будет сложно закрыть в реальном времени, я знаю, что у x264 есть мелодия с «низкой задержкой» или что-то в этом роде FWIW
rogerdpack

Ответы:

1

Проблема в основном из-за того, что вы используете программное транскодирование вместо аппаратного транскодирования .

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

FFmpeg поддерживает аппаратное ускорение, но обычно сложно заставить его работать на вас.

https://trac.ffmpeg.org/wiki/HWAccelIntro

С другой стороны, Google Chrome поддерживает аппаратное кодирование / декодирование VP8 и H264 (где оно доступно) как на вашем компьютере, так и на вашем телефоне Android:

http://code.google.com/p/chromium/issues/detail?id=428223

HO1
источник
1
Хотя дело не только в аппаратном ускорении ... Конфигурация кодека играет гораздо большую роль в задержке. Кодек должен быть настроен так, чтобы задержка была низкой, за счет качества и пропускной способности. Это можно сделать независимо от того, используете ли вы кодеки с аппаратным ускорением или нет.
Брэд
В этой ссылке говорится, что Chrome НЕ поддерживает аппаратное кодирование на рабочем столе, ТОЛЬКО на Android.
Давр
Извините, но Брэд прав, ответ совершенно неправильный: если вы устанавливаете одинаковые настройки кодека, нет никакой разницы, если вы выполняете аппаратное или программное кодирование (если у вас достаточно мощности ЦП для кодирования в реальном времени с помощью настройки кодека). Правильно то, что речь идет не только о настройках видеокодека, но в основном о типе транспорта и поведении буферизации декодера. WebRTC работает, потому что он настроен на низкую задержку. Типичный Webm-декодер не предназначен для работы с низкой
Гарри