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

Вамъ видно?
Развернуть все изображения
No. 156267    
2020_12_06_08_15_51.webp - (132.01KB, 2560×1440)
156267
Firefox for Android Beta (84.0.0-beta.2), не видно.
No. 156268    
Не видно разницы между 8 бит и 10 бит
No. 156270    
А давайте ещё вместо webm прикрутим какой-нибудь дурацкий формат, который почти никто не использует и чтобы его открывать не все могли!
No. 156272    
>>156270
Webp уже прикрутили вместе, а не вместо, он гораздо хуже во всех отношениях!
No. 156273    
Screenshot_1.png - (482.71KB, 830×910)
156273
Pale Moon
28.16.0 (32-bit)

Не видно.
No. 156274    
Screenshot_2.png - (74.06KB, 750×330)
156274
Ах, и седьмая Винда, если это важно и нужно.
>>156273
No. 156275    
4fd00a2aqpZVcWu4.png - (132.49KB, 600×690)
156275
А вот объясните бестолковому, пожалуйста.
Когда речь идёт о добавлении поддержки какого-либо типа файлов для доски (WEBM, WEBP), имеется в виду только то, что теперь этот файл можно прикрепить к сообщению? Или же подразумевается, что прикрепляемый файл должен воспроизводиться\отображаться в браузере на любом устройстве средствами самого сайта?

Вот у меня видео из ОП-поста, если его скачать, открывается плеером, но в браузере не отображается.
А видео про "Одиннадцать постов про W" и в браузере не показывает, и плеер ругатется на отсутствие необходимых кодеков или фильтров.

Для того, чтобы считалось, что "файл поддерживается", нужно чтобы оба видео на сайте открывались? Или во втором случае это уже лично моя проблема и Совус тут ни при чём?
No. 156276    
>>156275
> Когда речь идёт о добавлении поддержки какого-либо типа файлов для доски (WEBM, WEBP), имеется в виду только то, что теперь этот файл можно прикрепить к сообщению?
True
> Или же подразумевается, что прикрепляемый файл должен воспроизводиться\отображаться в браузере на любом устройстве средствами самого сайта?
False
No. 156277    
А вообще все эти обновления только раздражают, если они принудительные.

Заглядываешь в твиттор какой-нибудь, а там половина "GIF"-файлов не проигрывается (зачем вообще вешать плашку "GIF", если это видео, а не GIF?).
На YouTube видео в 1080р стали лагать во всех браузерах (уже года два как, наверное) и приходится переключаться на 720р, хотя до этого всё нормально работало.
Заходишь на какой-нибудь сайт крупного магазина бытовой элеткроники, а там такое количество полупрозрачных окошечек, анимированных объявлений о скидках и плавно (в теории) выпадающих менюшек, что компьютер просто захлёбывается от всей этой "красоты".
Ну раньше же нормально всё работало, ну!

Было бы здорово, если бы все обновляторы под свои обновления ещё и железки для апгрейда компьютера высылали бесплатно.
No. 156278    
80476524_p14.jpg - (660.57KB, 1000×1402)
156278
>>156276
Понятно, спасибо.
Тогда не ясно зачем спрашивать "Видно или нет?".
Прилепилось? Прилепилось. Значит, всё ок?
No. 156279    
Ме тоже видо.
No. 156281    
Otter Browser, GNU/Linux, ничего не видать. В консоли браузера:
WebKit ошибка #203: Loading is handled by the media engine


А если бы и было видно, то всё равно превратилось бы в слайдшоу с такими разрешениями и такими кодеками.

Так что пользуясь случаем, решительно возражаю против прикрепления к постам видео-отрывков в высоком разрешении. Они же всё равно в окно не поместятся! Если уж всё равно вырезать и конвертировать, то можно и разрешение заодно снизить.
No. 156283    
ет, е видо. икогда е смотрю, though.

Btw, Мицгол, е узаю тебя в гриме.
No. 156284    
>>156283
Держи. "Н, н."
No. 156286    
gunfire amazing.jpg - (50.13KB, 800×941)
156286
Ѿвѣтъ на вопрос >>156278 довольно прост: нѣтъ смысла прикреплять видеозапись к сообщению, если её очень мало кто увидит, особенно если среди неувидевших будут не только тѣ потенциальные зрители, которые сами выбрали свой удѣлъ (напримѣръ, когда приняли рѣшеніе купить мобильное устройство от Apple или рѣшеніе остаться на браузере Pale Moon), но и очевидно болѣе крупные сегменты пользователей.
No. 156287    
76910766_p0.png - (1.38MB, 1883×1600)
156287
>>156286
Ясно, понятно. Спасибо за разъяснения.
>рѣшеніе остаться на браузере Pale Moon
FireFox стал жирным и неповоротливым. А ещё после какого-то там обновления (чёртовы обновления!) полностью сломали совместимость со всеми плагинами, которыми я пользовался. И я подумал, пускай тогда в баню идут с таким подходом.
А в хромобраузере история не отключается. Либо каждый раз чистить ручками, либо ставить костыли и бить в бубен, чтобы отключилась. Слишком много лишних телодвижений ради элементарной функции. На фиг.

О старая Опера. Как же я по ней скучаю. По RSS-ленте и удобнейшим закладкам.
Потом они всё наобновляли и от Оперы только название осталось.
No. 156295    
Screenshot_20201207-104454.jpg - (549.87KB, 720×1560)
156295
>>156266
Видно, но только слайд-шоу.
No. 156299    
>>156295

Хром?
No. 156305    
Screenshot_20201207-222343.png - (192.81KB, 1080×1920)
156305
>>156266
На телефоне в плеере даши жёсткое слайдшоу. Но плеер даши — то ещё добро по производительности. Да и телефону уже куча лет.
Будь видео меньшего разрешения, могло бы быть нормально.
No. 156347    
>>156266
Да, видно.

Firefox 78 GNU/Linux
No. 159408    
screenshot.webp - (346.95KB, 1280×1500)
159408
По адресу https://410chan.org/.appeals/2020/app2020-hule.htm говорится, что около 3¼% посѣщеній 410чана случается с операционной системы macOS.

По адресу https://9to5mac.com/2021/02/18/apple-adds-webm-video-playback-support-to-safari-with-macos-big-sur-11-3/ сообщают (скриншот прилагаю), что поклонникам этой системы суждено возрадоваться, так как в бета-версиях macOS Big Sur 11.3 замѣчена поддержка видеоформата WebM во браузере Safari, прежде в этом браузере всё время совершенно отсутствовавшая. Стало быть, надо думать, во второй половине нынешней весны (или, может быть, в начале лѣта) не только в бета-версии, но и в релизе Big Sur появится такая возможность просмотра WebM.

И когда появится она, то не позабудьте провѣрить видеоролик >>156266 и узнать, ограничивается ли поддержка WebM в macOS Big Sur 11.3 только восьмибитными компонентами цвѣта или же и десятибитные также поддерживаются.
No. 159409    
Огнелиса, 10 окон, полет нормальный.
>>156287
>жирным и неповоротливым
Да, когда на 8 вкладках браузер кушоет 1гб, это не круто, но из всех мощных браузеров огнелиса самая лучшая. Гигабайт у меня все равно 12, так что склерозом не страдаю. А плагинами не пользуюсь, ничего не скажу.
No. 159410    
Не видно, чром на прыщах.
No. 159411    
78 Firefox, Linux - все окей
No. 159412    
>>159411
Блджад, у меня дефекткный браузер.
No. 159414    
Chromium 89, Linux
It works!
No. 159423    
>>159412
Странно конечно
No. 159424    
>>159423
Чего странного. Может он так его собрал. Или пакеты устаревшие. Или ОС такая.
No. 159428    
>>159424
Всё может быть и тем не менее.
No. 159435    
>>159424
Просто хромиум из репозитория Debian Bullseye.
No. 160484    
faptcha_php.png - (8.91KB, 90×50)
160484
Допустимо ли небольшой опрос по кодекам, браузерам и по тому, у кого что открывается?
Во всех трёх видео есть звук.

1. https://410chan.org/b/src/161965252067.mp4 : MP4 + AV1 + FDK AAC;
2. https://410chan.org/b/src/161977454386.mp4 : MP4 + AV1 + Opus;
3. https://410chan.org/b/src/162017610847.webm : WebM + AV1 + Opus.

_____________

PaleMoon 29.1.0 --enable-av1
1. [OK]; 2. Без звука; 3. [OK].
No. 160486    
safari норм
No. 160488    
А тем временем отрывок из >>156266 в mpv вызывает лаги и жёсткое выпадение кадров, но преспокойно воспроизводится в Firefox (87). Бред какой-то. Это как вообще?!
No. 160489    
По опросу, проведенному любителями новых кодыков, у 100% любителей новых кодыков открылись новые кодыки.
Как же хочется видеть вас пеплом в печах, неугомонные.
No. 160490    
>>160484
88 firefox, все три видео ОК
No. 160491    
>>160488
Предположу, Лиса пытается запустить видео то об GPU, mpv либо прямо от CPU, либо fallback'нулся на CPU, после того как GPU-способ не сработал. Они есть разные. На одной машине ловил, что vaapi работало, а opengl-hq нет, например.
BTW, Луна в 10-битное видео то не может.

>>160489
Ну знаете, меж миниатюрной кашей из блоков навроде https://410chan.org/b/arch/src/153746341150.webm, которая открывается у всех, и более-менее смотримым видео, которое у кого-то не открывается, я выберу открывающееся не у всех для публикации на чане. Возможно, кинув VP9-версию на catbox.
Вопрос в том, как сделать так, чтобы некаша корректно открывалась у максимального числа.
No. 160495    
>>160491
Телепатия на высшем уровне! Действительно, хоть и в обоих случаях происходит fallback на софтовый декодинг, но cо стандартным vo=gpu mpv его гладко воспроизвести отчего-то не может, а вот с vo=vaapi — пожалуйста. Однако у vaapi сломано OSD полностью, что делает его, так скажем, не слишком привлекательным вариантом. Включение-отключение opengl-hq (а точнее, gpu-hq) на картину влияет весьма слабо, а вот принудительный рендеринг через Vulkan (gpu-api=vulkan) неожиданно исправляет всё! Ну и дела.
No. 160530    
WebM in Safari.webp - (51.18KB, 900×338)
160530
Мрачно подозреваю, что автор сообщения >>160486 обманывает нас насчёт того, что в Safari всѣ эти видеоролики в порядке, и имѣю для того двѣ причины:

① По адресу https://webkit.org/blog/11648/new-webkit-features-in-safari-14-1/ сказано (скриншот прилагаю), что недавний запуск поддержки WebM в Safari подразумевает поддержку звука Vorbis, а про поддержку Opus ничё не сказано.

② Баг https://bugs.webkit.org/show_bug.cgi?id=183852 с марта 2018 года остаётся незакрытым.
No. 160531    
>>160489

> Как же хочется видеть вас пеплом в печах, неугомонные.
No. 160537    
>>160530
я решил, что видео без звука
No. 160545    
16202966519.webp - (283.25KB, 576×576)
160545
Пусть будет здесь.
Неча каждый тред угонять обсуждениями этой лабуды.

>>160540
>>160542
Там параметры, влияющие на качество, скорость и тому подобное. Видимо, они поставлены не были. К тому же, не указано даже, по чему кодирование производилось (CRF, CQP, etc.). Поставив me_range в 256 у preset-а placebo, получите скорость кодирования сопоставимую с libvpx-vp9 при самых медленных (и дающих наилучшее качество/размер соотношение) его настройках. Но вот твикай libx264 хоть так, твикай эдак, при сколь-нибудь отличных от 0 CRF libx264 не сможет дать меньший размер, чем у libvpx-vp9 при его настройках, дающих лучшее размер/качество соотношение. Иначе говоря, с VP9 для заданного размера можно получить качество принципиально недостижимое с H.264, и чем меньше размер, тем более бросается в глаза это обстоятельство.
Единственно что, как-то было обнаружил на нескольких образцах анимации1280:720, что у libx264 (nearly) lossless эффективнее, чем у libx265 и libvpx-vp9 при лучших их всех настройках. Но Лиса напрочь не может в lossless libx264.
Зачем я это всё пишу?
No. 160546    
out.webm - (4.25MB, 1920×1080)
160546
Окей, просите здесь, буду здесь. Тест третий поехал.
No. 160547    
>>160546
Параметры:
ffmpeg -i in.webm -c:v libvpx-vp9 -c:a libopus -b:v 193K -b:a 64K out.webm
При таких настройках получился слегка меньший битрейт, а именно на 33 килобита в секунду и заметно меньший размер. Учитывая, что эти килобиты глазами не видно, качество внешне неотличимо, размер заметно меньше и открывается на телефоне тоже, я смог добиться требуемого тобой результата, могу радоваться за себя. Вот так вот.
No. 160548    
>>160547
> качество внешне неотличимо
Лолнет.
No. 160550    
>>160548
Ватсон, убери микроскоп.
No. 160552    
>>160550
Нельзя убрать того, чего нет.
No. 160554    
Ну и таки не поленись вы глянуть адекватные настройки для VP9, качество то было бы заметно лучше, чем у вывода x264 при том же размере. Да и тот видос с x264 могли бы лучше пожать. Так что нет, радоваться за себя пока не можешь.
No. 160557    
>>160554
>адекватные настройки
Стандартные всегда самые адекватные, а битрейт я поменял, что бы не раздувало. Качество я глазами и ушами отличить не могу, уверен, многие тоже. А открывается у всех и размер лучше. Танцевать с бубном и настраивать каждый пиксель ради 0.1Мб я не буду во первых потому, что не умею, а во вторых, потому что вряд ли мне когда-то будет интересно научится страдать на ровном месте.
>и тот видос с x264 могли бы лучше пожать
Возьми и пожми, я не вижу смысла выдавливать из библиотеки того, на что она не расчитанна.
>Ну и таки не поленись вы глянуть адекватные настройки для VP9, качество то было бы заметно лучше, чем у вывода x264 при том же размере
Качество уже заметно лучше.
Боже, какие унылые тролли набижали, я сливаюсь, торжествуйте.
No. 160558    
кисленько!.webm - (2.54MB, 1280×720)
160558
>>160557
> x264 default preset
> 2021
> адекватные настройки
Also
> выдавливать из библиотеки то, на что она не расчитана
> Стандартные всегда самые адекватные
> Танцевать с бубном и настраивать каждый пиксель ради 0.1Мб
> спойлер
No. 160613    
>>160557

> Стандартные всегда самые адекватные

Нѣтъ.

https://old.reddit.com/r/AV1/comments/k7colv/encoder_tuning_part_1_tuning_libvpxvp9_be_more/
No. 160615    
>>160613
https://trac.ffmpeg.org/wiki/Encode/VP9
No. 160617    
>>160615
У FF-проекта проблема с документацией и написанием подробных guide. Отсутствие информации на track wiki обычное дело.
Документация вот: https://ffmpeg.org/ffmpeg-codecs.html#libvpx
Ну и стоит глянуть guide на вики webm project, на которых указанная в >>160615 wiki ссылается: https://sites.google.com/a/webmproject.org/wiki/ffmpeg/vp9-encoding-guide
No. 160642    
>>160617
Вытирает пену
Нет, я ничего не имею против вики, очень хорошая вещь, только если бы ты когда нибудь попробовал енкодить в два прохода вп9 на i3-7020U, ты бы эту ссылку не дал, потому что как бы я не бил настройки, меньше чем за час я эти две с половиной минуты не обработаю.
No. 160647    
Так как этот процессор располагает двумя двухпоточными ядрами, то я б рекомендовал параметры «-tile-columns 2 -threads 4» (из гугловской инструкции https://developers.google.com/media/vp9/settings/vod#tiling_and_threading_recommendations взятые) в сочетании с ненулевым значением параметра cpu-used.
No. 160657    
>>160647
Да, спасибо за Америку.
>>160609
Раньше x264 смотрели и никто не жаловался, а сейчас тебе vp9 с артефактами. Рекомендую менять глаза или там мировоззрение, не знаю что с тобой не так.
No. 160669    
>>160668
Научи быстро кодировать в av1 (конечно же через ffmpeg), потому что я документации не нашел, в то время как документация vp9 позволила мне добиться скорости 0.7-0.8, что вполне приемлемо.
No. 160671    
download (2).jpg - (6.16KB, 300×168)
160671
>>160664
> Being Meguca is Suffering
Must save Megukas! Should end suffering!
No. 160672    
AOM vs VP9 vs x265.webp - (498.78KB, 3840×2086)
160672
Раньше было раньше.

В сообщении >>160609 показано: было время, когда и видео 240p (втрое меньше, чѣмъ 720p!) в формате Windows Media Video 9 считалось очень хорошим.

Сейчас всё не так. Можно сказать, что в этом отношении ужé перемѣнилось если и не всё міровоззрѣніе въ цѣломъ, то уж точно частная система взглядов, да притом же она лучше соѿвѣтствуетъ и глазам, так что совѣтъ «мѣнять глаза или міровоззрѣніе» безсмыслененъ.

Кроме того, ѳэзисъ «VP9 с артефактами» не означает же «а вот AV1 — без артефактов». Просто на 410чанѣ пятимегабайтовый предѣлъ объёма видеофайлов создаёт вот какие обстоятельства:

① Артефакты однопроходного кодирования VP9 дѣлаются замѣтными для цитат из аниме, превосходящих примѣрно ½ минуты, а раздражать начинают примѣрно для превосходящих минуту.

② Артефакты двухпроходного кодирования AV1 дѣлаются замѣтными для цитат из аниме, превосходящих примѣрно полторы минуты, а раздражать начинают примѣрно для превосходящих двѣ минуты с половиною.

③ Качество двухпроходного кодирования VP9 занимает промежуточное положение (по оцѣнкѣ https://engineering.fb.com/2018/04/10/video-engineering/av1-beats-x264-and-libvpx-vp9-in-practical-use-case/ оно примѣрно на ⅓ хуже, чѣмъ AV1), но если кодировать такъ непріятно (оттого что долго), как это только что обсуждалось, то тогда почему бы не кодировать вмѣсто того в AV1 на повышенной скорости? — и качество получится чуть повыше, и артефакты чуть болѣе пріятны. По крайней мѣрѣ, именно об этом свидетельствуют приводящиеся по адресу https://old.reddit.com/r/AV1/comments/gg105s/aom_vs_vp9_vs_x265/ результаты сравнения кодирования AV1 на высокой (четвёртой и пятой) скорости с результатами кодирования VP9 на предѣльно низкой (нулевой) скорости, причём сравнение это совершалося по объективному показателю (VMAF). Растровую копию прилагаю.

(Я всюду тут пишу «примѣрно», поскольку информационная ёмкость одной минуты аниме сильно зависит от динамизма; скажем, если сцена перемѣняется каждые нѣсколько секунд, как в рекламных предпросмотрах будущих аниме, то тогда и полутораминутные цитаты наподобие >>/a/16838 способны раздражать взгляд артефактами в пятимегабайтовых AV1.)
No. 160674    
1606248770577.jpg - (27.87KB, 300×505)
160674
>>160668
> то тогда почему бы не кодировать вмѣсто того в AV1 на повышенной скорости? — и качество получится чуть повыше, и артефакты чуть болѣе пріятны.
А вот это на самом деле спорный и интересный вопрос — в следующем ключе. Действительно ли (особенно, говоря о CRF кодировании только) default mode у кодека лучше, чем high complexity mode у другого кодека, предел потенциальной лучшести которого ниже, чем у предыдущего? Быть может, если стоит вопрос времени, стоит выбрать VP9 с placebo-tier настройками над AV1 на повышеной скорости? Быть может, над default mode у libpvpx-vp9 стоит выбрать placebo-tier у libx264? Опыт говорит, что таки бывает стоит.

В качестве примера, рассмотрим разницу меж default mode у libvpx-vp9 (далее vp9) >>160546 и default (даже не placebo) mode у libx264 >>160539 (далее vp9). Первое кодировалось по VB, второе по crf=35 (что делает, конечно, сие примером не столь наглядным и корректным). x264 справа. https://files.catbox.moe/0qz4jo.webp

001. У x264 имеем больший след от руки, но меньшую блюрность и блочность поля, чем у vp9.
003. x264 убирает след, сохраняяется блочность вдоль линий. vp9 не успевает восстановиться, и не только продолжает иметь худшую блочность и след от руки, но и имеет заметно заблоченым фон-одеяло, а также тень от подушки; при этом одна из линий на дощатом полу сильно утеряна.
021. x264 продолжает сохранять минорную блочность вокруг границ кластеров одного цвета. vp9 в силу небольшого количества движения к этому кадру успевает восстановиться, и имеет менее заблоченные, чем x264 границы. Хотя градиент в нижнем левос углу лучше, пожалуй, всё-таки у x264.
207. После смены сцены, появляется рука. Рука в дивжении, и примерно одинаково заблюрена/заблочена у обеих кодеков. С виду, x264 продуцирует несколько больше дефектов на границах волос, но это не точно.
397.
418. Оба scenecut-а корректно обработаны обеими кодировщиками. При ближайшем рассмотрении, разность есть с точностью до шума.
451. Очередной scenecut с движением. В этот раз vp9 страдает также, как и напервых кадрах, заблюривая и заблочивая, и отпрянувшего от девицы человека, и одеяла в верхнем невом углу, и небо за окном - вообще всё, и это сильно заметно. У x264 этого нет, дефекты выражены во вразы меньшей степени.
457. Мальчик долбанулся спиной о стену. vp9 восстанавливается, но всё равно не дотягивает до уровня x264 даже спустя 6 кадров.

Как можно видеть, x264 при (условно) сопоставимом размере файла не только достигает сопоставимое качество не первых сценах, но и качество заметно превосходящее vp9, на которое было потрачено не меньше часа (опять же, со слов кодировавшего, который мог иметь ввиду только двух-проходное кодирование). И это только default mode! Так что, при наличии вопроса времени, placebo у libx264 может оказаться адекватнее использования default mode у libvpx-vp9, quality-wise speaking. Из опыта, показанное в кадрах 3 и 451 — типичная проблема low complexity VP9, избавляющегося от блочности на переходах так долго, что это создаёт новое движение, сильно бросающееся в глаза.

Тем не менее, это примеры. Конкретного хорошего исследования, дававшего бы графики и таблицы SSIM и PSNR/размер при CRF кодировании для разных кодеков, а также их настроек скорости (разумеется, с указанием времени) и target bitrate/crf я не находил (возможно, потому что особо не искал — что-то подобное, правда для одного ролика и ограниченного набора кодировщиков, только что запостили). Нет и сопоставления CRF к SSIM для разных кодировщиков при их mid-tier или placebo-tier настройках. Могу ли я, например, верить, что crf=44 у AV1 есть примерно то же самое, что и у VP9? Не могу. Это затрудняет адопцию формата; хотя речь в посте не про это.
No. 160675    
> x264 слева
fxd
No. 160677    
out.webm - (4.85MB, 1920×1080)
160677
>>160674
Входной файл тот же.
ffmpeg -i in.webm -c:v libvpx-vp9 -b:v 180K -minrate 90K -maxrate 260K -crf 35 -speed 2 -tile-columns 2 -threads 4 -c:a libopus -b:a 64K out.webm
No. 160678    
out1.mp4 - (4.60MB, 1920×1080)
160678
ffmpeg -i in.webm -c:v libx264 -b:v 180K -crf 32 -tune animation -preset veryslow -c:a libopus -b:a 64K out1.mp4
No. 160679    
Иронично, но x264 справился лучше.
>>160674 описал что именно x264 делает лучше.
Кроме того, лично мне было приятней смотреть на работу x264.
Кому не влом, попробуйте vp9 2-pass сделать, может оно выдаст лучший результат.
No. 160681    
chck:2pass.webm - (4.66MB, 1920×1080)
160681
キタ━━━(゚∀゚)━━━!!
No. 160682    
chck:2pass.mp4 - (4.68MB, 1920×1080)
160682
キタ━━━(゚∀゚)━━━!!
No. 160684    
Как можно видеть, на статических картинах vp9 дал более красивый результат, в то время как картины с резкими переходами сильно размылило, чего у x264 не наблюдается. Так что в целях экономии времени, что бы не высиживать этот ваш шакальный av1 можно делать в один проход x264 и радоваться.
No. 160690    
out2.webm - (669.03KB, 1920×1080)
160690
ffmpeg -i in.webm -c:v libvpx-vp9 -b:v 180K -minrate 90K -maxrate 260K -crf 31 -tile-columns 2 -threads 4 -speed 0 -row-mt true -t 00:00:30 -bufsize 360K -slices 2 -g 180 -an out2.webm
Если убрать флаг -g, будет такое же мыло, как и в прошлых экземплярах. При -g 180 мыла заметно меньше. Но по-моему он не вложится в 5мб если все видео енкодить. Разве что добивать при помощи -crf, но не ясно стоит ли оно того.
No. 160699    
>>160690
>Разве что добивать при помощи -crf, но не ясно стоит ли оно того.
В общем я потыкал и не стоит. x264 то же выдает, а скорость нормально так выше.
No. 160707    
Аналог видеоцитаты >>160457 (но на сей раз между отмѣтками времени 9:57.846 и 12:36.666 из предлагаемого по адресу https://doki.co/2012/01/22/denpa-teki-na-kanojo-bd/ файла 1080p, использовавшегося и в прошлый раз), кодированный въ AV1 съ десятибитными компонентами цвѣта вмѣсто восьмибитныхъ (то есть кодированный наподобие >>156266, но въ AV1 вмѣсто WebM).

Два дополнительных бита вчетверо увеличивают количество доступных уровней компонента — соѿвѣтственно, вчетверо уменьшают артефакты, вызванные преобразованием цвѣтового пространства (из RGB в YUV) или собственно недостаточностью уровней в тёмных сценах (то есть подавляют дробление плавных цвѣтовыхъ переходов на ѿдѣльныя широкія раздражающе одноцвѣтныя полосы, вчетверо сокращая ширину их).

Однако поддержка многобитных AV1 появилась во браузерах не так давно, этот видеофайл может у кого-то вовсе не показываться — а у кого-то показываться, но подтормаживать.

Лично у меня в Firefox 88 на виндѣ и видно, и не подтормаживает.

Вамъ видно ли? Не подтормаживает ли?
No. 160709    
(Как справедливо подмѣтилъ автор сообщения >>160674, первый кадр рассыпается на макроблоки.

Я не понимаю, почему это так; подозреваю глюк кодировщика.)
No. 160710    
Firefox for Android Beta (89.0.0-beta.5), видно и не тормозит.
No. 160711    
Google Chrome 90.0.4430.91 на одиннадцатом Андроиде: видно, но тормозит (чѣмъ показывает наглядно, что libgav1 отстаёт от dav1d).
No. 160713    
>>160709
Не только первый. При стандартном значении -g когда он срывается с кровати при виде внезапно появившейся девы, все тоже рассыпается.
No. 160720    
>>160707
Firefox 88, GNU/Linux: видно, но в резких переходах между сценами начинает подтормаживать, а где-то после 2:11 картинка замирает и больше не обновляется; mpv 0.32.0, libdav1d 0.7.1, софтовый декодинг: видно, но в переходах между сценами также подтормаживает (mpv позволяет увидеть, что происходит небольшое, но заметное выпадение кадров, а также лёгкий рассинхрон, который быстро проходит), местами в сценах с высоким битрейтом воспроизведение замирает на долю секунды, а после 2:11 начинаются жёсткое выпадение кадров и сильный рассинхрон.

И всё-таки кодек из будущего!
No. 160721    
>>156266
Оверчан, Сяома, всё работает, ничего не тормозит.
No. 160727    
Сейчас ещё раз свѣжимъ взглядомъ посмотрѣлъ на тормоза >>160711 и вижу, что напрасно цѣликомъ ѿнёсъ их на счёт недостатков libgav1:

① У меня стоит довольно новый Chrome — версия 90.0.4430.91.

② По адресу https://old.reddit.com/r/AV1/comments/lwtstm/chrome_89_released_with_dav1d_081_and_avif/ сказано, что с версии 89 браузер Chrome перешёл к употреблению dav1d 0.8.1 под Android.

③ По адресу https://old.reddit.com/r/AV1/comments/lxhkbl/dav1d_082_cherrypicked_to_chromium_m90_branch/ пишут (на https://bugs.chromium.org/p/chromium/issues/detail?id=1182745#c9 ссылаясь) даже и то, что во Chrome 90 засунули ужé dav1d 0.8.2.

Получается, что в Файерфоксе dav1d не тормозит, а во Хроме тормозит, причём на том же смартфоне. Видимо, авторы Хрома засунули в него движок dav1d недавно и оттого неоптимально? — или у них pipeline многобитных видеокадров тормозит?

Ещё получается, что автору сообщения >>160720 надо бы обновить mpv, а не то версия dav1d не совершенно свѣжая. (По адресу https://code.videolan.org/videolan/dav1d/-/commit/f06148e7c755098666b9c0ed97a672a51785413a пишут, что только к версии 0.8.2 была окончена работа по ускорению декодирования AV1 с десятибитными и двенадцатибитными компонентами цвѣта на ARM32 и ARM64, продолжается работа по ускорению на x86.)
No. 160739    
162072275097.jpg - (215.93KB, 1280×720)
160739
>>160707
PaleMoon 29.2.0, мобильный i7 почти 10-летней давности, проигрывается без проблем.

Вообще, тестировать всю ту лабуду стоит не только на почти статичном >>160707,
но и и на динамичных видео с большим количеством движения. Хорошим примером будет RockOverJapan сцена из MawaruPenguindrum.

>>160690
Уменьшенное g если лечит проблему, то путём отрубания руки вместе с воспалением. При кодировании видео для публикации на чанах, g, keyint, и им подобное полезно закручивать в максимум, оно задаёт максимальное допустимое расстояние между I- или keyframe-ами. Например, установив у >>160678 keyint в 8192 можно будет выиграть ~200 KiB при (почти) такой же скорости кодирования и без потерь в качестве. Из возможных побочек высоких g, проявляющихся если видео имеет длинные статичные сцены (на которых высокое g даст наибольший выишрыш в объёме): во-первых, перемещение на выбранную позицию в видео может занять какое-то время; во-вторых, некоторые плэеры позволяют перемещаться только меж keyframe-ами, поэтому плэер может сильно промазать. Пользователю, разумеется, не понравится, когда он тыкает на отметку в 02:30, а видео либо открылось на 00:44, либо заставляет компьютр пошуметь пару секунд перед открытием нужной отметки, и так каждый раз. Поэтому keyint стоит низкий by default. Но для картинкодосок его допустимо задирать в небеса, поскольку seeking in video процесс скорее отсутствует.

speed=0 aside, complexity всё ещё low. Может попробую как-нибудь позже покодировать решить проблему, подведя настройки под то же, что и у >>160677, fps. Никогда раньше не задавался вопросом эффективнейших настроек для более быстрого кодирования VP9.
No. 160740    
>>160727
> Ещё получается, что автору сообщения >>160720 надо бы обновить mpv, а не то версия dav1d не совершенно свѣжая.
Ладно-ладно, в моём дистрибутиве 0.8.2 уже на подходе, как только так сразу! Посмотрим, смогут ли те оптимизации преодолеть аппаратные ограничения.
No. 160962    
не_баг_а_фича.webp - (23.36KB, 925×483)
160962
>>159081
>>159083
>> Install webp-pixbuf-loader
>< Не для всего ПО на GTK она решится лишь установкой пакета
У PaleMoon тамова picrelated. Достаточно добавить webp в список из UXP/widgets/gtk/nsAppShell.cpp, чтобы thumbnail’ы в диалоге выбора файла отображались (разумеется, при установленном том пакете), но можно и вовсе снести тот костыль. Правда, у GTK assert’ции на счёт картинки и её размера валятся, так что для идеального-идеального решения поменять ещё несколько файлов. Но чтобы работало, достаточно поменять только показанный код. Видимо, кто-то поленился это делать, а заметившие поленились добавить issue на трэкер.

>>160484
… чего не скажешь об Opus в MP4:
https://repo.palemoon.org/MoonchildProductions/UXP/issues/1225
Уже год висит.

Тем временем, недавно добавили задачу по запилу поддержки JXL:
https://repo.palemoon.org/MoonchildProductions/UXP/issues/1769

Добавлять поддержку AVIF отказались под предлогом недостаточной адопции и мертворождённости формата в связи с JXL, приправленным аргументом про неточность SSIM/PSNR и прочих оценок:
https://forum.palemoon.org/viewtopic.php?f=13&t=26037&p=206992
Хотя адопция у AVIF сейчас выше, чем у JXL:
https://caniuse.com/avif
No. 160968    
> Шебпфанатики: везде играется! Нетоповых и необновленных конфигураций не существует! Никаких проблем! Переходим!
> Также шебпфанатики: надо покостылять тут и тут, а ещё здесь подпорочку, а вот там уже начали костылики внедрять! Через неделю — <ненужноформат> на марсе!
No. 160979    
>>160739

Годится ли >>160790 какъ примѣръ (также AV1 милліардоцвѣтный) динамичныхъ видео съ большимъ количествомъ движенія?

(Болѣе продолжительную версію этой видеоцитаты прилагаю.)

>>160968

Ваша метафора про марс основана на названии двойного выигрыша в нарды?
No. 160980    
>>160979
Нет, к сожалению я не настолько умен. Основана она на высмеивании типичных прогрессистов, любителей всего нового, и тестировать это на себе и других, вместо того чтобы использовать проверенное. Колонизация и полеты к Марсу — последняя жужжащщая тема. Известно, что у Маска сенсорные экраны не только в машине стоят, но и в космотехнике вроде планируются. Вот почему бы марсоходу изображения в webp не кодировать, ага.

«only common, stable formats» (c) не_баг_а_фича.webp
No. 160986    
> only common, stable formats
И в ~2015-ом году, когда Мозиловцы написали тот костыль, фраза была корявой по отношению к идущему там ниже коду. Потому, что множество стабильных форматов список тот не включает. Потому, что XPM, ICO и BMP не сказать, чтоб common. Особенно XPM.
No. 161015    
Контраргумент >>160980 я отвергаю на том основании, что «использовать проверенное» в сём случае как раз и означает использовать WebP.

Формат WebP и впрямь вѣдь был провѣренъ долгою эксплоатаціею в самых различных условиях со дня его появления в далёком 2010 году, и не просто провѣренъ, но и найден превосходящим прежние форматы сжатия, совершаемого без потерь: и формат PNG, и тѣмъ болѣе формат GIF — по степени сжатия почти во всѣхъ случаях, окромя рѣдкостныхъ частных случаев (один из которых прилагаю).

Что же касается превосходства WebP над прежним форматом сжатия, совершаемого с внесением потерь — то есть превосходства над JPEG — то тут ситуация чуть сложнѣе:

① В момент своего появления формат WebP увѣренно превосходил JPEG по степени сжатия, совершаемого с внесением потерь, при равном качестве изображения, измѣряемого по объективным метрикам (в частности, SSIM).

② Послѣ появления WebP была сдѣлана попытка спасти JPEG: Фонд Мозиллы поднатужился и выпустил кодировщик MozJPEG, также оставляющий другие средства создания JPEG далеко позади.

③ Однако появление MozJPEG не было способно полностью преодолѣть разрыв между JPEG и WebP, потому что часть того разрыва обусловлена конструктивными особенностями (в частности, WebP может содержать области, прозрачные полностью или частично, а JPEG — нѣтъ).

④ Кроме того, появление MozJPEG осталось не совершенно замѣченнымъ рядовыми пользователями, которые продолжают кодировать JPEG один Бог знает какими приложениями. Хорошо, если авторы тѣхъ приложений знают про MozJPEG; если ж нѣтъ, то почти исчезает надежда на то, что пользователь будет вмѣсто JPEG сохранять в PNG и затѣмъ сам скармливать тот PNG в MozJPEG.

⑤ Для крупных компаний, напротив того, появление MozJPEG не осталось незамѣченнымъ, однако же и переход к употреблению MozJPEG не состоялся. Дѣло тут в том, что скорость работы MozJPEG составляет в среднем 0,022 от скорости работы libjpeg-turbo (как можно видѣть по адресу https://libjpeg-turbo.org/About/Mozjpeg послѣ слов «Compared to baseline, the overall performance of mozjpeg's default mode»), то есть MozJPEG дѣйствуетъ примѣрно в 45½ раза медленнѣе. Может ли крупная компания, занимающаяся обработкою изображений, поступающих от пользователей, позволить себе не трёхкратное, не пятикратное, не десятикратное, не двадцатикратное, а болѣе чѣмъ сорокапятикратное увеличение вычислительных расходов (то есть буквально к каждому из её многих сёрверов, жмущих JPEG, купить и поставить рядом ещё 45 сёрверов, на порядок нарастить площадь зала, купить больше земли и протянуть под нею болѣе жирные кабели для подачи электричества, etc.)? — как правило, не может. Напримѣръ, по адресу https://twittercommunity.com/t/feedback-for-upcoming-changes-to-png-image-support/118901/84 можно прочесть, как в январе 2019 года Нолан О'Брайен (который тогда работал в Твиттере) рассказывает, что пользователи могут позволить себе использование таких средств сжатия PNG (он упоминает OptiPNG и oxipng), которые Twitter с его масштабами позволить себе не может, и что именно этим Twitter руководится («It cannot scale internally, but moving that onto the user's computer makes it much more likely to be viable») при создании правил https://twittercommunity.com/t/upcoming-changes-to-png-image-support/118695 съ тѣмъ расчетомъ, чтобы пользователи, загружающие в Twitter достаточно сжатые картинки, вознаграждались отказом Твиттера от дальнейшего переужатия тѣхъ картинок на стороне сёрвера. (Пользователи становятся довольны качеством изображения, а Twitter не затрачивает дорогостоящие усилия, но всё равно достигает желаемой степени экономии пространства.) В той же реплике О'Брайен предлагает ориентироваться на использование Твиттером кодека libjpeg-turbo (а не MozJPEG), хотя и намекает, что Twitter использует собственный кодек, не идентичный libjpeg-turbo, а похожий по степени сжатия.

⑥ Кроме того, хотя MozJPEG оставляет прочие кодировщики JPEG далеко позади по качеству изображения, достигаемому при равных объёмах файлов, всё же MozJPEG не в силах полностью догнать качество сжатия WebP, совершаемого с внесением потерь. Чѣмъ сильнѣе сжатие, тѣмъ это виднѣе. В рамках 410чана это было наглядно показано сравнением анонимного ноунэймового «шакального JPEG» >>158719 с результатом работы MozJPEG >>158729 (который выглядит лучше) и затѣмъ с результатом, достигаемым WebP >>158731 (этот послѣдній замѣтно лучше двух предшествующих результатов, хотя объём файла чуть меньше).
No. 161017    
⑦ Кроме того, остающиеся от внесения потерь артефакты JPEG (и «расходящиеся волны» вокруг линий, и «вьющаяся мошкара» вокруг мелких деталей, и «размытие по квадратику» у острых углов и у диагоналей) гораздо более отвратительны, чем артефакты WebP (мягкое «умное размытие», сперва подавляющее наиболее слабоконтрастные детали и текстуры, от которого деревянные и кожаные и каменные и металлические поверхности постепенно начинают выглядеть всё более похожими на гладкий пластик, а лица людей «прихорашиваются» устранением морщин и пор кожи, напоминающим эффект от наложения пудры или тонального крема) при равном объёме файла.
No. 161112    
На примѣрѣ >>/a/17124 ловится ещё одинъ багъ въ кодировщикѣ: на ѿмѣткѣ времени 01:15.206 расположенъ чёткій keyframe, а до того примѣрно пять секундъ кряду точно то же сáмое изображеніе (въ видѣ стопъ-кадра) торчитъ предъ зрителемъ въ до крайности размытомъ видѣ.

Ѿчего жъ такъ? — должно быть, разработчики ѿлаживали только съ параметромъ «--enable-fwd-kf=1» (при которомъ появленіе ключевого кадра въ хвостѣ у кучи неключевыхъ — это ѽкей) и запамятовали, что тотъ параметръ

① не включёнъ по умолчанію,

② изъ FFmpeg (въ ѿличіе ѿ непосредственнаго вызова aomenc) онъ и не можетъ быть включёнъ, пока не устранятъ проблему https://bugs.chromium.org/p/aomedia/issues/detail?id=2960 (извѣстную болѣе чѣмъ три мѣсяца, то есть ещё съ середины февраля, однако жъ до сихъ поръ никто и пальца о палецъ не ударилъ).
No. 161148    
③ И у видеозаписи >>/a/17106 та же проблема.

④ И эта проблема, по-видимому, проявляется въ сочетаніи съ глюкомъ >>160709, который впервые замѣченъ мною въ видеоцитатѣ, не имѣющей ненормальной разстановки ключевыхъ кадровъ.

⑤ И я ужé сообщилъ о проблемѣ Альянсу за Открытыя Медіа.

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

Чего они тамъ въ Альянсѣ — на аниме не тестируютъ свои подѣлія, что ли?
No. 161174    
>>161015
>«использовать проверенное» в сём случае как раз И означает использовать WebP.
Угу. При том, что он не поддерживается кучей просмотрщиков и зачастую приходиться устанавливать сторонний софт, просто что бы позырить в WebP. Вот когда сделаете, что бы он везде работал, тогда и посмотрим. А jpeg и png работают безотказно.
No. 161175    
miyako.webp - (17.28KB, 290×371)
161175
>>
>>161174
> При том, что он не поддерживается кучей просмотрщиков
В браузере открой, солнышко.
No. 161177    
icons.webp - (13.41KB, 1362×693)
161177
>>161175
> просматривать картинки web-браузером
Не скатывайтесь до.
No. 161178    
>>161174
Им это уже не раз объясняли, но, как видишь, турбо-демагогией удалось аж вывернуть наизнанку: это, оказывается, форсящийся последние годы вебп, о котором никто и не слышал раньше, "стабильный". За такое поведение в разговоре, слепое закидывание пропагандой, и называю их формато-сектантами.
О чём говорить, если отдельные сумасшедшие перед постингом(!) специально(!!) конвертируют обычные картинки в своё шебп(!!!). Что это есть, как не тот самый троллинг в особо крупных размерах, в котором они пытаются обвинять других. Кстати, один из них вроде и признавался, что специально поджигает.
Так что можешь не пытаться в по-существу, там будут Мицгол-стены про попиксельные разборы картинок, "все корпорации уже внедрили, негоже сидеть в стороне" и т.п., а как ещё и личная армия сочувствующих подключится, то туши свет.
Всё просто. Увидел шебп/ав1/10бит сектанта — харкни ему соплёй в рожу. Только такое обращение за осознанное, умышленное забивание коммуникационных каналов своей мелкой технической бредятиной.
No. 161179    
162216760565.jpg - (62.44KB, 1280×720)
161179
>>161178
No. 161180    
tanya_webp.jpg - (16.27KB, 180×252)
161180
>>161178
А то твоё сообщение не троллинг и демагогия, солнце. Ответить на такое можно только следующим образом - у меня линукс и всё работает! Мир спасет только следование стандартам, а те кто, кто посмел не подчиниться требованиям прогресса и новым спецификациям будут аннигилированы Столманом и Линусом Торвальдсом в самое ближайшее время. Алоха народ.
No. 161181    
>>161180
> Алоха народ
Это по таджикски?
No. 161182    
>>161181
По Горно-Бадахшански.
No. 161183    
>>161181
Художники не рисуют в webp. Буры не выкладывают в webp. А ну прекрати конвертировать немедленно сейчас же!
No. 161185    
>>161183
Все всё выкладывают и открывают в браузерах и модных вьюверах, только у вас проблемы какие-то.
No. 161187    
>>161180
Когда на каждые новые 5~10 процентов сжатия внедряют новый формат, это не прогресс, а бедлам. У себя потестите, если вам не терпится, а внедрять извольте так, что бы оно того стоило и что бы ни у кого не возникало проблем.
No. 161189    
>>161185
Stop it already. For he won't.
No. 161190    
>>161187
Так оно уже давно без меня внедрено и стандарт де-факто, что я поделать то могу с этим? Конвертировать в jpg? И опять же, удивляют люди у кого НЕ ОТКРЫВАЕТСЯ, что у вас за рабочее окружение, оборудование?
No. 161194    
>>161190
>И опять же, удивляют люди у кого НЕ ОТКРЫВАЕТСЯ
Много людей сидят на старом железе и старых осях, не имея возможности обновится и которые не желают страдать с "модерными" жЫрными просмотрщиками (или как просматривать картинки в браузере, прости господи), а просто хотят пользоваться компьютером.
>Так оно уже давно без меня внедрено и стандарт де-факто, что я поделать то могу с этим?
Во-первых не стандарт и до стандарта, если другой новый кодек не вытеснит, пройдет еще лет 5-10.
>что поделать?
Не усугублять. Вы как психи-фанатики с больной упертостью впариваете людям свой WebP и это раздражает. Многие люди не любят WebP просто потому, что вы его силой пихаете.
No. 161196    
>>161194
Да никто никому ничего не впаривает, вам не нравится, потому что сидите на семерках и икспи(до сих пор есть и такие уникумы), что в любом случае, по совокупности факторов приведет вас к чему то очень нехорошему. Относительно стандарт/нестандарт, ну каждый третий файл на бордах, простите этого самого формата. И он будет вероятно употребляться ещё чаще, т.к. юзеров с такими аппаратными ограничениями явное меньшинство. Дело не в моих хотелках(мне все равно по большому счету), а в объективной реальности.
No. 161197    
>>161196
>Да никто никому ничего не впаривает
В Мицгола пальцем тыкнуть?
>потому что сидите на семерках и икспи
Сижу на десятке плюс убунте 20.04 ЛТС, нигде нативный просмотрщик не поддерживает вебп.
>Относительно стандарт/нестандарт, ну каждый третий файл на бордах, простите этого самого формата.
Ну, я сомневаюсь, что кроме Мицгола и еще парочки любителей новый кодеков, кто-то сидит и специально переписывает картинки в WebP, как скачалось так и есть, а на сайтам выгодней использовать вебп, потому что размер.
> И он будет вероятно употребляться ещё чаще, т.к. юзеров с такими аппаратными ограничениями явное меньшинство.
Если не заменится другими кодеками.
No. 161198    
>>161196
Объективная реальность: моя мыльница не понимает WebP, мой плеер не понимает WebP, мой телевизор не понимает WebP, мой навигатор не понимает WebP, мой телефон не понимает WebP, мой тостер не понимает WebP. IT-дурачки с магическим мышлением могут сколько угодно кричать про грядущее, но их слова не в силах изменить объективную реальность.
No. 161199    
>>161198
А у меня так уж сложилось, там где надо(телефон и десктоп) все прекрасно понимает вебп, более того, скорее всего и у вас такая же картина. А так-то думаю вебп не грядущее, а именно что настоящее и объективная реальность, как вы прекрасно знаете.

>>161197
> Сижу на десятке плюс убунте 20.04 ЛТС, нигде нативный просмотрщик не поддерживает вебп.

Т.е. никаких проблем нет в принципе на самом деле.

>Если не заменится другими кодеками.

Думаю раньше заменится чем джпег даже. Собственно, терпеть вам вероятно где-то два с половиной года еще, видимо.
No. 161200    
>>161198
Объективная реальность: это твои проблемы.
No. 161201    
>>161199
Людям, которые видят WebP в браузере, не нужен WebP. Им вообще глубоко фиолетово, Gif там или WebP, браузер картинку показывает и ладно. Производить его никто не будет, просто потому, что ни одно устройство его производить не умеет и уже никогда не научится. То есть контента на нём нет, а без этого его распространение ограничено.
Я использую это ваше WebP просто чтобы постить одни и те же аватарки; эту картинку я могу запостить ещё 98 раз минимум.
Аминь.
No. 161205    
>>161201
Вообще говоря, сейчас то уже очевидно, что данный формат будет вскорости замещен по всей видимости. Тем не менее я говорил не совсем о браузерах, да и контента создано же весьма прилично. Да он не столь универсален как привычные "старые" форматы, тем не менее истерика которую я наблюдаю, малость несоизмерима с его относительно этой истерики небольшими недостатками. Сильно это меня удивляет, тут никакой Мицгол-евангелист оправданием быть не может. Ну и для веба данный формат действительно полезен, там экономия очень существенная.
No. 161206    
default.png - (4.72KB, 90×50)
161206
>>161204
Меня тоже удивляет, потому что единственно верное его использование — WEBP отдаётся клиенту тогда и только тогда, когда клиент явно указал, что он понимает WEBP (image/webp). Во всех остальных случаях, даже с image/*, отдаётся PNG, JPEG, GIF, BMP. Если завтра WEBP заменят на WEBT, разницы клиенты при такой схеме не заметят. То есть, он изначально создавался как формат, ненужный конечным потребителям.
No. 161207    
>>161206
Он создавался для экономии места разумеется и да, это единственно верный способ(а раньше был и единственно возможный). Но так как тут вечный 2003 год, то и неизбежные странности, с неизбежным "навязыванием"(а как иначе, включить то формат уже нужно) происходят.
No. 161210    
>>161207
Фигня в том, что имиджборды типа Автобуса предоставляют тебе источники файлов такими, как их залил пользователь, без пережатия и переконвертирования. Однако, для совместимости, например, можно выдавать миниатюры в каком-то одном формате или в таком, какой захочет/сможет клиент. Польза от этого - webp миниатюры будут меньше jpeg миниатюр при том же видимом качестве, например. Сейчас, однако, миниатюра выдается в том же формате, что и формат источника. Вероятно, это захардкожено в движке.
No. 161212    
>>161210
Фигня в том, что движок Автобуса, как и прочих, генерирует статические HTML-страницы, так что весь content negotiation идёт лесом.
No. 161213    
>>161212
Может, можно извратиться как-то, что под одним и тем же именем файла будут выдаваться разные форматы.
No. 161215    
1622086637211.jpg - (125.47KB, 600×665)
161215
>>161201
> контента на нём нет
WebP кодирует Imgur (некоторые анонимы почему-то посят туда вместо Catbox-а или ещё чего-либо), кодирует Телега и кодируют некоторые сканляторы картинок. Переодически попадается на сайтах, иногда ещё и переименнованный в .jpg, чтобы на Винде оно локально открывалось в программе «Фотографии» (там, я давно правда не обновлялся, Paint может в WebP из коробки, explorer тоже; просмотровщик картинок тоже может, но не даёт открывать — пока в .jpg или .png не переименуешь).
Редко на WebP натыкаюсь в моей части интернетов, этот и обратный маршрут не в счёт, но оно тем не менее есть.

>>161190
Правды ради, во многом обсуждение любых стандартов, поддерживаемостей и прочего тут имеет смысл делать скорее в контексте нашего уголка инырнетов сообразно нашим use case-ам (и ведь, наверно, не имеет же, поддержка есть, никто убирать не собирается). Так в нашем контексте вообще нет людей, ОСи и устройства которых не (с)могут в WebP, например; они до сих пор не подали голос. Но в этом же контексте, можно сказать, либо что WebP не стандарт, либо стандарт, который до нас особо не дошёл.

И, вполне возможно, не дойдёт. Количество желающих ковырять движки меньших booru сопоставимо с желающими ковырять FBE, гиганты навроде Danbooru и Pixiv-а, зарабатывающие на рекламе и платных подписках, на возможное отсечение части аудитории, за которую трясутся, не идут — в силу этого поисковики картинок, и что важнее — анимешные чаны — не очень заморачиваются с добавлением поддержки формата в силу малочисленности контента, который в основном дёргается либо со старых постов, либо с вышеупомянутого, либо со screenshot’ов — mpv может прямо в WebP кодировать (но по умолчанию-то JPEG), могут ли MPC с VLC я не знаю.

«Не идут» должно вызывать закономерный вопрос: почему оно так, несмотря на выигрыш в месте и трафике. Можно предположить следующее. Так, около момента написания поста последний id на Пиксиве 90151466, принявше средний размер картинки в 8 MiB, имеем 721211728 MiB или где-то 688 TiB картинок, что составляет всего-то навсего 45 Seagate-ов или около $25200, увеличиваем эту сумму вдвое — на самсунговские SSD-шники, которые вдруг кэшируют популярные картинки, и получаем, что хранить медиа для такого титаническо сайта, видимо, не очень-то дорого. С трафиком уже иная история, но, видимо, и тут это им обходится не так дорого, чтобы наслаждаться перспективой потерять часть аудитории. Так что пока Web^^P^ массово-массово не начнёт переходить на JXL, и default’ные настройки всего и вся (особенно Винды, Ведра и лицекниг с телегами) не падут на него, смерть JPEG с PNG как стандартных–обычных форматов мы не увидим.
No. 161217    
Ещё забыл Твиттор как источник контента.
No. 161218    
>>161178

> Увидел шебп/ав1/10бит сектанта — харкни ему соплёй в рожу.

Пока что всё наоборот: это твоя харя всё сильнее опоганивается каждым файлом WebP, каждым видео AV1 или десятибитным.
No. 161223    
>>161197
Каково название «нативного» просмотровщика картинок в LTS том?
No. 161225    
>>161223
EOG. Да брось, будто для Убунты много нативных просмотрщиков. Или ты думаешь, я бы стал менять DE?
No. 161226    
2018-06-28-966372.gif - (177.14KB, 700×1000)
161226
>>161215
>контент
>кодирует
По вашей логике получается, я — великий творец контента, затмевающий собой самого Соуса. Я-то думала, что для создания контента надо хотя бы взять мыльницу, пойти куда-то и чего-то нафоткать.
>они до сих пор не подали голос
Ну у меня есть мыльница, она пишет жопег и ави. Выкладывать, например в одноклассниках, я буду жопег и ави соответственно. Т.е. меня, как производителя контента, это ваше WebP никак не касается.
No. 161227    
faptcha_php.png - (9.13KB, 90×50)
161227
>>161225
Я слабо представляю, что там в Убунту, тем более в LTS.
А вот что EOG не может, это странно, Gnome огромное DE — у таких вроде с поддержкой разных форматов должно быть всё хорошо. У Gnome, впрочем, есть другой «нативный» просмотровщик, который gThumb, он вроде может.
No. 161229    
chiochan.mp4 - (1.39MB, 1920×1080)
161229
>>161227
No. 161230    
>>161226
Не получается. Таких предположений лично на счёт вас не было. К тому же, я помню, что у вас мыльница, и что она пишет в JPEG.
А у меня, например, была квазизеркалка и она писала в NEF.
> AVI
Оно ещё живое? Етить. Какая модель мыльницы? Also, браузеры в AVI не могут, придётся remux-нуть в MP4. Если, конечно, у них там на сервере однокласников такого нет. Среднестатистическая *чанька там едва ли сидит, а если сидит, то с целью потролить обитателей, поди.
No. 161231    
faptcha_php.png - (5.43KB, 90×50)
161231
>>161229
Если я правильно понимаю происходящее, включили один нативный гномопросмотровщик вместо другого нативного гномопросмотровщика в свою базовую группу пакетов. Сам пакет в репозитории есть.

Also, Firefox и основанные на нём браузеры не поддерживают стандарт H.264. Точнее, не полностью его поддерживают — в данном случае не поддерживается кодирование RGB (gbrp). Так что, если хотите кодировать именно с libx264 для публикации на чанах, то стоит поставить pix_fmt в yuv420p, уменьшив тем качество — в полноцветное yuv444p Лиса тоже не умеет. Таким образом, записи экрана лучше кодировать VP-кодеками, с ними у Лисы этой и ряда других проблем нет.
No. 161232    
default.png - (8.71KB, 90×50)
161232
>>161230
Вы сами заявили, что контент с WebP есть на основании того, что некий картинкохостинг умеет конвертировать загруженные на него изображения в WebP. Я тоже могу конвертировать чужие картинки в WebP.
No. 161233    
cG9x7DP_d.webp - (61.61KB, 616×707)
161233
>>161232
> контент с WebP есть на основании того, что некий картинкохостинг умеет конвертировать загруженные на него изображения в WebP
Ну он и отдаёт их в WebP. Иной раз, вроде, без вариантов. Следовательно, контент с WebP там есть. Такие дела.
> Я тоже могу конвертировать чужие картинки в WebP.
You sure can. Единственно что, не так сильно шакальте.

>>161215
> кодирует Телега
Точнее, дозволяет. Кодирует некоторые виды стикеров вроде.
No. 161234    
>>161231
Я удалил пост, не знаю почему не удалилось. А x11grab в yuv не умеет, я сначала думал перекодировать с rgb в yuv, но это невозможно, без кучи геморроя, думал перезаписать через нормальную програму, а потом увидел, что пост не удалился и ты уже написал мне ответ.
No. 161235    
BTW, так что за мыльница и сколько ей лет?
No. 161236    
>>161231
Also, pix_fmt yuv420p does nothing, точнее, просто пишет, что incompatible pixel format.
No. 161237    
>>161236
Полная комманда, которую использовали?
No. 161239    
>>161237
ffmpeg -i c.mp4 -c:v libx264rgb -preset ultrafast -pix_fmt yuv420p try.mp4
Если бы я хоть немного понимал в программировании, я бы может и сделал костыль для перегонки с rgb в yuv, но увы.
No. 161241    
>>161239
Окей, в yuv444p оно нормально делает, а в yuv420p не хочет. Не хочу с этим мучатся, лучше просто буду писать в следующий раз через OBS.
No. 161243    
>>161239

Будьте любезны «rgb» убрать.
No. 161244    
>>161243
Что бы получить на выходе розовое видео? Или ты думаешь, что я не протыкал все комбинации в тщетных попытках?
No. 161251    
оригинал слева.png - (1.10MB, 1431×792)
161251
>>161244
Что такое c.mp4? Если то же, что и 162220659081.mp4, то результат ffmpeg -i 162220659081.mp4 -c:v libx264 -preset ultrafast -pix_fmt yuv420p d.mp4 справа. Мощных цветовых отклонений в фоне в сравнении с оригиналом нет. Вы действительно пытались, что пытались? Настолько серьёзный баг в собранном убунтовцами кодировщике или просмотровщике быть почти наверняка не может.
No. 161252    
d.mp4 - (2.43MB, 1920×1080)
161252
>>161251
Собственно, результат ffmpeg -i 162220659081.mp4 -c:v libx264 -preset ultrafast -pix_fmt yuv420p d.mp4.
No. 161269    
>>161252
Заново пересобрал ffmpeg и все библиотеки с исходников и заработало.
No. 161275    
>>161269
> Заново пересобрал ffmpeg и все библиотеки
Ничё себе. Ещё и библитеки собственной сборки. Для чего? Интересно. Так-то, если поддержку какого кодека добавить, достаточно --enable-что-нибудь добавить, довавить в cпекфайл нужные зависимости и поставить пакет. Но вы и билиотеки собственной сборки делаете.
No. 161278    
>>161275
Работает? Работает. Вот и все.
No. 161279    
screenshot.webp - (77.47KB, 1200×947)
161279
Подтверждаю мнѣніе >>161227 гиперссылкою на разсказъ https://mail.gnome.org/archives/gthumb-list/2012-September/msg00000.html о томъ, что gThumb понимаетъ WebP съ сентября 2012 года (на будущій годъ будетъ десять лѣтъ).

Скриншотъ прилагаю. (Прошу вниманія на послѣднюю строчку.)
No. 161280    
81927968_p0.jpg - (1.15MB, 1400×1980)
161280
>>161278
Не хотите отвчеать? Жалко.
No. 161282    
>>161280
Мне нечего отвечать. В гайде написанно: "if your repository provides $LIBRARY version > $VERSION, install with "sudo apt install $LIBRARY", otherwise you can compile."
No. 161283    
>>161275
Использую генту.

>Так-то, если поддержку какого кодека добавить, достаточно --enable-что-нибудь добавить, довавить в cпекфайл нужные зависимости и поставить пакет.
Разве это так работает? Где? С ffmpeg вроде если оно не залинковано туда (на стадии линковки, после конпеляции), то и поддержки не будет. Ну, если это внешняя либа, конечно. Не помню, как там с отключением/включением внутренних фич, но я бы полагал, что тоже на стадии компиляции.
No. 161284    
>>161282
Ну, тут в голове мимоходом куча вопросов появляется. Что за гайд? your repository provides $LIBRARY version > $VERSION окозалось неправой из-за отсутствия нужных версий или отсутствия библиотек? Если из-за отсутствия нужных версий, то почему это так, если ставили по убунтовскому спекфайлу? А если при этом ставили не по убунтовскому спекфайлу, то зачем собирали и ставили ПО вне системы Убунту; выбрав bleeding-edge ffmpeg, из-за чего не оказалось нужных версий библиотек?
No. 161285    
>>161283
> скомпилировать и поставить поставить пакет
fxd
No. 161286    
>>161285
Ну да, я так и понял, но потом. Пересобирать все зависимости и правда необязательно лол.
No. 161288    
>>161284
Что за гайд?
Он один.
>окозалось неправой из-за отсутствия нужных версий или отсутствия библиотек?
Нет, просто мне захотелось скомпилировать, problems?
> Если из-за отсутствия нужных версий, то почему это так, если ставили по убунтовскому спекфайлу?
Не знаю, что такое спекфайл и причем он тут.
> А если при этом ставили не по убунтовскому спекфайлу, то зачем собирали и ставили ПО вне системы Убунту
Вообще не понял.
>выбрав bleeding-edge ffmpeg, из-за чего не оказалось нужных версий библиотек?
Тоже не понял.
Какой-то у прогромистов специфический троллинг вопросами, уже не первый раз наблюдаю. Так вот хочу вам сказать, что простолюдины этого троллинга не понимают.
No. 161290    
ubuntu.webp - (14.72KB, 340×607)
161290
>>161288
> Нет, просто мне захотелось скомпилировать, problems?
Nicht.
> Не знаю, что такое спекфайл и причем он тут.
Рецепт для создания пакета дистрибутива, оговаривающий его имя, зависимости, компиляцию, параметры установки и исправления багов специфичные для того дистрибудива. По спекфайлу официальные утилиты дистрибутива могут собрать пакет и установить, встроив его в дерево пакетов. Пакетная система используется Убунту и многими другими дистрибутивами для простого распределения и установки софта, управления зависимостями и файлами ПО, и так далее.

Говоря чуть проще, Убунту считает, что никакой софт за пределами пакетной системы не существует, поэтому любое очередное обновление или установка другого ПО потенциально может установленный вне системы софт — особенно ключевой и сложный, как собранный вами ffmpeg — затереть, изменить или иначе поделить на 0, приводя к багам навроде тех, с каким столкнулись выше, а то и полной трудноустранимой неработоспособности софта и системы в целом.

Стоит пользоваться официальными спекфайлами разработчиков дистрибутива не только по тому, что спекфайлы и пакеты — официальный стандартный метод сборки, дистрибуции и установки софта, не только по описанным выше причинам, но и потому, что это проще определённо, если настроена система их сборки: разработчиками дистрибутива выбрана стабильная версия исходников, совместимая с системой, известные баги специфичные для дистрибутива решены за вас, подобраны настройки, которые не ломают ПО, уже прописаны необходимые зависимости, и так далее.
> выбрав bleeding-edge ffmpeg, из-за чего не оказалось нужных версий библиотек?
Выбрали было, видимо, самую новую современную версию исходников ffmpeg для сборки, из-за чего в Убунту под неё не оказалось готовых пакетов библиотек, и библиотеки те понадобилось собирать. Можно было взять более старый код, версия которого соответствует версии стандартного пакета из репозитория, тогда условие $LIBRARY version > $VERSION выполнилось бы.
> Он один.
Eh? Держите, минимум, четыре.
https://help.ubuntu.com/community/CompilingSoftware
https://help.ubuntu.com/community/CompilingEasyHowTo
https://packaging.ubuntu.com/html/index.html
http://archive.ubuntu.com/ubuntu/pool/universe/f/ffmpeg/ffmpeg_4.2.4-1ubuntu0.1.dsc

> Какой-то у прогромистов специфический троллинг вопросами
Щто поделать, если полезную информацию из некоторых категорий пользователей приходится вырывать раскалёнными клещами, а те молчат как партизаны.
No. 161291    
>>161290
>затереть
А /usr/local для меня по приколу сделали, да?
>Стоит пользоваться официальными спекфайлами
Вот когда добавят туда пуль и qsv, тогда и буду, а пока я лучше знаю, какие кодеки мне нужны.
>Eh? Держите, минимум, четыре.
Я предпочитаю использовать официальную документацию и следовал гайду на траке.
>Щто поделать, если полезную информацию из некоторых категорий пользователей приходится вырывать раскалёнными клещами, а те молчат как партизаны.
И чем эта информация для тебя полезна. Любишь довольно цокать языком при виде очередного ньюфага в вакууме?
No. 161292    
>>161291
Не пуль, а пульс, не дожал кнопку.
No. 161293    
https://en.wikipedia.org/wiki/Debian_build_toolchain

Таки погуглил про спекфайлы, похоже называть их спекфайлами для debian-based неправильно, потому что spec - это для rpm-based и выдает инфу о том, как переводить пакеты с одной системы на другую. В дебианах dsc отдельно, скрипты для сборки отдельно.

mimoshol
No. 161296    
1600208298568.jpg - (221.36KB, 1280×960)
161296
>>161291
> А /usr/local для меня по приколу сделали, да?
Я не знаю, куда и с какой целью ffmpeg ставили, поэтому гадаю. Учитывая, что библиотеки те из указанного guide статично впиливаются в ffmpeg, затереть оно ничё не должно. Если всё по тому guide сделали, баг теоретически мог быть непосредственно в исходниках последней версии, либо возникнуть из-за несовместимости последней или убунтовской версии какой-то из библиотек с последним релизом ffmpeg. Но это не точно.
> Вот когда добавят туда пуль и qsv, тогда и буду, а пока я лучше знаю, какие кодеки мне нужны.
Добавьте туда включение тех кодеков сами, это и предлагается. Проще, чем ручками собирать часть зависимостей (libx264-dev версии большей, чем указано в track, в репозитории есть, например).
> Я предпочитаю использовать официальную документацию
Приведённые странички с Убунту — тоже официальная документация по сборке и установке софта с исходников, а также официальные исходники ffmpeg для Убунту вашей версии. guide с track, хотя покрывает один весьма конкретный «случай», для этого случая вполне разумный. Единственно что, ПО использующее ffmpeg при таком варианте не сможет использовать добавленные в собранное кодеки.
> И чем эта информация для тебя полезна.
Касательно конкретно сказанного, мне интересно, зачем и почему именно такой необычный и затратный метод, и какая среда и цель привели к нему, а также к тому багу. Раскрываемая же пользователями информация касательно багов и проблем полезна, чтобы их решить и не натыкаться на них самому.
> Любишь довольно цокать языком при виде очередного ньюфага в вакууме?
Разве что в ваших фантазиях.

>>161293
Не совсем корректно, да. Но тут под спекфайлами подразумевается общее название для этого всего. Например, для Gentoo это будут ebuild-ы, для Arch-а — PKGBUILD-ы.
No. 161298    
>>161291
> И чем эта информация для тебя полезна. Любишь довольно цокать языком при виде очередного ньюфага в вакууме?
Капец ты чиочанька конечно, немного в шоке. Тебе осведомлённая чиочанька всё прекрасно расписала (на что у меня не хватило бы терпения), а ты ещё вредничаешь, а потом такие как ты жалуются, что программисты злые.
No. 161299    
>>160962
> У PaleMoon тамова picrelated.
И действительно вайтлист расширений. Есть подозрение, что изначально это было сделано для того, чтобы заранее защититься от потенциальных RCE через уязвимости в обработчиках неизвестных науке форматов. Или что-то вроде этого. Впрочем если такой «специально подготовленный файл» уже находится локально, то всё уже весьма печально в любом случае, и подобная перестраховка выглядит немного излишней. Видимо, в больших проектах предпочитают перебдеть. Или снять с себя ответственность на всякий случай.

>>161227
Вот как раз в апстриме GNOME всё местами довольно... странно. Есть вот, например, такой полуавтономный компонент gdk-pixbuf¹, который в какой-то там версии прямо вынесли наружу из основной библиотеки GTK. Он отвечает за поддержку разных форматов изображений. Вынести-то вынесли, а форматы новые как-то в него добавлять не особо горят желанием. И даже наоборот, недавно вот JPEG2000 удалили. Но вот сторонний разработчик дописал для этого gdk-pixbuf отдельный плагин с поддержкой WebP², предложил разработчикам включить его в дерево — те не хотят, говорят мол, что pixbuf этот по большому счёту полузаброшен, и новый код сильно усложнит им дальнейшую поддержку³. Соображениями безопасности опять же прикрываются. И вроде бы всё это не такая уж и беда — отдельный плагин, который тот самый webp-pixbuf-loader, ведь не делся никуда, архитектура gdk-pixbuf позволяет ему существовать отдельно. Вот только и мейнтейнить его в дистрибутивах нужно тоже отдельно. Чувствуете, куда ветер дует? Да-да. Чтобы в Debian с его бюрократией вот так запросто взять и пронести новый пакет, при том не особо-то и нужный вроде бы как? Неслыханное дело. Вот и нет его там до сих пор! В Ubuntu, соответственно, тоже. Баги и там⁴ и там⁵ заведены, но толку пока нет. Не все дистрибутивы одинаково хороши для чего угодно.

Впрочем, реализовать поддержку разных форматов изображений в GTK-программах можно и в обход pixbuf — никто не запрещает, было бы желание с разными библиотеками вручную возиться. В gThubmb именно так и сделали, причём ещё в 2012 году. А вот в EOG не хотят — есть, говорят, тот loader, им вот и пользуйтесь⁶. И вроде бы и правильно говорят, вот только легче от этого не становится. Вот как-то так оно всё в GNOME и происходит.

При чём тут корпорации, спросите вы? Да при том, что даже с таким немного странным решением со стороны gdk-pixbuf некоторые библиотеки изображений прекрасно уживаются. Да-да, они просто носят в себе эти плагины-loader'ы для pixbuf помимо самой библиотеки. То есть установка пакета с этой библиотекой сразу же добавляет в pixbuf (а значит, и в весь GTK) поддержку соответствующего формата. Так, например, делают AOM с AVIF и даже компания Struktur AG с HEIF. Но только не Googlе! Никакого pixbuf-плагина в составе их libwebp нет и не наблюдается, несмотря на открытый баг⁷. Заявляют, что для них не в приоритете вообще! Должно быть, такую разработку ни в отчёт толком не включишь, ни на график не нанесёшь. Пыль, значит, в глаза менеджерам пустить сложновато. Вот и нет никакого pixbuf-плагина в libwebp. Так и живём.

_________

¹ — https://gitlab.gnome.org/GNOME/gdk-pixbuf
² — https://github.com/aruiz/webp-pixbuf-loader
³ — https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/103#note_674097
⁴ — https://bugs.launchpad.net/ubuntu/ source/gdk-pixbuf/ bug/1864215
⁵ — https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951113
⁶ — https://bugzilla.gnome.org/show_bug.cgi?id=700751#c2
⁷ — https://bugs.chromium.org/p/webp/issues/detail?id=227

>>161241
Ну или через SimpleScreenRecorder. Тащить то вещательное чудище необязательно.

https://www.maartenbaert.be/simplescreenrecorder/

>>161296
Да пусть совершает ошибки и превращает систему в Slackware самостоятельно, если так уж сильно хочет! Тоже метод познания в общем-то. Впрочем, произносить все эти вещи в любом случае крайне полезно. Аплодисменты вашей выдержке!
No. 161301    
>>161298
Мне рассказывают то, что я уже прочитал в документации и манах.
>>161296
>зачем и почему именно такой необычный и затратный метод
Мне так захотелось.
>>161299
>Ну ты и чиочанька.
>Slackware
Кисленько. Впрочем, я действительно много действий делаю наугад. В любом случае, я на убунте не храню никаких важных данных и если понадобится, я просто снесу все и поставлю заново, но это будет очень не скоро ибо не скоро я пойму, как ваше программирование работает.
No. 161302    
> Не знаю, что такое спекфайл
> Вообще не понял.
> Тоже не понял.
> Мне рассказывают то, что я уже прочитал в документации и манах
No. 161304    
>>161301
Оная убунта не в виртуалке ли стоит?
No. 161305    
>как ваше программирование работает
Это системное администрирование вообще-то. Причем только одной машины.
Вообще, даже если ты не намазываешь жиру, этот разговор скорее как комедия читается. Что один ведет себя как арчешкольник, что другой с умным видом пытается что-то ему объяснить.
No. 161306    
>>161302
Я старался.
>>161304
Нет.
>>161305
>Администрирование
Разве компиляция и тому подобное это администрирование?
>Спойлер
Я не намазываю, я уже выливаю.
No. 161307    
>>161306
>Разве компиляция и тому подобное это администрирование?
Думаю да, можно так назвать, потому что в данном случае это тупо процесс установки ПО. Здесь ты, как пользователь, используешь инструменты, которые к тому же работают как целая инфраструктура.
>Систе́мный администра́тор (англ. system administrator — дословно «администратор системы»), ИТ-администратор — сотрудник, должностные обязанности которого подразумевают обеспечение штатной работы парка компьютерной техники, сети и программного обеспечения. Зачастую системному администратору вменяется обеспечение информационной безопасности в организации. Разговорное название — сисадми́н (англ. sysadmin).
Возможно даже, такое нельзя назвать даже системным администратором, потому что это банально пользователь ПеКа, но на мой взгляд, это зависит от того, насколько глубоко ты занимаешься этим. Ты как бы можешь в принципе выполнять работу мэйнтейнера всего (не очень большого) дистра, теоретически.
Программист же пишет программы. Ну, те, которые канпелируют потом.
Лол.
No. 161308    
148706018921.webp - (133.96KB, 500×354)
161308
>>161305
Шутка прошла мимо вас: объясняющий и арчешкольник — одно лицо.

>>161306
Компиляция это компиляция. В вашем случае она часть процесса администрирования.
No. 161309    
>>161308
Комедия одного актера - тоже комедия!
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]