Я читав цю статтю і побачив, що процесор кращий для стиснення відео, ніж GPU.
У статті йдеться лише про те, що це відбувається тому, що процесор може обробляти складніші алгоритми, ніж графічний процесор, але я хочу більш технічного пояснення, я здійснив пошук в Інтернеті, але нічого не знайшов.
Отже, хтось знає, щоб пояснити або пов’язати сайт, щоб у мене було більш глибоке пояснення цього?
Відповіді:
Стаття, яку ви пов’язали, не дуже гарна.
Зазвичай однопрохідні бітрейтові кодування перетворюють ваш бітрейт в значення RF з максимальним обмеженням бітрейта і приймає його звідти.
Контроль швидкості ABR на один прохід x264 не реалізований як обмеження CRF +. Він має рацію, що 2pas - на сьогоднішній день найкращий спосіб досягти цільового бітрейта.
І він, мабуть, не усвідомлює, що він може запустити x264 з ниток = 3 чи чогось, щоб залишити деякий час процесора вільним для інших завдань. Або встановіть пріоритет x264 на дуже низький, так що він отримує лише час процесора, якого не хоче жодна інша задача.
Він також змішує теми = 1 за допомогою CUDA або чогось іншого. Не дивно, що у вас є запитання, адже ця стаття має ГРОМНЕ пояснення. Вся стаття в основному зводиться до: використання x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkvабо, можливо, використання легкої фільтрації за допомогою вхідного сценарію AviSynth. Він фактично рекомендує "плацебо". Це весело. Я ніколи не бачив піратського файлу, закодованого плацебо. (ви можете сказати з me=esaабо me=tesaзамість me=umhусіх пресетів хорошої якості, аж до veryslow.
Він також не згадує про використання 10-бітової глибини кольору. Повільніше кодувати та розшифровувати, але навіть після перетворення на 8 біт, ви покращуєте 8-бітний SSIM. Мабуть, більша точність руху векторів руху допомагає. Також допомагає не округлення до цілого 8-бітного значення. Ви можете думати про 8-бітовий компонент як пробій швидкості; квантування в частотній області, а потім стискання цього за допомогою CABAC означає, що більш високі коефіцієнти глибини біта не повинні займати більше місця.
(BTW, h.265 отримує меншу вигоду від 10-бітових кодувань для 8-бітового відео, оскільки він вже має більшу точність для векторів руху. Якщо є користь від використання 10-бітових x265 для 8-бітових входів відео, це менше, ніж з x264. Так що менше шансів на те, що швидкість покарання буде вартим цього.)
редагувати: doom9 знову знову, тому я налагоджую посилання. Перейдіть до цього для правильного цитування того, хто що сказав.
http://forum.doom9.org/showthread.php?p=1135399#post1135399
google кешує лише тупу версію друку, яка не відображає належним чином цитування. Я не зовсім впевнений, які частини цих повідомлень є цитатами, а які приписуються самій людині.
Вкрай нерегулярні схеми розгалуження (пропускні режими) та бітова маніпуляція (квантування / кодування ентропії) не відповідають сучасним графічним процесорам. IMO - єдиний справді хороший додаток на даний момент - це алгоритми повного пошуку ME, зрештою, хоча прискорений повний пошук все ще повільний, навіть якщо це швидше, ніж на процесорі.
- MfAНасправді, на графічному процесорі все можна розумно зробити, за винятком CABAC (що можна зробити, це просто не можна було паралелізувати).
x264 CUDA спочатку реалізує алгоритм ME fullpel і subpel ME; пізніше ми могли б зробити щось на кшталт RDO з наближенням біт-вартості замість CABAC.
Тому що він повинен робити все з плаваючою точкою з
одною точністю - MfAНеправильно, CUDA підтримує математику з цілим числом.
- Темний Шикарі
Dark Shikari - це сервіс, що підтримує x264, і розробник більшості функцій з 2007 року.
AFAIK, цей проект CUDA не втратив уваги. Існує підтримка використання OpenCL для вивантаження деякої роботи з потоку пошуку (швидке рішення вводу / виводу / B, не остаточне якісне кодування кадру).
Я розумію , що пошуковий простір для кодування відео настільки великий, що розумна евристика для дострокового припинення шляхів пошуку на процесорах обіграє жорстокі графічні процесори, принесені до таблиці, принаймні для кодування високої якості. Це лише порівняно з тим, -preset ultrafastде ви можете розумно вибрати кодування HW через x264, esp. якщо у вас повільний процесор (наприклад, ноутбук з двоядерним процесором і без гіперточення). На швидкому процесорі (i7 чотирьохядерний з гіперточенням) x264 superfast, ймовірно, буде настільки ж швидким, і виглядатиме краще (в той же бітрейт).
Якщо ви робите кодування, де взагалі мають значення спотворення швидкості (якість на розмір файлу), слід використовувати x264 -preset mediumабо повільніше. Якщо ви щось архівуєте, витрачаючи трохи більше часу на процесорі, ви будете економити байти, поки ви зберігаєте цей файл.
бічне зауваження, якщо ви коли-небудь бачите повідомлення з дедретів на відеофорумі, це не буде корисним. Він помиляється з приводу більшості речей, про які він говорить у кожній темі, яку я коли-небудь бачив. Його публікації з'явилися в декількох нитках, які я розглядав щодо кодування GPU x264. Мабуть, він не розуміє, чому це не просто, і кілька разів опублікував, щоб розповісти розробникам x264, чому вони німі ...
Оновлення 2017 року:
ffmpeg підтримує h264 та h265 NVENC GPU-прискорене кодування відео . Ви можете зробити кодування 1-прохідного або 2-прохідного в якості, яке ви вибрали, або для hevc_nvenc або h264_nvenc, або навіть із графічним процесором початкового рівня це набагато швидше, ніж кодування, що не прискорюється, та кодування Intel Quick Sync прискорене.
2-прохідне якісне кодування:
ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4
1-прохідне кодування за замовчуванням:
ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4
Довідка та варіанти NVENC ffmpeg:
ffmpeg -h encoder=nvenc
Використовуйте це, це набагато швидше, ніж кодування процесора.
Якщо у вас немає GPU, ви можете використовувати кодек Intel Quick Sync, h264_qsv, hevc_qsv або mpeg2_qsv, які також набагато швидше, ніж кодування, що не прискорюється.
ffmpegз -vcodec h264_qsvна моїй старій Intel ноутбук з Intel HD 4000 Grpahics зробив рендеринга набагато швидше!
Більш детально зупинитися на тому, що каже Пітер, загалом використання декількох процесорів допомагає у випадках, коли у вас є кілька незалежних завдань, які потрібно виконати, але не мають залежностей один від одного, або одне завдання, коли ви виконуєте те саме математика на масових обсягах даних.
Якщо, однак, вам потрібно вивести обчислення A як вхід обчислення B, а вихід обчислення B як вхід до обчислення C, ви не можете його прискорити, виконавши різну основну роботу над кожним завданням ( A, B або C), оскільки не можна починати, поки інший не закінчиться.
Однак, навіть у вищенаведеному випадку, ви, можливо, зможете паралелізувати це іншим способом. Якщо ви можете розбити вхідні дані на шматки, у вас може бути одна основна робота над виконанням A, потім B, C з одним фрагментом даних, тоді як інше ядро працює над A, потім B, C з іншим фрагментом даних .
Є й інші міркування. Можливо, ви можете знайти спосіб паралельного обчислення, але просто зчитування даних з диска або через мережу, або надсилання їх до GPU займе більше часу, ніж проведення обчислень. У такому випадку паралелізовувати це не має сенсу, оскільки просто отримання даних у пам'ять займає більше часу, ніж час, який ви економите, виконуючи обчислення паралельно.
Іншими словами, це стільки мистецтво, скільки і наука.
-c:v libx264 -preset slower(що не так повільно, як майже в реальному часі для 1920x1080p24 на Skylake i7-6700k.)