>Например, при низком битрейте на статических сценах кадр из I фрейма будет
>существенно уступать по качеству последующим. По той простой причине, что кодировщик
>физически не сможет впихнуть в него всю информацию,Это по идее зависит от того что кодеку можно. Если ему можно задирать битрейт - задерет и будет нормально. Если нельзя - закодит как можно. Вот только референситься на I-кадр который УЖЕ был далек от оригинала как черт знает что - тухлое начинание. Хороший метод испортить картинку изначально, потом конечно P-кадры пытаются что-то исправить но это уже не то, картинка получается гадостной. По опыту извращений с MPEG кодеками - строгий CBR режим для гадость и куда лучше получается если разрешен достаточно широкий VBR чтобы кодек мог подбрасывать скорость на I-кадрах. Субъективно - лучше позволить жировать на I-кадрах путем откусывания у P-кадров чем начать с дрянного I-кадра и пытаться вытянуть дело увеличением размера P и B кадров. Потуги экономии на I кадрах в пользу P/B как-то себя не оправдали. У мпегов есть противное свойство - они скорее засирают картинку с I-кадра нежели улучшают, особенно с B-кадрами, особенно если их много подряд. В итоге обычно на последовательностях где I кадры редки - наблюдается мерзенький эффект: на I кадре картинка идеальная (если кодек не загнан в задницу) а вот потом картинка деградирует. За счет P и особенно B кадров. Потому что они, конечно, уточняют, но не очень то и точно.
>зато последующими кадрами "уточнит" статическую картинку.
Субъективно - мпеги не очень то и склонны к "уточнению", напротив, они прилично засирают картинку промежуточными кадрами так что нередко можно лицезреть назойливый эффект: на I-кадре "с глаз слетает пелена" а потом постепенно опять появляется. Заметно там где кодеку позволено делать I-кадры с приличным качеством а интервал между I кадрами - большой.
>Обратный пример - низкий битрейт и сильная динамика.
А там будет мазня как ни изгаляйся в таком допущении :) лучше позволить кодеку задрать битрейт на конкретной сцене. Да, локально битрейт будет сильно круче но и сцена будет вытянута. А в среднем - размер файла и общая скорость мало изменится и пусть лучше кодек скостит что-то с малоактивных сцен где это не заметно почти.
>Далее, выбор ключевых кадров - это вообще-то и есть задача кодировщика (если
>это не MPEG-2, конечно, где GOP фиксирован).
В мпегах 1 и 2 кодировщик тем не менее может варьировать последовательность кадров, хотя она и одна на весь мувик по структуре, IIRC. Т.е. числа P и B кадров в GOPе - выбирабельны. Хотя фиксированные I кадры - на редкость дурная затея, битрейт высаживатеся почем зря + упомянутый эффект с циклическим прыганием качества зачастую очень выражен получается.
>Другое дело, что по одному кадру сравнивать кодировщики видео - бредовое занятие.
А еще бредовое занятие - сравнивать уже сжатые ранее последовательности. При этом мпеги явно частично маскируют свои прошлые искажения исходного материала новыми и разница получается невелика, тогда как VP8 не похожий на них - плодит свои искажения, которые не маскируются исходными. О чем гуглевцы недвусмысленно сказали. Заметьте как VP8 втопил на исходно не сжатом материале AKA последовательности "mobile calendar", где в силу несжатости исходного материала и отсутствия на нем артефактов сжатия кодеки оказались в равных условиях.
>Желательна серия последовательных кадров, причем одна серия для статики,
>другая для динамических сцен.
При том желательно чтобы эти кадры не были сжаты ранее каким-то мпегом, иначе получается что мпег себе подыгрывает, заранее запакостив правильным образом исходный кадр с которым сравнение, что не есть честно :-)
