Intel Quick Sync: прихована відеозброя

Що таке Quick Sync насправді (і чого це не стосується)

Quick Sync Video — це виділений апаратний блок для медіа в багатьох CPU Intel (і в деяких дискретних GPU Intel). Він обробляє кодування/декодування відео, не навантажуючи загального призначення CPU. Важливе слово — виділений. Це не «використання iGPU для обчислень». Це використання фіксованої (або напівфіксованої) електроніки, спеціально побудованої для декоду/енкоду H.264/H.265/VP9/AV1 (залежно від покоління) та суміжної обробки.

У практичному SRE-плані: QSV перетворює «транскодування — це CPU-завдання пакетної обробки» на «транскодування — це конвеєр I/O-подібного типу з обмеженнями пристрою». Вузьке місце переміщається. Зазвичай це хороший крок, але потрібно знати, куди воно перемістилося.

Ментальна модель, яка не підведе

• Декод: перетворити стиснуте відео на сирі кадри.
• Фільтр/Обробка: масштабування, перетворення кольорового простору, деінтерлейсинг, тонемапінг (іноді на GPU, іноді ні).
• Енкод: сирі кадри назад у стиснутий формат.

Quick Sync може прискорювати декод і енкод. Ваш конвеєр все ще може відкотитися на CPU для фільтрів, якщо ви явно не триматимете кадри в шляхах GPU. Саме тут «я ввімкнув апаратне прискорення» перетворюється на «я ввімкнув його напівпортionsально».

Також: QSV — це не магія стискання. Якщо ви попросите «прозору якість при 2 Mbps для 4K», апарат ввічливо виконає та результат буде виглядати як акварель. Апаратне прискорення змінює вартість і пропускну здатність. Воно не скасовує фізику.

Факти та історичний контекст для нарад

Це короткі, конкретні пункти, які припиняють безкінечні суперечки в кімнаті.

1. Quick Sync дебютував з Sandy Bridge (2011), тому старі домашні гайди згадують «Gen6». Ідея стара; можливості — ні.
2. Підтримка залежить від покоління: пізніші iGPU додають 10-бітний HEVC, VP9 і зрештою AV1. «Має Quick Sync» ≠ «має потрібний вам кодек».
3. Intel використовує два основні user-space стекa на Linux: VA-API (з iHD драйвером) і Media SDK / oneVPL маршрут. QSV у FFmpeg може працювати через них.
4. На сучасному Linux iHD (intel-media-driver) — зазвичай правильний вибір; i965 (legacy) все ще може з’являтися на старих дистрибутивах і створювати плутанину.
5. Plex і Jellyfin не «використовують QSV» безпосередньо; вони викликають FFmpeg (або еквівалент), який викликає стек драйверів. Коли щось ламається, часто причина не в «Plex», а в правах доступу або драйверах/бібліотеках.
6. Пропускна здатність Quick Sync не лінійна від номерів моделей CPU. Дешевший CPU з сучасним iGPU може краще транскодувати, ніж старіший «більший» CPU, бо змінився медіа-блок.
7. HDR → SDR тонемапінг — часта пастка для прискорення. Декод/енкод можуть бути апаратними, але тонемапінг може відкотитися на CPU, якщо ви не побудуєте конвеєр обережно.
8. Intel Arc та новіші iGPU можуть кодувати AV1 (залежно від моделі). Це змінює стратегії архівації та стрімінгу, але й ускладнює сумісність клієнтів.

Коли використовувати QSV проти CPU або NVIDIA/AMD

Якщо ви запускаєте production відео-робочі навантаження, ваше рішення не повинно бути «що найшвидше». Має бути «що відповідає моєму SLA з передбачуваними режимами відмов і розумними операціями». Ось відверта версія.

Використовуйте QSV коли

• Ви хочете високу одночасність транскодів на ват на одному хості.
• Ви будуєте чутливі до витрат вузли, де дискретний GPU буде недозавантажений.
• Вам потрібна достатньо хороша якість на практичних бітрейтах для стрімінгу, а не кіномайстерня.
• Ви віддаєте перевагу інтегрованій надійності (без додаткової PCIe карти, менше вентиляторів, менше несподіванок з драйверами при оновленнях ядра — зазвичай).

Використовуйте CPU (x264/x265) коли

• Якість на бітрейт важлива для бізнесу (архіви, майстер-енкоди VOD, ескалації «чому це виглядає розмазано?»).
• Ваш конвеєр потребує екзотичних фільтрів і ви не хочете змішаного апаратно/програмного графа.
• Ви можете амортизувати довгі часи кодування і хочете детермінізму.

Використовуйте дискретне GPU коли

• Вам потрібно більше сесій, ніж iGPU може забезпечити на цільових налаштуваннях.
• Вам потрібні функції, які просто краще підтримуються на цій платформі у вашому середовищі.
• У вас стандартизований флот вже (наприклад, NVIDIA скрізь), і стандартизація важить більше за теоретичну ефективність.

Моя операційна упередженість: якщо ви будуєте медіабокс або невеликий пул транскодування і у вашому ланцюгу постачання вже є Intel iGPU, почніть з QSV. Це «безкоштовний обід», який справді безкоштовний — поки ви не забудете перевірити права на /dev/dri і не проведете суботу, розбираючись чому обід вислизнув.

Якість, затримка, бітрейт: реальні компроміси

Скажемо прямо: QSV часто не відрізняється від CPU-енкодів на типових стрімінгових бітрейтах — поки не відрізняється. «Поки не» зазвичай проявляється в темних сценах, шумі, швидкому русі та контенті з великою кількістю дрібних текстур (спорт, анімація з градієнтами, кінозерно). Коли хтось скаржиться на «banding», це сигнал перевірити 10-бітні шляхи, налаштування енкодера і чи не робите ви непотрібні перетворення кольорового простору.

Зрозумійте реальні ручки, які у вас є

• Керування бітрейтом: CBR/VBR/ICQ/LA_ICQ (назви варіюються). Для багатьох QSV-воркфлоу режим, схожий на ICQ, може бути оптимальним: стабільна якість, розумний бітрейт.
• Lookahead: покращує якість за рахунок затримки і іноді ресурсів GPU.
• B-кадри: краща компресія, але можуть збільшувати затримку і створювати проблеми сумісності в деяких low-latency сценаріях.
• Low power режим: чудово для енергоефективності; не завжди найкраще для якості або підтримки функцій.
• 10-бітне кодування: допомагає проти banding; вимагає підтримки клієнтів і коректного конвеєру.

Затримка — це не лише «швидкість енкодера»

Апаратний енкодер може бути швидким і одночасно давати більшу загальну затримку, якщо ваш граф фільтрів пересилає кадри GPU → CPU → GPU. Кожна копія додає накладні витрати, і у масштабі ці копії стають вузьким місцем. Саме тому ви тестуєте з той самими фільтрами, які використовуєте в продакшні, а не з милим демо «перекодуй файл».

Цитата, яку варто тримати на стікері, переказана від John Ousterhout: Простота — передумова надійності. QSV-конвеєри стають ненадійними, коли вони надто хитромудрі.

Драйвери Linux і вузли пристроїв: де прискорення гине

На Linux успіх з QSV зазвичай залежить від чотирьох речей:

1. Ядро бачить iGPU і завантажує i915 (або новіший стек графіки Intel).
2. User-space має правильний медіа-драйвер (intel-media-driver / iHD) і підтримуючі бібліотеки.
3. Ваш процес може отримати доступ до /dev/dri/renderD* (а іноді й card*).
4. Ваш застосунок використовує апаратний шлях end-to-end (decode → filter → encode) без мовчазних відкотів.

На серверах налаштування BIOS люблять саботувати вас. «Headless» не означає «вимкнути iGPU». Вам потрібно, щоб iGPU був увімкнений навіть без монітора, і часто треба вмикати опцію на кшталт «iGPU multi-monitor», щоб пристрій лишався перерахованим.

І контейнери: маппінг /dev/dri — необхідний, але не достатній. Користувач у контейнері потребує прав, і стек драйверів хоста має бути сумісний з бібліотеками всередині контейнера. Якщо ви міксуєте, як плейлист, отримаєте ремікс, якого не просили.

Жарт №1: апаратне прискорення — як абонемент у спортзал — саме по собі не зробить вас швидшим; треба ним користуватися.

Практичні завдання: команди, виводи, рішення

Нижче — реальні завдання оператора. Кожне включає: команду, типовий вивід, що це означає і яке рішення прийняти.

Завдання 1: Підтвердити наявність iGPU і правильний драйвер ядра

cr0x@server:~$ lspci -nnk | sed -n '/VGA compatible controller/,+6p'
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 770 [8086:4692] (rev 0c)
	Subsystem: ASUSTeK Computer Inc. Device [1043:8882]
	Kernel driver in use: i915
	Kernel modules: i915

Значення: iGPU виявлено і використовується i915. Добре.

Рішення: Якщо ви не бачите Intel graphics або відсутній рядок Kernel driver in use, виправте налаштування BIOS, параметри ядра або вибір апаратури перед налаштуванням FFmpeg.

Завдання 2: Перевірити, що /dev/dri існує і які вузли присутні

cr0x@server:~$ ls -l /dev/dri
total 0
drwxr-xr-x  2 root root        80 Jan 10 09:20 by-path
crw-rw----+ 1 root video  226,   0 Jan 10 09:20 card0
crw-rw----+ 1 root render 226, 128 Jan 10 09:20 renderD128

Значення: У вас є render node (renderD128), який потрібен більшості транскодингових задач; права засновані на групах (render).

Рішення: Переконайтеся, що сервісний користувач у групі render (іноді також video). Віддавайте перевагу render nodes над card nodes для обчислень без відображення.

Завдання 3: Перевірити права сервісного користувача на пристрій

cr0x@server:~$ id plex
uid=998(plex) gid=998(plex) groups=998(plex),44(video),109(render)

Значення: Користувач plex може отримати доступ і до video, і до render пристроїв.

Рішення: Якщо render відсутній — додайте користувача і перезапустіть сервіс. Не вирішуйте це chmod 777, якщо не любите інциденти, зроблені власноруч.

Завдання 4: Підтвердити, що VA-API бачить intel media driver і профілі

cr0x@server:~$ vainfo --display drm --device /dev/dri/renderD128 | head -n 25
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_20
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.20 (libva 2.20.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 23.4.3 ()
vainfo: Supported profile and entrypoints
      VAProfileH264Main            : VAEntrypointVLD
      VAProfileH264Main            : VAEntrypointEncSlice
      VAProfileHEVCMain            : VAEntrypointVLD
      VAProfileHEVCMain            : VAEntrypointEncSlice
      VAProfileVP9Profile0         : VAEntrypointVLD

Значення: Драйвер iHD завантажується і відкриває точки входу для декоду й енкоду. Це ваш базовий список можливостей.

Рішення: Якщо завантажується i965 несподівано або драйвер не відкривається — ви у зоні невідповідності бібліотек/драйверів. Виправте це перед тим, як звинувачувати QSV.

Завдання 5: Перевірити, чи FFmpeg бачить QSV енкодери/декодери

cr0x@server:~$ ffmpeg -hide_banner -encoders | grep -E 'qsv|vaapi' | head
 V..... h264_qsv             H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration)
 V..... hevc_qsv             HEVC (Intel Quick Sync Video acceleration)
 V..... h264_vaapi           H.264/AVC (VAAPI) (codec h264)
 V..... hevc_vaapi           H.265/HEVC (VAAPI) (codec hevc)

Значення: FFmpeg зібрано з підтримкою QSV і VAAPI.

Рішення: Якщо QSV енкодери відсутні — ваша збірка FFmpeg невідповідна для мети. Виправте пакування/збірку; не налаштовуйте прапори, які не працюватимуть.

Завдання 6: Запустити мінімальний QSV-транскод і підтвердити, що він не мовчки працює на CPU

cr0x@server:~$ ffmpeg -hide_banner -y \
  -init_hw_device qsv=hw:/dev/dri/renderD128 -filter_hw_device hw \
  -hwaccel qsv -c:v h264_qsv -i input.mp4 \
  -c:v h264_qsv -global_quality 23 -look_ahead 1 \
  -c:a aac -b:a 160k output.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
  Stream #0:0: Video: h264 (High), yuv420p, 1920x1080, 30 fps
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (h264_qsv) -> h264 (h264_qsv))
Press [q] to stop, [?] for help
frame=  900 fps=240 q=-0.0 Lsize=   28000kB time=00:00:30.00 bitrate=7648.0kbits/s speed=8.00x

Значення: І декод, і енкод виконуються через QSV, і швидкість натякає на апаратне прискорення.

Рішення: Якщо ви бачите h264 (software) замість h264_qsv, ви не використовуєте QSV, незважаючи на наміри. Виправте команду, налаштування застосунку або середовище.

Завдання 7: Виявити fallback на CPU, спостерігаючи за використанням CPU по потоках під час «апаратної» роботи

cr0x@server:~$ pidof ffmpeg
24718
cr0x@server:~$ top -H -p 24718 -b -n 1 | head -n 15
top - 09:41:12 up 12 days,  3:18,  1 user,  load average: 0.88, 0.71, 0.62
Threads:  18 total,   0 running,  18 sleeping
%Cpu(s):  8.3 us,  1.2 sy,  0.0 ni, 90.1 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
24718 cr0x      20   0 1522480 212340  60240 S  24.0   1.3   0:03.20 ffmpeg
24731 cr0x      20   0 1522480 212340  60240 S   1.0   1.3   0:00.05 ffmpeg

Значення: Використання CPU невелике. Якщо «апаратний» транскод зʼїдає 600% CPU, фільтри ймовірно на CPU або відбувся повний fallback.

Рішення: Високе навантаження CPU означає аудит графа фільтрів і апаратних поверхонь, а не зміну бітрейту.

Завдання 8: Перевірити завантаження графічного двигуна Intel GPU (реальна перевірка)

cr0x@server:~$ sudo intel_gpu_top -J -s 1000 -o - | head -n 20
{
  "period": 1000,
  "engines": {
    "Render/3D/0": { "busy": 3.21 },
    "Video/0": { "busy": 64.18 },
    "VideoEnhance/0": { "busy": 22.07 },
    "Blitter/0": { "busy": 0.00 }
  }
}

Значення: Відео-двигун зайнятий. Це Quick Sync робить роботу. Активність VideoEnhance часто вказує на масштабування або постобробку.

Рішення: Якщо Video близький до 0% під час «апаратного» транскоду, ви не апаратно кодуєте/декодуєте. Припиніть суперечки і виправте шлях.

Завдання 9: Швидко перевірити підтримку кодеків за допомогою vainfo grep

cr0x@server:~$ vainfo --display drm --device /dev/dri/renderD128 | grep -E 'AV1|HEVC|H264' | head -n 12
VAProfileH264Main            : VAEntrypointVLD
VAProfileH264Main            : VAEntrypointEncSlice
VAProfileHEVCMain            : VAEntrypointVLD
VAProfileHEVCMain            : VAEntrypointEncSlice

Значення: У вас є H.264/HEVC декод+енкод. AV1 тут не показано, тому не обіцяйте AV1-енкод на цій машині.

Рішення: Узгодьте стратегію клієнтів/пристроїв з тим, що підтримує апарат. Якщо потрібен AV1 — підбирайте інший силікон.

Завдання 10: Виявити невідповідність драйверів/бібліотек у логах, коли застосунки контейнеризовані

cr0x@server:~$ docker logs jellyfin 2>&1 | tail -n 20
[AVHWDeviceContext @ 0x55a2c7c8c700] Failed to initialise VAAPI connection: -1 (unknown libva error).
Device creation failed: -5.
Failed to set value 'vaapi=va:/dev/dri/renderD128' for option 'init_hw_device': Input/output error
Error parsing global options: Input/output error

Значення: Контейнер бачить шлях пристрою (або думає, що бачить), але ініціалізація VAAPI провалюється — часто через відсутні або неправильні user-space драйвери всередині контейнера, або права доступу.

Рішення: Переконайтеся, що образ контейнера містить правильні libva + intel-media-driver, і змонтуйте /dev/dri разом із правильними групами/правами.

Завдання 11: Підтвердити, що контейнер дійсно має /dev/dri і відповідні групи

cr0x@server:~$ docker exec -it jellyfin bash -lc 'ls -l /dev/dri && id'
total 0
crw-rw---- 1 root render 226, 128 Jan 10 09:20 renderD128
uid=0(root) gid=0(root) groups=0(root)

Значення: Пристрій присутній; контейнер працює від root, тому права, ймовірно, не проблема. Це повертає нас до відсутніх драйверів/бібліотек.

Рішення: Встановіть intel media driver пакети в образ або перейдіть на образ, який їх вже містить; тримайте очікування libva хоста і контейнера сумісними.

Завдання 12: Перевірити граф фільтрів FFmpeg щодо випадкового завантаження/вивантаження на CPU

cr0x@server:~$ ffmpeg -hide_banner -loglevel verbose \
  -init_hw_device qsv=hw:/dev/dri/renderD128 -filter_hw_device hw \
  -hwaccel qsv -c:v hevc_qsv -i hdr10_input.mkv \
  -vf 'scale=1280:720' -c:v h264_qsv -global_quality 24 -an -f null - 2>&1 | grep -E 'hwupload|hwdownload|qsv|format' | head -n 30
[graph 0 input from stream 0:0 @ 0x55b0be5f9f00] w:3840 h:2160 pixfmt:p010le tb:1/1000 fr:24/1 sar:1/1
[Parsed_scale_0 @ 0x55b0be6a8440] w:3840 h:2160 fmt:p010le -> w:1280 h:720 fmt:yuv420p
[Parsed_scale_0 @ 0x55b0be6a8440] using software scaling

Значення: Фільтр масштабування працює програмно. Для одного потоку це може бути прийнятно, але це часто прихований споживач CPU у «апаратних» конвеєрах, особливо з 4K HDR.

Рішення: Якщо CPU стає вузьким місцем, використовуйте апаратно-орієнтоване масштабування (QSV/VAAPI фільтри) і тримайте кадри на GPU, де можливо.

Завдання 13: Переконатися, що iGPU не засинає на headless сервері (перевірка dmesg)

cr0x@server:~$ dmesg | grep -E 'i915|drm' | tail -n 12
[    2.114321] i915 0000:00:02.0: [drm] VT-d active for gfx access
[    2.118220] i915 0000:00:02.0: [drm] GuC firmware load skipped
[    2.145881] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[    2.146201] i915 0000:00:02.0: [drm] Using Transparent Hugepages

Значення: i915 ініціалізувався коректно. Помилки тут (невдачі прошивки, wedged GPU) корелюють з нестабільністю транскодингу.

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

Завдання 14: Перевірити ознаки насичення сесій (коли QSV «працює», але є брак потужності)

cr0x@server:~$ sudo intel_gpu_top -s 1000 | head -n 12
intel-gpu-top: Intel Alderlake_s (Gen12)
      IMC reads:  312 MiB/s  IMC writes:  148 MiB/s

      Render/3D     6.12% |      Blitter   0.00% |      Video  96.88% | VideoEnhance  54.22%

      RC6       0.00% |       Power   18.40 W | GPU freq  1550 MHz

Значення: Video завантажено майже на 100%. Ви близькі до ліміту рухуна QSV.

Рішення: Зменшіть складність на потік (масштабуйте раніше, знижуйте частоту кадрів, уникайте дорогого тонемапінгу), або додайте вузли. Не підвищуйте ліміти CPU — CPU більше не вузьке місце.

Завдання 15: Переконатися, що Plex справді використовує апаратне транскодування

cr0x@server:~$ sudo tail -n 30 "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Logs/Plex Media Server.log" | grep -i -E 'qsv|vaapi|hardware'
Jan 10, 09:48:01.112 [0x7f2b2c0b6700] INFO - [Transcode] Using hardware transcoding: Intel Quick Sync Video
Jan 10, 09:48:01.115 [0x7f2b2c0b6700] INFO - [Transcode] Selected video encoder: h264_qsv

Значення: Plex вважає, що використовує QSV і обрав QSV-енкодер.

Рішення: Вважайте це необхідною, але не достатньою умовою. Перевірте додатково за допомогою intel_gpu_top. Логи можуть казати «hardware», навіть коли пізніший етап відкотився.

Завдання 16: Перевірити, що Jellyfin/FFmpeg обирають QSV (а не випадково VAAPI)

cr0x@server:~$ grep -R "h264_qsv\|hevc_qsv\|init_hw_device" -n /var/log/jellyfin/ffmpeg*.log | tail -n 10
/var/log/jellyfin/ffmpeg-transcode-6b4c2.log:12:ffmpeg -init_hw_device qsv=hw:/dev/dri/renderD128 -filter_hw_device hw -c:v h264_qsv -i ...
/var/log/jellyfin/ffmpeg-transcode-6b4c2.log:34:Stream #0:0 -> #0:0 (h264 (h264_qsv) -> h264 (h264_qsv))

Значення: Реальна командна рядок використовує QSV device init і QSV кодек. Це сильніший доказ, ніж перемикач у UI.

Рішення: Якщо логи показують libx264 або відсутній hw init — виправте налаштування апаратного прискорення Jellyfin і маппінг пристрою в контейнері.

Швидкий план діагностики

Це для випадків, коли у вас скарги на буферизацію і рівно п’ятнадцять хвилин до наступної наради. Мета — визначити вузьке місце, а не досягти просвітлення.

Перше: доведіть, чи QSV задіяний

1. Перевірте завантаження Video engine за допомогою intel_gpu_top. Якщо Video лишається близько 0% під час транскоду — QSV не задіяний.
2. Перегляньте ефективну FFmpeg-команду/логи застосунку (логи Plex, ffmpeg логи Jellyfin). Шукайте h264_qsv, hevc_qsv і -init_hw_device qsv=....
3. Підтвердіть доступ до пристрою: ls -l /dev/dri і групи користувачів. Проблеми з правами — #1 причина «вчора працювало» після оновлень або змін у контейнерах.

Друге: визначте, GPU- чи CPU-заблоковані ви

1. Якщо Video engine ~90–100% і CPU помірний: ви QSV-заблоковані. Зменшуйте навантаження на потік або розгорніть горизонтально.
2. Якщо CPU високий, а Video мало/помірно: ви обмежені фільтрами на CPU (масштабування, вбудовування субтитрів, тонемапінг) або конвеєр відкотився.
3. Якщо обидва низькі, але відтворення буфериться: дивіться на диск/мережу, а не на транскодування.

Третє: знайдіть конкретну стадію, яка шкодить

1. Тонемапінг HDR? Припускайте, що це підозрюваний, поки не доведено інше. Перевірте, чи прискорюється тонемапінг у вашому стеку.
2. Вбудовування субтитрів? Зображення-подібні субтитри (PGS) часто змушують рендерити CPU і можуть сильно знизити пропускну здатність.
3. Масштабування з 4K? Програмне масштабування з 4K до 1080p — ефективний спосіб перетворити ваш CPU на контролер вентилятора.

Жарт №2: Найшвидший транскод — той, який ви не робили — direct play це єдина оптимізація, яка ніколи не ламається.

Три корпоративні міні-історії з практики

1) Інцидент через неправильне припущення: «Це Intel CPU, значить QSV доступний»

Команда, з якою я працював, побудувала новий рівень стрімінгової платформи для внутрішніх навчальних відео. Вибір апаратури був «безпечний»: сучасні Intel CPU, багато RAM, швидкі NVMe. Припущення було, що Quick Sync впорається з транскодами для віддалених співробітників на сумнівному Wi‑Fi.

Тиждень запуску прийшов. Моніторинг показав неприємну картину: CPU на 95% у пулі, затримки зростають, черги транскодингу утворюються, як лінія в парку розваг. Але панель додатку стверджувала «hardware acceleration enabled». Інженер на чергуванні робив те, що ми всі робимо під тиском: перезапускав сервіс і ще уважніше дивився на панель.

Насправді все було болісно просто. Це були F-серії CPU — без інтегрованого GPU. Ніякого iGPU, ніякого QSV. Сервери робили програмний енкод, бо більше нічого не могли робити. Ніхто не перевірив lspci перед затвердженням BOM.

Виправлення не було героїчним. Вони перепланували специфікацію вузла, щоб включити частини з iGPU (або додали дискретні GPU в підмножину вузлів), оновили правила закупівель і додали preflight-скрипт, який відмовляв у провізії, якщо /dev/dri/renderD128 не присутній.

Операційний урок: «Intel» — не функція. QSV вимагає силікону, драйверів і прав. Ставтеся до цього як до залежності. Перевіряйте її, не влаштовуйте vibe-check.

2) Оптимізація, яка відкотилася: «Давайте змусимо все HEVC, щоб зекономити трафік»

Платформа корпоративного звʼязку вирішила стандартизувати транс-коди на HEVC, щоб зменшити витрати CDN. На папері це було розумно: краща компресія ніж H.264 при тій же якості, і сучасні клієнтські пристрої були «переважно сумісні». Вони змінили дефолтний ladder на HEVC і побачили покращення графіків трафіку.

Потім почалися заявки в підтримку. Деякі клієнтські пристрої переходили на програмний декод, батарея садилася, і слабші ноутбуки почали втрачати кадри. Гірше: частина корпоративних браузерів не відтворювала формат залежно від політики і збірки ОС. Сторона транскоду виглядала здоровою; клієнтський досвід — ні.

Вони намагались «виправити» підвищенням бітрейту. Це зменшило артефакти, але підняло трафік назад. Вони намагались «виправити» шляхом прокачування більшої кількості HEVC-сеансів через QSV на вищих якостях, що наситило відео-двигун. Тепер буферизація зʼявилася і на боці сервера.

Зрештою вирішення було нудне, але ефективне: тримати H.264 як найбільш сумісну базу, використовувати HEVC вибірково та інвестувати в розумні рішення direct play. Також HDR-контент зробили спеціальним шляхом, бо тонемапінг і 10-бітні обробки мають інші обмеження.

Операційний урок: рішення щодо кодеків — це рішення кінцево-системне. Оптимізація однієї статті бюджету може вибухнути в іншій — зазвичай у бюджеті підтримки.

3) Нудна, але правильна практика, яка врятувала ситуацію: тести ємності з реальним набором фільтрів

Інша організація запускала сервіс медіаобробки, що генерував proxy-файли для редагування та перегляду. У них на більшості вузлів працював QSV, і це працювало. Що підтримувало стабільність — проста практика: кожен релізний кандидат проходив тест ємності, який включав субтитри, масштабування і ті самі кроки деінтерлейсу/тонемапінгу, що використовуються в продакшні.

Одного кварталу базовий образ обновився і підхопив іншу збірку FFmpeg. В юніт-тестах нічого не сигналізувало. «ffmpeg -encoders» все ще показував QSV. Але тест ємності відразу виявив регрес: пропускна здатність впала на 40% під «реальним» навантаженням, і CPU підскочив. Логи показали, що програмне масштабування просочилося, бо апаратний шлях фільтра більше не був доступний в тій конфігурації збірки.

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

Операційний урок: синтетичні тести брешуть. Реалістичні тести брешуть менше. Якщо вам важлива надійність — тестуйте той конвеєр, який ви реально запускаєте, а не той, яким би хотілося.

Поширені помилки: симптом → корінь проблеми → виправлення

1) «Апаратне транскодування увімкнене», але CPU завантажений

Симптом: UI каже апаратне прискорення; CPU досягає 400–1200% під час одного потоку.

Корінь проблеми: Фільтр-стадія на CPU (програмне масштабування, вбудовування субтитрів, тонемапінг) або FFmpeg відкотився через непідтриманий профіль/рівень.

Виправлення: Проаналізуйте реальну FFmpeg-команду/логи і запустіть з verbose, щоб помітити «using software scaling» або fallback кодека. Перенесіть масштабування на апарат, де можливо; уникайте вбудовування субтитрів або попереднього рендеру; обробляйте HDR тонемапінг явно.

2) QSV працює на хості, але не в Docker

Симптом: Тести на хості успішні; логи контейнера показують помилки ініціалізації VAAPI/QSV.

Корінь проблеми: Відсутній user-space драйвер у контейнері або невідповідність груп/прав; іноді несумісні версії libva.

Виправлення: Привʼяжіть /dev/dri до контейнера, переконайтеся, що користувач контейнера має доступ до групи render, і встановіть intel-media-driver + libva всередині образу, сумісні з дистрибутивом.

3) Випадкові помилки транскодингу після оновлення ядра

Симптом: Працювало місяцями; після оновлень ОС деякі задачі помилково завершуються або GPU скидається.

Корінь проблеми: Зміна поведінки i915, зміни прошивки, або несумісні user-space бібліотеки; іноді оновлення BIOS змінює енамерування iGPU.

Виправлення: Ставтеся до цього як до стеку драйверів: фіксуйте версії, де потрібно, перевіряйте на canary-вузлі, і захоплюйте dmesg навколо помилок. Якщо стабільність критична — стандартизувати комбінації ядра+драйверів для флоту.

4) «Чому якість гірша за CPU x264?»

Симптом: Banding у градієнтах, блокування в темних сценах, скарги на «мутність» у швидкому русі.

Корінь проблеми: Занадто агресивний цільовий бітрейт, неправильний режим керування бітрейтом, відсутній 10-бітний шлях або непотрібні перетворення кольорового простору.

Виправлення: Використовуйте режим, схожий на ICQ, де доступний; розгляньте 10-бітний HEVC для сумісних клієнтів; уникайте подвійного масштабування або шифрування кадрів CPU↔GPU. І ще: не порівнюйте налаштований повільний пресет x264 з дефолтними апаратними налаштуваннями і не дивуйтеся результатам.

5) QSV-двигун швидко насичується: «Все було нормально, поки не прийшло троє користувачів»

Симптом: Перші потоки швидкі; потім усі буферяться; intel_gpu_top показує Video ~100%.

Корінь проблеми: Ви досягли ліміту пропускної здатності апаратного двигуна, ускладненого 4K, високою частотою кадрів або дорогими обробками як тонемапінг.

Виправлення: Зменшіть працю на потік (попередньо генеруйте lower-res версії, обмежте частоту кадрів, уникайте тонемапінгу в реальному часі), або масштабуйтесь. Не додавайте CPU-ядра — це не вирішить проблему.

6) Direct play раптом перетворюється на транскод без видимої причини

Симптом: Той самий файл direct-play для одного клієнта, але транскодується для іншого або після невеликого оновлення.

Корінь проблеми: Невідповідність контейнера (кодек, профіль, рівень), несумісний аудіокодек, формат субтитрів або політика клієнта.

Виправлення: Перегляньте media info і можливості клієнтів; віддавайте перевагу стандартним контейнерам/кодекам для вашої аудиторії. Де можливо, адаптуйте бібліотеку, щоб уникати комбінацій, які запускають транскод.

Контрольні списки / покроковий план

Покроково: побудова Linux-хоста з підтримкою QSV (версія для операторів)

1. Підбирайте апаратне забезпечення, яке дійсно має iGPU. Перевіряйте перед покупкою. «F» моделі — поширена пастка.
2. Увімкніть iGPU в BIOS навіть для headless серверів. Підтвердіть, що він перераховується в lspci.
3. Встановіть стек Intel media driver, відповідний до вашого дистрибутива (libva + intel-media-driver/iHD).
4. Підтвердіть VA-API профілі за допомогою vainfo.
5. Підтвердіть, що FFmpeg має QSV (ffmpeg -encoders | grep qsv).
6. Надайте права доступу до пристрою: додайте сервісних користувачів до render (і іноді до video).
7. Запустіть реальний транскод і перевірте з intel_gpu_top.
8. Навантажте тестами з реальним набором фільтрів (субтитри, масштабування, тонемапінг). Збирайте метрики CPU/GPU/диска.
9. Кодизуйте preflight перевірки в провізіонінгу, щоб неконфігуровані вузли не приєднувалися до пулу.

Контрольний список: розгортання контейнера, яке не посоромить

• Змонтируйте /dev/dri в контейнер.
• Запускайте контейнер від користувача, що має доступ до renderD*, або мапуйте додаткові групи.
• Переконайтеся, що образ містить сумісні libva і Intel media driver пакети.
• Фіксуйте образ і катайте оновлення через canary вузол з тестом ємності.
• Логуйте ефективні FFmpeg-командні рядки (і зберігайте їх).

Контрольний список: оптимізація продуктивності без самонанесення шкоди

• Почніть з оптимізації direct play: стратегія кодеків/контейнерів, сумісність аудіо, формати субтитрів.
• Потім переконайтеся, що задіяно апаратний декод + енкод.
• Далі перенесіть масштабування/деінтерлейсинг на апаратні шляхи, якщо CPU високий.
• Тільки потім налаштовуйте енкодерні ручки (режим якості, lookahead, B-кадри).
• Вимірюйте одночасність під реалістичними навантаженнями; не екстраполюйте з одного файлу.

Часті питання

1) Чи Quick Sync — те саме, що «використання iGPU»?

Ні. Quick Sync — це медіа-двигун. iGPU — це пристрій, який його містить. Ви можете мати iGPU для графіки без використання QSV, і ви можете випадково використовувати CPU, маючи QSV.

2) Як дізнатися, що я справді апаратно транскодую?

Два докази важать більше за все: (1) логи FFmpeg показують h264_qsv/hevc_qsv і в декоді, і в енкоді, і (2) intel_gpu_top показує, що Video engine зайнятий під час роботи.

3) Чому вбудовування субтитрів руйнує пропускну здатність?

Тому що рендеринг субтитрів часто виконується на CPU як операція композиції зображення, особливо для зображувальних форматів (як PGS). Це змушує завантаження/вивантаження кадрів або повністю програмний конвеєр.

4) Що краще використовувати у FFmpeg: VAAPI чи QSV?

Обидва можуть працювати. QSV — це специфічний шлях, оптимізований для Intel. VAAPI — більш загальний API. У продакшні оберіть один підхід для середовища, протестуйте ретельно і стандартизуйте — змішані «залежно від випадку» налаштування породжують тікети.

5) Чи підтримує Quick Sync AV1?

Залежить від покоління. Деякі новіші Intel GPU підтримують AV1 декод і/або енкод. Перевіряйте за допомогою vainfo і списків енкодерів FFmpeg на конкретній машині, яку ви збираєтеся використовувати.

6) Що зазвичай лімітує ємність у QSV?

Зазвичай Video engine (пропускна здатність енкоду/декоду) або шлях «VideoEnhance», якщо ви робите важке масштабування/тонемапінг. Іноді пам’ять і пропускна здатність шини стають релевантними при багатьох одночасних 4K потоках.

7) Чому HDR → SDR транскодування так «б’є» по ресурсах?

Тонемапінг обчислювально дорогий і часто відкотиться на CPU, якщо у вас немає повністю прискореного конвеєру. Легко випадково конвертувати піксельні формати так, що змушує програмні фільтри.

8) Чи апаратне кодування завжди гірше за x264/x265?

Не завжди. Для типової стрімінгової роботи QSV може бути відмінним. Але при тому самому бітрейті повільний CPU-енкод часто перемагає на складному контенті. Питання в тому, чи прийнятна якість для вашого SLA і глядачів.

9) Чи можу я запускати headless сервер без монітора і все одно використовувати QSV?

Так, якщо BIOS залишає iGPU увімкненим і ОС завантажує драйвер. Headless — нормальний режим для медіасерверів; помилка — вимикати iGPU, а не відсутність HDMI.

10) Який найшвидший спосіб зменшити навантаження на транскод без чіпання налаштувань QSV?

Збільшіть кількість direct play: віддавайте перевагу H.264 + AAC у широко підтримуваному контейнері для сумісності, уникайте примусового вбудовування субтитрів і тримайте кілька версій для поширених роздільностей.

Практичні наступні кроки

1. Проганяйте перевірку доказів на одному хості: lspci → vainfo → FFmpeg QSV тест → intel_gpu_top. Не рухайтеся далі, поки Video engine не покаже реальну роботу.
2. Аудитуйте ваші реальні конвеєри: чи ви масштабуєте, тонемапите або вбудовуєте субтитри? Визначте, які кроки CPU-залежні, і вирішіть, чи це прийнятно.
3. Стандартизуйте розгортання: фіксуйте драйвери/бібліотеки, кодуйте права доступу до пристроїв і додайте preflight, що відхиляє вузли без /dev/dri/renderD*.
4. Тест ємності з вашими «потворними» кейсами: 4K, HDR, субтитри і ваші типові клієнтські цілі. Легкі файли не оплачують вашу зарплату.
5. Запишіть правила прийняття рішень: коли direct play, коли апаратний транскод, коли відмовлятися (або попередньо генерувати) HDR тонемапінг. Майбутнє-ви подякує сьогоденному-вам.

Quick Sync не прихований тому, що він obscure. Він прихований тому, що легко забути, що найшвидший апарат в коробці — той, який ви не інструментували. Проінструментуйте його, підтвердьте роботу і дайте CPU назад робити CPU-роботу — наприклад вдавати, що йому не жарко.