В соседнем очень любимом и почитаемом чатике Exitlight развернулась дискуссия про фреймрейты!

🎬Не все в этом чате (а чат вообще-то полон профи!) знают, почему, например, кино — это 24 кадра в секунду, а ТВ во многих странах — 25. Но это еще полбеды, потому что работая в одном стандарте можно и не вдаваться в технические тонкости. Однако как только речь заходит о конвертации фильма для ТВ, вскрывается огромный пласт проблем.

⭕️Смотрите, у нас есть фильм, снятый и смонтированный в стандартные для кино 24 fps. И вдруг появляется задача подготовить мастер для ТВ, которое вещает в 25 fps. Если просто пересчитать фильм, поставив в настройках рендера 25 fps, получится так себе, потому что раз в секунду будет проскакивать статичный кадр. Как быть?

✅Вариант 1 (простой). Пересчитать кино, выставив ему принудительно в настройках клипа фреймрейт равный 25 fps.
Плюсы: быстро.
Минусы: получаем ускорение и небольшой питчинг звука, фильм становится короче.
В принципе это будет не сильно заметно глазу и уху, особенно если поправить питчинг.

✅Вариант 2 (посложнее). Поставить принудительно нужный фреймрейт и пересвести звук со звукорежиссером.
Плюсы: не портится звук.
Минусы: небольшое ускорение видео, возможные трудности со звуком, особенно в длинных сценах и в случаях, где музыка очень четко привязана к картинке, фильм становится короче.

✅Вариант 3 (сложный). Пользоваться различными алгоритмами ретайма.
Плюсы: не меняется звук, сохраняется длина фильма.
Минусы: долго, ресурсоемко, возможны артефакты из-за ретайма.

Ни один вариант не без минусов, так что смотреть нужно по ресурсам и обстоятельствам. Чаще всего работает первый вариант, иногда — второй. Третий вариант используется крайне редко (и это замечательно).

➡️Если нужно подготовить мастер, снятый и смонтированный в 25 fps под стандарты кино, то возможные алгоритмы точно такие же. Ну, разве что теперь материал не ускоряется, а замедляется, а при ретайме видео нам нужно не дорисовывать дополнительный кадр каждую секунду, а прятать.

Такие дела.

Кстати, если у вас есть какие-то пожелания и предложения по контенту на канале — не стесняйтесь писать комментарии!

#ретайм #фреймрейт

🎬Продолжаем обсуждение воркфлоу и проблем, связанных с ним.

Часть 1 можно прочитать по ссылке.

Часть 2. Кодеки: intermediate vs. delivery.

Конечно, когда мы работаем сами для себя, делаем видосики для бабушки и влоги на ютуб, то редко перед нами встает вопрос об использовании какого-то единого кодека для всех файлов, и монтажеры чаще всего никак не адаптируют исходники. Когда речь заходит о сколько-нибудь серьезном проекте, так делать не стоит (но, по моему опыту, так делают примерно все).

😡Почему вообще это проблема?
Дело в том, что при работе с видео, пришедшими к нам, например, в .mp4/h.264, мы имеем дело с межкадровым сжатием, которое серьезно нагружает процессор. А если исходники длинные, да еще и сильно пережатые, например, часовой ролик с ютуба, из которого мы хотим вырезать пару секунд, то даже очень мощная машина может задуматься на полминуты при перетаскивании плейхэда. Эта проблема как раз и возникает из-за межкадрового сжатия.

Если немного углубиться в техническую сторону, в таких файлах значительная часть кадров (B-frames, P-frames) отрисовывается не просто так, а через экстраполяцию специальным алгоритмом из другого, «настоящего» кадра (I-frame). Кадры выстраиваются в последовательность типа IBBPBBPBBPBBI, это называется GOP — group of pictures. Чем длиннее эта последовательность, тем тяжелее процессору и тем больше времени занимает рендер каждого кадра. А чем больше у вас таких исходников на таймлинии, тем хуже ваш проект ворочается.

⚠️Иногда наличие сильно пережатых исходников с внутрикадровым сжатием приводит к выпадающим кадрам на рендере.

🤔А что там с интер... как ты там это называешь?
Intermediate-кодеки, они же монтажные, не имеют межкадрового сжатия, в них используется только внутрикадровое, что позволяет проигрывать такие исходники без проблем даже на самых слабых компьютерах, лишь бы хватило скорости диска. Процессор почти не загружается, благодать. Платим мы за такое удовольствие временем на пересчет исходников и свободным местом (да, файлы в монтажном кодеке весят очень много). Чаще всего для монтажа исходники пересчитывают в ProRes или в DNx.

👻Темная сторона нашего сегодняшнего текста — delivery-кодеки, то есть кодеки для «доставки клиенту». Это как раз упомянутый выше h.264, более новый h.265 и все прочие h., да и в принципе это практически все то, что уходит после рендера на размещение в интернет или на ТВ, но конечно чаще всего средний монтажер считает именно .mp4/h.264. Нет, не то, чтобы эти кодеки были чем-то хуже, просто у них иное предназначение, нежели попадать под нож монтажера.

✅Давайте закрепим:

Intermediate-кодеки — это хорошо, потому что монтировать можно на любом калькуляторе, но вот места на диске понадобится довольно много.

Delivery-кодеки — это тоже хорошо, но не для монтажа, потому что хоть места такие файлы займут немного, а процессор будет уставать.

Если проект долгий, пересчет исходников в intermediate-кодек сэкономит вам очень много времени в будущем. Возьмите за правило кодировать все, с чем работаете, в монтажный кодек!

#воркфлоу

🎬А вот и третья часть большой темы по воркфлоу!

Мы уже рассмотрели информацию о кодеках, и не единожды, а дважды. Сегодня хочу подробнее рассказать о компрессии изображения.

Часть 3. Компрессия изображения.

✅Из названия в целом все понятно: изображение сжимается, что помогает экономить место на диске. С компрессией мы сталкиваемся ежедневно, взять хотя бы .rar и .zip архивы, .jpeg и другие зашакаленные картинки. Из предыдущих постов мы еще и про компрессию видео узнали! Теперь нам понятно, почему компрессия — не всегда благо, ведь в случае с тем же .mp4/h.264 при сильной экономии места мы получаем худшее качество (артефакты сжатия), для декодирования требуется большая вычислительная мощность. Давайте залезем в теорию поглубже, мне кажется, это будет полезным и лучше поможет понять, как вообще работает сжатие. Всего существует два вида компрессии: с потерями и без потерь, или lossy и lossless по-английски.

Параграф 1.
Lossy compression, то есть сжатие с потерями.

Файлы, прошедшие через алгоритмы lossy, невозможно восстановить в исходном качестве: пережатый джипег не станет исходной хайрезной фотографией. Но здесь нужно ответить себе на вопрос, зачем мы пользуемся именно lossy-алгоритмами в случае с конкретным видео?

1. Если видео не предполагает дальнейшей обработки, и мы предоставляем его как финальный результат, то lossy нам будет достаточно (но есть нюанс со степенью сжатия, чуть ниже расскажу).

2. Если с видео будет работать кто-то после нас, например ротоскопер/колорист/композер, то сжатие с потерями — не наш выбор. Специалистам в пайплайне почти всегда необходимы исходники с минимальными потерями или вообще без них.

Степень сжатия lossy-алгоритмами

Википедия добродушно подсказывает, что

очень сильная компрессия видео (порядка 100:1) практически незаметна глазу;
сильная компрессия аудио (10:1) не приводит к субъективной потере качества звука;
сильная компрессия статичных картинок (10:1) заметна при скрупулезном рассмотрении.

Разумеется, это ориентировочные показатели, потому что сжатие видео или фото с зеленой листвой с таким соотношением приведет к серьезным видимым артефактам. То же самое можно сказать про плавные световые и цветовые градиенты, которые при сжатии приводят к так называемому бандингу (мерзким широким полоскам😡).

➡️Если говорить понятным всем монтажерам языком, то результат вывода HD-видео с разрешением 1920x1080 в .mp4/h.264 с битрейтом 1 Мб/с выглядит плохо, а вот если битрейт поднять до 20 Мб/с, то вполне себе неплохая картинка получается, не видно никаких артефактов.

✅Вывод: если клиент должен получить результат в lossy-кодеке («давай эмпэчетыре тяжелую»), то постарайтесь избежать артефактов высоким битрейтом. А если есть строгая верхняя граница битрейта, то клиенту стоит быть готовым к артефактам. Впрочем, даже с низким битрейтом можно частично избежать видимых артефактов, но это уже другая история, которую я обязательно расскажу в грядущих постах!

#воркфлоу #компрессия

Смотрите, сделал тест по бандингу, чтобы было понятнее, чем lossy и сильная компрессия могут быть опасны. Это простой статичный линейный градиент на 5 секунд.

Тут 4 картинки:

1. Экспорт стилла из Premiere с таймлайна
2. Стилл из отрендеренного файла в 10 Мб/с
3. Первый кадр из отрендеренного файла в 1 Мб/с
3. Двадцать шестой кадр из отрендеренного файла в 1 Мб/с

Последние два кадра взяты из одного и того же рендера, но при переходе с 25 на 26 кадр происходит резкий скачок. Это связано с низким битрейтом и длиной GOP, которую Premiere выставляет автоматически. На видео видно, что таких скачков несколько.

🎬Продолжим разговаривать про воркфлоу в целом и про компрессию изображения в частности, первая половина текста была выше.

Часть 3. Компрессия изображения.

Параграф 2.
Lossless compression, то есть сжатие без потерь.

В отличие от lossy-компрессии, lossless-алгоритмы позволяют восстановить информацию исходного файла. То есть используется обратимое сжатие. Хитрые алгоритмы позволяют сократить используемое дисковое пространство, за что мы обычно платим потерей производительности при воспроизведении или обработке.

⚠️Здесь нужно понимать, зачем нам такое сжатие, потому что при доставке готового рендера клиенту lossless-кодеки практически никогда не используются, во всяком случае в видео. Обычно lossless-алгоритмами пользуются при передаче секвенций на композ (здесь нам помогает уже знакомый .exr) или при сдаче важных рендеров в архив. То есть в воркфлоу мы пользуемся сжатием без потерь только как intermediate-кодеком для передачи между департаментами.

А что у нас по lossy- и lossless-кодекам?

✅На самом деле проще начать с lossless. Применительно к нашей работе нам интересны:

a) Статичные изображения/секвенции:

OpenEXR (.exr) с некоторыми алгоритмами сжатия: Zip, PIZ и RLE
PNG (.png)
JPEG (.jpg) с RLE-алгоритмом сжатия
JPEG 2000 (его мы чаще видим как Motion JPEG 2000 в составе контейнеров MXF_OP1a или DCP)
TARGA (.tga) с RLE-алгоритмом сжатия
TIFF (.tiff) с LZW-алгоритмом сжатия

b) Видеокодеки:

h.264/h.265 lossless (не встречал в работе)
VP9 (это кодек в основном для Youtube)

✅С lossy все проще: это почти все остальное, что не перечислено выше :) Исключение составляют только non-compression-кодеки вроде Avid DNxUncompressed или YUV 4:4:4, но они используются крайне редко, поскольку имеют более компактную по занимаемому месту lossless-альтернативу.

На этом я заканчиваю свой TED-talk, если остались вопросы, можете задать их в комментариях, а впереди нас ждет еще несколько интересных и важных тем, посвященных рабочему процессу!

#воркфлоу #компрессия

🎬Мы уже много чего обсудили по тэгу #воркфлоу, настало время поговорить про битность цвета, она же bit depth.

Это что такое?

➡️Мы каждый день видим разные изображения на экранах. Обычно нас при этом ничего не смущает, потому что современные устройства передают цвета так, что мы не замечаем разницы между изображением объекта и тем, как он выглядел бы в жизни. Градации цвета передаются довольно точно. Раньше было иначе, но наше воображение помогало представить в цвете монохромную картинку на Nokia 3310. Отличие экранов старых кнопочных телефонов от современных смартфонов в том, что у последних выше битность. Говоря простым языком, чем выше битность, тем лучше, тем больше оттенков цвета мы видим на картинке.

А теперь языком посложнее.

✅Бит — наименьшая единица информации, принимает значения 0 или 1, то есть «отсутствие информации» или «наличие информации». Следовательно, однобитное изображение будет иметь количество цветов равное 2¹, то есть количество значений, которое может принимать бит, возведенное в степень битности, всего 2 цвета. Это либо черный и белый (запустите командную строку в Windows, например), либо черный и зеленый, либо любые другие два оттенка. Если изображение двухбитное, то количество оттенков будет 2² = 4. А если трехбитное? Правильно! 2³ = 8, ну вы поняли. Исторически самые используемые битности это 1, 8, 24, 30.

Теперь ближе к монтажу и цветокоррекции.

➡️Сегодня большинство потребительских устройств отображает цвета в режиме 24 бит, то есть по 8 бит на каждый цветовой канал R, G и B (чаще всего используется именно RGB-модель, но не всегда).
2²⁴ = 16 777 216 оттенков.

В чем тут проблема?

⚠️Дело в том, что современные видеокамеры записывают видео с большей битностью, обычно 10, 12 или 16 бит на канал. Эти оттенки не отображаются корректно на 24-битных мониторах, потому что матрица дисплея не способна воспроизвести нужный оттенок. Для этого существуют более дорогие мониторы, в основном, конечно, для специалистов по работе с цветом. Битность таких мониторов на канал — 10 или 12. Но здесь мы ступаем на скользкую дорожку HDR, пока не будем об этом. Вернемся в мир монтажа.

✅При этом даже если наш монитор не способен отобразить цвета в 10 битах на канал, показывая лишь 8, мы легко можем запороть материал с высокой битностью, передавая его по пайплайну другим специалистам. В Premiere Pro реализован немного дурацкий алгоритм кодирования ProRes, поэтому критически важно нажимать галку Render at Maximum Depth и ставить там 16-bpc, а также ставить галку Use Maximum Render Quality. Про 16 бит на канал Premiere Pro немного лукавит, но самое главное, что так мы не потеряем в битности, а материал останется гибким при работе с цветом после нашего рендера. Стоит заметить, что это беда и многолетняя недоработка Adobe, а в том же DaVinci Resolve такой проблемы нет, там битность сохраняется в соответствии со спецификацией кодеков.

Также хочу отметить два важных момента:

- когда мы говорим «10 бит на канал», то это то же самое, что сказать «30-битное изображение», потому что мы подразумеваем, что наше RGB изображение складывается из трех цветовых каналов, у каждого из которых битность равна 10. 10 + 10 + 10 = 30;

- но не всегда это так :) Ведь при добавлении альфа-канала «10 бит на канал» превращаются в «40-битное изображение», потому что теперь у нас 4 канала: R, G, B и альфа-канал a. 10 + 10 + 10 + 10 = 40.

🎬Если резюмировать, то старайтесь обращать внимание на битность исходников, а при передаче материалов дальше по пайплайну не забывайте нажимать нужные галки, особенно в Premiere Pro :)

#воркфлоу

И то же самое отправлю файлами, чтобы телеграм не улучшал без спроса качество зашакаленных картинок :)