| 1.2, Zenitur (?), 23:17, 06/07/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Ну наконец-то. Хоть русские сравнили с XviD. очень давно хотел узнатрь, чем он не угодил.
| | |
| |
| 2.24, User294 (ok), 13:29, 07/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Он "не угодил" сугубо тем что реализует менее навернутую чем в случае x.264 инкарнацию MPEG4, а посему имеет меньше возможностей для качественного кодирования. Что и наблюдается - его соотношение битрейт vs качество картинки явно хуже чем у x.264 и VP8.
| | |
|
| |
| 2.4, JL2001 (ok), 23:30, 06/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >Хотелось бы увидеть стоп-кадры всех троих при заданных битрейтах.
стопкадры таки реально не показатель для видео
или вы хотите стопкадры статических сцен ?
| | |
| |
| 3.5, астронимус (?), 23:36, 06/07/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>стопкадры таки реально не показатель для видео
Таки ничего лучше пока не придумали. К тому же, есть куча дефектов, которые стоп-кадры могут выявить. И 4ый скриншот с исходника
| | |
| |
| 4.6, Аноним (-), 00:30, 07/07/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Таки ничего лучше пока не придумали.
Вы что, думаете что по ссылке топика графики люди рисовали «на глаз»?
читайте: http://ru.wikipedia.org/wiki/Качество_видео
«Наиболее традиционным методом измерения качества системы обработки цифрового видео (таких как видеокодеки DivX, XviD)) является измерение Отношения сигнала к шуму и пикового отношения сигнала к шуму между исходным сигналом и сигналом на выходе системы. PSNR — это одна из метрик объективного качества видео. Она может быть автоматически вычислена компьютерной программой. Но хороший PSNR не всегда гарантирует хорошее качество, из-за того что зрительная система человека обладает нелинейным поведением. Не так давно было разработано несколько более сложных и точных метрик, например VQM и SSIM.»
| | |
| |
| |
| 6.12, Damon_ (ok), 07:41, 07/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
 А что, нельзя смотреть видео и оценивать "PSNR или SSIM", "на глазок", примерно? :-)
Кто-то там, в древнеримской истории, мог же делать несколько дел одновременно!
| | |
| 6.20, Аноним (-), 12:25, 07/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
Моё восприятие качества видео соответствует модели SSIM. Если ещё что-то не ясно, спрашивайте :)
| | |
| |
| 7.22, астронимус (?), 13:12, 07/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Моё восприятие качества видео соответствует модели SSIM. Если ещё что-то не ясно,
>спрашивайте :)
SSIM - оценка интегральная. Что может вылезти на отдельных неудобных сценах, она никак не покажет.
| | |
| 7.25, User294 (ok), 13:31, 07/07/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Моё восприятие качества видео соответствует модели SSIM. Если ещё что-то не ясно,
>спрашивайте :)
Спрашиваем, сами напросились:
1) А как это проверялось?
2) И на основании чего такой вывод?
3) С какой точностью соответствует?
4) И как быть с ДВИЖУЩИМИСЯ объектами? Каким макаром SSIM учитывает человеческие особенности восприятия ДВИЖУЩИХСЯ объектов, например?
| | |
|
|
|
| 4.18, User294 (ok), 11:51, 07/07/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Таки ничего лучше пока не придумали.
Дело в том что на ДВИЖУЩИХСЯ объектах глаз человека вообще не воспринимает мелкие детали. Посему насколько такое сравнение соответствует тому как будет воспринят ролик при просмотре - большой вопрос, имхо. Безусловно, красивый стопкадр тоже фича, но явно не главная для ВИДЕОкодека, основная задача которого - движущиеся картинки.
| | |
| |
| |
| 6.23, User294 (ok), 13:12, 07/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
И чего? Просто сравнение стопкадров самих по себе - вообще не факт что является адекватным сравнением ВИДЕОкодеков. Это же не ФОТОкодеки, правда? Да и как правильно кто-то заметил, расстановка key frames (I-frames в мпег) может порядком отличаться. Стратегия расстановки кейфреймов конечно тоже часть логики кодека, влияющая на качество картинки и вообще баланс битрейт-качество кодека. Однако, почему-то мало кто учитывает что эта логика может по разному работать, так что один кодек качественнее осилит одни сцены, а другой - другие. По логике вещей соотношение качества кадров надо бы смотреть по всему мувику. Правда вот что такое соотношени качества для ДВИЖУЩЕЙСЯ картинки (которую не совсем корректно анализировать как стопкадры) - кажется так никто толком и не придумал so far.
| | |
|
|
|
|
|
| 1.7, emg81 (?), 03:32, 07/07/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
>Хотелось бы увидеть стоп-кадры всех троих при заданных битрейтах.
Вы, наверное, знаете, что есть три типа фреймов - I,P,B. лучшее качество и больший размер у I, это ключевые кадры. худшее качество - у B - это кадры-заполнения, грубо говоря. Так вот I-фрейм и B-фрейм в разных видеосэмплах могут выпасть на 1 кадр, как раз который мы сравниваем (а это бывает часто, т.к. порядок B-фреймов и их количество, а также частоту I-фреймов практически всегда меняют, и в разных кодировщиках по-умолчанию стоят разные показатели. Поэтому стоп-кадр - не самый лучший вариант для сравнения. к тому же при пресетах.
-
и да, я пробовал кодировать этим кодеком (пришлось патчить мплеер/менкодер). и theora тоже пробовал с интересом и надеждой.
очень хотелось бы, чтобы его доделали / улучшили, т.к. поклонник опенсорса. но, констатирую факт, рядом с x264 (привет стандарту Н264) им и не кодировали
-
>Разработчики кодека VP8 прокомментировали результаты, подчеркнув, что проблемы >с качеством скорее всего вызваны тем, что кодированию подвергался поток, уже >ранее подвергавшийся сжатию другим кодеком
и чего? вообще-то многие рипуют и перериповывают с рипов (с BD делают BDRip-1080/720, с BDRip1080/720 нередко делают HQRip-AVC и просто HQRip на пару гигов. если для VP8 это проблема, то это крайне плохо, значит, как кодек он ещё не готов.
это только моё личное мнение и я не утверждаю, что оно правильное
| | |
| |
| 2.9, Alex__S (?), 04:53, 07/07/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Вы, наверное, знаете, что есть три типа фреймов - I,P,B. лучшее качество
>и больший размер у I, это ключевые кадры. худшее качество -
>у B - это кадры-заполнения, грубо говоря. Так вот I-фрейм и
>B-фрейм в разных видеосэмплах могут выпасть на 1 кадр, как раз
>который мы сравниваем (а это бывает часто, т.к. порядок B-фреймов и
>их количество, а также частоту I-фреймов практически всегда меняют, и в
>разных кодировщиках по-умолчанию стоят разные показатели. Поэтому стоп-кадр - не самый
>лучший вариант для сравнения. к тому же при пресетах.
вы, наверное, знаете, что , взяв отдельный P или B-фрейм вы , скорее всего, не получите внятной картинки вообще. Грубо говоря "кадр" при выводе - это результат обработки всех фреймов с момента получения последнего ключевого.
то есть - сравнивать отдельно I, P и B фреймы - смысла нет . как и говорить о "качестве" P и B фреймов..
| | |
| |
| 3.10, anonymous (??), 07:06, 07/07/2010 [^] [^^] [^^^] [ответить]
| +2 +/– | |
прикидываемся? Ежу понятно что речь шла не о IPB порциях кодированного потока а отображаемые на экране кадры, уже раскодированные из этих IPB, и в одном кодеке могут выбрать 778 кадр как опорный I а другой кодек этот 778 кадр выберет как P или B.
Счастливый горе-тестировщик выложит скриншоты этих кадров и на основании этого будет делать очень далеко идущие выводы что второй кодер плохой.
К.О
| | |
| |
| 4.14, ptr (??), 10:06, 07/07/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Вообще-то, близость к оригиналу кадров, сформированных из I, P и B фреймов зависит от кучи параметров.
Например, при низком битрейте на статических сценах кадр из I фрейма будет существенно уступать по качеству последующим. По той простой причине, что кодировщик физически не сможет впихнуть в него всю информацию, зато последующими кадрами "уточнит" статическую картинку.
Обратный пример - низкий битрейт и сильная динамика.
Далее, выбор ключевых кадров - это вообще-то и есть задача кодировщика (если это не MPEG-2, конечно, где GOP фиксирован). Другое дело, что по одному кадру сравнивать кодировщики видео - бредовое занятие. Желательна серия последовательных кадров, причем одна серия для статики, другая для динамических сцен.
| | |
| |
| 5.29, User294 (ok), 01:58, 08/07/2010 [^] [^^] [^^^] [ответить] | +/– | Это по идее зависит от того что кодеку можно Если ему можно задирать битрейт - ... большой текст свёрнут, показать | | |
|
|
|
| 2.16, gkv311 (ok), 10:27, 07/07/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
 >>Разработчики кодека VP8 прокомментировали результаты, подчеркнув, что проблемы
>>с качеством скорее всего вызваны тем, что кодированию подвергался поток, уже
>>ранее подвергавшийся сжатию другим кодеком
>и чего? вообще-то многие рипуют и перериповывают с рипов (с BD делают BDRip-1080/720,
>с BDRip1080/720 нередко делают HQRip-AVC и просто HQRip на пару гигов.
>если для VP8 это проблема, то это крайне плохо, значит, как кодек он ещё не готов.
>это только моё личное мнение и я не утверждаю, что оно правильное
Проблема в том, что VP* кодеры имеют иной характер искажений как результат сжатия (по отношению к популярной серии MPEG4). Поэтому когда ПЕРЕкодируется поток, изначально сжатый MPEG4, в VP*, то мы получаем сложение обоих искажений, тогда как при перекодировании его же снова в MPEG4 отпечаток как бы накладывается тот же и приводит к значительно меньшему ухудшению качества.
Поэтому и говорится, что сравнивать качество алгоритмов сжатия можно только используя несжатый оригинал (который обычно не доступен, в лучшем случае можно экспериментировать со слабосжатыми толстыми потоками). Уверен, что никто и не пытался сравнивать качество изначально сжатого в VP* видео, перекодированного снова в VP* с перекодированным в MPEG4.
Что касается (пере)рипов, то использовать разные промежуточные кодеки едва ли имеет много смысла, универсальных кодеков и универсальных параметров для любого видео пока не существует.
| | |
| |
| 3.28, User294 (ok), 13:40, 07/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Проблема в том, что VP* кодеры имеют иной характер искажений как результат
>сжатия (по отношению к популярной серии MPEG4). Поэтому когда ПЕРЕкодируется поток,
>изначально сжатый MPEG4, в VP*, то мы получаем сложение обоих искажений,
>тогда как при перекодировании его же снова в MPEG4 отпечаток как
>бы накладывается тот же и приводит к значительно меньшему ухудшению качества.
Именно, поэтому сравнивать надо на изначально несжатых сценах, только вот с их доступностью бывают определенные проблемы. Я знаю аж 2 мувика для которых реально нарыть несжатые сцены: Elephant Dreams и Big Bucks Bunny. Но это computer generated картинки, несколько отличные от типичного видео.
| | |
|
|
| 1.13, sluge (ok), 09:55, 07/07/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 это типа мгушники занялись кодированием видео? ну надеюсь от них будет толк, не разбегутс по коммерческим конторам
| | |
| |
| |
| |
| 4.27, User294 (ok), 13:37, 07/07/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>И как результат?
Сходите на их сайт да посмотрите. Часть результатов - вполне себе общедоступна.
| | |
|
|
| 2.26, User294 (ok), 13:34, 07/07/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>это типа мгушники занялись кодированием видео?
Они уже давно занимаются. И, строго говоря, чуть ли не единственные кто пытается хоть как-то подогнать все это под научные основы. Насколько оно им удается - хрен бы его знает, но более хороших сравений все-равно никто не осилил ;).Кстати из их сравнений видно еще и забавный факт: GPLный x.264 по битрейт-качество делает практически все коммерческие энкодеры H.264.
| | |
|
|
