CHYOSS
Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата:| Они кодируют AVC видео в мыльном фаст пресете, а на VP9 выделяют больше ресурсов и кодируют как положено. И в итоге получается, что потенциал AVC не раскрывается (в том же битрейте он может существенно больше и лучше), зато посредственный VP9 можно выдать "более качественный", если сравнивать сэмплы с ютуба. |
Что-то у Вас всё перемешалось, кони-люди, "посредственный", "более качественный", "не раскрывается"....
Предположим что Гугл не хочет, "раскрывать потенциал AVC".
Но какой в этом смысл? Чтоб показать некой маленькой кучке пользователей, которые лезут в дебри и разбираются в стандартах сжатия, что AVC плохой, а VP9 хороший? Но кучка незначительная. Это как-то очень мелочно, особенно учитывая остальные аспекты.
Я выкачивал несколько раз сэмплы с ютуба и сравнивал, для роликов H.264 в FHD предположительно использовалось качество Medium. Да и в целом Medium это качество кодирования по-умолчанию, для х264 если ему в командой строке не указать пресет, по умолчанию будет Medium. Да и 3 B-Frames и 3-Ref тоже этому пресету соответствуют. Ощущение что Ютуб не запарились просто настроили по умолчанию так и юзают, без доп. ключей, как х264 кодит из коробки, а с другой стороны, стоит понимать, Ютуб использует Vp9 и Av1 не для "качества", а для более плотного сжатия, и уменьшения потока.
Т.е. при переключении на эти стандарты, лучшего качества не будет, вы уменьшите кол-во потребляемого трафика, и уменьшите нагрузку на датацентры Гугла (Ютуба)
Т.е. если просто, то поток Н.264 самый толстый, и имеет самый высокий битрейт, Vp9 имеет сниженный битрейт примерно на 25% хотя в некоторых сэмплах доходит до 50% снижение битрейта, Av1 еще сильнее ужимает и снижает битрейт. Но при этом качество видео во всех случаях примерно на одном уровне. И это понятно, потому как для Гугла гораздо критичнее и профитнее снижение битрейта что очень положительно сказывается на производительности его датацентров.
А поскольку качество всех семплов получается примерно на одном уровне, можно предположить что Гугл кодирует ролики с какими-то оптимальным для нужд Гугла, приемлемым уровнем Quality, а размер потока, уже упирается в то, насколько тот или иной encoder настроен и способен сжать поток для достижения этого самого Quality.
Т.е. если возвращаться к идее того, что Гугл хочет показать убогость H.264 и крутизну Vp9 то тогда надо было оставлять одинаковый размер потока для Vp9, и тогда он бы именно что качественно превосходил бы AVC. Но как видим логика тут другая.
Да и возвращаясь к идее того, что подавляющее большинство юзеров ничего никуда не переключают, они смотрят так как есть, всеми переключениями у них занимается Ютуб, или приложение в телефоне, и там логика вообще не такая. Ютубу надо чтоб юзер беспроблемно смотрел видео, и рекламу ессно, и видео должно не глючить, зависать, постоянно подгружаться итд. Потому как если приложение видит что аппарат Vp9 не умеет вообще, тогда приложение запускает поток с H.264 и таких случаев много, а лишняя нагрузка на датацентры не нужна, значит сильно занижать и плохо жать H.264 Гуглу тоже не выгодно. А тут приложение замечает что много дроп. фреймов. У юзера, оказывается, плохой мобильный интернет, приложение начинает снижать качество, и вот уже 720p, но и 720p интернет не вытягивает, всё равно видео лагает, качество снижается еще ниже, и алгоритм приложения, делает финт ушами и подсовывает продолжение с потоком av1, да оно жрёт процессор, но по сравнению с Н.264 у Av1 битрейт при том же качестве значительно ниже, и вот дропфреймы прекращаются, приложение делает вывод что для av1 хватает скорости интернета и поднимает качество до 720p и юзер досматривает ролик с приемлемым качеством, но есть развилка и другая, финт ушами к положительному результату не приводит, приложение возвращается на H.264 и снижает качество до уровня Waka Waka https://coub.com/view/2z1l60
И в добавку, у Н.264 есть существенный недостаток, он в своей изначальной редакции, не умеет в HDR, позже прикрутили, но в железо пошёл изначальный стандарт, так что H.264 HDR экзотика, и железом крайне слабо поддерживается, чё-то там еще пыхтели поначалу, но когда замаячил HEVC который всё и сразу может изначально, без костылей, то все костыли для H.264 утратили актуальность, а без HDR в будущем он мало кому нужен, напоминаю VP9 в HDR умеет. И это ставит крест на 4K потому как 4K это переход к следующему стандарту высокой чёткости, 4K + HDR и H.264 туда не подходит.
И относительно иного аспекта, это схожесть как с Нвидия, которую уже не раз пытались уличить в том, что они занижают обновлением драйверов скорость старых поколений видеокарт, для продвижения новых. Но когда начинали разбираться, то всё немного не так, по факту Нвидия не занижала старые поколения, а просто после выхода новых, забивала на оптимизацию старых, и вроде бы как и не ухудшает но и не развивает. Здесь работает такая же логика, Гугл конечно же будет развивать и продвигать свои стандарты сжатия, ну это очевидно, все корпорации и компании так делают, развивают и продвигают своё. Поскольку Гугловские стандарты являются в роли догоняющих по многим аспектам, Гуглу необходимо использовать такую стратегию продвижения, чтоб как-то навёрстывать отставание. Без агрессивного пропихивания- внедрение поддержки в железо однозначно происходило бы медленнее, и если смотреть по результату, то наверное с позиции Гугла они всё делали правильно, ведь если бы они не продвигали свои стандарты, то возможно внедрение в железо так и оставалось бы где-то там, далеко. Но и Гугл тут всё таки в роли "Корпорации добра" потому как их основная идея в том, что медиа стандарты должны быть свободными в интернете, и они всё это открыли и заопенсорсили, это им даёт огромный бонус.
А то для примера Майкрософт, тоже имел свои стандарты и пытался их продвигать, вот только что-то как-то не срослось, и слава богу ))
оффтоп |
Всего записей: 313 | Зарегистр. 12-08-2006 | Отправлено: 21:54 22-06-2023 | Исправлено: Maz, 21:33 25-06-2023 |
|
