Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск кодировщика SVT-AV1 2.0 и декодировщика dav1d 1.4 для формата видео AV1"	+/–
Сообщение от opennews (??), 15-Мрт-24, 15:31
Опубликован выпуск библиотеки SVT-AV1 2.0 (Scalable Video Technology AV1) c реализациями кодировщика и декодировщика формата кодирования видео AV1, для ускорения которых задействованы присутствующие в современных CPU Intel средства аппаратного распараллеливания вычислений. Проект создан компанией Intel в партнёрстве с Netflix с целью достижения уровня производительности, пригодного для перекодирования видео на лету и применения в сервисах, отдающих видео по запросу (VOD). В настоящее время разработка ведётся под эгидой альянса Open Media (AOMedia), курирующего развитие формата кодирования видео AV1. Ранее проект развивался в рамках проекта  OpenVisualCloud, который также разрабатывает кодировщики SVT-HEVC и SVT-VP9. Код  распространяется под лицензией BSD... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60788
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от Аноним (-), 15-Мрт-24, 15:31	+7 +/–
> Для использования SVT-AV1 необходим процессор x86_64 с поддержкой инструкций AVX2. > Для кодирования 10-битовых потоков AV1 с качеством 4K требуется 48 Гб ОЗУ, 1080p - 16 Гб, 720p - 8 Гб, 480p - 4 Гб Автор новости, вы пишете неправду и дезинформацию. Очевидно из-за копипаста из новости в новость. 1) SVT в какое-то время перешел из лап интеля в AOM. 2) После этого системные требования оному - радикально снизили. На минималках есть чисто сишная версия. Есть несколько оптимизаций под SSE2, AVX, NEON, а может и еще что. AVX2 в обязаловку сто лет как не надо уже ему! 3) Жор оперативы ему тоже очень радикально поубавили. Реально на 720p с разумными настройками более гига-два не жрет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #5, #7, #36

4. Сообщение от Аноним (4), 15-Мрт-24, 15:42	–5 +/–
Да и про "больше вычислений" прохладное, если vp9 подкрутить на качество он будет получше libaom картинку на битрейт выдавать (и уж точно меньше глитчей), но это будет не меньше сложность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #8

5. Сообщение от Аноним (5), 15-Мрт-24, 15:43	+/–
Забавно, что автор ещё и ссылку поставил на документ, в котором примерно то же самое написано. Возможно он просто не так понимает значение слова "необходим".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

7. Сообщение от birdie (ok), 15-Мрт-24, 15:47	+/–
> дезинформацию Очевидно, что вы не понимаете значение этого слова. Оно обозначает желание её автора вас обмануть с тем, чтобы получить выгоду или создать вам картину мира, выгодную для него. У Максима нет и не было таких намерений. Да, он копирует информацию за неимением более новой. Ваш коммент никакой информации на тему не содержит: > Реально на 720p с разумными настройками более гига-два не жрет. Вот это просто понос. Слово "разумный" что-то значит только для вас. Покажите данные для всех разрешений с нужной битностью с настройками кодирования для максимального качества. Ваши fast presets encodes YUV420 исходников никого не волнуют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #15, #66

8. Сообщение от Аноним (-), 15-Мрт-24, 15:48	+4 +/–
> Да и про "больше вычислений" прохладное, если vp9 подкрутить на качество он > будет получше libaom картинку на битрейт выдавать Не, не будет. У VP9 сильно меньше tools для кодирования и уменьшения потока данных не в ущерб визуальному качеству. Поэтому при равном визуальном качестве VP9 обречен весить заметно больше. > (и уж точно меньше глитчей), но это будет не меньше сложность. Он кодирует побыстрее - но битрейт-качество у него заметно хуже AV1, что libaom что сабжа. Я сравнивал side by side, оно не конкурент этой парочке от слова вообще. В AV1 на уровне формата потока ряд весьма крутых фич завезли - а у VP9 их нету. Он сразу на старте в проигрыше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #13

11. Сообщение от Аноним (11), 15-Мрт-24, 15:59	–7 +/–
dav1d и вообще av1 мусор, я как-то пытался 30 секунд видео закодировать, он и одну секунду больше часа кодировал на 100% cpu. Так что использовали x265 - будем x266. Правда даже x265 в опенсорс проектах очень не любят из-за потенциальных проблем с патентастами,  даже если x264 используют.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17, #19, #60

13. Сообщение от Аноним (4), 15-Мрт-24, 16:04	–1 +/–
А почему у кодеров h265 без этих крутых фич картинка лучше и битрейт куда эффективнее расходуется? Не в них счастье, получается. Хотя, в том же кривом libx265 надо психовизуальщину отключать, иначе тоже весь битрейт на отсутствующие в исходнике гличи отправит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #18, #37, #53

15. Сообщение от Аноним (-), 15-Мрт-24, 16:10	+/–
> Очевидно, что вы не понимаете значение этого слова. Оно обозначает желание её > автора вас обмануть с тем, чтобы получить выгоду или создать вам > картину мира, выгодную для него. У Максима нет и не было > таких намерений. Да, он копирует информацию за неимением более новой. Кто-то запретил сорц скачать или немного исследовать тему? Зайти на тот же Doom9 или куда там еще? А, ну да, копипастой проще? И хрен с ним что новость технически некорректная - при том в совершенно вопиющем масштабе вот тут. Чего я такой злой? А вот то: наслушался подобных [beep!] и долго игнорил SVT, пока скепсис не взял свое - и я не тестанул его лично! И тут я узнал много нового! :E Оказывается, никакого AVX2 не надо, память давно не жрет в тех объемах, и вообще, это не новость - а на@#ка сплошная! Сцук, теперь это мой любимый кодек, AOM сделали из него реально нормальный и крутой проект толпой, не то что интел изначально. А пару лет тупняка с этим - достаточно чтобы крепко не любить всех кто способствовал такому гранд-на@бизму, и опеннет в топе этой "заслуги" с такими новостями! Это вредительство какое-то а не новость. > Ваш коммент никакой информации на тему не содержит: Наверное ваш комент ценнее и полезнее? > данные для всех разрешений с нужной битностью с настройками кодирования для > максимального качества. Просто для понимания: я этот кодек не так давно собрал и протестировал, прикинув что доверять экспертизе опеннетчиков - такое себе. В паре с свежим ffmpeg. И тут я осознал во сколько именно раз меня наели в таких "новостях". И это было не круто. Мягко говоря. Для вот именно МАКСИМАЛЬНОГО (-preset=0..1) - вы опупеете его ждать по CPU прежде всего! И там уже имхо будет пофиг на потребление RAM. Которое, впрочем, не сильно меняется от preset'а. Более того - этой штуке в какой-то момент навесили адаптив! Если в энной системе недостаточно рам относительно того что хотелось - окей, скушает сколько есть, а не сколько хочется, немного урезав осетра. Битрейт-качество немного пострадает но ничего > Ваши fast presets encodes YUV420 исходников никого не волнуют. Я кодирую с близким к топовому preset=2..3, и в 10-bit mode потому что так битрейт-качество лучше и артефактов меньше. И даже так - те цифры полный булшит на данный момент. Оказывается, за несколько лет программу оптимизировать могут. И новость превращается в какое-то вредительство просто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #26

17. Сообщение от Аноним (17), 15-Мрт-24, 16:11	+5 +/–
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #28

18. Сообщение от потому (?), 15-Мрт-24, 16:13	+/–
> А почему у кодеров h265 без этих крутых фич картинка лучше и битрейт куда эффективнее расходуется? Не лучше, дядя. Купи очки и выбрось уже CRT, на дворе 2k24.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #24, #25

19. Сообщение от потому (?), 15-Мрт-24, 16:15	+2 +/–
> я как-то пытался 30 секунд видео закодировать, он и одну секунду больше часа кодировал на 100% cpu. дай угадаю - на пне 3?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #30, #81

21. Сообщение от Аноним (37), 15-Мрт-24, 16:25	+/–
Кто-нибудь знает какая связь между AOMedia AV1 codec ( https://aomedia.googlesource.com/aom/ ) и SVT-AV1 ( https://gitlab.com/AOMediaCodec/SVT-AV1 ) ? Это же всё-таки разные кодеки? И они теперь попали под управление одной организацию? И теперь их смержат, или как?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #31, #61

24. Сообщение от Аноним (4), 15-Мрт-24, 16:38	–2 +/–
>Не лучше, дядя. Купи очки и выбрось уже CRT, на дворе 2k24. Конечно, лучше. Это подтверждается и визуально при покадровом сравнении, и даже libvmaf. Ну а уж если вспомнить, что намного дешевле кодировать/декодировать, то тут фаворит очевиден. Вообще, я давно заметил, что за av1 топят какие-то полнейшие неадекваты, начитавшиеся брошюр и неспособные самостоятельно сравнить. Этот кодек придуман не для того чтобы быть качественнее проприетарного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #55

25. Сообщение от Аноним (25), 15-Мрт-24, 16:39	+/–
В 2240, наверное, уже даже голография будет считаться устаревшей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

26. Сообщение от Аноним (26), 15-Мрт-24, 16:40	+/–
> AOM сделали из него реально нормальный и крутой проект толпой, не то что интел изначально А ничего что те же самые разработчики пилят тот же самый проект под другим руководством? Флаг поменяли и из "говнокодеров" в "нормальных" превратились (им интел как платил зарплату так и платит). Парад лицемерия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #58

28. Сообщение от КО (?), 15-Мрт-24, 16:43	–3 +/–
Пфф, вот сейчас на Sandy попробовал, такой же эффект 100% загрузки и ноль эффекта Очередная лоховушка от копрорастов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #33

29. Сообщение от Аноним (26), 15-Мрт-24, 16:45	+2 +/–
попробуйте уловить разницу между кодеком, спецификацией, реализацией и проектом под которым разработка реализации ведется. AV1 - кодек. алгоритм как че пожать и распаковать. AOMedia - организация. пачка перцев от разных корпораций собралась и сказала "ну мы тут будем смотреть че каво делается с кодеком. и друг дружку обижать не будем, патентные претензии предъявлять". под эгидой AOM есть несколько реализаций /aom/ aka 'AV1 Codec Library' - изначальная "референсная" реализация которая не подразумевала оптимизации вовсе изначально. с нее и пошел мем про "AV1 в 10000 раз медленнее H.264". /dav1d/ - быстренький декодер AV1 /SVT-AV1/ - быстренкьий энкодер AV1. изначально интел его пилил, теперь как бы весь AOM, но по сути главные разрабы так же из интела.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #38, #52

30. Сообщение от Аноним (25), 15-Мрт-24, 16:45	+1 +/–
1 с за час? На 80386, наверно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #43

31. Сообщение от Аноним (26), 15-Мрт-24, 16:46	+/–
Я не думаю что их объединят, маловероятно, слишком сложная задача, в 10 раз сложнее чем каждый проект с нуля переписать. Плюс референсный проект все же и декодер и энкодер предоставляет, т.е. они не идентичны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

33. Сообщение от Аноним (17), 15-Мрт-24, 16:55	+2 +/–
Вы там посмотрите таблицу поддержки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #41

35. Сообщение от Аноним (35), 15-Мрт-24, 17:23	+/–
Я, было, думал, что выход второй версии будет одновременно со стабилизацией AV2. Но нет же. Ладно, ждём.
Ответить | Правка | Наверх | Cообщить модератору

36. Сообщение от Аноним (36), 15-Мрт-24, 17:36	+/–
>Для использования SVT-AV1 необходим процессор x86_64 с поддержкой инструкций AVX2. Для кодирования 10-битовых потоков AV1 с качеством 4K требуется 48 Гб ОЗУ, 1080p - 16 Гб, 720p - 8 Гб, 480p - 4 Гб Да, как уже отписались, это устаревшая информация, с avx2 быстрее и он рекомендуется, но не требуется и по памяти за это время было много оптимизаций и теперь 16 Гб вполне хватает для кодирования 4K на типичном десктопном процессоре, для серверных с кучей ядер или для самых медленных пресетов типа 0 или -1, может нужно и больше >Из-за усложнения применяемых в AV1 алгоритмов, для кодирования данного формата требуется существенно больше ресурсов, чем для других форматов, что не позволяет применять штатный кодировщик AV1 для перекодирования в реальном времени. Например, штатный кодировщик от проекта AV1 требует в 5721, 5869 и 658 раз больше вычислений по сравнению с кодировщиками x264 (профиль "main"), x264 (профиль "high") и libvpx-vp9. Но эта информация не имеет отношения к svt-av1, да и само по себе такое сравнение несет мало смысла, потому что это одна из первых версий референсного кодировщика с максимальными настройками качества (что в приоритете на начальных этапах, чтобы проверить потолок эффективности) с уже зрелыми оптимизированными кодировщиками с типичными настройками, да и подобным сравнениям уже больше 6 лет Сейчас же svt-av1 вполне подходит для кодирования в реальном времени (на более быстрых пресетах), да и libaom встроен в браузеры и используется для webrtc (в том числе на смартфонах, для более низких разрешений) А при достаточном количестве ядер svt-av1 даже обгоняет все прошлые поколения кодеков по скорости/эффективности (хотя по личному опыту это не всегда так, очень зависит от битрейта и контента, да и x26x все еще более стабильны по среднему качеству и имеют лучше настроенную психовизуалку)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #54

37. Сообщение от Аноним (37), 15-Мрт-24, 17:56	+/–
А с чего вы взяли, что у H.265 качество лучше и он битрейт лучше чем AV1 расходует? Тесты как бы говорят об обратном: http://compression.ru/video/codec_comparison/hevc_2020/main_...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #39, #42

38. Сообщение от Аноним (37), 15-Мрт-24, 18:05	+/–
Спасибо, понятно. Хотя, непонятно тогда, по чему репозиторий референсной реализации /aom/ такой активный. Много коммитов, веток, тэгов и релизов. Как будто там идёт активная разработка, а не лежит замороженный референсный код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #40, #84

39. Сообщение от cheburnator9000 (ok), 15-Мрт-24, 18:12	+/–
по твоей же картинке svt-av1 и x265 разница во сколько 4%? и это коллосальной ценой по затратам мощностей CPU/RAM и низкой скорости кодирования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #48, #56

40. Сообщение от Аноним (4), 15-Мрт-24, 18:14	+/–
Лучше бы не трогали, потому что 2 ветка давала лучше результаты.  Референсный означает лучший и наиболее полноценный. SVT, судя по прошлым успехам, означает мыльный и дефективный, но чуть быстрее (ценой выкидывания большей части операций). И, насколько я понимаю ситуацию, полноценный аппаратный кодер всё ещё невозможен, хотя преобразования и пытались ограничивать так, чтобы их можно было реализовать в железе. Поэтому софткодер всё равно будет востребован всегда. Доработать обещали в av2.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #77, #97

41. Сообщение от cheburnator9000 (ok), 15-Мрт-24, 18:17	–4 +/–
Даже если и купить самый новый интел с поддержкой av1 encode то этим "intel quick sync" лучше не пользоваться, слово "Quick" там не спроста, там хардвардный кодировщик всегда предпочитает скорость качеству кодирвоания, как-то пробовал для H264 качество тьфу, у nvidia лучше намного в разы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #46, #74

42. Сообщение от Аноним (4), 15-Мрт-24, 18:25	+/–
С того что мне есть что кодировать и я регулярно проверяю успехи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

43. Сообщение от cheburnator9000 (ok), 15-Мрт-24, 18:37	–2 +/–
Провал как-то кодирвоать сериалы в архив в av1 чисто для себя. На своем старом томогочике Skylake. FPS примерно 1-2. Если поубавить качество то можно добиться 4-5fps, иными словами часовую серию ждать придется примерно 5-6 часов. В то время как nvenc для H265 с хорошим качеством в два прохода выдает примерно 40-60fps на GTX1060, думаю выбор очевиден.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #64, #80

45. Сообщение от Аноним (74), 15-Мрт-24, 18:42	+3 +/–
> AV1 Не нужно. Пока не появятся дешевые затычки с пассивным охладом, которые смогут его аппаратно декодировать. Пока это возможно только в топовых GPU и во встройках свежих CPU.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50, #62, #85, #88

46. Сообщение от Аноним (17), 15-Мрт-24, 18:44	+4 +/–
>самый новый интел Вы про процессор со "встройкой" или про дискретные Intel Arc ? https://videocardz.com/intel
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

47. Сообщение от cheburnator9000 (ok), 15-Мрт-24, 18:51	+2 +/–
Для тех кто хочет посмотреть на AV1 на ютубе вот пожалуйста плейлист https://www.youtube.com/watch?v=m1jY2VLCRmY&list=PLAMlLc3Zgg... AV1 выдается не для каждого разрешения видео, но для FullHD видео есть, для 4K нашел только Anne-Marie ролике. FullHD можно смотреть даже на процессорах 10 летней давности, загрузка 10-20%. Через yt-dlp можно скачать AV1 в 4/8K для тех кто желает "поглядеть" на него. Например yt-dlp -F url для списка форматов у видео. yt-dlp -f 701 https://www.youtube.com/watch?v=1La4QzGeaaQ для ролика PERU в 4K HDR 60FPS AV1.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49, #102

48. Сообщение от Аноним (37), 15-Мрт-24, 18:51	+2 +/–
> по твоей же картинке svt-av1 и x265 разница во сколько 4%? Ага, значит вы признаёте, что изначальное утверждение, что H.265 лучше AV1 битрейт расходует - ложь? Хорошо, давайте тогда про 4%. Вы точно ту картинку смотрели? Я вот эту смотрел: http://compression.ru/video/codec_comparison/hevc_2020/figur... То что я вижу - SVT-AV1 выдаёт размер примерно на 10% меньше, чем x265. > и это коллосальной ценой по затратам мощностей CPU/RAM и низкой скорости кодирования Ого, "коллосальной" ценой. Пафоса то сколько. А вы откуда эту цену взяли, из того же места, что и "h265 хуже av1 битрейт расходует"? Скачайте с той странички отчёт исследования. Вот прямая ссылка: http://compression.ru/video/codec_comparison/hevc_2020/downl... Посмотрите PDF, страницу 14, график 5. SVT-AV1 оказался БЫСТРЕЕ x265 примерно в полтора раза.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #57

49. Сообщение от Аноним (74), 15-Мрт-24, 19:01	+2 +/–
> FullHD можно смотреть даже на процессорах 10 летней давности, загрузка 10-20%. У тебя всё равно частично видюха работает. Если её нет, загрузка на встройке хасвела будет 146 %.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #51, #99

50. Сообщение от Аноним (17), 15-Мрт-24, 19:04	+6 +/–
>дешевые затычки Intel Arc A310
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #89, #92, #95

51. Сообщение от cheburnator9000 (ok), 15-Мрт-24, 19:12	+/–
>> FullHD можно смотреть даже на процессорах 10 летней давности, загрузка 10-20%. > У тебя всё равно частично видюха работает. Если её нет, загрузка на > встройке хасвела будет 146 %. В firefox будет загружено 3D ядро для отображения кадров через firefox webrender да, декодирование только на CPU.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

52. Сообщение от Аноним (36), 15-Мрт-24, 19:32	+/–
>/aom/ aka 'AV1 Codec Library' - изначальная "референсная" реализация которая не подразумевала оптимизации вовсе изначально. с нее и пошел мем про "AV1 в 10000 раз медленнее H.264". Оптимизация также подразумевалась, он и референсный и продакшен кодировщик, тоже самое как и многие другие форматы от google, типа vp8, vp9, webp и т.п., тут это отличается от MPEG форматов >/SVT-AV1/ - быстренкьий энкодер AV1. изначально интел его пилил, теперь как бы весь AOM, но по сути главные разрабы так же из интела. В целом мало что поменялось в разработке, разве что svt-av1 больше принимает сторонние изменения (и комьюнити неплохо так добавило некоторых фишек и еще парочка интересных рассматривается) и много чего портирует из libaom, в основном разные оптимизации которых еще не было, ну а так svt-av1 все еще остается более ограниченным av1 кодировщиком, где не все возможности полноценно поддерживаются (максимум 10-бит 4:2:0, не поддерживается lossless, есть более строгие лимиты на максимальное и минимальное разрешение и т.п.), но зато быстрый и намного лучше параллелится
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

53. Сообщение от Аноним (-), 15-Мрт-24, 20:01	+1 +/–
> А почему у кодеров h265 без этих крутых фич картинка лучше и > битрейт куда эффективнее расходуется? Кто вам это сказал? Как пример: клип BBB 480p на примерно 500 кбит таргет в q-mode сабж делает практически идеальным! Найти хоть какой-то артефакт - довольно сложно. x265 при таргетировании сравнимого битрейта угробит как минимум все титры в клипе до нечитаемого месива (они там неудобные для кодирования, у AV1 видимо global motion wings it как раз). Про картинку без артефактов при таком битрейте речь не пойдет принципиальною. А если хотеть минимально сравнимую картинку, средний битрейт придется закрутить выше раза в полтора наверное! С хоть какими там настройками x265. При прочих равных он современному SVT в подметки не годится, и на их горе SVT - это не libaom, умеет жрать куда больше ядер проца, и вообще, довольно резвый. И тут вдруг предлагается платить роялти - за этот хлам? ORLY?! Надеюсь это объясняет почему исо так истошно строгает кодеки. Контроль над процессом утекает из их грязных коррумпированых лапок, обслуживающих когорту патентных троллей. > Не в них счастье, получается. Таки - и в них тоже. Сколько код xvid не оптимизируй - но x264 из него не получится. Достижимый frontier сильно зависит от доступных фич. А оптимизация множества вариантов представления до наиболее компактного и хорошо выглядящего - и тормозит современные кодеки. > Хотя, в том же кривом libx265 надо психовизуальщину отключать, иначе тоже весь битрейт > на отсутствующие в исходнике гличи отправит. В сабже же надо напротив врубать психовизуальный тюнинг - дефолтный тюнинг на PSNR, чтоли, и он работает хуже на почти всем контенте. На doom9 есть примеры. Еще сабж довольно забавен тем что в q-mode ему 2 прохода не требуются особо - он это не умеет толком, но при всем этом выдает битрейт-качество довольно сравнимый с libaom на примерно том же таргетировании. Но заметно быстрее. Да, может самую капельку хуже. Но в целом очень хорошая картинка, довольно шустро (vs liaom), проц юзает полнее, пресеты типа 2..4 на мощном проце вполне ОК по скорости даже на довольно жирных видео без радикальных вещей типа отката к tiling (улучшает параллелизуемость но портит битрейт-качество).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

54. Сообщение от Аноним (4), 15-Мрт-24, 20:06	+/–
В libvpx качество серьёзно просаживается, если больше чем в полтора потока кодировать и ограничения достаточно жёсткие. На 4к можно удвоить и это рекомендации гугла. Отчасти это решили в современных проприетарных кодеках (некоторые операции можно запараллелить), лично оценить степень деградации на av1 пока не было возможности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #59, #63

55. Сообщение от Аноним (-), 15-Мрт-24, 20:11	+/–
> Конечно, лучше. Это подтверждается и визуально при покадровом сравнении, и даже libvmaf. Ну вон качни с Xiph BBB (BigBuckBunny, нежатый вариант) в 480p и попробуй с хоть какими настройками на примерно 500kbit (среднего) вкатить. Я тебе выкачу со своей стороны 10-bit q-mode BBB с средним примерно 531 Кбит (+/- 30 кбит мне пофигу, целься туда!) в AV1. Сравним картинку всей толпой, посмотрим что мы как кодировщики видео можем? Как тебе такое, Элон Маск? Почему этого? С одной стороны весьма неудобен кодировщику по ряду аспектов, хороший стресстест. Я так "калибрую" режимы кодирования. Если BBB выглядит хорошо - остальное и подавно норм будет. С другой он с таким размером кодируется даже мощным кодеком за обозримое время на среднем железе. > Ну а уж если вспомнить, что намного дешевле кодировать/декодировать, то тут > фаворит очевиден. Это тот, за который амеровские патентные вымогатели еще и отчисления требуют - при том что формат потока убогий? Почему это фаворит у патентных троллей я еще могу понять: мало поработали но хотят много денег. А вот зачем мне такой формат в фаворе? > Вообще, я давно заметил, что за av1 топят какие-то полнейшие неадекваты, начитавшиеся > брошюр и неспособные самостоятельно сравнить. Ну вот я собираю FFMPEG с распоследними либами. И вон те МГУшные сравниватели кодеков - которые это профессионально делают, для корпов, за бабки - тоже неадекватные? > Этот кодек придуман не для того чтобы быть качественнее проприетарного. А таки - он намного лучше 265 жмет. Хоть полопайтесь там. Особенно на нижнем сегменте типа интернет-видео заметно. С ломовым то битрейтом и Mpeg2 - "типа, кодек".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #138

56. Сообщение от Аноним (-), 15-Мрт-24, 20:12	+/–
> по твоей же картинке svt-av1 и x265 разница во сколько 4%? и > это коллосальной ценой по затратам мощностей CPU/RAM и низкой скорости кодирования. Теперь попробуй инверсный лукап. Что-что, можно скостить битрейт в ДВА РАЗА при равном качестве картинки?! Вау... такие 4%, если делать лукап интересуясь битрейт-качество :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

57. Сообщение от Аноним (-), 15-Мрт-24, 20:14	+/–
> Посмотрите PDF, страницу 14, график 5. SVT-AV1 оказался БЫСТРЕЕ x265 примерно в > полтора раза. Как бы это сказать то, ща уже 2024 и данные на 2020 здорово устарели, сабжа пиляет толпа народа и буквально ежеденвно. x265 ессно пиляют куда менее активно, кому он нужен то такой, с теми соотношениями... сабжем IIRC несколько комерческих сервисов онлайн видео жмут. А x265 прикормлен чуть ли не патентными троллями в открытую уже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

58. Сообщение от Аноним (-), 15-Мрт-24, 20:17	+/–
> А ничего что те же самые разработчики пилят тот же самый проект > под другим руководством? Набежало комьюнити. Послало решения манагеров интела по втюхиванию последних процов в пень. Заоптимизили под все что шевелится. Даже ARM зашел на огонек и вкатил немеряно неона, чтобы и их процам благодати досталось. Так стало намного лучше. Кодек как тул впаривания последних интелских процов - ну такая себе идея. Особенно когда конкурирующих кодеков есть. > Флаг поменяли и из "говнокодеров" в "нормальных" превратились (им интел как платил > зарплату так и платит). Парад лицемерия. Странно, с каких пор интел платит например чувакам из @arm.com? Я бы на это посмотрел :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

59. Сообщение от Аноним (-), 15-Мрт-24, 20:20	+/–
> гугла. Отчасти это решили в современных проприетарных кодеках (некоторые операции можно > запараллелить), лично оценить степень деградации на av1 пока не было возможности. Это и в открытых решили, которые давно уже могут дать мастеркласс любой проприетари. Можно tiles юзать но это рушит битрейт-качество. Особенно на мелких видео. На 4K - урон меньше. Но есть идеи лучше. Скажем  на Doom9 есть забавная прога на хрусте которая пилит видео на сегменты, пинает ffmpeg на каждом сегменте отдельно, потом сводит все сегменты в один файл. Так можно прогрузить 100500 ядер если они есть, ничего особо не теряя в качестве. Но это больше тул для bulk-encoders которые вот реально EPYC'ов понабрали под задачу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

60. Сообщение от Аноним (-), 15-Мрт-24, 20:24	+1 +/–
> dav1d и вообще av1 мусор, я как-то пытался 30 секунд видео закодировать, > он и одну секунду больше часа кодировал на 100% cpu. dav1d невозможно закодировать видео - это декодер! А так все хорошо прекрасная маркиза :) > Правда даже x265 в опенсорс проектах очень не любят из-за потенциальных > проблем с патентастами,  даже если x264 используют. Его не любят за то что... 1) Спонсируется по сути патентными троллями. 2) По битрейт-качество ни о чем. 3) h265 не играется в вебе. 4) При таком соотношении он нафиг не упал! Как и весь h265.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #82

61. Сообщение от Аноним (-), 15-Мрт-24, 20:28	+/–
> Кто-нибудь знает какая связь между AOMedia AV1 codec ( https://aomedia.googlesource.com/aom/ > ) и SVT-AV1 ( https://gitlab.com/AOMediaCodec/SVT-AV1 ) ? Это же всё-таки разные > кодеки? И они теперь попали под управление одной организацию? И теперь > их смержат, или как? Это 2 разные проекта имплементящих одну спецификацию. Технически начинка довольно разная. Libaom - это дальний потомок Libvpx, ранее известный как VP10. SVT - изначально вообще интелем написан был, вроде с ноля, как быстрый кодер AV1 писаный с ноля. Изначально они жестили с требованиями к хардвару но после передачи AOM это требование ессно убрали. И было это уж чуть ли не пару лет назад, оказывается! А жирафли с копипастой до сих пор про AVX2 лечат, блин. Вот фэйспалмище то - новость есть, но действительности давно не соответствует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

62. Сообщение от Аноним (-), 15-Мрт-24, 20:29	–1 +/–
> Не нужно. Пока не появятся дешевые затычки с пассивным охладом, которые смогут > его аппаратно декодировать. Пока это возможно только в топовых GPU и > во встройках свежих CPU. Уже кучка одноплатников современных умеет. Где вся борда меньше этой затычки жрет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #72

63. Сообщение от Аноним (36), 15-Мрт-24, 20:38	+/–
По умолчанию SVT-AV1 может до 16 потоков полностью загружать для 1080p без какого либо изменения качества, но если использовать пресет не медленней 4, на самых медленных мультипоточность похуже. С тайлами можно совсем на сотни потоков нагрузку распределять, но они уже влияют на качество, хотя очень незначительно, меньше процента в среднем для 2+1 тайлов, да и от их использования есть дополнительные плюсы в виде более быстрого декодирования и seeking-е Хотя не для стриминга поточность не настолько важна, потому что можно использовать какие то дополнительные тулзы типа av1an, которые будут разбивать видео на куски и кодировать их параллельно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #70

64. Сообщение от Аноним (-), 15-Мрт-24, 20:40	+2 +/–
> Провал как-то кодирвоать сериалы в архив в av1 чисто для себя. На > своем старом томогочике Skylake. FPS примерно 1-2. Если поубавить качество то > можно добиться 4-5fps, иными словами часовую серию ждать придется примерно 5-6 А таки на шустрых процах вполне нормуль, пережать видики с камеры сдув их раз в 5 при визуально идентичной картинке без артефактов - не вопрос. И так далее. > часов. В то время как nvenc для H265 с хорошим качеством > в два прохода выдает примерно 40-60fps на GTX1060, думаю выбор очевиден. Ну а смысл в этой операции вообще? Если битрейт-качество похрен, можно было оставить сериал как есть и не выделываться. А тут погрели воздух - фиг знает зачем при том. Кодирование на видяхе, с таким FPSом - битрейт-качество очень неоптимальные делает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

65. Сообщение от VladSh (?), 15-Мрт-24, 20:40	+/–
> Работа пресета MR, предоставляющего эталонное качество, ускорена на 100%. Как это, на 100%?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #68, #69, #100

66. Сообщение от ИмяХ (ok), 15-Мрт-24, 20:42	+/–
>>копирует информацию за неимением более новой. Значит надо дождаться другую, более новую информацию от независимого источника, досконально проверить её, выявить и исправить все несоответствия, а потом уже писать новость. А то получится не новость, а шурнашлюшный шлак.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

68. Сообщение от Аноним (-), 15-Мрт-24, 20:44	+2 +/–
>> Работа пресета MR, предоставляющего эталонное качество, ускорена на 100%. > Как это, на 100%? Ну вот так. В два раза. Если скорость кодирования была X а стала 2X - на сколько процентов она ускорилась? Скорость в 2 раза выше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

69. Сообщение от ИмяХ (ok), 15-Мрт-24, 20:50	+1 +/–
В два раза быстрее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

70. Сообщение от Аноним (-), 15-Мрт-24, 20:53	+/–
> влияют на качество, хотя очень незначительно, меньше процента в среднем для > 2+1 тайлов, да и от их использования есть дополнительные плюсы в > виде более быстрого декодирования и seeking-е Но битрейт-качество все же довольно круто проседает. То что 1-2% по качеству - по битрейту может быть и 30% какие. Т.е. можно было урезать файло на треть при той же картинке. Инверсная зависимость весьма крутая. > Хотя не для стриминга поточность не настолько важна, потому что можно использовать > какие то дополнительные тулзы типа av1an, которые будут разбивать видео на > куски и кодировать их параллельно Ну вот этот - даже EPYC прогрузить может. Ему пофиг, он на сегменты режет, пускает ffmpeg'ов пачку, кодирует сегменты параллельно, сводит. Так любой суперсервер можно озадачить - если есть чем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #75

72. Сообщение от Аноним (74), 15-Мрт-24, 21:11	+2 +/–
> Уже кучка одноплатников современных умеет. Хоть один покажи. (не покажешь т.к. это бpeд)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #111

74. Сообщение от Аноним (74), 15-Мрт-24, 21:14	–1 +/–
> хардвардный кодировщик всегда предпочитает скорость качеству кодирвоания Epyндy нe пишитe. А то так до бескислородной меди и лампового звука дойдёте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

75. Сообщение от Аноним (36), 15-Мрт-24, 21:20	+/–
>Но битрейт-качество все же довольно круто проседает. То что 1-2% по качеству - по битрейту может быть и 30% какие. Т.е. можно было урезать файло на треть при той же картинке. Инверсная зависимость весьма крутая. Нет, я имел ввиду при том же битрейте (можно и нагулить много тестов и я сам это проверял), если речь про SVT-AV1, ну или проще сказать что общая эффективность падает на эти пару процентов, на самом деле сильнее это влияет на самые медленные пресеты, на быстрых использование парочки тайлов может даже частенько улучшить эффективность (видимо они по какой то причине лучше работают локально, из-за более упрощенных алгоритмов)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #78

77. Сообщение от Аноним (26), 15-Мрт-24, 21:30	+/–
моя GeForce 4070 вполне себе поддерживает аппаратный энкодер AV1.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

78. Сообщение от Аноним (-), 15-Мрт-24, 21:55	+/–
> Нет, я имел ввиду при том же битрейте (можно и нагулить много > тестов и я сам это проверял), Падение на 1-2% при том же битрейте - не очень информативно, в том смысле что инверсный маппинг "на сколько можно снизить битрейт при достижения все той же картинки" таки и интереснее, и информативнее. То-есть, если кодек X делает файло на 30% меньше чем кодек Y при визуальном отсутствии разницы, мы за это кодек X и любим. Даже если на битрейте Z формальная разница визуальных метрик "всего" 1-2% - это не отменяет вон ту крутизну инверсной зависимости. И пыхтим мы чтобы при визуально идеальной по возможности картинке - скостить битрейт до уровня пока картинка все еще трудноотличима от оригинала. > если речь про SVT-AV1, ну или проще сказать что общая эффективность падает на > эти пару процентов, Эти пару процентов оттранслированые в инверсный топик, как то - "какой битрейт надо для визуально такой же картинки" выгдядят куда пессимистичнее. Там довольно крутая зависимость, и в одной из прошлых новостей кто-то показывал этот фокус, просто расчертив графики, маппинг осей битрейта-качества. То что 1-2% на одной - довольно дохрена битрейта на другой так то. > на самом деле сильнее это влияет на самые медленные пресеты, на > быстрых использование парочки тайлов может даже частенько улучшить эффективность Это в целом плохой способ увеличения эффективности, особенно если это менее 1080p размером. На 1080p - можно, но не рекомендуется. На 4К уже вариант. Если вдруг все ядра еще и так не сожраны (у вас там что, реально EPYC последний?). Еще от числа тайлов зависит. С 2 потери меньше чем с 4 например. Но и параллелизм хуже. > (видимо они по какой то причине лучше работают локально, из-за более упрощенных > алгоритмов) Таки это несколько неоптимально - реюз инфо на границах и проч хромает. И в целом битрейт-качество теряется. И это довольно заметный шаг назад, его рекомендуют только как last resort. Другие варианты могут быть дать приемлимый эффект при меньших потерях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #79

79. Сообщение от Аноним (36), 15-Мрт-24, 22:49	+/–
>Падение на 1-2% при том же битрейте - не очень информативно, в том смысле что инверсный маппинг "на сколько можно снизить битрейт при достижения все той же картинки" таки и интереснее, и информативнее. Обычно выстраиваются графики с BD Rate (Bjontegaard delta rate) с кодированием в разные битрейты и сравнением каких то настроек, в данном случае тайлов и затем все это измеряется разными метриками или MOS (Mean opinion score), для обычных людей проще использовать метрики и взять или написать какой то скрипт для вычисления метрик и построения таких графиков, метрики не идеальны, но если будут какие то заметные изменения, то они это покажут, ну и вот на тайлах эти изменения минимальны, если с ними не перебарщивать. Можно также и визуально сравнить, но разницу с использованием парочки тайлов я думаю мало кто заметит, av1 достаточно эффективно работает с ними. Если не хочется строить графики, можно просто сделать кодирования с тайлами и без в одинаковый битрейт (с 3 или сейчас с 2-проходами) и сравнивать, тут не будет такого разброса битрейта, пару тайлов даже и для однопроходного crf то не особо на битрейт влияют, так что это достаточно простой способ. >Это в целом плохой способ увеличения эффективности, особенно если это менее 1080p размером. На 1080p - можно, но не рекомендуется. На 4К уже вариант. Если вдруг все ядра еще и так не сожраны (у вас там что, реально EPYC последний?). Еще от числа тайлов зависит. С 2 потери меньше чем с 4 например. Но и параллелизм хуже. Для архивного качества, когда нужно выжать максимум с самыми медленными настройками может и да, тайлы не лучший выбор, ну и особенно если нет больше 16 потоков, но в остальном, как я уже написал, они не так сильно влияют на качество. Ютуб к примеру для своих av1 транскодирований разбивает на тайлы аж на каждые 400-480 пикселей по стороне, потому что это существенно помогает софтварному декодированию, ну и перемотке на нужный кадр, так что тут еще зависит как этот контент будут потреблять и на чем. Не обязательно делать как Ютуб, можно лишь парочку добавить (для кодировщиков значения считаются как log2), ну и сравнить декодирование через ffmpeg/mpv бенчмарки, оно практически линейно растет, хотя для av1 есть и frame parallel threading, но оно менее эффективное, да и даже при его использовании скорость декодирования приумножается вместе с тайловым, поэтому тайлы бывают полезны не только для кодирования и вреда от них на деле не так много, если использовать с умом
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #87

80. Сообщение от Гость (??), 15-Мрт-24, 23:04	–1 +/–
> H265 с хорошим качеством в два прохода выдает примерно 40-60fps на GTX1060 GTX1060 с 6 поколением NVENC, H265 хуже H264 кодирует и по качеству и по битрейту!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #86

81. Сообщение от Аноним (81), 15-Мрт-24, 23:17	+/–
не угадал, рязань.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

82. Сообщение от Аноним (81), 15-Мрт-24, 23:19	–1 +/–
а блин, значит на давид, но тоже на расте энкодер был.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #83, #91

83. Сообщение от Аноним (81), 15-Мрт-24, 23:21	+1 +/–
https://github.com/xiph/rav1e
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

84. Сообщение от Аноним (84), 15-Мрт-24, 23:56	+/–
Он хоть и референсный, но и в какой-то мере экспериментальный (там зачастую обкатываются новые методы сжатия), и в какой-то мере боевой (используется, к примеру, в браузерах для кодирования AV1). Но он не настолько оптимизирован, как SVT-AV1. По сути, libaom изначально пилит Google, SVT-AV1 - Intel (теперь - не только), а rav1e - Xiph. Разные разработчики, немного разные цели, разные поддерживаемые фичи. К примеру, SVC поддерживается только libaom.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #116

85. Сообщение от Zulu (?), 16-Мрт-24, 00:12	+/–
У меня Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz без железного декодера, но вполне себе с пассивным охлаждением и av1 показывает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #98

86. Сообщение от cheburnator9000 (ok), 16-Мрт-24, 00:15	+1 +/–
Не надо врать Гость! Я проверял пережатие BDRemux в H264/5 на nvenc. Так вот при битрейте в условные 4мбита на h265 картинка не многим хуже оригинала, для простого архива любимых сериалов в самый раз. А вот h264 на 4мбит страдает сильно по картинке!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

87. Сообщение от Аноним (-), 16-Мрт-24, 00:45	+/–
> не идеальны, но если будут какие то заметные изменения, то они > это покажут, ну и вот на тайлах эти изменения минимальны, если > с ними не перебарщивать. Они минимальны в процентах метрики. Но если инвертировать вопрос и задаться вопросом "на сколько отличается битрейт при равном качестве картинки" (одинаковый SSIM/VMAF/визуальное качество/wahtever) - разница более заметная. Точно не 1% по битрейту. Тут на опеннете кто-то чертил в прошлой новости, просто 2 линии до пересечения с кривой, маппинг 2 точек с 1 стороны в 2 точки с другой. И с другой стороны вовсе не 1% будет. > Можно также и визуально сравнить, но разницу с использованием парочки тайлов я > думаю мало кто заметит, av1 достаточно эффективно работает с ними. А таки - не рекомендуют использовать кроме как last resort фичу когда скорость кодирования была важнее чем битрейт-качество, а контент был 1080p, а лучше 4K. На более мелком рушит битрейт-качество сильнее (негде разогнаться особо) и за это считается неважным tradeoff. > без в одинаковый битрейт (с 3 или сейчас с 2-проходами) и сравнивать, Мне вообще нравится в сабже как он q-mode делает. В 1-проходном режиме почти как 2-проходный libaom по битрейт-качество. Собссно в q-mode априорное знание того что дальше не так уж много что дает - ведь constraints на битрейт все равно нет, только на качество, можно накинуть столько битов сколько надо для вот этого уровня качества, а оптимизация сводится к достижению этого уровня качества с минимальным числом битов (подбор наиболее эффективного кодирования). > тут не будет такого разброса битрейта, пару тайлов даже и > для однопроходного crf то не особо на битрейт влияют, так что > это достаточно простой способ. Таки - влияют. При равном CRF будет меняться - размер файла. И чем эффективнее сжатие тем он меньше, соответственно. Вон то соответственно накинет явно более 1% к размеру файла. > Для архивного качества, когда нужно выжать максимум с самыми медленными настройками может > и да, тайлы не лучший выбор, ну и особенно если нет больше 16 потоков, но в остальном, > как я уже написал, они не так сильно влияют на качество. Для тяжелого кодека где мы убиваемся за битрейт-качество это таки - важный фактор, иначе зачем мы проц грели вообще?! Утяжеление на идентичном crf файла будет не 1% а уже несколько, может даже десяток. Ибо инверсный маппинг точек на кривой - довольно крут, и "небольшое" изменение транслированое в битрейт становится ощутимым. > Ютуб к примеру для своих av1 транскодирований разбивает на тайлы аж на > каждые 400-480 пикселей по стороне, потому что это существенно помогает софтварному > декодированию, ну и перемотке на нужный кадр, А это как определялось? Памятуя как меня тут жестко наели с свойствами САБЖА, что по требуемому CPU, что по RAM, думаю что вы поймете мой скепсис и желание верифицировать данные. > считаются как log2), ну и сравнить декодирование через ffmpeg/mpv бенчмарки, оно > практически линейно растет, хотя для av1 есть и frame parallel threading, Я пробовал, но мне не понравилось увеличение файлов для равного качества. И вон то не мои идеи, а выжимка doom9 и гайдов по кодированию сабжем. Для кодека этого класса не особо удачный tradeoff, в том смысле что на относительно домашнем применении можно скорость подразогнать и другими способами, возможно более удачными по соотношениям. А это last resort на случай когда дофига ядер - есть недогруз - и скорость кодирования ваше все. Тайлы размером 480 это не дофига если что. > но оно менее эффективное, да и даже при его использовании скорость > декодирования приумножается вместе с тайловым, Это опять же актуально только для большого кадра и жирного битрейта опять. Т.е. >= 1080p. А на допустим 720p оно и так справится, особенно с свежим dav1d каким (как раз в тему в новости) и проч. > поэтому тайлы бывают полезны не только для кодирования и вреда от них на деле не так много, > если использовать с умом Да, но опять же - актульно для >= 1080p и высокого битрейта имхо. Иначе не особо удачный маневр по соотношениям. На <= 720p совсем не рекомендуется - на мелком тайле негде разогнаться и урон растет. И чем больше тайлов тем хуже. Т.к. 2 тайла на 1080 или 4 на 4K еще куда ни шло. Но в целом достаточно чреватая штука. А так есть еще frame-parallel MT и проч, несколько ядер декодер и так жрать сможет. А подразумевать EPYC для декодирования все же слегка перебор :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #103

88. Сообщение от Аноним (88), 16-Мрт-24, 00:47	+1 +/–
Атомный N100 на 6W прекрасно кстати его декодирует. И обычно предполагается что на пассивном охлаждении.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #96, #101, #104

89. Сообщение от Аноним (-), 16-Мрт-24, 01:05	+2 +/–
Посмотрел цену Intel Arc A310 - 15500 рублей. Имея пенсию среднюю по РФ 14 тысяч рублей такое не купить. Жителям Москвы немного легче у них пенсия 21 тысячу рублей. По этому ещё: мы свободны хочешь работай, а хочешь не работай и умри с голоду. И зарплаты 20 тысяч рублей есть такого тоже не мало.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #109, #117

91. Сообщение от Аноним (-), 16-Мрт-24, 01:07	+2 +/–
> а блин, значит на давид, но тоже на расте энкодер был. Не в лотерею, а в карты... 1) dav1d это таки - декодер! 2) и писан он таки на сях! 3) а то что наивные чукотские юноши не могут отличить его от rav1e - ну, упс, бывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

92. Сообщение от Аноним (-), 16-Мрт-24, 01:18	+1 +/–
Intel Arc A310. Это не уровень "затычек" как ты выразился это серьезнее. https://www.techpowerup.com/gpu-specs/matrox-luma-a310.b11123 https://www.techpowerup.com/gpu-specs/gigabyte-arc-a310-wind... >дешевые затычки Intel Arc A310 Так прокомментирую. Эти слова. Intel Arc A310 это уровень "затычек" в будущем когда закончат с производством и продажей 600, 700, и 1000 серий GT которые в 3-4 раза дешевле. А через сколько это будущее настанет я незнаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #93

93. Сообщение от Аноним (-), 16-Мрт-24, 01:21	+/–
Выше надо так, если не удолят. Пока скрыто. По этому ещё раз: ... Не заметил, что слово раз забыл написать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

95. Сообщение от Аноним (-), 16-Мрт-24, 01:43	–1 +/–
Так точнее: Nvidia GeForce GT.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

96. Сообщение от Аноним (-), 16-Мрт-24, 02:30	+/–
Видео с разрешением 4К и битрейтом 20-50Мбит или 630p с битрейтом 500-800Кбит? Огласите характеристики  просматриваемого видео.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #105

97. Сообщение от Аноним (-), 16-Мрт-24, 02:30	+/–
> Лучше бы не трогали, потому что 2 ветка давала лучше результаты.   > Референсный означает лучший и наиболее полноценный. SVT, судя по прошлым успехам, > означает мыльный и дефективный Вы просто не читали doom9 и мануалы по его использованию. А если ему дать нечто типа (кусок командлайна ffmpeg'а, crf-mode): -c:v libsvtav1 -preset 2 -crf 30 -g 300 -threads 6 -pix_fmt yuv420p10le -svtav1-params tune=0:enable-qm=1:qm-min=0 - ну и где там мыло? Да, тюнинг оверрайднут на визуальный а не дефолтный, в том числе и поэтому. Вам же не SSIM офигенный надо, а картинку, так? Это достаточно качественный процессинг под относительно мощный проц, -preset 4 будет чуть похуже но заметно быстрее. Еще быстрее если убрать форс 10-бит формата, но так больше артефактов. Threads по вкусу, tune=0 лучше дефолтного имхо, qm по идее немного разгоняет эффективность сверх дефолтов, но зависит от настроек и контента. Если делать нечего еще :enable-overlays=1 можно попробовать в params добавить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #114

98. Сообщение от Аноним (-), 16-Мрт-24, 02:33	+/–
> У меня Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz без железного декодера, но > вполне себе с пассивным охлаждением и av1 показывает А чего ему не? С dav1d он довольно много в софте сжует и не подавится. Уж ютуб то запросто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #126

99. Сообщение от Bob (??), 16-Мрт-24, 03:12	+1 +/–
На винде в Daum PotPlayer засунь FHD 30FPS! - будет на intel atom N2800 30-40% жрать. Против 3-4% на h264 и CoreAVC c DXVA. Винда 10ка, кастом драйвер intel gma 3600 vp9 уже 10-15%, в пиках до 20%
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

100. Сообщение от Bob (??), 16-Мрт-24, 03:13	+/–
Имелось одно пиво. Стало 2. За те же деньги)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #141

101. Сообщение от Аноним (-), 16-Мрт-24, 03:13	+/–
360p не 630p. Полностью так 630x360.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

102. Сообщение от Аноним (-), 16-Мрт-24, 03:46	+1 +/–
Схитрили 8K c 24 кадрами. Это не тоже самое как с 60 кадрами - нагрузка на декодер другая если битрейт одинаковый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

103. Сообщение от Аноним (36), 16-Мрт-24, 04:40	+/–
>Они минимальны в процентах метрики. Но если инвертировать вопрос и задаться вопросом "на сколько отличается битрейт при равном качестве картинки" (одинаковый SSIM/VMAF/визуальное качество/wahtever) - разница более заметная. Точно не 1% по битрейту. Тут на опеннете кто-то чертил в прошлой новости, просто 2 линии до пересечения с кривой, маппинг 2 точек с 1 стороны в 2 точки с другой. И с другой стороны вовсе не 1% будет. Конечно тут сильно зависит от контента и от пресета, если не путаю на P4 тестировали (один из оптимальных пресетов, дальше там все уменьшающаяся эффективность за очень большой рост времени кодирования) и он в среднем был около 1% или даже чуть меньше для двух тайлов, это среднее для десятка разных видео сэмплов по BD-Rate, т.е. на каких то может быть чуть больше, на каких то использование тайлов может давать даже лучшие оценки метрик, но если использовать еще больше тайлов, то там да, в основном результаты ухудшаются. Суть в том что это может немного влиять на качество, но очень незначительно и если нет задачи выжать самый возможный максимум от кодировщика и когда время кодирования не имеет значения, то вполне себе можно их использовать, ну или если это просто для личного использования и скорости декодирования и так хватает. А так разница между пресетами или даже многими другими опциями будет намного больше, с тайлами нет раздутия битрейта для такого же качества на 30%, да или даже 10%, если их не накидывать до предела. >Для тяжелого кодека где мы убиваемся за битрейт-качество это таки - важный фактор, иначе зачем мы проц грели вообще?! Утяжеление на идентичном crf файла будет не 1% а уже несколько, может даже десяток. Ибо инверсный маппинг точек на кривой - довольно крут, и "небольшое" изменение транслированое в битрейт становится ощутимым. Ну с SVT-AV1 тяжесть очень расплывчата, у него выбор пресетов от -3 (в форке, т.е. -3, -2, -1, 0, 1 и т.п.) до 13 и на быстрых пресетах он подходит для стриминга и даже при достаточном количестве потоков обгоняет более старые кодеки по скорости (может за исключением уж самых быстрых пресетов), при обычно лучшем качестве. Не всегда и не всем нужно максимально возможное качество от av1, бывает что важнее лучшее соотношение скорости и качества, можно глянуть старые слайды от интела где они показывают как svt-av1 всех уделывает по скорости/качеству (кроме может vvc на медленных режимах) https://user-images.githubusercontent.com/12956286/183626151... Да и тем более для архивного и визуально lossless кодирования av1 все еще недозрел, он все еще очень уж много мелких деталей отбрасывает и не важно какой из открытых кодировщиков использовать, хотя ситуация немного улучшается и даже комьюнити помогает патчами уменьшить это смазывание и эффект пластиковости, но до x26x еще далеко, а вот для низких битрейтов с приемлемой картинкой av1 хорош. >А это как определялось? Памятуя как меня тут жестко наели с свойствами САБЖА, что по требуемому CPU, что по RAM, думаю что вы поймете мой скепсис и желание верифицировать данные. Определялось что, количество тайлов у Ютуба или скорость декодирования? С Ютуба можно просто скачать случайное av1 видео и посмотреть в аналайзерах, кстати там обычно даже для 360p и 480p используется два тайла, для 720p четыре (2x2), для 1080p - 8 (4x2), для 4к - 32 (8x4) и т.п., но иногда по какому то принципу используется только вертикальное деление, для HDR в основном замечал, ну и еще Ютуб не использует CDEF (один из тяжелых фильтров, который хорошо подчищает и блочность и артефакты на краях, но кодирование и особенно декодирование ощутимо замедляет) А по скорости декодирования, проще ffmpeg использовать с опциями `-benchmark -stream_loop -1` с выводом в NUL/null, там покажет fps или еще общее время декодирования, если без `-stream_loop -1` >Я пробовал, но мне не понравилось увеличение файлов для равного качества. И вон то не мои идеи, а выжимка doom9 и гайдов по кодированию сабжем. При кодировании и просто добавлением тайлов размеры обычно очень близкие, как минимум для свежих aomenc и svt-av1 это должно быть так, ну про метрики я уже писал. А про doom9, это не лучшее место с информацией по av1, большинство гайдов переносится из других комьюнити и различных каналов дискорда и много чего там неактуально или не совсем верно, да и подано достаточно скудно, насколько помню там только Блюсворд более подробно по параметрам отписывался, часть там нормальной информации, часть додумок или неверной или уже на данный момент устаревшей. >А так есть еще frame-parallel MT и проч, несколько ядер декодер и так жрать сможет. А подразумевать EPYC для декодирования все же слегка перебор :) В основном это очень влияет на декодирование в браузерах, особенно для стримов, например Twitch недавно начал тестировать av1 и вот там у очень многих людей даже на 1080p60 av1 без тайлов были постоянные дропы при софтверном кодировании в Chrome и на остальных браузерах на основе Chromium, особенно почему то страдают Райзены первых поколений (Zen/Zen2), даже восьмиядерные, не говоря про 1440p+, ну и мы потом делали свои тесты и тайлы тут сильно помогают (с дополнительным fast-decode совсем проблем нет, но он тоже не бесплатен для качества, да и для hw кодировщиков подобное не включить одним кликом), на Firefox дело почему то получше, видимо там максимальный приоритет и больше ресурсов отдается декодированию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #130

104. Сообщение от Аноним (104), 16-Мрт-24, 05:11	–4 +/–
> Атомный N100 Это тот мусор с производительностью 3 пня и с мобильным GMA 950? Даже не смешно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #106, #107, #125

105. Сообщение от Аноним (88), 16-Мрт-24, 09:41	+/–
4K видео из ютуба по ссылке выше. Хоть 8к можно. Энергопотребление 3-4 ватта с пиками до 6, пассив. Пруф: https://imgur.com/a/2rAF2m3
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #123

106. Сообщение от Аноним (17), 16-Мрт-24, 09:51	+2 +/–
>с производительностью 3 пня Нет. Вы много пропустили. https://nanoreview.net/ru/cpu-compare/intel-processor-n100-v...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

107. Сообщение от Аноним (88), 16-Мрт-24, 09:59	+/–
Вам смешно, а мне нет. Взял известный в узких кругах 10" ноут за 300 usd чтобы таскать с собой на случай срочной необходимости что-то поправить (работа такая что бывает даже в выходные случается). Там как раз такой проц на 6W. Это наследник N5100 (Jasper Lake), графика там та же самая но добавили декодирование AV1. Сам проц чуток быстрее. Для своих задач отличный, всего в пару раз уступает 15W Core i3-N305 из дешевых ноутов (там та же самая атомная архитектура). В свое время игрался с планшетами на Bay Trail (Atom Z37*) и Cherry Trail (Atom Z83*), те были намного медленнее, но юзабельны. Следующие поколения атомов N4100 и N5100 и далее вот этот. Интел просто отказался от бренда Атом тк потребители не взлюбили, но по сути это их линейка. E-core в больших процах это тоже вот эти самые атомы...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #112, #127

108. Сообщение от ааноним (?), 16-Мрт-24, 10:08	+/–
Под Винду есть этот кодировщик?
Ответить | Правка | Наверх | Cообщить модератору

109. Сообщение от Посмотрел (?), 16-Мрт-24, 10:42	+1 +/–
Не влезет в плату с пнем 3?! О ужас, продолжай сидеть на древностях - все для победы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #121

110. Сообщение от Аноним (110), 16-Мрт-24, 12:32	+/–
А есть проекты кодировщиков для FPGA-плат?
Ответить | Правка | Наверх | Cообщить модератору

111. Сообщение от Приблудившийся (-), 16-Мрт-24, 12:55	–1 +/–
Куча тв боксов и стиков на s905x4 и s905w2. Стоимость - 1800-10000 рублей. В среднем 2500рублей. На CPU 1080p потянет любой неновый 8ми ядерный смартфон средней ценовой категории и Смарт ТВ если у них 8 ядер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #120

112. Сообщение от Вендузятник пох. (?), 16-Мрт-24, 13:10	+/–
так, а можно пальцем ткнуть в это известное в узких кругах?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

113. Сообщение от Roman (??), 16-Мрт-24, 14:27	+/–
Я жму 4k UHD-ремуксы Handbrake'ом на маке с M1 pro в h265 аппаратным маковским кодировщиком в 4k с дефолтными настройками видео. ~30 минут полнометражный фильм обрабатывается. 10-15 гигов файл на выходе. Разницы в качестве картинки с оригиналом - 0. Может быть с BBB в 480p все иначе, но 4k h265 жмёт аппаратно очень быстро и очень качественно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #118

114. Сообщение от Аноним (36), 16-Мрт-24, 14:51	+/–
Можно еще попробовать svt-av1-psy форк, пока еще большая часть из него не влито в основную ветку, с tune 3 и sharpness 2 или больше, а для битрейтов повыше отключать фильтрацию alt-ref (enable-tf 0) и CDEF (enable-cdef 0), тогда мыла будет еще меньше, а сохраненных деталей больше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #115

115. Сообщение от Аноним (-), 16-Мрт-24, 16:58	+/–
> Можно еще попробовать svt-av1-psy форк, пока еще большая часть из него не > влито в основную ветку, с tune 3 и sharpness 2 На вон той конфиге - и этот ничего особо не портит по мылу, у имеющегося "визуального" оптимизера приоритеты иные чем у оптимизера формальной метрики. Вот тот - может замыливать, ибо метрику это не портит. А вот визуально такое - "когда как". > или больше, а для битрейтов повыше отключать фильтрацию alt-ref (enable-tf 0) Вот это иногда может прокатить и дать положительный эффект. Но зависит от. > и CDEF (enable-cdef 0), тогда мыла будет еще меньше, а сохраненных деталей больше В целом CDEF ничего не портит, и скорее улучшает. А вот битрейт-качество от этого портится изрядно и единственный реальный повод так делать - декодируемость потока на low-end железе (обсчет этого добра в декодере приличный % от сложности декодирования).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #119

116. Сообщение от Аноним (-), 16-Мрт-24, 17:00	+/–
> По сути, libaom изначально пилит Google, SVT-AV1 - Intel (теперь - не > только), а rav1e - Xiph. Разные разработчики, немного разные цели, По состоянию на вот прям сейчас - в SVT комьюнити активнее комитит, а в libaom сильно меньше. Видимо последнее связано с использованием экзотического гуглосервиса, и "односторонними" решениями во имя удобства гугли, делающими неудобно - другим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

117. Сообщение от Аноним (-), 16-Мрт-24, 17:01	+/–
> Посмотрел цену Intel Arc A310 - 15500 рублей. Имея пенсию среднюю по > РФ 14 тысяч рублей такое не купить. Ну вот и смотри ламповый телевизор. Это технологии которые ты объективно заслужил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #122

118. Сообщение от Аноним (-), 16-Мрт-24, 17:10	+/–
> Может быть с BBB в 480p все иначе, Это просто пример агрессивного пушинга кодеков к пределам современных возможностей. Втолкать это в 500 кбит среднего - для мелкого файла и скачки через интернет при практически идеальной картинке - это шикарно. > но 4k h265 жмёт аппаратно очень быстро и очень качественно. Но правда соотношение битрейт-качетсво по сравнению с софтварными кодеками - ни к черту, а так все хорошо прекрасная маркиза. Это больше для реалтаймных стримов делано, там скорость приоритетнее чем оптимизация битрейт-качество. А если транскодировать - так это делается 1 раз в жизни на мувик, и вкалывает машина. И вот куда мы тут спешим? А вот место на диске эта байда будет занимать - почти вечно, если это что-то хоть немного нужное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

119. Сообщение от Аноним (36), 16-Мрт-24, 18:08	+/–
>На вон той конфиге - и этот ничего особо не портит по мылу, у имеющегося "визуального" оптимизера приоритеты иные чем у оптимизера формальной метрики В форке эти параметры уже включены по умолчанию, ну и некоторые дополнительные, потому что они в большинстве случаев делают лучше, да и сам этот форк от этих же людей кто рекомендации по этим параметрам и описывал на doom9, reddit и прочим местам с комьюнити по кодированию. tune 3 - это микс лучшего из tune 0 c tune 2 (который тоже добавило комьюнити) sharpness - позволяет сбавить иногда излишне агрессивную фильтрацию, этот параметр сам по себе есть внутри кодировщика, но просто не везде им дают управлять, а настройки от разработчиков не всегда оптимальны, так что этим дополнительно можно подкрутить Ну а variance boost скоро должны принять и в основную ветку, но когда это еще будет, вот в форке он тоже работает по умолчанию с достаточно нейтральными настройками, которые можно в нужную сторону дополнительно подкрутить https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2195 >В целом CDEF ничего не портит, и скорее улучшает Улучшает на средне-низких битрейтах, для более высоких он не особо нужен и он вполне может портить, т.к. это все равно фильтр который вносит искажения, хоть он и более продвинутый, но далек от идеального и может где и не надо смазать детали Опять же все зависит от контента, почти все кодировщики av1 очень не любят высокочастотные данные и просто их дропают или смазывают, с x264/x265 это еще можно затюнить и вытащить, а вот с av1 достаточно тяжело, когда и невозможно, даже на очень высоких битрейтах, но вот различные форки немного улучшают ситуацию, для libaom тоже есть подобные, но там в основную ветку почти ничего не принимается, намного более закрытая от внешнего влияния разработка
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

120. Сообщение от зачеиттьбмммммммммм (?), 16-Мрт-24, 21:18	+/–
> потянет любой неновый 8ми ядерный смартфон бред, любой 4 ядреный с неоном потянет 1080p
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

121. Сообщение от Аноним (-), 17-Мрт-24, 00:17	+/–
Ты прав не как, нет возможности использовать Arc A310 с Pentium 3, нет в материнских платах для Pentium 3 разъёма PCI-E, а с Pentium 4 прокатит, если в материнской плате для Pentium 4 есть разъём PCI-E.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

122. Сообщение от Аноним (-), 17-Мрт-24, 00:22    Скрыто ботом-модератором	+/–
Работаем братья. Всё что заработаем честным путём всё наше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

123. Сообщение от Аноним (-), 17-Мрт-24, 01:06	+/–
Я знаю, что это за процессор, посмотрел его характеристики, представление имею. Вопрос был без подвоха. 8К 24 кадров, а не 60 кадров. Там вроде два видео 8К, одно 24 одно 30 кадров. Раз они стремятся и проталкивают 60 кадров то проверять надо с видео 4К и 8К с 60 кадрами если надо проверять как воспроизводится видео с 60 кадрами. Из картинки я вижу очень маленькую нагрузку на GPU, частота GPU не повышена на минимуме - мой вывод декодируется видео процессором CPU я прав? Может видео на паузе?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

125. Сообщение от Аноним (-), 17-Мрт-24, 01:34    Скрыто ботом-модератором	+/–
-> tinyurl.com/2jb53zc9 открыл, посмотрел, узнал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

126. Сообщение от Zulu (?), 17-Мрт-24, 02:38	+/–
> А чего ему не? С dav1d он довольно много в софте сжует > и не подавится. Уж ютуб то запросто. А мне почем знать. Но ОП почему-то считает что без "затычек с пассивным охлаждением", которые еще не появились, av1 не нужен. Моему процессору лет 6 будет, и ничего, av1 вполне пригождается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

127. Сообщение от Аноним (127), 17-Мрт-24, 02:57	+/–
Intel Processor N100 это что-то новое. Нет в процессорах Pentium, Celeron, Athom инструкций AVX. А в Intel Processor N100 уже есть avx1,avx2 инструкции, а это уже как в Core i3, i5.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #128, #129

128. Сообщение от Аноним (127), 17-Мрт-24, 03:01	+/–
Atom
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

129. Сообщение от Аноним (-), 17-Мрт-24, 03:21	+/–
И 6ватт с такими характеристиками это шикарно. Круче было бы только 1 Ватт - шутка. Плохо, что это мобильный процессор, что вне ноутбуков продажа не подразумевается. Может будет или есть в мини ПК не искал, не смотрел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

130. Сообщение от Аноним (-), 17-Мрт-24, 03:38	+/–
> эффективность за очень большой рост времени кодирования) и он в среднем > был около 1% или даже чуть меньше для двух тайлов, Оно от много чего зависит. А мой пойнт в том что этот же вопрос при его трансляции в термины битрейта/размера файлов выглядит интереснее и в терминах битрейта теряется таки - больше. Вполне валидно юзать этот тул. Но имхо >=1080p, и с минимумом тайлов диктуемым практическими соображениями. Во всяком случае "для себя" если с прицелом все же в хорошее качество при минимальном размере. > давать даже лучшие оценки метрик, но если использовать еще больше тайлов, > то там да, в основном результаты ухудшаются. Он почти всегда от тайлов ухучшается, и в терминах битрейта - неприятно. Поэтому их и не рекомендуют без острой необходимости (т.е. >=1080p какой, ну может 720 если очень охота). И даже если в метриках это "всего" 1% то в битрейте заметно хуже, в сильных кодеках и не за такое то рубилово идет, и легко дарить эн процентов битрейта при энном качестве... ну такое себе, хотя на hi-res это актуально еще и для скорости декодирования. > Суть в том что это может немного влиять на качество, но очень незначительно Я не согласен с "очень незначительно" - в терминах битрейта при равном качестве ощутимо может быть. За что и не рекомендуют при кодировании "для себя". > и если нет задачи выжать самый возможный максимум от кодировщика > и когда время кодирования не имеет значения, то вполне себе можно их использовать, Сабж 8-16 ядер и так спокойно жрет - так что актуально в основном владельцам EPYC'ов и подобного. Мне именно VoD-овские кейсы не интересны, я как максимум могу эн своих мувиков для других выложить но это не VoD и т.п. все же. > ну или если это просто для личного использования и скорости декодирования и так хватает. Я больше про кодирование "для себя" как раз. SVT в этом плане довольно дружелюбная штука ибо позволяет закодировать плотно - и довольно быстро в общем то. Из реальных конкурентов libaom но он в целом медленнее. > А так разница между пресетами или даже многими другими опциями будет намного больше, Тоже не мировая константа. Скажем 2 и 3 не так уж сильно отличаются, как и 3 и 4. Когда качество при минимальном размере мое все это 2, а если тороплюсь то 4. Ну а 3 некий компромисс. > с тайлами нет раздутия битрейта для такого же качества на 30%, да или даже 10%, > если их не накидывать до предела. Ну 30% и даже 10% это все же уже слегка экстрим, только совсем уж дурацкое что-то сделать, но несколько процентов потерять может вполне, и это сравнимо в вон тем переключением пресетов иди даже превосходит это. Хотя на высоком разрешении и эффект меньше и смысла больше. > он подходит для стриминга и даже при достаточном количестве потоков обгоняет более > старые кодеки по скорости (может за исключением уж самых быстрых пресетов), Ну вот он этим и забавен. Хотя если стримить в реалтайме - то и чудес по битрейт-качество не будет. Я для себя решил что мне для многих кейсов скорость 2..4 с хорошими настройками уже вполне нормуль, сжатие получается плотное, время кодирования для всяких клипов с камер и проч вполне обозримое, а что-то реально длинное - я могу и "на ночь" пнуть, это ж не я пашу а комп. > от интела где они показывают как svt-av1 всех уделывает по скорости/качеству С тех пор он в общем то стал еще лучше. И таки редкий случай когда это не гнилой пиар - а вполне честные данные. Реально шустрая для своей плотности сжатия штука. И это был повод заагриться на некорректную новость рассказывающую небылицы про AVX2, 48 гиг оперативы и проч. > Да и тем более для архивного и визуально lossless кодирования av1 все > еще недозрел, он все еще очень уж много мелких деталей отбрасывает У меня несколько нежатых "raw" последовательностей есть - я иногда балуюсь тестами открытых кодеков для себя. И могу сказать что с вон тем зацитированым куском командлайна напрягаюсь уже отличить сжатое от оригинала. И не, никакие мелкие детали он не грохает. Даже чат с фонтом с субпиксельным сглаживанием - норм вроде, от оригинала так сразу не отличишь. > пластиковости, но до x26x еще далеко, а вот для низких битрейтов > с приемлемой картинкой av1 хорош. Я бы сказал что картинка оооочень близка к идеалу. Более того - на примерно 500 кбит в среднем для вон того BBB оно смогло почти идеально титры в конце оформить. Они там сложные для кодирования, и требуют либо зверский битрейт либо артефактов много. Но нет, вот этот - отлично их сделал. А x265 при попытке втиснуть клип в 500 кбит среднего (даже как CRF и проч) там закатит полную жесть. Ему битрейт надо здорово задирать для того же качества картинки, особенно на титрах в конце - они очень неудобные для кодирования, думаю что AV1 там глобальной компенсацией движения отигрывает, или типа того. У H.265 этого на уровне потока - нет. > Определялось что, количество тайлов у Ютуба или скорость декодирования? Тайлы. > С Ютуба можно просто скачать случайное av1 видео и посмотреть в аналайзерах, Все же было бы неплохо конкретику. > кстати там обычно даже для 360p и 480p используется два тайла, Интересно нафига? Чтоб смартфоны всякие в софте на относительно хилом но многоядерном проце жевали? > но иногда по какому то принципу используется только вертикальное деление, С гугли станется и ML воткнуть на выбор параметров для кодирования энного мувика. > подчищает и блочность и артефакты на краях, но кодирование и особенно > декодирование ощутимо замедляет) Он да, тяжелая штука. Но визуально картинку здорово окультуривает, особенно на низком битрейте. > -1` с выводом в NUL/null, там покажет fps или еще общее > время декодирования, если без `-stream_loop -1` Я просто пинаю кодирование реалистичного потока - с лимитом числа фреймов. Дает понимание ballpark и соотношений. > При кодировании и просто добавлением тайлов размеры обычно очень близкие, как минимум > для свежих aomenc и svt-av1 это должно быть так, ну про метрики я уже писал. Ну я попробовал - размер таки при равном crf рос. Хотя на >=1080 оно имеет смысл, и по соображениям скорости декодирования тоже. Как я понимаю урон тем хуже чем меньше размер тайла. С большими тайлами - урон небольшой. Так что настаивать что фичу совсем ни-ни, даже на 1080 и выше - ну не. Можно, а порой и нужно. > А про doom9, это не лучшее место с информацией по av1, Да. Но даже там есть некоторое количество дельных мыслей. > большинство гайдов переносится из других комьюнити и различных каналов дискорда Я не пользуюсь дискордом и мне похрен на него. Но на кодирование сабжем в CRF дельный материалец попадался, я на нем и забазировался. > многих людей даже на 1080p60 av1 без тайлов были постоянные дропы > при софтверном кодировании в Chrome Вот это - запросто, при стриме битрейт относительно высокий (реалтайм кодирование же, соотношение битрейт-качетсво плохое!), а 60FPS еще больше подгружают это дело. Оно и зашьется. Для вот чего-то такого и жирнее - тайлы получают свой пойнт. > не говоря про 1440p+, ну и мы потом делали свои тесты > и тайлы тут сильно помогают (с дополнительным fast-decode совсем проблем нет, > но он тоже не бесплатен для качества, Ну вот да, для hi-res контента тайлы - штука вполне полезная. И там это оправдано и даже нужно. Видимо идею стоит сформулировать так: если тайл мелкий, это ведет к неудачным соотношениям. С крупными и без фанатизма - соотношения заметно лучше. > да и для hw кодировщиков подобное не включить одним кликом), на Firefox дело почему то > получше, видимо там максимальный приоритет и больше ресурсов отдается декодированию. Может там декодер другой юзается? Ну скажем ffmpeg'овский dav1d? А в хроме гугл какую-то свою либу двигал. Может поленились оптимизить на асме столько же как вон те?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #131

131. Сообщение от Аноним (36), 17-Мрт-24, 06:08	+/–
>Я не согласен с "очень незначительно" - в терминах битрейта при равном качестве ощутимо может быть. За что и не рекомендуют при кодировании "для себя". Для себя можно и не использовать (если более быстрый seeking не нужен, потому что тайлы и его ускоряют), но это именно очень незначительно, что опять же не очень сложно и проверить любому кто минимально знаком как считать метрики и кодировать, для примера взял один из сэмплов, 1080p пресет 4: Размер ---    VMAF --  MS-SSIM - Тайлы (columns|rows log2) 33984647  89.963493  0.996456   1 0 (всего 2) 33983309  89.960426  0.996454   0 0 (нет тайлов) 33972823  89.919441  0.996441   1 2 (2x4, всего 8) Как можно заметить размеры файлов практически одинаковые (и соответственно битрейт), разброс минимальный, оценки метрик тоже очень близкие и опять 2 тайла дало чуть лучший результат, но это скорее погрешность, потому что и размер чуть больше, по покадровым графикам метрики можно сказать сливаются, никаких просадок на каких то определенных кадрах не замечено, визуально невозможно определить где использовались тайлы, а где нет, даже если попиксельно рассматривать каждый кадр (какая то разница есть, но сказать где хуже или лучше невозможно), притом это и для 8 тайлов не заметить, где чуть большая просадка, не то что для 2. Для более медленных пресетов может и будет чуть больше разница и когда нужно выжать максимум и тайлы не важны совсем, то их можно не использовать, но их влияние на качество минимальное, большинство других параметров кодирования и то дадут большую разницу, тайлы для определенных форматов могут быть вредными или очень заметными, например для HEVC с хардварным кодированием на смартфонах можно даже временами эти линии и разрывы с тайлами увидеть, но у AV1 их реализация намного лучше и я подобного не замечал. >С тех пор он в общем то стал еще лучше. И таки редкий случай когда это не гнилой пиар - а вполне честные данные. Реально шустрая для своей плотности сжатия штука. Все же есть некоторая маркетинговость графиков, там во первых среднее из всех метрик, что очень не рекомендуется делать для нормальных результатов, используется 96 ядерный процессор, ну а большинство других кодеров столько не могут загрузить, x264 к примеру после 12 потоков практически не параллелится, ну и понятно откуда тут взялась такая разница в скорости. Да и по соотношению качества пресетов несоответствия, особенно быстрых, svt-av1 с первых версий имел баг с блочностью на сложных кадрах или когда какие то резкие движения и он особенно часто проявляется на p7 и быстрее, просто на случайных кадрах есть выпавшие очень заметные блоки, притом даже x264 на этих же кадрах такого не позволяет, хотя может общее среднее качество и будет чуть похуже. Ну и вот на этот баг уже десятки репортов висит и так ничего не исправляется, а уже годы прошли и притом это может случайно вылезти даже на самых медленных пресетах и там подобное не сразу и не заметить, если прямо по кадрам не сравнивать, но штука неприятная если это видео например для распространения будет или как архивное. >Я не пользуюсь дискордом и мне похрен на него. Но на кодирование сабжем в CRF дельный материалец попадался, я на нем и забазировался. Дискорд неудобен что он закрыт от поиска извне и если в определенных конфах не сидеть, то информация оттуда никуда и не выходит, ну а там сейчас большинство обсуждений, доработок и ресерчей происходит и многие разработчики кодеков также сидят. Doom9 же почти вымирающий, а по av1 туда минимум какой то информации попадает, вот Блюсворд тут временами просыпается из годовой спячки и бывает что-то публикует, но все это часто через короткий промежуток становится уже не совсем актуальным, да и из того что публикуется не все там правильно или было проверено. >У меня несколько нежатых "raw" последовательностей есть - я иногда балуюсь тестами открытых кодеков для себя. И могу сказать что с вон тем зацитированым куском командлайна напрягаюсь уже отличить сжатое от оригинала. И не, никакие мелкие детали он не грохает. Даже чат с фонтом с субпиксельным сглаживанием - норм вроде, от оригинала так сразу не отличишь. Тут зависит от битрейта, для средне-низких или для чистого/плоского контента, как я уже написал, то av1 неплох, но вот если есть очень качественный исходник с кучей мелких деталей и нужно добиться архивного качества, то пока что любой av1 кодировщик тут не готов, даже на самых медленных пресетах, я и на -3 кодировал и с 0 для aom, при обычном просмотре это может и не заметить, но при покадровом это очень явно, ну а чтобы какой то film grain сохранить оригинальный или шум, речи совсем не идет, тут разве что синтезированный может помочь, но у него куча своих недостатков и что паттерны бывают достаточно заметны и что его трудно подобрать под исходник, да и вместе с зерном там и прочие детали отфильтровываются, а вот x26x подобное вполне могут, если знать что крутить и если это не низкобитрейтное кодирование. >Интересно нафига? Чтоб смартфоны всякие в софте на относительно хилом но многоядерном проце жевали? У Ютуба очень облегченный для декодирования профиль av1, все что тяжелое практически не используется, ну и да, чтобы максимально широко было доступно декодирование на любой микроволновке, а кодируется там хардварно, асиками, так что скорее и дальше надолго подобные настройки останутся, до каких то следующих поколений и обновлений этих кодировщиков. А по скачиванию, ну любым даунлоадером или yt-dlp, тут все обычно. >Может там декодер другой юзается? Ну скажем ffmpeg'овский dav1d? А в хроме гугл какую-то свою либу двигал В Chrome и остальных браузерах практически сразу dav1d и был, это в андройде свой использовался gav1, но сейчас в новых версиях тоже на dav1d меняют, скорее всего какой то режим экономии энергии или что-то подобное, а для десктопов чтобы декодер не весь процессор отжирал его как то ограничивают
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #134

132. Сообщение от robot228 (?), 17-Мрт-24, 07:25	+/–
Приму ваши пресеты под FullHD для ютуба с этим кодеком.
Ответить | Правка | Наверх | Cообщить модератору

133. Сообщение от Аноним (133), 17-Мрт-24, 13:57	+/–
А я не могу включить аппаратное ускорение видео на Debian12/wayland и даже xwayland. Gstreamer не видит nvcodec, хоть он и есть. И в браузере about:gpu выдаёт далеко не все возможности.
Ответить | Правка | Наверх | Cообщить модератору

134. Сообщение от Аноним (-), 17-Мрт-24, 22:04	+/–
> Для себя можно и не использовать (если более быстрый seeking не нужен, > потому что тайлы и его ускоряют), но это именно очень незначительно, Я для контролируемого времени seeking нечто типа -g 300 подгоняю или около того (в терминах ffmpeg. Время seek контролируемое получается. Тоже конечно немного битрейта теряет. > 33984647  89.963493  0.996456   1 0 (всего 2) > 33983309  89.960426  0.996454   0 0 (нет тайлов) > 33972823  89.919441  0.996441   1 2 (2x4, всего 8) Прикольный подход к делу. И как я вижу 2 тайла вообще ничего не портят, 8 просело но реально мизер. Еще вроде кто-то упоминал потенциал для артефактов на границе стыковки тайлов. > использовались тайлы, а где нет, даже если попиксельно рассматривать каждый кадр > (какая то разница есть, но сказать где хуже или лучше невозможно), Где-то народ писал что стыковка тайлов в каких-то случаях может быть не идеальная и это как бы known issue. И да, на >=1080p тайлы в умеренном количестве ничем не плохи. На более мелком - ну вот хз, если то что вы пишете верно то гугл или жестит в пользу "времени появления видео в AV1" сделав это приоритетным, или все же смог в какой-то момент подрихтовать алго уменьшив потери до приемлимых. Что libaom что сабж - moving target, живые и эволюционирующие проекты, знания могут и устареть - так что спасибо за измерения. > притом это и для 8 тайлов не заметить, где чуть большая просадка, не то что для 2. Ну я в конечном итоге предпочитаю доверять больше всего - глазам. Придирчиво рассмотрев что накодилось. В этом смысле CRF=30..32 в сабже почти гарантированно идеальный, даже на стопкадре артефактов не видно. Для большинства видео можно CRF до 36-40 затянуть без особых последствий. Если что у сабжа идеи на тему CRF отличаются от x26x и некоторых других, это про именно сабж. > не использовать, но их влияние на качество минимальное, большинство других параметров > кодирования и то дадут большую разницу, Раньше довольно заметную разницу давали на <=720p, откуда и та идея. На >=1080p они скорее полезны из-за распараллеливания процесса - при мизерном уроне. > на смартфонах можно даже временами эти линии и разрывы с тайлами > увидеть, но у AV1 их реализация намного лучше и я подобного не замечал. Ну вот народ утверждает что в принципе стыковка тайлов _может_ быть не идеальной и заметной и с AV1. Хотя лично я этот эффект в заметном объеме на сабже не видел, даже зная что искать. Тут такое дело что не весь контент одинаковый, и на каком-то те или иные артефакты (не)заметнее. Скажем "ringing" и нестыковка границ с которой CDEF борется не палится на фильмообразном контенте, но на "скринкасте" - это все все гораздо критичнее. > Все же есть некоторая маркетинговость графиков, там во первых среднее из всех > метрик, что очень не рекомендуется делать для нормальных результатов, используется 96 > ядерный процессор, ну а большинство других кодеров столько не могут загрузить, Тем не менее, САБЖ оказался довольно резвый и в более скромных конфигах, при том делая весьма приятную картинку. Про AVX2 и 48 гигов было нагнано с три короба! Мне сабж весьма понравился по сочетанию свойств. > x264 к примеру после 12 потоков практически не параллелится, Да оно ему с его сложностью процессинга не очень то и надо, имхо. Тем более с риском потери битрейт-качество, которое у него и так ни о чем по современным меркам. Он же даже VP9 не побьет, на вашей же кривой видно что VP9 и x265 примерно равны по силе в challenging условиях. > Да и по соотношению качества пресетов несоответствия, особенно быстрых, svt-av1 с первых > версий имел баг с блочностью на сложных кадрах или когда какие > то резкие движения и он особенно часто проявляется на p7 и быстрее, Ну я с настолько быстрыми не экспериментировал, мне фоновый транскод для себя более интересен, а это 2..4 в общем случае. > штука неприятная если это видео например для распространения будет или как архивное. Кто ж архивное то видео на 7 пресете жмет? Там самый край - 4й. Более высокие используют довольно жесткие tradeoff вносящие приличный урон в битрейт-качество. > а там сейчас большинство обсуждений, доработок и ресерчей происходит и многие > разработчики кодеков также сидят. Они и много где еще сидят, особенно нормальные, опенсорсные, а не нубы-хайпонашки с аниме и чем там еще (мне такой кейс не интересен). > Doom9 же почти вымирающий, а по av1 туда минимум какой то информации попадает, Просто он больше о транскоде DVD и народец там довольно проприетарный. Но ряд дельных идей по сабжу там все же есть, в относительно концентрированом виде и сравнительно валидное. А разработчики с дискордом могут идти куда подальше имхо. Псевдоопенсорс с закрытым знанием и лизом проприетарных ботинок - нахрен не упал. > не совсем актуальным, да и из того что публикуется не все > там правильно или было проверено. Ну как бы сабж довольно таки moving target - но ряд идей все же достаточно базовые и остаются. > Тут зависит от битрейта, для средне-низких или для чистого/плоского контента, как я > уже написал, то av1 неплох, но вот если есть очень качественный исходник с кучей > мелких деталей и нужно добиться архивного качества, У меня есть и несколько скринкастов, с мелким текстом и проч. Который кроме всего прочего жутко чувствителен к subsampling например. Там мелкие детали так критичны что одно время libvpx делал libaom с ffmpeg! Ибо тот еще не умел в ffmpeg RGB/HBD/444 и проч а как yuv420 мклкие детали типа текста портятся by design и это видно. В актуальных версиях починено. Не могу сказать ничего плохого о сабже с разумными пресетами (2..4) на таком контенте, с CRF в районе 30-36 или типа того. Опять же отличить от оригинала довольно сложно. > покадровом это очень явно, Не замечал такой эффект на моем контенте. Но как бы контента много и разного и на глобальных выводах настаивать не буду. > ну а чтобы какой то film grain сохранить оригинальный или шум, речи совсем не идет, Я честно говоря не понимаю зачем все это извращение надо - я совершенно не ностальгирую по техническим дефектам. Но таки CRF в районе <=30 и это вроде более-менее делает, просто битрейта будет больше. У AV1 есть синтез film grain но я с этим не развлекался. Мне технические дефекты на видео не вперлись. > вот x26x подобное вполне могут, если знать что крутить и если > это не низкобитрейтное кодирование. Хызы, я немного крутил x265 и он мне совсем не понравился. Не понимаю что такого крутого в этой штуке варезники находят. И зачем мне все это знание на патентованый формат который даже в вебе потом хрен выложишь. Вот x264 по своим временам крутая штука был. Но реально в более-менее challenging ситуациях он не побьет даже VP9 непатентованый. > У Ютуба очень облегченный для декодирования профиль av1, все что тяжелое практически > не используется, ну и да, чтобы максимально широко было доступно декодирование За это их видимо и лю. Пока у всех икает и лагает, у них как раз очень разумный набор компромиссов под real world с всеми его заскоками. > на любой микроволновке, а кодируется там хардварно, асиками, так что скорее > и дальше надолго подобные настройки останутся, А откуда эти сведения про асики? Судя по тому сколько времени занимает транскод - они это в софте делали и бэклог немеряный. А асику душно будет столько памяти выделять на всякие реф-фреймы и проч, под реалтайм кодеры очень урезаные. У гугли в libaom есть rtc варинат и как я понимаю они его сразу в ASIC и отливают high-level synthesys'ом прямо из того сорца. Но это реалтаймный пресет, он многим жертвует ради скорости. > А по скачиванию, ну любым даунлоадером или yt-dlp, тут все обычно. Мне скорее интересно было кто разблюдовку на тайлы кажет и при том не очень монструозный по зависимостям и сложности сборки. > В Chrome и остальных браузерах практически сразу dav1d и был, это в > андройде свой использовался gav1, но сейчас в новых версиях тоже на dav1d меняют, Во всяком случае у гугли есть своя либа декодирования av1, и вроде ее не списали в утиль? Или таки - списывают в пользу dav1d? > подобное, а для десктопов чтобы декодер не весь процессор отжирал его > как то ограничивают Ну как бы чудес не бывает и что с атомом малохольным в нетбуке не делай а 4K в AV1 он все же не сжует. Особенно 32 бит которые.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #135

135. Сообщение от Аноним (36), 17-Мрт-24, 23:59	+/–
>Где-то народ писал что стыковка тайлов в каких-то случаях может быть не идеальная и это как бы known issue Теоретически возможно, но я не замечал, хотя кодировал и экспериментировал с av1 очень много (еще до финализации стандарта) и на всех доступных реализациях. На хардварных кодировщиках или в других форматах такое уже встречалось, например на видеокартах с av1/hevc кодировщиками, когда очень тяжелая игра с rtx и gpu загружен по полной, то может быть смещения в местах тайлов, видимо синхронизация сбивается и какой то тайл позже обрабатывается и подобное происходит. >Кто ж архивное то видео на 7 пресете жмет? Там самый край - 4й. Более высокие используют довольно жесткие tradeoff вносящие приличный урон в битрейт-качество. А это и на медленных пресетах может проявляться, про что я и написал, просто намного реже, но от этого это еще труднее отследить, метрики подобное практически не замечают, а глазами каждый кадр просматривать времени не хватит, на это есть репорты на гитлабе, но они так и висят годами. >У AV1 есть синтез film grain но я с этим не развлекался. Мне технические дефекты на видео не вперлись. Ну это уже давно не технические дефекты, это скажем так видение создателя, когда и камера подбирается и стиль fg в них настраиваемый или даже специально на посте потом добавляется, хороший кодек не должен сам что-то фильтровать, он должен максимально сохранять оригинал, если нужна фильтрация, то для этого есть другие инструменты. Да и убрать fg идеально невозможно, всегда удаляются также и некоторые другие данные, есть алгоритмы и фильтры которые это лучше делают, но они очень медленные, есть которые хуже, но быстрее (вот в кодировщиках фильтрация обычно работает если включен fgs, но и то, со временем поняли что это не очень хорошо и в недавних апдейтах это в svt-av1 отключили) >У меня есть и несколько скринкастов, с мелким текстом и проч. Который кроме всего прочего жутко чувствителен к subsampling например. Там мелкие детали так критичны что одно время libvpx делал libaom с ffmpeg! Ибо тот еще не умел в ffmpeg RGB/HBD/444 и проч а как yuv420 мклкие детали типа текста портятся by design и это видно. В актуальных версиях починено. Кстати, в svt-av1 все еще максимальны 10-бит и 420, поэтому если нужно что-то выше, то его не используют, хотя в планах добавление 422/444 у них висело еще с первых версий, но как то со временем про это совсем забыли. >Просто он больше о транскоде DVD и народец там довольно проприетарный. Но ряд дельных идей по сабжу там все же есть, в относительно концентрированом виде и сравнительно валидное. Да, но в основном для других форматов и по большей части старых, ну и про vvc и прочие mpeg стандарты некоторые новости индустрии, хотя и многие старички из разработчиков оттуда тоже поуходили, по av1 там очень мало, вот опять же выдернутые куски с дискорда/реддита и прочих ресурсов,  может попинают людей и они напишут скоро про psy форк подробнее и в целом какие изменения у av1 кодировщиков за это время произошли. Например вот недавнее сравнение с этим форком в одном из issues: https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1920#note_1... Со скриншотом насколько большая может быть разница, притом видео закодированное svt-av1-psy даже немного меньше размером https://gitlab.com/AOMediaCodec/SVT-AV1/uploads/c0fae4cdd466... Хотя это и не означает что для любого контента будут такие же улучшения, но, как минимум форк дает более гибкие настройки для того чтоб что-то подправить. >Хызы, я немного крутил x265 и он мне совсем не понравился. Не понимаю что такого крутого в этой штуке варезники находят. И зачем мне все это знание на патентованый формат который даже в вебе потом хрен выложишь. Вот x264 по своим временам крутая штука был. Но реально в более-менее challenging ситуациях он не побьет даже VP9 непатентованый. А потому что x26x все еще хороши для более высокого битрейта, да и декодирование поддерживается очень широко на любых устройствах, даже для hevc по сути каждый tv или телефон, года так с 2015, с av1 же пока только последние поколения начали добавлять, ну а для vp9 хороших не коммерческих кодировщиков так и не появилось. А про патентные отчисления, то они сейчас в основном с девайсов собираются и каких то услуг по облачному кодированию или продаж на физических носителях, даже у hevc с определенного момента убрали отчисления за стриминг и прочее нефизическое распространение, так что для обычных пользователей разницы нет, ну кроме того что они и так заплатили стоимость этих патентов как часть цены устройства, допустим своего смартфона, видеокарты или тв. У av1 все хорошо на низких или средних битрейтах, в принципе для чего он в первую очередь и создавался, для стриминг качества, но вот для высоких, после какого то порога у него наступает предел и дальше сколько битрейта не накидывай и какие фильтры не отключай, он все равно не может сохранить прямо все детали, а с x26x это возможно, если понимать что и где тюнить. >А откуда эти сведения про асики? Судя по тому сколько времени занимает транскод - они это в софте делали и бэклог немеряный. А асику душно будет столько памяти выделять на всякие реф-фреймы и проч, под реалтайм кодеры очень урезаные. А невозможно было бы на cpu столько видео обрабатывать, точнее возможно, но экономически это были бы просто огромнейшие затраты, на Ютуб заливаются миллиарды видео каждый день по статистике и это количество растет с каждым годом, притом среди них есть и очень длинные видео и стримы по 30 часов и т.п. и все это нужно кодировать в разные форматы, качества и разрешения, понятно что av1 не для всех кодируется, но процент av1 уже достаточно большой и постоянно увеличивается, даже ролики с парой тысяч просмотров последнее время замечаю что бывает. Асики намного экономичней и Ютуб их еще со времен VP9 начал использовать, у них собственная разработка Argos и они его поколения обновляют периодически и если взять для примера из каких-то подобных современных решений, то там потребление 1w на одно кодирование и до 256 параллельных кодирований на сервер, с очень большой скоростью, хоть и качество не будет как при софтварном  кодировании на самых медленных пресетах, но все равно достаточно высокое и для Ютуб-подобных кейсов вполне подходит https://blog.youtube/inside-youtube/new-era-video-infrastruc.../ Еще и учитывая что у Ютуба все видео выше 1080p идет только в vp9, а в 8к разрешении только в av1, для любых пользователей, ну и все нижние разрешение и прочие кодеки тоже нужно дополнительно для этого видео кодировать. >Мне скорее интересно было кто разблюдовку на тайлы кажет и при том не очень монструозный по зависимостям и сложности сборки. Можно погуглить что-то типа av1 analyzer, помню точно видел был даже онлайновый вариант, ну а я коммерческие тулзы использую для этого, которых скорее всего нет в свободном доступе, ну или максимум какие то древние ломанные версии, скорее всего без av1 >Во всяком случае у гугли есть своя либа декодирования av1, и вроде ее не списали в утиль? Или таки - списывают в пользу dav1d? Вот в новых версиях заменяют, потому что dav1d намного быстрее, они хотели из нее сделать более экономичный декодер, который бы использовал gpu шейдеры, это не быстрее, но потребление меньше, но как то у них не особо чего вышло и видимо совсем бросили попытки, потому что приходит время полноценных hw декодеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

136. Сообщение от Аноним (136), 18-Мрт-24, 11:54	–1 +/–
Это свободный кодек? Целиком и полностью придуман сообществом (включая и алгоритмы сжатия) а не подарен корпорациями как с theora и всякими vp8 и vp9 было?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #142

138. Сообщение от Аноним (4), 18-Мрт-24, 13:03	+/–
Я сразу вижу ряд проблем с этим: - x265 _очень_ плохо работает с sd-контентом - лосслесс данные это не то, с чем кодек будет работать и на лосси libaom сыпется очень-очень сильно - 480 вообще максимально субоптимальная высота с которой кодеки не умеют работать [SAR 5760:4739 DAR 8448:4739] - 500кбпс заведомо недостаточно -- в зависимости от контента, x265 может 432 и в 300кбпс запихать так, что будет абсолютно ок, но полное отсутствие дефектов на любом контенте часто предпочтительнее и это порядка 650кбпс среднего, к слову, для avc аналогичное визуальное качество достигается где-то на 4000кбпс. - предложенный материал сам по себе содержит артефакты, на которые уходит весь битрейт, а анимация весьма низкокачественная как и положено опенсорсу -- содержимое выглядит дефективно и это опять же не то что кодеки кодируют в норме, что вообще подобным мусором можно проверить я не представляю Я закодировал 480p bbb дефолтным crf=27 которого достаточно в большинстве ситуаций, получилось  в районе 350kbps. Небольшие дефекты краёв в движении, надо присматриваться при увеличении на весь экран, чтобы увидеть. Для такого битрейта неплохо. Вообще без проблем. Когда мне надо нормальное качество, я ставлю crf=21 и это что-то вроде аналога crf=17 у x264, получилось ~800kbps, лучше картинку получить сложно. После этого я переключил пресет с medium на veryslow и crf обратно на 27, качество ощутимо выросло, у меня практически нет претензий ни к чему и дефекты минимальные (битрейт 372kbps), veryslow с включенной психовизуальщиной + tune=animation выглядит визуально лучше и на весь экран 393kbps. Нужно учитывать, что crf у x265 обеспечивает качество на битрейт значительно ниже, чем 2-проходный режим на битрейт, но результат более предсказуемый (а битрейт нет). При этом, x265 вообще не показатель, и референсный кодер по ряду лицензионных причин выдаёт картинку куда чище и детализированнее с меньшим мылом и артефактами. А вот libaom/libvpx это референсный и "самый лучший", поэтому подобное сравнение изначально глупость несусветная. Сравнил сейчас libaom crf=35 с libx265 crf=27 как сопоставимые по битрейту и качеству, выглядит примерно одинаково паршиво, libaom намного дороже. Только у libaom адовое мыло, важные детали вроде лиц размыты куда сильнее. Меньше артефактов краёв в движении, они лезут когда недостаточно битрейта. Качество сопоставимо с отключённой психовизуальщиной, но x265 в несколько раз производительнее в итоге. Со стандартной психовзуальщиной + tune=animation качество выше у x265 при той же вычислительной сложности. В любом случае, BBB в качестве тестовых данных никуда не годится. Ах да, я использую шейдер FSRCNNX_x2, поэтому все дефекты sd-контента вижу очень отчётливо. Возможно, есть другой шейдер, который будет сглаживать конкретно эти артефакты, этот делает все артефакты более явными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #140

140. Сообщение от Аноним (-), 18-Мрт-24, 17:21	+/–
> Я сразу вижу ряд проблем с этим: > - x265 _очень_ плохо работает с sd-контентом О! Пули оказывается не из серебра?! А сабжу - нормуль, прекрасно жмет себе. > - лосслесс данные это не то, с чем кодек будет работать и > на лосси libaom сыпется очень-очень сильно Мы вообще про SVT в этом треде. И между прочим в паре с ffmpeg при транскодировании уже жатого можно и префильтры постпроцессинга ffmpeg'у вкатить. > - 480 вообще максимально субоптимальная высота с которой кодеки не умеют работать > [SAR 5760:4739 DAR 8448:4739] Сабжу похрен, жмет нормально! У нормального кодека 480 проблем не вызывает. А если вызывает - окей, это голимый кодек. > - 500кбпс заведомо недостаточно -- в зависимости от контента, x265 может 432 > и в 300кбпс запихать так, что будет абсолютно ок, но полное > отсутствие дефектов на любом контенте часто предпочтительнее и это порядка 650кбпс А я как бы в курсе что x265 нишмагет. А вот САБЖ сделал мне изумительный 532кбит CRF вариант вон того, даже с 10 бит процессингом - где я напрягаюсь найти отличия от оригинала. Все что надо знать о силе кодеков на этом рабочем участке. > - предложенный материал сам по себе содержит артефакты, на которые уходит весь > битрейт, а анимация весьма низкокачественная как и положено опенсорсу -- содержимое > выглядит дефективно и это опять же не то что кодеки кодируют в норме, что вообще > подобным мусором можно проверить я не представляю Как раз таки местами весьма challenging, плавные градиенты, в титрах еще и в смеси с текстом. Все г-но и левые допущения кодека вылезут наружу как облупленые. И да, это очень кстати ибо потом кодируя "супер" кодеком какой-нить скринкаст можно будет жестко обломиться. Это что, то размер окошка не тот, то разрешение не вышло, то контент не такой и супер-кодек еще и диктовать мне будет что жать? Хороший кодек должен быть универсальным, имхо. > Я закодировал 480p bbb дефолтным crf=27 которого достаточно в большинстве ситуаций, > получилось в районе 350kbps. Небольшие дефекты краёв в движении, надо присматриваться В вон том 532 кбит - дефекты даже на стопкадре еще изгальнуться увидеть надо. При том для той последовательности я знаю сложные сцены. Скажем начальный fade in. Или титры. Или когда с птица перья сыпятся. Или падающий абрикос. > при увеличении на весь экран, чтобы увидеть. Для такого битрейта неплохо. > Вообще без проблем. Когда мне надо нормальное качество, я ставлю crf=21 > и это что-то вроде аналога crf=17 у x264, получилось ~800kbps, лучше > картинку получить сложно. Ну а у вон того на 531 кбит практически идеальная картинка, которую я от оригинала отличу не сразу, если вообще, и это зная что искать. > к чему и дефекты минимальные (битрейт 372kbps), veryslow с включенной психовизуальщиной > + tune=animation выглядит визуально лучше и на весь экран 393kbps. А вон там - дефекты не заметно практически. В оригинальном размере совсем, да даже на весь 30" экран - только общий upscale заметно, но вот имено дефекты кодека? Их по сути нет. > Нужно учитывать, что crf у x265 обеспечивает качество на битрейт значительно ниже, > чем 2-проходный режим на битрейт, но результат более предсказуемый (а битрейт нет). А сабж еще забавен тем что его CRF в однопроходном режиме довольно крут и сравним с libaom в 2-проходном. > При этом, x265 вообще не показатель, и референсный кодер по ряду лицензионных > причин выдаёт картинку куда чище и детализированнее с меньшим мылом и артефактами. Этого булшит-бинго от ISO я уже за столько лет - наслушался. Поэтому они могут идти нахрен. Вместе со своими лицензированиями, имхо. > А вот libaom/libvpx это референсный и "самый лучший", поэтому подобное > сравнение изначально глупость несусветная. Я даже уже и не знаю кто они сейчас. Ибо САБЖ тоже AOM пилит. Хорошо пилит я б сказал. > Сравнил сейчас libaom crf=35 с libx265 crf=27 как сопоставимые по битрейту и > качеству, выглядит примерно одинаково паршиво, libaom намного дороже. Libaom и SVT надо актуальных версий сравнивать если что. Они довольно бойко развиваются. Так что вот, сказ про AVX2 и 48 гиг на поаерку оказался - полным булшитом. > отключённой психовизуальщиной, но x265 в несколько раз производительнее в итоге. Ну а вот сабж - заметно резвее. И может сожрать довольно много ядер если они есть. Но вообще при ворочании тяжелым кодеком я заведомо не торопился. Иначе нафиг я его взял? :) > вычислительной сложности. В любом случае, BBB в качестве тестовых данных никуда не годится. Ну вот конечно, будем подгонять решение под ответ, коли x265 на этом лажает. > Ах да, я использую шейдер FSRCNNX_x2, поэтому все дефекты sd-контента вижу очень > отчётливо. Возможно, есть другой шейдер, который будет сглаживать конкретно эти артефакты, > этот делает все артефакты более явными. А я просто делаю ресайз ffplay на полный экран, без постпроцессинга. С моим размером экрана (30" 4K качественный IPS) вся лажа кодека как на ладони.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

141. Сообщение от Аноним (141), 18-Мрт-24, 17:38	+/–
За те же деньги для продавца ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

142. Сообщение от Аноним (88), 19-Мрт-24, 17:45	+/–
AV1 это эволюция VP9. Который гугл обязался защищать от патентных нападок. Они улучшали VP9, вначале назвав   его VP10 (https://www.phoronix.com/news/Libvpx-VP10-Start) но потом решили расширить участие других разработчиков и вместо VP10 назвали AV1. тут почитайте: https://web.archive.org/web/20210711073657/https://www.gpac-.../ И да, ноги у него растут из Theora который был проприетарный и закрытый VP3..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #143, #144

143. Сообщение от Аноним (143), 19-Мрт-24, 22:49	+/–
Понял, спасибо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

144. Сообщение от Аноним (-), 21-Мрт-24, 01:44	+/–
> AV1 это эволюция VP9. Который гугл обязался защищать от патентных нападок. Они > улучшали VP9, вначале назвав   его VP10 ...но AV1 мощнее чем это. Он гибрид, где улучшения для VP10 - от гугля. Ряд идей из Thor от CISCO. Часть идей - DAALA от Xiph. А некоторые разработки - вообще уникальны для этой тимы самой по себе. CDEF например, прямых аналогов этой фичи никогда и ни у кого не было. Глобальная компенсация движения? Тоже в общем то разработана участниками под эту штуку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

145. Сообщение от Tester (??), 23-Мрт-24, 19:21	+/–
да пробовал как то на ffmpeg кодировать AV1 постоянно ошибки - avcodec_receive_packet failed, error: Resource temporarily unavailable, code: -11
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема