Nie można transkodować 8 źródeł w jednym wystąpieniu w czasie rzeczywistym (FFmpeg)


1

Tylko na drugi dzień ja pisał o mojej niezdolności przekodować wielośladowym wideo w czasie rzeczywistym, -Rc-uprzedzona zakończył się rozwiązaniem. Jednak było to podczas nagrywania dość statycznych sygnałów, gdy każda karta przechwytywania odbiera bardziej złożony sygnał, nadal nie jestem w stanie transkodować w czasie rzeczywistym za pomocą żadnego z poleceń wymienionych w tym poście.

Dowództwo:

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

Celem jest nagrywanie wszystkich źródeł jednocześnie i synchronizacja, dla uproszczenia brakuje wielu opcji, których używam do synchronizacji. Podsumowując, powyższe polecenie nie transkoduje w czasie rzeczywistym. Nagrywanie rozpoczyna się z prędkością około .5x i powoli przesuwa się w kierunku 1x, ale gdy osiągnie około .9-.95x, przestaje się przesuwać i ostatecznie moja pamięć systemowa (32 GB) jest nasycona, powodując spadki klatek, jeszcze gorszą transkodowanie i ogólny system ospałość. Nie jestem pewien, jaka jest tak naprawdę moja pamięć systemowa, ponieważ mam tylko 2 GB buforu na każdym wejściu, a suma powinna wynosić około 11 GB ... ale dygresuję.

Oddzielenie każdego wejścia od własnego wyjścia nie wydaje się pomocne. Jeśli usunę jedno ze źródeł, nawet strumienie audio połączone z jednym ze strumieni wideo, transkodowanie w czasie rzeczywistym nastąpi w ciągu minuty. Jeśli usunę jedno ze źródeł wideo, transkodowanie w czasie rzeczywistym nastąpi w ciągu 10 sekund. Jeśli obniżę bitrate wideo do 1M, mogę również osiągnąć transkodowanie w czasie rzeczywistym w ciągu 1 minuty, choć można by pomyśleć, że ma to większy efekt niż usunięcie jednego z mniejszych źródeł audio.

Można by pomyśleć, że gdzieś w moim systemie będzie wąskie gardło, ale nie jest widoczne. Zużycie procesora i napędu wynosi poniżej 30%, a użycie enkodera mojego GPU poniżej 70%. Co więcej, jeśli oddzielę każde wejście / wyjście od własnej instancji Powershell / FFmpeg, ale nadal uruchomię je jednocześnie / jednocześnie, wszystko transkoduje w czasie rzeczywistym w zasadzie natychmiast, co wydaje się wykluczać wąskie gardło sprzętowe. Czy to możliwe, że jest to po prostu ograniczenie FFmpeg? A może istnieje opcja, która może rozwiązać problem?

Wszelkie informacje na ten temat byłyby bardzo mile widziane.


Pierwsza rzecz do wypróbowania: symuluj polecenie za pomocą źródeł plików o podobnych właściwościach, ale zachowaj parametry wyjściowe takie same.
Gyan

Masz na myśli po prostu zmianę 5 wejść na żywo na 5 plików?
Zwinny

Tak. Z tymi samymi właściwościami, tj. Rozdzielczością, liczbą klatek na sekundę itp.
Gyan

Uruchomiłem więc powyższe polecenie przez minutę, z wyjątkiem danych wyjściowych dla każdego wejścia, a następnie powyższego polecenia ponownie z tymi plikami jako danymi wejściowymi. Wydajność była znacznie gorsza niż w przypadku kodowania źródeł na żywo, poniżej 0,5x w czasie trwania konwersji. Bardzo mocno uderzał w mój procesor, co nie zdarza się w przypadku źródeł na żywo, dodanie -hwaccel nvdec zmniejszyło obciążenie procesora, ale nie poprawiło prędkości transkodowania.
Zwinny

Dane wejściowe pliku są prawdopodobnie kodowaniem. Dla lepszej symulacji powinny one być nieskompresowane lub mieć lekką kompresję. Opcjonalne jest także korzystanie ze źródeł lavfi, ponieważ pomija ono także dyskowe operacje we / wy.
Gyan
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.