9

Я использовал это между 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 ответ1

1

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

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

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

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

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

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .