Учитывая, что для вашей цели не существует специального программного обеспечения *, я постараюсь ответить на это с точки зрения 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 к вашей проблеме. Вы должны будете попробовать это, чтобы узнать, работает ли это, я прошу прощения за это. Но сам по себе код должен работать - и если аппаратное обеспечение (особенно пропускная способность сети) не сдерживает вас, этот подход должен прекрасно работать на любом относительно новом процессоре.