Невозможно перекодировать 8 источников в реальном времени (FFmpeg)


1

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

Команда:

ffmpeg -y `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 3440x1440 -framerate 100 `
-pixel_format nv12 -i video="Video (Pro Capture)":audio="ADAT (3+4) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 3840x2160 -framerate 60 `
-pixel_format nv12 -i video="AVerMedia HD Capture GC573 1":audio="SPDIF/ADAT (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 1920x1080 -framerate 60 `
-pixel_format yuv420p -i video="Game Capture HD60 Pro (Video) (#01)":audio="Game Capture HD60 Pro (Audio) (#01)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -i audio="Analog (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -i audio="ADAT (5+6) (RME Fireface UC)" `
-c:v h264_nvenc -preset: llhp -pix_fmt nv12 -rc-lookahead 100 -b:v 288M -minrate 288M -maxrate 288M -bufsize 288M `
-c:a aac -ar 44100 -b:a 384k -vsync 1 -max_muxing_queue_size 9999 `
-map 0:0,0:1 -map 0:1 -map 1:0,1:1 -map 1:1 -map 2:0,2:1 -map 2:1 -map 3 -map 4 `
C:\Users\djcim\Videos\FFmpeg\FFmpeg.ts

Цель состоит в том, чтобы записывать все источники одновременно и синхронизироваться, многие параметры, которые я использую для синхронизации, отсутствуют в этой команде для простоты. Суть в том, что приведенная выше команда не транскодирует реальное время. Запись начинается со скоростью примерно .5x и медленно ползет к 1x, но как только она достигает 0.9-.95x, она перестает двигаться вверх, и в итоге моя системная память (32 ГБ) становится насыщенной, что приводит к падению кадров, еще худшей скорости транскодирования и общей системе вялость. Я не уверен, что моя системная память на самом деле заполняется, так как у меня есть только 2 ГБ буфера на каждом входе, и общий объем должен быть около 11 ГБ ... но я отвлекся.

Разделение каждого входа на его собственный вывод, кажется, не помогает. Если я удалю какой-либо из источников, даже только аудиопотоки, связанные с одним из видеопотоков, я достигну транскодирования в реальном времени в течение минуты. Если я удалю один из источников видео, я достигну транскодирования в реальном времени в течение 10 секунд. Если я уменьшу битрейт видео до 1M, я также смогу достичь транскодирования в реальном времени в течение 1 минуты, хотя можно подумать, что это даст больший эффект, чем удаление одного из небольших аудиоисточников.

Так что вы могли бы подумать, что где-то в моей системе будет узкое место, но видимого нет. Загрузка ЦП и накопителя составляет менее 30%, а кодирование моего графического процессора - менее 70%. Более того, если я разделю каждый вход / выход на свой собственный экземпляр Powershell / FFmpeg, но все равно буду запускать их одновременно / одновременно, то все будет транскодироваться в реальном времени практически мгновенно, что, похоже, исключит узкое место в оборудовании. Возможно ли, что это просто ограничение FFmpeg? Или есть вариант, который может решить проблему?

Любое понимание этого вопроса будет высоко оценено.


Первое, что нужно попробовать: смоделировать вашу команду с источниками файлов с похожими свойствами, но оставить выходные параметры одинаковыми.
Gyan

Вы имеете в виду, просто измените 5 живых входов на 5 файловых входов?
Nimble

Да. С такими же свойствами, то есть разрешением, частотой кадров и т. Д.
Gyan

Таким образом, я выполнил указанную выше команду в течение минуты, за исключением выводов для каждого входа, а затем снова вышеупомянутой команды с этими файлами в качестве входных данных. Производительность была значительно хуже, чем при кодировании живых источников, ниже .5x во время преобразования. Он также сильно ударял по моему ЦП, чего не происходит с живыми источниками, добавив -hwaccel nvdec, сняв нагрузку на ЦП, но не улучшив скорость транскодирования.
Nimble

Входные данные файла, вероятно, являются кодировками. Для лучшей симуляции они должны быть несжатыми или иметь легкое сжатие. Использование источников lavfi также является опцией, поскольку при этом также пропускается дисковый ввод-вывод.
Gyan
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.