Мы хотели бы сделать на одном экране нашу прямую трансляцию до 60 HD телеканалов, похожую на это старое видео, показывающее 12 каналов SD. Мы сделали это с помощью программного обеспечения на подходящем мощном сервере, но хотели бы изучить аппаратное ускорение его и задались вопросом, что могут сделать современные высокопроизводительные графические процессоры?

https://www.youtube.com/watch?v=Ig6MpUsXyiY

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

Итак, что я должен искать, чтобы узнать, сколько HD-каналов может воспроизводить данная видеокарта, и есть ли хороший выбор (на данный момент) для этого?

1 ответ1

0

Учитывая, что для вашей цели не существует специального программного обеспечения *, я постараюсь ответить на это с точки зрения FFmpeg.

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

Я предполагаю следующие вещи:

  • Входные потоки имеют соотношение сторон 16: 9 и должны быть оставлены таким образом (т.е. без обрезки)
  • Выходной поток также имеет соотношение сторон 16: 9
  • Оба входных потока и выходной поток являются FullHD (1920x1080 пикселей)
  • Аппаратные возможности не ограничены (имеется в виду: я не могу проверить свой ответ, поскольку у меня нет 60 входных потоков и / или того же оборудования, что и у вас).

Разделенный экран

Если вы не хотите обрезать что-либо из каких-либо входных данных и соотношение сторон обоих входов и выходных данных одинаково, вы можете использовать сетку из n * n потоков. Поскольку 8 * 8 = 64 - это самая маленькая сетка, подходящая для всех входов, мы пойдем с этим. 4 пространства сетки не будут заполнены - вы можете сэкономить их в середине или по углам (я пойду с последним).

-filter_complex "
    nullsrc=size=1920x1080[base];
    [0:v]scale=w=in_w/8:h=in_h/8[0_1];
    [1:v]scale=w=in_w/8:h=in_h/8[0_1];
    [2:v]scale=w=in_w/8:h=in_h/8[0_2];
    [3:v]scale=w=in_w/8:h=in_h/8[0_3];
    <<AND SO ON>>
    [59:v]scale=w=in_w/8:h=in_h/8[7_6];
    [base][0_1]overlay=x=240:y=0[tmp0];
    [tmp0][0_2]overlay=x=480:y=0[tmp1];
    <<AND SO ON>>
    [tmp9][1_2]overlay=x=480:y=135[tmp10];
    <<AND SO ON>>
    [tmp58][7_6]overlay=x=1440:y=945
"

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


Потоки (как внутри, так и снаружи)

Должна быть самая легкая часть, хотя это та часть, о которой я действительно не могу сказать много. StreamingGuide от FFmpeg имеет несколько идей по этому поводу:

На стороне ввода:

# Using TCP:
ffmpeg -i tcp://host:port?listen
# Using RTSP:
ffmpeg -rtsp_flags listen rtsp://host:port/live.sdp?tcp

На выходной стороне:

# For TCP:
ffmpeg -i INPUT -f mpegts tcp://host:port
# For UDP:
ffmpeg -i INPUT -f mpegts udp://host:port
# For RTSP (using TCP instead of UDP):
ffmpeg -i input -f rtsp -rtsp_transport tcp rtsp://host:port/live.sdp

Документация FFmpeg ссылается на этот сайт - он содержит пример транскодирования из RTMP в RTMP.


Ускорение, латентность

StreamingGuide FFmpeg предлагает следующие настройки:

-c:v libx264 -tune zerolatency -preset ultrafast

Они кажутся вполне разумными, так как они, вероятно, не окажут слишком большого влияния на вашу задержку. Если хотите, вы можете попробовать другие кодеки (в x265 также есть опция zerolatency). Если есть вероятность того, что какой-либо из входных потоков имеет поток autio, будет хорошей идеей -an , так как он пропустит все auio и, следовательно, на один кодер меньше беспокоиться.

Теперь, если вы хотите пойти по GPU-маршруту, я мало что могу вам сказать, не зная точную модель вашего GPU. HWAccelIntro-Wiki от FFmpeg, вероятно, может вам помочь. Я, например, не стал бы беспокоиться об этом - я даже не могу заставить свой GTX970 вести себя хорошо с двумя входными потоками (я предполагаю, что это потому, что GPGPU не созданы для многозадачности, но это неподдерживаемое утверждение) и h264_nvenc on -preset fast значительно медленнее , чем libx264 на -preset ultrafast Даже если это работает, вещи начинают становиться грязными, быстрыми: поток будет раздутым (по сравнению с x264), и блокирующие артефакты довольно распространены.


Добавление всего этого вместе

# Calling FFmpeg, getting inputs:
ffmpeg -i tcp://host:port?listen <<REPEAT 59 TIMES>>
# Create the splitscreen:
    -filter_complex "<<TAKE THE FILTER FROM ABOVE>>"
# Encoding-options:
    -an -c:v libx264 -tune zerolatency -preset ultrafast
# Output as stream:
    -f mpegts tcp://host:port

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


Заключение

Это должен быть подход FFmpeg к вашей проблеме. Вы должны будете попробовать это, чтобы узнать, работает ли это, я прошу прощения за это. Но сам по себе код должен работать - и если аппаратное обеспечение (особенно пропускная способность сети) не сдерживает вас, этот подход должен прекрасно работать на любом относительно новом процессоре.

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