[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Animapcha image [@] [?]
Тема   ( ответ в 156266)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов GIF, JPG, MP4, OGV, PNG, WEBM, WEBP размером до 5000 кБ.
  • Ныне 4227 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 375
No. 156266    
Мнѣ видно (въ Firefox 83 на виндѣ).

Вамъ видно?
161 сообщений пропущено. Показаны 50 последних сообщений Развернуть все изображения
No. 161311    
h264.webp - (29.08KB, 1060×555)
161311
>>161299
Что забавно, с Opus в MP4 у PaleMoon иная история. Есть в белом списке из MP4Decoder.cpp, но не работает. Врочем, соседней функции чуть выше списка запрещается открытие H.264 с Level > 6.2, но видео покодированное с -level 6.2 Луна спокойно открывает. Видимо, тут без отладчика уже не обойтись.
No. 161312    
>>161308
Интересно наверно шутить про арч и школьников в 2021
No. 161313    
minami1.jpg - (46.72KB, 512×384)
161313
>>161312
причем лет 10 уже как поздновато, наверное.
No. 161314    
faptcha_php.png - (6.34KB, 90×50)
161314
>>161312
Да не особо.
No. 161315    
>>161313
Ну, лично у меня не было готового эпитета к персоналии, которая обладает некоторыми познаниями в линуксах, но при этом обладает странными идеями о юзабилити и вообще о комьюнити. Сказал, что первое в голову пришло.
А что, арчешкольники перевелись что ли? В принципе, это может быть собирательным образом для всех юных ойтишников, которые только начинают постигать линуксы. Вряд ли там что-то сильно поменялось.
No. 161316    
>>161315
У арчика как такового слишком уж упала популярность в этой среде за последние 10 лет, раньше эпитет "арчешкольник" имел более прямые отсылки к реальности. Правда сейчас многие школьники ставят себе блэкарч, но это как правило те же люди что и любители кали линукс. т.е. никак уже не "арчешкольники".
No. 161318    
c3db88e13308e0e4bd2bccb71502c710.png - (485.02KB, 1300×1045)
161318
>>161315
Да нет, живы и сут: у некоторых арчешкольников уже давно арчешколята появились. Арчу-то уже скоро двадчать лет исполнится: в следующем году, считай.
No. 161370    
Комментарий >>160710 нуждается въ нѣкоторой коррекции, поскольку я только что поглядѣлъ на свѣжеустановленный браузер Firefox for Android Beta (версии 89.0.0-beta.10) и убедился в том, что он по умолчанию не поддерживает AV1 (скриншот прилагаю).
No. 161372    
AV1 settings in Firefox Beta.webp - (21.33KB, 1080×1333)
161372
Вот если по адресу «about:config» включить настройку «media.av1.enabled» (как на скриншоте; обратите внимание, что значение «true» для этой настройки установлено не по умолчанию, на что указывает появление кнопки «Reset», служащей для сброса значения настройки в исходное состояние), тогда AV1 будет показывать невозбранно.

(О том же и столбец «Firefox for Android» на странице https://caniuse.com/av1 сообщает.)
No. 161384    
>>161312
>>161313
>>161318
Школьников, может, и нет, но есть определённая категория людей, которая использует арч и навязывает его остальным, выказывая явное неодобрение как в сторону пользователей винды, так и некоторых дистрибутивов линукса (типа дебиана), которые они считают неправильными. Адекватных аргументов, почему я должен использовать арч, они не предоставляют (хотя свои аргументы они считают адекватными).
То есть, если у меня не ThinkPad с установленным арчлинуксом и тайловым WM и не хочу "развиваться" (идти в сторону этого задротства), то я недалёкий человек.
No. 161385    
>>161384
Дебиан если по хорошему - не меньшее задротство ведь. Вменяемые аргументы в пользу арча с удовольствием послушал бы кстати, помимо учебных соображений.
No. 161391    
1485800204682.jpg - (358.10KB, 992×1797)
161391
  • AUR;
  • Весьма свежий софт;
  • mkinitcpio;
  • pacman;
  • arch-chroot, netctl и другие полезные скрипты;
  • Ориентированность исключительно на AMD64 (хотя есть и отдельный проект по Арчу на Arm, и другой более слабый отдельный проект для x86_32);
  • Удобная система сборки пакетов, готовая к использованию из коробки;
  • Как правило разумный выбор пакетов и их зависимостей, относительная гибкость;
  • Почти все пакеты dev версий, обычно не нужно отдельно ставить заголовки;
  • Прозрачный процесс установки;
  • Няшная, удобная архитектура;
  • Няшная wiki.
Ещё бы систему, чтобы для части пакетов репозитория патчила PKGBUILDы и автоматом нужное обновляла/пересобирала/ставила, функционируя либо как настройка над pacman, либо равноправно работая в связке с ним.

> типа дебиана
Типа Убунту.
> учебных соображений
С ними, наверное, лучше в другое место. Yocto Project и популярные на предприятиях линукса.
No. 161394    
Ikazu_Cirno_full_202517.jpg - (287.57KB, 540×710)
161394
>>161385
  • Название
  • Иконка

No. 161400    
Арч, если вкратце, это такой дистрибутив для тех, кто уже́ хорошо понимает, чего именно хочет от дистрибутива и как именно это делать; дистрибутив, который практически ничего безальтернативно не решает за пользователя кроме systemd, ага, и предоставляет удобные инструменты для решения относительно сложных задач, связанных с обустройством собственной системы. Ну и инфраструктура для публикации пользовательских пакетов. А также превосходная и непревзойдённая wiki-документация по всему этому безобразию. Там, где в Red Hat коммерческие интересы, в Debian внутренняя бюрократия, в Ubuntu заигрывание с массовой аудиторией, в Gentoo пересборка мира, в каком-нибудь Trisquel возведённая в абсолют идея, а в Slackware Патрик — в Arch здоровая прагматичность и отсутствие странных ограничений любого рода. Что и способствовало появлению всех этих >>161391 замечательных вещей!

Но разумеется, не стоит полагать, что Arch сверхуниверсален и подойдёт всем и каждому. И тем более, что в принципе может быть какой-то единственно верный способ его применения. Что за топорные карикатуры вообще? Может подойти только тем, кто желает и способен принимать многие системные решения по собственному разумению. Arch — это не дистрибутив для тех, кому неинтересно.

>>161391
> Ещё бы систему, чтобы для части пакетов репозитория патчила PKGBUILDы и автоматом нужное обновляла/пересобирала/ставила, функционируя либо как настройка над pacman, либо равноправно работая в связке с ним.
А вот здесь мы начинаем подбираться к пределам возможностей той самой архитектуры... и в этот момент можно взглянуть в сторону NixOS с её оверлеями, которые делают ровно вот это вот.
No. 161415    
>>161400
> и в этот момент можно взглянуть в сторону NixOS с её оверлеями, которые делают ровно вот это вот
Guix then
No. 161563    
Init.webp - (25.64KB, 981×623)
161563
>>161311
До чего же огромный, путанный конструкт поддержка этих видеов. Впрочем, вряд ли тут можно иначе.

Во-первых, Opus в MP4 даже не распознаётся как Opus в силу того, что MPEG4Extractor.cpp:parseChunk не знает про MP4 box с именем Opus, помимо этого Opus нет в местном списке/словаре MIME-типов.
Во-вторых, для Opus-а доступен только декодеровщик, который OpusDecoder.cpp (по крайней мере, через него реализовано чтение Opus в WebM). Но он, первое, ожидает, что заголовок Opus частично разжёван декодером контейнера, а MP4AudioInfo::Update, заточенный под AAC, делает предразжёвывание только по box-у с именем esds, который MP4/Opus не использует. Поэтому инициализация OpusDecoder вылетает по первому же if-у. Второе, инициализатор и OpusDecoder:DecodeHeader расчитывает на наличие OpusHeader и конфигурацию декодировцика в том виде, в котором она в WebM и в .opus; а в MP4 конфигурация декодировщика записана в подbox dOps; расположение данных вполне возможно несовместимо.

Из чего делаем вывод, что поддержка Opus в MP4 не реализована (для чего и откуда тогда проверка на audio/opus из dom-овского MP4Decoder.cpp?). Жалко, конечно. Хотя теоретически, если добавить в MP4AudioInfo::Update, OpusDecoder.cpp:DecodeHeader и OpusDecoder.cpp:Init MP4/Opus-специфичный код для чтения конфигурации декодировщика, оно может заработать. Так-то спецификация открыта, ещё можно попробовать нужный код у Квантума с Хромом стырить.
No. 161566    
screenshot.webp - (194.21KB, 1280×1587)
161566
Неожиданный и неприятный поворот приобретает дѣло проблемы >>160709 с такими ключевыми кадрами, на которых являются крупные (и с раздражающе прямоугольными границами) области другого, невѣрнаго цвѣта.

При виде комментариев, по адресу https://old.reddit.com/r/AV1/comments/nq2k8w/weird_blocking_issue_with_one_particular_frame_in/ расположенных (скриншот прилагаю), узнал эвона чего:

① У других людей также возникали подобные проблемы (об их подобии можно легко судить, на скриншоты https://slow.pics/c/zFnxh0Pr глядя), причём возникали также с десятибитными компонентами цвѣта (о десятибитности можно легко судить, скормив видеоролик https://ufile.io/y5hflci8 в FFprobe, напримѣръ).

② Включение параметра enable-keyframe-filtering=0 устраняет такие области невѣрнаго цвѣта, так что можно предполагать, и небезосновательно, что появление этих артефактов — ожидаемое слѣдствие от включения ключевых кадров в общий цикл обработки временны́м фильтром (то есть от enable-keyframe-filtering=1 по умолчанию), устраняющим информационную избыточность. Если же задать параметр enable-keyframe-filtering=0, то ключевые кадры останутся нетронутыми, однако возрастёт избыточность и оттого вырастет объём файла (я попробовал создать аналог видеоцитаты >>/a/17101 с этим параметром и получил рост объёма файла на 0,8%.)

③ Несмотря на очевидность происходящего (параметр задал — ключевые кадры починил) мнѣ всё же трудно повѣрить, что временнóй фильтр должен именно так работать: сосѣдніе-то кадры не так разительно отличаются от ключевого, как результат фильтрации отличается от оригинала ключевого кадра. Может ли простое (и безошибочное) устранение информационной избыточности вызвать так сильно бросающийся в глаза эффект? — казалось бы, никоим образом не может! Возможно, всё же баг.

④ Если читать пособие по параметрам кодировщика, то становится видно, что тому же параметру можно придать и значение enable-keyframe-filtering=2, при котором ключевой файл всё же подвергается временнóй фильтрации (чтоб объём файла не слишком распух), однако повѣрхъ него накладывается дополнительный слой коррекции внесённых артефактов. В результате тот же видеофайл распухает всего ничего — на 0,09%.

⑤ Но если вслѣдъ за этим https://bugs.chromium.org/p/aomedia/issues/detail?id=2862 также прочитать, то сразу приходится охѣрѣть от того, что поддержка результатов работы enable-keyframe-filtering=2 настолько не реализована в просмотрщиках, что ни в одном браузере и ни в одном видеопроигрывателе такой видеофайл не удаётся нормально промотать к желаемому мѣсту, а только смотрѣть с сáмого начала.

Ѽ, етить.
No. 161568    
>>156273
Только что свичнулся с FF на palemoon, подтверждаю фичу.
No. 161582    
highbd.webp - (28.40KB, 1009×554)
161582
AV1 в 10 бит работает, а VP9 в 10 бит нет. Как же так? Открываем AOMDecoder.cpp и видим там вот такое вот. Открываем FFmpegVideoDecoder.cpp, которым на моих линуксах производится декодирование, и видим во-первых, как бы whitelist из 8bpc цветовых форматов, во-вторых, не видим никакого кода, который конвертировал бы кадр в 8-bit'ный: идёт прямое приравнивание цветовых плоскостей, декодированных FFmpeg-ом к оным у выходного YCbCrBuffer.

Стало быть, если вставить в тот файл костыль как из AOMDecoder.cpp, оно корректно заработает. У AOMDecoder оно в виде отдельной небольшой функции highbd_img_downshift, которую легко адаптировать под AVFrame-ы. Никаких AVX-ов c SSE в коде том нет, но работает достаточно быстро, чтобы на моём далеко не самом быстром проце Мицголово видео не тормозило. Ещё можно попробовать добавить заголовки libavfilter и задействовать фильтр colorspace, то бишь средставми FFmpeg решить проблему.

А по-хорошему, стоит не заниматься двойной обработкой кадра yuv10bit → yuv8bit → rgb, а до- и перепилить YCbCrBuffer и связанное, чтобы оно поддерживало 10bit-ные палитры и могло конвертировать кадры с ними напрмямую в RGB. Хотя ещё по-хорошему… там местами становится понятна мотивация Мозилы перейти на Квантум, скажем так. Если Квантум то, что я думаю, конечно.

Печальная ситуация с поддержкой медиа, видимо, следствие стратегии сделать хоть как-то, чтоб работало на первое время, потом ни в коем случае не вспоминать, потом ужаснуться, обнаружив объём полезного кода и костылией, завязанных на это работающее хоть как-то.

>>161568
Можно сделать вывод, что на полноценно тянуть браузер у PaleMoon, к сожалению, не хватает человекочасов; со всеми вытекающими. Ещё, судя по всякому разному, они отсекают людей, которые могли бы это потенциально изменить, или вообще пользоваться проектом. В самом свежем релизе вот выпилили поддержку старых FF дополнений, которые не пилятся конкретно под PM, например. Так что, возможно, свичнусь обратно. Хотя бы на ребрэндированный GNUшниками FF, особенно если там загрузку Pixiv-а починили.
No. 161586    
screenshot.webp - (77.91KB, 1920×1080)
161586
При виде подтверждения того, что проблема >>161566 не у одного меня возникает при кодировании видеозаписей AV1 с десятибитными компонентами цвѣта, невольно приходится задаваться вот каким вопросом: а точно ли эта проблема ограничивается одними только десятибитными видеозаписями? — может ли быть, что она и в традиционных видеозаписях TrueColor также возникает?

Посмотрѣвъ рядъ примѣровъ, приходится непріязненно констатировать, что только одно это и может быть.

В частности, в видеоцитате >>/a/17100 именно такой (квадратиками похѣрившійся) ключевой кадр нетрудно отыскать не далѣе, чѣмъ на ѿмѣткѣ времени 00:03.009 (скриншот прилагаю).

Я подумал над этим, подумал, да и пошёл добавить «-aom-params enable-keyframe-filtering=0» во всѣ, во всѣ командныя строки для FFmpeg в моих пакетных файлах, AV1 создающих. И добавил.

Ужасно то, насколько обнаруженная проблема противорѣчитъ моему же непосредственному опыту, но обретённому лѣтъ двадцать тому назад. В тогдашних видеофайлах, особенно при сильном кодировании их (происходящем от желания засунуть нѣсколько видео на один DVD), очень частою была та ситуация, когда самым красивым из всѣх видеокадров в одной и той же кадровой группе был ключевой кадр, а послѣ него остальные кадры становились всё хуже и хуже (потому что алгоритм видеокодирования экономил мѣсто на их качестве), но затѣмъ начиналася новая группа кадров, и первый из них, будучи ключевым, рывком возвращал качество к прежнему, болѣе высокому, уровню, с которого вдругорядь начиналася постепенная деградация.

Теперь же получается, что алгоритм экономит на качестве ключевого кадра, стремясь каким-то образом (по-видимому, наложением временнóго фильтра — это что же, усреднением по времени?) достигнуть того, чтоб дальнѣйшіе (разностные) кадры в кадровой группе не слишком-то ѿличалися и не принуждали кодировать болѣе значительные ѿ него ѿличія. И в этом занятии кодировщик так увлекается, так похѣриваетъ ключевой кадр, что приходится выключать это намѣреніе, чтобы зрителю по глазам во время просмотра, наподобие миѳическаго малозамѣтнаго «двадцать пятаго кадра», не ударял бы ключевой кадр пониженного качества.

До этого времени я много раз думал: вот, с 2018 года (болѣе трёхъ лѣтъ!) существует видеоформат AV1, а через год (в 2019 году) формат его ключевых кадров окончательно приспособили для ѿдѣльнаго хранения графических данных (создали версию 1.0 формата AVIF в феврале 2019 года), так почему ж не существует ещё (ни в FFmpeg, ни ѿдѣльно) таких средств или утилит, которые позволяли бы вытащить из видео AV1 очередной ключевой кадр и без внесения дополнительных потерь пересохранить в AVIF?

Оказывается, этот образ мыслей — опять же из нулевых лѣтъ, а в третьем десятилѣтіи XXI вѣка ключевые кадры по умолчанию (без параметра «-aom-params enable-keyframe-filtering=0») выглядят так гадко, что никому «без дополнительных потерь» не нужны, так как в них и без того потерь дохѣрищща.

Ѽ, етить-колотить.
No. 161588    
>>161586
Не знаю как там оно с AV1, но у VP9 при кодировании только по CRF оно лечится примерно такой конфигурацией с двумя проходами.
-deadline best -threads 1 -speed 0 -tile-columns 0 -frame-parallel 0 -auto-alt-ref 1 -lag-in-frames 25 -aq-mode 0
No. 162149    
Поклонникам AV1 рекомендую безъ малѣйшаго промедления обратить внимание на содержимое тѣхъ измѣненій въ кодѣ у кодировщика libaom-av1, которыя по адресу https://aomedia.googlesource.com/aom/ /165793458d52bc3d60618137b07fda921c3b4af9 показаны.

Силою этих измѣненій любая сколько-нибудь свѣжая сборка FFmpeg позволяет внести в командную строку, для кодирования AV1 употребляемую, слѣдующія двѣ благотворныя перемѣны:

① Указание параметра «lag-in-frames» может быть увеличено до величины «-lag-in-frames 48» вмѣсто прежняго максимума «-lag-in-frames 35». Это позволяет кодировщику анализировать наперёд ещё больше кадров (двѣ секунды по 24 кадра в секунду в случае аниме) и обеспечивать ещё болѣе эффективное соѿношеніе качества и объёма видеофайла.

② Параметр «-aom-params enable-keyframe-filtering=0» (необходимость которого в сообщении >>161586 обосновывается) можно дополнить до вида «-aom-params enable-keyframe-filtering=0:enable-tpl-model=1». Я только что провѣрил эффект от этой перемѣны в командной строке (сравнительно с той командной строкою, которая подверглась только «-lag-in-frames 48» и «-aom-params enable-keyframe-filtering=0») и на примѣрѣ видеоцитаты >>/a/17106 увидѣлъ одновременно и рост качества (измѣряемого по объективному показателю VMAF), и уменьшение объёма итогового видеофайла (хотя и не очень большое, всего на 0,05%).

Сочетание же того и другого параметра я провѣрилъ на примѣрѣ видеоцитаты >>/a/17124 и увидѣлъ, что рост качества сопровождается ростом объёма получающагося видеофайла на 2,51%.
No. 162166    
>>162149
Как давно у Вас AV1? Можете описать симптомы?
No. 162167    
>>162166
Я чувствую непреодолимое желание кодировать видео и вступать в беседы о достоинствах того или иного видеокодека. Я ощущаю необходимость использовать AV1 для всех моих видео.
No. 162170    
>>162166

Или как скажешь брату твоему: «дай, я выну AV1 из глаза твоего», а вот, в твоём глазе JPEG?
No. 162175    
>>162170
> webp
No. 162721    
Всё ещё неизмѣримо хуже, чѣмъ я предполагал первоначально.

На примѣрѣ видеороликов https://410chan.org/a/src/162565496252.webm и https://iichan.hk/a/src/1625554395668.mp4 мнѣ удалось установить, что упомянутый в сообщениях >>161112 и >>161148 баг (проявляющийся как появление ключевых кадров в неподходящих мѣстахъ, а именно за группою визуально подобных им промежуточных кадров, а не предъ нею) возникает не только в десятибитных цитатах из аниме, но и в восьмибитных также.

Я очень глубоко скорблю.

Получается, что безполезно даже быть готовым пожертвовать ꙫчевидными достоинствами десятибитныхъ видеороликовъ (напоминаю ранѣе упомянутые итоги тестированія, по адресу https://old.reddit.com/r/AV1/comments/i6o5l0/aomenc_parameters_benchmark/ выложеннаго: переход ѿ восьмибитности къ десятибитности приводит к тому, что видеофайлы AV1 получаются меньше на ≈3%—6½% при равномъ показателѣ VMAF): такая жертва всё равно не позволит избѣгнуть этого бага.

Получается, что во имя болѣе высокаго качества надо всё же изготавливать десятибитные AV1 и притом ещё долго, долго, мѣсяцъ за мѣсяцемъ (пока не починят) мириться съ тѣмъ, что часть AV1 псевдослучайным образом оказывается забагованною и высокаго качества не достигает.

Ѽ безысходность!
No. 163021    
боль-печаль.webp - (2.47MB, 3840×2160)
163021
>>163015
Всё-таки моя кофеварка уже слабовата для современного мира. 4k видео не тянет. Хотя 4k, в HEVC с VP9 закодированное, быстрее декодирует, при этом всё равно в real-time не укладываясь.
No. 163115    
>>163021

У меня во браузере (Mozilla Firefox 90.0.2) тормозит, а в видеопроигрывателе (Media Player Classic Home Cinema) не тормозит.

Это означает, что рано или поздно перестанет тормозить и во браузере, когда браузеростроители обновят встроенный декодировщик.
No. 163241    
screenshot.webp - (170.31KB, 1280×2440)
163241
Может, конечно (да и должен, навѣрное), напрашиваться такой вопрос: а когда упомянутое в сообщении >>163115 событие произойдёт, то есть когда в Firefox (да и в другие, много болѣе распространённые браузеры, которые на гуглохромовой основе в отличие от него) добавят декодировщик dav1d новой версии, способной достаточно быстро декодировать 4K AV1 с десятибитными компонентами цвѣта?

Оказывается, не так-то просто выяснять это.

В гуглохромовом коде обновление dav1d обычно выглядит как появление подобных https://chromium-review.googlesource.com/c/chromium/src/ /2900797 наборов измѣненій, в которых только словá «On the road to 0.9.0» в комментарии к одному из коммитов могут указать, что рѣчь идёт о версии 0.9.0. Много проще ориентироваться на появление страниц, https://old.reddit.com/r/AV1/comments/nf2jos/dav1d_090_merged_into_chromium_will_be_in_chrome/ подобных, в сабрэддите AV1.

В файерфоксовом коде, если просто зайти в Багзиллу и запустить быстрый поиск по слову «dav1d», то с адреса https://bugzilla.mozilla.org/buglist.cgi?quicksearch=dav1d произойдёт перенаправление на адрес https://bugzilla.mozilla.org/show_bug.cgi?id=dav1d и сдѣлается видно, что внутрибагзилловый идентификатор «dav1d» отдан багу трёхлѣтней давности о переходе на dav1d. Болѣе результативным оказывается поиск по словам «update dav1d», позволяющий обнаружить цѣлую цѣпь багов, каждый из которых помѣченъ как зависящий от предшественника: баг https://bugzilla.mozilla.org/show_bug.cgi?id=1720177 об обновлении dav1d в Firefox 92 помѣченъ как зависящий от бага https://bugzilla.mozilla.org/show_bug.cgi?id=1716453 об обновлении dav1d в Firefox 91, а тот — как зависящий от бага https://bugzilla.mozilla.org/show_bug.cgi?id=1700452 об обновлении dav1d в Firefox 90, и такъ далѣе.

Въ наиболѣе недавних двух из этих багов даже является бот, перечисляющий коммиты dav1d, о которых идёт рѣчь, но также не очень ясно, о каких конкретных версиях dav1d идёт рѣчь; но на сей раз в сабреддите AV1 никакие страницы разъяснений никто не трудится создавать (видимо, руководясь сознанием пренебрежимой малости числа пользователей браузера Mozilla Firefox), так что и такого ориентира ужé нѣтъ.

Въ цѣломъ создаётся такое впечатление (и это впечатление я считаю совершенно вѣрно отражающим дѣйствительное положение дѣлъ), что при появлении новой тестовой версии браузера (тестовый Chrome называется словом Canary, тестовый Firefox называется словом Nightly) туда засовывают всѣ недавние коммиты dav1d (нисколько не глядя на то, достиг ли dav1d новой версии или же это промежуточные коммиты), после чего чаще всего ничего ужé не добавляют при переходе от тестовой версии к бета-версии и к релизу, так что от обновлений dav1d до появления этих обновлений во браузерах проходит примѣрно два цикла разработки.

Firefox использует полуторамѣсячный цикл разработки (версия 88 вышла в середине апрѣля, версия 89 вышла 1 июня, версия 90 вышла в середине июля), так что dav1d в релизе браузера примѣрно на три мѣсяца отстаёт от недавнего.

Chrome (как по адресу https://www.zdnet.com/article/google-to-shorten-chrome-update-cycle-to-four-weeks/ говорится) планирует в третьем (нынешнем) квартале 2021 года перейти на четырёхнедѣльный цикл разработки, а до тѣхъ пор использовал также шестинедѣльный (полуторамѣсячный).

Соѿвѣтственно, видя по адресу https://code.videolan.org/videolan/dav1d/-/commit/1ff26cd7fc8cf9bd8fa351a4a9311bf633775226 в конце июля выпуск 0.9.1 кода dav1d (содержащего, как это по адресу http://www.jbkempf.com/blog/post/2021/dav1d-0.9.1-a-ton-of-asm говорилось 1 августа, охѣрительное количество ассемблерных вставок для почти окончательного существенного ускорения работы десятибитных и двенадцатибитных компонентов цвѣта в AV1 на всѣхъ платформах наконец, так что многолѣтній проект dav1d почти завершён; скриншот прилагаю), можно ждать внедрения его в релизах браузеров примѣрно к концу октября или в сáмом начале ноября — а если Chrome ускорит свой цикл разработки, то и к началу октября управится — но ранѣе того ничего не будет.

Это и есть ѿвѣтъ на вопрос, названный напрашивающимся в начале моего сообщения.
No. 163447    
screenshot.webp - (92.00KB, 900×786)
163447
>>163241

> Firefox использует полуторамѣсячный цикл разработки (версия 88 вышла в середине апрѣля, версия 89 вышла 1 июня, версия 90 вышла в середине июля)

Эту оцѣнку, тут 5 августа высказанную, слѣдует перемѣнить теперь на нѣсколько болѣе оптимистическую ввиду того, что 10 августа по адресу https://www.mozilla.org/en-US/firefox/91.0/releasenotes/ было объявлено о выходе браузера Mozilla Firefox версии 91. (Причём не просто «было объявлено» на словах, но и Firefox 91 дѣйствительно появился.)

Получается, что разработчики браузера Firefox совершили над собою усилие, необходимое для возвращения к тому четырёхнедѣльному циклу разработки, который по адресу https://hacks.mozilla.org/2019/09/moving-firefox-to-a-faster-4-week-release-cycle/ объявили начавшимся с первого квартала 2020 года.

Соѿвѣтственно, и версию декодировщика dav1d в релизе браузера слѣдуетъ считать примѣрно на два мѣсяца (а не на три) ѿстающею ѿ свѣжей версии декодировщика.

Что это означает в практическом смысле? — а вот что: так как в сообщении >>163241 я указывал, что каждое обновление dav1d в файерфоксовой Багзилле помѣчается как зависимое от предшествующего обновления, и так как в настоящее время по адресу https://bugzilla.mozilla.org/show_bug.cgi?id=1720177 то обновление dav1d, которое в Firefox 92 произошло, указано как зависящее от обновления из Firefox 91, но зато ещё не имѣющее зависящих от него самогó обновлений, то можно съ увѣренностью предполагать, что обновление кода dav1d в версии Firefox 93 ещё не произошло; стало быть, когда оно произойдёт, Firefox 93 будет содержать нынешнюю (свѣжайшую) версию dav1d, содержащую вообще весь код на языке ассемблера, по адресу http://www.jbkempf.com/blog/post/2021/dav1d-0.9.1-a-ton-of-asm восхваляемый, и поэтому Firefox 93 будет способным воспроизводить видеозаписи 4K AV1 с десятибитными компонентами цвѣтовъ, причём воспроизводить без подтормаживания и без пропускания видеокадров.

И если надѣяться на сохранение нынешнего темпа разработки, то тогда Firefox 93 появится через ≈два мѣсяца послѣ Firefox 91 (то есть в октябре), а в сентябре появится Firefox 92, содержащий (согласно опубликованному по адресу https://groups.google.com/a/mozilla.org/g/dev-platform/c/j7xbfJqVQDA/m/w3LYT85cAQAJ намѣренію, скриншот которого прилагаю) поддержку графического формата файлов AVIF (основанного на формате ключевых кадров видео AV1), работающую по умолчанию (то есть ужé не создающую никакой необходимости залазить на страницу «about:config» и править сокрытые там настройки браузера). Но всё ещё без поддержки анимированных AVIF.

Тем временем во браузере Firefox 91 даже fullHDшные видеоролики AV1 с десятибитными компонентами цвѣтовъ (>>/a/17103 и >>/a/17106 и >>/a/17111 напримѣръ) продолжают подтормаживать въ наиболѣе динамичные моменты аниме.
No. 163453    
Возможно ли AVIF кодирование, у которого lossless лучше, чем у WebP, не говоря уж о JXL? И если да, то как и чем его осуществить?
No. 163454    
screenshot.webp - (146.32KB, 1200×1041)
163454
>>163453

https://nowere.net/d/res/3070.html#5262
No. 163903    
На второй минуте четвёртой серии аниме «No Game No Life» (WebM съ десятибитными компонентами цвѣта прилагаю) Щиро называет произошедшую «революцию на шахматной доске» словом, которое на слух ну очень напоминает «майдан».

Как оно пишется по-японски?
No. 163904    
>>163903
内乱
Nairan
No. 164111    
screenshot.webp - (72.02KB, 900×620)
164111
Оптимизм >>163447 оказался неоправданным: позавчера (7 сентября) вышел новый Firefox (версия 92), но поддержку AVIF всё ещё не содержащий, так как она напоролася на своего рода «подводный камень», по адресу https://bugzilla.mozilla.org/show_bug.cgi?id=1729071#c4 упомянутый (несоѿвѣтствіе неопубликованной версии стандарта, в рамках которой, как оказалось, всё же генерируются многие файлы популярными утилитами).
No. 164138    
поддержка farbfeld когда
No. 164140    
>>164111
интересно откуда у утилит доступ к секретному стандарту если даже мозилла не смогла его оперативно получить.
(и зачем вообще мозилла пишет свой код для работы с этим мемоформатом вместо использования готовых библиотек)
No. 164143    
abydos.png - (179.49KB, 800×600)
164143
>>164138

поддержка farbfeld зачѣмъ

При чтении https://github.com/mcritchlow/farbfeld или https://tools.suckless.org/farbfeld/faq/ становится совершенно ясно, что этот формат построен на маниловщине: дескать, въ идеальномъ мірѣ архиваторы общего назначения (и, в качестве конкретнаго примѣра, там рекомендуемого — bz2) должны заниматься сжатием информации ничуть не хуже, чѣмъ тѣ специализированные алгоритмы, которые лежат в основе графических форматов.

По адресу https://github.com/ImageMagick/ImageMagick/discussions/2664 видно, что поддержку этого формата засунули в ImageMagick, а также и что по адресу https://telparia.com/fileFormatSamples/image/farbfeld/ лежит примѣръ — файл https://telparia.com/fileFormatSamples/image/farbfeld/abydos.ff

Скачиваю этот файл, вижу 3 840 016 байтов — ужé повод не поддерживать этот формат во браузерах в его сыром виде, так как громаден.

Использую 7-Zip версии 19.00 и жму этот файл в bzip2 на ультранастройках (командою «7za a -tbzip2 -mx=9 -mpass=7 -md=900000b abydos.bz2 abydos.ff») — получаю 322 775 байтов.

(Для сравнения: команда «7za a -t7z -mx=9 abydos.7z abydos.ff», также подаваемая в 7-Zip версии 19.00, порождает архив 7-Zip размѣромъ 283 089 байта.)

Запускаю ImageMagick версии 7.1.0-4 Q16 x64 2021-07-18 и подаю в нём команду «magick convert abydos.ff abydos.png» — получаю 222 588 байтов.

Обрабатываю в oxipn версии 5.0.0 в режиме Zopfli — получаю 183 793 байта (результат прилагаю).

То есть стародавний формат PNG (из второй половины девяностых годов), в который заложено использование только ещё болѣе старинного алгоритма DEFLATE (из первой половины девяностых годов) и упоминаемых по адресу https://en.wikipedia.org/wiki/Portable_Network_Graphics#Filtering предсказательных фильтров (в прилагаемом примѣрѣ — только вычитание левого пиксела) ужé достигает лучших результатов, чѣмъ bzip2 или LZMA2.
No. 164144    
abydos.webp - (138.31KB, 800×600)
164144
При использовании libwebp 1.2.1 команда «cwebp -z 9 -mt -v -progress исходный.png -o результат.webp» уменьшает файл до 141 632 байтов (результат прилагаю).

Кодировщик JPEG XL версии 0.6.0 (на основе коммита https://github.com/libjxl/libjxl/commit/2ebc6ecb37ac322da485b68f6d4fbd619fa738b5 собранный) командою «cjxl --effort=9 -d 0 -I 1 -E 3 --palette=0 -g 1 исходный.png результат.jxl» уменьшает файл до 89 900 байтов, это болѣе чѣмъ в два раза меньше PNG, даже изготовленного при посредстве алгоритма Zopfli. А уж по отношению к архиву 7-Zip файл JXL меньше на 68,24%.
No. 164145    
(Опечатка: в сообщении >>164143 записано «oxipn», слѣдуетъ читать «oxipng».)
No. 164148    
>>164143
Зато простой как три копейки, и разделение зон ответсвенности (данные отдельно, компрессия отдельно) тоже хорошо.
No. 164161    
«А давайте файлов плодить в два раза больше и сжимать в три раза хуже, потому что это хорошо!» — нѣтъ, не хорошо.
No. 164349    
161908382876.webp - (3.83MB, 2508×3541)
164349
Значится, опробовал я JXL на ≈20000 файлов, в основном анимешных, в placebo-режиме. Кодирование заняло порядка недели на одном ядре старенького мобильного i7, в результате точно было выиграно несколько гигабайтов, но строго за этим слежка не производилась. Из тех файлов для ≈800 JXL дало увеличение размера где-то на 3%, в основном это WebP (особенно screenshot-ы, но наблюдалось и на фотографиях) и мелкие (меньше 100x100) JPEGи. Стоит оговориться, что JXL поддерживает биективное перекодирование JPEGов без потерь, дающее выигрыш где-то в 15%, но зачастую и куда больше, по наблюдению. Этим оно выгодно отличается от предыдущих наследников, поскольку позволяет при необходимости получить исходный файл для использования в legacy, которое везде. Подобный же, хотя и меньший процент, наблюдался и на lossless WebP.

К сожалению, не только скорость кодирования у этой штуки умопомрачительно низка. При декодировании пережатых PNGшек time djxl $filename даёт real time в 0.3 секунды на HD (!) кадрах из аниме, 0.6 секунд на Full HD, а на high-res-ах типа этой картинки с Марисой (которые не очень-то high на самом деле) даёт 2.9 секунды. Для сравнения, на этой картинке pngcrush -force -m 1 -l 0 и dwebp дают 0.14. Так что вот, надо ли оно такое для пользователей досок с их специфичным процессом подбора нужной картинки к посту и для web-а в целом — вопрос. Может, конечно, оптимизируют, если оптимизируют, но пока оригинальный lossless формат не для кофеварок.
No. 164350    
PS JXL кодировалось с -q 100 -s 9 -E 3.
No. 164363    
>>164349

> в placebo-режиме

Вообще-то >>164350 ещё не placebo (то есть ещё не максимально долгий режим в пользу предѣльно большего сжатия файла).

① Не вижу прибавления «-I 1» к настройкам кодирования, хотя в сообщении >>164144 подавал примѣръ.

② Не вижу попыток испытывать прибавление «--palette=0» к настройкам кодирования, хотя в сообщении >>164144 подавал примѣръ. (Также ещё «--palette=4096».)

③ Не вижу попыток испытывать прибавление «-g 0» к настройкам кодирования, хотя в сообщении >>164144 подавал примѣръ. (Также ещё «-g 1», «-g 2», «-g 3».)

④ Нѣкоторые пользователи, стремящиеся вообще всё перепробовать, способны ещё на ≈порядок замедлить всё дѣло, но перебрать значения от «-P 0» до «-P 13» включительно.

> на одном ядре старенького мобильного i7

Старенькие мобильные i7 бывают разными: бывают без поддержки AVX (первое поколение i7), а бывают даже с поддержкою AVX2 (четвёртое поколение i7, появление которого всё-таки тоже ужé может считаться давнишним, так как 2013 и 2014 год).

Опять же вопрос, насколько оптимизированною под возможности этого процессора была сборка утилит cjxl и djxl, а также и насколько свѣжею, то есть на основе какого дня коммитов https://github.com/libjxl/libjxl/commits/main собранною — понятно, что не сегодня (16 сентября), но и не 15, и не 13, и даже не 10 сентября, коль скоро недѣлю проработали онѣ послѣ сборки.
No. 164366    
>>164349

Полное декодирование этой картинки с Марисою и впрямь занимает ≈3 секунды, однако nomacs с плагином https://old.reddit.com/r/jpegxl/comments/l4nwb2/how_to_view_jpeg_xl_images_in_nomacs_for_windows/ быстрѣе показывает нѣкую малопиксельную картинку, затѣмъ (через ≈секунду) болѣе чёткую.

Может быть, не только lossy-режим VarDCT помѣщаетъ усреднённые данные о цвѣтѣ своих макроблоков перед остальным кодированным изображением (и тѣмъ позволяет раньше декодировать ≈миниатюру, усреднением ≈размытую, как это упоминалося по адресу https://github.com/libjxl/libjxl/issues/92 и ещё ранѣе упоминалося в других мѣстахъ, https://gitlab.com/wg1/jpeg-xl/-/issues/133#note_527018688 напримѣръ), но и Modular-режим (в lossless JPEG XL употребляемый) также?

Может быть, nomacs кэширует итог декодирования в уменьшенном нечётком виде?

Я не увѣренъ, не могу сказать.
No. 164373    
мясной ѿдѣлъ.jpg - (59.50KB, 960×738)
164373
Может возникнуть вопрос: а зачѣмъ третий из пунктов >>164363 вообще нужен? — разве справка «cjxl --help --verbose» не сообщает, что параметр «-g» (он же «--group-size») автоматически выбирается равным единице или двойке? — уж навѣрное разработчики предусмотрѣли алгоритм такого выбора наилучшим образом, а возможность автовыбора значения 0 или 3 исключили оттого, что оно даёт результат похуже, чѣмъ 1 или 2?

Увы, это часто бывает не так, и даже примѣры таких исходных данных, при которых это бывает не так, отыскиваются довольно просто! — напримѣръ, изображение Марисы из сообщения >>164349 (после преобразования в PNG, командою «dwebp Мариса.webp -mt -o Мариса.png» совершённаго) может быть вызовом команды «cjxl --effort=9 -d 0 -I 1 -E 3 -g 3 Мариса.png Мариса.jxl» ужато до объёма 3062698 байтов.

Та же команда при «-g 2» сжимает только до 3100255 байтов.

Та же команда при «-g 1» сжимает только до 3162728 байтов.

(Провѣрялся кодировщик JPEG XL версии 0.7.0-08dcb04, то есть основанный на коммитах https://github.com/libjxl/libjxl/commits/main по 10 сентября включительно, но не новѣе.)

Видно, что дѣло тут не шуточное, болѣе чѣмъ 1% можно выиграть, хотя и цѣною учетверения расходов времени работы центрального процессора.
No. 164378    
yande_re 423800.webp - (2.53MB, 3640×2048)
164378
>>164363
-O3 -mtune=native; я не использую ту систему на одной только машине, поэтому компилять что-то под конкретное устройство я редко компиляю. Поколенье третье, AVX2 там увы нет и DDR4 тоже. Чем оно кодировалось в конце июля/начале августа я не помню уже, но время декодирования получено сегодня на 0.5-ом релизе.
> Полное декодирование этой картинки с Марисою и впрямь занимает ≈3 секунды
А у вас какой проц?

> то есть ещё не максимально долгий режим в пользу предѣльно большего сжатия файла
Ясно.
Но эффективность "-g" зависит от картинки? Тут нужен перебор внешними средствами, чтобы быть гарантированно лучше автоматики.
"-P" на effort-е в 9 разве уже не становится в 15, которое mix everything? Хотя тут mix наверняка что-то интеллектуальней перебора.
"-I" в help-е старой версии нет, поэтому было пропущено, видимо.
Палитру действительно стоило по-толще сделать.
Так что если на placebo оно не тянет, то на veryslow очень даже да.

>>164366
Интересно. Может и в других просмотровщиках можно такое имплементировать.
No. 164380    
> А у вас какой проц?

i7-3770
Удалить сообщение []
Пароль  
[Mod]