После полутора лет разработки представлен (https://groups.google.com/a/webmproject.org/forum/#!topic/co...) выпуск библиотеки libvpx 1.4.0 (http://www.webmproject.org/), в рамках которой развиваются эталонные реализации свободных видеокодеков VP8 (http://www.opennet.me/opennews/art.shtml?num=26656) и VP9 (http://www.opennet.me/opennews/art.shtml?num=37195). Код libvpx распространяется под лицензией BSD. Компания Google делегировала неограниченному кругу лиц возможность безвозмездного использования всех патентов, касающихся заложенных в VP8 и VP9 технологий, и отказалась от сбора каких либо отчислений (royalty-free).
По результатам внутреннего тестирования кодек VP9 кодирует видео значительно эффективнее (при аналогичном уровне сжатия удаётся упаковать видео с более высоким качеством картинки), чем VP8 или лучшие реализации H.264 high profile, и даже немного обгоняет H.265 (HEVC). Особенностью VP9 также является адаптация декодера для работы на маломощных встраиваемых устройствах и предоставление широкого спектра режимов качества, в том числе для кодирования без потерь. Из задействованных в VP9 новых технологий можно отметить применение новых структур кодирования (квадродеревьев), поддержка использования в качестве суперблоков областей в 32x32 и 64x64 пикселей, возможность трансформации DCT (8x8, 16x16) и ADST (4x4, 8x8, 16x16), улучшенный алгоритм предсказания межкадровых изменений, улучшенная модель энтропийного кодирования, новые методы объединения схожих блоков в сегменты. Кодек VP9 интегрирован в кодовые базы браузеров Chrome и Firefox, а также таких открытых проектов, как VLC, FFmpeg и GStreamer.
Основные новшества libvpx 1.4.0:
- По умолчанию включен режим многопоточного кодирования, распределяющий работу на несколько ядер CPU. Доступно два режима распределения заданий по потоком: мозаичное кодирование, с разделением картинки на несколько блоков, каждый из которых обрабатывается в разном потоке, и разбиение на кадры, при котором разные кадры обсчитываются в разных потоках;- Добавлены дополнительные опции (http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide) для управления кодеком VP9;
- Значительно улучшены алгоритмы кодирования VP9;
- Добавлена поддержка цветовых пространств YUV 4:2:2 и 4:4:4, а также режимов с 10- и 12-битами на цветовой канал;
- Проведена дополнительная оптимизация функций кодирования и декодирования VP9;
- Поддержка 64-разрядных платформ ARM;
- Нарушение совместимости с выпуском 1.3 на уровне ABI (вызовы IMG_FMT_* заменены на VPX_IMG_FMT_*). Удалена функция obj_int_extract.Из планов на будущее отмечается усовершенствование средств для кодирования потоков в режиме реального времени и экспериментирование с многопоточным декодированием.
URL: https://groups.google.com/a/webmproject.org/forum/#!topic/co...
Новость: http://www.opennet.me/opennews/art.shtml?num=41972
А на повседневных устройствах типа телеков и dvd/bd плейеров уже реализован этот кодек?
Там же какие-то микросхемные реализации этого кодека делать надо?
Не знаю как там насчет DVD плееров (кто-то их еще покупает?), а многие новые SoC умеют как минимум аппаратное декодирование VP8, а более новые - и VP9. И любой телевизор может это все проигрывать. При помощи довеска размером с флешку.
>А на повседневных устройствах типа телеков и dvd/bd плейеров уже реализован этот кодек?у меня смартфон на чипе Mediatek умеет аппаратно декодировать VP9
>Там же какие-то микросхемные реализации этого кодека делать надо?
да, и гугл даже сделал открытую схему в формате Verilog
Это раньше выпускали специализированные чипы. Сейчас это нецелесообразно. Аппаратная поддержка реализуется программно. На процессорах за счет задействования sse и avx, на видео - за счет вычисления на унифицированных шейдерных блоках. Т.е. задача ограничивается написанием специализированного кода.
SSE/AVX с унифицированными шейдерными блоками в телевизоре нужны только в том случае, если вы собираетесь играть на нём в скайрим. А для просмотра видео таки дешевле поставить туда какой-нибудь хиленький ARM со встроенным аппаратным декодером.
Достойный ответ на патентные замашки акул окучивающих H.265 :)
Достойным он будет, когда vp9 приблизится к скорости кодирования x264 и результатам, бьющими последнего с полной выкладкой сравнительных скриншотов и прочих psnr
Вам что-то мешает провести такое тестирование самостояетльно? Либа вышла же.
Я состарюсь, пока закодирую 10 минут через vp9
> Я состарюсь, пока закодирую 10 минут через vp9Какое же у вас время полураспада? Вы Нобелий-259?
Тебе надо - сравнивай :)
Свободное конечно хорошо, но по предыдущим версиям по показателям уступал HEVC, вряд ли всё разом кардинально поменялось.
> Свободное конечно хорошо, но по предыдущим версиям по показателям уступал HEVC,И где можно ознакомиться с результатами сравнений? Кодек вообще на 10% алгоритм и на 90% реализация. Да, вы знаете, H.264 в реализации от адобы - жал хуже чем даже XVID реализующий упрощенный вариант MPEG4. Не говоря уж про х264, где реализация намного качественнее.
Ну вот у гугли есть ресурсы чтобы сделать качественную реализацию кодека. А кто будет H.265 качественно реализовывать? И где это будет играться? VP9 можно браузеру скормить уже сейчас, если что, а 265 это даже в проекте не светит из-за патентных проблем.
> И где можно ознакомиться с результатами сравнений?Я ввёл в поисковик "vp9 h265 compare" - везде одно и тоже о превосходстве H265, смотришь на скрины - они лучше у h265.
Вот тут VP9 сливает везде http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X26...> А кто будет H.265 качественно реализовывать? И где это будет играться? VP9 можно браузеру скормить уже сейчас, если что, а 265 это даже в проекте не светит из-за патентных проблем.
Враньё, как раз гугл в хромиуме/хроме наверно первый и реализует, пока в процессе. Spartan от microsoft тоже реализует, про safari уже лень смотреть - c apple понятно что реализуют.
> Я ввёл в поисковик "vp9 h265 compare" - везде одно и тоже
> о превосходстве H265, смотришь на скрины - они лучше у h265.Особенно если спонсором MPEG LA выступает.
> Вот тут VP9 сливает вездеКхм? 2013 год? Препринт? oO А сейчас - 2015. Гугл тем временем два года въе, при том - не для красоты, как вы понимаете. А еще там в этой пдф прямо написано: E-mail: grois@ieee.org
Ну то-есть вы не придумали ничего умнее как прислать ссыль на заказной отчет двухлетней давности, сделанный перцем из IEEE-ее-ее, по заказу MPEG LA-aa-aa. А гетзефаксы от микрософта вы как, тоже будете цитировать?
> Враньё, как раз гугл в хромиуме/хроме наверно первый и реализует,
Для совсем тyпых - еще раз: VP9 в хроме и файрфоксе УЖЕ ПОДДЕРЖИВАЕТСЯ И ИГРАЕТСЯ. А H.265 вообще где? Особенно с такими страшилками как в соседней новости. То-есть, VP9 уже имеет некую фору и вполне конкретные юзкейсы: высококачественный контент в вебе - это VP9...
> пока в процессе.
Пока я вижу как у меня в браузере играется VP9. А никакого H.265 я там не вижу.
> Spartan от microsoft тоже реализует, про safari уже лень смотреть
> - c apple понятно что реализуют.Пожелаем им и дальше продолжить пике, пусть гугл их замочит а мозилла окончательно утрамбует земличку на могилке этих упырей :). А оно мне надо - платить роялти всяким пи...сам и заморачиваться их ИмПатентами, когда у гугля есть качественная референсная реализация кодека и их патенты может использовать кто угодно? :)
> заказной отчетЯ привёл тесты, которые нашёл (ещё было несколько других, везде такая же картина). Опровергни сылками на объективные сравнения, в которых и скриншоты по качеству и прочее.
> Для совсем тyпых - еще раз: VP9 в хроме и файрфоксе УЖЕ ПОДДЕРЖИВАЕТСЯ И ИГРАЕТСЯ
Поясняю. В фурифоксе пока с мультимедиа плохо, они до стабильного уровня MSE пока не довели. Chrome вообще имеет нормальное GPU декодирование только на венде (не проверял, это судя по их багтрекеру, знаю только что к сожалению на OS X и линукс с этим пока плохо). VP9 имеется только на одном сайте - гугловская тытруба. Отличная картина - да...
PS: Я говорю факты, хорошие они или нет, а ты только фанатское кококо
Вообще-то то, что этот сайт - гугловская тытруба, принципиально меняет дело. Это так, впридачу к аргументам, изложенным товарищем выше.
> Я привёл тесты, которые нашёл (ещё было несколько других, везде такая же
> картина). Опровергни сылками на объективные сравнения, в которых и скриншоты по
> качеству и прочее.Не скажу за "объективные сравнения" (а объективный критерий для видео - он какой? Те же SSIM и PSNR - сферические пyзомерки в вакууме) а кaчнуть 500Кбит зайца в VP9 можно вон там. Желающие могут поупражняться в кодировании и перeплюнуть - ссылка на нежaтый исходник я привел (правда H.265 мне скорее всего нечем смотреть будет, заодно и проверим как раз, если кому не лениво).
> Поясняю. В фурифоксе пока с мультимедиа плохо, они до стабильного уровня MSE
> пока не довели.MSE гугле надо для того чтобы ... такие как ты поменьше у них тыpили у них высококачественный контент ;). Одно дело файл с HTTP сервера кaчать, и совсем иное - если JS как-то кacтомно перекидывается с сервaком пакетами данных в произвольном формате, а файл как таковой на сервере может не существовать. JS попросит нечто - сервак нечто отдаст. А дальше скрипт сам разберется как это обрабатывать и кодеку отдать. Хочешь плюшку, хомячок? Ты ее получишь, со ВСЕМИ ингредиентами.
> Chrome вообще имеет нормальное GPU декодирование только на
> вeнде (не проверял, это судя по их багтрекеру, знаю только что
> к сожалению на OS X и линукс с этим пока плохо).В OS X вообще много с чем плохо. И графический стэк там - редкое г0внo! По скорости тамошний OpenGL сдeлает даже опенсорсная MESA, от чего макoфаги не так давно сyровo батхeртили на форониксе. Или вон в багтрекере лисы - кернелпаник макоси при открытии нескольких сайтов. С какими-то предъявами лисе (ага, файрфокс яблочным хомякам виноват что у яблока ядро или драйвера гни лые).
И да, знаешь, нынче даже смартфон может декодировать видео с интернетовским битрейтом софтварно, не говоря о более мощных устройствах типа писюков и ноутов, которым все это на один зубок. А куча писюков и ноутов, особенно старых - элементарно не имеют хардварный декодер на борту. Да и набор форматов там ограниченный. На писюках H.265 умеет играть полторы железки от нвидии. Ну и все. Они вроде как и VP8/9 поддерживают как раз.
> VP9 имеется только на одном сайте - гугловская тытрyба. Отличная картина - да...
Он имеется в общем то на любом сайте где админ это захотел. Если я слеплю десяток вхостов и закачаю туда пару мувиков - тебя это устроит? А то вон микрософтушка для пущей убедительности крутизны IIS по таким критериям вхосты с дефолтными зaтычками миллионами строгает :)
> PS: Я говорю факты, хорошие они или нет, а ты только фанатское кoкoкo
Интересные у тебя факты - типа сравнения двухлетней давности, от перца из IEEE. Нейтральные и совсем не предвзятые факты, ага.
А мои факты простые: я умею кодировать видео и в курсе как это устроено. И я вижу что VP9 это вполне качественный кодек на привлекательных условиях. Да еще браузерами играется. А тут высовываетесь вы и начинаете вещать про H.265, который собственно никто нигде не использует, железом он тоже не больно поддерживается, но кoкoкo о том какой он там более хороший - развели. При том что я вообще даже не уверен что он у меня хоть чем-то проиграется, для начала. Не говоря о том что я в этом формате ни 1 файла еще нигде не встречал.
> MSE гугле надо для того чтобы ... такие как ты поменьше у них тыpили у них высококачественный контентБлагодаря MSE, я наконец-то в 2015 году (дождались млин) могу смотреть онлайн трансляции без флеша, ну и флеш совсем удалил. А стырить видео и так не проблема с тытрубы.
> В OS X вообще много с чем плохо. И графический стэк там - редкое г0внo! И да, знаешь, нынче даже смартфон может декодировать видео с интернетовским битрейтом софтварно.
Я бы хотел чтоб на линуксе можно было так играть видео в браузере, как на OS X в safari или в опере через VDA. Ну и опять врёшь, на моём ноутбуке Intel Core i5-4260U не справляется хромиум с 4К видео в софтварном декодировании, на десктопе помощнее процессор - там прожевывает.
> На писюках H.265 умеет играть полторы железки от нвидии. Ну и все. Они вроде как и VP8/9 поддерживают как раз.
"nvidia 346.16 Beta Adds VP8 Decoding" - ничего себе, только что добавили? Про VP9 что-то не видно. До моей ubuntu lts это ещё не пришло. H264 то уже давно поддерживается.
PS: остальное флуд - без ответа.
> и так не проблема с тытрубы.Расскажи плиз - как ты тыришь high-res высококачественное видео передаваемое с помощью MSE. Мне интересно - как это выглядит технически. Я могу придумать некоторые варианты, но они геморные и оверинжинеринг во все поля.
> Я бы хотел чтоб на линуксе можно было так играть видео в
> браузере, как на OS X в safari или в опере через VDA.Для начала, на писюках аппаратных декодеров часто нет или они умеют полтора формата. Уметь пользоваться ускорением декодирования - ну да, неплохо. С другой стороны, по моим наблюдениям - там скорее предъява к иксам, которые элементарно не могут гнать 2D с приличной скоростью без фееричных костылей. На тытрубе процесс иксов может стрескать времени сравнимо с процессом браузера. Вот это да - проблемный компонент и шапка не зря хочет пристрeлить этот окаменелый крап.
> Ну и опять врёшь, на моём ноутбуке Intel Core i5-4260U
> не справляется хромиум с 4К видео в софтварном декодировании, на десктопе
> помощнее процессор - там прожевывает.А ты смотрел на что время тратится? Может так оказаться что все уперлось в тормозной вывод 2D иксами - надеюсь это объясняет за что я их не люблю ;). И да, а монитор то 4К у тебя есть? Или ты как самый умный скачал в несколько раз больше данных только для того чтобы их потом после декодирования задayнcэмплить? А то киздатый юзкейс - качать данные для того чтобы их отбросить.
> не пришло. H264 то уже давно поддерживается.
А H.265 - только полторы новые видеокарты, найти живого пользователя которых - редкая удача, тем более на опеннете. Там же вроде как и VP8/9, vdpauinfo точнее скажет.
> Расскажи плиз - как ты тыришь high-res высококачественное видео передаваемое с помощью MSEyoutube-dl -f 137+141 "https://www.youtube.com/watch?v=CphDpZrmo8U"
> А ты смотрел на что время тратится? Может так оказаться что все уперлось в тормозной вывод 2D иксами
Я под OS X смотрел, и да при использовании аппаратного декодирования в chromium/opera dev версии (только что вот его наконец-то добавили) всё замечательно.
> А H.265 - только полторы новые видеокарты
Только ради этого и побегу за новой невидией 900-ой серией, хорошо чтоб и VP9 туда попал, а не так что "покупай для VP9 опять новую карту".
> youtube-dl -f 137+141 "https://www.youtube.com/watch?v=CphDpZrmo8U"А с чего ты взял что он пользуется MSE? Он просто качает добрецо HTTP GET запросами, как файло, скорее всего используя deprecated интерфейс для флеша к тому же, который постепенно выпилят. А вот чтобы содрать контент подаваемый через MSE - надо будет как минимум двигло JS и нефиговый кус HTML5 и браузера реализовывать, чтобы оно смогло выполнять код гугли который знает как и где брать видеоданные и будет их втрамбовывать в декодер. Ну или браузер патчить, чтобы в этот момент данные куда-то сэйвились. Хорошая заявка на гемoppoй.
А так - выпилит гугель например доступ к видео как к файлам и оставит только MSE. И твой даунлоадер ВНЕЗАПНО превратится в тыкву. JS со своей стороны они всегда смогут поменять под свое представление, если что, произвольно поменяв способ доставки. В общем образцовая радость папуаса по поводу монтажа виселицы, при непонимании того для кого она предназначена. Это конечно формально не DRM, а именно продвинутый стриминг. Однако поскольку там произвольная логика в JS разбирается как и где брать пакеты данных и как это компоновать в видеопоток, сдирание этого представления может потребовать убедительных инженерных усилий, которые будут за пределами умений домохозяйки типа тебя. Стало быть, до кучи оно может быть и эрзац-DRM-ом.
> Я под OS X смотрел, и да при использовании аппаратного декодирования в
> chromium/opera dev версии (только что вот его наконец-то добавили) всё замечательно.А, ну про этих ничего не скажу. Могу лишь заметить что влияет не столько разрешение, сколько битрейт. А большой битрейт через веб никто и не будет прокидывать. Тем паче что у обладателей больших мониторов и проц мощный как правило - иначе что они на этом мониторе вообще будут делать? Это ж динозавр получается, если мозг маленький а монитор большой.
>> А H.265 - только полторы новые видеокарты
> Только ради этого и побегу за новой невидией 900-ой серией, хорошо чтоб
> и VP9 туда попал, а не так что "покупай для VP9 опять новую карту".А я бы на месте нвидии как раз просил покупать новую видеокарту на каждый пшик и почаще. Зачем же продавать папуасу бусы 1 раз, если можно 2 раза? Это непредусмотрительно :). Желательно при этом чтобы стандарты менялись раз в год. Ну там H.266 уже пора наверное проектировать втихаря. Чтобы как только лохи накупят чипов с аппаратным декодером - сказать что все уже устарело и есть кодек в 2 раза лучше. Ну вон Daala можно например начать продвигать :)
> Это ж динозавр получается, если мозг маленький а монитор большойНаркоман, планшеты щас с разрешением больше чем у ноутбука, с которого я пишу, теже смарт телефизоры - у всех у них здоровые по разрешению экраны и простые процессоры, которые не потянут нормальное разрешение видео в софтварном режиме.
Да и нормальному человеку как-то не особо круто, что проц пыжится, тратит больше энергии, когда GPU одним мизинцем с этим справится. Разве что, если у тебя в квартире холодно и дешёвая электроэнергия, то мизерный плюс есть.
PS: фанатско-неадекватное "ненужно" оно такое.
> НаркоманА я человек. Будем знакомы. Хоть и не очень приятно, но объясняет странности поведения.
> планшеты щас с разрешением больше чем у ноутбука, с которого я пишу,
Круто. Но во первых, 4К планшетов я все-таки не вижу, а во вторых, новые SoC как раз VP8/9 как правило играют.
> теже смарт телефизоры - у всех у них здоровые по разрешению экраны
Чаще всего обычный FullHD.
> и простые процессоры, которые не потянут нормальное разрешение видео
> в софтварном режиме.Да это вообще пофиг - если очень хочется, свисток на андроиде, втыкаемый в HDMI, с размерами чуть больше флешки - стоит баксов 30-50 и там декодер аппаратнй. Это на тех же чипах что и планшеты/смарты. Так что проапгрейдить поддержку форматов - получается дешево и сердито. По поводу чего всякая архаика типа DVD плееров отмирает в пользу таких девайсов. Китайцы их миллионами гонят, двд/блюреям такие тиражы только в сладких снах снятся. Потому что кому нужна здоровая и дубовая дурында если штука размером с флеху играет больше форматов, может самостоятельно качнуть из интернета, если хочется, и вообще, при нужде легко апгрейдится.
> Да и нормальному человеку как-то не особо круто, что проц пыжится, тратит
> больше энергии, когда GPU одним мизинцем с этим справится.Нормальному человеку это относительно пофиг. Ну я у себя настроил аппаратное декодирование мувиков в мплеере. Ну да, GPU упирается побольше, CPU поменьше. Монитор у меня большой, да. Но если честно - особой разницы с софтварным декодированием я не вижу: проц у меня тоже солидный и ему реально существующие видеопотоки - на один зубок. Там запас еще раз в 10 остается.
> Разве что, если у тебя в квартире холодно и дешёвая электроэнергия,
Если мне захочется топить электричеством - я запущу майнер на GPU, он то делает хорошо :-)
> PS: фанатско-неадекватное "ненужно" оно такое.
Скорее, мнение обладателя большого монитора, GPU с аппаратной акселерацией и мощного CPU. Ну да, фича, из разряда "good to have". Но ничего сногсшибательного. Реально на этой планете есть over 9000 форматов и субформатов и аппаратный декодер справится далеко не со всем зоопарком. Поэтому уповать только на него мне как-то не хочется - так в полвине случаев можно без видео остаться.
>>Расскажи плиз - как ты тыришь high-res высококачественное видео передаваемое с помощью >>MSE. Мне интересно - как это выглядит технически. Я могу придумать некоторые варианты, но >>они геморные и оверинжинеринг во все поля.Лол, VLC-3.0.0-git поддерживает dash, то есть стырить такой потом можно(я пробовал) даже без пережимания. Есть еще, ниже отмечали, youtube-dl, mpd, livestreamer и вообще, стандарт открыт, можно за вечер на любимом языке набросать парсер и сэйвер потока.
> Лол, VLC-3.0.0-git поддерживает dash,Dash != MSE. Сам по себе MSE - средства для JS скормить декодеру полученный (или даже сгенерированный локально) где-то как-то поток видео. Ну то-есть JS может конструировать поток для декодера. А вот как и где JS возьмет данные для этого - очень отдельный такой вопрос. Еще более отдельный вопрос - насколько эти ваши vlc и youtube-dl готовы столкнуться с кастомным пакетизатором данных (где можно и шифрование на JS до кучи привинтить, лол). Так что до кучи MSE может выступить и эрзац-DRM, сделав сдирание данных нетривиальным. Теоретически возможным, но практически весьма усложненным.
И чтобы с MSE иметь дело - надо всего ничего: интерпретатор JS, парсер HTML, какую-никакую реализацию MSE. За вечер говорите, наваяете? Длинный у вас будет вечер, наверное это скорее будет полярная ночь :)
> не уверен, даже не встречал H265, не знаю каким плеером его воспроизвести, но знаю что VP9 лучшетогда понятно, вопросов больше нет...
> тогда понятно, вопросов больше нет...Если ты такой крЮтой - вон там внизу ссыль на нежатый исходник BigBuckBunny в 480p24 - можешь попробовать закодировать на 500 кбит (среднее) ака ~33Мб на все и вся лучше. Выбор кодека и параметров кодирования - за тобой.
>Chrome вообще имеет нормальное GPU декодирование только на венде (не проверял, это судя по их багтрекеру, знаю только что к сожалению на OS X и линукс с этим пока плохо).Linux, аппаратное декодирование на NVidia начиная с ubuntu 12.04, на AMD начиная с Ubuntu 14.04. Единственное - в chrome://flags приходится включать флаг "Переопределение списка программного рендеринга" (Переопределяет встроенный список программного рендеринга и активирует графический ускоритель на неподдерживаемых системах. #ignore-gpu-blacklist).
Аппаратное декодирование на amd и intel не требует использования флага.
Т. е. для linux они заблеклистили кучу gpu и не особо проверяют, как сейчас работает. Что печалька, но не большая проблема, так как по факту работает.
> Linux (chromium), аппаратное декодирование на NVidia начиная с ubuntu 12.04. Единственное - в chrome://flags приходится включать флаг "Переопределение списка программного рендеринга"Не удалось найти в ынтернетах человека, у которого бы это заработало. Так же и сам пробовал - грузит CPU будь здоров, VDPAU и не пахнет.
Единственное, что пробовал последний раз несколько месяцев назад, может что-то поменялось, но про "с ubuntu 12.04" точно речи быть не может.
> Не удалось найти в ынтернетах человека, у которого бы это заработало.А сколько человеков ты опросил? :)
> пусть гугл их замочит а мозилла окончательно утрамбует земличку на могилке этих упырейГугл это та кампания, которая в android lolipop уже встроила поддержу H.265 и которая обещала в 2011 году выкинуть из хрома поддержку H.264?
Мозила это та компания, которая в версии 24 сделала поддержку H.264, оставив в природе только один единственный браузер с только свободными кодеками, внезапно проприетарную оперу.
> Гугл это та кампания, которая в android lolipop уже встроила поддержу H.265А уж VP8/9 они там сто лет как встроили.
> и которая обещала в 2011 году выкинуть из хрома поддержку H.264?
А там их кодек есть? А так - тут я еще понимаю: видео которое играл флеш без рекодирования цепануть. Но вот транскодить видео в 265 - нафига бы?
> Мозила это та компания, которая в версии 24 сделала поддержку H.264,Они сами никакой поддержки не предоставляют. Могут пользоваться системным кодеком или подaчкой от цыски. Тормозной что пи...ц и отвратительной в плане умения правильно дропать кадры при нехватке времени, что очень доставляет владельцам старых компов. Они так рады такому счастью что в потоке мата на слайдшоу с икающим звуком (спецы реалтаймных комуникаций из цыски не в курсе что аудио надо приоритет отдавать, офигеть) - цензурными оказываются разве что междометия.
> оставив в природе только один единственный браузер с только свободными
> кодеками, внезапно проприетарную оперу.Опера внезапно стала шкуркой для хромиума и поэтому умеeт и VP9 в том числе.
Да, всё так и есть.
Суть проста: 1) H265 несколько превосходит VP9 по тех параметрам, 2) за H265 плати-плати-плати, 3) скорее всего опять в битве форматов всех нагнут на использование проприетарных решений
PS: щас My Little Pony 5-ый сезон начался, посмотри - там как розовый мир про пони, а не реальный
> Суть проста: 1) H265 несколько превосходит VP9 по тех параметрам,Не вижу откуда это вытекает. Та или иная реализация в тех или иных условиях может показывать те или иные результаты и там очень зависит от того насколько алгоритмы конкретно данной реализации пролошились на конкретно вот этом материале. И это очень варьируется. Еще в частном случае есть умение индивида пользоваться тем или иным инструментом - понимание кодека и "ощущение" какие параметры ему скормить в конкретной ситуации будет правильно, если хочется наилучший результат. А иногда можно и откровенно вкостылить, исправив заскоки кодека ручной задачей параметров. Объем костылинга и квалификация кодирующего - параметры не очень технические, но на результат тоже влияют.
Вопросы качества видео - довольно субъективны. Существующие методики в основном оценивают восприятие стопкадров. А для движущейся картинки восприятие иное - видимо мегаэксперты пока не придумали метрику, которая бы это могла учесть. Хороший стопкадр - здорово. Но мало что говорит о восприятии движущейся картинки. Если на то пошло - глаз не замечает мелкие детали в движении, так что небольшое мыло - никто не заметит кроме как на стопкадре. А какой-нибудь злостный ringing на контрастных границах - заставит глаза вытекать, даже если загажена небольшая часть кадра и формальные метрики вроде ок.
Говоря за лично себя мне семейство VPx нравится именно неназойливыми артефактами, которые не бросаются в глаза. На первый взгляд, аллокатор битрейта тоже там разумный - вон на зайце титры в вп9 выглядят явно лучше чем в 264. Как оно в 265 - ну, проверьте.
Еще кстати половина экспертов, в том числе с дум9 - считают нормальным брать уже пожатый ранее материал и сравнивать то что перекодировано из него. О том что MPEG-based при этом полчит сказочного размера скидку из-за того что артефакты сжатия в исходнике похожи на артефакты сжатия которые сделал испытуемый кодек, так что формальные метрики будут сильно перекошены в пользу мпега (а если взять исходник в VP8/9 - можно столь же необоснованно выпятить VPx, пожалуй). А брать именно нежатый исходник без артефактов сжатия - вот тут получается намного интереснее, но почему-то половина мегаэкспертов до этого не допирают. Собственно, одна из причин по которой у xiph.org нынче есть некое количество несжатого материала для непредвзятого тестирования поведения кодеков и изучения их свойств.
> на использование проприетарных решений
Не знаю кого там нагнут, но этот кто-то будут имхо не я.
> PS: щас My Little Pony 5-ый сезон начался,
Мне пофиг. Хотя если они выложат несжатый исходник - поиграюсь как с разновидностью материала для кодирования.
> Не знаю кого там нагнут, но этот кто-то будут имхо не я.Ога, навернякак есть уже техника (смартфон, ноутбук, телевизор, хардварный плеер...), где уже тебя нагнули и ты заплатил за всякие там патенты и за кодеки и прочее.
Ну и я понял, всё видео, которые к тебе попадает помимо тытрубы (а это щас H264 в подавлюящем числе случаев) конвертируешь в VP9 и только потом смотришь - ну разве только так...
> Ога, навернякак есть уже техника (смартфон, ноутбук, телевизор, хардварный плеер...),
> где уже тебя нагнули и ты заплатил за всякие там патенты и за кодеки и прочее.Ну вот лишний раз нагибаться и тем более продвигать нагибание я как-то не планирую. А тебе флаг в руки и барабан на шею, если тебе так нравится.
> (а это щас H264 в подавлюящем числе случаев) конвертируешь в VP9
> и только потом смотришь - ну разве только так...Странный вывод.
Вот ещё один заказной отчёт http://www.slideshare.net/touradj_ebrahimi/spie2014-hev-cvsvp9
Неплохой форум по всяким кодированиям http://forum.doom9.org/ - там тоже все заказные посты.
На швабре тоже все комментаторы оказались куплены, говорят что у VP9 мыльнее кадры.
PS: правда дороже фанатизма
> говорят что у VP9 мыльнее кадры.Не, блин, намного лучше лицезреть фирменные мпеговские ringing and twinkling :)
> PS: правда дороже фанатизма
Ну так правда такова что полинтернета уже может смотреть мувик в VP9 - достаточно его выложить на сервак. Например, свой, если гугловский не нравится. А H.265 я даже и не знаю чем смотреть.
> Пока я вижу как у меня в браузере играется VP9И да. С аппаратным декодированием играется? Или пускай процессор пыжится на 4К видео?
> И да. С аппаратным декодированием играется? Или пускай процессор пыжится на 4К видео?Для начала - в интернете для тебя никто не будет высокобитрейтный поток хостить, потому что бандвиз стоит денег, как и сервера, способные отгрузить приличный поток толпе народа.
А поскольку роялит объем данных которые надо лопатить, напряг получится не такой уж и большой. Да и у кого есть 4К экраны - то и процессор там под стать. Хардварные видеодекодеры штуки довольно капризные, имеют ряд ограничений по тому что они поддерживают и с какими параметрами. Даже у того же H.264 - high профайл играет далеко не любой аппаратный декодер, многие аппаратные декодеры только mainline тянут.
>А кто будет H.265 качественно реализовывать?Apple, Microsoft, Samsung, Sony, и прочие члены MPEG LA
> Apple, Microsoft, Samsung, Sony, и прочие члены MPEG LAФлаг им в руки. На мобильном рынке эппла осталось 10% в мобилах, 20% в планшетах. Остальное, извините, гугль. В вебе видимо будет как-то аналогично. Ну там еще фокс как-то рубается. Ну вот пусть эти проприерасы и лицензируют свое жлобство сами себе.
>На мобильном рынке эппла осталось 10% в мобилах, 20% в планшетаха у самсунга, сони и прочих не перечисленных тут? Аппаратная поддержка HEVC есть во всех относительно новых мобильных чипах уже сейчас, и если Гугл начнет запрещать этот формат на уровне ОС, то все йоллы с цианогенами скажут ему большое спасибо.
И да, в вебе будет аналогично: если пользователи начнут разряжать девайсы за час сидения на ютубе из-за того что там только софтверный VP9, то они потихоньку потянутся на другие видеохостинги.
> а у самсунга,Самсунг врядли будет рубиться с гуглем. Не в его интересах. Может быть их телефоны будут понимать и то и другое, но не на выбор.
> сони и прочих не перечисленных тут?
А у сони нынче есть какая-то рыночная доля за пределами фоновых продаж?
> Аппаратная поддержка HEVC есть во всех относительно новых мобильных чипах уже сейчас,
Там же есть и VP9. При том китайцы не особо горят желанием платить роялти и в дешевых китайских обынчо H.264 и VPx.
> и если Гугл начнет запрещать этот формат на уровне ОС, то все йоллы
> с цианогенами скажут ему большое спасибо.А нафига им что-то запрещать, имеючи поисковик для пиара, наверное самый популярный на планете видеохостинг для применения, являясь поставщиком оси для тех кто ведроид делает, etc? У них все компоненты технологий - на руках. Поэтому они будут делать то что сочтут нужными и забудут спросить у эппла и микрософта - а можно ли.
> час сидения на ютубе из-за того что там только софтверный VP9,
Гугл в отличие от этого жлобья - весьма заботится о продвижении. Раздавая и качественный референсный софтварный кодек, и для производителей SoC - IP блок. Нахаляву. С сорцами. С помощью в внедрении. Где все это от стандартизаторов H.265? Там вон вместо этого - патентами махают. По поводу чего в новых SoC как раз VPx встречаются часто. А HEVC - еще будем посмотреть. Если эти "стандартизаторы" и дальше будут такой рэкет устраивать - они будут стандартизировать параметры метлы, когда им придется податься в дворники. Т.к. такой "стандартизатор", который принимает стандарты под рэкетиров - не очень то и сильно нужен. И пальму первенства вполне могут перехватить.
> то они потихоньку потянутся на другие видеохостинги.
Я думаю лучше тянуться к другим процедурам стандартизации. Когда стандартизатор не является подстилкой для пары особо наглых акул бизнеса.
> Достойным он будет, когда vp9 приблизится к скорости кодирования x264Во первых, VP9 может жать лучше чем 264, и как таковой - конкурент H.265. А для 264 есть VP8, который на 8 ядрах кодирует со скоростью ракеты (быстрее реалтайма даже с максимальным качеством кодирования на моем 8-ядернике), при этом вполне честно рубясь по битрейт/качество с майнлайн профaйлом 264.
Во вторых, скорость кодирования там выбирается. На предмет того что в приоритете - максимальное качество при минимальном размере или время кодирования.
В третьих, не так давно гугл и скорость сильно подтянул и многопоточность кодирования запилил. Стало вообще симпатично.
В четвертых, VP9 имеет коронное преимущество над H.265: он уже играется толпой браузеров, здесь и сейчас ;)
> и результатам, бьющими последнего с полной выкладкой сравнительных скриншотов и прочих psnr
Могу ради лулзов выложить "зайца" (BigBuckBunny) которого я из интереса VP9 пожал. Из uncompressed YUV исходника до 500Кбит (среднее), что для 480p24 (704×480@24FPS) - достаточно скромный битрейт. Несмотря на скромный битрейт, у VP9 - качество радует глаз, найти дефекты сжатия - надо сильно приглядываться.
И не скажу за PSNR, но при таргете на 500Кбит и 2-проходном кодировании - визуально x264 ощутимо проcacывает VP9 на титрах в конце, стопкадр там вообще буэ, да и даже движущаяся картинка - хреновая, ringing вокруг текста и мусор - оптом. А VP9 дает довольно чистую картинку в этом месте. При том вроде бы и не в ущерб всему остальному.
Best of all: это играется в лисе и хроме. Здесь и сейчас. А H.265 - ну вы поняли. Да еще патентные проблемы.
> В четвертых, VP9 имеет коронное преимущество над H.265: он уже играется толпой браузеров, здесь и сейчасА можно примеры сайтов с VP9 кроме зондовогугловой тытрубы?
> А можно примеры сайтов с VP9 кроме зондовогугловой тытрубы?Ну так спроси у поисковика. Я ж не веб-паук гугли чтобы все сайты и все что на них лежит знать. Могу лишь прикинуть что скоро их будет. Потому что новые мобилки это будут отлично поддерживать.
Китайцы с дешевыми SoC только рады бесплатному хардварному кодеку для их чипов. А вот HEVC они не спешат внедрять зачастую. Даже на Raspberry Pi и то вон VP8 - играется сразу, а чтобы H.264 заработал - там какой-то трехэтажный гемор с докупкой ключей за отдельную мзду у броадкома, т.к. броадкому видимо впадлу платить роялти за всех.
Ну так выкладывай
> Ну так выкладывайЗабирай: http://rghost.net/7MVxN4gyd
SHA256SUM:
4384d6f57b1acc9ab96d932946de0b76ff99b01763d6860ea40659b233b8a44a test-vp9-500kbps-best.webmКодировалось с target bitrate = 500kbps, настройки качества - на максимум. Интересно же - а смогет оно пропихнуть 480P24 на всего 500 килобитов? Смогет, как оказалось. Реальный средний битрейт даже немного ниже запрошенного.
Особо внимательные могут заметить что это даже еще не 1.4.0 кодировано :-). Ну а желающие могут побить этот результат. Например, попытавшись получить сравнимое качество от x264, только у меня он всегда сильно гадит титры в конце на 500Кбит, так что глаза вытекают. Хотя файл даже чуть больше чем 500kbps получается. Еще желающие могут поупражнятсья с H.265, но мне вполне вероятно будет нечем его проиграть. Этот то можно браузеру отдать. Или хоть vlc не сильно архаичному.
Ах да, при желании поупражняться в кодировании, оригинал брать тут: https://media.xiph.org/video/derf/y4m/big_buck_bunny_480p24.... (весит 1.6Гб сжатый, что-то порядка 30Гб распакованный).
> только у меня он всегда сильно гадит титры в конце на 500Кбит, так что глаза вытекаютТ.е. вы даже не зная о том, что такое ratecontrol (и о том, что он не имеет напрямую отношения к кодеку) рассуждаете о качестве? В простых утилитах типа x264 никто нормальный ratecontrol и не прикручивал, он там на фиг не сдался. Кодируйте через ffmpeg с его ratecontrol'ом и будут нормальные титры.
Вообще пример для оценки h.265 плохой, на таком разрешении выигрыш от него небольшой (хотя и то есть). В другой раз сравнивайте h.264 и h.265 на примерах высокого разрешения, как это делают на https://x265.com/hevc-video-files/ например.
На 4K видео (напр. crowd run - https://media.xiph.org/video/derf/y4m/crowd_run_2160p50.y4m - осторожно, почти 6 гигов) h.265 даст качество намного выше, чем VP9 на половине его битрейта. Готовые кодирования h.265 и h.264 можно скачать например на http://forum.videohelp.com/threads/360069-x265-HEVC-Encoder/...
Прошлогодние, правда. С тех пор качество x265 ощутимо подросло. Это вообще очень молодой кодек, в отличие от старенького VP9 - нормальные реализации только начинают появляться. Даже стандартные профили HEVC еще только в draft'ах, финальные версии будут в этом году. Но тем не менее.Пример кодирования x264 (битрейт я взял 450, а не 500, т.к. такой получился у этого VP9 файла - чтобы честнее было):
http://rghost.ru/8KcF9MzrP (пресет veryslow, который был вполне себе быстрым даже на моем Core i5-2500 - порядка 250 к/с первый проход и 65 к/с второй - одна и 4 минуты соответственно)Пример кодирования x265 (битрейт аналогичный). Кодирование в самом банальном профиле, 8 бит, никаких фич не включено (см. http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Pr... - в данном случае профиль "main")
http://rghost.ru/8VQbdTXfj (пресет тот же, первый проход 47 к/с, 5 минут, второй 4 к/с, порядка часа)Как легко заметить, даже у x264 результат на всех кадрах содержит больше деталей, чем VP9, а с x265 даже сравнивать смысла нет. Можете внимательно сравнить заинтересовавшие вас титры в VP9 и x256. На первом - куча артефактов, на втором - практически неотличим от оригинала.
Любопытства ради закодировал с использованием 10-ти битного (профиль main10) h.265. Исчез бандинг на небе в нескольких сценах, где он был заметен. Загрузил http://rghost.ru/68cxzQFww
> Т.е. вы даже не зная о том, что такое ratecontrolПогоди, чувак! Ты предлагаешь мне самому весь rate curve формировать вместо кодека? А не сильно ли крЮтая скидка на хреновый rate control для х264 получится? Чего это я буду вместо него упираться?
В обоих случаях было сделано двухпроходное кодирование: и VP9 и x264. И кодеки имели все карты на руках заранее узнать сложность сцен и отстроить распределение скоростей так как считали нужным, в рамках желаемого бюджета. Ну и вот, VP9 как-то в целом лучше это сделал чем х264 - у VP9 титры в конце не выглядят как ужас-ужас. А ты можешь попробовать вправить мозг x264 чтобы он титры не поганил. Бюджет - среднее 500Кбит ака 33Мбайта на весь файл, burst можешь разрешать какой угодно: титры - длинные, там кратковременными всплесками не отделаешься. Я как только ни кодировал х264 (git-версией, как и vpx) - титры выглядели отвратительно. А остальное - на уровне VP9 или чуть хуже.
По поводу чего я склонен считать VP9 побившим H.264 в лице неплохого представителя - x264. Но ты можешь попробовать закодировать лучше, чтобы титры не загаживались.
> (и о том, что он не имеет напрямую отношения к кодеку) рассуждаете о качестве?
Затея была в том чтобы создать относительно сложную ситуацию, когда артефакты сжатия уже начнут становиться заметными, чтобы посмотреть что могут выжать кодеки в достаточно тяжелых, но имеющих реалистичные применения условиях. Вот тогда мы узнаем кто есть кто.
> В простых утилитах типа x264 никто нормальный ratecontrol и не
> прикручивал, он там на фиг не сдался.Это прикол такой? Это было двухпроходное кодирование, так что кодеки могли заранее посмотреть весь материал и знать что их ждет, выбирая распределение скоростей, да и основные рукоятки там все есть. И оба кодека так пинались - VP9 был в точно таких же условиях: использовался vpxenc. По вашей же логике, VP9 тогда тоже может преимущества из-за ffmpeg получить.
> Кодируйте через ffmpeg с его ratecontrol'ом и будут нормальные титры.
А с чего вдруг там будет улучшение? Хотите сказать что сам по себе х264 в двухпроходном кодировании - лох? :)
И да, standalone тулзы использовались потому что их просто перестроить из текущих гитовых версий. Чтобы смотреть на то что есть сейчас, а не сколько там назад. Перестраивать весь ффмпег мне, скажем прямо, неохота.
> h.265 на примерах высокого разрешения, как это делают на https://x265.com/hevc-video-files/
> например.В мои планы не входит заниматься синтетическим подгоном решений под ответ. Полмегабита для 480P24 - выглядит вполне приличным юзкейсом для выкладывания в интернете. С сильным кодеком получается разумный битрейт при приличной картинке, где в случае VP9 артефакты можно найти только в паре мест, и то - если приматриваться (или сильно зумать).
> Прошлогодние, правда. С тех пор качество x265 ощутимо подросло. Это вообще очень
> молодой кодек, в отличие от старенького VP9 -Да вообще-то они вполне сравнимы по возрасту, так что выбивать скидки не получится.
> нормальные реализации только начинают появляться. Даже стандартные профили HEVC еще только в draft'ах,
> финальные версии будут в этом году. Но тем не менее.Ну вон гугель тоже 10/12 бит и прочие 4:4:4 на ходу подшивает. И?
> Пример кодирования x264 (битрейт я взял 450, а не 500, т.к. такой
> получился у этого VP9 файла - чтобы честнее было):Заказыалось 500, но rate control проявил некий пессимизм и сделал даже чуть ниже.
> http://rghost.ru/8KcF9MzrP (пресет veryslow, который был вполне себе быстрым даже на моем
> Core i5-2500 - порядка 250 к/с первый проход и 65 к/с
> второй - одна и 4 минуты соответственно)Неплохо. И титры немного получше чем у меня с х264 получились вроде. Но все-равно: там где мышь жонглирует фруктами, стоя на блоке титров (и немного до этого) - нагажено весьма даже, мусора много, это видно. И когда большой блок титров кончается и идет переход в плавный градиент - идет крайне противное мерцание, куча мусора. Да и в целом - текст титров запорчен, границы нерезкие. Мелкий текст читается очень трудно. У VP9 имхо оно как-то лучше выглядит. Я уж не знаю почему, но с титрами х264 традиционно справляется плохо. Еще у зайца на быстрых сценах шкурка становится квадратиками, но это не очень заметно в движении.
> Пример кодирования x265 (битрейт аналогичный). Кодирование в самом банальном профиле,
Вот это уже лучше. И артефакты сжатия он прячет как-то больше в духе VP9 - так что сразу и не сообразишь где они, хотя в сложных местах они разумеется на месте, как положено :). Но вот фирменная слабость с титрами - в наличии! Посмотри: блок с мелким текстом по прежнему размазан и читается ну просто отвратительно. А вот у VP9 - текст просто кристально четкий и после 264/265 - просто радует глаз.
> Как легко заметить, даже у x264 результат на всех кадрах содержит больше
> деталей, чем VP9, а с x265 даже сравнивать смысла нет.А вот это - вообще совсем неправда. Идем на блок с мелкими титрами и понимаем где мелкие детали в большом количестве выглядят лучше.
> Можете внимательно сравнить заинтересовавшие вас титры в VP9 и x256. На первом
> - куча артефактов, на втором - практически неотличим от оригинала.Кроме одной мелочи: у VP9 текст очень четкий, границы резкие, читается легко. А у H.264 и H.265 там форменная мазня и глаза при попытке чтения такого текста собираются в кучку. Это к вопросу о наличии мелких деталей. И да, H.264 в титрах наартефактил поболее VP9, имхо. H.265 вел себя приличнее, но читаемость текста все-равно убил изрядно.
> Погоди, чувак! Ты предлагаешь мне самому весь rate curve формировать вместо кодека? А не сильно ли крЮтая скидка на хреновый rate control для х264 получится? Чего это я буду вместо него упираться?Нет, я предлагаю использовать отлаженный rate control, напр. в ffmpeg.
> По поводу чего я склонен считать VP9 побившим H.264 в лице неплохого представителя - x264. Но ты можешь попробовать закодировать лучше, чтобы титры не загаживались.
А как насчет полного мыла в текстурах камней, зверей и прочего в VP9, чего нет в h.264?
> Это прикол такой? Это было двухпроходное кодирование, так что кодеки могли заранее посмотреть весь материал и знать что их ждет, выбирая распределение скоростей, да и основные рукоятки там все есть. И оба кодека так пинались - VP9 был в точно таких же условиях: использовался vpxenc. По вашей же логике, VP9 тогда тоже может преимущества из-за ffmpeg получить.
Еще раз: встроенный ratecontrol несколько примитивен (а в x265 вообще в релиз не вошел, только в dev-ветке появился на днях). Кроме того, для специфических случаев можно выбрать другую формулу изменения rate'а (в ffmpeg по умолчанию "tex^qComp"). Да, VP9 мог бы тоже получить преимущества в титрах (ценой ухудшения в другом месте). Там тоже сильные артефакты. Но во всяком случае, сравнение с одим rate control'ом - это обязательный фактор при сравнении кодеков таким способом. Иначе получается бредовое сравнение: сравниваем не сколько как кодек жмет, сколько как разные формулы или внутренние методы оценки качества по умолчанию себя ведут на разных материалах.
Я даже не буду комментировать, что на самом деле качество кодеков давно стараются сравнивать иначе - кодировать все с одинаковой квантизацией (постоянный уровень качества) и тем самым вообще не зависеть от rate control'а (CRF режим). Все равно на практике, после того как ушла необходимость подгонять рипы под размер болванки :) в жизни кодируют именно так. Под постоянный уровень качества. Так вот, делают несколько кодирований с разными уровнями качества, а потом сравнивают между кодеками - находят те, где уровень качества совпадает, и сравнивают битрейт.
Что касается титров, возможно, я вас удивлю - *в жизни* как раз в низкобитрейтном кодировании раньше для них нередко вручную сильно увеличивали битрейт, если нужна четкость. По определенным причинам скользящие титры с четким текстом кодируются плохо, а алгоритмическая оценка это оценивает неправильно. Но при кодировании с постоянным CRF такой проблемы нет. С ним вообще намного проще.
> Да вообще-то они вполне сравнимы по возрасту, так что выбивать скидки не получится.
С трудом. HEVC стандарт, считайте, еще не утвержден до конца. Он еще не живет. Поэтому и кодирований нет. Только в этом году утвердили расширенные профили, к началу 2016 - дополнительные расширения, помогающие кодировать отрендеренный текст, графику и анимацию (внезапно, наш случай). Потом x265 еще немного созреет, появятся нормальные коммерческие энкодеры, поддерживающие все это и он потихонечку начнет свой путь. А VP9 уже существует почти 4 года.. Так что сравнивать их популярность имеет смысл не раньше, чем через 2-3 года. Подобному кодеку нужно дозреть.
> У VP9 имхо оно как-то лучше выглядит. Я уж не знаю почему, но с титрами х264 традиционно справляется плохо
Лично я вижу жуткое дрожание текстур на первых блоках титрах (которые на цветном фоне) что у VP9, что у x264, этого нет у x265.
Но как я уже сказал это *некорректное* сравнение. Просто у утилиты x264 rate control не рассчитан на цифры. В топку. Кодировать с постоянным качеством и проблемы не будет.
> H.265 вел себя приличнее, но читаемость текста все-равно убил изрядно.
Тоже относится к ситуации выше, но, полагаю, это несложно исправить и без перехода на CRF. Просто настройки по умолчанию рассчитаны на обычное видео с камеры. Тут неплохой результат с анимацией (детали на текстурах у x265 как в оригинале, у x264 неплохие, у VP9 - полное мыло..), но вообще анимация, а также титры требуют специальных настроек.
> Нет, я предлагаю использовать отлaженный rate control, напр. в ffmpeg.Не заметил фундаментальной разницы ваших мувиков с моими, если честно. В том плане что все проблемные места остались там же где и были. Может общее качество чуть выросло, но принципиально ничего не изменилось. А один фиг первый проход делается грубо и быстро и потом сложность сцен намереная там и определяет общий вид rate curve. Собствено, пoйнт 2-проходного кодирования в том чтобы кодек заранее знал что его ждет и мог оптимальнее раскинуть доступный бюджет битрейта.
> А как насчет полного мыла в текстурах камней, зверей и прочего в
> VP9, чего нет в h.264?Действительно: там у бегущего зайца на пyзе - просто мпеговские квадратики. Зато никакого мыла! :)
Но вот на мое имхо - мыло меньше бросается в глаза чем квадратики. Более того - если обратить внимание, в х265 это, похоже, осознали и там - все тоже именно замылено. Относительно незаметный артефакт: глаз мелкие элементы в движении не очень различает, безoбрaзие видно только на стопкадре, и то бросается в глаза только если видел оригинал. В этом плане VP9 и x265 довольно похожи :)
> Еще раз: встроенный ratecontrol несколько примитивен (а в x265 вообще в релиз
> не вошел, только в dev-ветке появился на днях).Еще раз: все то же самое в этом случае применимо и к VP9 - он тоже своим rate control обходился. И если у ffmpeg он такой замечательный - наверное VP9 от него тоже должен бы выигрывать? Я кодировал vpxenc-ом, так что rate control был оттуда. Тем более что вы были вольны кодировать чем угодно. Что х264 не сильно помогло, как я вижу. Наверное потому что общая форма кривой скоростей определялась первым проходом.
> Кроме того, для специфических случаев можно выбрать другую формулу изменения
> rate'а (в ffmpeg по умолчанию "tex^qComp").Не вижу ничего особо специфичного в мувике про зайца. Обычный мувик с несколькими заметно разными сценами. Как раз хорошо чтобы посмотреть на то как кодек ведет себя на существенно разном материале. Более того - я не вижу фундаментальной разницы на титрах что с х264, что ваш ffmpeg-овский вариант.
> Да, VP9 мог бы тоже получить преимущества в титрах
> (ценой ухудшения в другом месте). Там тоже сильные артефакты.Местами - есть. Но в целом как-то менее назойливо (такого жесткого мерцания как в х264 все-таки нет) и сами титры - намного лучше читаются.
> Но во всяком случае, сравнение с одим rate control'ом - это обязательный фактор
> при сравнении кодеков таким способом.Совершенно ниоткуда не следует и делает допущение что улучшенный rate control не может быть фичой кодека и/или утилит вокруг него. А с чего вдруг такие допущения?
А так у VP9 есть фичи которые вы напрямую не сравните с x264/265. Например alt ref frame. В VP8 он был IIRC, 1 ("golden frame") а в VP9 их стало можно делать несколько. И возможность референситься к куску "более подходящего" кадра чем то что вокруг - вполне может поднять соотношение битрейт/качество (вооюще никак не касаясь квантизации и прочего) - за счет лучшего motion compensation, например.
> Иначе получается брeдовое сравнение: сравниваем
> не сколько как кодек жмет, сколько как разные формулы или внутренние
> методы оценки качества по умолчанию себя ведут на разных материалах.Сравниваем реалистичные юзкейсы: есть эн бандвиза/размера файла. Хочется получить на этом максимально приличную картинку. Что в этом такого особенного? Обычная интегральная оценка "кодека вообще". И да, потоянно тыкать носом кодек - может за..., так что оценка аллокации битрейта и прочая имхо имеет право на жизнь. Вообще - мегавaнтузкодировщики с дум9 погрязли в какой-то синтетике. Которая вообще ни в какие реальные юзкейсы не маппится. В результате они что-то вроде сравнивают. Но толку на практике с этого не густо.
> стараются сравнивать иначе - кодировать все с одинаковой квантизацией
А это вообще какая-то махровая синтетика. Какое мне с пользовательской точки зрения дело до того какая там в данный момент квантизация?! Меня волнует битрейт и качество картинки при этом. И это совокупность всех свойств кодека. В первом приближении это могут отражать метрики типа SSIM/PSNR и изменение таковых vs bitrate, но они опять же оперируют больше восприятием стопкадра, нежели чем-то еще, по поводу чего они достаточно сферично-вакуумные.
> (постоянный уровень качества) и тем самым вообще не зависеть от rate control'а
Это опять же синтетика и нишевой юзкейс. См. дальше, чем мне это не нравится.
> режим). Все равно на практике, после того как ушла необходимость подгонять
> рипы под размер болванки :) в жизни кодируют именно так.В жизни - лично я выставляю желаемые constraints rate control'у и получаю результат. Ну то-есть я знаю какой средний битрейт/размер файла хотелось бы и я могу предположить какой overshoot/undershoot при этом меня устраивает. Скажем для кодирования под проигрывание в интернете - не айс, если кодек возьмет сильно более крутой битрейт чем среднее и надолго, у юзера смотрящего мувик может underrun случиться.
А постоянный уровень квантизации - ну вот например, я нахожу достаточно глупым выставлять высокий уровень квантизации какому-нибудь черному квадрату. Нафига там генерить много данных, если завинченные коэффициенты квантизации ничего принципиально хуже там не делают? :)
> Под постоянный уровень качества.
Для меня как-то совершенно не очевидно что пустой черный квадрат и сцена с множеством деталей нуждаются в одинаковом уровне квантизации. Это какой-то очень примитивный взгляд на применение кодеков, являющийся пережитком эпохи мпег 1 или около того.
> Так вот, делают несколько кодирований с разными уровнями качества, а потом сравнивают между
> кодеками - находят те, где уровень качества совпадает, и сравнивают битрейт.И в чем пойнт этой синтетики? Я предпочел плясать от реалистичного юзкейса: допустим мы готовы дать 500 Кбит битрейта на ролик. Ну или 33 мегабайта стоража (если нам bursts не принципиальны). Задача - получить картинку получше. Это интегральная оценка конструкции в целом - при этом роялит и rate control (и его грубая лажа отностельно того что запрошено - кодеку не в плюс). Вот это - понятный мне юзкейс, а не сферическая абстракция в вакууме.
А коэффициенты квантизации - ну, крyто. А что господа заклиненые на мпегах будут делать для описания кодеков у которых принципы работы другие? Ну там wavelet-based всякие, по типу дирака и прочая? Daala, где насколько я помню используется другое преобразование нежели DCT и фокус с overlapping? Это как будете сравнивать, гражданин хороший?
> Что касается титров, возможно, я вас удивлю - *в жизни* как раз
> в низкобитрейтном кодировании раньше для них нередко вручную сильно увеличивали битрейт,
> если нужна четкость.Замечательно, а теперь садись вон на сервак гугле и расставляй там вручную битрейты двум газиллионам мувиков заливаемых юзерами. В смысле, кодек сам не должен протyплять, без педальных приводов и тыкaний ноcом. Иначе это фиговый rate control у кодека, а не что-нибудь еще. И с этим не поздравляют. Заметь: я не занимался тыканием VP9 носом. Я только constraints битрейту задал немного. И кстати я не пользовался alt ref кадрами еще.
> По определенным причинам скользящие титры с четким текстом кодируются плохо,
При том эти причины видимо называются "у нас тут motion compensation обгaдился по полной программе". В смысле, VP8 на титрах по жизни лажал сильно меньше. А VP9 так и вовсе молодцом. У хваленого х265 как и у 264 там полное мыло, а у VP9 по сравнению с ними идеально четкий текст. VP9 иногда прихватывает кусок бэкграунда, когда цвет похож/границы совпали (motion compensation видимо дyреет), но этот эффект так или иначе вылезает у всех трех. А вот мелкий текст наиболее приятно выглядит у VP9, как ни крути.
> а алгоритмическая оценка это оценивает неправильно. Но при кодировании
> с постоянным CRF такой проблемы нет. С ним вообще намного проще.Вот только с точки зрения здравого смысла - черный квадрат не очень логично гнать с суперкачественной квантизацией. Его как ни квантизуй, а получишь... в общем, зачем нам лишние биты на пустых кадрах? Их логичнее отдать сценам где они нужнее. По поводу чего режим с постоянным качеством у меня чрезмерного оптимизма не вызывает.
> С трудом. HEVC стандарт, считайте, еще не утвержден до конца.
Ну вон и VP9 доделывают на ходу. High bit depth вон прикрутили, все дела. А в глубоких недрах есть и нечто "next". Может быть VP10, а может и прямо так удастся включить. Этого еще и кексы из гугля не знают.
> расширенные профили, к началу 2016 - дополнительные расширения, помогающие кодировать
> отрендеренный текст, графику и анимацию (внезапно, наш случай).А потом будем чесать репу - какой же процент пользователей на данный момент все это счастье понимает, а кто не сможет это проиграть. Очень удобно, ага. Главное бардака развести побольше. Ну как с кодированием в х264 - high profile и потом узнаванием того что половина аппаратных кодеков так не умеет, так что или размахивания про аппаратные видеодекодеры идут лесом с интересом, или мы пользуемся урезанным и упрощенным субсетом H.264 без половины фич.
> потихонечку начнет свой путь. А VP9 уже существует почти 4 года..
При том мне намного больше нравится отношение гугли к процессу. Народ сказал - хотим high bit depth, гугл сказал - сделаем. ЧСХ не соврали. При том все это сразу же и внедряется в один из самых популярных браузеров, да и остальным разлетится оперативно. А х265 - вообще в вебе пока ноль, а с отношением к делу акул из мпеглы и прочая - они получат то что заслуживают.
> Так что сравнивать их популярность имеет смысл не раньше, чем через
> 2-3 года. Подобному кодеку нужно дозреть.Через 2-3 года народ может допилить какую-нибудь Daala и надрать всем зад. Как в случае с Opus, который вынес вообще всех. Даже супер-дупер варианты AAC, так что любителям cocaть у обладателей патентов - пришлось безоговорочно капитулировать. Если честно, у меня ощущение что xiph + google уже вполне себе заруливают зажpaвшихся инженеров из IEEE, которые перешли в режим подстилания под эппл и микрософт, втюхивая максимальное число патентованных техник своих хозяев, игнорируя проблемы всех остальных. Так что акул уже не одна стая, а даже целых две образовалось. Спасиб, стандартизаторы которые стандартизируют OOXML с спеками на 6000 страниц и требуют использовать патентованные техники - могут идти лесом с интересом. Они лишний элемент пейзажа. Такие "стандарты" миру ни к чему. Представьте себе что вас попросили бы за все винты M3 заплатить роялти. Стали бы вы пользоваться резьбой M3? :)
> Лично я вижу жуткое дрожание текстур на первых блоках титрах
Так x264 у вас там вообще какое-то адское мерцание устроил, с расколбaсом значительной площади (эпилeптикам понравится, если на фулскрин), х265 - получше, да, но дальше титры все-равно гyняво смотрятся.
> Но как я уже сказал это *некорректное* сравнение. Просто у утилиты x264
> rate control не рассчитан на цифры. В тoпку. Кодировать с постоянным
> качеством и проблемы не будет.Так это... я вроде не выдвигал к вам никаких требований - чем именно кодировать и как именно распределять битрейт. Только пожелание чтобы размер не превышал мой файл и был более-менее в тех же пределах. Единственное что если битрейт раскидывался руками - это нехило бы указать отдельно, поскольку кроме кодека еще и человек работал, тратя свое время на то что должна была сделать машина.
>> H.265 вел себя приличнее, но читаемость текста все-равно убил изрядно.
> Тоже относится к ситуации выше, но, полагаю, это несложно исправить и без
> перехода на CRF.Мне не нравится хрень типа "переход на CRF", поскольку я нахожу глупым квантовать с приличным качеством всякие пустые кадры, тратя биты неизвестно что. Тезис о том что все сцены надо под одну гребенку - выглядит упрощением из эпохи мпег 1.
> Просто настройки по умолчанию рассчитаны на обычное видео с камеры.
А про то что в видео бывают титры - создатели этих кодеков не слышали?
> x265 как в оригинале,
Если посмотреть в правильных местах (там где интенсивное движение, так что rate control и прочим приваливает работенки) - можно увидеть вполне себе обычное "мыло". И вообще в целом х265 именно мылит, а-ля VP9. Может немного менее топорно местами, но смысл похожий. Забавно когда критиканы VPх с наездами на мыло резко любят то же самое мыло с другими буковками ;). Что еще забавнее - половина дум9 с мыслью про мыло согласны вроде.
> у x264 неплохие,
Только на квадратики рассыпаются, как на бегущем зайце. А в титрах - вообще психоделика какая-то в начале большого блока, когда там все кислотно мерцает разными цветами с высокой частотой. Весьма невкусный артефакт сжатия, имхо. При том это у вас, я вас не заставлял с этими параметрами кодировать.
> у VP9 - полное мыло..),
Вообще-то, тексуры там в большинстве мест где их хорошо видно (относительно статичные места) - как раз проработаны замечательно и даже никаких особых артефактов и проблем я там не вижу, он без особых проблем уложился.
> но вообще анимация,
В данном случае оно скорее "фильмоподобное" нежели "анимационное". По общим свойствам матриала это ближе к тому что с камеры идет, хоть и не 1 в 1 (шума в первом приближении - нет). Но что приятнее - VP8/9 не сильно лажают и на скринкастах, прорабаывая резкие границы не хуже чем титры вот тут, даже при кодировании с deadline = realtime. Тогда как 264 может запросто изгадить такую картинку. И я как-то не умею при 1-проходном, подпертом реалтаймом кодировании bitrate curve расставлять, а место на диске не резиновое и поднимать битрейт в ...цать раз на всякий случай - мне не очень охота, если что.
> а также титры требуют специальных настроек.
А что, поработаешь "демоном максвелла" на серваке гугли, расставляя миллионам мувиков в день правильное распределение битрейта? Или к вопросу о том почему качественная автоматика в распределении битрейта не пустой звук: юзкейсы бывают разные.
> H.265, но мне вполне вероятно будет нечем его проигратьТак вроде все мажорные линуксовые плееры умеют HEVC: kodi (с 14 версии), mpv (этак с год назад научился), vlc (2.1.1)
> Так вроде все мажорные линуксовые плееры умеют HEVC: kodi (с 14 версии),
> mpv (этак с год назад научился), vlc (2.1.1)Хз, у меня нет ни 1 файла в этом формате и я без понятия где их брать. Самому закодировать? А зачем? Я в VP9 лучше покодирую и научусь им кодировать хорошо. Это потом будет играться у 60-80% населения веба. А проприерасы пусть и ощущают себя инвалидами веба, имхо. Мне так больше нравится, прикиньте? Это интереснее чем когда проприерасы вторым сортом пытаются выставить опенсорс и я не вижу ничего зазорного в применении проприерасовских методов к их же окорокам :)
Иксперты заливающие на rghost...
> а также режимов с 10- и 12-битами на цветовой канал;Как раз новый сезон аниме пошёл.
А оно такое же тормозное, как x265 ?
На Core i7 x265 выдает жалкие 15 fps при кодировании
> А оно такое же тормозное, как x265 ?А это как попросите - так и будет. Может реалтаймно фигачить, но битрейт/качество будет хуже. Может супермедленно но - максимально качественно (при равном битрейте).
> На Core i7 x265 выдает жалкие 15 fps при кодировании
Можно закодировать видео быстро, качественно и компактно. Выберите любые 2 из 3 ;)
Ну а что же хорошего в этом проприетарном поделии?
> Ну а что же хорошего в этом проприетарном поделии?Как что, деньги MPEG LA и какой там еще группе вымогателей приносить будет. За все заплатит лох^W покупатель.
> Можно закодировать видео быстро, качественно и компактно. Выберите любые 2 из 3
> ;)Эту рекламу можно услышать от любого производителя любого коммерческого гумуса. Придумай что-нибудь поновее.
> что-нибудь поновее.Это международный стандарт оценки. Он универсален.
>> Можно закодировать видео быстро, качественно и компактно. Выберите любые 2 из 3 ;)
> Эту рекламу можно услышать от любого производителя любого коммерческого гумуса. Придумай
> что-нибудь поновее.Это не реклама, баклан. Это капитанинг.
Смотри: чем больше времени мы потратим на поиск отличий от прошлого кадра и попытки представить новый кадр как некие отличия (перемещения, etc) от старого - тем выше будет коэффициент сжатия при прочих равных. Однако чем более полный поиск вариантов представления нового кадра делается - тем больше времени CPU на это уйдет.
Баклан твой папа. Речь как раз и идет про капитанинг. То же самое можно сказать про любой кодек. Это и есть банальная реклама.
> самое можно сказать про любой кодек.ВНЕЗАПНО, капитаны - капитанят.
> Это и есть банальная реклама.
Не очень понимаю что я там отрекламил. Принцип 2 из 3? А он заслуживает рекламы - часто встречается и работает :). И разумеется это касается разных кодеков. Чего вы взъелись то? Если что - HEVC сватал какой-то иной аноним.
Отличная новость! VP9 имеет все шансы стать стандартом в мире Web, а затем и индустриальным стандартом.
Не стесняемся, голосуем тут и тут, чтобы в нового Осла его включили, а Сафари потом было бы некуда деваться. https://wpdev.uservoice.com/forums/257854-internet-explorer-... https://windows.uservoice.com/forums/285214-project-spartan/...
> Не стесняемся, голосуем тут и тут, чтобы в нового Осла его включили,Лучше пусть не включают - больше народа свалит на хром и лису из-за качественного контента на ютубе.
> больше народа свалит на хром и лису из-за качественного контента на ютубеПока из-за качественного контента на ютубе народ с лисы может разве что свалить. С каждым релизом пользователи ноят о багах с мультимедиа.
Да и у гугла в высоком качестве видео одинаково доступно, что в свободном, что не в свободном формате (опять же по крайне мере пока)Да и вообще с ютюба надо валить, ибо зонд, монополист, зажрался, рекламы напихал, платные подписки ввёл, почти принудительная интеграция с Гэ плюсом (надеюсь ничего не забыл)
> С каждым релизом пользователи ноят о багах с мультимедиа.Не заметил никаких особых багов мультимедии в свежей лисе. А так с учетом числа пользователей - там ноют о самых разных вещах.
> Да и у гугла в высоком качестве видео одинаково доступно, что в
> свободном, что не в свободном формате (опять же по крайне мере пока)У них вообще ничего не доступно в H.265. Так, для начала.
> Да и вообще с ютюба надо валить, ибо зонд, монополист, зажрался, рекламы
> напихал, платные подписки ввёл, почти принудительная интеграция с Гэ плюсом (надеюсь
> ничего не забыл)Ну, вали. А я не собираюсь пользоваться флешом и геморроиться с патентованными форматами. Поэтому желающие стать конкурентом гугле должны быть как минимум не хуже. Для меня это включает поддержку VP8/9.
"Я, я, я, УМВР" - только это не отражает общего положения вещей и рынка.
Да, именно пока используемый H264 уступает по тех параметрам VP9 в отличии от H265.
По поводу флеша - многие видеохостинги поддерживают HTML5 видео (vimeo, dailymotion, metacafe), но само собой по контенту они уступают монополисту.
Да и вот так облизывать гугл, который сам же и запиливает поддержку H265 в свой хромиум и который переведёт свои ролики из H264 в H265, потому что трусит вырубить несвободные кодеки на тытрубе, ибо боится потерять 50% пользователей из-за бабок с рекламы - по моему это двуличие и лицемерие.
> "Я, я, я, УМВР" - только это не отражает общего положения вещей и рынка.Зато гугл с ютубом и браузером, смартами и планшетами - ответит на любые вопросы по поводу рынка и долей на оном.
> Да, именно пока используемый H264 уступает по тех параметрам VP9 в отличии от H265.
И VP9 играется браузерами. А H265 - ну понятно чего.
> По поводу флеша - многие видеохостинги поддерживают HTML5 видео (vimeo, dailymotion, metacafe),
> но само собой по контенту они уступают монополисту.А еще не умеют VP8/9 в массе своей. Поэтому если их замнет гугл - я только за. И эплоту всякую пусть замнут (микрософт с виндофоном уже погоды не делает, вот пусть эппл еще туда же отпправится - по заслугам будет).
> Да и вот так облизывать гугл, который сам же и запиливает поддержку
> H265 в свой хромиумНе вижу - где там поддержка H265.
> и который переведёт свои ролики из H264 в H265, потому что трусит вырубить
> несвободные кодеки на тытрубе, ибо боится потерять 50% пользователей
> из-за бабок с рекламы - по моему это двуличие и лицемерие.По-моему там как раз все логично - гугль продвигает свои решения, но мягко а не жестко.
> запиливает поддержкуH265 в свой хромиум
> Не вижу - где там поддержка H265Опять же то, что ты не видишь, не хочешь видеть и т.д. не меняет сути https://code.google.com/p/chromium/issues/detail?id=454948
Ога, нравятся мне такие кадры:> we don't need to add software decoder
Ну то-есть играться будет только на девайсах с хардварным декодером, то-бишь по принципу random(10). Их тима то поди ориентируется на какие-то внутренние юзкейсы, типа поставки девайса по типу приставки к телеящику, с аппаратным декодером который так заведомо умеет, так что 100% этих девайсов будут играть то что хотела эта командочка.
Но в постановке вопроса от той командочки нет ни малейшего намека на то чтобы каждый первый обладатель хрома/хромиума в любой ОС на любом девайсе мог бы играть это видео, что намекает что они целятся в какой-то свой юзкейс а не решение которое GA.
На самом деле не так, они для венды и os x запилили GPU декодирование, а про линукс сослались, «что графическая система плохая, пилить не будем»
> На самом деле не так, они для венды и os x запилили GPU декодирование,При том для начала GPU умеющих H.265 - полторы модели на планету.
> а про линукс сослались, «что графическая система плохая, пилить не будем»
Вы когда врете - следите чтоб усы не отклеивались. Потому что тут в соседних коментах рассказывают как включить это самое "нереализованное" ускорение через флаги в хроме. Интересная фигня - не реализовано, но включается. Где-то здесь нестыковочка! :)
Чтоб ничего не отклеивалось и грива была мягкой шелковистой есть простой рецепт.
Проверять что значат флаги типа ignore-gpu-blacklist, проверять оф багтрекеры на информацию, проверять самому, проверять выхлоп браузера на то что используется ли реально GPU декодирование видео и т.д. и т.п. Это не трудно.
Можно конечно с радостным видом включить ignore-gpu-blacklist и думать что он включит GPU декодирование на линуксе, но только это как раз неправда.
> Можно конечно с радостным видом включить ignore-gpu-blacklist и думать что он включит
> GPU декодирование на линуксе, но только это как раз неправда.А вы как эталон правды - приведете нам ссыль на источник ваших данных про отсутствие поддержки? А то я код нашел, если что.