> Нет, я предлагаю использовать отл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 расставлять, а место на диске не резиновое и поднимать битрейт в ...цать раз на всякий случай - мне не очень охота, если что.

> а также титры требуют специальных настроек.

А что, поработаешь "демоном максвелла" на серваке гугли, расставляя миллионам мувиков в день правильное распределение битрейта? Или к вопросу о том почему качественная автоматика в распределении битрейта не пустой звук: юзкейсы бывают разные.