вот, кстати, не знаю, как тогда работает алгоритм, то ли он расставляет ключевые кадры в зависимости от динамичности сцены, что, кстати, логично при двух-проходном кодировании, а вот как оно происходит при однопроходном, вообще хз.
Экспериментировал только при выводе из Ае в QuickTime кодеком H.264.
Задача была получить файл приемлемого качества при минимизации размера, что бы можно было послать почтой привьюшку (3-5 Мб для минутного HD (720р) ролика).
Так вот, не трогая "Key frame every..." и "Limit data rate to..." а пытаясь задать качество только ползунком "Quality" - приемлемое качество получалось при слишком большом размере. В почту не лезло.
Если при 75% качестве задавать желаемый битрейт, то получалась каша.
Волшебство случалось только при колдовстве с "Key frame every..." при установке его в районе "25 frames" привьюха выглядела нормально. Рассыпалась только на совсем загруженных мелкими деталями кадрах.
Ещё, в ходе этих экспериментов я выяснил, что на предельных режимах сжатия вывод сразу в MOV (QuickTime, H.264) работает хуже (т.е. при сопоставимом качестве, файл получается больше), чем при выводе в mp4 (H.264). Из этого можно сделать выводы, что, либо они работают с разной степенью оптимизации, либо они по разному пакуются и (или) в mov контейнере присутствует какая-то ещё информация.
Кстати, разный принцип видно, если наблюдать за папкой, куда рендерится. При кодировании в mp4 в папке создаётся два файла - со звуком и видео, а потом собирается в один *.mp4, а при выводе в MOV - создаётся один и его размер меняется