☰

Потоковая передача с низкой задержкой с использованием ffmpeg

tag-icon • tag-icon performance streaming ffmpeg
Потоковая передача с низкой задержкой с использованием ffmpeg

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

Это маленькийпочти работаетДоказательство концепции. Когда закончу, смогу заменить VNC, используяffmpegпотоковое вещание сх2хилисинергиядля пересылки событий клавиатуры и мыши.

Теперь я могу начать трансляцию, используя:

ffmpeg -f x11grab -s "1600x1200" -i ":0" \
    -f alsa -i pulse \
    -s 800x600 -b 200k -f mpegts - \
    | mplayer -cache 1024 -
#
# I have pulse audio configured so that `-i pulse` will
# The output can sent through for example netcat to another host
#

Задержка зависит от параметров кодирования. С этими параметрами задержка между обновлением экрана и обновлением видео составляет около 800 мс.

Чего я пытаюсь добиться:

  • Достичь задержки100мс.

  • Когда mplayerон выполняется, он жалуется, что не может искать в потоках света и нетнет звука. У меня все еще есть звук, когда я сохраняю вывод в файл и воспроизводю его.

    EDIT: После добавления -cacheсообщения для поиска в линейных потоках больше не появляются. Изменение выходного формата на -f mpegtsзаставляет звук работать.

  • Было бы здорово, если бы кодирование не занимало 100% одного из ядер процессора (второстепенная цель).

После некоторых поисков в интернете я думаю, что эти проблемы связаны с кодеками/опциями, которые мне следует использовать. Но я не знаю различий между существующими возможностями. Не могли бы вы дать мне несколько вариантов, которые решат мои проблемы? Также, является ли VLC хорошей альтернативой, и если да, то какие будут эквивалентные команды для потоковой передачи с одного рабочего стола на другой?

решение1

Потоковая передача с desktopA на desktopB — интересная проблема. Если вам не нужно видео/аудио, то вы можете вместо этого проверить протокол NX. Он гораздо эффективнее VNC. FreeNX — это сервер, а NoMachine и другие делают NX-клиенты. Есть и другие серверы — бесплатные и коммерческие.

Также ведется работа над высокопроизводительным удаленным рабочим столом, SPICE, возможностью в качестве проекта F/LOSS. Я думаю, Redhat берет на себя инициативу.http://spice-space.org/

Не знаю, полезны ли эти ответы, но, возможно, они просто наводят на что-то более полезное?

Для потоковой передачи видео, вероятно, необходимо избегать накладных расходов, характерных для полноценного настольного протокола.

решение2

Недавно мне нужно было настроить потоковую передачу с низкой задержкой и даже более строгими требованиями, чем у оригинального автора (OP). Я разработал решение, которое работает достаточно хорошо, чтобы использовать его в качестве дополнительного монитора для моего ноутбука, с плавным вводом с мыши и клавиатуры.

На отправляющей стороне я использовал следующую ffmpegкоманду:

ffmpeg -video_size 1920x1080 -r 30 -framerate 30 -f x11grab -i :0.0+0x0 \
    -b:v 40M -maxrate 50M -bufsize 200M \
    -field_order tt -fflags nobuffer -threads 1 \
    -vcodec mpeg4 -g 100 -r 30 -bf 0 -mbd bits -flags +aic+mv4+low_delay \
    -thread_type slice -slices 1 -level 32 -strict experimental -f_strict experimental \
    -syncpoints none -f nut "tcp://10.0.0.1:1234"

Критической частью этой команды является аргумент -g 100, который добавляет время между ключевыми кадрами, снижая битрейт потока.

На принимающей стороне я использовал ffplay(входит в комплект ffmpeg) для отображения потока на Raspberry Pi 3:

ffplay -autoexit -flags low_delay -framedrop -strict experimental \
    -vf setpts=0 -tcp_nodelay 1 "tcp://10.0.0.1:1234\?listen"

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

Связанный контент