Как сформулировать команду FFmpeg для потокового вещания с нулевой задержкой на гарнитуру VR?
Как бы сформулировать команду для потоковой передачи 2K 60-90 Гц с одного ПК на другой с минимально возможной задержкой с помощью ffmpeg?
Полная история:
Я собрал VR гарнитуру из eyebox с Amazon, гироскопа + arduino и 2K HDMI дисплея с Alibaba. Она хорошо работает с Blender Game engine, но провода сводят меня с ума.
Я пытаюсь сделать его беспроводным с помощью Raspberry Pi или другого маленького компьютера. (В любом случае мне нужно добавить груз сзади, чтобы сбалансировать гарнитуру)
Вот как я представляю себе настройку -
Сервер (ПК): Транслировать окно приложения 2K с минимально возможной задержкой на один из портов IP
Клиент (HMD): Запускаем Mplayer в режиме бенчмарка для минимально возможной задержки (согласно документации FFmpeg)
FFmpeg полностью интегрирован в Blender, но входной поток может быть просто захватом экрана рабочего стола.
Домашний маршрутизатор моего провайдера поддерживает 5Ghz Wifi. У меня также есть USB-накопитель 5Ghz Wifi CSL, который подключается к Linux.
Так как задержка очень плоха для VR, я думаю, я могу сэкономить несколько миллисекунд, передавая поток без сжатия? Поскольку потоковая передача осуществляется только по локальной сети, пропускная способность ограничена, я думаю, только 5 ГГц Wifi, который, я думаю, составляет около 100 Мбит/с.
Есть сотни способов интерпретировать документацию ffmpeg, похоже, что вы можете понять, какие опции использовать, только на собственном опыте. Я не вижу, чтобы кто-то еще пытался сделать то же самое.
Я могу потратить неделю, пробуя все возможные настройки, но я уверен, что тот, кто работает с ffmpeg каждый день, сразу поймет, какие настройки лучше использовать.
Эта команда дает около секунды задержки и 25 FPS:
Сервер: avconv -f x11grab -s 2160x1200 -r 60 -i :0.0 -f mpegts udp://192.168.0.2:1234
Клиент: mplayer -benchmark udp://192.168.0.2:1234
Если я использую 'rawvideo', поток не будет принят mplayer. Он просто скажет "поток не доступен для поиска".
avconv -f x11grab -s 640x1200 -r 60 -i :0.0 -f mpegts udp://192.168.0.2:1234
avconv -f x11grab -s 640x1200 -r 60 -i :0.0 -f mpegts udp://192.168.0.2:1235
avconv -f x11grab -s 640x1200 -r 60 -i :0.0 -f mpegts udp://192.168.0.2:1236
avconv -f x11grab -s 640x1200 -r 60 -i :0.0 -f mpegts udp://192.168.0.2:1237
и
MPlayer в режиме бенчмарка для отсутствия задержки
Более подробно: По сути, я выяснил, что поток нужно разделить, чтобы использовать больше CPU. Использование 'nice' для определения приоритета одного потока ничего не дает. Он просто гонит 2k при 25fps, используя, возможно, 30% CPU. Если же я разделю его на несколько потоков, как описано выше, то смогу получить 60FPS на каждой плитке при 85% использования CPU. Опция -threads 0-6 ведет себя не так, как можно было бы ожидать. Он просто делает рендеринг медленнее, если вообще делает. H264 лучше, а сеть должна быть гигабитной.