Серверне рішення для кодування відео з використанням вбудованого відео Intel HD Graphics

    
У попередній статті йшлося про кодування відео з використанням технології Intel Quick Sync на сучасних процесорах Intel і про той досвід, який ми отримали в процесі інтеграції цієї технології в наш софт. Цього разу я розповім про те, як ми створювали серверне рішення, про проблеми, з якими зіткнулися, а також про продуктивність нашого рішення на серверних процесорах Intel. Користуючись нагодою, хочу подякувати наших колег з Intel за оперативну допомогу в процесі інтеграції Intel Quick Sync в наш софт.
 
 

Тестування

Для тестування нашого ПЗ був обраний 1U сервер в такій конфігурації:
              
M / B Supermicro X10SLH-F
Процесор Intel ® Xeon ® CPU E3-1225 v3@3.20GHz
Пам'ять 16 Гб
Версія OS на сервері Ubuntu 12.04.4 LTS 3.8.0-23-generic. Головною умовою роботи Quick Sync є наявність рядка С226 в специфікації чіпсета. Тільки чіпи з таким маркуванням вміють працювати з апаратним кодуванням відео. Крім цього, бажано відсутність вбудованого відео на материнській платі, в іншому випадку можуть виникнути проблеми з визначенням, а значить, і використанням Intel GPU засобами Intel Media SDK.
Материнська плата, описана вище, має інтегровану графіком (вбудоване відео) на борту, і нам довелося повозитися для того, що б змусити працювати SDK на цьому залозі. При установці SDK на новий сервер скрипт установки Media SDK не побачив ID пристрою. При цьому, нам не вдалося включити вбудовану в процесор графіком з BIOS. Пошук рішення привів до необхідності оновити BIOS. Після цього в BIOS з'явився заповітний пункт. Однак, довелося ще відключити вбудоване на материнській платі відео шляхом перемикання перемички. У такій конфігурації не працює IPMI і вихід на монітор, але ми працюємо з сервером через SSH і це не так критично.
Крім цього, є деякі обмеження на використовуване в системі ядро ​​Linux. Для серверів це Ubuntu 12.04 LTS з ядрами 3.2.0-41 і 3.8.0-23 або SUSE Linux Enterprise Server 11 з ядром SP3 3.0.76-11.
 
Також ми оптимізували механізм передачі сирих фреймів у нашому конвеєрі, використовуючи нативний тип пам'яті SDK, що збільшило продуктивність і дало можливість вичавити з заліза максимум швидкості. При цьому передається лише вказівник на поверхню і не відбувається фізичного копіювання пам'яті по конвеєру.
 
В якості тестового ролика виступало відео 1920x800, H264, тривалістю 12 хвилин. Вихідна відео: 1920x800, high, H264, 8Мб / с. У разі ffmpeg параметри були за замовчуванням (profile high). Тестова утиліта з Intel Media SDK sample_full_transcode також кодувала з параметрами за замовчуванням (profile high). Streambuilder з підтримкою QuickSync кодував з наступними параметрами: profile high, RateControlMethod cbr, level avc 4.2. Параметр target usage (впливає на якість / швидкість кодування) у всіх випадках balanced.
Результати тестів ілюструє наступна таблиця.
 
 Процесор: E3-1225 V3, 16 Гб ОЗУ, Intel ® HD Graphics P4600
                                                          
ffmpeg sample_full_transcode streambuilder (no optimization) streambuilder (optimization)
time 8 хв. 42 з 1 хв. 19 з 2 мін.19 з 1 хв. 40 з
cpu (max) 750% 55% 125% 50%
mem (max) 3,3% 4,6% 0.5% 0.4%
PSNR 48,107 46,68
Average PSNR 51,204 49,52
SSIM 0,99934 0,9956
MSE 1,623 2,969
 Процесор: I7-3770, 3 Гб ОЗУ, Intel ® HD Graphics 4000
                                                          
ffmpeg sample_full_transcode streambuilder (no optimization) streambuilder (optimization)
time 8 хв. 48 з 1 хв. 24 з 2 хв. 31 з 1 хв. 23 з
cpu (max) 750% 19% 150% 45%
mem (max) 18% 20% 2.8% 2.3%
PSNR 48,107 46,495
Average PSNR 51,204 49,27
SSIM 0,99934 0,991
MSE 1,623 3,036
 Процесор E3-1285 v3, 16 Гб, Intel ® HD Graphics P4700
                                                          
ffmpeg sample_full_transcode streambuilder (no optimization) streambuilder (optimization)
time 8 хв. 1 з 1 хв. 11 з 2 хв. 11 з 1 хв. 34 з
cpu (max) 750% 55% 130% 55%
mem (max) 3,3% 4,6% 0.5% 0,4%
PSNR 48,107 46,68
Average PSNR 51,204 49,52
SSIM 0,99934 0,9956
MSE 1,623 2,969
 

Аналіз результатів

Метрики для streambuilder відповідають отриманим метрикам для тестової утиліти sample_full_transcode і я їх опустив.
З цих таблиць видно, що серверні процесори з Intel ® HD Graphics P4700/P4600 в даному експерименті працюють швидше і дають кращу якість кодування, ніж I7-3770, Intel ® HD Graphics 4000. Однак ця теза не завжди вірний, так як Intel вдосконалює якість кодування з кожною новою версією чіпа і SDK і швидкість на нових чіпах може бути менше. При цьому навантаження на CPU у першому трохи більше. З чим це пов'язано, поки незрозуміло.
Крім цього, оптимізація роботи з пам'яттю дала приріст приблизно в 2 рази в плані продуктивності.
 
Якість кодування на Intel ® HD Graphics P4700 вийшло таким же, як і на Intel ® HD Graphics P4600, але E3-1285 v3 працює швидше приблизно на 14% при тій же завантаженні ресурсів. Крім цього, E3-1285 v3 швидше E3-1225 V3 в кодуванні за допомогою ffmpeg приблизно на 10%.
Сервер з встановленим streambuilder з підтримкою Quick Sync дозволяє кодувати одне джерело в 12 якостей Full HD (1080p), 24 якості HD (720p) і 46 якостей SD (480p) з нарізкою в HLS. Якщо це з'їм «сирого» сигналу з SDI, то число одночасно кодованих якостей трохи більше.
Поекспериментувати зі streambuilder (поки тільки libavcodec based версія) можна скачавши його звідси . З ним в комплекті йде стандартний конфіг, що дозволяє записувати в формат HLS будь-яке джерело.
 
 

Підсумки

Технологія Intel Quick Sync дозволяє зібрати порівняно недорогий продуктивний сервер для кодування відео з прийнятною якістю. У процесі впровадження цієї технології ми зіткнулися з деякими технічними проблемами, пов'язаними з наявністю інтегрованого в материнську плату відео, які, втім цілком вирішувані. (Нагадаємо, головне при виборі заліза для цих цілей — це чіп зі специфікацією С226 і материнська плата без інтегрованого відео, так як з ним може не працювати IPMI і VGA вихід).
Плюси такого рішення, на мій погляд, це те, що майже не задіяний CPU, а також невелике споживання пам'яті. При цьому, вільні ресурси можна використовувати для інших завдань або для кодування засобами CPU.
 
У найближчих планах у нас погратися з VPP (video post processing = постобробка відео) функціями Intel Media SDK (denoise, crop, resize, frame rate conversion, deinterlacing і т.д.). Поки ми реалізували crop, resize і deinterlacing, і ці операції виконуються так само швидше, ніж їх чисто програмні аналоги. У Intel Media SDK досить багато параметрів кодування, і ми продовжуємо робити тести і порівнювати з нашим профайламі. Про результати експериментів з VPP, продуктивністю / якістю і порівнянні 2-pass кодування ffmpeg/h264 з технологією LookAhead Intel HD Graphics, я думаю, ми ще напишемо.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.