https://opennet.dev/openforum/vsluhforumID3/92882.html Выпущена (http://code.google.com/p/webm/source/browse/CHANGELOG?repo=libvpx) версия 1.3.0 библиотеки libvpx, в рамках которой развивается реализации свободного видеокодека VP8 (http://www.opennet.ru/opennews/art.shtml?num=26656). Основным новшеством в данной версии библиотеки является добавление поддержки использования нового кодека VP9 (http://www.opennet.ru/opennews/art.shtml?num=37195), отличающегося улучшенным соотношением битрейт/качество (по некоторым оценкам, поток с равным визуальным качеством может иметь на 50% более низкий битрейт).<br><br><br>Отмечается, что добавление кодека VP9 сделано в обратно-совместимом виде: те, кто использовал библиотеку для кодирования VP8 не заметят никаких изменений. Тем не менее, у кодека VP9 иной набор опций, не полностью соответствующий опциям кодека VP8. Кроме этого, реализация кодировщика VP9 в данный момент поддерживает не все возможности кодека. Заинтересованным в более полном использовании возможностей кодека VP9 предлагается обратить внимание на ветку git master (http: https://opennet.dev/openforum/vsluhforumID3/92882.html#17 Tue, 03 Dec 2013 12:53:16 GMT libvpx собирается. под x86, amd64, arm и mips. Как по мне - для кодека этого вполне достаточно.<br> https://opennet.dev/openforum/vsluhforumID3/92882.html#16 Mon, 02 Dec 2013 12:01:08 GMT Я и не спорю, что развивается. И я только за.<br>Но не надо путать вкусное с полезным.<br><br>&gt; А что-то IETF-а, который бы улучшал референсную реализацию H.265 я в упор не вижу.<br><br>Референсный код и не надо улучшать - на то он и референсный. Он должен быть 100% рабочим и как можно более понятным.<br>&gt; Про то чтобы горе-стандартизаторы выложили вменяемый референсный кодек под нормальной лицензией, показывающий "а как это вообще делать?" - не дождешься.<br><br>Это все есть, "но надо заплатить".<br><br>&gt; А тут готовая либа которую взял да поюзал.<br><br>Да, но только под теми платформами, для которых оно запилено. В отличие от конкурентов, код которых можно легко понять и запилить не только на любых своих платформах, но и в железе.<br><br>&gt; Если зудит улучшить - опять же, логично базироваться на этой либе как раз.<br><br>Код смотрели? Впрочем, в сравнении с vp8 - да, стало получше. Но все еще недостаточно.<br><br>&gt; Благо условия лицензирования - полная халява.<br><br>Это *единственный* плюс vp9.<br><br>&gt; Они были бы редкими глупцами, если бы потратили бол https://opennet.dev/openforum/vsluhforumID3/92882.html#15 Sun, 01 Dec 2013 20:34:19 GMT &gt; Референсный кодер от гугла - редкое барахло.<br><br>Да вот знаете, гугл кодировщик VP9 улучшает семимильными шагами, и это еще и раздается на вполне вкусных условиях. И либа, и кодировщики показывающие как этой либой пользоваться. Отличный наборчик на самом деле: на примере реальных программ показано как их библу юзать.<br><br>А что-то IETF-а, который бы улучшал референсную реализацию H.265 я в упор не вижу. Есть какие-то совершенно сторонние инициативы, но они вообще ни разу не заслуга стандартизаторов. Про то чтобы горе-стандартизаторы выложили вменяемый референсный кодек под нормальной лицензией, показывающий "а как это вообще делать?" - не дождешься.<br><br>И да, поскольку кодек на 10% спеки и на 90% реализация, толку то со спеков. Вы будете несколько лет вкалывать чтобы получить хоть какое-то подобие конкурентоспособного кодировщика. А тут готовая либа которую взял да поюзал. Если зудит улучшить - опять же, логично базироваться на этой либе как раз. Благо условия лицензирования - полная халява. А гугл как компания https://opennet.dev/openforum/vsluhforumID3/92882.html#14 Sat, 30 Nov 2013 18:03:49 GMT Референсный кодер от гугла - редкое барахло. Как и "стандарт", вредставляющий из себя по большей части куски сырого кода без вменяемых комментариев.<br> https://opennet.dev/openforum/vsluhforumID3/92882.html#13 Fri, 29 Nov 2013 19:16:38 GMT &gt;&gt; студент) реализацию для фпга для простейшего случая. Болт клали с ответом.<br>&gt; Ты кто такой? Студент? Давай, до свиданья.<br><br>Могли и просто письмо про...ть. На сайте написано что они весьма заинтересованы в улучшении fpga версии. На данный момент она по их утверждениям бесполезна - максимум SD разрешение тянет.<br> https://opennet.dev/openforum/vsluhforumID3/92882.html#12 Fri, 29 Nov 2013 19:13:55 GMT &gt; Стандарты от MPEG в этом плане НАМНОГО качественнее.<br><br>Зато у них другие проблемы:<br>1) Патентные грабли разложены в самом видном месте. Ыкспертам из группы - пофигу на проблему. Замечательно, ага. Как хотите так и долбитесь, дорогие реализаторы. С другой стороны гугл правдами и неправдами вышиб условия позволяющие royalty-free распостранение и явным образом разрешает юзать патенты.<br><br>2) Референсная реализация хоть того же H.264 от мпега - полный шит. Да еще на конских условиях. А гугл дает референсный кодировщик. Довольно качественный. Под весьма либеральной лицензией. Спеки это прекрасно, но это 10%. А остальные 90% - это кодинг кодека который по этим спекам что-то не слишком поганое выдать потом сможет. А то вон H.264 от адобы жмет хуже xvid по битрейт-качество, например. Как видишь, хорошие спеки - еще не гарантия хорошего результата.<br><br>3) Жеолезячная реализация кодера/декодера? У гугли не только есть но они еще и раздают сие желающим. На royalty-free условиях. Как бы удачи дождаться такого от MPEG и п https://opennet.dev/openforum/vsluhforumID3/92882.html#11 Fri, 29 Nov 2013 19:07:52 GMT &gt; Код хардвара они похоже только своим корпорашкам отдают.<br><br>Там написано что любой желающий может намылить и запросить копию сорца. Собственно, а что ты будешь с оным кодом делать? Про FPGA там сказано что получается медленно и печально, HD не потянет. А ASIC сделать у тебя все-равно денег не хватит.<br> https://opennet.dev/openforum/vsluhforumID3/92882.html#10 Fri, 29 Nov 2013 18:28:08 GMT Любой каприз за ваши деньги ©<br> https://opennet.dev/openforum/vsluhforumID3/92882.html#9 Fri, 29 Nov 2013 17:41:43 GMT Анон, если на похорониксе что-то написано, то это не значит, что это правда. Релиза ещё не было.<br>