Исходное сообщение
"Компания Google подробно обосновала причины удаления поддерж..." Отправлено User294, 17-Янв-11 06:02
> Просто оставлю это здесь. 67kbps Угу, только вот на адрес посмотреть забыли. Какой же разработчик себя обругает? :) Так, на подумать: 1) Это очень специфичный вид видео. Это аниме, с весьма небольшим движением и мизерным фактическим фрэймрейтом (т.е. картинка сама по себе изменяется лишь несколько раз в секунду). А знаете, если взять 1 статичный жпег на мегабайт, поффтыкать на него неделю и битрейт посчитать - получится еще более офигительно. Правда, даже менее полезно, но все-таки. В общем сильно нишевой случай. 2) Если вы там не видите жутких артефактов - вам, вероятно, стоит посетить окулиста. Вокруг объектов повмеместно мпеговский срач, как и положено. Да что там артефакты, на немногочисленных сценах с движением, особенно "камеры в целом" - картинки вообще НЕТ, есть набор абстрактных шевелящихся блоков в этих местах. Ну да, статичные "почти стоп кадры" выглядят неплохо. Зато любое движение - как и следует ожидать на таком битрейте, рассыпается на просто набор квадратиков. На котором вообше ничерта не видно. 3) Если туда подсунуть более нормальное ВИДЕО, а не АНИМАЦИЮ, например, поток с камеры - там будет просто набор шевелящихся блоков на котором нихрена не разобрать. Ну за исключением случая когда картинка полностью статична, может быть. 4) Типовой битрейт для интернета все-таки 500Кбит или выше. Не, конечно, видеосервисы будут счастливы скостить битрейт в 5-10 раз, но для кого процента мувиков это получится, как вы думаете? А если еще и кодировать автоматически, без хэнджоба с твикингом алгоритмов кодека и тонким тюнингом параметров чуть ли под одну конкретную анимаху? :))) 5) На самом деле, вы просто видите приближение к идеалу. Древнючий Smacker от Rad Game Tools в свое время детектили подобную практически статичную картинку влет и, если им дать именно непожатый оригинал вот такого вот аниме или подобной анимации (без шума/артефактов от предыдущего кодека) - его даже в полностью lossless режиме (с идеальной картинкой) утрамбовало бы в мизерный битрейт. Потому что в таком "видео" реальных отличий между кадрами - мизер, и самих кадров - немного. Это называется АНИМАЦИЯ и оно по природе своей очень сильно жмется самим фактом того что кодек может детектить разность между кадрами (ее почти не оказывается, особенно если шума и артефактов от прошлого кодека нет или их зафильтровали грамотно). Проблемы начинаются на сценах с движением, когда отличий между кадрами становится достаточно много: если попытаться уложиться в 67кбит, качество будет *жутчайшим* поскольку кодек чтобы уложиться в битрейт будет вынужден сильно просадить качество блоков передающих отличия, ну и картинка превратится в ШЫТ. Итого: ну выкопали некий corner case, заоптимизили пузомерку, подобрав грамотно исходный материал для кодирования (аниме с малым количеством движения) и параметры кодека. Проблема только в том что это был corner case с оптимизацией под него. Попробуйте на 67Кбит заэнкодить нормальное видео с камеры, например. А потом покажите. Вместе поблюем. В общем то единственное что тут заметно - то что детектирование и кодирование отличий у x264 работает неплохо, так что если подсунуть ему специально подготовленный материал, можно понтануться офигенным битрейтом... Проблема состоит в том что это сработает только на специфичном типе материала. Вы можете в лепешку разбиться, но более реальный видеопоток, например, с камеры, при таком битрейте будет полным дерьмом. Поэтому жизню онлайн видеосервисов сие никак особо не облегчит: там никто не будет сношаться с хардкорным детектированием типа мувика и подбором целую неделю идеальных параметров кодирования для именно этого конкретного мувика.