Тема кодування відео, де ми любимо кодувати

Інструменти для обговорення

Я відновлю тут тему, створену в розділі усунення несправностей, щоб поговорити про HEVC (x265).

• Що таке кодек hevc?

Це кодек, призначений для зменшення розміру відео, зберігаючи якість, еквівалентну AVC (x264). І це за допомогою використання більш складних алгоритмів.
Цей кодек призначений для форматів HD і вище (2k 4k 8k) та високої частоти кадрів.

• Сумісність

Сьогодні більшість сучасних читачів підтримують це. Його велике слабке місце і обчислювальна потужність, необхідна для його декодування, що є більш важливим, ніж x264.
На наших буржуазних машинах проблема відчувається не надто сильно, але на мобільних пристроях або досить старих проблема набагато більш чутлива!

На щастя, що стосується апаратного декодування x264, поступово настає.
-Intel управляє цим з Skylake (трохи раніше при частковій підтримці)
-Amd управляє цим з Carrizo
-Nvidia впорається з цим, але це безлад, а також керує форматом на своєму екранованому планшеті.

Для інших чіпів, особливо ARM, підтримка все ще досить обмежена. Але це буде демократизувати одночасно з логічним джерелом 4k.

• Кому потрібно виконати кодування x265?

В даний час x265 ще трохи молодий як формат для отримання результатів, еквівалентних старим високим бітрейт x264. З іншого боку, він перевершує, коли бітрейт досить низький.
В основному, якщо ви хочете зберегти 1080p відео 1h30 у файлі

4 кадри в секунду повільно
Xeon x5670 (6/[email protected]) ->

7 кадрів в секунду повільно, у віртуальній машині.

• А тепер поговоримо про технічне

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

Мої налаштування досить прості і такі:

ffmpeg -i input.mkv -map 0 -c: v libx265 -встановлений повільний -x265-param "profile = main: CRF = 18" -c: a copy -c: s copy -c: t copy output.mkv

-map 0: бере весь "потік" вхідного файлу

-c: v: для відеопотоків ми застосовуємо такі варіанти
libx265: бібліотека, що використовується для кодування
-повільне попереднє налаштування: див. нижче
-x265-param: параметри, характерні для HEVC, пояснюються нижче

-c: копія: ми копіюємо аудіопотоки
-c: s copy: те саме для субтитрів
-c: t copy: те саме для "вкладених" файлів, таких як шрифти

output.mkv: вихідний файл, ffmpeg автоматично визначає тип файлу відповідно до розширення. Ви також можете вказати його за допомогою опції -f

Пресети
-повільний зарезервований для відео, яке ви хочете заархівувати, інакше перейдіть на середній-> дуже швидкий, в основному достатній, як правило.
-для майже реального часу або кодування для перевірки опцій (наприклад, якості) надшвидких!
-пресети впливають на побітове якість кодування, тому, якщо ви використовуєте CRF для визначення якості, змінюватиметься лише розмір файлу. Якщо ми використовуємо постійний бітрейт (наприклад, 2-прохідне кодування), попередньо встановлений параметр вплине на кінцеву якість відео.
-Нижче економії бітрейту в порівнянні з часом кодування, синім кольором ми бачимо криву x265, три точки внизу ліворуч плацебо/дуже повільно/повільніше. Ми можемо чітко бачити вартість з точки зору часу порівняно з виграшем. Це стає більш розумним із повільним.
Графіка, що показує коефіцієнт часу/стиснення трьох останніх кодеків
Графічний кредит

ХНН
Для еквівалента 23 x264 я приймаю CRF 18 x265. На даний момент x265 не є найуспішнішим з точки зору якості, і це нормально. HEVC швидше розроблений для досить низьких бітрейтів.
Наприклад, великий бойовик у 1080p, кодований зі швидкістю 1 Мбіт/с у x264 та x265, справді виявить інтерес HEVC з точки зору якості. З іншого боку, при> 3 Мбіт/с інтерес обернений, і ми починаємо відчувати, що зерно та деталі більше присутні у x264, ніж у x265.

Для утримання зерна
-що стосується x264: -ці зерна

Профілі
Профілі забезпечують сумісність з апаратними декодерами. Зазвичай прийняті профілі є основними та основними10. Наприклад, для плексу, якщо програвач підтримує апаратне декодування, відео не перекодується.

Інший
Існує безліч інших параметрів для оптимізації ваги або якості кодування. Приклад: параметр keyint, який змінює кількість зображень між двома опорними зображеннями. Більше значення може зменшити розмір файлу, але збільшити час пошуку, це також може порушити сумісність з деякими програвачами. Занадто велике значення не дасть жодного посилення бітрейту.

---