Якщо DaVinci Resolve нормально відтворює ваш матеріал у реальному часі, я б узагалі нічого не оптимізував.
Сам по собі H.264, H.265, 4K або навіть RAW ще не означає, що вам обов’язково потрібні proxy. На сучасному залізі багато форматів прекрасно декодуються апаратно. Проблема починається не з назви кодека, а в момент, коли конкретний проєкт перестає нормально працювати.
- Resolve не тримає потрібний фреймрейт;
- мультикам починає сипатися на кількох потоках;
- матеріал лежить на повільному накопичувачі або NAS;
- оригінали з камери займають кілька терабайтів;
- проєкт треба віддати іншому монтажеру;
- потрібно попрацювати з ноутбука без усього масиву оригіналів.
Ось тоді вже є сенс вирішувати, що використовувати: Proxy Media чи Optimized Media.
Для себе я майже завжди дивлюся в бік Proxy Media. Optimized Media використовую значно рідше.
У чому між ними різниця
- Живе всередині проєкту Resolve
- Швидко ввімкнути без окремих кроків
- Не розрахована на перенесення проєкту
- Окремі файли, які видно й можна скопіювати
- Легко перенести на SSD або віддати монтажеру
- Передбачуваний воркфлоу незалежно від машини
Коли я роблю Proxy Media чи Optimized Media
Це найочевидніший сценарій.
Умовно, проєкт займає 3 ТБ. Я не хочу щоразу тягати за собою 3 ТБ оригіналів з камери тільки для того, щоб підправити монтаж.
Створюю proxy, копіюю їх разом із проєктом на SSD і можу працювати з іншої машини.
Повернувся до основної системи — Resolve знову бачить оригінали.
Теж дуже зручно.
Замість передачі всього знімального матеріалу можна віддати:
- Proxy Media;
- звук;
- графіка;
- проєкт Resolve;
- інші потрібні матеріали.
Людина може нормально монтувати, а важкі оригінали з камери залишаються у вас.
Для реклами або великих зйомок це часто набагато логічніше, ніж копіювати кілька терабайтів тільки тому, що монтажеру треба зробити офлайн-монтаж.
Один H.265 може прекрасно грати навіть у 4K.
Вісім таких потоків одночасно — уже інша історія.
У мультикамі я дивлюся не на окремий кодек, а на сумарне навантаження:
- декодування;
- пропускна здатність сховища;
- кількість камер;
- роздільність;
- продуктивність машини.
Якщо система починає задихатися, proxy часто вирішують проблему дуже просто.
Монтувати напряму з ARRIRAW, BRAW або RED RAW можна. Питання лише в тому, чи є в цьому сенс саме на етапі офлайн-монтажу.
Якщо мені для монтажу не потрібна вся інформація з RAW, я краще зроблю компактні proxy й повернуся до оригіналів уже на конформ і колор.
Так менше навантаження на диски, мережу і саму монтажну систему.
Локальний інструмент для одного проєкту
Для мене це більше локальний інструмент.
Наприклад, є проєкт, який я точно нікуди не передаватиму. Кілька кліпів працюють погано або система не витягує їх нормально в реалтаймі.
У такому випадку можна просто Generate Optimized Media і не займатися окремою організацією proxy-файлів.
Це працює.
Але якщо є хоча б шанс, що проєкт переїде на іншу машину або його треба буде комусь передати, я краще відразу зроблю Proxy Media.
Коли не потрібне ні те, ні інше
Я б узагалі починав саме з цього питання.
Не з: «Який кодек краще для proxy?»
А з: «У мене взагалі є проблема?»
Якщо матеріал нормально грає, скраб працює, кадри не губляться, сховище справляється — нічого генерувати не потрібно.
Створювати proxy просто тому, що матеріал у H.265 або має роздільність 4K, сенсу немає.
Особливо зараз, коли сучасні CPU, GPU та SoC мають апаратне декодування для багатьох профілів H.264/H.265.
Proxy — це рішення конкретної проблеми, а не обов’язковий перший етап кожного монтажу.
Які налаштування Proxy Media я використовую
Ось тут якраз найчастіше починається плутанина.
У Resolve нас цікавлять дві речі:
Proxy Media Format
Proxy Media Resolution
Саме вони найбільше впливають на розмір proxy та на те, наскільки легко їх буде відтворювати.
Якщо я хочу максимально передбачуваний монтажний воркфлоу, особливо на Mac, найчастіше вибираю ProRes Proxy.
Це нормальний інтрафрейм-кодек для монтажу. Він легко скрабиться, добре працює з мультикамом і не створює зайвого навантаження на декодер.
Так, файли виходять більшими, ніж H.264 або H.265.
Але це і є компроміс: менше компресії → більше файли → простіше декодування.
Окремо варто сказати: ProRes — нативний кодек Apple. На Mac він декодується дуже ефективно навіть на старих машинах, оскільки це intraframe-формат без складного лонг-геп декодування. На Apple Silicon це додатково прискорюється апаратно, тому ProRes Proxy стабільно тягне навіть слабкі Mac.
Для локального монтажу мене це зазвичай влаштовує.
Якщо потрібен аналогічний воркфлоу із DNxHR, вибираю DNxHR LB.
Для proxy немає великого сенсу використовувати DNxHR HQ або HQX, якщо завдання просто зробити легкі офлайн-файли.
Тут діє той самий принцип, що й із ProRes.
Proxy не повинні намагатися стати другим master.
DNxHR — це кодек, розроблений Avid, і саме він є нативним для Avid Media Composer. Технічно DNxHR працює і на Mac, і на Windows, але на Windows це фактично основний вибір для якісного проміжного/proxy формату, бо Apple прибрала QuickTime для Windows, і нативної підтримки ProRes там немає. А якщо монтаж піде в Avid Media Composer, DNxHR — це стандартний і по суті обов’язковий формат для комфортної роботи в цьому середовищі.
Я не вважаю H.264 або H.265 поганим форматом для proxy.
На сучасному обладнанні вони можуть декодуватися апаратно і працювати абсолютно нормально.
Я використав би їх тоді, коли важливіший саме розмір файлів.
Наприклад:
- передача через інтернет;
- хмарний воркфлоу;
- невеликий зовнішній SSD;
- потрібно швидко передати матеріал іншому монтажеру.
Тут H.265 особливо цікавий, тому що дозволяє отримати дуже компактні файли.
Але якщо в мене важкий мультикам і головне завдання — максимально комфортний реалтайм плейбек, я все одно швидше виберу ProRes Proxy або DNxHR LB.
Не тому, що H.265 «поганий». Просто завдання різні.
Важливий нюанс: апаратне декодування H.264/H.265 добре працює лише на дійсно сучасних машинах із нормальною апаратною підтримкою саме цього кодека. Навіть тоді декодер все одно завантажується, тому що це лонг-геп формат — кожен кадр залежить від сусідніх. Якщо потужності не вистачає (особливо в мультикамі), краще перейти на ProRes Proxy або DNxHR LB вище — вони декодуються простіше і рівномірніше.
Цю штуку бачу регулярно.
Людина робить proxy в ProRes 422 HQ і потім отримує папку гігантського розміру.
Технічно це працює.
Практичного сенсу для звичайного офлайн-монтажу я в цьому майже не бачу.
Якщо фінальний рендер все одно піде з оригіналів з камери, мені не потрібна така якість у робочих proxy.
У більшості випадків ProRes Proxy достатньо.
ProRes 422, 422 HQ або DNxHR HQ мають сенс уже в інших воркфлоу, де ці файли можуть використовуватися як мезонінне медіа або йти далі по постпродакшн-пайплайну.
Але це вже не зовсім класичні proxy.
Яку Proxy Media Resolution використовувати
Оце другий момент, який постійно плутають.
DaVinci Resolve дозволяє вибрати:
- Original;
- Half;
- Quarter;
- Eighth;
- Sixteenth;
- Choose Automatically.
Для UHD-матеріалу Half дає звичайні 1920×1080.
Для монтажу цього мені в більшості випадків більш ніж достатньо.
Я нормально бачу композицію, акторську гру, фокус, рух і дрібні монтажні моменти.
При цьому proxy вже значно легші за 4K оригінали.
Тому для стандартного 4K-проєкту моя базова точка: ProRes Proxy / DNxHR LB + Half Resolution.
Quarter дає приблизно 960×540.
Я б ішов сюди, якщо:
- дуже багато камер;
- слабша монтажна машина;
- proxy треба максимально зменшити;
- матеріал передається через інтернет;
- якість передперегляду не настільки важлива.
Для звичайного рекламного монтажу 540p уже може бути трохи малувато, особливо якщо треба оцінювати фокус або деталі кадру.
Але для чорнового монтажу або великого мультикаму цього може бути цілком достатньо.
Наприклад, якщо взяти 8K і зробити Half, ми отримаємо приблизно 4K proxy.
Для офлайн-монтажу це часто просто зайве.
У такому проєкті я швидше виберу Quarter або Auto.
Тобто я дивлюся не стільки на напис Half / Quarter, скільки на те, яку реальну роздільність отримаю в результаті.
Мені не потрібен 4K proxy просто тому, що камера знімала 8K.
Auto зручний, якщо в одному проєкті змішані різні камери та роздільності.
Наприклад: 4K, 6K, 8K.
У такій ситуації не завжди є сенс ставити однаковий масштаб для всього.
Resolve може сам підібрати адекватну proxy resolution залежно від вихідного матеріалу і таймлайну.
Я все одно люблю розуміти, що саме отримаю на виході, але для великих змішаних проєктів Auto цілком має сенс.
Мої базові налаштування
| Задача | Формат | Роздільність |
|---|---|---|
| Звичайний 4K монтаж | ProRes Proxy / DNxHR LB | Half |
| 6K–8K RAW | ProRes Proxy / DNxHR LB | Quarter / Auto |
| Мультикам | ProRes Proxy / DNxHR LB | Half / Quarter |
| Передача через інтернет | H.264 / H.265 | Half / Quarter |
Proxy Media, Timeline Playback Resolution і Render Cache
Їх часто складають в одну купу, хоча це різні речі.
- Окремі файли на диску, менші за оригінал
- Замінюють camera originals у монтажі
- Resolve просто обробляє таймлайн у нижчій робочій роздільності
- Вмикається й вимикається миттєво, без генерації
- Temporal Noise Reduction, Fusion, важкі OFX, грейд, ефекти швидкості
- Proxy тут не допоможе — гальмує не декодування, а обробка
Що відбувається на фінальному рендері
Proxy я використовую для монтажу.
Master хочу отримувати з оригіналів з камери.
У Deliver DaVinci Resolve має окремі опції використання оптимізованого медіа, proxy media та кешованих зображень.
Тому перед фінальним експортом я завжди перевіряю, з чого саме Resolve буде рендерити.
Якщо proxy зроблені в 1080p H.265 тільки для офлайн-монтажу, немає жодної причини використовувати їх для фінального 4K master.
Після пікчер-лока я повертаюся до оригіналів з камери і вже з них роблю конформ, колор та делівері.
Що в результаті вибрати
А далі вже питання не «який кодек правильний», а що вам важливіше:
Головне, щоб proxy реально робили проєкт легшим.
Якщо після їх створення монтаж працює так само, а на диску просто з’явилося ще пів терабайта файлів, оптимізація пішла кудись не туди.
