> Скорее значение имеет то, что x264 разрабатывается высокопрофессиональным открытым сообществом. И это в том числе.
> "Оппонент" же напротив долго пилился умирающей проприетарной конторкой, а сейчас над ним
> трудятся толпы индусов. Результат, как говорится, налицо.
Угу, среди этой толпы индусов - всякие там разработчики ffmpeg, почему-то финики делающие чипы и прочая. В общем когда надо - гугля умеет надирать задницы и перетягивать умных парней к себе. И им оно похоже стало надо. Они это делают. Неплохо делают, судя по логам коммитов. Индусы пишущие оптимизацию под ARM, на асме, с юзежом SIMD команд - это как минимум весьма редкое и маловероятное явление природы.
>> Это с хрена ли VP3 будет выглядеть предпочтительнее VP8?
> Вам же сотни раз объясняли, VP8 "мажет" картинку. Theora 1.1 сохраняет фактуру
> там где в WebM сплошное "мыло".
Чтобы он стал мылом - должно откровенно не хватить битрейта. И если битрейта не хватает - в общем то сольется любой кодек, с теми или иными артефактами. Более или менее заметными глазу. Ну не бывает чудес в природе - если битрейта мало, значит какие-то параметры картинки при передаче придется загрубить. И всегда наступит момент когда обман станет заметен. Вопрос только в том сколько данных удастся выбросить до того как двуногие начнут замечать существенные отличия от оригинала. А мазание картинки кстати ИМХО неплохой метод сэкономить битрейт на быстро движущихся сценах, т.к. глаз там один фиг не замечает мелкие быстро движущиеся объекты из-за особенностей человеческого зрения. Ну и напуркуа бы битрейт тратить на то что никто не разглядит? Статичные сцены... вот тут я заметил что в 1-проходном режиме vpxenc может ступить и очень пессимистично занизить битрейт и засрать сцену (получив в итоге поток с здорово меньшим битрейтом чем его просили, кстати). В 2-проходном режиме он зато пунктуален как швейцарские часы и раскидывает доступный битрейт намного лучше. В этом режиме по чисто визуальному качеству мувик пожатый vp8 вполне себе порубается с мувиком пожатым базовым профайлом H.264.
> И устранять это по ходу никто не собирается (возможно, будет нарушен формат
> битового потока)
C каких пор деблокинг вдруг стал багом а не фичой? Мсье поклонник теплых ламповых квадратиков эпохи ранних мпегов, когда деблокинг никто не делал т.к. не хватало CPU и вся сущность DCT преобразований над блоками просто вопиюще лезла на глаза в виде нестыковки цветов границ блоков акa "характерные мпеговские квадратики"? Не, спасибо, характерное рассыпание интенсивных сцен на разноцветные квадратики не заметит только крот, сидящий к монитору задом. Деблокинг лучше чем его отсутствие с точки зрения вырвиглазности итоговой картинки. Ну не для красоты же его придумали, правда?
