Як змінити налаштування ffmpeg -threads


15

Робота над ділянкою трубки . Я біг відео через FFmpeg на Linux виділеного сервера для перетворення в mp4 .

Характеристики сервера:

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

Проблема під час тестування полягає в тому, що навіть роблячи 4-5 одночасно, сервер завантажується в середньому приблизно в 36. Це лише одна людина. Я думаю, що коли це відкриється, багато людей одразу завантажуватимуть.

Здається, ffmpeg намагається використати всі доступні ресурси за конверсію.

Я чув, що є параметр-нитки, який можна змінити, але я не можу його знайти. У мене є 8 процесорних серверів. Він використовується лише для конверсій, тому я чув, що найкраще налаштування було б від 2 до 4. Я можу перевірити його.

Але як я можу змінити цей параметр? Все, що я бачу в Інтернеті, обговорює цей параметр, але не кроки щодо його зміни.

linux  ffmpeg  cpu  mp4 

Відповіді:


17

Прапор опції, який ви хочете, насправді справедливий, -threadsі ви використовуєте його так (лише для однієї теми):

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

Однак є досить багато тонкощів, які піднімуть навантаження вашого сервера та час роботи, наприклад, масштабування, застосування фільтрів та кінцева якість кадру / частота кадрів - не кажучи вже про те, що деякі архітектури VM насправді читають і записують все двічі (колись вроджене і раз практично !!!)

Ось декілька порад для підвищення швидкості:

  1. використовуйте чергу, щоб одночасно перекодувати лише один елемент
  2. запитувати менші файли у своїх користувачів
  3. використовуйте повну потужність машини:
    • читання і запис з рамного диска
    • перехід на голий метал для завдань з перекодування
    • використання -threads 0

Що б ви не робили, інформуйте своїх користувачів про процес перекодування, оскільки це просто потребує часу. (IJTT)

[відредагована команда для відображення коментаря LordNeckbeard]


10
Варіант розміщення має значення. З -threadsперед введенням ви застосовуєте цю опцію вхід (декодер). Узагальнене використання є ffmpeg [global options] [input options] -i input [output options] output.
— llogan

То де б ви запропонували розмістити його? Я думав на початку, що це застосовується у всьому світі?
— denjello

3
Як вихідний варіант, він стає варіантом кодування. Перегляньте документацію FFmpeg, щоб переглянути параметри, позначені як (global).
— llogan

чи має значення, якщо ви ставите -threadsarg перед або після -iarg? Крім того, як я повинен визначити, скільки ниток я повинен використовувати? Я в основному просто роблю-c copy
— chovy

3

Це може бути трохи старим, але це здається ідеальним завданням для такого контейнера, як докер.

  • Нехай ffmpeg працює з full horsepower(як denjello називав це)
  • але нехай він працює всередині докера

Тепер ви можете обмежити, скільки ресурсів може використовувати один екземпляр ffmpeg, навіть не використовуючи параметри командної лінії ffmpeg. І не тільки процесор, але й пам'ять та IO.

Навіть більше: Можливо, у вас є різні завдання, які можуть працювати у фоновому режимі, і вам не байдуже, скільки часу вони займають, і у вас є завдання, які повинні швидко працювати, тому ви можете наділити вагу різним завданням.

Дивіться https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources

На github вже є попередньо визначене зображення ffmpeg: https://github.com/jrottenberg/ffmpeg

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

Одне перетворення, ймовірно, буде проходити повільніше через накладні витрати, але якщо одночасно запускати неодноразові екземпляри, це може бути величезною користю. Будь-яке це буде масштабувати дуже добре, не кажучи вже про покращену безпеку, оскільки кожне завдання ізольовані від основної ОС.


Хіба це не трохи екстремально запустити його в докер? Існує буквально багато інших кращих способів обмежити використання процесора в Linux scoutapm.com/blog/…
— yurtesen

Чому? Подумайте, у вас уже встановлений докер, запуск контейнера з --rmпрапором для виконання завдання та видалення контейнера після виходу є абсолютно нормальною справою, яку адміністратори могли і повинні робити у 2019 році. Особливо для таких речей, як перетворення документів. Не вдалося перетворити? Спробуйте іншу версію конвертера, не оновлюючи / зменшуючи місцевий ланцюжок інструментів? Ви не довіряєте документу, оскільки його завантажено з Інтернету? Виділіть завдання в контейнер. Ffmpeg не є винятком. cvedetails.com/vulnerability-list/vendor_id-3611/Ffmpeg.html
— Юрген Штейнблок

Це звучить як маркетингова розмова. Докер не є ідеальним, як ви сказали -> techbeacon.com/security/… У Linux звичайний користувач також користується обмеженим доступом та безпекою системи. Необхідність поновлення версій програми дуже рідкісна і може бути здійснена через сховище. Багато зображень докера зроблені випадковими людьми. Можливо, зображення докера перетворювача документів було порушено, і копія всіх ваших документів була віддалена на віддалений сервер. Так, використання зображень докера збільшує можливість такої вразливості. Що потім?
— юртесен

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?перевірити репо, вивчити докер-файл і використовувати docker build -t myimageдля створення локального зображення самостійно. Або створіть свій власний докерфайл, це не ракетна наука github.com/alfg/docker-ffmpeg/blob/master/Dockerfile
— Jürgen Steinblock
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.