Jak zmienić ustawienia wątków ffmpeg

15

Praca na stronie z rurkami . Biegnę filmy przez ffmpeg na linux serwer dedykowany do konwersji na mp4 .

Specyfikacja serwera:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 60
Stepping:              3
CPU MHz:               3491.749
BogoMIPS:              6983.49
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7

Problemem podczas testów jest to, że nawet robiąc tylko 4-5 naraz, serwer ładuje się gwałtownie do średnio około 36. To tylko jedna osoba. Wyobrażam sobie, że kiedy się otworzy, wiele osób będzie przesyłać jednocześnie.

Wygląda na to, że ffmpeg próbuje wykorzystać wszystkie zasoby dostępne na konwersję.

Słyszałem, że istnieje ustawienie -wątków, które możesz zmienić, ale nie mogę go znaleźć. Mam serwer 8 procesorów. Jest używany tylko do konwersji, więc słyszałem, że najlepsze ustawienie będzie między 2 a 4. Mogę to przetestować.

Ale jak mogę zmienić to ustawienie? Wszystko, co widzę online, omawia to ustawienie, ale nie kroki, aby je zmienić.


źródło

Odpowiedzi:

17

Flaga opcji, którą chcesz, jest naprawdę sprawiedliwa -threadsi możesz jej użyć w ten sposób (tylko dla jednego wątku):

ffmpeg -i somefile.wmv -c:a libfdk_aac -c:v libx264  -threads 1 transcoded.mp4

Istnieje jednak kilka subtelności, które zwiększą obciążenie serwera i czas operacji, takie jak przeskalowanie, zastosowanie filtrów i końcowa jakość klatek / liczba klatek - nie wspominając o tym, że niektóre architektury VM faktycznie odczytują i zapisują wszystko dwa razy (raz natywnie i raz wirtualnie !!!)

Oto kilka wskazówek, jak przyspieszyć:

  1. użyj kolejki, aby transkodowany był tylko jeden element naraz
  2. żądaj mniejszych plików od użytkowników
  3. wykorzystaj pełną moc swojej maszyny poprzez:
    • czytanie i pisanie z ramdysku
    • przejście na czysty metal do zadań transkodowania
    • posługiwać się -threads 0

Cokolwiek robisz, informuj swoich użytkowników o procesie transkodowania, ponieważ zajmuje to tylko trochę czasu. (IJTT)

[zredagowane polecenie odzwierciedlające komentarz LordNeckbeard]

denjello
źródło
10
Umieszczenie opcji ma znaczenie. Z -threadsprzed wejściem zastosujesz tę opcję wejście (dekoder). Uogólnione użycie to ffmpeg [global options] [input options] -i input [output options] output.
llogan
Więc gdzie sugerowałbyś go umieścić? Myślałem, że na początku był stosowany globalnie?
denjello,
3
Jako opcja wyjściowa staje się więc opcją kodowania. Zobacz dokumentację FFmpeg, aby zobaczyć, które opcje są oznaczone jako (global).
llogan
czy to ważne, czy wstawisz -threadsarg przed argonem, czy po nim -i? Jak mam ustalić, ile wątków powinienem użyć? Po prostu robię-c copy
chovy
3

To może być trochę stare, ale to brzmi jak idealne zadanie dla kontenera takiego jak doker.

  • Pozwól ffmpeg działać z full horsepower(jak to nazwał denjello)
  • ale pozwól mu działać w oknie dokowanym

Teraz możesz ograniczyć ilość zasobów, które pojedyncza instancja ffmpeg może zużyć bez użycia opcji wiersza komend ffmpeg. I to nie tylko procesor, ale także pamięć i operacje we / wy.

Co więcej: być może masz różne zadania, które mogą działać w tle i nie obchodzi Cię, jak długo one zajmują, i masz zadania, które powinny działać szybko, abyś mógł przypisać wagę różnym zadaniom.

Zobacz https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources

Na github jest już wstępnie zdefiniowany obraz ffmpeg: https://github.com/jrottenberg/ffmpeg

docker run jrottenberg/ffmpeg \
        -i http://url/to/media.mp4 \
        -stats \
        $ffmpeg_options  - > out.mp4

Pojedyncza konwersja będzie prawdopodobnie działać wolniej z powodu narzutu, ale jeśli uruchomisz wiele instancji jednocześnie, może to być ogromna korzyść. Wszystko to skaluje się bardzo dobrze, nie wspominając o poprawionym bezpieczeństwie, ponieważ każde zadanie jest odizolowane od podstawowego systemu operacyjnego.

Jürgen Steinblock
źródło
Czy to nie jest trochę ekstremalne, aby uruchomić go w oknie dokowanym? Istnieje dosłownie wiele innych lepszych sposobów ograniczenia użycia procesora na Linux scoutapm.com/blog/…
yurtesen
Dlaczego? Załóżmy, że masz już dokera, uruchamianie kontenera z --rmflagą w celu wykonania zadania i usunięcie kontenera po wyjściu to zupełnie normalna rzecz, którą administratorzy powinni i powinni zrobić w 2019 r. Zwłaszcza w przypadku konwersji dokumentów. Konwersja kończy się niepowodzeniem? Wypróbować inną wersję konwertera bez uaktualniania / obniżania poziomu lokalnego zestawu narzędzi? Nie ufasz dokumentowi, ponieważ został pobrany z Internetu? Izoluj zadanie w kontenerze. Ffmpeg nie jest wyjątkiem. cvedetails.com/vulnerability-list/vendor_id-3611/Ffmpeg.html
Jürgen Steinblock
To brzmi jak rozmowa marketingowa. Docker nie jest doskonały, jak to ująłeś -> techbeacon.com/security/... W Linuksie zwykły użytkownik ma również ograniczony dostęp i bezpieczeństwo systemu. Konieczność obniżenia wersji programu jest bardzo rzadka i można to zrobić poprzez repozytorium. Wiele obrazów dokerów jest tworzonych przez przypadkowych ludzi. Być może obraz dokera konwertera dokumentów został naruszony i wysłano kopię wszystkich dokumentów na zdalny serwer. Tak więc używanie obrazów dokerów zwiększa prawdopodobieństwo takiej podatności. Co wtedy?
yurtesen,
Perhaps the document converter docker image was compromised and sent copy of all your documents to a remote server. So, using docker images increase possibility such vulnerability. What then?przejrzyj repozytorium, sprawdź plik dokera i użyj go, docker build -t myimageaby samodzielnie stworzyć lokalny obraz. Lub stwórz własny plik dokerów, to nie jest nauka o rakietach github.com/alfg/docker-ffmpeg/blob/master/Dockerfile
Jürgen Steinblock