Сравнение размера файлов и качества картинки ProRes vs. H.264
ProRes vs. H.264 (Windows)
Решил я посчитать файлы не абы как, а по требованиям Айса, т.е. Quick Time, H.264, 30 Мбит для 1080р АМЕ показал, что минутный файл будет весить 215 Мб. Это мне показалось много, потому что исходники в разы легче. Вспомнил, как регулярно нахваливают ProRes и решил выяснить точно ли он появился в Винде в полноценном виде, подумав, раз он такой хороший, возможно он более эффективно сжимает видео.
И, таки, да - в АМЕ 2019 v.13.0.2 завезли таки настоящий ProRes. Чит - если нужен только он, то не нужно ставить весь СС2019, достаточно Media Encoder'a - из него открывать подготовленный проект и рендерить. Да, на сайте Adobe говорится, что для него нужна Windows 10 (1703), у меня нормально заработало на Win7 x64 sp1. Update Нашёл причину - Adobe отказались от включения в пакет кодеков Dolby Digital и перешли на использование встроенных в систему. А они в Винде стали появляться с 8.1. Пруф - https://helpx.adobe.com/media-encode...ed-import.html
Update Adobe такой Adobe... Добавил ProRes в Quick Time, но убрал возможность кодировать H.264 в .mov, только в .mp4
P.S. Теперь понятно, почему у некоторых возникает ощущение, что Final Cut работает быстрее Pr. А вы подготовьте для Премьера такие же исходники... Судя по битрейту ProRes 422 HQ - 220 Mbps это как PhotoJPEG c 95% качеством. Так вот с такими исходниками, да c SSD, да с кучей оперативки на борту, Премьер летать будет быстрее Файнала. Хотя, у меня и без этого летает)
Разницы практически нет, при просчёте в АМE, может быть H.264 чуть порезче, но заметна при просчёте в Premiere. Оказывается, имеет значение, где происходит деинтерлейсинг и пересчёт (интерполяция) кадров. Точнее так. В АМЕ можно сделать только пересчёт кадров, при выводе с частотой, отличной от исходника, а в Pr можно интерполировать файл с нужной для просчёта частотой и тогда, по факту, пересчёта не происходит и, как следствие, картинка остаётся "целее".
Ну и как бы, да, смысла в 200 Мбит, когда исходник в 30, никакого нет, поэтому "Update3"
Самое главное - время рендера: ProRes (AME CC2019) - 11 сек., H.264 (AME CC2015) - 49 сек. Тут непонятно, то ли это СС2019 хорош, то ли ProRes, сейчас в СС2019 попробую mp4 сделать, не совсем прямое сравнение, но всё же. СС2019 - 47 сек СС2015 - 43 сек Всё таки это ProRes хорош )
Минусы у ProRes Proxy в сравнении с H.264: - размер в 1.5 раза больше; - чуть меньше качество; - для работы на Win7 нужно будет подготавливать файлы, если в них есть дорожка AC3 - удалять её. Критично только при покраске. Напрямую файл Энкодером распознаётся без звука. Хотя, в Энкодере можно накинуть постобработку, те же LUT и Lumetri, но всё равно "танцы с бубном" получаются. - не принимают на стоки
Update2 И тут я решил посмотреть требования iStock по ProRes'у... Никакого Proxy, только 422 HQ и 4444. Ну, хорошо, сейчас сделаю ещё и ProRes HQ, к чёрту сон)
В Quick Time H.264 стоит ограничение в 2000 пикселей, поэтому рендерим в .mp4, потом просто меняем расширение, если нужно именно такой вариант залить на сток. 300 Mbps - ограничение профиля High 5.2 H.264, который просит Айс. ProRes HQ сохраняет всё без потерь. Оно и понятно - битрейт в 2 раза больше исходника. 100 Mbps H.264 съедает внутренние мелкие "одиночные" детали, получается такой шумодав - текстуры немного разглаживаются, контрастные детали остаются на месте (чёткость лучей на семпле не уменьшилась). А вот 200-300 уже вполне себе приемлемо, хотя рисунок шумов отличается от оригинала.
Сравнение размера видео 4K UHD 60 к/с PhotoJPEG и ProRes 422 HQ
Поэкспериментировал с 4K UHD 60p с целью сравнить вес файлов в PhotoJPEG и ProRes 422 HQ CG. Звёздное небо. Это к тому, почему PNG весит меньше PhotoJPEG 30 секунд. 1. Исходник - PNG секвенция - 2,04 Гб QuickTime в PhotoJPEG c 95% качеством - 2,6 Гб (743 Mbps) QuickTime в ProRes 422 HQ - 6,17 Гб (1766 Mbps)
2. Исходник - PNG секвенция - 1,6 Гб QuickTime в PhotoJPEG c 95% качеством - 3,54 Гб (1014 Mbps) QuickTime в ProRes 422 HQ - 6,59 Гб (1886 Mbps)
В ProRess секвенцию кодировал в AME СС2019. И, похоже, он при работе использует GPU всегда.