| 1.1, gegMOPO4 (ok), 13:11, 09/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –8 +/– |
 > по сравнению с первым вариантом кодировщика
Да, хорошо сравнивать с 1913 годом.
| | |
| |
| |
| 3.20, gegMOPO4 (ok), 17:13, 09/03/2011 [^] [^^] [^^^] [ответить]
| +4 +/– | |
Для тех, кто не помнит -- при Союзе была традиция сравнивать любые показатели (производство чугуна, количество автомобилей на душу населения) с 1913 годом. Получали умопомрачительные проценты прогресса, даже во времена застоя.
Так и тут, сравнивать третью версию с первой, давным давно улучшенной ко второй, -- это просто такой грязный маркетинговый трюк, чтобы числа внушительнее выглядели. В том, что стало быстрее в 4.7 раза, заслуга не столько третьей версии (в 1.35), как второй (в 3.3). Сравнивать новую версию имеет смысл только с предыдущей (если, разумеется, в предыдущей не было регресса), точнее -- с лучшей из прошлых.
| | |
| |
| 4.29, eve (?), 21:02, 09/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>Для тех, кто не помнит - при Союзе была традиция
У кого была традиция? И что все 74 года производство чугуна и т.д. сравнивали с 1913 годом?
| | |
| |
| 5.30, anonim (?), 22:20, 09/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да!
за все 74 года не скажу, а в 75-90 сравнивали именно с ним. Посмотри любой учебник по истории этого периода.
| | |
| |
| 6.31, eve (?), 00:57, 10/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Да!
> за все 74 года не скажу, а в 75-90 сравнивали именно с
> ним. Посмотри любой учебник по истории этого периода.
Ссылку гони на учебник ибо есть мнение, что сравнивали не только с 1913, а и с довоенным и послевоенным дабы показать прогресс. Что есть правильно.
| | |
|
|
| 4.37, Тот_Самый_Анонимус (?), 06:24, 10/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
Враньё. Не только с 1913 сравнивали. А в тех случаях, когда был 1913 (и такое было) так сравнивали с самым успешным годом по Российской империи. Если бы с 1914 или 1915 сравнивали, тогда бы и свистел о подтасовках.
| | |
|
|
|
| 1.4, Аноним (-), 13:47, 09/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +9 +/– |
> Качества кодирования в режиме "Best" по сравнению с прошлой версией увеличено на 6.3%
> За счет использования улучшенного двухпроходного режима контроля интенсивности потока достигнут более постоянный высокий уровень качества для всего видео клипа;
> Значительно улучшено качество
> Улучшено качество кодирования
Радость! Несмотря на нетронутый формат файла, по-видимому ещё есть куда увеличивать качество. Догоним и перегоним H.264!
| | |
| |
| 2.7, Zenitur (ok), 14:47, 09/03/2011 [^] [^^] [^^^] [ответить]
| –4 +/– |
 Ну конечно есть. В лучшем качестве (я кодировал несколько видео с разной динамикой и длинной) в среднем в h264 получалось например 3 Мб, а в WebM - 4,5 Мб, при полностью одинаковом качестве получившегося видео. Стремиться куда есть.
| | |
| |
| 3.10, anonymous (??), 15:09, 09/03/2011 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>В лучшем качестве (я кодировал несколько видео с разной динамикой и длинной) в среднем в h264 получалось например 3 Мб, а в WebM - 4,5 Мб, при полностью одинаковом качестве получившегося видео.
Ой не смеши. До сих пор сами разработчики x264 спорят со страшной силой улучшилось ли качество картинки при добаылении психовизуальных оптимизаций, можно ли ставнивать квчество видеопотока по отдельным кадрам, стоит ли доверять стввнению PSNR или даже SSIM и так далее. И это при настоящих слепых тестах (кто то выкладывает серию видеофрагментов без подписчи какими опциями сжато а остальные должны угадать). Банально кому то нравится больше теплое ламповое сглаживание артефактов кодировщика WebM, ктото прется от высокочастотного шума ошибок на x264 думая что это и есть детали изображения.
Я вот так же скажу :
В лучшем качестве (я кодировал несколько видео с разной динамикой и длинной) в среднем в Webm получалось например 3 Мб, а в x264 - 4,5 Мб, при полностью одинаковом качестве получившегося видео.
Единственно где x264 гарантировано уделывал первые версии WebM это рипы длиннющих ворованых фильмов, в режиме нарушающем стандарт то есть при допущении любых вариаций потока без ограничений что можно распаковать только на топовом железе и никакая встроеная железка не проглотит. Подозреваю что
>За счет использования улучшенного двухпроходного режима контроля интенсивности потока достигнут более постоянный высокий уровень качества для всего видео клипа;
и есть эта самая фишка, раньше пишут что в начале клипа было слишкомхорошее качество а к концу соответственно ниже среднего.
| | |
| |
| 4.13, Аноним (-), 15:12, 09/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Подозреваю что
>>За счет использования улучшенного двухпроходного режима контроля интенсивности потока достигнут более постоянный высокий уровень качества для всего видео клипа;
> и есть эта самая фишка, раньше пишут что в начале клипа было слишкомхорошее качество а к концу соответственно ниже среднего.
Кстати, о том же подумал. Помню, в первых версиях писали об ошибке распределения битрейта, который вычисляется в первом проходе, по фильму во втором проходе, сдвиг по времени там что ли какой-то был, который весь профит от первого прохода сводил на нет.
| | |
| 4.23, манна (?), 17:38, 09/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
Сразу видно грамотного собеседника
> в режиме нарушающем стандарт то есть при допущении любых вариаций потока без ограничений что можно распаковать только на топовом железе и никакая встроеная железка не проглотит
Просьба не путать валидный битовый поток с ограничениями профайлов.
> За счет использования улучшенного двухпроходного режима контроля интенсивности потока достигнут более постоянный высокий уровень качества для всего видео клипа
Двухпроходное кодирование используется для попадания в размер, а не для улучшения качества.
| | |
| |
| 5.25, Аноним (-), 19:18, 09/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Двухпроходное кодирование используется для попадания в размер, а не для улучшения качества.
В том числе и для улучшения качества, выделяя из среднего битрейта ту дозу, которая требуется для конкретного кадра и уменьшая его для того кадра, где большой не требуется.
| | |
| |
| 6.27, codec (?), 20:37, 09/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
Да полно вам. Кодировщику вполне достаточно выделяемого буфера для хранения и обсчета опорных кадров.
| | |
| |
| 7.36, User294 (ok), 05:39, 10/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > Да полно вам. Кодировщику вполне достаточно выделяемого буфера для хранения и обсчета
> опорных кадров.
В выделяемый буфер особо много кадров не положишь - посчитайте размер одного кадра HD видео. И скажите сколько их таких вы готовы закешировать для анализа "в будущем"? Оператива то не резиновая, а кодек не единственная программа на компе, вы прикиньте?! А при 2-проходном кодировании вы наперед знаете сложность ВСЕХ сцен в будущем (по логу первого прохода) - можно принимать решение о выделении битов уже "заранее" зная что подсунут, так что кодек куда точнее может оценить сколько битов куда раскинуть следует, не проявляя необоснованного пессимизма который в 1-проходном режиме неизбежен чтобы избежать длительного многократного превышения желаемой скорости которое вызовет опустошение буфера и срыв воспроизведения (для онлайн видео сие как бы весьма и весьма актуально).
| | |
|
|
| 5.32, User294 (ok), 03:10, 10/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Просьба не путать валидный битовый поток с ограничениями профайлов.
Да, только вот железок способных прожевать ЛЮБОЙ битовый поток, включая high профайл на этой планете не так уж много. А большая часть согласны жрать лишь базовый профайл, особенно этим грешат мобильные девайсы. А у базового профайла качество - вполне сравнимо с VP8, так что гугл весьма грамотно подсуетился и правильно нагнул распоясавшихся MPEG LA. А то они совсем оборзели - вплоть до изменения условий лицензирования задним числом.
| | |
| 5.35, User294 (ok), 05:33, 10/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Двухпроходное кодирование используется для попадания в размер, а не для улучшения качества.
Оно позволяет при равном размере файла получить более хорошее качество картинки. При одном проходе есть довольно противная проблема: кодек не знает что ему подсунут через N кадров в будущем, насколько сцена будет сложна в кодировании и какой резерв битов на самом деле у него есть на момент кодирования текущего кадра. Это вынуждает кодек проявлять некий пессимизм чтобы избежать ситуации "полчаса подряд битрейт был в 3 раза выше изначально желаемого среднего битрейта - буфер постоянно опустошался, юзер чертыхался". В случае 2-проходного кодирования кодек знает сложность сцен в будущем и может куда более точно оценить куда и сколько битов оптимальнее было бы выделить, что ессно способствует более качественной картинке - "добавочные" биты более точно попадают в сцены которые в них нуждаются, что хорошо влияет на отсутствие видимых артефактов в этих сценах :)
| | |
|
|
| 3.11, devcoder (ok), 15:09, 09/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > при полностью одинаковом качестве получившегося видео
А чем сравнивал, глазами?
| | |
| |
| 4.16, Аноним123321 (ok), 16:29, 09/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 это он 20й-раз рассказывает свою иссторию о том как он сначало закодировал видио из рабочего стола (баги программы Wine) в какойто-MPEG-формат хорошего качества (НО С ПОТЕРЯМИ!) ,
, а потом перекодировал это: в WebM/Vp8 и H.264
и в WebM/Vp8 -- получилось размера больше (оно и ясно -- перекодировка всётаки играет свою роль)
| | |
| |
| 5.18, Zenitur (ok), 16:36, 09/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> видио
Видио? Ты не поверишь, но у меня дневник есть, и я туда выкладываю видЕо с тэгом <video>.
| | |
|
| 4.17, Zenitur (ok), 16:30, 09/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
Глазами конечно. Вот например Theora сльно напоминает WMV с одинаковым битрейтом, а WebM - h264, но при одинаковом качестве размер файла чуть больше.
| | |
| |
| 5.19, devcoder (ok), 17:12, 09/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
Скорость кодирования/декодирования не замерял?
И откуда источники видео первоначально были сняты (камера, тв)
и в каком формате yuv420 или yuv422?
| | |
| |
| 6.21, Zenitur (ok), 17:18, 09/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
yuv420, Web-камера + с экрана монитора спецпрограммой. Скорость кодирования не замерял, субъективно WebM заметно быстрее кодирует.
| | |
|
| 5.34, User294 (ok), 05:21, 10/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> а WebM - h264, но при одинаковом качестве размер файла чуть больше.
У webm артефакты какие-то другие. Менее заметные чем "звон" вокруг четких границ и квадратики типичные для мпега на мою имху. У VP8 картинка просто становится более размытой, но квадратиков практически не видно, в отличие от. Кстати понравиолсь что гугловцы грамотно твиканули кодирование переходов между сценами.
| | |
|
|
|
|
| |
| 2.33, User294 (ok), 03:19, 10/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> За год они даже близко не приблизились к показателям DivX.
А что есть DivX? Если вы про простые MPEG4 кодеки с данным названием - то vp8 уже давно на его уровне и даже получше, пожалуй, на нежатом контенте. Если вы про DivX Plus который H.264 в матрешке - так там от дивикса только название и осталось, пожалуй, а проблемы все те же что и у H.264 как то - без геморроя и не заплатив юзать его данный формат можно сильно местами, там где у США и мпеглы руки коротки :)))
| | |
|
|
