Лаборатория компьютерной графики и мультимедиа при факультете ВМиК МГУ опубликовала (http://www.compression.ru/video/codec_comparison/h264_2010/v...) результаты оценки работы кодировщиков VP8, x264 и XviD. С точки зрения адаптации потока под заданный битрейт VP8 продемонстрировал очень хорошие результаты. При кодировании VP8 оказался медленнее XviD и x264 в 5-25 раз, показав при этом по сравнению с XviD на 10-30% более высокое качество картинки и уступив по качеству кодирования обычного видео x264 на 20-30%, но при кодировании HDTV-потока результирующее качество было на уровне с x264.
Разработчики кодека VP8 прокомментировали результаты, подчеркнув, что проблемы с качеством скорее всего вызваны тем, что кодированию подвергался поток, уже ранее подвергавшийся сжатию другим кодеком, высокое качество кодирования в VP8 неискаженного HDTV-потока подтверждает данную догадку. Что касается скорости, то разработчики заявили, что они только приступили к оптимизации кодировщика, ...URL: http://lists.mpegif.org/pipermail/mp4-tech/2010-July/009388....
Новость: http://www.opennet.me/opennews/art.shtml?num=27216
Уже не новость. http://www.opennet.me/openforum/vsluhforumID3/68296.html#8
Угу, это не новость, это старость :)
Ну наконец-то. Хоть русские сравнили с XviD. очень давно хотел узнатрь, чем он не угодил.
Он "не угодил" сугубо тем что реализует менее навернутую чем в случае x.264 инкарнацию MPEG4, а посему имеет меньше возможностей для качественного кодирования. Что и наблюдается - его соотношение битрейт vs качество картинки явно хуже чем у x.264 и VP8.
Хотелось бы увидеть стоп-кадры всех троих при заданных битрейтах.
>Хотелось бы увидеть стоп-кадры всех троих при заданных битрейтах.стопкадры таки реально не показатель для видео
или вы хотите стопкадры статических сцен ?
>стопкадры таки реально не показатель для видеоТаки ничего лучше пока не придумали. К тому же, есть куча дефектов, которые стоп-кадры могут выявить. И 4ый скриншот с исходника
> Таки ничего лучше пока не придумали.Вы что, думаете что по ссылке топика графики люди рисовали «на глаз»?
читайте: http://ru.wikipedia.org/wiki/Качество_видео
«Наиболее традиционным методом измерения качества системы обработки цифрового видео (таких как видеокодеки DivX, XviD)) является измерение Отношения сигнала к шуму и пикового отношения сигнала к шуму между исходным сигналом и сигналом на выходе системы. PSNR — это одна из метрик объективного качества видео. Она может быть автоматически вычислена компьютерной программой. Но хороший PSNR не всегда гарантирует хорошее качество, из-за того что зрительная система человека обладает нелинейным поведением. Не так давно было разработано несколько более сложных и точных метрик, например VQM и SSIM.»
Ты тоже смотришь PSNR или SSIM? Или смотришь видео?
А что, нельзя смотреть видео и оценивать "PSNR или SSIM", "на глазок", примерно? :-)
Кто-то там, в древнеримской истории, мог же делать несколько дел одновременно!
Моё восприятие качества видео соответствует модели SSIM. Если ещё что-то не ясно, спрашивайте :)
>Моё восприятие качества видео соответствует модели SSIM. Если ещё что-то не ясно,
>спрашивайте :)SSIM - оценка интегральная. Что может вылезти на отдельных неудобных сценах, она никак не покажет.
>Моё восприятие качества видео соответствует модели SSIM. Если ещё что-то не ясно,
>спрашивайте :)Спрашиваем, сами напросились:
1) А как это проверялось?
2) И на основании чего такой вывод?
3) С какой точностью соответствует?
4) И как быть с ДВИЖУЩИМИСЯ объектами? Каким макаром SSIM учитывает человеческие особенности восприятия ДВИЖУЩИХСЯ объектов, например?
>Таки ничего лучше пока не придумали.Дело в том что на ДВИЖУЩИХСЯ объектах глаз человека вообще не воспринимает мелкие детали. Посему насколько такое сравнение соответствует тому как будет воспринят ролик при просмотре - большой вопрос, имхо. Безусловно, красивый стопкадр тоже фича, но явно не главная для ВИДЕОкодека, основная задача которого - движущиеся картинки.
Дело в том, что мелкими деталями, качество видео не обходиться.
И чего? Просто сравнение стопкадров самих по себе - вообще не факт что является адекватным сравнением ВИДЕОкодеков. Это же не ФОТОкодеки, правда? Да и как правильно кто-то заметил, расстановка key frames (I-frames в мпег) может порядком отличаться. Стратегия расстановки кейфреймов конечно тоже часть логики кодека, влияющая на качество картинки и вообще баланс битрейт-качество кодека. Однако, почему-то мало кто учитывает что эта логика может по разному работать, так что один кодек качественнее осилит одни сцены, а другой - другие. По логике вещей соотношение качества кадров надо бы смотреть по всему мувику. Правда вот что такое соотношени качества для ДВИЖУЩЕЙСЯ картинки (которую не совсем корректно анализировать как стопкадры) - кажется так никто толком и не придумал so far.
>Хотелось бы увидеть стоп-кадры всех троих при заданных битрейтах.Вы, наверное, знаете, что есть три типа фреймов - I,P,B. лучшее качество и больший размер у I, это ключевые кадры. худшее качество - у B - это кадры-заполнения, грубо говоря. Так вот I-фрейм и B-фрейм в разных видеосэмплах могут выпасть на 1 кадр, как раз который мы сравниваем (а это бывает часто, т.к. порядок B-фреймов и их количество, а также частоту I-фреймов практически всегда меняют, и в разных кодировщиках по-умолчанию стоят разные показатели. Поэтому стоп-кадр - не самый лучший вариант для сравнения. к тому же при пресетах.
-
и да, я пробовал кодировать этим кодеком (пришлось патчить мплеер/менкодер). и theora тоже пробовал с интересом и надеждой.
очень хотелось бы, чтобы его доделали / улучшили, т.к. поклонник опенсорса. но, констатирую факт, рядом с x264 (привет стандарту Н264) им и не кодировали
-
>Разработчики кодека VP8 прокомментировали результаты, подчеркнув, что проблемы >с качеством скорее всего вызваны тем, что кодированию подвергался поток, уже >ранее подвергавшийся сжатию другим кодекоми чего? вообще-то многие рипуют и перериповывают с рипов (с BD делают BDRip-1080/720, с BDRip1080/720 нередко делают HQRip-AVC и просто HQRip на пару гигов. если для VP8 это проблема, то это крайне плохо, значит, как кодек он ещё не готов.
это только моё личное мнение и я не утверждаю, что оно правильное
>Вы, наверное, знаете, что есть три типа фреймов - I,P,B. лучшее качество
>и больший размер у I, это ключевые кадры. худшее качество -
>у B - это кадры-заполнения, грубо говоря. Так вот I-фрейм и
>B-фрейм в разных видеосэмплах могут выпасть на 1 кадр, как раз
>который мы сравниваем (а это бывает часто, т.к. порядок B-фреймов и
>их количество, а также частоту I-фреймов практически всегда меняют, и в
>разных кодировщиках по-умолчанию стоят разные показатели. Поэтому стоп-кадр - не самый
>лучший вариант для сравнения. к тому же при пресетах.вы, наверное, знаете, что , взяв отдельный P или B-фрейм вы , скорее всего, не получите внятной картинки вообще. Грубо говоря "кадр" при выводе - это результат обработки всех фреймов с момента получения последнего ключевого.
то есть - сравнивать отдельно I, P и B фреймы - смысла нет . как и говорить о "качестве" P и B фреймов..
прикидываемся? Ежу понятно что речь шла не о IPB порциях кодированного потока а отображаемые на экране кадры, уже раскодированные из этих IPB, и в одном кодеке могут выбрать 778 кадр как опорный I а другой кодек этот 778 кадр выберет как P или B.Счастливый горе-тестировщик выложит скриншоты этих кадров и на основании этого будет делать очень далеко идущие выводы что второй кодер плохой.
К.О
Вообще-то, близость к оригиналу кадров, сформированных из I, P и B фреймов зависит от кучи параметров.
Например, при низком битрейте на статических сценах кадр из I фрейма будет существенно уступать по качеству последующим. По той простой причине, что кодировщик физически не сможет впихнуть в него всю информацию, зато последующими кадрами "уточнит" статическую картинку.
Обратный пример - низкий битрейт и сильная динамика.Далее, выбор ключевых кадров - это вообще-то и есть задача кодировщика (если это не MPEG-2, конечно, где GOP фиксирован). Другое дело, что по одному кадру сравнивать кодировщики видео - бредовое занятие. Желательна серия последовательных кадров, причем одна серия для статики, другая для динамических сцен.
>Например, при низком битрейте на статических сценах кадр из 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", где в силу несжатости исходного материала и отсутствия на нем артефактов сжатия кодеки оказались в равных условиях.
>Желательна серия последовательных кадров, причем одна серия для статики,
>другая для динамических сцен.При том желательно чтобы эти кадры не были сжаты ранее каким-то мпегом, иначе получается что мпег себе подыгрывает, заранее запакостив правильным образом исходный кадр с которым сравнение, что не есть честно :-)
>>Разработчики кодека VP8 прокомментировали результаты, подчеркнув, что проблемы
>>с качеством скорее всего вызваны тем, что кодированию подвергался поток, уже
>>ранее подвергавшийся сжатию другим кодеком
>и чего? вообще-то многие рипуют и перериповывают с рипов (с BD делают BDRip-1080/720,
>с BDRip1080/720 нередко делают HQRip-AVC и просто HQRip на пару гигов.
>если для VP8 это проблема, то это крайне плохо, значит, как кодек он ещё не готов.
>это только моё личное мнение и я не утверждаю, что оно правильноеПроблема в том, что VP* кодеры имеют иной характер искажений как результат сжатия (по отношению к популярной серии MPEG4). Поэтому когда ПЕРЕкодируется поток, изначально сжатый MPEG4, в VP*, то мы получаем сложение обоих искажений, тогда как при перекодировании его же снова в MPEG4 отпечаток как бы накладывается тот же и приводит к значительно меньшему ухудшению качества.
Поэтому и говорится, что сравнивать качество алгоритмов сжатия можно только используя несжатый оригинал (который обычно не доступен, в лучшем случае можно экспериментировать со слабосжатыми толстыми потоками). Уверен, что никто и не пытался сравнивать качество изначально сжатого в VP* видео, перекодированного снова в VP* с перекодированным в MPEG4.
Что касается (пере)рипов, то использовать разные промежуточные кодеки едва ли имеет много смысла, универсальных кодеков и универсальных параметров для любого видео пока не существует.
>Проблема в том, что VP* кодеры имеют иной характер искажений как результат
>сжатия (по отношению к популярной серии MPEG4). Поэтому когда ПЕРЕкодируется поток,
>изначально сжатый MPEG4, в VP*, то мы получаем сложение обоих искажений,
>тогда как при перекодировании его же снова в MPEG4 отпечаток как
>бы накладывается тот же и приводит к значительно меньшему ухудшению качества.Именно, поэтому сравнивать надо на изначально несжатых сценах, только вот с их доступностью бывают определенные проблемы. Я знаю аж 2 мувика для которых реально нарыть несжатые сцены: Elephant Dreams и Big Bucks Bunny. Но это computer generated картинки, несколько отличные от типичного видео.
это типа мгушники занялись кодированием видео? ну надеюсь от них будет толк, не разбегутс по коммерческим конторам
уже больше 10 лет занимаются
И как результат?
>И как результат?Сходите на их сайт да посмотрите. Часть результатов - вполне себе общедоступна.
>это типа мгушники занялись кодированием видео?Они уже давно занимаются. И, строго говоря, чуть ли не единственные кто пытается хоть как-то подогнать все это под научные основы. Насколько оно им удается - хрен бы его знает, но более хороших сравений все-равно никто не осилил ;).Кстати из их сравнений видно еще и забавный факт: GPLный x.264 по битрейт-качество делает практически все коммерческие энкодеры H.264.