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

"Выпуск SVT-AV1 3.0, кодировщика для формата видео AV1"	+/–
Сообщение от opennews (??), 23-Фев-25, 11:20
Опубликован выпуск библиотеки SVT-AV1 3.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.me/opennews/art.shtml?num=62781
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 23-Фев-25, 11:20	+1 +/–
>для кодирования данного формата требуется существенно больше ресурсов Поэтому хардварный Quick Sync это имба: https://www.techpowerup.com/review/intel-core-ultra-arrow-la...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #11

2. Сообщение от Аноним (2), 23-Фев-25, 12:09	+/–
> Улучшены unit-тесты для кода, использующего инструкции Arm Neon и SVE2. А если запустить в bochs или qemu в tcg? А то комп у меня не имееть этой инструкции...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #7, #9

3. Сообщение от Аноним (3), 23-Фев-25, 12:11	+1 +/–
Как у него с соотношением битрейт/качество?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #5

4. Сообщение от Аноним (-), 23-Фев-25, 12:12	–1 +/–
> для которых применяются ассемблерные оптимизации на базе инструкций SIMD Я понимаю что копипаст это круто - но последние пару релизов там доминирует фирма ARM с оптимизациями под свои процы. А заодно и RISCV оптимизации как раз в этой версии завезли. Но про это в новости почему-то ни звука.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #40

5. Сообщение от Аноним (-), 23-Фев-25, 12:13	+/–
> Как у него с соотношением битрейт/качество? Весьма прилично на нижних пресетах (0..4 примерно). Более высокие оптимизированы на скорость кодирования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

6. Сообщение от Аноним (3), 23-Фев-25, 12:14	+2 +/–
> А если запустить в bochs или qemu в tcg? Результат кодирования будешь ждать уже не сутками, а годами. > А то комп у меня не имееть этой инструкции... Собери сабж без её использования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #8

7. Сообщение от Аноним (-), 23-Фев-25, 12:18	+1 +/–
> А если запустить в bochs или qemu в tcg? А то комп у меня не имееть этой инструкции... Для работы кодировщика они в обязаловку не требуются, есть даже чисто сишный fallback. Он уже давно не "требует" команды, а определяет в рантайме - что есть, ну и использует лучшее из доступного. Поэтому будет работать и без них. Запускать юнит-тесты вон того - вообще имеет смысл только если вы девелопаете этот код. Если вы девелопаете оптимизации SVE2 - наверное, логично купить проц с ним. Или как вы эффект от них будете оценивать?! А neon - есть по моему у всех мыслимых ARM кроме совсем уж ископаемых. На совсем уж ископаемом ARM - вы врядли захотите AV1 кодировать - ибо не доживете до окончания кодирования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

8. Сообщение от Аноним (-), 23-Фев-25, 12:27	+/–
>> А если запустить в bochs или qemu в tcg? > Результат кодирования будешь ждать уже не сутками, а годами. Зато познает дао рендера в юнитах FPY - frames per year.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

9. Сообщение от Аноним (9), 23-Фев-25, 13:35	+/–
Bochs чисто про x86, там нет ARM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

10. Сообщение от Карлос Сношайтилис (ok), 23-Фев-25, 13:41	+/–
> присутствующие в современных CPU Intel средства аппаратного распараллеливания вычислений Так AMD тоже поддерживает AVX2. Или они ассемблерные вставки только под Intel клепают?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48

11. Сообщение от Аноним (11), 23-Фев-25, 14:05	+/–
Я бы поставил на то, что nvenc и тут уделает. Естественно, конкурировать тут только с svt-av1 и получится. Видимо, они сознательно делают libaom всё более глючным с кучей артефактов, но av1 мертворождённый в любом случае. Ты вот знал, что в нём даже поддержки альфа-канала нет? Мыло опять же. Разве что меньше бандинга и лестниц на градиентах стало. В остальном, как был vp8, так и остался. Если очень повезёт, добьётся хотя бы такого же распространения (только теперь уже требует поддержки в железе). Всё жду, когда jpegxl окончательно вынесет avif и webp (видеокодеки не подходят для растра) и h266 в свою очередь все видеокодеки (если только av2 всех не удивит).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #15, #18, #47, #67

15. Сообщение от Аноним (1), 23-Фев-25, 14:45	+/–
>но av1 мертворождённый в любом случае https://en.wikipedia.org/wiki/AV1#Content_providers >Я бы поставил на то, что nvenc и тут уделает По качеству или как ? Просто тут тогда надо смотреть более детально и сравнивать возможности как встройки, так и дискретки: - https://3dnews.ru/assets/external/illustrations/2025/01/16/1... - https://3dnews.ru/assets/external/illustrations/2025/01/16/1...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #20, #27

18. Сообщение от Ivan_83 (ok), 23-Фев-25, 15:10	+1 +/–
Не знаю чем нужна прозрачность в видео. Как пользователь трекеров я бы хотел везде видеть AV1 или хотя бы h.265 - быстрее качается а с виду тоже самое. Для себя рассматривал возможность перекодировки домашнего видел в AV1, пока пробовал получалось в 2-3 раза меньше без видимой потери качества (относительно аппаратного .h264 который выдавал 100 мегабит поток). Насчёт фоток - хз, мне тут и старого джпега хватает. avif выглядит заманчиво - унификация с видео кодеком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #21, #23, #28, #45, #52, #76

20. Сообщение от Аноним (-), 23-Фев-25, 15:32	–1 +/–
У меня NVIDIA GeForce GT 1030 менять пока не планирую, устраивает, тогда так: https://3dnews.ru/1110510/vk-video-vnedryaet-tehnologiyu-sga... Нужен не нужен AV1 не спрашивают внедряют кому надо. Для меня так как и процессор не передовой оптимально качество, скорость это x264 как был так и остался. x264 в режиме сжатие без потерь тоже пользуюсь. Пользуюсь и другими кодеками xvid, FFV1, по ситуации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #73, #74

21. Сообщение от Аноним (11), 23-Фев-25, 15:39	+2 +/–
Эпл вон оценил такую фичу, очевидно, она необходима в современном мире. Как пользователь трекеров я хотел бы видеть больше сидов на ремуксах, это примерно всегда h265. То, что перекодировано с них, всегда мыльное и глитчами. Часто с убитыми цветами и балансом белого, иногда и контрастностью. В актуальных картах nvidia стоит неплохой кодер h265, кодер h264 хоть и улучшали, весьма посредственный. Насчёт картиночек, для меня ключевое то, что видеокодеки не имеют цели точно кодировать отдельные кадры, отсюда и все особенности. Ну и заточены на определённый контент. Кроме того хотелось бы стандартизированную поддержку "расширенных" параметров, чтобы не было такого, что нормально отображается только в 1 программе, причём, той версии, в которой файл и создан.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #29, #77

22. Сообщение от Аноним (22), 23-Фев-25, 15:49	+/–
> с целью достижения уровня производительности, пригодного для > перекодирования видео на лету Стесняюсь спросить, но все же - иии... и как? С перекодированием на лету?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43

23. Сообщение от Аноним (-), 23-Фев-25, 15:59	+/–
У webp тем что я пользуюсь, есть крутилка качества сжатия как и у jpeg, работает так: 0-100% меньше хуже выглядит, меньше размер. Я использую webp с 65%. С каким-то изображением, без видимого ухудшения качества, меньше размер выходит если использовать GIF. Webp меняет оттенки цвета красный может стать розоватым, всегда, не всегда не запомнил, может от сжатия зависит меньше качество сильнее заметно. Использую webp: показал и забыл даже не сохраняю. В моем деле непринципиально в каком формате показывать. И не всегда это webp. Испоьльзую GIF, PNG.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #24, #30

24. Сообщение от Аноним (11), 23-Фев-25, 16:11	+1 +/–
Если включишь sharp yuv в кодере, webp будет на порядки лучше. В частности, с цветами. А в чём смысл качество меньше 90 ставить? Это не как jpeg, где с качеством 60 ещё можно что-то рассмотреть. На ультранизком качестве вроде avif лучше всего позволяет пожать, но выглядит он хуже webp.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #25, #78

25. Сообщение от Аноним (-), 23-Фев-25, 16:29	+/–
С webp подробностей не знаю, не интересовался. Попробовал webp, посмотрел какие в нём есть настройки. Самое простое для понимания был регулятор от нуля до 100. Покрутил, по сжимал с 5, 33, 65 по умолчанию было вроде 80. Посмотрел качество, размер, остановился на 65. Делов на несколько минут. Подробно изучать настройки не хочу, мне это на данный момент не нужно, возможно и не когда не понадобится, выше написал по чему. "Использую webp: показал и забыл даже не сохраняю. В моем деле непринципиально в каком формате показывать. И не всегда это webp. Использую GIF, PNG"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

27. Сообщение от Аноним (-), 23-Фев-25, 17:03	+/–
https://3dnews.ru/assets/external/illustrations/2025/01/29/1... Эх не оправдали мои надежды до потребления как электрический чайник (1800-2000Ватт) ещё далеко или нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

28. Сообщение от Аноним (28), 23-Фев-25, 17:22	+/–
"Revolution OS", закодированный в Theora хватит всем гнутым.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #34, #36

29. Сообщение от Ivan_83 (ok), 23-Фев-25, 17:51	+/–
Я не понимаю  профита от прозрачности в видео, а эпл там же и DEI оценил, только вот я тоже не понимаю какая с этого польза. Видеокодеки имеют цель качественно кодировать ключевые кадры, это как минимум логично. Хз какие вам там нужны параметры, я кроме разрешения, битности и степени сжатия ничего не знаю да и не нужно это в 99% случаев.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #31

30. Сообщение от Ivan_83 (ok), 23-Фев-25, 17:54	+/–
https://www.opennet.me/opennews/art.shtml?num=56229 Вот идеальный "кодек", можно сказать архиватор картинок :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #55

31. Сообщение от Аноним (11), 23-Фев-25, 18:00	–1 +/–
Профит в обработке/производстве видео. Сейчас у тебя либо эпловский софт с поддержкой h265 и прозрачности, либо лосслесс и пнг с каждым кадром отдельно на диске.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #59

33. Сообщение от Аноним (33), 23-Фев-25, 18:10	+/–
Чем это лучше VVC? Неуплатой дани патентастам? Так бери и не плати. И заметьте - AV1 таки использует запатентованные технологии.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37, #41, #69

34. Сообщение от Аноним (-), 23-Фев-25, 18:23	+/–
Всё это движение с развитием кодеков делается для уменьшения размера. Если размер не учитывать, MPEG-1, MPEG-2 визуально большинство устроит если битрейт использовать от 4000 кбит/c и выше 8000, 20000, 800000 кбит/с, 300 Мбит/с. И если аппаратура справится. Интернете если канала хватит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #35, #38

35. Сообщение от Аноним (-), 23-Фев-25, 18:27	+1 +/–
80000 кбит/с = 80Мбит/c ноль выше лишний.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

36. Сообщение от Аноним (-), 23-Фев-25, 18:29	+1 +/–
80000 кбит/с = 80Мбит/c ноль выше лишний.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

37. Сообщение от Хо (?), 23-Фев-25, 18:49	+3 +/–
Этот vvc с вами в одной комнате? В интернете нигде не встречал его, а av1 в Ютубе давно есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

38. Сообщение от Аноним (11), 23-Фев-25, 18:53	+/–
300 Мбит/с это только для фуллхд хватит, сейчас уже 8к на дворе. Наконец сравняли качество цифровой картинки с плёнкой 100-летней давности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #39

39. Сообщение от Аноним (-), 23-Фев-25, 19:49	+/–
"300 Мбит/с это только для фуллхд хватит" не проверял. Сомневаюсь что это правда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #42, #49

40. Сообщение от Аноним (40), 23-Фев-25, 19:58	+/–
Наверное, из-за рассововерности x86_64.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

41. Сообщение от Аноним (40), 23-Фев-25, 20:02	+1 +/–
Но AV1 ещё никто не нагнул на роялти. За ним стоит копрорация бобра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #85

42. Сообщение от Аноним (11), 23-Фев-25, 20:06	+/–
Ну понятно это всё равно mpeg2 будет, просто удобоваримый. Какой-нибудь prores лучше для обработки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

43. Сообщение от Аноним (43), 23-Фев-25, 21:38	+/–
А ты попробуй. Я вот игры записывал, но если мониторинг включен обыватели будут шарахаться, хотя 12900К не то чтобы с избытком хватает. Конечно можно качество урезать, но так тоже можно. Если стрим идет на мобильном интернете может и помочь для 4К в 60 кадров. Фишка в том что и те кто смотрят могут иметь полуживой интернет и тут AV1 выручает. Хотя можно интеловскую видеокарту или встройку новую под это дело выделить. UHD770 на линуксе слабовата для 4К и даже в VP9 залагивается. Хотя может гуру подскажут как это можно обойти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #44, #46

44. Сообщение от Аноним (11), 23-Фев-25, 21:54	+/–
>UHD770 на линуксе слабовата для 4К и > даже в VP9 залагивается Неужели всё так плохо? 4k vp9 нормально декодировался программно бюжетным sandy bridge в браузере на линуксе и ещё половина процессора оставалась. И это было почти 15 лет назад.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #53

45. Сообщение от fuggy (ok), 23-Фев-25, 22:14	+/–
> avif выглядит заманчиво - унификация с видео кодеком Для разработчика кодека изображений это хорошо - меньше работы. Но видеокодеки плохо подходят для статических картинок, они мылят картинку, что на количестве кадров в секунду это незаметно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #54

46. Сообщение от Аноним (1), 23-Фев-25, 22:24	+/–
С 30-ой версии появилось: >Добавлена поддержка технологии Intel QSV (Quick Sync Video) для аппаратного ускорения кодирования и декодирования видео в форматах H264, HEVC и AV1 на платформе Linux. https://opennet.ru/60098-obs
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

47. Сообщение от Аноним (47), 23-Фев-25, 23:05	+/–
>  Я бы поставил на то, что nvenc и тут уделает. Естественно, конкурировать тут только с svt-av1 и получится. Из широко доступных аппаратных NVENC самый лучший, да: https://compression.ru/video/codec_comparison/2023/hardware_... Только программные кодеки по качеству всё равно на голову выше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

48. Сообщение от Аноним (48), 24-Фев-25, 00:14	+/–
Самое забавное, что как раз у Intel c AVX2 не очень.1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #51, #66

49. Сообщение от Аноним (-), 24-Фев-25, 00:18	+/–
""300 Мбит/с это только для фуллхд хватит" не проверял. Сомневаюсь что это правда" У меня сомнения если 8к 60 кадров сжимать в MPEG-2 300 Мбит/с не хватит предполагаю должно хватить с большим запасом не проверял. 1080p 25 кадров 10-20Мбит/с. Для 4К 60 кадров для MPEG-2 есть предположение 20-30Мбит/с. хватит. Проверял но уже подзабыл точные цифры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #50

50. Сообщение от Аноним (-), 24-Фев-25, 00:53	+/–
У меня есть файл AVC1 4k 60 кадров битрейт меняется от 11 тыс. до 23 тыс. кбит/с. Средний 15 тысяч. кбит/с. Я этот файл не кодировал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

51. Сообщение от Аноним (1), 24-Фев-25, 01:10	+/–
>не очень Почему ? AVX2 у Интел появился раньше: https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPU...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

52. Сообщение от Аноним (55), 24-Фев-25, 03:28	+/–
> avif выглядит заманчиво - унификация с видео кодеком. Обманчивая мысль. 1) Видеокодеку почти не нужен lossless-режим. 2) Не нужна прогрессивная загрузка ключевых кадров. 3) Не нужно быстрое программное декодирование, если он уже сильно завязан на аппаратные декодеры. WebP вот тоже унифицирован с VP8. Но для lossless-режима он вместо унификации вобрал в себя отдельный кодек. Результат: lossless AVIF хуже, чем lossless WebP[1]. А на унификации WebP ещё обжёгся тем, что нет 4:4:4 lossy (который для VP8 был не нужен). А что будет, если про эту обманчивую мысль забыть? Вот у старого жипега было больное место - арифметическое кодирование, которое сначала не включали из-за патентов, а потом из-за обратной совместимости. И это больное место превратили в отдельный режим у JXL - в него без потерь перекодируются жипеги с экономией 15-20% места. [1] https://github.com/AOMediaCodec/av1-avif/issues/111 и заодно https://www.reddit.com/r/AV1/comments/rkcx0o/we_need_to_reth.../
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #68

53. Сообщение от Аноним (43), 24-Фев-25, 03:40	+/–
Да, запись на линуксе хромает на все три ноги. Иначе этот SVT-AV1 и ненужен. Он только для записи. Причем в OBS, чтобы не придирались. Впрочем там еще и игра часто влияет и некоторые игры могут статтерить и в 1080. Очень трудно в итоге запись сделать показав реальные цифры производительности и потребления. Просто топовый процессор жрен дофига и пугать людей потреблением более 100 ватт это напрашивать на критику тех кто это увидит. Я вот не считаю что та же Троя должны столько жрать. Это надо быть безумцем чтобы гнаться за производительностью методом покупки дорогого железа. Я всеми руками против предтоповых и топовых видеокарт из-за их крайней жручести в паре с весьма скромной энергоэффективностью относительного центральных процессоров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #56, #57

54. Сообщение от Аноним (55), 24-Фев-25, 03:42	+/–
Ну, ключевым кадрам надо выглядеть хорошо и в видеоэнкодерах можно припомнить крутилки вроде "tune grain", "tune stillimage", которые должны усмирять психовизуальные оптимизации, опирающиеся на то, что кадр долго разглядывать не будут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

55. Сообщение от Аноним (55), 24-Фев-25, 04:49	+/–
Это кодек для чьей-то программерской души и обучения. А пользователь скажет, что они по характеристикам изобрели TGA (скорость и степень сжатия), но пожертвовали совместимостью (один TGA у пользователей уже есть). Отдушина для чьей-то души, уставшей от сложного софта, не любящей фиксированные типы (uint32_t)[1] и ошибающейся с порядком байт[2]. [1] https://github.com/phoboslab/qoi/issues/197 [2] https://github.com/phoboslab/qoi/issues/36
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #58

56. Сообщение от Аноним (11), 24-Фев-25, 10:08	+/–
Так речь о декодировании. А так там nvenc есть в самых бюджетных картах и не создаёт никакой нагрузки на процессор. За исключением совсем уж огрызков вроде GT 1030. Кто ж использует программные кодеры в obs. https://developer.nvidia.com/video-encode-and-decode-gpu-sup...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #62, #64, #65

57. Сообщение от Аноним (11), 24-Фев-25, 10:19	+/–
А электричество они при этом не используют особо, центральный процессор куда жручей. Особенно, если это карта с пассивным охлаждением.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #63

58. Сообщение от Ivan_83 (ok), 24-Фев-25, 14:54	+/–
Тут скорее алгоритм сжатия изобрели, а реализацию допиливают. TGA я давно не видел, лет 20-25 :) А эти мелочи легко поправить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #61, #91

59. Сообщение от Ivan_83 (ok), 24-Фев-25, 14:55	+/–
Я всё равно не понял для чего в видео нужна прозрачность. Если это камень в огород AVIF то я понимаю, да и то, по мне прозрачность это то что нужно для фоток :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #60

60. Сообщение от Аноним (11), 24-Фев-25, 15:07	+/–
Зелёный экран будет работать только если ассеты сжаты без потерь и то не всегда. И прозрачность будет работать без затрат, но нет поддержки в софте и ограниченная поддержка в железе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #84

61. Сообщение от Аноним (-), 24-Фев-25, 15:58	+/–
А это во что будешь сохранять, было бы чем сохранять и чем просматривать. ibb.co/PsYv6CgY
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

62. Сообщение от Аноним (43), 24-Фев-25, 16:08	+/–
То что вы там на своей волне и пытаетесь все так представить не делает SVT-AV1 декодировщиком. Нагрузка и на UHD770 практически не ощущается. Я использую программный вариант, потому что сил встройки не хватает для этого. Покупать проклятую нвидию в линукс я что-то пока не рехнулся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

63. Сообщение от Аноним (43), 24-Фев-25, 16:09	+/–
Да только качество у аппаратного кодировщика все равно хуже. Так что для себя какой-нибудь семейный архив аппаратными кодерами делать не стоит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #70

64. Сообщение от Аноним (-), 24-Фев-25, 16:32	+/–
Как будто до GT 1030 других версий видеокарт не было. Кому что надо и у кого какие интересы. Цена, наличие денег.  Меня не цена не устраивает, не размеры, не потребление электричества и нагружать мне RX видеокарты не чем и подобные от AMD. Есть чем но, это вне моих интересов.  Я когда покупал GT 1030 не смотрел на ней можно кодировать, а что декодировать. Я знал что декодировать можно точно H264,AVC1. H265,HEVC,VP9 предполагал. Кодировать видеокартой вообще не рассматривал мне это не особо надо на процессоре устраивает использовать x264 для того что я кодирую. Но, у меня требования к видео низкие 240p устраивает не критично. Фильмы я практически не смотрю. В игры не играю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

65. Сообщение от Аноним (-), 24-Фев-25, 16:47	+/–
И GTX не надо мне по тем же причинам что и RTX. Не нужен мне AV1 я его не выбирал пользуюсь что дают. На процессоре хватает декодировать 360p,720p и сойдёт. Я к чему это, не все покупают от не знания что покупают и от отсутствия денег купить другое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #71

66. Сообщение от Аноним (-), 24-Фев-25, 17:37	+/–
Это ты о Pentium и Celeron?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

67. Сообщение от Аноним (-), 24-Фев-25, 17:59	+/–
> Я бы поставил на то, что nvenc и тут уделает. Только по скорости. По битрейт-качество libaom на медленных пресетах рулит, особенно новый и если параметры под контент покрутить. Но надо мощный проц. > Естественно, конкурировать тут только с svt-av1 и получится. > Видимо, они сознательно делают libaom всё более глючным с кучей артефактов, Для специфичного контента может потребоваться подкрутить параметры. По дефолту ВИДЕОкодеки - оптимизируют на ВИДЕО. А не шакаленый контент от всяких хикки. Сабж интересен тем что шустр при использовании CPU, лучше прогружает ядра и при всем этом неплохо жмет. И вот утащили оптимизации из стороннего форка (PSY-оптимизации). > но av1 мертворождённый в любом случае. В нем играется практически весь ютуб. На одном только этом фоне дохлые - потуги от ISO. За день в мире играется столько AV1, сколько в других кодеках за неделю не будет. Разве что VP9. > Мыло опять же. Настраивается в современных кодеках. Включая сабжа. Только чудес не бывает и при плотном сжатии - можно артефакты огрести. А в случае конкретно сабжа - они тягают оптимизации вооон оттуда https://github.com/psy-ex/svt-av1-psy - какие-то видеоэксперты с https://svt-av1-psy.com/video/ вполне не против присоединиться к гонке и дать мастерклассы. > Разве что меньше бандинга и лестниц на градиентах стало. Это все на каком битрейте? > В остальном, как был vp8, так и остался. Полный BS. Это уже давно гибрид Thor, Daala и VP9. А фичи битстрима делают допустим H.265 с огромным отрывом. У того ни аналога CDEF, ни нормальной компенсации глобального движения, да даже по моему аналога CFL - и то нету. Убогий формат, с единственным достоинством - "патентные тролли хотят денег". Поэтому и истерика на тему строгания новых WTFVC, которых уже штук пять наплодили - только никому уже не надо на тех условиях. > поддержки в железе). Всё жду, когда jpegxl окончательно вынесет avif и > webp (видеокодеки не подходят для растра) Это простое заявление - палит весь уровень экспертизы "эксперта" как облупленного. > и h266 в свою очередь все видеокодеки (если только av2 всех не удивит). Никто не будет в вебе платить отчисления за патенты - когда можно не платить. Да и длинной очереди желающих реализовывать продвинутый качественный кодек - не заметно. В том числе и потому что в веб этому барахлу путь заказан. Так что патентные тролли будут грызться между собой на тему почему им денег нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

68. Сообщение от Аноним (-), 24-Фев-25, 18:19	+/–
>> avif выглядит заманчиво - унификация с видео кодеком. > Обманчивая мысль. 1) Видеокодеку почти не нужен lossless-режим. Почти - не считается. Есть случаи когда lossless полезен. А минус отдельные либы - удобно в, допустим, браузерах. Небольшой такой юзкейс. > 2) Не нужна прогрессивная загрузка ключевых кадров. У нас тут что, эксперт из ISO, под которым кресло шатается? Нефиг было патентных троллей ублажать вместо своей работы, имхо. За свою коррумпированость ISO стал довольно непопулярен. 3) Не нужно быстрое программное декодирование, если он > уже сильно завязан на аппаратные декодеры. В случае картинок - пофиг. Времена декодирования не такие чтобы париться. > вобрал в себя отдельный кодек. Результат: lossless AVIF хуже, чем lossless WebP[1]. Какой-то nitpicking бестолковый. Без аргументов, пруфов и проч. С 0 ответов на наброс. > А на унификации WebP ещё обжёгся тем, что нет 4:4:4 > lossy (который для VP8 был не нужен). Так не нужен, что его в VP9 его запилили. Логично. > из-за патентов, а потом из-за обратной совместимости. И это больное место > превратили в отдельный режим у JXL - в него без потерь > перекодируются жипеги с экономией 15-20% места. Это все прекрасно - но совместимость этого JXL с софтом как раз - провальная. Это то что господа получают за жабу. Извините, но 15% экономии - это не то ради чего кто-то будет сильно убиваться. Просто для понимания, AV1 относительно 264 может битрейт разика в 3 скостить без визуальных потерь. И тут еще понятно ради чего мучаться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #72, #99

69. Сообщение от Аноним (-), 24-Фев-25, 18:26	+/–
> Чем это лучше VVC? Неуплатой дани патентастам? Так бери и не плати. Тем что 1) Уже широко задеплоен и юзается. Если в инфо о видео (stats for nerds) на ютубе написано "AV01" - это оно. А теперь это там - по уже везде. 2) Поддержка софта и нормальные кодеки этого WTFVC где? Или это еще и самим писать надо? 3) Не зашкварившийся ISO, дискредитировавший себя обслугой патентных троллей, OOXML и прочей откровенной коррупцией. > И заметьте - AV1 таки использует запатентованные технологии. Там пул патентов организован чтобы всем его нашару юзать всей толпой. И условия довольно интересные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

70. Сообщение от Аноним (-), 24-Фев-25, 18:28	+/–
> Да только качество у аппаратного кодировщика все равно хуже. Но какой-нить голимый стрим на 1 раз - сойдет, там все равно детали рассматривать некогда, реалтайм же не ждет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

71. Сообщение от Аноним (-), 24-Фев-25, 18:58	+/–
"Не нужен мне AV1 я его не выбирал пользуюсь что дают. На процессоре хватает декодировать 360p,720p и сойдёт" Точнее так: не нужно мне на данный момент декодирование AV1 видеокартой, я AV1 не выбирал пользуюсь что дают. На процессоре хватает декодировать 360p,720p и меня устраивает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

72. Сообщение от Аноним (55), 24-Фев-25, 20:52	+/–
Могу объяснить, почему ты неадекватен. > Почти - не считается. Есть случаи когда lossless полезен. > Небольшой такой юзкейс. Ты споришь с реальностью. Видеокодеку почти не нужен lossless-режим (этот сценарий хорошо закрывается *специальным* кодеком FFV1 и старым H.264) и поэтому его поддержку только сейчас добавляют в SVT-AV1, а libaom в этом режиме с x264 не конкурирует (допишу, когда он хоть что-то закодирует). > У нас тут что, эксперт из ISO, под которым кресло шатается? Нефиг было патентных троллей ублажать вместо своей работы, имхо. За свою коррумпированость ISO стал довольно непопулярен. Ты не понимаешь других людей. Я рассказал про то, что в AVIF нет прогрессивной загрузки (как в JPG или JXL) из-за унификации с видеокодеком, а ты в ответ набрасываешься с посторонним бредом про ISO. > Какой-то nitpicking бестолковый. Без аргументов, пруфов и проч. С 0 ответов на наброс. Ты клевещешь ради холивара. Ссылка на гихтаб AOMediaCodec и десятки комментариев там. Вместо просьбы о других источниках насчёт худшей степени сжатия - "наброс". Нет, наброс - это у тебя. > Так не нужен, что его в VP9 его запилили. Логично. Цифры 8 и 9 различаются. Докажи, что его следовало добавить в VP8. В WebP он востребован из-за конкуренции с JPEG (где этот режим есть), а зачем он нужен для stopgap-кодека с более серьёзными проблемами, который применялся для низких разрешений на ютубе? > Это все прекрасно - но совместимость этого JXL с софтом как раз - провальная. Речь идёт об одном большом браузере на букву Х. На всё воля Google, захочет добавить поддержку - добавит, не захочет - не добавит. У корпораций огромная власть. > Извините, но 15% экономии - это не то ради чего кто-то будет сильно убиваться. > Просто для понимания, AV1 относительно 264 может битрейт разика в 3 скостить без визуальных потерь. Путаешься в показаниях. Начал с того, как lossless важен, а закончил тем, что он не важен и обманом сравнил lossless-режим с lossy ("без визуальных потерь"). [1] https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #75, #79

73. Сообщение от Аноним (73), 24-Фев-25, 21:01	+/–
> xvid Прямо интересно услышать хоть одну причину его использования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

74. Сообщение от Аноним (-), 24-Фев-25, 21:53	+/–
> У меня NVIDIA GeForce GT 1030 менять пока не планирую, устраивает, тогда > так: https://3dnews.ru/1110510/vk-video-vnedryaet-tehnologiyu-sga... > Нужен не нужен AV1 не спрашивают внедряют кому надо. С вас денег - как с козла молока, а трафик и хранение ваших котят денег жрет дай боже. Платить в РАЗЫ больше - кому-то надо? К тому же чем жирнее поток видео онлайн - тем чаще оно выпадает и икает, чем бесит пользователей. > Пользуюсь и другими кодеками xvid, FFV1, по ситуации. Осталось еще MPEG-2 вспомнить... ибо кому и зачем в второй четверти 21 века вперся xvid?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #81

75. Сообщение от Аноним (55), 24-Фев-25, 23:01	+/–
> допишу, когда он хоть что-то закодирует ffmpeg -i <in> -c:v libx264 -qp 0 <out> aomenc --lossless=1 --output=<out> <in> aomenc посвежее, чтобы избежать старого бага[1]. Хм, там ещё открытый баг про 10-битный режим[2]. В общем, файлы от aomenc крупнее, про скорость лучше не буду. В AV1 lossless-режим почти не важен, я говорил. В H.265 (или как минимум x265) с эффективностью losless-режима похожая ситуация была. [1] https://aomedia.issues.chromium.org/issues/42302424 [2] https://aomedia.issues.chromium.org/issues/387472912
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #80

76. Сообщение от Аноним (-), 25-Фев-25, 03:16	+/–
> в 2-3 раза меньше без видимой потери качества (относительно аппаратного .h264 > который выдавал 100 мегабит поток). Мувик с не очень похабной камеры дающей рыхлый H.264 можно раз в 5 сжать без видимых визуальных потерь. Учитывая объемы мувиков нынче - весьма актуально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

77. Сообщение от Аноним (-), 25-Фев-25, 03:27	+/–
> Эпл вон оценил такую фичу, очевидно, она необходима в современном мире. Для чего? И да, этот ваш эпл - встроил AV1 в сафари. И даже по моему в i-девайсы уже. А куда он денется с подводной лодки, иначе пользователи этих премиум-жестянок будут смотреть ютуб в зашакаленном качестве, кушая 264 fallback. Как вам 360p премиум на ретина-дисплее, нормуль? :) > Как пользователь трекеров я хотел бы видеть больше сидов на ремуксах, это > примерно всегда h265. А эпл бы вас вообще - в тюрьме хотел бы видеть за это. Хотя-бы в цифровой. На их девайсы вообще видео закачивать - тот еще гемор. Даже просто мувик с камеры залить - та еще порнография. > В актуальных картах nvidia стоит неплохой кодер h265, кодер h264 хоть > и улучшали, весьма посредственный. Кодить хардварным кодером раздачу - это просто позор какой-то. > Насчёт картиночек, для меня ключевое то, что видеокодеки не имеют цели точно > кодировать отдельные кадры, отсюда и все особенности. Ну и заточены на > определённый контент. Кроме того хотелось бы стандартизированную поддержку "расширенных" > параметров, чтобы не было такого, что нормально отображается только в 1 > программе, причём, той версии, в которой файл и создан. С таким уровнем экспертизы лучше сразу помалкивать что вы там хотите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

78. Сообщение от Аноним (-), 25-Фев-25, 03:29	+/–
> Если включишь sharp yuv в кодере, webp будет на порядки лучше. В > частности, с цветами. Однако ряд картинок по типу скриншотов - yuv 4:2:2 by design убивает, и это не лечится. Совсем. Работает он так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

79. Сообщение от Аноним (-), 25-Фев-25, 15:08	+/–
> Могу объяснить, почему ты неадекватен. Не уверен что я. > Ты споришь с реальностью. Видеокодеку почти не нужен lossless-режим (этот сценарий > хорошо закрывается *специальным* кодеком FFV1 и старым H.264) У AV1 мощнее предсказания и их больше - по идее может быть компактнее древних, если довести до ума. А до кучи полезно иногда. Это довольно просто на техническом уровне. Кодек работает как обычно, потом считается ошибка оригинал VS результат, сие кодируется ("residuals"). Так lossy становится lossless. > и поэтому его поддержку только сейчас добавляют в SVT-AV1, а libaom в этом режиме с > x264 не конкурирует (допишу, когда он хоть что-то закодирует). Без этого можно обойтись - но 95% нужной механики уже есть, так что почему бы и? > Ты не понимаешь других людей. Я рассказал про то, что в AVIF > нет прогрессивной загрузки Это можно за минус наверное посчитать. Однако, насколько я помню, у жпегов это раздувает файл, конечный результат одинаковый, так что я этим - не пользовался. Для веба, где это важно, есть технологии лучше. Превьюшки можно генерить отдельно, мизерные, а фулсайз (и тот кодированый под разумные размеры, так что вгрузка быстрая) тягать по мере надобности. Возможно с префетчем следующей картинки, если слайдшоу, пока юзер на первую смотрит. Как вы понимаете, на серваке хочется минимум трафа и чтобы клиент отвалил побыстрей. > Ты клевещешь ради холивара. Ссылка на гихтаб AOMediaCodec и десятки комментариев там. На гитхабе вроде 1 комент без ответа? А ссыль на редит "авторитативна" не более чем ссыль на опеннет. Реддит - просто трепалка в интернете, давно уже довольно маргинальная. > Вместо просьбы о других источниках насчёт худшей степени сжатия - "наброс". Что за просьбы? Если что, анонов бывает - более 1. По моему это претензия - не по адресу. Или хотя-бы дословно цитируйте что вы мне предъявить пытаетесь. > Нет, наброс - это у тебя. Забойная аргументация, что сказать. >> Так не нужен, что его в VP9 его запилили. Логично. > Цифры 8 и 9 различаются. Докажи, что его следовало добавить в VP8. VP9 появился как развитие VP8, внезапно. Это ТА ЖЕ кодовая база, где добавили больше инструментов кодирования, ссылки на N разных golden frames, другие варианты subsampling, вплоть до 4:4:4 (no subsampling), цветовые пространства типа RGB, позволяющие нормально кодировать видео с компов, 10/12 бит на составляющую, etc. Т.е. это работа над ошибками VP8 по сути. Появление VP9 говорит что это следовало сделать. И сделали. То что webp на данный момент устаревший... блин да, поторопились с релизом. И формат файла не очень расширяемо задуман в плане обратной совместимости. Гугл с webp сделал - первое что в бошку пришло, почти внутренний эксперимент. А оно взяло и пошло в массы, зашло - и хрен отберешь без воя! Это слегка глупо, но технология порой начинает жить не так как представляли создатели, а потом что-то крупно менять поздняк. Как с IPv4 и 32 бита на адрес примерно. > В WebP он востребован из-за конкуренции с JPEG (где этот режим есть), Я никогда не кодировал под веб с прогрессивом т.к. файло - больше. > а зачем он нужен для stopgap-кодека с более серьёзными проблемами, > который применялся для низких разрешений на ютубе? Если stopgap это AV1 - то это такой нормальный stopgap, который может утирать нос не только 265 но и 266, не страдая патентопроблемами в том обхеме и играясь в вебе. Это очень жирное преимущество, имхо. > Речь идёт об одном большом браузере на букву Х. А также о софте для редактирования и преобразования. Собссно у webp с этим тоже проблемы есть. Скажем сделать анимированный webp - да не вопрос, даже ffmpeg можно, из любого мувика или кучки картинок. Но вот теперь открыть такой webp чем-то кроме браузера... не, даже ffmpeg сие как input не жрет! И хрен знает кто кроме браузеров - жрет. Анимированный webp - эталонный write-only формат. > На всё воля Google, захочет добавить поддержку - добавит, не захочет - не добавит. У разработчиков есть свои заморочки, типа объема кода на майнтенанс. Если вон то они и так и сяк майнтайнили, а тут надо отдельные либы, ради 15% выигрыша, только на картинках - это не очень хорошее соотношение в целом на уровне проекта. > У корпораций огромная власть. В отличие от борцунов с форумов у них как правило мощный и рациональный менеджмент, нацеленный на сбалансированную картинку в целом. > Путаешься в показаниях. Начал с того, как lossless важен, а закончил тем, > что он не важен и обманом сравнил lossless-режим с lossy ("без визуальных потерь"). Я вообще никогда не педалировал lossless режим, это какой-то другой анон видимо был. Мне AV1 нравится как раз тем что круто жмет в lossy, показывая забойное соотношение битрейт/качество.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #86

80. Сообщение от Аноним (-), 25-Фев-25, 15:10	+/–
>> допишу, когда он хоть что-то закодирует > ffmpeg -i <in> -c:v libx264 -qp 0 <out> А это точно - lossless был? Ибо 264 вроде никогда и не заявлял - lossless?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #87

81. Сообщение от Аноним (-), 25-Фев-25, 18:14	+/–
Для чего делают кодеки это понятно и отчасти известно, в первую очередь уменьшить размер файла. "Осталось еще MPEG-2 вспомнить... ибо кому и зачем в второй четверти 21 века вперся xvid?" Нет возможности использовать MPEG-2, Xvid, а если есть вы против? Это будет такое же обсуждение, а за чем нам надо MP3. Не надо MP3, MPEG-2, Xvid не конвертируйте кодеками MP3, MPEG-2, Xvid, надо конвертируйте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #82, #83

82. Сообщение от Аноним (-), 25-Фев-25, 18:55	+/–
Xvid основан на стандарте MPEG-4 Part 2.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

83. Сообщение от Аноним (83), 25-Фев-25, 19:46	+/–
> Для чего делают кодеки это понятно и отчасти известно, в первую очередь > уменьшить размер файла. Именно. И прогресс lossy измеряется в соотношении битрейт-качество. > "Осталось еще MPEG-2 вспомнить... ибо кому и зачем > в второй четверти 21 века вперся xvid?" Нет возможности использовать MPEG-2, > Xvid, а если есть вы против? Я просто не понимаю зачем это. Конечно иногда люди и на паровозах ездят, но это больше в "декоративных" целях чем что-то практически значимое. > Это будет такое же обсуждение, > а за чем нам надо MP3. Не надо MP3, MPEG-2, Xvid > не конвертируйте кодеками MP3, MPEG-2, Xvid, надо конвертируйте. Между нами - я уже и не вспомню в каком году запускал lame или xvid. Это было давно. Более 10 лет назад точно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

84. Сообщение от Аноним (83), 25-Фев-25, 19:48	+/–
> Зелёный экран будет работать только если ассеты сжаты без потерь и то > не всегда. Зеленый экран и проч - как и прозрачность - весьма нишевые специализированные вещи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

85. Сообщение от Аноним (85), 26-Фев-25, 04:25	+/–
> Но AV1 ещё никто не нагнул на роялти. За ним стоит копрорация бобра. Более того - у них общий патентный пул И фонд который как раз поддержит тех на кого подали в суд за использование кодека если они сами - тощие. Вот прям так. Т.е. это неудобная для наездов патентных троллей цель, они явно задались вопросом как это дело срубить. И по моему есть правила позволяющие аннулировать патенты, если доказано что владелец патента сам разработок не ведет, не имеет таких намерений - и только занимается саботажем других. В этом смысле вон те конторки видимо могут гопстопать только тех кто по доброй воле гопстопается. Как говорится - А можно меня не есть? - Можно, вычеркиваю! - Ух ты, а что, так можно было?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

86. Сообщение от Аноним (55), 26-Фев-25, 08:44	+/–
> Не уверен что я. А посмотри, что ты делаешь. Вместо доказывания своих тезисов уводишь разговор в сторону, тонешь в частностях, выдираешь обрывки фраз из контекста. Вместо самостоятельного тестирования или чтения манов поучаешь других ("...так lossy становится lossless" - это пожалуйста, а про наличие lossless в x264 узнать?). --- видеокодеки и lossless-режим "Извини, он и правда слабо востребован в AV1 и плохо работает, не проверил. Битрейты у lossless-видео обычно столь велики, что профессионалы предпочитают lossy ProRes, DNxHR и т.д. Про либы я без повода написал (никто же не предлагал убрать режим из AV1)" --- Не нужна прогрессивная загрузка ключевых кадров "Извини насчёт эксперта из ISO, бес попутал; конечно не нужна. Прогрессивная загрузка - это же чтобы картинка постепенно отрисовывалась при медленном соединении, а в видео надо 24-60 разных изображений в секунду отрисовывать" --- без потерь перекодируются жипеги с экономией 15-20% места. "20% в сжатии без потерь - это ощутимо, это разница между последним призёром конкурса Хаттера и ZPAQ. Или между ZPAQ и 7zip." "Я ещё сам погуглил и узнал[1][2], что lossless AVIF выдаёт файлы в полтора раза крупнее, чем JXL. Это хуже, чем PNG, ну и ну. Это что получается, JXL технически во всём лучше AVIF? Про размеры lossless WebP vs AVIF ты тоже был прав." "Смешивать степени сжатия lossy и lossless больше не буду, это было глупо" > Я никогда не кодировал под веб с прогрессивом т.к. файло - больше. "Я в очередной раз ошибся, у JPEG это уменьшает файл, об этом даже пишут разработчики кодеков[3][4]. Самоуверенность меня подводит, постараюсь поменьше писать, повнимательнее читать" > Забойная аргументация, что сказать. Называешь набросом дискуссию на 20-30 комментариев в репозитории av1-avif. То ли делаешь вид, что их там нет, то ли не можешь допустить, что проблема на твоей стороне в браузере. Называешь набросом консенсус по степени сжатия lossless AVIF - даже не пытался разобраться, слепо бросился защищать гугл, не разбираясь в теме. > Если stopgap это AV1 Ты издеваешься? Предыдущее предложение: "Докажи, что его следовало добавить в VP8". > Без этого можно обойтись - но 95% нужной механики уже есть, так что почему бы и? Это просто иллюстрация невостребованности, ему лет 6, а режим только начинают пилить. А в картинках востребован. И из-за этого противоречия страдает AVIF - он же основан на видеокодеке. В котором режим слабо востребован! Слабо востребован, но его никто не предлагает удалять, поэтому я не принимаю возражение "почти - не считается", оно приписывает мне то, чего я не говорил. А говорил я о том, что lossless-режим в видеокодеках востребован слабо и из-за этого страдает AVIF, основанный на видеокодеке. И мочало. [1] https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQp.../ [2] https://arxiv.org/pdf/2108.02557 [3] https://libjpeg-turbo.org/About/Mozjpeg [4] https://hacks.mozilla.org/2014/08/using-mozjpeg-to-create-ef.../
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #89

87. Сообщение от Аноним (55), 26-Фев-25, 09:19	+/–
Хэши от декодированого потока можно так сверить. ffmpeg -loglevel error -i <in1> -map 0:v -pix_fmt yuv444p16le -f md5 - ffmpeg -loglevel error -i <in2> -map 0:v -pix_fmt yuv444p16le -f md5 - Про pix_fmt: если он у файлов различается (bgr/rgb, le/be), то хэш не сойдётся - наверное, есть смысл прописать какой-нибудь большой формат, чтобы оба файла в него помещались.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #88

88. Сообщение от Аноним (55), 26-Фев-25, 10:01	+/–
> если он у файлов различается Ну, на самом деле не у файлов. А у несжатого кодека (типа rawvideo или pcm_s16le), в который ffmpeg по умолчанию предпочитает кодировать этот файл (поэтому он 24-битный звук при кодировании в wav норовит сделать 16-битным). У него есть защита от неявных преобразований -noauto_conversion_filters, но с -f md5 от неё пользы мало.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

89. Сообщение от Аноним (89), 26-Фев-25, 21:32	+/–
> тестирования или чтения манов поучаешь других ("...так lossy становится lossless" - > это пожалуйста, а про наличие lossless в x264 узнать?). Тут минимум 2 разных анона - вот вас и плющит. А может и больше, я не считал. > "Извини, он и правда слабо востребован в AV1 и плохо работает, не > проверил. Битрейты у lossless-видео обычно столь велики, что профессионалы предпочитают > lossy ProRes, DNxHR и т.д. Это прекрасно - но лично я в ряде случаев именно lossless - пользовался. Да, для нишевых вещей. И что? Учитывая что это просто делается - "почему бы и нет?". > Про либы я без повода написал (никто же не предлагал убрать режим из AV1)" Я подозреваю что майнтайнеры хромиума - не хотят иметь дел с +1 или несколько либ ради 15% выигрыша. > - это же чтобы картинка постепенно отрисовывалась при медленном соединении, а > в видео надо 24-60 разных изображений в секунду отрисовывать" В вебе эту проблему решили иначе - и не особо парятся. Оно оказалось не так уж и нужно. > --- без потерь перекодируются жипеги с экономией 15-20% места. > "20% в сжатии без потерь - это ощутимо, это разница между последним > призёром конкурса Хаттера и ZPAQ. Или между ZPAQ и 7zip." Это несколько другое. Ибо изначальный материал уже lossy. С AV1 имхо мало кто стал бы возиться, если б он дал 20% относительно xvid (jpeg уместно сравнивать наверное с чем-то таким). Но там разница буквально в разы VS 264, на сильно более других объемах трафа/стоража. > "Смешивать степени сжатия lossy и lossless больше не буду, это было глупо" Похвально. Ибо сильно разные ипостаси. Более того - PNG лучше жмет line art, а вон то - фотоподобное добро. Алгоритмы очень сильно разные. > Называешь набросом дискуссию на 20-30 комментариев в репозитории av1-avif. То ли делаешь > вид, что их там нет, то ли не можешь допустить, что > проблема на твоей стороне в браузере. Может и правда не подгрузились. В любом случае не понимаю смысл выпиливать фичу если она делается просто и дешево. > сжатия lossless AVIF - даже не пытался разобраться, слепо бросился защищать > гугл, не разбираясь в теме. Это уже наезды какие-то. Народ от сжатия - сравнивает это все на более тематичном compression.su и тому подобном, и пришли к выводу что AVIF в целом - в целом весьма сильный контестант, с очевидной фичой что часть кодека который и так нужен. > Ты издеваешься? Предыдущее предложение: "Докажи, что его следовало добавить в VP8". Я доказал - показав что это добавлено, в то что стало VP9. VP9 это и есть - VP8 куда добавили вон то и расширили инструменты кодирования. Значит это следовало добавить. Никто не бухает время крутых програмеров в унитаз для лулзов. > Это просто иллюстрация невостребованности, ему лет 6, а режим только начинают пилить. Вы ничерта не понимаете в разработке софта. Есть такая штука как доступные ресурсы тимы и приоритеты. Как вы (не) понимаете, сначала окучивают то что 1) Просто и быстро сделать. 2) Дает при этом ломовой профит (в масштабах гугл). > А в картинках востребован. И из-за этого противоречия страдает AVIF - > он же основан на видеокодеке. Насколько я вижу на более профильных ресурсах, типа упомянутого - в целом AVIF считается весьма приличным контестантом на нишу lossy. Более того - сравнение lossy это всегда очень специфичная задача. Ибо метрики - лишь приблизительные, а субъектив это субъектив и в целом оно тот еще брейнфак. > не говорил. А говорил я о том, что lossless-режим в видеокодеках > востребован слабо и из-за этого страдает AVIF, основанный на видеокодеке. И мочало. Страдает он как-то весьма специфично - в целом довольно приличен вроде получился. А так - в случае жыпегов и проч возможны оптимизации, в том числе и lossless (в том смысле что output идентичный более жирному жыпегу, но файл меньше). > [1] https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQp.../ > [2] https://arxiv.org/pdf/2108.02557 > [3] https://libjpeg-turbo.org/About/Mozjpeg > [4] https://hacks.mozilla.org/2014/08/using-mozjpeg-to-create-ef.../ Ссылки на данные 2014 года - это прекрасно, конечно. Но не факт что актуальный state of art.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #90

90. Сообщение от Аноним (55), 28-Фев-25, 01:50	+/–
> Тут минимум 2 разных анона - вот вас и плющит. Разница между комментариями в 2 минуты, в другом комментарии та же манера расставлять тире и говорить "264", это твой комментарий. Так делать подло, как и отказываться признавать ошибки. И повторюсь: посмотри, что ты делаешь. Вместо доказывания своих тезисов уводишь разговор в сторону, тонешь в частностях. > В любом случае не понимаю смысл выпиливать фичу если она делается просто и дешево. "(никто же не предлагал убрать режим из AV1)", ты точно мне отвечаешь? > compression.su Форум называется encode.su. > Это уже наезды какие-то. Народ от сжатия - сравнивает это все на более тематичном compression.su и тому подобном, и пришли к выводу что AVIF в целом... ...выбран в качестве "безальтернативного" кодека в Chrome по политически мотивированным причинам[1]. Ну, это была не моя идея вспоминать про encode.su. "it should be clearly obvious, to anyone in the know, what they're trying to do. What I don't know is why they bother" "The AVIF team encourages developers to provide feedback and suggestions on how to improve the benchmarks" but after almost two months I am still waiting for a response to the feedback I gave in https://cloudinary.com/blog/contempl...ec-comparisons. Although I keep trying, it is getting increasingly hard to believe that this was a data-driven decision and not a politically motivated one." > Я доказал - показав что это добавлено, в то что стало VP9. > Вы ничерта не понимаете в разработке софта. Есть такая штука как доступные ресурсы тимы и приоритеты. Это ты свои мысли связать не можешь. Я два раза сказал: "Докажи, что его следовало добавить в VP_8_". Потому что для VP9 нужны ресурсы, нужно время, он появится позже, его нельзя выкатить в момент выхода VP8. > Ссылки на данные 2014 года - это прекрасно, конечно. Но не факт что актуальный state of art. Это типа доказательство, что выбор прогрессивного режима JPEG с тех пор стал увеличивать размер, а не уменьшать? [1] https://encode.su/printthread.php?t=3397&pp=30&page=9
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #94

91. Сообщение от Аноним (55), 28-Фев-25, 04:28	+/–
> А эти мелочи легко поправить. Типы - да, а порядок байт заморозили в спецификации. > Тут скорее алгоритм сжатия изобрели, а реализацию допиливают. Он мал и красив, хоть на стену вешай, следует принципу "совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать". > TGA я давно не видел, лет 20-25 :) Текстуры. TGA - это скорость из-за примитивного RLE. А QOI целится и попадает (как по скорости, так и по эффективности) между - RLE - Deflate, LZW "I found the space between RLE and LZW to be large enough to spend many days on"[1]. Но достаточно ли ниша велика, чтобы создавать новый негибкий формат? Косвенная польза от QOI в том, что народ стал ориентироваться на результаты QOI (автор хорошо поставил себя, про QOI услышали все), стал задаваться таким вопросом и пилить быстрые кодеки PNG. Говорят[2], можно побить QOI с помощью быстрых режимов JXL. [1] phoboslab.org/log/2021/11/qoi-fast-lossless-image-compression [2] cloudinary.com/blog/jpeg-xl-and-the-pareto-front
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #92, #93

92. Сообщение от Аноним (55), 28-Фев-25, 04:42	+/–
> Говорят[2], можно побить QOI с помощью быстрых режимов JXL. Говорят только о кодировании и на 8 потоках. "2.7 times as fast", то есть на 1 потоке (чтобы сравнение с QOI было честнее) JXL может быть до 3 раз медленнее, смотря как он параллелится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

93. Сообщение от Аноним (-), 01-Мрт-25, 08:14	+1 +/–
>> TGA я давно не видел, лет 20-25 :) > Текстуры. TGA - это скорость из-за примитивного RLE. А QOI целится и > попадает (как по скорости, так и по эффективности) между > - RLE > - Deflate, LZW TGA это таки тоже формат-контейнер с несколькими вариантами начинки. Бывает и совсем без сжатия. В основном потому что простой в разборе формат. В таком виде это достаточно минимальный хидер да массив пикселей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #96

94. Сообщение от Аноним (-), 01-Мрт-25, 19:16	+/–
> Разница между комментариями в 2 минуты, в другом комментарии та же манера > расставлять тире и говорить "264", Вариантов написания "264" у лично меня несколько, без явного предпочтения. > это твой комментарий. Так делать подло, как и отказываться признавать ошибки. Я понимаю что кругом заговор, но отдуваться за другого анона мне не с руки. Быть с ним на 100% согласным я тоже не обязан, ВНЕЗАПНО! Отдуваться за тезисы прерогатива их носителя. > И повторюсь: посмотри, что ты делаешь. Вместо доказывания своих тезисов > уводишь разговор в сторону, тонешь в частностях. См. выше. В частности вы упорно пытаетесь меня заставить доказывать тезисы которые я не выдвигал. Я другой анон влезший в середину дискуссии. Это так сложно понять? Поэтому в чем-то с тем аноном я согласен, а в чем-то нет. > "(никто же не предлагал убрать режим из AV1)", ты точно мне отвечаешь? Я вроде вообще ЭТО не говорил. Это моя цитата? Нельзя ли цитировать мое сообщение, нормально, in line? Чтобы было понятно где я ЭТО вообще сказал? >> compression.su > Форум называется encode.su. Блин, да, именно он. На нем одно время довольно плотно перемывали косточки jxl/avif/etc и насколько я запомнил из дискуссий, AVIF довольно сильный контестант, который как минимум здорово делает JPG во многих lossy номинациях. А когда некто начинает сравнивать lossless для "DCT-like" кодеков и тому подобное VS png (zlib) я понимаю что они не рубят в топике. Сильно разные по свойствам алго. Конечно на энной картинке можно говорить что такой-то сделал ее лучше. Но результат может сильно варьироваться в зависимости от содержимого картинки, и этот нюанс почему-то продалбывается. > ...выбран в качестве "безальтернативного" кодека в Chrome по политически мотивированным > причинам[1]. Ну, это была не моя идея вспоминать про encode.su. Думаю что не политически-мотивированным а прожект-манагерским. Ибо тащить в здоровый проект еще эн либ такое себе. А так - таки - ISO себя сильно дискредитировал в опенсорсной среде, крайне недружественнвыми, околокоррупционными действиями. Типа подмахивания OOXML майкрософту или > "it should be clearly obvious, to anyone in the know, what they're > trying to do. What I don't know is why they bother" Если у кого память короткая, я напомню что за ISO в целом числится довольно много подмахов коммерческихм интересам мегакорп и патентным троллям - в ущерб всем остальным, под эгидой якобы-стандартизации. По моему, "патентованный стандарт" это вообще маразм или даже эталон коррупции из палаты мер и весов. ИМХО или уж патентованное - или уж стандарт. А тут прям новый уровень дна с узаконенным вымогательством пробивается. А еще если у кого память короткая, я напомню что Fraunhofer и Apple - весьма шкурно заинтересованные в плане патентов entity. И те и другие закатали чертову кучу патентов на аудио и видео и ISO обслуживает интересы каких-то таких. > is getting increasingly hard to believe that this was a data-driven > decision and not a politically motivated one." Да, а давайте-ка мы эти же стандарты суждения применим - к ISO и их активности? Как они там патентных троллей и мегакорпов ублажали, не? И тут вдруг случайно оказалось что есть спрос - на что-то иное чем вот этот вот позор стандартизации, более сбалансированное в целом, и с учетом интересов имплементеров технологий, а не так что куча патентной троллоты ставит всех на бабки и мы им "должны" на ровном месте. Исо сильно дискредитировал себя в этом аспекте. Очень коррумпированная организация в последнее время. Я понимаю что их picture expert group есть поводы быть недовольными, они там наименее зашварившиеся из всех. Но у исы глобальная проблема с ценностью их стандартов и как они их делают, имхо. Не надо такие стандарты на этом глобусе, делаемые вот так, имхо. В AV1 на этом фоне вписались практически все топовые чипмейкеры. Те кто и делает технологии в конечном итоге! > Это ты свои мысли связать не можешь. Я два раза сказал: "Докажи, > что его следовало добавить в VP_8_". Потому что для VP9 нужны > ресурсы, нужно время, он появится позже, его нельзя выкатить в момент выхода VP8. Ну так раз добавили - и обозвали VP9 - значит вдолгую все же - следовало. А на момент девелопа VP8 компы были хилее, качественный контент и все такое были еще в диковинку, и рубался он с чем-то уровня xvid и MP4/simple, ну может самым baseline вариантов H264 каким. Но вообще прибивать на гвозди YUV subsampling без mandatory 4:4:4 было ошибкой уже тогда, ибо гарантия что например скрины с компов - иногда будут зашакалены, сугубо из-за subsampling цветовой составляющей. Бывает весьма фатально на резких границах, тексте и тому подобном. И в этом месте webp вообще не может сделать visually perfect картинку ни с каким набором параметров. Так что следовало ли добвить? ИМХО - однозначно. Особенно если именно webp хотелось заняться. Я считаю что webp был слишком рано релизнут - надо было лучше сархитектить, более расширяемо и на основе VP9, который в массы пошел не сильно позже. > Это типа доказательство, что выбор прогрессивного режима JPEG с тех пор стал > увеличивать размер, а не уменьшать? Ну я так, попробовал на разных файлах. То что там мозилла намеряла на своей либе - это примерно как макйрософт нам расскажет что windows server обгоняет Linux. А сами линуха юзают в хвост и гриву уже при том :) > [1] https://encode.su/printthread.php?t=3397&pp=30&page=9 Тем не менее, я могу понять нежелание гугла иметь какие-то дела с лишними либами вообще - и особенно всем что исходит от ISO - в частности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #95

95. Сообщение от Аноним (55), 02-Мрт-25, 02:11	+/–
> Я понимаю что кругом заговор, но отдуваться за другого анона мне не с руки. > Я другой анон влезший в середину дискуссии. > Поэтому в чем-то с тем аноном я согласен, а в чем-то нет. Ты начал ссылаться на других анонов ещё в тот момент, когда я отвечал на единственный твой комментарий (до этого в ветке идёт сообщение Ivan_83). Сегодня есть оправдание - весна началась. Могу с любой из твоих личностей поговорить... Я тогда ответил, что дополнительные источники можно взять и попросить, а не разбрасываться сгоряча словами "nitpicking бестолковый" и "наброс"[*], а ты в ответ: "Что за просьбы? Если что, анонов бывает - более 1. По моему это претензия - не по адресу". > Я вроде вообще ЭТО не говорил. Это говорил я. Пусть лучше одна личность будет отвечать... > и насколько я запомнил из дискуссий, AVIF довольно сильный контестант, который как минимум здорово делает JPG во многих lossy номинациях. Если обычный JPEG, то форумчанин Jon Sneyers в своих сравнениях[1][2] на cloudinary.com находил у AVIF большой отрыв на низких настройках качества, а в остальных случаях до -25% размера файла. "At JPEG bitrates above 1.22 bpp (which covers about 75% of the JPEG images on the web), the advantage of AVIF (or at least this AVIF encode setting) over libjpeg-turbo seems to be less than 25%. The gain gets smaller at higher bitrates."[1] Слабое место в "at least this AVIF encode setting (то есть s6)", но во второй статье[2] есть s0 и jpegli вместе с mozjpeg. Если JXL, то его там считают почти во всём лучшим форматом. И ссылаются на статьи со словами "Google wants to do what's best for its own predatory interests, not what's best for the web". И припоминают попытку гугла отжать отданный в public domain алгоритм форумчанина - гугл пытался его запатентовать. > Думаю что не политически-мотивированным а прожект-манагерским. Ибо тащить в здоровый проект еще эн либ такое себе. Говорят, что она меньше 200 КБ и есть теоретическая возможность замены JPEG-либы. На форуме склоняются к тому, что "политический" мотив есть, ну как минимум чья-то большая премия. Гугл одной рукой пишет "The AVIF team encourages developers to provide feedback and suggestions on how to improve the benchmarks", а другой - говорят на форуме - игнорировал письма на этот спец. ящик. Войти в положение гугла, эпла или майкрософта всегда можно, только не нужно. Лучше разделять свои интересы и интересы корпорации. У корпораций, конечно, бывают фанаты (вон, на Intel или AMD посмотреть), но это глупые люди, они за свою лояльность ничего не получат. > Да, а давайте-ка мы эти же стандарты суждения применим - к ISO и их активности? Не давайте. Есть конкретные кодеки MPEG (не ISO в целом, ещё бы ISO/IEC 9899 сюда записать) с известными патентными проблемами, зачем на них в сотый раз отвлекаться? И есть конкретные общественно-вредные решения вроде вышеупомянутой попытки гугла отжать алгоритм форумчанина Jarek'а, который в основу JXL положили (про это ещё хотя бы не вспоминали). > могу понять нежелание гугла иметь какие-то дела с лишними либами вообще - и особенно всем что исходит от ISO - в частности. И поэтому он активно участвует в разработке JXL[3]? Ты как всегда в теме. (перечисленные там люди занимаются JXL по работе, например, Luca Versari: "Current position: Working (mostly) on JPEG XL, a new image compression format"). Похоже, между отделениями гугла нет такой согласованности как между тобой и "гуглом в твоём представлении". > Так что следовало ли добвить? ИМХО - однозначно. Списывать ли мне это тоже на весну? Предыдущий комментарий: "Вы ничерта не понимаете в разработке софта ... Как вы (не) понимаете, сначала окучивают то что 1) Просто и быстро сделать. 2) Дает при этом ломовой профит (в масштабах гугл)". На допиливание до VP9 потратили 3 года. Значит, гугл не мог терять 3 года. Захотел бы он *потом* добавить VP*9* внутрь WebP - добавил бы (как в WebM). WebP же был чисто форматом для хрома (который гугл настойчиво обновляет). Вне браузеров с поддержкой было плохо, FF и Safari до 2019-2020 - было никак. Это всё даёт большую свободу действий. > Ну я так, попробовал на разных файлах. То что там мозилла намеряла на своей либе - это примерно как макйрософт Где мозилла, а где опеннетовский аноним с множественными личностями. Прогрессивный режим всегда давал возможность уменьшить файл с "не низким" качеством (в зависимости от файла выстреливает на разном q, в среднем, наверное, от 40). Этим lossless-оптимизаторы пользуются: jpegtran, jpegultrascan, JPEGrescan, ECT. Свежий энкодер jpegli тоже по умолчанию выбирает прогрессив. Кстати, если вернуться к этому: > Для веба, где это важно, есть технологии лучше. > В вебе эту проблему [прогрессивной загрузки] решили иначе - и не особо парятся. Оно оказалось не так уж и нужно. Зачем тогда в avifenc добавили[4] имитацию прогрессивного режима? Флаг --progressive. И пытаются добавить более полноценный (--layered)? Если гугл считает фичу нужной, то опять твой тезис сводится к его бессмысленной защите. [*] ведь слова на гитхабе о lossless AVIF согласовываются и с собственным бенчмарком гугла, а ты себя зачем-то закапываешь странными ошибками. [1] https://cloudinary.com/blog/contemplating-codec-comparisons [2] https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#med... [3] https://jpegxl.info/about/contributors.html [4] https://github.com/AOMediaCodec/av1-avif/issues/102
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #97, #100

96. Сообщение от Аноним (55), 02-Мрт-25, 02:13	+/–
Покопался у себя, чаще попадается без сжатия. Оффтоп: в принципе, PNG можно использовать без сжатия для ускорения*: в Deflatе можно все блоки делать несжатыми и в энкодерах PNG так принято при -compression_level 0. Ещё бессмысленный ("потому что я могу") вариант: у FLAC то же самое достигается форсированием verbatim subfram'ов (-0 --disable-fixed-subframes --disable-constant-subframes). Говорили, что Game Maker нехорошо в QOI вляпался. "Games now use a modified version of the QOI image format with BZ2 compression" (из истории версий). Сжатия QOI оказалось недостаточно, поэтому его подпёрли с помощью bzip2, а QOI использовали в качестве простого фильтра и пятого колеса (собственное сжатие QOI должно лишь мешать в таком варианте). Ни хорошего фильтра, ни хорошего компрессора, ни расширенных метаданных, ни простоты голого QOI. И что остаётся? Мода. * на ускорение декодирования удобно смотреть так: ffmpeg -benchmark -i <in> -f null -
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

97. Сообщение от Аноним (55), 02-Мрт-25, 03:11	+/–
Вообще, JXL закрывают нишу где-то 4+ форматов, поэтому вокруг него такая драма разгорелась: - JPEG. Есть много старых JPEG, которые не будут перекодировать в AVIF и проч. во избежание generation loss. - PNG. Слабое сжатие. - WebP. Слабое сжатие, уступает в lossy и lossless. Быстрый, но JXL имеет --faster_decoding и прогрессивный режим. - AVIF. Промах с lossless-режимом, lossy не лучше JXL. GIF, APNG, WebP2, AVIF-AV2?.. Казалось бы, должно было "прорвать": появился достаточный повод уйти от форматов 30-летней давности. Заменить их на один формат и снова забыть о проблеме на 30+ лет (L - long term) весьма привлекательно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #98

98. Сообщение от Аноним (55), 02-Мрт-25, 03:31	+/–
UPD2: Déjà vu! I've just been in this place before 2023: https://www.opennet.me/openforum/vsluhforumID3/132037.html#297
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

99. Сообщение от Молодой Смузихлёб (?), 02-Мрт-25, 07:46	+/–
> Извините, но 15% экономии - это не то ради чего кто-то будет сильно убиваться. Уточнение - 15% экономии при перекодировании из JPEG и обратно _без потерь_. Это киллер-фича, позволяющая хранить JXL на сервере и при этом иметь обратную совместимость с неподдерживаемыми клиентами. Но сотрудники Гугла последовали примерам анонам с опеннета и со словами "нинужно" прибили поддержку формата, хотя они же и участвовали в разработке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #102

100. Сообщение от Аноним (-), 03-Мрт-25, 07:32	+/–
> Ivan_83). Сегодня есть оправдание - весна началась. Могу с любой из > твоих личностей поговорить... Таки, вы своими цитатами предъявляли мне нечто далекое от моих взглядов местами. Да еще с дурацким цитированием которое проблемно коррелировать с конкретным сообщением. > разбрасываться сгоряча словами "nitpicking бестолковый" и "наброс"[*] Про наброс по моему я как раз и не говорил. Не помню чтобы я оперировал такими словами в ближайшее время. А вот nitpicking - да, для меня выглядело именно так. > Это говорил я. Пусть лучше одна личность будет отвечать... А вы не могли бы цитировать как это делают остальные? Не изобретая велосипед с квадратными колесами. Только запутывает. > "At JPEG bitrates above 1.22 bpp (which covers about 75% of the > JPEG images on the web), the advantage of AVIF (or at > least this AVIF encode setting) over libjpeg-turbo seems to be less > than 25%. The gain gets smaller at higher bitrates."[1] AV1 в браузере - УЖЕ есть. Для декодирования AV1 как видео. Если он до кучи еще и картинки будет жевать - ну, зашибись, почему нет? В этом смысле 25% почти нахаляву. Т.е. делать почти нихрена не надо. И наверняка там еще немеряно места для улучшения, стандарт новый и это никто не оптимизил еще толком. А для JXL - надо отдельную либу переть. Это совсем не халявно по кодингу, майнтенансу и проч. Да еще риски на какое-то г-но с патентами наступить, iso же, известное подставами на тему, так что долго не отмоются. И при таком раскладе - выигрыш должен быть просто ломовым. > Если JXL, то его там считают почти во всём лучшим форматом. А с точки зрения практического использования... https://caniuse.com/jpegxl https://caniuse.com/avif AVIF - УЖЕ есть, ВЕЗДЕ ЗАДЕПЛОЕН. JXL - тупо нету, нигде. Даже если начать вотпрямща внедрять в хвост и гриву, сравнимый процент доступности будет годков через пять. Если повезет. Пока все с ручника снимутся в всех движках, пока браузеры отапгрейдят, с истечением LTS версий, ... > И ссылаются на статьи со словами "Google wants to do what's best > for its own predatory interests, not what's best for the web". Я б все понял, если б ISO не обслуживал интересы еще более predatory фраунгофера, эпла, MPEG LA... (это самые злые патентные тролли, если что) Но тут в лучшем случае война была равна. В хучшем - не, знаете, вот что гугол не делал так это буллинг патентами всех вокруг. Напротив, нашару даже хардварные декодеры подгоняют для продвижения формата. Что, дорогое ISO, скушали? Поэтому AV1 неполхо распостранился. И AVIF по наследству. ... > гугл пытался его запатентовать. Это о каком именно алго? > Говорят, что она меньше 200 КБ и есть теоретическая возможность замены JPEG-либы. Это все равно - вкрячивание новой либы, с новыми апями, все траблы майнтенанса и проч. Тогда как декодер AV1 в браузере уже был - для видео. Чего ему и статический I-фрейм не скормить до кучи - черт знает. > На форуме склоняются к тому, что "политический" мотив есть, ну как > минимум чья-то большая премия. Я бы скорее поверил что немало корп наелись патентованой хрени от исы и теперь за километр обходят все связанное с ними, попутно - решив что прожектменеджмент решает, а что там с экспертами случится - проблемы этих экспертов. На лично мое мнение - ISO после OOXML и H26x заслудило - извините - быть распущенным. Такие стандартизаторы, имхо, просто не требуются. Обслуга интереса патентных вымогателей - это надругательство над идеей стандартизации! > the benchmarks", а другой - говорят на форуме - игнорировал письма > на этот спец. ящик. Там вполне мог быть фирменный антиспам гугли, который успешно защитил получателя от спама :) > Войти в положение гугла, эпла или майкрософта всегда можно, только не нужно. Да, а почему ISO входит - но только для эпла, фраунгофера и еще нескольких патентных троллей? Давайте-ка уж как-нибудь посимметричнее это дело? Не хочется быть вторым сортом и платить вымогателям под эгидой стандартизации. > Лучше разделять свои интересы и интересы корпорации. Бывает так что интересы корпорации и мои интересы могут совпасть. От AV1 я хочу примерно то же что и гугл, допустим. Чем мне гугл будет плох в этом контексте? А ISO лично я имею основание не доверять вообще. Ибо референсного софта от них - как с козла молока почти, зато подстав с патентами - за десятерых подгонят. >> Да, а давайте-ка мы эти же стандарты суждения применим - к ISO и их активности? > Не давайте. Есть конкретные кодеки MPEG (не ISO в целом, ещё бы > ISO/IEC 9899 сюда записать) с известными патентными проблемами, зачем на них > в сотый раз отвлекаться? Ну хотя-бы потому что они - околотопичные. А AVIF к топику вообще - до кучи относится. Потому что тем же декодером жрется. JXL этого достоинства не имеет, а origin - та же самая гнилая оргаенизация, которой доверия мало. > И есть конкретные общественно-вредные решения вроде вышеупомянутой > попытки гугла отжать алгоритм форумчанина Jarek'а, который в основу JXL положили > (про это ещё хотя бы не вспоминали). Это вы про ANS так? И мне казалось что тот форумчанин подписывается Jarek Duda, не? Насколько я помню там основной злодей был не гугл - а таки майкрософт. Который не только пытался, но и зафигачил вроде. Но они все пойдут нахрен - на первом же разбирательстве, из-за prior art коего - навалом. > И поэтому он активно участвует в разработке JXL[3]? Ты как всегда в теме. Потому что размеры у мегакорпов такие что правая рука не всегда знает что делает левая. Если бы гуглу оно было реально надо - оно бы уже было в каждом утюге. Ну, как AV1, где даже хардварные декодеры нашару отсыпали, насколько я помню. Потому что гуглу трафик денег стоит, они и пашут как черти для его урезания, так даже нашару поработать и раздать хардварный декодер выгодно, если больше клиентов станет формат жрать, скостив сотни трафа. > понимаете в разработке софта ... Как вы (не) понимаете, сначала окучивают > то что 1) Просто и быстро сделать. 2) Дает при этом > ломовой профит (в масштабах гугл)". Это ремарка про либы AVIF VS JXL. С точки зрения реализации соотношения какие-то такие. > На допиливание до VP9 потратили 3 года. Значит, гугл не мог терять > 3 года. Захотел бы он *потом* добавить VP*9* внутрь WebP - добавил бы (как в WebM). Представляете, у корпораций иногда тоже бывают странные профаки в менеджменте. И то как webp был выкачен VS vp9 имхо - что-то из этой области. Потому что webp не поражал воображение уже на момент его выхода. И при этом не был расширяем чтобы сие починить. Это фэйл! > было никак. Это всё даёт большую свободу действий. И именно поэтому - "это фэйл". Гугло большое и уже местами неповоротливое и/или делающее странное. Webp - один из артефактов вот этого всего. Более того - у мегакорпов одно подразделение может сыграть против другого. Не со зла, просто менеджмент рулил по разному, и не заметил - на пальцах ног у коллег станцевали случайно. > Где мозилла, а где опеннетовский аноним с множественными личностями. Мозилла - в соседней новости шкварится, как черти что. Хорошо что я не мозилла, они после вон того - тоже не отмоются, не хуже исы. Ибо изначально обещали - совсем иное :) > Прогрессивный режим всегда давал возможность уменьшить файл с "не низким" качеством (в > зависимости от файла выстреливает на разном q, Видимо я кодировал на веб с достаточно заурядным качеством - ибо размер файла в вебе это все же аргумент. И вопрос лишь в том чтобы это не выглядело как ужас-ужас. А эти, с hi-dpi мобилками с дофига пикселей при мелком экране - и ужас-ужас, кстати, сожрут и не подавятся. > Зачем тогда в avifenc добавили[4] имитацию прогрессивного режима? Флаг --progressive. А я знаю? У гугли спросите. Мой пойнт основан - на наблюдениях! Я заметил - что прогрессивные жыпеги встречаю - крайне редко. Может на каких-то сильно отдельных ресурсах оно и не так, но в среденм по вебу... не вижу завалов прогрессивных жпег. На заре в эпоху диалапа - да, кто-то парился, сейчас - все забили. > то опять твой тезис сводится к его бессмысленной защите. Бессмысленно - спорить с наблюдаемыми фактами. Если я озвучил мои наблюдения - что вы мне пытаетесь доказать? Что меня глючит и програссивные жыпеги - в вебе везде? А где это "везде" обитает? Ибо я знаю чем это на вид отличается. И таки - редко вижу прогрессив. И хрен с ним - ща не диалап чтобы париться этим. Там еще имело с мысл, срубить скачаную на 50% картинку - экономило малость времени.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #101

101. Сообщение от Аноним (55), 03-Мрт-25, 15:44	+/–
Это скучный и фанатичный троллинг в основном, уж извините-с. Например: 1. ~20% на lossless-пережатии JPEG не нужны 2. при выигрыше в -20% AVIF не нужен (JPEG устарел как "Xvid", выигрыш должен быть гораздо больше) 3. Если AVIF даёт лишь -25% относительно JPEG (что подозрительно) - это прекрасно Какие-то хаотичные метания от комментария к комментарию. Или вот это "ВЕЗДЕ ЗАДЕПЛОЕН". Да, это известно. Но если смотреть в будущее, то там будет AV2, который уже добавили в libavif. У него, как у JXL, поначалу будет плохая поддержка. И что? Или бесконечная война в комментариях с ISO. Она не мешает ютубу отдавать H.264. Принимать стримы в H.265. Не помешала гуглу применить MPEG-ный HEIF в качестве контейнера для AVIF. Тут в комментариях - личная неприязнь к ISO. А у гугла - лишь умение зарабатывать деньги. Или отсылки к сложности поддержки лишней библиотеки вместе с отрицанием "политического мотива" (по-моему, одно исключает другое). Гугл почему-то не мог назвать упрощение поддержки в качестве причины отказа в 2022, он называл другие странные причины. Или "совпадение интересов" в контексте поддержки JXL. Интерес помешать мне пользоваться пережатыми без потерь жипегами?.. Или интерес в который раз попытаться перевести разговор на что-либо другое?.. Или якобы нерасширяемость WebP. "Note: Older readers may not support files using the extended format." "Note: Older readers may not support files using the lossless format." Как его тогда, блин, дважды расширили? > Это о каком именно алго? > ... > Это вы про ANS так? И мне казалось что тот форумчанин подписывается Jarek Duda, не? Скучно проверять (а форум очевидно слишком тесен для двух Яреков из Кракова)? Мне тоже становится скучно отвечать. > Бессмысленно - спорить с наблюдаемыми фактами. Ну вот наблюдаемый факт - гугл нашёл для себя смысл в прогрессиве у AV1 и тратит на него человекочасы. Для JPEG очевидный смысл в эффективности сжатия, несколько процентов пригодятся. Посмотрел*, tumblr и pinterest вроде всегда используют. Устроить возвращение в эпоху диалапа несложно. Ещё некоторый плюс в простоте: когда прогрессивная загрузка реализуется сама, без передёргивания картинок джаваскриптом - это хорошо для маленьких сайтов и для статических сайтов. И как мысль "ща не диалап чтобы париться" сочетается с "есть технологии лучше / решили иначе" в предыдущих комментах - это же про нужность решений на JS? * magick identify -format %[compression]-%[interlace] $_ "JPEG-JPEG" == прогрессивный жипег "JPEG-None" == не прогрессивный жипег
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #103

102. Сообщение от Аноним (-), 03-Мрт-25, 18:57	+/–
>> Извините, но 15% экономии - это не то ради чего кто-то будет сильно убиваться. > Уточнение - 15% экономии при перекодировании из JPEG и обратно _без потерь_. И, собственно, что? Для серверов вопрос сводится скорее к... 1) Какой процент трафика будет сэкономлен В ЦЕЛОМ. 2) Нагрузка на сервер взамен и результирующие косты. Если 15% можно отыграть нашару - ЗБС. Но оно, таки, не на шару в контексте серваков. > Это киллер-фича, позволяющая хранить JXL на сервере и при этом иметь > обратную совместимость с неподдерживаемыми клиентами. Это - жранье проца на сервере. На ровном месте. Всегда. Везде. Потому что согласно caniuse.com неподдерживаемые клиенты - ЭТО ПОЧТИ ВСЕ. И это быстро не изменится. Значит - будет грузить сервак оптом. А вот это уже вопрос - надо ли оно ради 15%. Де факто придется хранить 2 формата чтобы это избежать. > Но сотрудники Гугла последовали > примерам анонам с опеннета и со словами "нинужно" прибили поддержку формата, Значит не увидели достаточно бенефитов от этого в итоге. Было б оно им критично - уже внедрили бы везде. Как AV1 с видео. Вот оно им да - надрываются конкретно, даже хардварные декодеры даром раздают. > хотя они же и участвовали в разработке. А они его когда-то активировали по дефолту? CanIuse по этому поводу - извините, красным красно. Т.е. эта фича никогда не была доступна в вебе нормально. О чем мы говорим?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

103. Сообщение от Аноним (-), 03-Мрт-25, 19:53	+/–
> Это скучный и фанатичный троллинг в основном, уж извините-с. Тут вы правы, имхо. Ибо если кто мне предъявляет чужие точки зрения, при неумении или нежелании нормально цитировать - очень похоже на ЭТО. > 1. ~20% на lossless-пережатии JPEG не нужны А куда и как это потом использовать на практике? Например с точки зрения сервака - экономия будет где и на чем? Так, глядя на caniuse.com? И сравнив с avif там же, ога. А с точки зрения девов браузера это +1 либа, ни для чего иного не юзавшаяся. > 2. при выигрыше в -20% AVIF не нужен (JPEG устарел как "Xvid", > выигрыш должен быть гораздо больше) Жыпег древний, уже оптимизировали все что можно. AVIF только начинает путь. Представляете, был момент когда XVID жал лучше чем (ранние) H.264. Вдолгую он, конечно, продул. Coding tools меньше. Сначала 264 имел репутацию тормозного и бесполезного формата. Изменилось в основном благодаря x264. И тут можно уже поговорить кому на самом деле надо денег давать! "Кодек это 10% спеки и 90% реализация" (c) какой-то дев кодеков. Так патентную шушеру пора на мороз, а потоки денег - разработчикам кодеков. AOM к этому ближе чем патентные стригали исы, на уровне организации. Иса вообще либы и референсы по сути не делает в потребном виде. > 3. Если AVIF даёт лишь -25% относительно JPEG (что подозрительно) - это прекрасно Поскольку либа уже была для декодирования видео, то с точики зрения браузера почти не надо изменений. А с точки зрения сервака... ну... 95% уже могут это, можно подумать о деплое технологии. Каждый 20-й недовольнй - многовато, но уже на грани приемлимости. Для видео допустимо прессовать активнее: платить за чужие скачки жирных видео "из своих" - никому не хочется! И если можно траф в пару раз урезать - вы, таки, прожметесь. Или не посмотрите мувик. Или нате мутный 360p fallback. Кинуть кость чтоб саппорт не рвали, во! > Какие-то хаотичные метания от комментария к комментарию. Скорее, смотрение на метрики в реальном мире и делание выводов. А еше я умею в софтострой и понимаю как там принимают решения: "best it mortal enemy of good enough". > Или вот это "ВЕЗДЕ ЗАДЕПЛОЕН". Да, это известно. Но если смотреть в > будущее, то там будет AV2, который уже добавили в libavif. У > него, как у JXL, поначалу будет плохая поддержка. И что? Когда caniuse покажет 95% AV2 и AVIF2 - можно будет рассматривать идею деплоя серьезнее чем "потрындеть на форуме". И то взвесив бенефиты VS затраты и головняк. > Или бесконечная война в комментариях с ISO. Она не мешает ютубу отдавать H.264. Ну так он уже устарел, даже патентные тролли утратили задор. А fallback для древних телевизоров с ютубов - надо. У них AV1 не отрастет! И проц - хилый! Но они уже часто оставляют только муть в 360p, сказать что видик не играется - не сможете. Хочется лучше? Умейте VP9 или AV1! > Принимать стримы в H.265. Не помешала гуглу применить MPEG-ный HEIF > в качестве контейнера для AVIF. Он вообще как я понимаю - не AVIF и не HEIF, а ISO BMFF в девичестве. Весьма генерик штука. AV1 в него тоже кладут. И собссно что? ISO и такое комбо стандартизовали, во. С точки зрения парсера - ему пофиг что в BMFF напхали! Это декодер ЗА ним будет рюхать. И вопрос в том есть декодер или нет. Парсер BMFF уже был, для 264 @ .mp4, etc. > Тут в комментариях - личная неприязнь к ISO. А у гугла - лишь умение зарабатывать деньги. У исы хуже - умение втравливать всех в зависимость от патентных троллей, прикрываясь стандартизацией. Почему я должен симпатизировать такому абьюзу идеи стандартов я хз. > Или отсылки к сложности поддержки лишней библиотеки вместе с отрицанием "политического > мотива" (по-моему, одно исключает другое). Т.е. упрощение и удешевление своей жизни энной корпой - в политический мотив не входит? > Гугл почему-то не мог назвать упрощение > поддержки в качестве причины отказа в 2022, он называл другие странные причины. Вот ща они пойдут анонам отчитываться о причинах своего decision making. Сделают как им удобнее и дело в шляпе. Это их программа, как хотят так и девелопают. А корпы так то денег зарабатывают и что им в целом выгоднее то они и... > Или "совпадение интересов" в контексте поддержки JXL. Интерес помешать мне пользоваться > пережатыми без потерь жипегами?.. Или интерес в который раз попытаться перевести > разговор на что-либо другое?.. Я сомневаюсь что у кого-то есть именно тот интерес. А вот интерес сэкономить ресурсы на разработке, не взваливать на себя лишний майнтенанс, и решить свои проблемы за чужой счет - есть у любой уважающей себя корпы. Они денег зарабатывают, чем меньше затрат, больше профит и ниже риски - тем лучше. Остальное в эту формулу входит весьма косвенно. > "Note: Older readers may not support files using the lossless format." > Как его тогда, блин, дважды расширили? Ну вот так блин и расширили. Череж ж@пу! Теперь сравним с APNG допустим! Если ридер не понимает APNG - это по прежнему валидный PNG и вы видите первый фрейм, статично. Видите разницу. > Скучно проверять (а форум очевидно слишком тесен для двух Яреков из Кракова)? Я редко на том форуме уже бываю. Они тор не лю, и он у меня грузился 1 раз через 5. > Ну вот наблюдаемый факт - гугл нашёл для себя смысл в прогрессиве > у AV1 и тратит на него человекочасы. Это дело гугеля. А реально прогрессивных жыпегов в вебе - как-то мизер. Значит не такая уж и важная фича на практике оказалась. Была б важная и без приколов - (почти) все было бы в этом диалекте. Логика. > Для JPEG очевидный смысл в эффективности сжатия, несколько процентов пригодятся. Посмотрел*, > tumblr и pinterest вроде всегда используют. Ну я этими не пользуюсь. А наобум посещаемые сайты, включая всякие инет-магазины и проч - этим особо не занимаются. У них как максимум динамическая вгрузка более жирной версии, иногда с упреждением, XHR. > Устроить возвращение в эпоху диалапа несложно. Да неужели? > мысль "ща не диалап чтобы париться" сочетается с "есть технологии лучше > / решили иначе" в предыдущих комментах - это же про нужность решений на JS? Ну вот да, прелоадеры используют XHR. И чего? > * magick identify -format %[compression]-%[interlace] $_ Что сие за зверь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #104

104. Сообщение от Аноним (55), 05-Мрт-25, 07:23	+/–
> Ибо если кто мне предъявляет чужие точки зрения Где? > Но они уже часто оставляют только муть в 360p Интересно, где? Именно 360p. > Жыпег древний, уже оптимизировали все что можно. AVIF только начинает путь. Гениальная мысль с учётом того, что те самые примерно -20% даёт JXL@lossless_jpeg, у которое есть и другие режимы. > Представляете, был момент когда XVID жал лучше чем (ранние) H.264. Всё может быть, но с твоей репутацией без пруфов не годится. Про H.264 заговорили вроде осенью 2004 вместе с выходом бета-версии кодека от Ateme, в январе 2005 МГУ ставит Ateme на 1 место (DivX Pro 5.1.1 - на второе). > Так, глядя на caniuse.com? И сравнив с avif там же, ога. Лишь глупое злорадство, что JXL нужна поддержка в браузерах, которой нет. Она утонула. Кто это сделал? > можно будет рассматривать идею деплоя серьезнее чем "потрындеть на форуме". И то взвесив бенефиты VS затраты и головняк. А мы именно что трындим на форуме. Про AV1 - где-то с 2016. > Он вообще как я понимаю - не AVIF и не HEIF Ошибочное понимание-то вредно. HEIF основан на ISOBMFF, но контейнер AVIF - это всё же HEIF. https://aomediacodec.github.io/av1-avif/v1.1.0.html > А вот интерес сэкономить ресурсы на разработке, не взваливать на себя лишний майнтенанс, и решить свои проблемы за чужой счет - есть у любой уважающей себя корпы. И именно поэтому гугл принимает участие в разработке JXL? И как это всё относится к "Бывает так что интересы корпорации и мои интересы могут совпасть"? Рассказывать в энный раз о глубоком понимании корпоративных ценностей - это, скорее, к врачу. > Ну вот так блин и расширили. Череж ж@пу! Теперь сравним с APNG допустим! Мне серьёзно нужно объяснять разницу между добавлением анимации и добавлением VP9? Или у тебя какой-то разрушительный план на тему своей репутации? А как представляется добавление VP9 в некий "более расширяемый WebP"? Или любого нового гуглокодека в любой контейнер? Вот AV1 использует в качестве контейнера WebM, который использовался VP9 и до этого VP8. И что из этого должно следовать?.. Расширять картиночные контейнеры вообще не принято (см. PNG Development Group против APNG), но, повторюсь, речь идёт о рассвете WebP, когда на его поддержку можно было рассчитывать по сути только в одной часто обновляемой программе от создателей WebP, что даёт большую свободу насчёт расширения контейнера. > Ну я этими не пользуюсь. Скромность украшает человека. > Ну вот да, прелоадеры используют XHR. И чего? А почему тебе здесь захотелось промолчать о прогрессивной загрузке на JS, хотя выше о ней сказал: "У них как максимум динамическая вгрузка более жирной версии"? > Что сие за зверь? imagemagick же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

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

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