Mind the framerate!
😡Часто замечаю в видео проблему с фреймрейтом. Обычно в любительских влогах, но иногда попадается и в рекламе или в других коммерческих видео. В чем суть проблемы?
🎬Когда в секвенции, созданной, скажем, в 25 кадров в секунду (fps) используют исходники, снятые в 30 fps, то каждую секунду из этого 30 fps клипа выбрасываются 5 кадров (dropframe). Как это выглядит на практике? Любое движение в кадре происходит с рывками от одного до нескольких раз в секунду, что сильно бьет по глазам (иногда это проблема ретайма, но мы не о нем сейчас).
✅Бороться с этим легко, если клипы, которые используются в монтаже, не привязаны к синхронному звуку. Например, вы сняли влог, и у вас там едут машины/летят птицы/ходят люди. Достаточно просто в настройках исходника изменить фреймрейт на тот, который стоит в секвенции. Такие клипы будут чуть медленнее (в случае перевода из большего фреймрейта в меньший), но зато не будет богомерзких дерганий.
⭕️Другой вариант: вы сняли интервью с двух камер, одна из которых записывала видео в 25 fps, а другая — в 30. С синхронным звуком проблем будет больше, потому что просто так растянуть/сжать звук не получится, будут искажения. Тут проще переснять, правда. Или пользоваться костылем вроде ретайма видео с включенным optical flow, но вот результаты могут не устроить.
✅Алгоритм перевода исходников с неправильным фреймрейтом в правильный простой. Разберем на примере секвенции в 25 fps:
Вот и все! Не забывайте снимать в правильном фреймрейте!
#fps
😡Часто замечаю в видео проблему с фреймрейтом. Обычно в любительских влогах, но иногда попадается и в рекламе или в других коммерческих видео. В чем суть проблемы?
🎬Когда в секвенции, созданной, скажем, в 25 кадров в секунду (fps) используют исходники, снятые в 30 fps, то каждую секунду из этого 30 fps клипа выбрасываются 5 кадров (dropframe). Как это выглядит на практике? Любое движение в кадре происходит с рывками от одного до нескольких раз в секунду, что сильно бьет по глазам (иногда это проблема ретайма, но мы не о нем сейчас).
✅Бороться с этим легко, если клипы, которые используются в монтаже, не привязаны к синхронному звуку. Например, вы сняли влог, и у вас там едут машины/летят птицы/ходят люди. Достаточно просто в настройках исходника изменить фреймрейт на тот, который стоит в секвенции. Такие клипы будут чуть медленнее (в случае перевода из большего фреймрейта в меньший), но зато не будет богомерзких дерганий.
⭕️Другой вариант: вы сняли интервью с двух камер, одна из которых записывала видео в 25 fps, а другая — в 30. С синхронным звуком проблем будет больше, потому что просто так растянуть/сжать звук не получится, будут искажения. Тут проще переснять, правда. Или пользоваться костылем вроде ретайма видео с включенным optical flow, но вот результаты могут не устроить.
✅Алгоритм перевода исходников с неправильным фреймрейтом в правильный простой. Разберем на примере секвенции в 25 fps:
23,976 -> 25✅Кратные значения вроде 50 и 100 не трогаем (ну или разворачиваем до 25 fps, чтобы получить замедление, если необходимо), потому что количество выкинутых кадров за каждый кадр видео будет одинаковым, то есть наши глаза не увидят никаких скачков. Несложно посчитать, насколько сильно замедляется или ускоряется видео в каждом случае, но повторюсь: если нет синхронизации со звуком, то это не так и важно.
24 -> 25
29,97 -> 25
30 -> 25
50 -> 50
60 -> 50
100 -> 100
120 -> 125
Вот и все! Не забывайте снимать в правильном фреймрейте!
#fps
❤2🔥1
Ну и как обойти стороной воркфлоу!
🎬Вкратце, это процесс, когда мы передаем файлы из одного софта в другой. Что тут может пойти не так? Как показывает практика, все что угодно.
Часть 1. Кодек/контейнер.
Многие монтажеры (и не только они, а вообще все специалисты в пайплайне) не знают, что необходимо перегонять все материалы, идущие дальше по департаментам, в какой-то заранее оговоренный кодек. И передавать в нужном кодеке дальше. Иначе получается перебрасывание .mp4/h264 из монтажа на цветокоррекцию, либо попытка запихнуть в Nuke .mp4 или еще что похуже.
😡Даже когда софт позволяет принимать такие файлы, не стоит необдуманно отдавать свои рендеры в чем попало, ведь кроме того, что может постоянно падать софт (вы пробовали красить h264 вообще?), можно по глупости потерять в качестве, битности, либо вообще передать материалы не в той гамме.
✅Избегайте этого, и, если не уверены (а с той стороны ничего не предлагают) отдавайте (с кучей допущений) ProRes 422HQ с максимальной битностью. В 90% случаев это покроет потребности всего пайплайна в несложных проектах.
➡️Наиболее частые варианты кодеков и контейнеров в пайплайне:
Продолжение следует! В будущих постах расскажу про другие проблемы с пайплайном. Если ничего не поняли — не страшно, я планирую записать серию видео про воркфлоу и пайплайн, там все расскажу подробнее и с примерами!
#воркфлоу
🎬Вкратце, это процесс, когда мы передаем файлы из одного софта в другой. Что тут может пойти не так? Как показывает практика, все что угодно.
Часть 1. Кодек/контейнер.
Многие монтажеры (и не только они, а вообще все специалисты в пайплайне) не знают, что необходимо перегонять все материалы, идущие дальше по департаментам, в какой-то заранее оговоренный кодек. И передавать в нужном кодеке дальше. Иначе получается перебрасывание .mp4/h264 из монтажа на цветокоррекцию, либо попытка запихнуть в Nuke .mp4 или еще что похуже.
😡Даже когда софт позволяет принимать такие файлы, не стоит необдуманно отдавать свои рендеры в чем попало, ведь кроме того, что может постоянно падать софт (вы пробовали красить h264 вообще?), можно по глупости потерять в качестве, битности, либо вообще передать материалы не в той гамме.
✅Избегайте этого, и, если не уверены (а с той стороны ничего не предлагают) отдавайте (с кучей допущений) ProRes 422HQ с максимальной битностью. В 90% случаев это покроет потребности всего пайплайна в несложных проектах.
➡️Наиболее частые варианты кодеков и контейнеров в пайплайне:
Монтаж✅Очень простое правило: внутри поста используем intermediate-кодеки, а отдавая готовые монтажи на площадку — delivery-кодеки.
ProRes 422 proxy и DNxHD 8 bit для прокси, ProRes 422HQ для чистового монтажа
Цветокоррекция
Исходники (желательно) либо ProRes 4444XQ на входе, ProRes 4444XQ или вариации DNx на выходе
Композитинг
.exr (piz/zip), .tiff, ProRes 422HQ/4444 на входе и то же самое на выходе.
Продолжение следует! В будущих постах расскажу про другие проблемы с пайплайном. Если ничего не поняли — не страшно, я планирую записать серию видео про воркфлоу и пайплайн, там все расскажу подробнее и с примерами!
#воркфлоу
👍1🔥1
Постоянная рубрика (с сегодняшнего дня) #киновечер
🎬Закончили смотреть третий сезон шведско-датского «Моста». Это по современным меркам уже довольно старый сериал в стиле всеми нами любимого скандинавского нуара: маньяки, методично разделывающие мирных жителей двух преуспевающих государств, против полицейских, расследующих эту не вполне законную расчлененку.
😍Третий сезон снят, как мне показалось, сильно лучше в техническом плане, чем первые два, постановка стала еще качественнее, каждый предмет в кадре стоит на своем месте, глаза отдыхают. Актеры играют замечательно — в общем, просто песня!
✅Цветокоррекция в сериале болезненно-зеленоватая в хайлайтах, это весьма в тему и тоже не режет глаз (равно как и в последнем «Безумном Максе» желто-оранжевый ЦК вообще не напрягает). Монтаж очень классный (только в паре мест сцены с погонями показались недожатыми), руки и головы актеров на каждой склейке оказываются на том же месте, где были до этого (тут моя знакомая Оля Артемьева, будучи режиссером, рассказала, что в западной традиции принято заставлять актеров заучивать все движения в кадре синхронно с речью, поэтому тут, возможно, тот же эффект).
В общем, классный сериал, посмотрите!
P.S. Извините, что прикрепляю скриншоты файлами, а не фотографиями, просто иначе сильно шакалится изображение.
🎬Закончили смотреть третий сезон шведско-датского «Моста». Это по современным меркам уже довольно старый сериал в стиле всеми нами любимого скандинавского нуара: маньяки, методично разделывающие мирных жителей двух преуспевающих государств, против полицейских, расследующих эту не вполне законную расчлененку.
😍Третий сезон снят, как мне показалось, сильно лучше в техническом плане, чем первые два, постановка стала еще качественнее, каждый предмет в кадре стоит на своем месте, глаза отдыхают. Актеры играют замечательно — в общем, просто песня!
✅Цветокоррекция в сериале болезненно-зеленоватая в хайлайтах, это весьма в тему и тоже не режет глаз (равно как и в последнем «Безумном Максе» желто-оранжевый ЦК вообще не напрягает). Монтаж очень классный (только в паре мест сцены с погонями показались недожатыми), руки и головы актеров на каждой склейке оказываются на том же месте, где были до этого (тут моя знакомая Оля Артемьева, будучи режиссером, рассказала, что в западной традиции принято заставлять актеров заучивать все движения в кадре синхронно с речью, поэтому тут, возможно, тот же эффект).
В общем, классный сериал, посмотрите!
P.S. Извините, что прикрепляю скриншоты файлами, а не фотографиями, просто иначе сильно шакалится изображение.
❤1
В соседнем очень любимом и почитаемом чатике Exitlight развернулась дискуссия про фреймрейты!
🎬Не все в этом чате (а чат вообще-то полон профи!) знают, почему, например, кино — это 24 кадра в секунду, а ТВ во многих странах — 25. Но это еще полбеды, потому что работая в одном стандарте можно и не вдаваться в технические тонкости. Однако как только речь заходит о конвертации фильма для ТВ, вскрывается огромный пласт проблем.
⭕️Смотрите, у нас есть фильм, снятый и смонтированный в стандартные для кино 24 fps. И вдруг появляется задача подготовить мастер для ТВ, которое вещает в 25 fps. Если просто пересчитать фильм, поставив в настройках рендера 25 fps, получится так себе, потому что раз в секунду будет проскакивать статичный кадр. Как быть?
✅Вариант 1 (простой). Пересчитать кино, выставив ему принудительно в настройках клипа фреймрейт равный 25 fps.
Плюсы: быстро.
Минусы: получаем ускорение и небольшой питчинг звука, фильм становится короче.
В принципе это будет не сильно заметно глазу и уху, особенно если поправить питчинг.
✅Вариант 2 (посложнее). Поставить принудительно нужный фреймрейт и пересвести звук со звукорежиссером.
Плюсы: не портится звук.
Минусы: небольшое ускорение видео, возможные трудности со звуком, особенно в длинных сценах и в случаях, где музыка очень четко привязана к картинке, фильм становится короче.
✅Вариант 3 (сложный). Пользоваться различными алгоритмами ретайма.
Плюсы: не меняется звук, сохраняется длина фильма.
Минусы: долго, ресурсоемко, возможны артефакты из-за ретайма.
Ни один вариант не без минусов, так что смотреть нужно по ресурсам и обстоятельствам. Чаще всего работает первый вариант, иногда — второй. Третий вариант используется крайне редко (и это замечательно).
➡️Если нужно подготовить мастер, снятый и смонтированный в 25 fps под стандарты кино, то возможные алгоритмы точно такие же. Ну, разве что теперь материал не ускоряется, а замедляется, а при ретайме видео нам нужно не дорисовывать дополнительный кадр каждую секунду, а прятать.
Такие дела.
Кстати, если у вас есть какие-то пожелания и предложения по контенту на канале — не стесняйтесь писать комментарии!
#ретайм #фреймрейт
🎬Не все в этом чате (а чат вообще-то полон профи!) знают, почему, например, кино — это 24 кадра в секунду, а ТВ во многих странах — 25. Но это еще полбеды, потому что работая в одном стандарте можно и не вдаваться в технические тонкости. Однако как только речь заходит о конвертации фильма для ТВ, вскрывается огромный пласт проблем.
⭕️Смотрите, у нас есть фильм, снятый и смонтированный в стандартные для кино 24 fps. И вдруг появляется задача подготовить мастер для ТВ, которое вещает в 25 fps. Если просто пересчитать фильм, поставив в настройках рендера 25 fps, получится так себе, потому что раз в секунду будет проскакивать статичный кадр. Как быть?
✅Вариант 1 (простой). Пересчитать кино, выставив ему принудительно в настройках клипа фреймрейт равный 25 fps.
Плюсы: быстро.
Минусы: получаем ускорение и небольшой питчинг звука, фильм становится короче.
В принципе это будет не сильно заметно глазу и уху, особенно если поправить питчинг.
✅Вариант 2 (посложнее). Поставить принудительно нужный фреймрейт и пересвести звук со звукорежиссером.
Плюсы: не портится звук.
Минусы: небольшое ускорение видео, возможные трудности со звуком, особенно в длинных сценах и в случаях, где музыка очень четко привязана к картинке, фильм становится короче.
✅Вариант 3 (сложный). Пользоваться различными алгоритмами ретайма.
Плюсы: не меняется звук, сохраняется длина фильма.
Минусы: долго, ресурсоемко, возможны артефакты из-за ретайма.
Ни один вариант не без минусов, так что смотреть нужно по ресурсам и обстоятельствам. Чаще всего работает первый вариант, иногда — второй. Третий вариант используется крайне редко (и это замечательно).
➡️Если нужно подготовить мастер, снятый и смонтированный в 25 fps под стандарты кино, то возможные алгоритмы точно такие же. Ну, разве что теперь материал не ускоряется, а замедляется, а при ретайме видео нам нужно не дорисовывать дополнительный кадр каждую секунду, а прятать.
Такие дела.
Кстати, если у вас есть какие-то пожелания и предложения по контенту на канале — не стесняйтесь писать комментарии!
#ретайм #фреймрейт
Telegram
ExitLight Community Chat
Чат cообщества ExitLight
Основной канал: https://t.me/exit_light
Ютуб:
https://www.youtube.com/@ExitLightChannel/featured
Правила:
https://t.me/ExitLight_Chat/130861
Поиск:
#levels #LUT #CST #матчинг #балансбелого #курсы
Полезное:
#вопрос #ответ
Основной канал: https://t.me/exit_light
Ютуб:
https://www.youtube.com/@ExitLightChannel/featured
Правила:
https://t.me/ExitLight_Chat/130861
Поиск:
#levels #LUT #CST #матчинг #балансбелого #курсы
Полезное:
#вопрос #ответ
👍2❤1
🎬Продолжаем обсуждение воркфлоу и проблем, связанных с ним.
Часть 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. Нет, не то, чтобы эти кодеки были чем-то хуже, просто у них иное предназначение, нежели попадать под нож монтажера.
✅Давайте закрепим:
#воркфлоу
Часть 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-кодеки — это хорошо, потому что монтировать можно на любом калькуляторе, но вот места на диске понадобится довольно много.Если проект долгий, пересчет исходников в intermediate-кодек сэкономит вам очень много времени в будущем. Возьмите за правило кодировать все, с чем работаете, в монтажный кодек!
Delivery-кодеки — это тоже хорошо, но не для монтажа, потому что хоть места такие файлы займут немного, а процессор будет уставать.
#воркфлоу
Telegram
24fps
Ну и как обойти стороной воркфлоу!
🎬Вкратце, это процесс, когда мы передаем файлы из одного софта в другой. Что тут может пойти не так? Как показывает практика, все что угодно.
Часть 1. Кодек/контейнер.
Многие монтажеры (и не только они, а вообще все специалисты…
🎬Вкратце, это процесс, когда мы передаем файлы из одного софта в другой. Что тут может пойти не так? Как показывает практика, все что угодно.
Часть 1. Кодек/контейнер.
Многие монтажеры (и не только они, а вообще все специалисты…
👍5
🎬А вот и третья часть большой темы по воркфлоу!
Мы уже рассмотрели информацию о кодеках, и не единожды, а дважды. Сегодня хочу подробнее рассказать о компрессии изображения.
Часть 3. Компрессия изображения.
✅Из названия в целом все понятно: изображение сжимается, что помогает экономить место на диске. С компрессией мы сталкиваемся ежедневно, взять хотя бы .rar и .zip архивы, .jpeg и другие зашакаленные картинки. Из предыдущих постов мы еще и про компрессию видео узнали! Теперь нам понятно, почему компрессия — не всегда благо, ведь в случае с тем же .mp4/h.264 при сильной экономии места мы получаем худшее качество (артефакты сжатия), для декодирования требуется большая вычислительная мощность. Давайте залезем в теорию поглубже, мне кажется, это будет полезным и лучше поможет понять, как вообще работает сжатие. Всего существует два вида компрессии: с потерями и без потерь, или lossy и lossless по-английски.
Параграф 1.
Lossy compression, то есть сжатие с потерями.
Файлы, прошедшие через алгоритмы lossy, невозможно восстановить в исходном качестве: пережатый джипег не станет исходной хайрезной фотографией. Но здесь нужно ответить себе на вопрос, зачем мы пользуемся именно lossy-алгоритмами в случае с конкретным видео?
1. Если видео не предполагает дальнейшей обработки, и мы предоставляем его как финальный результат, то lossy нам будет достаточно (но есть нюанс со степенью сжатия, чуть ниже расскажу).
2. Если с видео будет работать кто-то после нас, например ротоскопер/колорист/композер, то сжатие с потерями — не наш выбор. Специалистам в пайплайне почти всегда необходимы исходники с минимальными потерями или вообще без них.
Степень сжатия lossy-алгоритмами
Википедия добродушно подсказывает, что
➡️Если говорить понятным всем монтажерам языком, то результат вывода HD-видео с разрешением 1920x1080 в .mp4/h.264 с битрейтом 1 Мб/с выглядит плохо, а вот если битрейт поднять до 20 Мб/с, то вполне себе неплохая картинка получается, не видно никаких артефактов.
✅Вывод: если клиент должен получить результат в lossy-кодеке («давай эмпэчетыре тяжелую»), то постарайтесь избежать артефактов высоким битрейтом. А если есть строгая верхняя граница битрейта, то клиенту стоит быть готовым к артефактам. Впрочем, даже с низким битрейтом можно частично избежать видимых артефактов, но это уже другая история, которую я обязательно расскажу в грядущих постах!
#воркфлоу #компрессия
Мы уже рассмотрели информацию о кодеках, и не единожды, а дважды. Сегодня хочу подробнее рассказать о компрессии изображения.
Часть 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-кодеке («давай эмпэчетыре тяжелую»), то постарайтесь избежать артефактов высоким битрейтом. А если есть строгая верхняя граница битрейта, то клиенту стоит быть готовым к артефактам. Впрочем, даже с низким битрейтом можно частично избежать видимых артефактов, но это уже другая история, которую я обязательно расскажу в грядущих постах!
#воркфлоу #компрессия
Telegram
24fps
Ну и как обойти стороной воркфлоу!
🎬Вкратце, это процесс, когда мы передаем файлы из одного софта в другой. Что тут может пойти не так? Как показывает практика, все что угодно.
Часть 1. Кодек/контейнер.
Многие монтажеры (и не только они, а вообще все специалисты…
🎬Вкратце, это процесс, когда мы передаем файлы из одного софта в другой. Что тут может пойти не так? Как показывает практика, все что угодно.
Часть 1. Кодек/контейнер.
Многие монтажеры (и не только они, а вообще все специалисты…
👍2😍1
Смотрите, сделал тест по бандингу, чтобы было понятнее, чем lossy и сильная компрессия могут быть опасны. Это простой статичный линейный градиент на 5 секунд.
Тут 4 картинки:
Тут 4 картинки:
1. Экспорт стилла из Premiere с таймлайна
2. Стилл из отрендеренного файла в 10 Мб/с
3. Первый кадр из отрендеренного файла в 1 Мб/с
3. Двадцать шестой кадр из отрендеренного файла в 1 Мб/с
Последние два кадра взяты из одного и того же рендера, но при переходе с 25 на 26 кадр происходит резкий скачок. Это связано с низким битрейтом и длиной GOP, которую Premiere выставляет автоматически. На видео видно, что таких скачков несколько.