Вы про профайлы лучше почитайте. Они действительно называются baseline и high.
Я не стал выкручивать количественные параметры, потому что они существенно просаживают скорость, давая небольшой прирост в качестве. К тому же при больших числах bframes и ref ещё и растут требования по памяти, что неприемлемо для железных проигрывателей. Вы думаете youtube использует большие значения?
Мы всё-таки кодеки для веба сравниваем, а не для рипов на торренты.
На практике редко полезен ref выше 6 и bframes выше 8.
А настройки я выбираю в зависимости от задачи. Поскольку я недалеко ушёл от дефолта, можете ещё предъявить претензии разработчику, почему у него такие низкие дефолтные настройки.
Ничего страшного, что я указал параметры по умолчанию. Не имею привычки их запоминать наизусть.
--no-psy потому что сравнение объективное, а не субъективное. psy-rdo просаживает SSIM и PSNR.
--no-fast-pskip — проверил. Не знаю почему, но при его отключении уменьшается и fps, и SSIM. То есть влияние на скорость в пределах погрешности, а по SSIM всё-таки выигрыш.
Выбор ref я обосновал. Ну да, bframe на один отступил от дефолта, ой простите, простите, как я посмел.
Про crf. Не знаю, откуда пошёл этот миф. После первого прохода кодек как раз и оценивает crf, c которым он будет кодировать второй. Модель распределения битов по потоку известна на обоих проходах. И у меня была цель попасть в определённый размер, так как у VP8 нет crf-подобного режима, разумно их сравнивать в одинаковых usecase'ах.
Дело в том, что во время просмотра видео вы больше обращаете внимание на одни артефакты и меньше на другие. Это тоже важно. В видео вы обращаете внимание на движущиеся объекты больше, чем на задний план. Наверняка, можно ещё придумать причины, по которым нужно смотреть именно видео.
Правильный способ как раз видео на глаз сравнивать. Ещё при этом не зная, где какой кодек. И при большом количестве тестеров.
Если нет возможности подобное организовать, используются метрики качества, чтобы не потерять, например, те проблемные кадры, которые я привёл для VP8, и представлять картину в целом.
В статье критикуется использование метрики PSNR, так как она уже устарела. Например, адаптивное квантование улучшает SSIM и визуальное качество, но просаживает PSNR. То есть кодек может иметь худший PSNR, при этом картинка будет лучше.
Когда VP8 вышел, разработчик x264 провёл тесты, и заявил, что VP8 слегка превзошёл x264 BP, но не сильно не дотянул до x264 HP. При этом он измерял на одном видео на самых тяжёлых настройках кодеков.
On2 же заранее обещали заметное превосходство над H.264 HP при меньшей вычислительной сложности. Ни того, ни другого мы не получили.
Можно долго спорить, кто визуально лучше. Обычно при субъективных сравнениях берут много пользователей, потом результат усредняют, и отбрасывают те, которые сильно отличаются от среднего. Ещё перед сравнениям у тестеров проверяют цветовое восприятие.
Насчёт смытой черепицы, посмотрите в эту область:
Там результат у x264 HP лучше.
То, что у VP8 на небе, напоминает легкий блокинг.
Всё субъективно =)
Разработчикам x264 можно доверять, поскольку все их заявления обычно можно проверить самому. Они выкладывают все исходники и настройки, ведут дискуссии на doom9.
А On2 до релиза только картинки показывали, руками потрогать на давали. После релиза оказалось, что их обещания были необоснованными.
Нет стандарта VP8.
VP8 не был стандартизирован. Просто были заморожены спецификации формата.
И, учитывая отвратительные спеки и то, что область применения VP8 значительно меньше, чем у H.264, вряд ли появятся альтернативные реализации. Максимум — форки с небольшими твиками.
Там ещё аудио прикладывается зачем-то, закодированное разными кодеками. И контейнеры тоже разные, и разное количество инфы записывают в файл. Ещё кодеки не идеально попадают в битрейт даже при двухпроходном кодировании. Допустимы отклонения на несколько процентов. У плохих кодеков бывает и больше.
Параметры кодирования описаны, как будто это рип для торрентов, а не тестирование кодеков. В самой статье только в дополнении указано, что взят Baseline-профайл H.264, и почему MainConcept.
2. On2 на сайте почему-то приводят графики того, как они уделывают High Profile x264. Но на деле удалось сравниться только с Baseline, решили назвать кодек веб-оптимизированным. Пока нет подробных тестов, могу только предполагать, что оптимизированный по скорости декодирования пресет VP8 сольёт baseline-профайл настройками x264.
3. Ну да, только до ума они его так и не довели.
4. Не только Гугл может делать предложения, от которых трудно отказываться. Многим компаниям нужен свободный H.264-кодер, и они готовы его поддерживать. А успех open source разработки уже видели на примере Теоры.
5. Вы уверены, что Microsoft платит royalty? Они же и так вкладывают деньги в исследования, зачем ещё и платить.
Вы уверены, что Apple использует H.264 в сто раз больше? По-моему, количество установленных Win7 должно быть сравнимо, если превосходит, количество девайсов Apple, работающих с видео.
Как бы он не был оптимизирован, feature set у формата Theora намного скромнее, чем у H.264. И раз уже пошли скрины, то вероятно скоро появится и само сравнение со всеми подробностями.
Я к тому, что оптимизации не есть аппаратное декодирование.
Формально, конечно, да, но за счёт простоты декодера VP8 его декодирование не станет большой проблемой для уже выпущенных устройств.
Декодирование Baseline профайла H.264 тоже не является проблемой для чипов, основанных на ARM. И оптимизация там тоже проводилась. Но перенос функционала на отдельный сопроцессор позволяет увеличить время автономной работы.
Пруфлинк?
Я читал только про оптимизации под ARM. Для аппаратного декодирования обычно ставят отдельный сопроцессор для декодирования видео. Перепрошивкой тут не отделаешься.
Я не стал выкручивать количественные параметры, потому что они существенно просаживают скорость, давая небольшой прирост в качестве. К тому же при больших числах bframes и ref ещё и растут требования по памяти, что неприемлемо для железных проигрывателей. Вы думаете youtube использует большие значения?
Мы всё-таки кодеки для веба сравниваем, а не для рипов на торренты.
На практике редко полезен ref выше 6 и bframes выше 8.
А настройки я выбираю в зависимости от задачи. Поскольку я недалеко ушёл от дефолта, можете ещё предъявить претензии разработчику, почему у него такие низкие дефолтные настройки.
--no-psy потому что сравнение объективное, а не субъективное. psy-rdo просаживает SSIM и PSNR.
--no-fast-pskip — проверил. Не знаю почему, но при его отключении уменьшается и fps, и SSIM. То есть влияние на скорость в пределах погрешности, а по SSIM всё-таки выигрыш.
Выбор ref я обосновал. Ну да, bframe на один отступил от дефолта, ой простите, простите, как я посмел.
Про crf. Не знаю, откуда пошёл этот миф. После первого прохода кодек как раз и оценивает crf, c которым он будет кодировать второй. Модель распределения битов по потоку известна на обоих проходах. И у меня была цель попасть в определённый размер, так как у VP8 нет crf-подобного режима, разумно их сравнивать в одинаковых usecase'ах.
Если нет возможности подобное организовать, используются метрики качества, чтобы не потерять, например, те проблемные кадры, которые я привёл для VP8, и представлять картину в целом.
В статье критикуется использование метрики PSNR, так как она уже устарела. Например, адаптивное квантование улучшает SSIM и визуальное качество, но просаживает PSNR. То есть кодек может иметь худший PSNR, при этом картинка будет лучше.
Про первое. Давайте конкретно, что не так? Мой пресет несильно отличается от slow. Только число --ref я увеличивать не стал и включил --trellis 2.
On2 же заранее обещали заметное превосходство над H.264 HP при меньшей вычислительной сложности. Ни того, ни другого мы не получили.
Насчёт смытой черепицы, посмотрите в эту область:
Там результат у x264 HP лучше.
То, что у VP8 на небе, напоминает легкий блокинг.
Всё субъективно =)
А On2 до релиза только картинки показывали, руками потрогать на давали. После релиза оказалось, что их обещания были необоснованными.
VP8 не был стандартизирован. Просто были заморожены спецификации формата.
И, учитывая отвратительные спеки и то, что область применения VP8 значительно меньше, чем у H.264, вряд ли появятся альтернативные реализации. Максимум — форки с небольшими твиками.
3. Ну да, только до ума они его так и не довели.
4. Не только Гугл может делать предложения, от которых трудно отказываться. Многим компаниям нужен свободный H.264-кодер, и они готовы его поддерживать. А успех open source разработки уже видели на примере Теоры.
5. Вы уверены, что Microsoft платит royalty? Они же и так вкладывают деньги в исследования, зачем ещё и платить.
Вы уверены, что Apple использует H.264 в сто раз больше? По-моему, количество установленных Win7 должно быть сравнимо, если превосходит, количество девайсов Apple, работающих с видео.
Декодирование Baseline профайла H.264 тоже не является проблемой для чипов, основанных на ARM. И оптимизация там тоже проводилась. Но перенос функционала на отдельный сопроцессор позволяет увеличить время автономной работы.
Я читал только про оптимизации под ARM. Для аппаратного декодирования обычно ставят отдельный сопроцессор для декодирования видео. Перепрошивкой тут не отделаешься.