https://opennet.ru/openforum/vsluhforumID3/68296.html Разработчики проекта FFmpeg написали (http://blogs.gnome.org/rbultje/2010/06/27/googles-vp8-video-codec/) с нуля собственную реализацию декодера для видеокодека VP8 (http://www.opennet.ru/opennews/art.shtml?num=26656), в мае открытого компанией Google. Примечательно, что благодаря использованию уже присутствующих в FFmpeg типовых функций, декодер уместился в 1400 строк на языке Си, включая комментарии и пустые строки, плюс 450 строк для задействования функций DSP. Для сравнения, оригинальный декодер libvpx от Google насчитывает около 11 тыс. строк кода. Корректность работы нового декодера была проверена с использованием специального тестового комплекта для VP8, выходной поток оказался бинарно идентичен с эталонным потоком.<br><br><br>Среди достоинств нового декодера названа тесная интеграция с общей кодовой базой FFmpeg. По словам разработчиков, возможна не только организация совместного использования кода для всей серии кодеков VPx (у VP8 много общего с VP5/6/7), но и совместное использовани...<br><br>URL: http://blogs.g https://opennet.ru/openforum/vsluhforumID3/68296.html#19 Wed, 30 Jun 2010 02:19:47 GMT Реализация была дирак или шр&#235;дингер? Последний, вроде, специально на скорость точат.<br> https://opennet.ru/openforum/vsluhforumID3/68296.html#18 Tue, 29 Jun 2010 19:39:05 GMT а я всё равно буду юзать вебморду. и открыл когда надо и не мешается и памяти жрет минимум. <br> https://opennet.ru/openforum/vsluhforumID3/68296.html#17 Tue, 29 Jun 2010 17:50:27 GMT почему - читайте мой пост выше - они пишут что исходники взяты уже закодированные с помощью MPEG<br> https://opennet.ru/openforum/vsluhforumID3/68296.html#16 Tue, 29 Jun 2010 16:06:49 GMT Пробовал Дирак. Внешне на чистом источнике не хуже h264 был, но он медленнее даже VP7 кодера, очень медленный.<br> https://opennet.ru/openforum/vsluhforumID3/68296.html#15 Tue, 29 Jun 2010 15:12:23 GMT Интересно было бы добавить Dirac туда. Википедия говорит, что "Dirac Pro was used internally by the BBC to transmit HDTV pictures at the Beijing Olympics in 2008."<br> https://opennet.ru/openforum/vsluhforumID3/68296.html#14 Tue, 29 Jun 2010 14:11:27 GMT &gt;И из тестов видно что кодек сильнее xvid-а и по битрейт-качество наступает на пятки<br>&gt;h.264, зачастую уделывая простые/быстрые профайлы/настройки но сливая наиболее &gt;качественным.<br><br>Ему бы ещё скорости прибавить, раз эдак в 5-20, и можно было бы говорить о реальной конкуренции с H.264. Хотя по качеству VP8 всё-таки уступает, и учитывая стандартизацию его битового формата, на какие-то серьёзные улучшения в этой части расчитывать не приходится.<br> https://opennet.ru/openforum/vsluhforumID3/68296.html#13 Tue, 29 Jun 2010 12:33:35 GMT Эти человеки вполне серьезно тестят кодеки. И из тестов видно что кодек сильнее xvid-а и по битрейт-качество наступает на пятки h.264, зачастую уделывая простые/быстрые профайлы/настройки но сливая наиболее качественным. В целом недурно для кодека который выпущен без году неделя.<br> https://opennet.ru/openforum/vsluhforumID3/68296.html#12 Tue, 29 Jun 2010 06:56:01 GMT We've been following the MSU tests since they began and respect the group's work. One issue we noticed in the test is that most input sequences were previously compressed using other codecs. These sequences have an inherent bias against VP8 in recompression tests. As pointed out by other developers, H.264 and MPEG-like encoders have slight advantages in reproducing some of their own typical artifacts, which helps their objective measurement numbers but not necessarily visual quality. This is reflected by relatively better results for VP8 on the only uncompressed input sequence, "mobile calendar."<br><br>Even with this limitation, VP8 delivered respectable results against other encoders, especially considering this is the first time VP8 has been included in the test and VP8 has not been specifically optimized for SSIM as some other codecs have. <br> https://opennet.ru/openforum/vsluhforumID3/68296.html#11 Tue, 29 Jun 2010 06:48:45 GMT Порево иногда выкладывали в этом формате.<br>