Firefox for Android Beta (84.0.0-beta.2), не видно.

Не видно разницы между 8 бит и 10 бит

А давайте ещё вместо webm прикрутим какой-нибудь дурацкий формат, который почти никто не использует и чтобы его открывать не все могли!

>>156270
Webp уже прикрутили вместе, а не вместо, он гораздо хуже во всех отношениях!

Pale Moon
28.16.0 (32-bit)

Не видно.

Ах, и седьмая Винда, если это важно и нужно.
>>156273

А вот объясните бестолковому, пожалуйста.
Когда речь идёт о добавлении поддержки какого-либо типа файлов для доски (WEBM, WEBP), имеется в виду только то, что теперь этот файл можно прикрепить к сообщению? Или же подразумевается, что прикрепляемый файл должен воспроизводиться\отображаться в браузере на любом устройстве средствами самого сайта?

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

Для того, чтобы считалось, что "файл поддерживается", нужно чтобы оба видео на сайте открывались? Или во втором случае это уже лично моя проблема и Совус тут ни при чём?

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

А вообще все эти обновления только раздражают, если они принудительные.

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

Было бы здорово, если бы все обновляторы под свои обновления ещё и железки для апгрейда компьютера высылали бесплатно.

>>156276
Понятно, спасибо.
Тогда не ясно зачем спрашивать "Видно или нет?".
Прилепилось? Прилепилось. Значит, всё ок?

Ме тоже видо.

Otter Browser, GNU/Linux, ничего не видать. В консоли браузера:

WebKit ошибка #203: Loading is handled by the media engine

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

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

ет, е видо. икогда е смотрю, though.

Btw, Мицгол, е узаю тебя в гриме.

>>156283
Держи. "Н, н."

Ѿвѣтъ на вопрос >>156278 довольно прост: нѣтъ смысла прикреплять видеозапись к сообщению, если её очень мало кто увидит, особенно если среди неувидевших будут не только тѣ потенциальные зрители, которые сами выбрали свой удѣлъ (напримѣръ, когда приняли рѣшеніе купить мобильное устройство от Apple или рѣшеніе остаться на браузере Pale Moon), но и очевидно болѣе крупные сегменты пользователей.

>>156286
Ясно, понятно. Спасибо за разъяснения.
>рѣшеніе остаться на браузере Pale Moon
FireFox стал жирным и неповоротливым. А ещё после какого-то там обновления (чёртовы обновления!) полностью сломали совместимость со всеми плагинами, которыми я пользовался. И я подумал, пускай тогда в баню идут с таким подходом.
А в хромобраузере история не отключается. Либо каждый раз чистить ручками, либо ставить костыли и бить в бубен, чтобы отключилась. Слишком много лишних телодвижений ради элементарной функции. На фиг.

О старая Опера. Как же я по ней скучаю. По RSS-ленте и удобнейшим закладкам.
Потом они всё наобновляли и от Оперы только название осталось.

>>156266
Видно, но только слайд-шоу.

>>156295

Хром?

>>156266
На телефоне в плеере даши жёсткое слайдшоу. Но плеер даши — то ещё добро по производительности. Да и телефону уже куча лет.
Будь видео меньшего разрешения, могло бы быть нормально.

>>156266
Да, видно.

Firefox 78 GNU/Linux

По адресу 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 только восьмибитными компонентами цвѣта или же и десятибитные также поддерживаются.

Огнелиса, 10 окон, полет нормальный.
>>156287
>жирным и неповоротливым
Да, когда на 8 вкладках браузер кушоет 1гб, это не круто, но из всех мощных браузеров огнелиса самая лучшая. Гигабайт у меня все равно 12, так что склерозом не страдаю. А плагинами не пользуюсь, ничего не скажу.

Не видно, чром на прыщах.

78 Firefox, Linux - все окей

>>159411
Блджад, у меня дефекткный браузер.

Chromium 89, Linux
It works!

>>159412
Странно конечно

>>159423
Чего странного. Может он так его собрал. Или пакеты устаревшие. Или ОС такая.

>>159424
Всё может быть и тем не менее.

>>159424
Просто хромиум из репозитория Debian Bullseye.

Допустимо ли небольшой опрос по кодекам, браузерам и по тому, у кого что открывается?
Во всех трёх видео есть звук.

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].

safari норм

А тем временем отрывок из >>156266 в mpv вызывает лаги и жёсткое выпадение кадров, но преспокойно воспроизводится в Firefox (87). Бред какой-то. Это как вообще?!

По опросу, проведенному любителями новых кодыков, у 100% любителей новых кодыков открылись новые кодыки.
Как же хочется видеть вас пеплом в печах, неугомонные.

>>160484
88 firefox, все три видео ОК

>>160488
Предположу, Лиса пытается запустить видео то об GPU, mpv либо прямо от CPU, либо fallback'нулся на CPU, после того как GPU-способ не сработал. Они есть разные. На одной машине ловил, что vaapi работало, а opengl-hq нет, например.
BTW, Луна в 10-битное видео то не может.

>>160489
Ну знаете, меж миниатюрной кашей из блоков навроде https://410chan.org/b/arch/src/153746341150.webm, которая открывается у всех, и более-менее смотримым видео, которое у кого-то не открывается, я выберу открывающееся не у всех для публикации на чане. Возможно, кинув VP9-версию на catbox.
Вопрос в том, как сделать так, чтобы некаша корректно открывалась у максимального числа.

>>160491
Телепатия на высшем уровне! Действительно, хоть и в обоих случаях происходит fallback на софтовый декодинг, но cо стандартным vo=gpu mpv его гладко воспроизвести отчего-то не может, а вот с vo=vaapi — пожалуйста. Однако у vaapi сломано OSD полностью, что делает его, так скажем, не слишком привлекательным вариантом. Включение-отключение opengl-hq (а точнее, gpu-hq) на картину влияет весьма слабо, а вот принудительный рендеринг через Vulkan (gpu-api=vulkan) неожиданно исправляет всё! Ну и дела.

Мрачно подозреваю, что автор сообщения >>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 года остаётся незакрытым.

>>160489

> Как же хочется видеть вас пеплом в печах, неугомонные.

>>160530
я решил, что видео без звука

Пусть будет здесь.
Неча каждый тред угонять обсуждениями этой лабуды.

>>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.
Зачем я это всё пишу?

Окей, просите здесь, буду здесь. Тест третий поехал.

>>160546
Параметры:
ffmpeg -i in.webm -c:v libvpx-vp9 -c:a libopus -b:v 193K -b:a 64K out.webm
При таких настройках получился слегка меньший битрейт, а именно на 33 килобита в секунду и заметно меньший размер. Учитывая, что эти килобиты глазами не видно, качество внешне неотличимо, размер заметно меньше и открывается на телефоне тоже, я смог добиться требуемого тобой результата, могу радоваться за себя. Вот так вот.

>>160547
> качество внешне неотличимо
Лолнет.

>>160548
Ватсон, убери микроскоп.

>>160550
Нельзя убрать того, чего нет.

Ну и таки не поленись вы глянуть адекватные настройки для VP9, качество то было бы заметно лучше, чем у вывода x264 при том же размере. Да и тот видос с x264 могли бы лучше пожать. Так что нет, радоваться за себя пока не можешь.

>>160554
>адекватные настройки
Стандартные всегда самые адекватные, а битрейт я поменял, что бы не раздувало. Качество я глазами и ушами отличить не могу, уверен, многие тоже. А открывается у всех и размер лучше. Танцевать с бубном и настраивать каждый пиксель ради 0.1Мб я не буду во первых потому, что не умею, а во вторых, потому что вряд ли мне когда-то будет интересно научится страдать на ровном месте.
>и тот видос с x264 могли бы лучше пожать
Возьми и пожми, я не вижу смысла выдавливать из библиотеки того, на что она не расчитанна.
>Ну и таки не поленись вы глянуть адекватные настройки для VP9, качество то было бы заметно лучше, чем у вывода x264 при том же размере
Качество уже заметно лучше.
Боже, какие унылые тролли набижали, я сливаюсь, торжествуйте.

>>160557
> x264 default preset
> 2021
> адекватные настройки
Also
> выдавливать из библиотеки то, на что она не расчитана
> Стандартные всегда самые адекватные
> Танцевать с бубном и настраивать каждый пиксель ради 0.1Мб
> спойлер

>>160557

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

Нѣтъ.

https://old.reddit.com/r/AV1/comments/k7colv/encoder_tuning_part_1_tuning_libvpxvp9_be_more/

>>160613
https://trac.ffmpeg.org/wiki/Encode/VP9

>>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

>>160617
Вытирает пену
Нет, я ничего не имею против вики, очень хорошая вещь, только если бы ты когда нибудь попробовал енкодить в два прохода вп9 на i3-7020U, ты бы эту ссылку не дал, потому что как бы я не бил настройки, меньше чем за час я эти две с половиной минуты не обработаю.

Так как этот процессор располагает двумя двухпоточными ядрами, то я б рекомендовал параметры «-tile-columns 2 -threads 4» (из гугловской инструкции https://developers.google.com/media/vp9/settings/vod#tiling_and_threading_recommendations взятые) в сочетании с ненулевым значением параметра cpu-used.

>>160647
Да, спасибо за Америку.
>>160609
Раньше x264 смотрели и никто не жаловался, а сейчас тебе vp9 с артефактами. Рекомендую менять глаза или там мировоззрение, не знаю что с тобой не так.

>>160668
Научи быстро кодировать в av1 (конечно же через ffmpeg), потому что я документации не нашел, в то время как документация vp9 позволила мне добиться скорости 0.7-0.8, что вполне приемлемо.

>>160664
> Being Meguca is Suffering
Must save Megukas! Should end suffering!

Раньше было раньше.

В сообщении >>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.)

>>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? Не могу. Это затрудняет адопцию формата; хотя речь в посте не про это.

> x264 слева
fxd

>>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

ffmpeg -i in.webm -c:v libx264 -b:v 180K -crf 32 -tune animation -preset veryslow -c:a libopus -b:a 64K out1.mp4

Иронично, но x264 справился лучше.
>>160674 описал что именно x264 делает лучше.
Кроме того, лично мне было приятней смотреть на работу x264.
Кому не влом, попробуйте vp9 2-pass сделать, может оно выдаст лучший результат.

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

Как можно видеть, на статических картинах vp9 дал более красивый результат, в то время как картины с резкими переходами сильно размылило, чего у x264 не наблюдается. Так что в целях экономии времени, что бы не высиживать этот ваш шакальный av1 можно делать в один проход x264 и радоваться.

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, но не ясно стоит ли оно того.

>>160690
>Разве что добивать при помощи -crf, но не ясно стоит ли оно того.
В общем я потыкал и не стоит. x264 то же выдает, а скорость нормально так выше.

Аналог видеоцитаты >>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 на виндѣ и видно, и не подтормаживает.

Вамъ видно ли? Не подтормаживает ли?

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

Я не понимаю, почему это так; подозреваю глюк кодировщика.)

Firefox for Android Beta (89.0.0-beta.5), видно и не тормозит.

Google Chrome 90.0.4430.91 на одиннадцатом Андроиде: видно, но тормозит (чѣмъ показывает наглядно, что libgav1 отстаёт от dav1d).

>>160709
Не только первый. При стандартном значении -g когда он срывается с кровати при виде внезапно появившейся девы, все тоже рассыпается.

>>160707
Firefox 88, GNU/Linux: видно, но в резких переходах между сценами начинает подтормаживать, а где-то после 2:11 картинка замирает и больше не обновляется; mpv 0.32.0, libdav1d 0.7.1, софтовый декодинг: видно, но в переходах между сценами также подтормаживает (mpv позволяет увидеть, что происходит небольшое, но заметное выпадение кадров, а также лёгкий рассинхрон, который быстро проходит), местами в сценах с высоким битрейтом воспроизведение замирает на долю секунды, а после 2:11 начинаются жёсткое выпадение кадров и сильный рассинхрон.

И всё-таки кодек из будущего!

>>156266
Оверчан, Сяома, всё работает, ничего не тормозит.

Сейчас ещё раз свѣжимъ взглядомъ посмотрѣлъ на тормоза >>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.)

>>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.

>>160727
> Ещё получается, что автору сообщения >>160720 надо бы обновить mpv, а не то версия dav1d не совершенно свѣжая.
Ладно-ладно, в моём дистрибутиве 0.8.2 уже на подходе, как только так сразу! Посмотрим, смогут ли те оптимизации преодолеть аппаратные ограничения.

>>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

> Шебпфанатики: везде играется! Нетоповых и необновленных конфигураций не существует! Никаких проблем! Переходим!
> Также шебпфанатики: надо покостылять тут и тут, а ещё здесь подпорочку, а вот там уже начали костылики внедрять! Через неделю — <ненужноформат> на марсе!

>>160739

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

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

>>160968

Ваша метафора про марс основана на названии двойного выигрыша в нарды?

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

«only common, stable formats» (c) не_баг_а_фича.webp

> only common, stable formats
И в ~2015-ом году, когда Мозиловцы написали тот костыль, фраза была корявой по отношению к идущему там ниже коду. Потому, что множество стабильных форматов список тот не включает. Потому, что XPM, ICO и BMP не сказать, чтоб common. Особенно XPM.

Контраргумент >>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 (этот послѣдній замѣтно лучше двух предшествующих результатов, хотя объём файла чуть меньше).

⑦ Кроме того, остающиеся от внесения потерь артефакты JPEG (и «расходящиеся волны» вокруг линий, и «вьющаяся мошкара» вокруг мелких деталей, и «размытие по квадратику» у острых углов и у диагоналей) гораздо более отвратительны, чем артефакты WebP (мягкое «умное размытие», сперва подавляющее наиболее слабоконтрастные детали и текстуры, от которого деревянные и кожаные и каменные и металлические поверхности постепенно начинают выглядеть всё более похожими на гладкий пластик, а лица людей «прихорашиваются» устранением морщин и пор кожи, напоминающим эффект от наложения пудры или тонального крема) при равном объёме файла.

На примѣрѣ >>/a/17124 ловится ещё одинъ багъ въ кодировщикѣ: на ѿмѣткѣ времени 01:15.206 расположенъ чёткій keyframe, а до того примѣрно пять секундъ кряду точно то же сáмое изображеніе (въ видѣ стопъ-кадра) торчитъ предъ зрителемъ въ до крайности размытомъ видѣ.

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

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

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

③ И у видеозаписи >>/a/17106 та же проблема.

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

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

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

Чего они тамъ въ Альянсѣ — на аниме не тестируютъ свои подѣлія, что ли?

>>161015
>«использовать проверенное» в сём случае как раз И означает использовать WebP.
Угу. При том, что он не поддерживается кучей просмотрщиков и зачастую приходиться устанавливать сторонний софт, просто что бы позырить в WebP. Вот когда сделаете, что бы он везде работал, тогда и посмотрим. А jpeg и png работают безотказно.

>>
>>161174
> При том, что он не поддерживается кучей просмотрщиков
В браузере открой, солнышко.

>>161175
> просматривать картинки web-браузером
Не скатывайтесь до.

>>161174
Им это уже не раз объясняли, но, как видишь, турбо-демагогией удалось аж вывернуть наизнанку: это, оказывается, форсящийся последние годы вебп, о котором никто и не слышал раньше, "стабильный". За такое поведение в разговоре, слепое закидывание пропагандой, и называю их формато-сектантами.
О чём говорить, если отдельные сумасшедшие перед постингом(!) специально(!!) конвертируют обычные картинки в своё шебп(!!!). Что это есть, как не тот самый троллинг в особо крупных размерах, в котором они пытаются обвинять других. Кстати, один из них вроде и признавался, что специально поджигает.
Так что можешь не пытаться в по-существу, там будут Мицгол-стены про попиксельные разборы картинок, "все корпорации уже внедрили, негоже сидеть в стороне" и т.п., а как ещё и личная армия сочувствующих подключится, то туши свет.
Всё просто. Увидел шебп/ав1/10бит сектанта — харкни ему соплёй в рожу. Только такое обращение за осознанное, умышленное забивание коммуникационных каналов своей мелкой технической бредятиной.

>>161178

>>161178
А то твоё сообщение не троллинг и демагогия, солнце. Ответить на такое можно только следующим образом - у меня линукс и всё работает! Мир спасет только следование стандартам, а те кто, кто посмел не подчиниться требованиям прогресса и новым спецификациям будут аннигилированы Столманом и Линусом Торвальдсом в самое ближайшее время. Алоха народ.

>>161180
> Алоха народ
Это по таджикски?

>>161181
По Горно-Бадахшански.

>>161181
Художники не рисуют в webp. Буры не выкладывают в webp. А ну прекрати конвертировать немедленно сейчас же!

>>161183
Все всё выкладывают и открывают в браузерах и модных вьюверах, только у вас проблемы какие-то.

>>161180
Когда на каждые новые 5~10 процентов сжатия внедряют новый формат, это не прогресс, а бедлам. У себя потестите, если вам не терпится, а внедрять извольте так, что бы оно того стоило и что бы ни у кого не возникало проблем.

>>161185
Stop it already. For he won't.

>>161187
Так оно уже давно без меня внедрено и стандарт де-факто, что я поделать то могу с этим? Конвертировать в jpg? И опять же, удивляют люди у кого НЕ ОТКРЫВАЕТСЯ, что у вас за рабочее окружение, оборудование?

>>161190
>И опять же, удивляют люди у кого НЕ ОТКРЫВАЕТСЯ
Много людей сидят на старом железе и старых осях, не имея возможности обновится и которые не желают страдать с "модерными" жЫрными просмотрщиками (или как просматривать картинки в браузере, прости господи), а просто хотят пользоваться компьютером.
>Так оно уже давно без меня внедрено и стандарт де-факто, что я поделать то могу с этим?
Во-первых не стандарт и до стандарта, если другой новый кодек не вытеснит, пройдет еще лет 5-10.
>что поделать?
Не усугублять. Вы как психи-фанатики с больной упертостью впариваете людям свой WebP и это раздражает. Многие люди не любят WebP просто потому, что вы его силой пихаете.

>>161194
Да никто никому ничего не впаривает, вам не нравится, потому что сидите на семерках и икспи(до сих пор есть и такие уникумы), что в любом случае, по совокупности факторов приведет вас к чему то очень нехорошему. Относительно стандарт/нестандарт, ну каждый третий файл на бордах, простите этого самого формата. И он будет вероятно употребляться ещё чаще, т.к. юзеров с такими аппаратными ограничениями явное меньшинство. Дело не в моих хотелках(мне все равно по большому счету), а в объективной реальности.

>>161196
>Да никто никому ничего не впаривает
В Мицгола пальцем тыкнуть?
>потому что сидите на семерках и икспи
Сижу на десятке плюс убунте 20.04 ЛТС, нигде нативный просмотрщик не поддерживает вебп.
>Относительно стандарт/нестандарт, ну каждый третий файл на бордах, простите этого самого формата.
Ну, я сомневаюсь, что кроме Мицгола и еще парочки любителей новый кодеков, кто-то сидит и специально переписывает картинки в WebP, как скачалось так и есть, а на сайтам выгодней использовать вебп, потому что размер.
> И он будет вероятно употребляться ещё чаще, т.к. юзеров с такими аппаратными ограничениями явное меньшинство.
Если не заменится другими кодеками.

>>161196
Объективная реальность: моя мыльница не понимает WebP, мой плеер не понимает WebP, мой телевизор не понимает WebP, мой навигатор не понимает WebP, мой телефон не понимает WebP, мой тостер не понимает WebP. IT-дурачки с магическим мышлением могут сколько угодно кричать про грядущее, но их слова не в силах изменить объективную реальность.

>>161198
А у меня так уж сложилось, там где надо(телефон и десктоп) все прекрасно понимает вебп, более того, скорее всего и у вас такая же картина. А так-то думаю вебп не грядущее, а именно что настоящее и объективная реальность, как вы прекрасно знаете.

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

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

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

Думаю раньше заменится чем джпег даже. Собственно, терпеть вам вероятно где-то два с половиной года еще, видимо.

>>161198
Объективная реальность: это твои проблемы.

>>161199
Людям, которые видят WebP в браузере, не нужен WebP. Им вообще глубоко фиолетово, Gif там или WebP, браузер картинку показывает и ладно. Производить его никто не будет, просто потому, что ни одно устройство его производить не умеет и уже никогда не научится. То есть контента на нём нет, а без этого его распространение ограничено.
Я использую это ваше WebP просто чтобы постить одни и те же аватарки; эту картинку я могу запостить ещё 98 раз минимум.
Аминь.

>>161201
Вообще говоря, сейчас то уже очевидно, что данный формат будет вскорости замещен по всей видимости. Тем не менее я говорил не совсем о браузерах, да и контента создано же весьма прилично. Да он не столь универсален как привычные "старые" форматы, тем не менее истерика которую я наблюдаю, малость несоизмерима с его относительно этой истерики небольшими недостатками. Сильно это меня удивляет, тут никакой Мицгол-евангелист оправданием быть не может. Ну и для веба данный формат действительно полезен, там экономия очень существенная.

>>161204
Меня тоже удивляет, потому что единственно верное его использование — WEBP отдаётся клиенту тогда и только тогда, когда клиент явно указал, что он понимает WEBP (image/webp). Во всех остальных случаях, даже с image/*, отдаётся PNG, JPEG, GIF, BMP. Если завтра WEBP заменят на WEBT, разницы клиенты при такой схеме не заметят. То есть, он изначально создавался как формат, ненужный конечным потребителям.

>>161206
Он создавался для экономии места разумеется и да, это единственно верный способ(а раньше был и единственно возможный). Но так как тут вечный 2003 год, то и неизбежные странности, с неизбежным "навязыванием"(а как иначе, включить то формат уже нужно) происходят.

>>161207
Фигня в том, что имиджборды типа Автобуса предоставляют тебе источники файлов такими, как их залил пользователь, без пережатия и переконвертирования. Однако, для совместимости, например, можно выдавать миниатюры в каком-то одном формате или в таком, какой захочет/сможет клиент. Польза от этого - webp миниатюры будут меньше jpeg миниатюр при том же видимом качестве, например. Сейчас, однако, миниатюра выдается в том же формате, что и формат источника. Вероятно, это захардкожено в движке.

>>161210
Фигня в том, что движок Автобуса, как и прочих, генерирует статические HTML-страницы, так что весь content negotiation идёт лесом.

>>161212
Может, можно извратиться как-то, что под одним и тем же именем файла будут выдаваться разные форматы.

>>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 как стандартных–обычных форматов мы не увидим.

Ещё забыл Твиттор как источник контента.

>>161178

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

Пока что всё наоборот: это твоя харя всё сильнее опоганивается каждым файлом WebP, каждым видео AV1 или десятибитным.

>>161197
Каково название «нативного» просмотровщика картинок в LTS том?

>>161223
EOG. Да брось, будто для Убунты много нативных просмотрщиков. Или ты думаешь, я бы стал менять DE?

>>161215
>контент
>кодирует
По вашей логике получается, я — великий творец контента, затмевающий собой самого Соуса. Я-то думала, что для создания контента надо хотя бы взять мыльницу, пойти куда-то и чего-то нафоткать.
>они до сих пор не подали голос
Ну у меня есть мыльница, она пишет жопег и ави. Выкладывать, например в одноклассниках, я буду жопег и ави соответственно. Т.е. меня, как производителя контента, это ваше WebP никак не касается.

>>161225
Я слабо представляю, что там в Убунту, тем более в LTS.
А вот что EOG не может, это странно, Gnome огромное DE — у таких вроде с поддержкой разных форматов должно быть всё хорошо. У Gnome, впрочем, есть другой «нативный» просмотровщик, который gThumb, он вроде может.

>>161227

>>161226
Не получается. Таких предположений лично на счёт вас не было. К тому же, я помню, что у вас мыльница, и что она пишет в JPEG.
А у меня, например, была квазизеркалка и она писала в NEF.
> AVI
Оно ещё живое? Етить. Какая модель мыльницы? Also, браузеры в AVI не могут, придётся remux-нуть в MP4. Если, конечно, у них там на сервере однокласников такого нет. Среднестатистическая *чанька там едва ли сидит, а если сидит, то с целью потролить обитателей, поди.

>>161229
Если я правильно понимаю происходящее, включили один нативный гномопросмотровщик вместо другого нативного гномопросмотровщика в свою базовую группу пакетов. Сам пакет в репозитории есть.

Also, Firefox и основанные на нём браузеры не поддерживают стандарт H.264. Точнее, не полностью его поддерживают — в данном случае не поддерживается кодирование RGB (gbrp). Так что, если хотите кодировать именно с libx264 для публикации на чанах, то стоит поставить pix_fmt в yuv420p, уменьшив тем качество — в полноцветное yuv444p Лиса тоже не умеет. Таким образом, записи экрана лучше кодировать VP-кодеками, с ними у Лисы этой и ряда других проблем нет.

>>161230
Вы сами заявили, что контент с WebP есть на основании того, что некий картинкохостинг умеет конвертировать загруженные на него изображения в WebP. Я тоже могу конвертировать чужие картинки в WebP.

>>161232
> контент с WebP есть на основании того, что некий картинкохостинг умеет конвертировать загруженные на него изображения в WebP
Ну он и отдаёт их в WebP. Иной раз, вроде, без вариантов. Следовательно, контент с WebP там есть. Такие дела.
> Я тоже могу конвертировать чужие картинки в WebP.
You sure can. Единственно что, не так сильно шакальте.

>>161215
> кодирует Телега
Точнее, дозволяет. Кодирует некоторые виды стикеров вроде.

>>161231
Я удалил пост, не знаю почему не удалилось. А x11grab в yuv не умеет, я сначала думал перекодировать с rgb в yuv, но это невозможно, без кучи геморроя, думал перезаписать через нормальную програму, а потом увидел, что пост не удалился и ты уже написал мне ответ.

BTW, так что за мыльница и сколько ей лет?

>>161231
Also, pix_fmt yuv420p does nothing, точнее, просто пишет, что incompatible pixel format.

>>161236
Полная комманда, которую использовали?

>>161237
ffmpeg -i c.mp4 -c:v libx264rgb -preset ultrafast -pix_fmt yuv420p try.mp4
Если бы я хоть немного понимал в программировании, я бы может и сделал костыль для перегонки с rgb в yuv, но увы.

>>161239
Окей, в yuv444p оно нормально делает, а в yuv420p не хочет. Не хочу с этим мучатся, лучше просто буду писать в следующий раз через OBS.

>>161239

Будьте любезны «rgb» убрать.

>>161243
Что бы получить на выходе розовое видео? Или ты думаешь, что я не протыкал все комбинации в тщетных попытках?

>>161244
Что такое c.mp4? Если то же, что и 162220659081.mp4, то результат ffmpeg -i 162220659081.mp4 -c:v libx264 -preset ultrafast -pix_fmt yuv420p d.mp4 справа. Мощных цветовых отклонений в фоне в сравнении с оригиналом нет. Вы действительно пытались, что пытались? Настолько серьёзный баг в собранном убунтовцами кодировщике или просмотровщике быть почти наверняка не может.

>>161251
Собственно, результат ffmpeg -i 162220659081.mp4 -c:v libx264 -preset ultrafast -pix_fmt yuv420p d.mp4.

>>161252
Заново пересобрал ffmpeg и все библиотеки с исходников и заработало.

>>161269
> Заново пересобрал ffmpeg и все библиотеки
Ничё себе. Ещё и библитеки собственной сборки. Для чего? Интересно. Так-то, если поддержку какого кодека добавить, достаточно --enable-что-нибудь добавить, довавить в cпекфайл нужные зависимости и поставить пакет. Но вы и билиотеки собственной сборки делаете.

>>161275
Работает? Работает. Вот и все.

Подтверждаю мнѣніе >>161227 гиперссылкою на разсказъ https://mail.gnome.org/archives/gthumb-list/2012-September/msg00000.html о томъ, что gThumb понимаетъ WebP съ сентября 2012 года (на будущій годъ будетъ десять лѣтъ).

Скриншотъ прилагаю. (Прошу вниманія на послѣднюю строчку.)

>>161278
Не хотите отвчеать? Жалко.

>>161280
Мне нечего отвечать. В гайде написанно: "if your repository provides $LIBRARY version > $VERSION, install with "sudo apt install $LIBRARY", otherwise you can compile."

>>161275
Использую генту.

>Так-то, если поддержку какого кодека добавить, достаточно --enable-что-нибудь добавить, довавить в cпекфайл нужные зависимости и поставить пакет.
Разве это так работает? Где? С ffmpeg вроде если оно не залинковано туда (на стадии линковки, после конпеляции), то и поддержки не будет. Ну, если это внешняя либа, конечно. Не помню, как там с отключением/включением внутренних фич, но я бы полагал, что тоже на стадии компиляции.

>>161282
Ну, тут в голове мимоходом куча вопросов появляется. Что за гайд? your repository provides $LIBRARY version > $VERSION окозалось неправой из-за отсутствия нужных версий или отсутствия библиотек? Если из-за отсутствия нужных версий, то почему это так, если ставили по убунтовскому спекфайлу? А если при этом ставили не по убунтовскому спекфайлу, то зачем собирали и ставили ПО вне системы Убунту; выбрав bleeding-edge ffmpeg, из-за чего не оказалось нужных версий библиотек?

>>161283
> скомпилировать и поставить поставить пакет
fxd

>>161285
Ну да, я так и понял, но потом. Пересобирать все зависимости и правда необязательно лол.

>>161284
Что за гайд?
Он один.
>окозалось неправой из-за отсутствия нужных версий или отсутствия библиотек?
Нет, просто мне захотелось скомпилировать, problems?
> Если из-за отсутствия нужных версий, то почему это так, если ставили по убунтовскому спекфайлу?
Не знаю, что такое спекфайл и причем он тут.
> А если при этом ставили не по убунтовскому спекфайлу, то зачем собирали и ставили ПО вне системы Убунту
Вообще не понял.
>выбрав bleeding-edge ffmpeg, из-за чего не оказалось нужных версий библиотек?
Тоже не понял.
Какой-то у прогромистов специфический троллинг вопросами, уже не первый раз наблюдаю. Так вот хочу вам сказать, что простолюдины этого троллинга не понимают.

>>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

> Какой-то у прогромистов специфический троллинг вопросами
Щто поделать, если полезную информацию из некоторых категорий пользователей приходится вырывать раскалёнными клещами, а те молчат как партизаны.

>>161290
>затереть
А /usr/local для меня по приколу сделали, да?
>Стоит пользоваться официальными спекфайлами
Вот когда добавят туда пуль и qsv, тогда и буду, а пока я лучше знаю, какие кодеки мне нужны.
>Eh? Держите, минимум, четыре.
Я предпочитаю использовать официальную документацию и следовал гайду на траке.
>Щто поделать, если полезную информацию из некоторых категорий пользователей приходится вырывать раскалёнными клещами, а те молчат как партизаны.
И чем эта информация для тебя полезна. Любишь довольно цокать языком при виде очередного ньюфага в вакууме?

>>161291
Не пуль, а пульс, не дожал кнопку.

https://en.wikipedia.org/wiki/Debian_build_toolchain

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

mimoshol

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

>>161293
Не совсем корректно, да. Но тут под спекфайлами подразумевается общее название для этого всего. Например, для Gentoo это будут ebuild-ы, для Arch-а — PKGBUILD-ы.

>>161291
> И чем эта информация для тебя полезна. Любишь довольно цокать языком при виде очередного ньюфага в вакууме?
Капец ты чиочанька конечно, немного в шоке. Тебе осведомлённая чиочанька всё прекрасно расписала (на что у меня не хватило бы терпения), а ты ещё вредничаешь, а потом такие как ты жалуются, что программисты злые.

>>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 самостоятельно, если так уж сильно хочет! Тоже метод познания в общем-то. Впрочем, произносить все эти вещи в любом случае крайне полезно. Аплодисменты вашей выдержке!

>>161298
Мне рассказывают то, что я уже прочитал в документации и манах.
>>161296
>зачем и почему именно такой необычный и затратный метод
Мне так захотелось.
>>161299
>Ну ты и чиочанька.
>Slackware
Кисленько. Впрочем, я действительно много действий делаю наугад. В любом случае, я на убунте не храню никаких важных данных и если понадобится, я просто снесу все и поставлю заново, но это будет очень не скоро ибо не скоро я пойму, как ваше программирование работает.

> Не знаю, что такое спекфайл
> Вообще не понял.
> Тоже не понял.
> Мне рассказывают то, что я уже прочитал в документации и манах

>>161301
Оная убунта не в виртуалке ли стоит?

>как ваше программирование работает
Это системное администрирование вообще-то. Причем только одной машины.
Вообще, даже если ты не намазываешь жиру, этот разговор скорее как комедия читается. Что один ведет себя как арчешкольник, что другой с умным видом пытается что-то ему объяснить.

>>161302
Я старался.
>>161304
Нет.
>>161305
>Администрирование
Разве компиляция и тому подобное это администрирование?
>Спойлер
Я не намазываю, я уже выливаю.

>>161306
>Разве компиляция и тому подобное это администрирование?
Думаю да, можно так назвать, потому что в данном случае это тупо процесс установки ПО. Здесь ты, как пользователь, используешь инструменты, которые к тому же работают как целая инфраструктура.
>Систе́мный администра́тор (англ. system administrator — дословно «администратор системы»), ИТ-администратор — сотрудник, должностные обязанности которого подразумевают обеспечение штатной работы парка компьютерной техники, сети и программного обеспечения. Зачастую системному администратору вменяется обеспечение информационной безопасности в организации. Разговорное название — сисадми́н (англ. sysadmin).
Возможно даже, такое нельзя назвать даже системным администратором, потому что это банально пользователь ПеКа, но на мой взгляд, это зависит от того, насколько глубоко ты занимаешься этим. Ты как бы можешь в принципе выполнять работу мэйнтейнера всего (не очень большого) дистра, теоретически.
Программист же пишет программы. Ну, те, которые канпелируют потом.
Лол.

>>161305
Шутка прошла мимо вас: объясняющий и арчешкольник — одно лицо.

>>161306
Компиляция это компиляция. В вашем случае она часть процесса администрирования.

>>161308
Комедия одного актера - тоже комедия!

>>161299
Что забавно, с Opus в MP4 у PaleMoon иная история. Есть в белом списке из MP4Decoder.cpp, но не работает. Врочем, соседней функции чуть выше списка запрещается открытие H.264 с Level > 6.2, но видео покодированное с -level 6.2 Луна спокойно открывает. Видимо, тут без отладчика уже не обойтись.

>>161308
Интересно наверно шутить про арч и школьников в 2021

>>161312
причем лет 10 уже как поздновато, наверное.

>>161312
Да не особо.

>>161313
Ну, лично у меня не было готового эпитета к персоналии, которая обладает некоторыми познаниями в линуксах, но при этом обладает странными идеями о юзабилити и вообще о комьюнити. Сказал, что первое в голову пришло.
А что, арчешкольники перевелись что ли? В принципе, это может быть собирательным образом для всех юных ойтишников, которые только начинают постигать линуксы. Вряд ли там что-то сильно поменялось.

>>161315
У арчика как такового слишком уж упала популярность в этой среде за последние 10 лет, раньше эпитет "арчешкольник" имел более прямые отсылки к реальности. Правда сейчас многие школьники ставят себе блэкарч, но это как правило те же люди что и любители кали линукс. т.е. никак уже не "арчешкольники".

>>161315
Да нет, живы и сут: у некоторых арчешкольников уже давно арчешколята появились. Арчу-то уже скоро двадчать лет исполнится: в следующем году, считай.

Комментарий >>160710 нуждается въ нѣкоторой коррекции, поскольку я только что поглядѣлъ на свѣжеустановленный браузер Firefox for Android Beta (версии 89.0.0-beta.10) и убедился в том, что он по умолчанию не поддерживает AV1 (скриншот прилагаю).

Вот если по адресу «about:config» включить настройку «media.av1.enabled» (как на скриншоте; обратите внимание, что значение «true» для этой настройки установлено не по умолчанию, на что указывает появление кнопки «Reset», служащей для сброса значения настройки в исходное состояние), тогда AV1 будет показывать невозбранно.

(О том же и столбец «Firefox for Android» на странице https://caniuse.com/av1 сообщает.)

>>161312
>>161313
>>161318
Школьников, может, и нет, но есть определённая категория людей, которая использует арч и навязывает его остальным, выказывая явное неодобрение как в сторону пользователей винды, так и некоторых дистрибутивов линукса (типа дебиана), которые они считают неправильными. Адекватных аргументов, почему я должен использовать арч, они не предоставляют (хотя свои аргументы они считают адекватными).
То есть, если у меня не ThinkPad с установленным арчлинуксом и тайловым WM и не хочу "развиваться" (идти в сторону этого задротства), то я недалёкий человек.

>>161384
Дебиан если по хорошему - не меньшее задротство ведь. Вменяемые аргументы в пользу арча с удовольствием послушал бы кстати, помимо учебных соображений.

• AUR;
• Весьма свежий софт;
• mkinitcpio;
• pacman;
• arch-chroot, netctl и другие полезные скрипты;
• Ориентированность исключительно на AMD64 (хотя есть и отдельный проект по Арчу на Arm, и другой более слабый отдельный проект для x86_32);
• Удобная система сборки пакетов, готовая к использованию из коробки;
• Как правило разумный выбор пакетов и их зависимостей, относительная гибкость;
• Почти все пакеты dev версий, обычно не нужно отдельно ставить заголовки;
• Прозрачный процесс установки;
• Няшная, удобная архитектура;
• Няшная wiki.

Ещё бы систему, чтобы для части пакетов репозитория патчила PKGBUILDы и автоматом нужное обновляла/пересобирала/ставила, функционируя либо как настройка над pacman, либо равноправно работая в связке с ним.

> типа дебиана
Типа Убунту.
> учебных соображений
С ними, наверное, лучше в другое место. Yocto Project и популярные на предприятиях линукса.

>>161385

• Название
• Иконка

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

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

>>161391
> Ещё бы систему, чтобы для части пакетов репозитория патчила PKGBUILDы и автоматом нужное обновляла/пересобирала/ставила, функционируя либо как настройка над pacman, либо равноправно работая в связке с ним.
А вот здесь мы начинаем подбираться к пределам возможностей той самой архитектуры... и в этот момент можно взглянуть в сторону NixOS с её оверлеями, которые делают ровно вот это вот.

>>161400
> и в этот момент можно взглянуть в сторону NixOS с её оверлеями, которые делают ровно вот это вот
Guix then

>>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-специфичный код для чтения конфигурации декодировщика, оно может заработать. Так-то спецификация открыта, ещё можно попробовать нужный код у Квантума с Хромом стырить.

Неожиданный и неприятный поворот приобретает дѣло проблемы >>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 настолько не реализована в просмотрщиках, что ни в одном браузере и ни в одном видеопроигрывателе такой видеофайл не удаётся нормально промотать к желаемому мѣсту, а только смотрѣть с сáмого начала.

Ѽ, етить.

>>156273
Только что свичнулся с FF на palemoon, подтверждаю фичу.

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-а починили.

При виде подтверждения того, что проблема >>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») выглядят так гадко, что никому «без дополнительных потерь» не нужны, так как в них и без того потерь дохѣрищща.

Ѽ, етить-колотить.

>>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

Поклонникам 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%.

>>162149
Как давно у Вас AV1? Можете описать симптомы?

>>162166
Я чувствую непреодолимое желание кодировать видео и вступать в беседы о достоинствах того или иного видеокодека. Я ощущаю необходимость использовать AV1 для всех моих видео.

>>162166

Или как скажешь брату твоему: «дай, я выну AV1 из глаза твоего», а вот, в твоём глазе JPEG?

>>162170
> webp

Всё ещё неизмѣримо хуже, чѣмъ я предполагал первоначально.

На примѣрѣ видеороликов 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 псевдослучайным образом оказывается забагованною и высокаго качества не достигает.

Ѽ безысходность!

>>163015
Всё-таки моя кофеварка уже слабовата для современного мира. 4k видео не тянет. Хотя 4k, в HEVC с VP9 закодированное, быстрее декодирует, при этом всё равно в real-time не укладываясь.

>>163021

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

Это означает, что рано или поздно перестанет тормозить и во браузере, когда браузеростроители обновят встроенный декодировщик.

Может, конечно (да и должен, навѣрное), напрашиваться такой вопрос: а когда упомянутое в сообщении >>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 ускорит свой цикл разработки, то и к началу октября управится — но ранѣе того ничего не будет.

Это и есть ѿвѣтъ на вопрос, названный напрашивающимся в начале моего сообщения.

>>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 напримѣръ) продолжают подтормаживать въ наиболѣе динамичные моменты аниме.

Возможно ли AVIF кодирование, у которого lossless лучше, чем у WebP, не говоря уж о JXL? И если да, то как и чем его осуществить?

>>163453

https://nowere.net/d/res/3070.html#5262

На второй минуте четвёртой серии аниме «No Game No Life» (WebM съ десятибитными компонентами цвѣта прилагаю) Щиро называет произошедшую «революцию на шахматной доске» словом, которое на слух ну очень напоминает «майдан».

Как оно пишется по-японски?

>>163903
内乱
Nairan

Оптимизм >>163447 оказался неоправданным: позавчера (7 сентября) вышел новый Firefox (версия 92), но поддержку AVIF всё ещё не содержащий, так как она напоролася на своего рода «подводный камень», по адресу https://bugzilla.mozilla.org/show_bug.cgi?id=1729071#c4 упомянутый (несоѿвѣтствіе неопубликованной версии стандарта, в рамках которой, как оказалось, всё же генерируются многие файлы популярными утилитами).

поддержка farbfeld когда

>>164111
интересно откуда у утилит доступ к секретному стандарту если даже мозилла не смогла его оперативно получить.
(и зачем вообще мозилла пишет свой код для работы с этим мемоформатом вместо использования готовых библиотек)

>>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.

При использовании 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%.

(Опечатка: в сообщении >>164143 записано «oxipn», слѣдуетъ читать «oxipng».)

>>164143
Зато простой как три копейки, и разделение зон ответсвенности (данные отдельно, компрессия отдельно) тоже хорошо.

«А давайте файлов плодить в два раза больше и сжимать в три раза хуже, потому что это хорошо!» — нѣтъ, не хорошо.

Значится, опробовал я 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 формат не для кофеварок.

PS JXL кодировалось с -q 100 -s 9 -E 3.

>>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 сентября, коль скоро недѣлю проработали онѣ послѣ сборки.

>>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 кэширует итог декодирования в уменьшенном нечётком виде?

Я не увѣренъ, не могу сказать.

Может возникнуть вопрос: а зачѣмъ третий из пунктов >>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% можно выиграть, хотя и цѣною учетверения расходов времени работы центрального процессора.

>>164363
-O3 -mtune=native; я не использую ту систему на одной только машине, поэтому компилять что-то под конкретное устройство я редко компиляю. Поколенье третье, AVX2 там увы нет и DDR4 тоже. Чем оно кодировалось в конце июля/начале августа я не помню уже, но время декодирования получено сегодня на 0.5-ом релизе.
> Полное декодирование этой картинки с Марисою и впрямь занимает ≈3 секунды
А у вас какой проц?

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

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

> А у вас какой проц?

i7-3770

>>164380
Вот ты буржуй.
i5-6600

>>164397
Если такой i7 третьего поколения для вас буржуйство, то вы с поддержкой AVX2 и DDR4 тогда вообще буржуй из буржуев.

i3 7020U.
Вы все буржуи!

Примечательно, что чем новее запощенное ЦП, тем ближе к low-end своего времени оно оказывается.

А так, с мобильными процессорами и ноутами в high-end ситуация совсем печальная. Хьюлит просит $445 за одну только Шиндошс, предлагает отставший от Мди Интел со всего-то восемью ядрами за +$1200; ценник на конечную модель получается настолько охреневший, что его и озвучивать не хочется. Зато тоньше на 15%, и скидку при желании можно поставить на 42%, а то и на все 60%: у Леново оно по-приличней как-то.

>>164403
Чем новее запощенное ЦП, тем выше шанс получить бан! Предлагаю тебя забанить!

Хороших новостей у меня про AV1 нѣтъ, а плохие сообщу.

Помните ли упоминавшуюся в мае в сообщении >>161112 и >>161148 проблему некорректной расстановки ключевых кадров в AV1, кодировщику libaom-av1 свойственную? — ну, конечно, не помните: нечего и ждать того, чтоб помнили четыре мѣсяца кряду. А между тѣмъ я упоминал о том, что сообщил об этой проблеме в Alliance for Open Media, и что же? — миновало четыре мѣсяца, и нельзя даже сказать того, что разработчики палец о палец не ударили (ударили они, ударили! — всё же ведётся нѣкоторая работа в направлении исправления), однако всё же проблема остаётся на своёмъ мѣстѣ и досаждает; свѣжайшій (вчерашній) примѣръ видеоцитаты из аниме с напрочь похѣрившеюся разстановкою ключевых кадров можете поглядѣть при сообщении >>/a/17407, а до него ещё >>/a/17372.

А что сдѣлалося с моей надеждою >>163447 на то, что поддержка AVIF появится в Firefox 92, а свѣжій dav1d добавят в Firefox 93? — мало того, что AVIF отложили до Firefox 93 по неожиданному поводу (как я это в сообщении >>164111 упоминал ужé), дык ить теперича открывается ещё болѣе неожиданное упоминание о том, что в связи с этим отложили и обновление dav1d в Файерфоксе: типа, сначала выкатим AVIF спокойно, а не то обновление декодировщика может и новые баги принести. Формально это логично (формат AVIF — это почти в точности формат ключевых кадров AV1, декодировщик поэтому один и тот же, надо думать), но при виде https://bugzilla.mozilla.org/show_bug.cgi?id=1729340#c5 (скриншот прилагаю) как не подосадовать о том, что приход бестормозного десятибитного 4K AV1 в очередной раз откладывается на ещё не совершенно понятный период времени!

Болѣе того: по-моему, до сбоев кодировщика также доходит уж дѣло. У кого из вас Windows, попробуйте зайти на сайт сборок FFmpeg для Windows по адресу https://www.gyan.dev/ffmpeg/builds/ и скачать оттудова архив https://www.gyan.dev/ffmpeg/builds/packages/ffmpeg-2021-09-20-git-59719a905c-full_build.7z и распаковать ffmpeg.exe из него. Опосля того подайте в любом пустом подкаталоге двѣ команды:

ffmpeg -hide_banner -i "https://bugs.chromium.org/p/aomedia/issues/attachment?aid=520802&signed_aid=prMza270UAGJHOQvP5CvAQ=="; -pass 1 -passlogfile temp -sn -map_metadata -1 -map_chapters -1 -crf 59 -b:v 0 -c:v libaom-av1 -aom-params enable-keyframe-filtering=0:enable-tpl-model=1 -g 480 -lag-in-frames 48 -cpu-used 2 -row-mt 1 -tiles 1x1 -threads 2 -strict experimental -f null NUL

ffmpeg -hide_banner -i "https://bugs.chromium.org/p/aomedia/issues/attachment?aid=520802&signed_aid=prMza270UAGJHOQvP5CvAQ=="; -pass 2 -passlogfile temp -sn -map_metadata -1 -map_chapters -1 -crf 59 -b:v 0 -c:v libaom-av1 -aom-params enable-keyframe-filtering=0:enable-tpl-model=1 -g 480 -lag-in-frames 48 -cpu-used 2 -row-mt 1 -tiles 1x1 -threads 2 -strict experimental -movflags +faststart -flags +cgop result.mp4

Лично для меня это упражнение минут через семь-восемь заканчивается падением FFmpeg.

(Обладатели немайкрософтовских операционных систем также приглашаются испробовать на себе эти команды, но только сборка FFmpeg непремѣнно должна содержать достаточно свѣжій движок libaom-av1. Та сборка, которую я опробовал в предшествующих абзацах, называет себя основанною на коммите 26af456a7 прошлонедѣльномъ — а полный список коммитов, к настоящему времени в код движка libaom-av1 закоммиченных, можно по адресу https://aomedia.googlesource.com/aom/ log/ наблюдать.)

Вижу баг во Flower Bus Engine, из-за которого въ примѣры команд в сообщении >>164720 автоматически добавилася ненужная точка с запятою.

Перед употреблением уберите её.

Из Firefox для Ведра, оказывается, уже год как бы убрана поддержка addon’ов: разрешено только ≈16 штук их из белого списка, при этом никакой информации по отключению этой херни ни в программе, ни на странице поисковика addon’ов нет. Она есть, но находится на отдельной странице, находимой Google: для установки блокировщика Youtube-рекламы и uMatrix’а необходима регистрация и создание на их сайте коллекции таких addon’ов, опцию использования которой в программе можно увидеть только ткнувше 5 (пять) раз на логотип FF на activity “About”.
Как же они задолбали. Ещё и шрифт на сайте для мобилок какой-то гигантский, очень мало информации за раз видно и искать неудобно.

>>165206
https://github.com/fork-maintainers/iceraven-browser
?

>>165206
>уже год как
Всё потому что этот функционал не был востребован лично тобой!
>>165397
Жаль что обновляется только путём скачивания нового .apk. А пока можно взять с их страницы ссылку на коллекцию (https://addons.mozilla.org/en-US/firefox/collections/16201230/What-I-want-on-Fenix/) и впилить в Fennec, который из F-Droid (ну или в оФФициальную ночную лису, если хочется приключений).

>>165443
Я год не обновлялся.

>>165445
Из-за невозможности использования девайса по неким причинам, или же специально использовали старую версию браузера?
Это важно!

>>165458
Не важно!

>>165459
Ну и как я должен знать, считать тебя бакой, или просто человеком, откопавшим из шкафа какую-то старую железку?

>>165460
Того человека можно считать постящим почему-то screenshot увеличенной фапчи вместо, собственно, её самой.

>>165461
Потому что фаптча скачивает не ту картинку, которая на фаптче, а другую, а мне другой не надо. Скриншот тоже неплохо, правда непонятно зачем его увеличило. Я вроде не хотел, и раньше скриншот нормально работал. Возможно, лишних метаданных удалил.

>>165443
>Жаль что обновляется только путём скачивания нового .apk

Нет.
https://f-droid.org/en/packages/de.marmaro.krt.ffupdater/

>>165478
То есть, для автоапдейтов придётся устанавливать ещё один магазин приложений? Ладно.
Есть ли какая-либо выгода в его использовании по сравнению с Fennec (кроме изначально настроенной кастомной коллекции аддонов)?

Google похоже забанил youtube-dl: скорость не выше где-то 100 KiB/sec из разных стран.
yt-dlp пока работает нормально.

>>165484
Стриминги с качалками постоянно воюют. Я так один раз плюнул и захват экрана врубил.

>>165484
Meh. Опять ждать обновления.

>>165493
Хотя мне-то, дебианщику стабильному, ждать обновлений не так уж и сложно, ха-ха!

>>165494
Жертвуете безопасностью в угоду стабильности!

Не ждите обновлений youtube-dl.

Ставьте yt-dlp.

Параметры командной строки «--format "bestvideo+bestaudio" --format-sort fps,codec» выглядят короче и понятнѣе, чѣмъ их аналог в youtube-dl.

>>165493
youtube-dl не обновлялся с июня. yt-dlp - вот вчера скочал версию от 10 октября. Которая ещё хуже работает.

>>165498
То есть, с этими >>165497 параметрами работает, а совсем без параметров... сначала не работало, а теперь почему-то тоже работает... Гдеа моя штабильность??

>>165495
Ки-сле-нько!

>>165504
Ки-слень-ко

キッス恋子

>>165505
В японском закон открытого слога, так что...

>>164720

> приход бестормозного десятибитного 4K AV1 в очередной раз откладывается на ещё не совершенно понятный период времени!

Так как по адресу https://bugzilla.mozilla.org/show_bug.cgi?id=1734058 видим, что в код Firefox 95 всё же помѣстили новый код dav1d, то желаемое может быть достигнуто примѣрно через мѣсяцъ (появление Firefox 94 по адресу https://www.mozilla.org/en-US/firefox/94.0/releasenotes/ датируется 2 ноября, появление Firefox 93 по адресу https://www.mozilla.org/en-US/firefox/93.0/releasenotes/ датируется 5 октября).

>>167068
Тут скорее всего виноват не браузер, а устаревшее железо в сочетании с переходом Google’а на VP9. PaleMoon — это почти целиком плагиат со старого Firefox'а, и скорость у него соответствующая.

>>167053
Если говорить о внешнем мире, Палёная Луна — это весьма редкая фигня, которую нынче по слухам фактически пилит один человек — несмотря на им заявляемое, при этом он всячески отгоняет готовых maintain’ить это дело разработчиков от своего детища — например потому, что те якобы хотят нажиться на его трудах всего-то навсего портировав браузер под XP или BSD, тем якобы таща его детище в неверное маргинальное направление. Хотя, казалось бы, кто будет пользоваться его детищем, кроме тех маргиналов — очередной случай человека, рубящего сук на котором сидит. Не только Мозила этим грешна.

Кстати, ещё на PaleMoon 29.2.0 десятибитное AV1 проигрывались нормально [>>160739]. Код поддержки 10-битных видео есть, но, видимо, Цукико отчего-то решил не включать media.av1.enabled из about:config по умолчанию в новых сборках. Хотя раньше вроде оно было включено из коробки.

> Это тот браузер, в котором для того, чтобы отключить ведение истории и почистить куки нужно городить забор из костылей?
Ниет, для этого там такое вроде делать не надо. Но пост того человека от этого не менее толстый.

>>167072
>Ниет, для этого там такое вроде делать не надо.
Не уверен на счёт печенек, но вот историю там точно нельзя было отключить "из коробки".
Можно было только чистить руками после каждого сеанса.

Был вариант постоянно сидеть залогиненным в гуглоаккаунт, в настройках которого было отключено ведение истории.
Был вариант устанавливать сторонние костыли, которые каким-то образом отключали историю.
Был вариант вручную городить огород вокруг файлов, куда Хром пытается писать историю, чтобы он не писал туда историю.

>>160672

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

Но так как упомянутое сообщение было стёрто, то стало не очень ясно, что имѣлось в виду.

Надо поэтому пояснить, и поясняю: видеоиллюстрация для лимерика >>/a/17099 бралась по адресу https://youtu.be/juxJfkvezp8 на YouTube, хотя лежит там в плоховатом качестве (звук сдвинут относительно видео), а попытка взять её на странице проекта-первоисточника («РЕ-АНИМАЦИЯ») привела только к тому, что на странице http://www.re-animation.ru/main.php?p=show_film&fid=10 (скриншот которой прилагаю) обнаруживается видеофайл в формате Windows Media Video 9, а размѣръ кадра у того видеофайла — 420×240 пикселов, то есть качество по нынешним мѣркамъ и вовсе такое, что остаётся лишь вздохнуть и отвернуться.

Конечно, четверть вѣка тому назад (в середине девяностых годов) даже такое количество пикселов (420×240 TrueColor) было бы существенным шагом вперёд. Появление в 1987 году видеоадаптера VGA с режимом 320×240 пикселов и 256 цвѣтами, набор которых не был фиксированным, а задавался произвольным выбором из пространства TrueColor, считалося очень хорошим по сравнению со всѣмъ тѣмъ, что было до этого; но и далѣе по адресу https://books.google.ru/books?id=KjwEAAAAMBAJ&pg=PA55 видим, что и первые видюхи SVGA, неслабо дорогостоящія, к 1990 году за предѣлъ 256 цвѣтовъ и 1024×768 пикселов не вышли.

Но заливщик видеоролика https://youtu.be/juxJfkvezp8 относит его появление к 2007 году (то есть на цѣлое десятилѣтіе позже ситуации, обрисованной в предшествующем абзаце), и намѣреніе обнародовать только 240p к этому времени ужé может означать непреоборимое желание уберегать варианты видеоролика в большем разрешении от попирачивания. Сам видеоклип считаю созданным в большем разрешении потому, что результат видеозаливки https://youtu.be/juxJfkvezp8 ничуть не выглядит как такой чудовищный (в 4½ раза!) апскейл, который непремѣнно понадобился бы для превращения 240p в 1080p.

Результат >>168680 может быть ещё улучшен (результат улучшения прилагаю), если обратить внимание на то, что автор сообщения >>168213 ссылается на видеоролик https://youtu.be/N4FlL1FCbvA на YouTube, в подписи к которому заливщик пишет: мопед не мой, глядите по адресу http://bit.ly/srMzjP (откуда перенаправление на https://www.dailymotion.com/video/xm7oor идёт) первоисточник.

Это примѣчаніе позволяет использовать https://www.dailymotion.com/video/xm7oor как исходный видеофайл при кодировании, тѣмъ исключив негативное воздействие https://en.wikipedia.org/wiki/Generation_loss на качество видео. Появляется резерв для того, чтобы это качество видео можно было слегка ухудшить в процессе кодирования (задать «-crf 61» вмѣсто «-crf 60» в командной строке для FFmpeg), а на высвободившемся объёме файла качество звука замѣтно приподнять (до «-b:a 46.54k» при окончательной сборке видеофайла), после чего ужé и стереозвук начинает имѣть не невыносимое качество.

>>166609

Так и вышло.

Firefox 95 появился вчера (7 декабря), как об этом по адресу https://www.mozilla.org/en-US/firefox/95.0/releasenotes/ извѣщаютъ.

Видеофайлы AV1 с десятибитными компонентами цвѣта и с кадрами размѣромъ FullHD (напримѣръ, >>/a/17103 и >>168863) перестали подтормаживать даже в наиболѣе динамичных сценах.

Видеофайлы AV1 с кадрами размѣромъ 4K (напримѣръ, >>167237) также перестали подтормаживать.

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

Обновление Файерфокса, однако же, оказалось не безусловно ok.

Видеоролик >>167048 на моём компé не показывается в Firefox 95.0.2 (а в прежнем Файерфоксе я это видео невозбранно смотрѣлъ), новый видеоролик >>170207 также не показывается.

>>170256
УМВР

Сообщение >>170257 не информативно без указания названия и версии браузера.

>>170256

>>170256
В чем проблема? Не вы ли так яростно доказываете мне на каждом углу, что безопасность важнее стабильности?

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

>>170275
95.0.2, очевидно же.

С радостью сообщаю, что два видеоролика, которые в сообщении >>170256 мною упомянуты как неработающие, после обновления на Firefox 96 заработали у меня.

Автор сообщения >>170351 не понимает, что цѣлью обновления является, таким образом, не столько «безопасность», сколько желательная работоспособность: для Firefox 95 это была возможность смотрѣть без подтормаживания большинство видеороликов AV1 с повышенною глубиною цвѣта или с повышенною (до 4K) чёткостью кадра (возможность, которая ещё съ лѣта нетерпеливо ожидалася, как это можно по сообщению >>163241 видѣть), а для Firefox 96 — присоединение к этому большинству немногих исключений, существование которых раздражало досадою.

Послѣ того, как результатом >>169016 повергнут ѳэзисъ https://410chan.org/b/arch/res/146617.html#168213 о невозможности нормально пожать видеомем https://www.dailymotion.com/video/xm7oor в формате AV1 до 410чанского 5000-килобайтового объёма (да, мельтешение первых тринадцати секунд выглядит довольно скверно, но затѣмъ постепенно нормализуется), остаётся слѣдующій вопрос: не много ли этому способствовало то обстоятельство, что этот видеомем, окромя своего динамизма, всё же надѣлёнъ не очень значительным размѣромъ кадра (1280×720 — это обычный HD, а не fullHD) и притом не слишком значительною длиною (2:08 — это меньше, чем медианная длина видеоиллюстраций к лимерикам >>/a/17096, напримѣръ)?

Что же было бы при кадре fullHD (длина и высота которого в полтора раза превосходят 720p) и при длине столь же большей (то есть простирающейся за три минуты с лихвою)?

В общем-то, как нетрудно догадываться, ничего хорошего.

Старый добрый «Basu bango yonbyakujuu バス番号四百十 ED FULL», по адресу https://youtu.be/puRNQbSMEwo расположенный, по команде «yt-dlp --abort-on-unavailable-fragment --format "bestvideo+bestaudio" --format-sort fps,codec» скачивается как раз в форме fullHD длиною болѣе 3¾ минуты и располагается в объёме почти 66 «десятичных» мегабайтов, то есть для помѣщенія на 410чанѣ нуждается въ болѣе чѣмъ тринадцатикратном переужатии.

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

Так как видео такой длины в 410чановском объёме принуждено бывает ограничиваться 181 «десятичным» килобитом в секунду (считая по 125 байтов на один «десятичный» килобит), из которых болѣе 44½ тут отведено на звуковую дорожку (чтоб не совсем уж «кровь из ушей»), то оно и понятно.

На примѣрѣ упомянутых выше лимериков также очень видно, что качество видеозаписи становится проблемным в 410чанском объёме (даже не считая воздѣйствія багов, в сообщении >>164720 упомянутых, с которыми всѣ мы вошли и в 2022 год, к сожалению), когда длина её выходит за предѣлы двух минут с небольшим.

Мицу-нян, а как этим yt-dlp скачать только аудио И по возможности смержить с уже скачанным видео без звука?
Что-то листала страницу на гитхабе и не разобралась.
Пыталась указывать только "ba" без указания видео, но всё равно пробует качать видео.

>>178476
Глянь через -F, какие есть форматы, и качай через -f формат без видео, который нравится.

Мёрж можно так: ffmpeg -i video_src -i audio_src -c copy out.mkv
Но если так делать, то аудио может немножко опаздывать за видео или наоборот. Поэтому, по-хорошему, когда скачиваешь, стоит выбирать через скачивальщик нужный формат и аудио, и видео, потому что он-то десинхронизацию в случае чего пофиксит.

Ладно, дура частично разобралась. Он не видео скачивал, а аудио, но в webm формате по умолчанию, поэтому воспринимал уже лежащие в папке webm видео с такими же именами как аудио, наверное, и пропускал их скачивание. Если убрать видео из папки, то будет аудио только. А скачать отдельно аудио удалось только в m4a, а в других форматов нет, говорит.
Мне то уже не нужно, я уже нужные видео перекачала со звуком, так, на будущее узнать хотелось.

>>178476
yt-dlp -f 251 url
ffmpeg -i vid.webm -i audio.webm -c copy -map 0:0 -map 1:1

>>178480
Точно других форматов нет? У YouTube нынче почти всегда всё в opus-е, в webm только его запихать и можно, а в m4a opus как правило не сохраняют, в m4a скорее всего aac. Но оригинальный поток именно в aac может быть.

>>178482
Пробовала opus, ogg, mp3, aac и на всё

Requested format is not available

Только m4a and webm скачалось.
Я может всякие ключи неправильно ставлю, не знаю. Я не очень во всём этом разбираюсь совсем нет.

Чио, я ж знаю, что ты боженька ffmpeg’а и знаешь всё о видеокодировании, так что подскажи.
Задача такова: необходимо захватить видео с области экрана, ограниченной X’овым окном, и аудио с pulseaudio’вского sink’а и записать это всё в lossless видео без потерь и десинхронизаций, bitrate не главное.
Например, если делать это примерно так ffmpeg -f pulse -i audio_sink_device -f x11grab -thread_queue_size 256 -framerate 25 -video_size 1024x576 -i :0.0+0,0 -c:v libx264rgb -crf 0 -preset ultrafast -c:a copy out.mkv, то ffmpeg всё вроде записывать успевает, но в начале происходит странная десинхронизация с аудио, из-за которой оно потом отстаёт от видео секунд на 5—6.
Как это исправить? Или как это решить чем-то кроме ffmpeg, через gstreamer, например?

>>178485
Ну, webm’ки без видео — это как раз opus и есть, но в webm-контейнере. Так что opus доступен, и из тех webm’ок, во избежание конфуза с webm’ками с видео, его можно вытащить, скопировав его в файлы с расширением .opus.

Я пришёл повѣдать вам об очередном значимом шаге въ дѣлѣ распространения тридцатибитных AV1 (с десятибитными компонентами цвѣта) на имиджбордах.

Автор страницы https://zipdox.net/t/webmtrackhack/ придумал, как можно составить видеофайл WebM таким способом, чтобы Chrome и FFmpeg видели в нём одну видеодорожку, а Firefox и VLC — другую видеодорожку.

Так как достигнутая им невидимость во FFmpeg означала собою ещё и возможность обхода того запрета, который наложен на 4channel на выкладывание файлов WebM с современными видеокодеками (которые новѣе, чѣмъ VP8), то с 10 февраля по 15 февраля по адресу https://boards.4channel.org/wsg/thread/4355905 (скриншот я вынужден приложить в IPFS Cloudflare по адресу https://bafybeigjhu7j5icesaeupuefg34vrcggf2u5y35c6nueh3d4l7z5fddbom.ipfs.cf-ipfs.com/4channel30bitAV1.png ввиду того, что запостить его на 410чанѣ не удаётся) сообщество 4channel развлекалося, выкладывая тридцатибитные AV1 (а также и нетридцатибитные, которые просто TrueColor), видимые только в Файерфоксе и VLC (а в остальных средствах просмотра содержащие краткую заглушку VP8) — до тѣхъ пор, пока эта возможность не оказалася административно отключённою.

И всѣ тѣ имиджбордщики на Файерфоксах, которые прежде не имѣли представления о возможностях современных видеокодеков, смогли наконец посмотрѣть вꙭчію и немало дивилися и длине видео, въ предѣлахъ шести мегабайтов достигаемой, и необыкновенно малым артефактам видеосжатия.

>>178841
Едрить у тебя художественный слог.

>>178485
Недавно с похожим столкнулась, не знаю, твой ли это случай-ня.
При drag'n'drop'e выползла эта надпись, а в file selector'е всё загрузилось.
Либо наоборот.

Под конец февраля я заглянул в обсуждение https://old.reddit.com/r/AV1/comments/r1sv22/av1_the_opus_of_video_codecs_discuss/ и увидал там прилагаемую диаграмму, согласно которой движок libsvtav1 (он же SVT-AV1 через дефис) в своём наиболѣе медленном&качественном режиме работы слегка опережает libaom-av1 по качеству (работая при этом всё ещё чуть быстрѣе), а въ наиболѣе быстром&низкокачественном режиме работы опережает по скорости x264 placebo на полтора порядка (работая при этом всё ещё чуть качественнѣе, чѣмъ x264 placebo), то есть не сильно отставая аж от x264 veryfast по скорости.

Прежде от употребления libsvtav1 меня удерживало то обстоятельство, что по адресу https://gitlab.com/AOMediaCodec/SVT-AV1 и https://github.com/AOMediaCodec/SVT-AV1 указаны довольно мощные технические требования: дескать, нужен Intel Core не менѣе чѣмъ пятого поколения, а работа SVT-AV1 провѣряется разработчиками на Windows не старѣе 2016 года, а при попытке удѣлить менѣе шести гигабайтов RAM кодированию fullHD с десятибитными компонентами цвѣта будет вылетать ошибка. Однако, едва попробовав libsvtav1, я тотчас же вполне убедился в том, что всё это была хѣрня, то есть что на моём i7-3770 под седьмою виндою, кушая не болѣе двух-трёх гигабайтов RAM (но зато ≈9 гигов с учётом виртуальной памяти), именно fullHD и именно с десятибитными компонентами цвѣтовъ способен обрабатываться движком libsvtav1 невозбранно.

В первые же четыре дня марта (1—4 марта 2022 года) я изложил и это наблюдение, и дальнѣйшія свои впечатления от libsvtav1 в Твиттере по адресу https://twitter.com/FidonetRunes/status/1498642908215484416

В интересах автора сообщения >>180764 (и тѣхъ других лиц, которые страдают от невозможности обойти путинистические блокировки Твиттера — ну или драматически дѣлаютъ вид, что не могут обойти их) я приложу тут скриншот двадцатки моих микроблогозаписей, по адресу https://twitter.com/FidonetRunes/status/1498642908215484416 расположенных.

Суть такова:

① Движок libsvtav1 работает быстрѣе libaom-av1 (опережает на 72⅜% в одном из моих экспериментов), даже когда тот и другой работают двухпоточно в режиме максимального качества с равным CRF и съ примѣрно (с точностью до ≈3½%) равным битрейтом.

② Движок libsvtav1 лучше распараллеливается: упоминаемое по адресу https://ru.wikipedia.org/wiki/Закон_Амдала негативное влияние нераспараллеливаемых кусков исходного кода, по-видимому, замѣтно меньше в коде libsvtav1, чѣмъ в коде libaom-av1. На практике это означает, что если для существенного распараллеливания (на четыре или на восемь потоков) работа libaom-av1 в режиме максимального качества нуждалася в создании tiles (половинок или четвертушек видеокадра, кодируемых раздѣльно), то libsvtav1 может и без этого обходиться. Созданием таких тáйлов слегка умалялася сила сжатия видеокадров libaom-av1 (потому что движок жертвовал междукадровою предсказуемостью всѣхъ таких крупных движений в кадре, которые пересекают границу тайлов), тогда как для libsvtav1 можно ограничиться наращиванием числа threads (потоков исполнения программы) вообще без создания тайлов, результат такого кодирования будет байт-в-байт тѣмъ же, просто получится ещё быстрѣе. Когда CPU не занимается ничем другим, тогда можно, напримѣръ, на ночь оставить libsvtav1 и быть увѣреннымъ, что к утру шестипоточное кодирование потратит не болѣе трёх-пяти часов на каждую минуту видео (в зависимости от динамичности событий в кадре) и позволит на другой день выложить на имиджборде двухминутную или трёхминутную цитату, тогда как кодировщик libaom-av1 на такое не способен на малой скорости (в максимальном качестве).

③ Движок libaom-av1 качественно работает только в двухпроходном режиме (в первом проходе он быстро пробѣгаетъ по всѣмъ видеокадрам и оцѣниваетъ ихъ примѣрную «информационную стоимость» — в частности, чтобы понимать, куда расставлять ключевые кадры), а его разработчики проектируют ужé и трёхпроходный режим (способный лучше укладываться в указанный ему битрейт). Движок libsvtav1 в режиме неизмѣннаго качества (CRF-контролируемого) работает однопроходно, а ключевые кадры расставляет либо тупѣйшимъ способом (через каждые N кадров), либо распознавателем начала новой сцены. Оборотною стороною этого является недостаточная эффективность распознавателя, о которой по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/1741/diffs есть предупреждение.

④ У этой оборотной стороны есть и своя оборотная сторона: в CRF-режиме движку libsvtav1 можно вообще запретить создание ключевых кадров. Понятно, что при этом в видеопроигрывателе вырубается навигация (то есть исчезает возможность переставить ползунок времени на попозже, чтобы смотрѣть видеоролик оттудова, а не с сáмого начала его). Но не очень понятно (скорѣе даже парадоксально), что при этом сила видеосжатия нарастает (объём файла уменьшается, как я замѣтилъ, на ≈5% по сравнению с итогами работы распознавателя начала новой сцены). Тут даже перед двумя вопросами приходится остановиться в недоумении. Во-первых, ключевые кадры должны помогать экономить объём: если новая сцена начинается кадром болѣе тёмным, чѣмъ финал предшествующей сцены, то экономнее хранить сам кадр (как ключевой), а не разность между ним и предыдущим, которая крупнѣе по амплитуде, не правда ли? Тогда почему на сáмом дѣлѣ всё наоборот и объём экономится выключением создания ключевых кадров? Во-вторых, насколько я мог замѣтить, малодинамичные диалоговые сцены аниме (я провѣрилъ отрывок между ѿмѣтокъ времени 8:39.478 и 9:53.372 во второй серии «Denpa Onna to Seishun Otoko») и весьма динамичные сцены аниме (я провѣрилъ движение поѣзда по городу и проход махосёдзё по поѣзду в сáмом начале «Magia Record») демонстрируют ≈одинаковое ≈пятипроцентное уменьшение объёма при отключении ключевых кадров. Приходится прийти к выводу о том, что если «информационная стоимость» ключевых кадров не пропорциональна их количеству, то тогда, стало быть, она выражает собою что-нибудь другое — вѣроятно, процесс их расстановки (тот самый вышеупомянутый неоптимальный распознаватель начала новой сцены) систематически ошибается в ¹⁄₂₀ групп кадров — или, вѣрнѣе, ошибается ещё чаще, но зато и выгода от его неошибок систематически покрывает ровно такую часть ущерба от его ошибок, что разность выглядит пятипроцентною. Ещё, впрочем, возможно и то, что меня поразило самое обыкновенное совпадение — плод случайности! — и что я получил бы другой результат, если бы подверг испытанию другие аниме (не «Magia Record» и не «Denpa Onna to Seishun Otoko») или даже другие сцены тѣхъ же аниме.

⑤ Само собою понятно, что уходом от libaom-av1 к употреблению libsvtav1 я избавляю себя от подзадолбавших проблем libaom-av1, досаду от которых я выражал в предшествующих сообщениях — и от рассыпания ключевого кадра на макроблоки невѣрнаго вида (в сообщении >>160709 упомянутого тут в первый раз), и от невѣрной расстановки ключевых кадров, ухудшающей качество предшествующих (в сообщениях >>161112 и >>161148 упомянутой тут в первый раз), и от падения всего кодировщика (в сообщении >>164720 упомянутого тут в первый раз). Всѣ онѣ извѣстны разработчикам, и даже не первый год извѣстны, так что только уходом и можно избавить себя.

⑥ Правда, у кодировщика libsvtav1 есть и свои собственные проблемы. Прежде всего слѣдуетъ повторить тут то, что по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1834 было сказано: включение параметра «enable-overlays» может приводить к зависанию на скоростях от 1 до 12 включительно. (А я и на нулевой скорости поймал такое зависание, когда попробовал аналог видеозаписи >>180746 изготовить с этим параметром.) Можно, конечно, убеждать себя в том, что и не слѣдовало включать этот параметр, руководясь сообщением https://old.reddit.com/r/AV1/comments/s7yyf9/help_me_understand_svtav1_parameters/hti45u9/ о том, что PotPlayer моргает при просмотре видео AV1, созданных с этим параметром; но не криводушно ли такое самоубеждение.

⑦ Затѣмъ ещё слѣдуетъ упомянуть, что по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1810 было показано время от времени возникающее рассыпание кадров на макроблоки невѣрнаго вида. Это сильно напоминает аналогичную проблему libaom-av1, в сообщении >>160709 упомянутую тут в первый раз: в libaom-av1 её первопричиною была временнáя фильтрация ключевых кадров (и бороться было можно, её отключая: >>161566), а в libsvtav1 первопричиною является сломанность вообще всей временнóй фильтрации (так что одолѣть проблему можно, если параметру «enable-tf» придать нулевое значение).

⑧ Поэтому мне здорово повезло, что я начал изучать svtav1 вовремя: очень недавно (утром 22 февраля) в исходный код svtav1 добавили (как по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/bc4c6ce9db07d46448b8d92f1fec5b658d93c263 это видно) возможность переключения кодировщика на другой набор настроек, уделяющих меньше внимания формальному показателю PSNR (соотношению сигнала и шума) и больше внимания неформальному «видеокачеству» (подробности чего в обсуждении https://old.reddit.com/r/AV1/comments/sxw8be/vq_tuning_mode_being_added_to_svtav1/ были разъяснены). Оказывается, таким переключением заодно запускается и другой алгоритм временнóй фильтрации, менѣе жадный (анализирующий меньше кадров, сосѣдствующихъ по времени) и, главное, не приводящий к досадному искажению макроблоков. Только под конец февраля и в начале марта постигая libsvtav1, я могу с сáмого начала вмѣсто «enable-tf=0» использовать «tune=0» и имѣть дѣло съ болѣе высокимъ видеокачеством.

⑨ Очень мрачно было видѣть, что автор обзора https://old.reddit.com/r/AV1/comments/t59j32/encoder_tuning_part_4_a_2nd_generation_guide_to/ в своём рассуждении о выборе скорости работы кодировщика libaom-av1 пишет, что если хочется использовать libaom-av1 на седьмой или ещё болѣе высокой скорости, то слѣдуетъ использовать libsvtav1 вмѣсто этого. По-моему, кодировщик libaom-av1 ужé на шестой и даже на пятой скорости преизрядно жертвует качеством в угоду скорости, так что эта рекомендация должна восприниматься как изрядно низкая оцѣнка работы кодировщика libsvtav1 на малых скоростях (то есть с высоким качеством). Сперва я и знать не знал, как относиться к такой оцѣнкѣ (расходящейся с моим собственным пониманием итогов работы libsvtav1 какъ болѣе высококачественных), но затѣмъ я понял, что этот человѣкъ, уж конечно, подготавливал свой обзор (выложенный 2 марта) достаточно долго для того, чтобы не успѣть ознакомиться с итогами работы libsvtav1 в режиме «tune=0» и измѣнить своё мнение к лучшему по сравнению с libaom-av1, для чего достаточно было бы покадрового сравнения. Чуть ниже я собираюсь показать такое покадровое сравнение.

Исходя из вышеизложенных соображений, видеозапись >>180746 была создана мною при посредстве сборки https://www.gyan.dev/ffmpeg/builds/packages/ffmpeg-2022-02-28-git-7a4840a8ca-full_build.7z утилиты FFmpeg, а подавал я для того вот какую команду:

ffmpeg -hide_banner -i исходноеВидео.webm -sn -map_metadata -1 -map_chapters -1 -sc_detection 1 -la_depth 120 -crf 56 -b:v 0 -c:v libsvtav1 -svtav1-params keyint=480:tune=0:lp=6 -pix_fmt yuv420p10le -preset 0 -strict experimental -c:a libopus -b:a 64k -movflags +faststart -flags +cgop результат.mp4

Результат имѣлъ объёмъ 5 209 699 байтов и затѣмъ подгонялся под 410чановское 5000-килобайтовое ограничение снижением битрейта звука, как это в сообщении >>180746 ужé сказано.

А при CRF 54 результат имѣлъ объёмъ 5 900 125 байтов, так что эффект измѣненія CRF на единицу можно считать приближённо 350-килобайтовым при таком сильном сжатии (и, возможно, только при таком небольшом размѣрѣ кадра, который 640×480 пикселов).

Покадровое сравнение я начну подачею вот каких команд:

ffmpeg -hide_banner -i https://410chan.org/b/src/164646529953.webm -ss 3.93 -q 1 -frames:v 1 libsvtav1.png

ect -9 -strip -keep --allfilters --mt-deflate=6 libsvtav1.png

(Сборка https://github.com/fhanau/Efficient-Compression-Tool/releases/download/v0.8.3/ect-0.8.3-Win64.exe.zip утилиты «Efficient Compression Tool» используется второю из этих команд для сжатия PNG без внесения потерь.)

Приложенный к моему сообщению результат работы этих команд (файл libsvtav1.png) содержит кадр видеоролика >>180746, взятый на ѿмѣткѣ времени 3,93 секунды от начала.

(Я не стану переводить в WebP ни этот, ни слѣдующій кадр, так как они должны сохранять повышенную глубину цвѣта, тогда как для WebP (в отличие от PNG) предѣльною глубиною цвѣта является TrueColor.)

Покадровое сравнение я завершу подачею вот каких команд:

ffmpeg -hide_banner -i https://410chan.org/b/src/163655638612.webm -ss 3.93 -q 1 -frames:v 1 libaom-av1.png

ect -9 -strip -keep --allfilters --mt-deflate=6 libaom-av1.png

Приложенный к моему сообщению результат работы этих команд (файл libaom-av1.png) содержит кадр видеоролика >>167048, взятый на той же ѿмѣткѣ времени 3,93 секунды от начала.

Внимательно сравнивая тот и другой кадр, нетрудно убедиться в превосходстве высочайшего качества, достигаемого кодировщиком libsvtav1, над высочайшим же качеством, достигаемым кодировщиком libaom-av1, если обратить внимание вот на какие детали:

① Воздетый (и быстро движущийся в видео) палец гитариста оказывается гораздо менѣе размытым в файле libsvtav1.png.

② Движение губ и челюсти гитариста буквально разваливается на прямоугольники макроблоков в файле libaom-av1.png, тогда как в файле libsvtav1.png междумакроблоковая граница не настолько явственна.

③ Колковый механизм гитары выглядит болѣе размытым в файле libaom-av1.png по сравнению с файлом libsvtav1.png, показывающим эту металлическую конструкцию болѣе рѣзко.

④ Выражение лица сырнодержателя, стоящего за спиною у гитариста, в файле libaom-av1.png оказывается болѣе улыбчивым по сравнению с файлом libsvtav1.png — и это неоправданная улыбчивость, что можно замѣтить, если сравнить ещё и с содержащимся в видеоролике https://youtu.be/TL9qWmZ7FB4 кадром-первоисточником.

Только что упомянутый кадр-первоисточник также прилагаю.

В качестве примѣра избавления от проблемы невѣрной расстановки ключевых кадров, ухудшающей качество предшествующих (эта проблема упомянута в пятом пункте в сообщении >>180818), сравните видеоцитату >>/ts/6410 (в которой ключевые кадры расставляются в libaom-av1 некорректно) и видеоцитату >>/ts/6509 (в которой ключевые кадры расставляются в libsvtav1 малоэффективно, как о том по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/1741/diffs предупреждают, но хотя бы вѣрно).

Изначально обе они кодировалися с указанием звука 64 kbps в FFmpeg.

Видеоцитата >>/ts/6410 при CRF 46 на второй скорости видеокодирования не вмѣстилась в 5000 килобайтов, потребовалось уменьшить битрейт звука до 54 kbps. Таков эффект проблемы.

Видеоцитата >>/ts/6509 при CRF 46 на шестой скорости заняла 5 131 874 байта.

Видеоцитата >>/ts/6509 при CRF 45 на нулевой скорости заняла 5 059 450 байта. (Непосредственно к сообщению >>/ts/6509 вы видите приложенным именно этот вариант, но переоснащённый звуком 71,08 kbps.)

Получается, что одновременно снижение CRF на единицу и уменьшение скорости видеокодирования до предѣла возможного привело к экономии 72424 байтов.

В качестве другого примѣра хочется разсмотрѣть (и разсмотрю) перекодирование в libsvtav1 той антиинтернетовской мультипликации «Как облажаться в Интернете», которую в октябре 2019 года распространяло молодёжное направление Общероссийского народного фронта в Краснодарском крае (как о том по адресу https://www.kuban.kp.ru/online/news/3637343/ упоминают).

Этот мультик при CRF 55 на шестой скорости занял 5 377 009 байтов.

Этот мультик при CRF 55 на нулевой скорости занял 4 937 053 байта. (Непосредственно тут вы видите приложенным именно этот вариант, но переоснащённый звуком 71,92 kbps.)

Этот мультик при CRF 54 на шестой скорости занял 5 622 469 байтов.

Этот мультик при CRF 54 на нулевой скорости занял 5 148 691 байта.

Получается, что одновременно снижение CRF на единицу и уменьшение скорости видеокодирования до предѣла возможного привело к экономии 228318 байтов — ≈втрое большей, чѣмъ в предшествующем примѣрѣ.

Простое же снижение CRF на единицу привело к росту объёма файла на 245460 байтов на шестой скорости и на 211638 байтов на нулевой скорости. То и другое замѣтно меньше, чѣмъ ≈350 килобайтов в случае >>180820. (Интересно, чѣмъ сильнѣе объясняется это различие? Тѣмъ ли, что тут мультик, а там — так называемый реальный міръ? Тѣмъ ли, что тут FullHD, а там — только 640×480? Тѣмъ ли, что там нѣтъ сильнопредсказуемых движений персонажей через весь кадр?)

Простое же уменьшение скорости видеокодирования до предѣла возможного привело к экономии 439956 байтов при CRF 55 и 473778 байтов при CRF 54.

>>180865
>Интересно, чѣмъ сильнѣе объясняется это различие?
Для этого наверное стоит изучить сам алгоритм кодирования и представить какие данные для него представляют идаеальную и худшую ситуации.

Если лень, то можно попробовать погонять синтетические тесты, монотонное изображение (одноцветный прямоугольник) и белый шум.

Если прибѣгнуть к упомянутому выше приёму отключения ключевых кадров в видеоролике (четвёртый пункт в сообщении >>180818), то тогда рикролл, на основе ≈классического видеоролика https://youtu.be/dQw4w9WgXcQ изготовленный при CRF 62 на нулевой скорости, занимает 5 521 332 байта. (Непосредственно тут вы видите приложенным именно этот вариант, но переоснащённый звуком 47,55 kbps.)

Уменьшение CRF на единицу (до 61 пункта) приводит к росту объёма, достигающего 6 282 068 байтов.

Видим рост на 760 736 байтов, согласовать который с ≈350 килобайтами в случае >>180820 (при CRF 56→54) или с лежащими в диапазоне 200—250 килобайтов измѣненіями объёма в случае >>180865 (при CRF 55→54) мне удаётся только при том предположении, что при росте CRF болѣе значительным становится эффект от измѣненія CRF на единицу. На этом предположении, впрочем, я пока ещё не готов всерьёз настаивать.

Тот же приём позволяет при сжатии https://youtu.be/puRNQbSMEwo по большей части избавиться от упомянутого в сообщении >>175216 повреждения тонкоконтурных пляшущих сѵмволовъ над головами у персонажей и персонажиц (повреждения, оказывающегося свойственным libaom-av1, но не libsvtav1), оставаясь въ предѣлахъ 5000-килобайтового ограничения на 410чане.

Результат такого сжатия при CRF 63 (то есть на предѣлѣ возможного) занимает 5 959 580 байтов. (Непосредственно тут вы видите приложенным именно этот вариант, но переоснащённый звуком 35,99 kbps.)

При CRF 63 объём видеофайла рѣзко возрастает до 7 437 845 байтов. Разность 1 478 265 байтов (то есть без малого полуторамегабайтовая) ещё менѣе объяснима, чѣмъ упомянутая в предшествующем сообщении.

Поведение видеокодировщика SVT-AV1 в настоящее время ухудшилось, сдѣлалось досадным.

В качестве причины этого я укажу вам на коммит, по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/d1154a85de8b8614dec5d8a5288e3afe26370eeb совершённый — он соѿвѣтствуетъ запросу на слияние, по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/1865 расположенному, а называется «Optimize SCD».

Сокращение «SCD» означает в его названии понятие «scene detection», то есть понимание кодировщиком того мѣста (того кадра), с которого начинается новая сцена в видеозаписи. Упомянутую же «оптимизацию» поневоле приходится понимать в том смысле, в каком это слово подчас употребляется в нехорошо извѣстной российской практике как эвфемизм, означающий уничтожение. Авторы SVT-AV1 употребили этот термин именно в том же смысле, как это нетрудно увидеть, глядя на прилагаемый мною скриншот одной из правок, содержащейся в этом коммите и уведомляющей: «у SVT-AV1 есть встроенный механизм принятия решений о режиме работы, обрабатывающий смѣну сцен, а ключевой кадр при начале новой сцены не будет вставляться».

Между тѣмъ raison d'être опознавания начала новой сцены заключается в том только, чтобы засовывать ключевой кадр не тупо ровнёшенько через каждые N кадров (каждые 120, каждые 240, каждые 480, etc.), а непремѣнно в начало сцены засовывать его. Зачѣмъ ещё может быть нужным кодировщику понимание того, когда заканчивается одна сцена и начинается другая? — только для того, чтобы уменьшить собою то распухание объёма файла, которое причиняет ему расстановка ключевых кадров. Но пояснение причин этого распухания приходится перенести въ слѣдующее сообщение.

Дѣло тут вот в чём: по опредѣленію, ключевой кадр — это такой кадр, которым начинается новая группа кадров (group of pictures, или попросту GOP).

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

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

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

Когда зависимости расстановки ключевых кадров от работы SCD оказывается выключенною нафиг, как теперь она выключена в libsvtav1, тогда каждый кадр расставляется «на ровном мѣстѣ», а не в начале сцены, так что стоимость хранения его изображения цѣликомъ (а не разницы между ним и одним или двумя сосѣдствующими кадрами) отягощает собою объём файла.

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

Можно ли, руководясь существованием таковых механизмов, всерьёз надѣяться на то, что если в видеозаписи «на ровном мѣстѣ» будут появляться ключевые кадры каждые пять-десять секунд (по величине интервала между ключевыми кадрами, заранее заданного во избавление проматывания к любому мѣсту от тормозов), а не один-два раза в минуту (то есть на ≈порядок меньше — по числу сцен, длительностью превышающих заданный интервал между ключевыми кадрами, заранее заданный во избавление проматывания к любому мѣсту от тормозов), то и тогда всё будет достаточно ok, так что сломанною зависимостью расстановки ключевых кадров можно пренебрегать?

Надеяться на это никоим образом нельзя. По двум причинам.

Во-первых, каждый из таких механизмов способен только умалить собою цену ключевого кадра, «на ровном мѣстѣ» поставленного, но не совершенно ѿмѣнить её.

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

Но для начала задам напрашивающийся уточняющий вопрос: в чём именно заключается проблема той ситуации, когда ключевой кадр по своему содержимому мало чѣмъ отличается от предшествующих и послѣдующихъ обычных кадров, но это малое отличие недостаточно используется и потому приводит к лишнему росту объёма файла? С какой стороны оно не используется? Если попристальнѣе взглянуть вперёд во времени, то станет понятно, что для послѣдующихъ кадров вроде как большой проблемы нѣтъ: их внутрифайловое представление содержит описание небольшой межкадровой разницы внѣ зависимости от того, становится ли предшествующий им кадр ключевым или нѣтъ. То есть факт их небольшого отличия от ключевого кадра — это факт не игнорируемый, а используемый по-прежнему. Получается, что глядеть надо в другую сторону: проблема располагается сзади по времени, проблема заключается именно в игнорировании разницы между ключевым кадром и предшествовавшими ему кадрами видео.

Под стать пониманию этой проблемы оказывается и метод её устранения, а именно переход от закрытых GOP к открытым GOP, в которых предсказываемыми по разности, указанной относительно ключевого кадра, могут быть не только кадры, слѣдующіе за ключевым, но и кадры предшествовавшие. (Подробнѣе и нагляднѣе разница между закрытыми GOP и открытыми GOP показана в обзоре, по адресу https://ottverse.com/closed-gop-open-gop-idr/ расположенном, и дополняется по адресу https://ottverse.com/difference-between-i-frames-p-frames-b-frames/ объяснением использованных терминов «I-frame», «P-frame», «B-frame».)

Оборотная сторона этого метода — это задница, извините уж за выражение. По адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1548 нетрудно видеть, что многие видеопроигрыватели испытывают проблемы с проматыванием видеозаписей, созданных с открытыми GOP в SVT-AV1.

Когда двухмегабайтовое ограничение >>/d/2760 будет убрано, то я постараюсь не позабыть и для примѣра приложу тут одну такую видеозапись (аналог видеоцитаты >>/ts/6509, созданный с открытыми GOP): сможете попробовать во браузере, сможете скачать и попробовать в видеопроигрывателе — то и другое убеждает нагляднейше, что проматывание мрачно подтормаживает на много секунд, и чѣмъ далѣе к концу этой краткой (менѣе чѣмъ двухминутной) видеоцитаты, тѣмъ сильнѣе. Вообразите же по аналогии тот ад, в который этот эффект способен обращать многодесятиминутные или, тѣмъ болѣе, многочасовые видеозаписи.

И, кажется, проблема не только в видеопроигрывателях. Команда «ffprobe -loglevel error -select_streams v:0 -show_entries packet=pts_time,flags -of csv=print_section=0 имяФайлаВидеозаписи | find /n "K" >"%~n1.keyframes.txt"» также показывает только один ключевой кадр — первый.

Ещё один способ уменьшить вѣсъ ключевого кадра состоит в том, что тот кадр, на который ссылаются сосѣдствующіе, дѣлается сильно отфильтрованным (для устранения временнóй избыточности, чтобы разности между ним и предсказываемыми на его основе сосѣдними кадрами поуменьшилися), но невидимым (чтобы итог такой бѣшеной фильтрации не оскорблял собою взгляд зрителя), а показывается вмѣсто него итог наложения уточняющей разности на этот кадр, приводящей настоящий показываемый кадр к желаемому виду. Такой невидимый кадр называется альтернативно-ссылочным (ALTREF), и по адресу https://github.com/AOMediaCodec/SVT-AV1/blob/master/Docs/Appendix-Alt-Refs.md создание таких кадров (и корректирующих наложений на них) разъяснено поподробнѣе.

Оборотная сторона этого метода — та же задница, вдругорядь извините за выражение. То есть опять же по адресу https://bugs.chromium.org/p/aomedia/issues/detail?id=2862 ясно видна проблема с проматыванием видеозаписей, созданных в libaom-av1 с примѣненіемъ ALTREF и корректирующих наложений на них. (Эту проблему я ужé упоминал въ послѣднемъ пунктѣ сообщения >>161566.)

Можно утешаться надеждою при виде того, что эта проблема наблюдается по итогам работы libaom-av1, а в SVT-AV1 я ещё не пробовал создавать такие видеозаписи. Но не затаивайте дыхание в ожидании чуда: скорѣе всего, чудес не будет.

Ещё одним неприятным слѣдствіемъ одновременной неработоспособности SCD и ALTREF является похѣриваніе содержимого первого кадра новой сцены сильным зафильтровыванием, по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1857 наблюдающееся. Понятно, что этой проблемы с этим кадром ни в коем случае не было бы, кабы механизм SCD сдѣлалъ его ключевым (если проблема заключается в том, кадр не ключевой, а предсказательная сила не достаточна для точного предсказания его содержимого по соседним кадрам), а затѣмъ корректирующее наложение на ALTREF при необходимости привело показываемый кадр к желаемому виду (если кадр, сдѣлавшись ключевым, не избавился бы от проблемы, которая приобрела бы вмѣсто исходной новую форму необходимости сильной временнóй зафильтрованности кадра). Но вот хѣръ.

Вотъ обѣщанная труднопроматываемая видеоиллюстрация к сообщению >>181790.

Для поклонников самостоятельного видеокодирования сообщаю, что видеодорожка в этой видеоцитате создана вот какою командною строкою FFmpeg:

ffmpeg -hide_banner -i вырѣзаннаяЦитата.mkv -sn -map_metadata -1 -map_chapters -1 -crf 46 -b:v 0 -c:v libsvtav1 -svtav1-params keyint=479:scd=1:lookahead=120:tune=0:irefresh-type=1:lp=4 -preset 0 -strict experimental -c:a copy -movflags +faststart -flags -cgop итог.mp4

Важно ѿмѣтить, и ѿмѣчаю, что экономия ѿ «irefresh-type=1» составляет всего-навсего 1,27%: было 5 553 244 байтов, стало 5 482 503 байта (при равном битрейте звука цитаты, до его уменьшения перед размѣщеніемъ на 410чанѣ).

При измѣреніи экономіи я учёл, что параметр «keyint=480», с которым я кодировал видео до этого времени, не очень эффективен: в пособии https://github.com/AOMediaCodec/SVT-AV1/blob/master/Docs/svt-av1_encoder_user_guide.md#running-the-encoder рекомендуется дѣлать его дѣлящимся на 16 с остатком 1 (для закрытых GOP) или без остатка (для открытых GOP), если я правильно понял смысл выражения «forward frame» (исходя из того, что в таблице https://github.com/AOMediaCodec/SVT-AV1/blob/master/Docs/svt-av1_encoder_user_guide.md#gop-size-and-type-options сказано, что «FWD Frame» и «Open GOP» — одно и то же).

Поэтому, чтобы случайно не измѣрить эффективность «keyint=480» (становящуюся идеальной при переходе к открытым GOP) вмѣсто эффективности «irefresh-type=1» (то есть вмѣсто эффективности самогó перехода к открытым GOP), я заодно перешёл к использованию параметра «keyint=479» (который при «irefresh-type=1» должен быть настолько же неэффективным, насколько «keyint=480» при «irefresh-type=2» был до этого).

В идеале-то слѣдовало бы сравнивать «keyint=481» при значении по умолчанию и «keyint=480» при «irefresh-type=1» (чтобы значение keyint сравнивалося на максимальной эффективности). Может быть, со временем приду и к такому сравнению, а пока что меня сбило с толку то обстоятельство, что обсуждение https://old.reddit.com/r/AV1/comments/s7yyf9/help_me_understand_svtav1_parameters/ пришло к рекомендации использовать «irefresh-type=2» и «keyint=240» одновременно, так что с этого-то я и начал, тѣмъ болѣе что в пособии https://github.com/AOMediaCodec/SVT-AV1/blob/master/Docs/svt-av1_encoder_user_guide.md#running-the-encoder примѣръ (в котором параметр «--keyint 240» используется без указания какого-либо значения для irefresh-type, то есть по умолчанию) вроде как подтверждал это. Много позже я понял, что этот примѣръ сочиняли до того, как для рѣшенія проблемы https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1548 закрытые GOP начали использовать по умолчанию. Но къ нынѣшнему моему сравнению это понимание опоздало.

Сколько буков.
А по более низким CQP и CRF (соответствующим 13 и 16 у H264) и применимости этого дела для анимешных BDRip’ов так исследований и нет.
Я вот недавно получил, что -crf 16 -preset placebo -threads 1 -x264-params keyint=600:rc_lookahead=250:no_psy=1 оказывается чуть-чуть лучше по одной из цветовых компонент SSIM метрики, чем VP9 с CRF=10 (!) **-b:v 0 -crf 10 -tile-columns 0 -frame-parallel 0 -speed 0 -deadline best -threads 1 -aq-mode 0 -lag-in-frames 25 -auto-alt-ref 1 -g 600, хотя тот чуть-чуть выигрывал по PSNR и по VMAF.
Получил на первом эпизоде YrYr от FY-Raws, не на BlueRay’е, хотя и на нём в шестигигабайтовых файлах артефакты есть.

>>181833
Другая разметка под спойлером! Олдфажно.

>>181833

> Я вот недавно получил, что -crf 16 -preset placebo -threads 1 -x264-params keyint=600:rc_lookahead=250:no_psy=1 оказывается чуть-чуть лучше по одной из цветовых компонент SSIM метрики, чем VP9 с CRF=10 (!) -b:v 0 -crf 10 -tile-columns 0 -frame-parallel 0 -speed 0 -deadline best -threads 1 -aq-mode 0 -lag-in-frames 25 -auto-alt-ref 1 -g 600, хотя тот чуть-чуть выигрывал по PSNR и по VMAF.

А был ли VP9 двухпроходным при этом? А был ли x264?

>>181840
VP9 был двупроходный. Извиняюсь, что не указал.
x264 по CRF бывает только однопроходный.

Руководясь соображениями изъ послѣдняго абзаца в сообщении >>181828, на примѣрѣ приложеннаго к сообщению >>/ts/6509 видеоролика я провѣрилъ, насколько эффективным оказывается переход от «keyint=480» к «keyint=481» для достижения дѣлимости на 16 с остатком 1 (то есть для идеализации структур закрытых GOP, по инструкции https://github.com/AOMediaCodec/SVT-AV1/blob/master/Docs/svt-av1_encoder_user_guide.md#running-the-encoder совершаемой).

Оказалось, что при равном битрейте звука («-c:a libopus -b:a 64k») и при прежних настройках видео (не считая перехода от «keyint=480» к «keyint=481») видеофайл уменьшился: было 5 553 244 байта, стало 5 547 449 байта (достигнутый результат прилагаю опосля уменьшения битрейта звука для впихивания файла в 410чановское 5000-килобайтовое ограничение объёма).

Нетрудно сосчитать, что рѣчь идёт об уменьшении на 0,10%.

Между тѣмъ один только эффект от того, что вѣсомый ключевой кадр теперь приходится на каждые 481 кадров вмѣсто 480, должен был уменьшить удѣльный вѣсъ ключевых кадров на величину ⁴⁸¹/₄₈₀ = 0,208%.

Может ли разница между объёмом одного передвинутого ключевого кадра и одного добавленного промежуточного кадра быть настолько незначительною в каждой GOP, чтобы ≈вполовину уменьшить в конечном итоге тот эффект, который упомянут в предшествующем абзаце, и привести его к величине, упомянутой ещё одним абзацем выше? Нѣтъ, этого быть не может! Никоим образом не может! Ключевой кадр по объёму данных превосходит собою обычные кадры не в ≈два раза, а существеннѣе.

А могло ли совершенно случайно так получиться, что до перехода от «keyint=480» к «keyint=481» один из ключевых кадров случайно попадал на начало очередной сцены (и оттого случайно был эффективнѣе даже съ тѣмъ хѣровымъ SCD, о котором шла рѣчь выше в сообщениях с номерами от >>181780 до >>181828 включительно), а переход к «keyint=481» вызвал такое рѣзкое падение эффективности, которое (даже если его одно раздѣлить на весь файл) оказалось уполовинивающим собою выигрыш от оптимальной структуры GOP?

В это мнѣ также трудновато повѣрить. Я скорѣе предположу, что для «irefresh-type=2» придумали какой-нибудь компенсатор длины GOP на единицу, так чтобы кратное 16 значение keyint продолжало оставаться оптимальным, но документацию https://github.com/AOMediaCodec/SVT-AV1/blob/master/Docs/svt-av1_encoder_user_guide.md#running-the-encoder позабыли обновить. Я продолжу употреблять «keyint=480» въ дальнѣйшемъ.

Как и в видео >>181828, приложенный файл использует CRF 46 (на единицу больше, чѣмъ >>/ts/6509), и всё же битрейт его звука пришлось понизить до «-c:a libopus -b:a 37.55k», чтобы файл помѣстился на 410чан. Рост видеобитрейта (равный необходимому уменьшению аудиобитрейта) я отношу не только на счёт неэффективности, неисправным SCD порождаемой с 18 марта. Допускаю (и даже считаю вѣроятнымъ), что и исправление бага https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1847 (проявлявшаго себя как визуальное «уполовинивание частоты кадров» въ тѣняхъ; увы, даже тѣни видеоролика >>181116 этому эффекту оказались подвергнутыми!) также досталося наращиванием битрейта видеодорожки во имя отказа от чрезмѣрностей темпоральнаго фильтра, которыми прежде достигалася дополнительная экономия видеобитрейта.

На примѣрѣ видеофайлов https://nowere.net/b/src/1648562012457.webm и https://nowere.net/b/src/1648648646033.webm (содержащих AV1-представление того AMV 2015 года, которое по адресу https://amvnews.ru/?go=Files&in=view&id=6451 находится) я также попробовал эффект от параметра «enable-overlays=1» (второй из упомянутых файлов отличается употреблением этого параметра).

Во-первых, я с радостью убеждаюсь на практике, что проблема, под конец сообщения >>180818 упомянутая, оказалась совершенно исправленною, как это теперь и на странице https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1834 говорится — с 19 марта исправленною. Кодировщик не зависает.

Во-вторых, я вижу с радостью, что проблема с проматыванием видеозаписей, созданных в libaom-av1 съ примѣненіемъ кадров ALTREF и корректирующих наложений на них (упоминаемая по адресу https://bugs.chromium.org/p/aomedia/issues/detail?id=2862 и вызывавшая мою досаду, выраженную в сообщениях >>161566 и >>181791) — эта проблема, по-видимому, не существует для видеозаписей, созданных в SVT-AV1: видеофайл https://nowere.net/b/src/1648648646033.webm проматывается невозбранно (я провѣрялъ и во браузере Mozilla Firefox 98.0.2, и в видеопроигрывателе Media Player Classic Home Cinema 1.9.20).

В-третьих, при равном битрейте звука («-c:a libopus -b:a 64k») и при прежних настройках видео (CRF 14, нулевой пресет SVT-AV1 и tune=0, тридцатибитные пикселы) видеофайл увеличился: было 17 362 340 байтов, стало 19 147 479 байтов. Нетрудно сосчитать, что рѣчь идёт об увеличении на 10,28%.

Ѽ ёлки-палки! Как это слѣдуетъ понимать?

Либо приходится признать безоговорочно, что на практике опровергнутым оказывается моё предшествующее убеждение >>181791 насчёт того, что примѣненіе кадров ALTREF и корректирующих наложений на них — это способ уменьшить вѣсъ ключевых кадров. Ни хѣра этот способ не уменьшает, а оказывается методом наращивания качества ключевых кадров за счёт роста объёма файла. (Но тогда зачѣмъ такой метод вообще может быть нужен? — не лучше ли уменьшить CRF и тѣмъ приподнять качество вообще всѣхъ кадров видеозаписи, а не одних только ключевых, тѣмъ болѣе что при неисправном SCD кадры становятся ключевыми или промежуточными по воле случая, не отражающего их роль в первоисточнике?)

Либо приходится задуматься о том, может ли примѣненіе кадров ALTREF и корректирующих наложений на них оказаться непригодным как способ уменьшения вѣса ключевых кадров имѣнно въ тѣхъ условияхъ, в которых я его только что протестировал, а внѣ этих условий оставаться пригодным. Но что ж мѣшаетъ ему? — у меня четыре версии:

① При неисправных SCD ключевой кадр выбирается посередь сцены и оттого чаще всего мало отличается по содержимому от послѣдующихъ кадров — слѣдовательно, наращивание временнóго усреднения не экономит вообще ничего. Иными словами, эта версия предполагает, что про ALTREF лучше забыть до тѣхъ пор, пока в SVT-AV1 не починят SCD.

② Даже при исправных SCD наращивание временнóго усреднения было бы полезным для экономии объёма только тогда, когда невидимый ALTREF-кадр в начале новой сцены был средним между начальным содержимым новой сцены и конечным содержимым предшествующей, чтобы успѣшно использоваться для предсказания и предшествующих, и послѣдующихъ кадров. Иными словами, эта версия предполагает, что про ALTREF лучше забыть до тѣхъ пор, пока видеопроигрыватели не начнут справляться с открытыми GOP.

③ В обсуждении https://old.reddit.com/r/AV1/comments/sxw8be/vq_tuning_mode_being_added_to_svtav1/ было сказано, что SVT-AV1 в режиме tune=0 ограничивает рамки временнóй фильтрации всего одним кадром, слѣдующимъ за ключевым. Иными словами, эта версия предполагает, что про ALTREF лучше забыть до тѣхъ пор, пока в SVT-AV1 не появится возможность отказаться от tune=0 с сохранением качества (пока этой возможности нѣтъ: напримѣръ, упомянутая в седьмом пункте сообщения >>180819 проблема рассыпания кадров на макроблоки невѣрнаго вида была закрыта по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1810 со словами «при tune=0 всё ok», так что попытка отказаться от tune=0 означает ныряние с головою в направлении как этого, так и других подобных «подводных камней»).

④ Высококачественность провѣряемаго видеоролика была доведена почти до предѣла возможного использованием довольно малого значения CRF (а мы всѣ понимаем, что 14 — это не 55 и даже не 23), поэтому можно вообразить кодировщик удѣляющимъ качеству ALTREF и качеству корректирующего наложения чрезмѣрное внимание в ущерб экономии объёма файла (и даже в ущерб воображаемой мною нацѣленности самогó механизма ALTREF на экономию этого объёма). Иными словами, эта версия предполагает, что мнѣ надо будет провѣрить эффект от параметра «enable-overlays=1» при замѣтно меньших битрейтах видео.

Двѣ новости окажутся радостными для поклонников видеоформата AV1:

① Во браузер Firefox 99 внедрили версию 1.0.0 декодировщика dav1d: https://bugzilla.mozilla.org/show_bug.cgi?id=1758482

Главным образом при этом улучшилася скорость и многопоточность.

② Авторы кодировщика SVT-AV1 выпустили версию 1.0.0: https://old.reddit.com/r/AV1/comments/u9bfg3/svtav1_v100_released/

К первому релизу кодировщик подходит с единственным замѣтнымъ недостатком, ужé упомянутым в сообщении >>181780 и далѣе: ключевые кадры расставляются тупо через каждые N кадров (через сколько задано), и кодировщик даже не пытается переставлять их къ тѣмъ моментам, в которые одна сцена смѣняется другою в кодируемой видеозаписи.

>>181833
Протестировал это дело на Blue-Ray’ном исходнике первого эпизода весом в 6 GiB, который предварительно был без потерь перекодирован в MKV (H.264/FLAC). CRF 16 для libx264 был выбран, потому что именно с таким CRF кодировали Coalgirls.
AV1 прогнал через сегментирующий параллелировщик в 8 потоков. Сегменты ставит по keyframe’ам и scenecut’ам. Учитывая, что libaom-av1 при таком CRF keyframe’ы ставил довольно агрессивно, и что файл был разбит всего на 27 сегментов не менее 1200 кадров длинной, серьёзных увеличений размера файла от этого было быть не должно.
В итоге выяснилось, что CRF 12 у libvpx-vp9 не хуже, чем CRF 16 у libx264, ни по одной из метрик, хотя по Y-компоненте в SSIM там скорее впритык. Ещё, libvpx-vp9 не сильно медленнее, чем libx264 в плацебо-режиме.
CRF 16 у libx265 не хуже, чем CRF 16 у libx264, также ни по одной из метрик. По U и V компонентам PSNR незначительно хуже, чем у libvpx-vp9, но незначительно лучше по Y и в среднем. Внезапно, оказался значимо хуже, чем VP9, по VMAF.
aomenc — это чудовище. И в смысле времени кодирования, и в смысле результата. На 24% меньше размер файла и на 36% меньше размер у видеопотока, чем у файла с H.264, при метриках не хуже, чем у каждого из опробованных кодеков. В сравнении с libx265, размер файла меньше на 11% и размер видеопотока на 18%. Может, отчасти помогают внутренние 10 bit, с 10-bit’ным pix_fmt я другие кодировщики пока не тестировал.

Какой процессор надо для нормального кодинга видяо? На i3 7th gen ~1000x500 100fps даже на cpu-used 3 кодится неприлично долго, а реальный выиграш в качестве/размере идет где-то на cpu-used 1. Иначе ради пары мегабайт и бороться не зачем.

ps libaom

Вот, с реддита рандомное видео.

ffmpeg -i I\ don’t\ remember\ seeing\ this\ on\ history\ channel\ \[k8rzwehm0f091\].mp4 -c:a copy -c:v libaom-av1 -cpu-used 1 -aq-mode 1 -lag-in-frames 48 -g 300 -pix_fmt yuv420p10le -crf 45 -b:v 0 -threads 4 out.mkv

заняло больше получала и прокодировало только 38 секунд, я психнул и выключил. У человека блюрей серия, вероятно, 24 минуты за 86 часов прокодировалась, так ведь там разрешение наверное 1080р!
Не понимаю.

>>184738
>>184740

> кодится неприлично долго, а реальный выиграш

Прежде всего можно рекомендовать уход от libaom к libsvtav1 и создание AV1 непремѣнно с тридцатибитными пикселами (то есть с десятибитными компонентами цвѣта) даже при truecolorном первоисточнике видео (руководясь малоустаревшим пониманием https://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf того обстоятельства, что при таком наращивании битности качество растёт сильнѣе, чѣмъ объём файла).

Руководясь графиком >>180816, можно опосля этого искать баланс между стремлением получить «реальный выиграш» (Bjøntegaard-Delta) и опасением получать его «неприлично долго».

> Какой процессор надо для нормального кодинга видяо? На i3 7th gen

Опираясь на изложенныя по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/CommonQuestions.md#threading-and-efficiency или https://github.com/AOMediaCodec/SVT-AV1/blob/master/Docs/CommonQuestions.md#threading-and-efficiency свѣдѣнія о способности libsvtav1 занять около шестнадцати ядер процессора кодированием видео 1080p с использованием пресетов 4—6 (меньше пресет — меньше скорость и меньше параллелизма, зато выше качество), идеалом процессора для движка libsvtav1 приходится счесть шестнадцатипоточные модели (для десктопов они начинаются у Intel от Core i7 и от Core i9 десятого поколения, а у AMD от Ryzen 7 4700GE и от Ryzen 7 Pro 4750GE).

А так-то и на i3 7th gen (быть может, на том именно, который в сообщении >>164400 упоминался) можно достичь пристойных результатов, поставив однопоточное кодирование в фоне на нѣсколько суток и занимаясь в это время другими дѣлами на остальных трёх потоках.

> ради пары мегабайтов и бороться незачѣмъ

В случае 410чановского 5000-килобайтового ограничения лишняя пара мегабайтов означает выигрыш болѣе чѣмъ 40%, то есть на предѣлѣ сжатия это разница между возможностью и невозможностью положить сюда видеоцитату болѣе чѣмъ 220-секундную (как >>181116 напримѣръ).

получаса*

>>184777
Ну ладно. Обидно просто, что нельзя вкусить сладкий плод прогресса до покупки нового процессора, которая может вообще и не будет никогда.

>>184776

① Скачал видео https://twitter.com/nanosaur/status/1288410954548428801 посредством yt-dlp.

② Получил файл 7 815 887 байтов, содержащий кадры 886×582 пикселов.

③ Запустил перекодировку:

ffmpeg -hide_banner -i скачанный.mp4 -sn -map_metadata -1 -map_chapters -1 -crf 43 -b:v 0 -c:v libsvtav1 -svtav1-params keyint=20s:scd=1:lookahead=120:tune=0:lp=4 -pix_fmt yuv420p10le -preset 0 -strict experimental -c:a libopus -b:a 64k -movflags +faststart -flags +cgop результат.mp4

④ FFmpeg работал 6 часов 42 минуты, так что это как раз задача на одну ночь.

⑤ Я увидѣлъ, что объём файла многоват для 410чана, но так как неохота дальше возиться (моей цѣлью был не идеальный файл, а выяснение длительности работы FFmpeg при нулевом пресете), то просто уменьшаю битрейт звука:

ffmpeg -hide_banner -i результат.mp4 -i скачанный.mp4 -map 0:v:0 -map 1:a:0 -map_metadata -1 -map_chapters -1 -c:v copy -strict experimental -b:a 19.02k результат.webm

⑥ Полученный файл прилагаю.

⑦ То обстоятельство, что до этого уменьшения битрейта файл был великоват для 410чана, объясняется странным фактом: если в сообщении >>180865 «одновременно снижение CRF на единицу и уменьшение скорости видеокодирования до предѣла возможного» приводило к экономии объёма файла, то на сей раз даже увеличение CRF на единицу не компенсировало собою рост объёма файла при обнулении пресета. С шестидесятичетырёхкилобитовою звуковою дорожкою при «-crf 42 -preset 6» получался файл 5 319 543 байта, а при «-crf 43 -preset 0» получился файл 5 385 535 байтов. Возможно, такой хѣровый первоисточник (видеозахват доцифрового телеэфира 2007 года, надо полагать? — да ещё и прошедший через агрессивное твиттеровское видеосжатие, давно ставшее притчею во языцех даже не в переносном смысле этого выражения, а в прямом международном смысле!) просто-напросто не позволяет серьёзно экономить объём файла увеличением CRF.

⑧ В сообщении >>181116 опечатка въ послѣднемъ абзацѣ: вмѣсто «При CRF 63 объём видеофайла рѣзко возрастает» слѣдуетъ читать «При CRF 62 объём видеофайла рѣзко возрастает». (Имѣлся в виду рѣзкій ростъ объёма видеофайла, наблюдавшийся при уменьшении CRF всего-навсего на единицу по сравнению съ предѣльно высоким CRF 63, разсмотрѣннымъ в предшествующем абзаце того сообщения.)

>>184782
>6 часов 42 минуты

>>184738
Чем дороже и новее, тем лучше, но смотря для какого видео. Чем длиннее, тем легче оно параллелится.
Сейчас в идеале что-то типа https://www.amd.com/en/products/cpu/amd-epyc-74f3 было бы заполучить, но с DDR5 и более Threadripper’ного плана, или когда там SaphireRapids выйдут. Отнюдь не только для кодирования видео, правда.

>>184776
Разрешение 1080p. Но у вас видео, которое с камеры, а там аниме. У аниме сложность кодирования, если нет большого количества движения, не такая большая. Потом, у меня параллелизм по сегментам и yuv420p, у вас yuv420p10le и aq-mode=1, хотя и больший CRF.
Ноутбук с Ryzen 7 5800H и неплохой системой охлаждения. Cinebench R23 давал 1410 в 1 поток и 11663 в 16 потоков. Стабильно держит 10—11 ватт на работающее ядро, если нагружать не более 3-х ядер, и 7—8.5 ватт на ядро при полной нагрузке.

>>184799

> у меня параллелизм по сегментам

А на какой операционной системе и посредством чего? — не https://github.com/master-of-zen/Av1an ли, случаем?

> и yuv420p

По адресу https://en.wikipedia.org/wiki/AV1#Profiles сказано, что даже основной профиль AV1 поддерживает десятибитные компоненты цвѣта, так что каждый видеопроигрыватель, способный воспроизводить TrueColor AV1, теоретически должен быть способным воспроизводить и тридцатибитные пикселы.

Я это к тому, что, может быть, не стоило ограничивать себя yuv420p, так как yuv420p10le обеспечивает нѣсколько лучшее соѿношеніе качества и объёма файла.

>>184807
>не av1an ли
Спешу ответить за того человека, потому что если вчитаться в >>183327 а в особенности обратить внимание на скриншот, то можно прийти к выводу, что таки да.

Между тѣмъ я перекодировал >>184782 однопоточно (lp=1) с чуть меньшим качеством видео (-crf 44) и получил видеофайл из 5 113 367 байтов, который довёл до 410чанского объёма повышением указанного битрейта Opus до 70,79 килобитов в секунду.

FFmpeg работал 17 часов 27 минут в то время, когда я занимался другими дѣлами, иногда вычислительно сложными (файлы PNG для архива >>/a/18350 переужимал в oxipng, напримѣръ), так что эту оцѣнку необходимого времени слѣдуетъ понимать какъ оцѣнку сверху.

Результат прилагаю.

Дополнительно могу подтвердить (и подтверждаю, но с неудовольствием), что я был прав въ послѣднемъ абзаце сообщения >>181866: исправление ошибок качества, свойственных видеоролику >>181116, сопровождается в недавней новой версии кодировщика (SVT-AV1 v1.1.0) ростом битрейта.

Да ещё каким ростом-то!

Со звуковою дорожкою (Opus 64k) результат переужатия видеоролика https://youtu.be/puRNQbSMEwo даже на предѣле возможного (CRF 63) получается равным 7 362 384 байтам MP4, так что он:

① не может быть засунут на 410чан при посредстве уменьшения битрейта звука (даже вообще без звуковой дорожки и даже с использованием формата WebM для экономии объёма, по адресу https://t.me/ReadMithgol/330 и https://twitter.com/FidonetRunes/status/1370925530808254466 упомянутой, получается 5 446 020 байтов, что больше 5000 килобайтов),

② превосходит даже тот объём, который видеоролик >>181116 имѣлъ при CRF 62 (этот объём упомянут въ послѣднемъ абзаце сообщения >>181116, но учтите опечатку, упомянутую в восьмом пункте сообщения >>184782).

>>184912
В общем, нужно разработчикам настучать и по голове и по рукам! Совсем думать не хотят, нарастили эти ваши биторейты и радуются!!

При подготовке видеоролика >>184824 я увидѣлъ, что этот видеоматериал 4K, если кодировать его на нулевом preset и с шестидесятичетырёхкилобитным звуком,

при CRF 61 занимает 8 271 839 байтов,

при CRF 62 занимает 6 022 029 байтов,

при CRF 63 занимает 4 087 827 байтов, которые прилагаю.

Наблюдаемая двухмегабайтовая разница превосходит даже ту полуторамегабайтовую, которая была подмѣчена в только что упомянутом послѣднемъ абзаце сообщения >>181116; стало быть, видео 4K замѣтно сильнѣе (чѣмъ fullHD 1080p) реагируетъ на единичныя измѣненія значеній CRF, близкихъ къ предѣльнымъ.

Но при тѣхъ же условиях разница между >>184782 (7 815 887 байтов при CRF 43) и >>184912 (5 113 367 байтов при CRF 44) ещё значительнѣе (2 702 520 байтов), а вѣдь тамъ 582p.

Однако ПАРАДОКС.

(Можно думать: зато там значения CRF далеки ѿ предѣла CRF 63; но разве въ послѣднемъ абзаце сообщения >>181114 я не видѣлъ, напротив, уменьшение реакции на CRF при ѿдаленіи ѿ предѣла? — видѣлъ, видѣлъ!…)

>>184912
Однако вам не кажется, что кодить 17 с половиной часов шакальнейшее видео низкого разрешения это не совсем то, чего хочется?

Начинающая собою вторую серию аниме «ISUCA» игра слов «бака нэко» и понятия https://ru.wikipedia.org/wiki/Бакэнэко была ужата мною в полдесятка приёмов:

① Сперва, для быстроты запустив шестой пресет, я увидѣлъ, что при CRF 35 видеофайл получает объём 4 163 464 байта. (Здесь и далѣе в FFmpeg передаётся указание поддерживать битрейт аудио шестидесятичетырёхкилобитным, если не сказано нѣчто другое.)

② Затѣмъ, быстро попробовав тот же пресет при CRF 31, я увидѣлъ, что видеофайл дорос до объёма 5 096 875 байтов. Грубо (то есть без учёта нелинейности зависимости) можно было сосчитать, что каждая единица CRF прибавляла в среднем чуть менѣе четверти мегабайта.

③ Так как 410чановский 5000-килобайтовый предѣлъ объёма был почти достигнут, то на медленном нулевом пресете я попробовал то же значение CRF 31, однако увидѣлъ, что видеофайл достиг объёма 5 665 608 байтов. Налицо тот же рост объёма при обнулении пресета, который наблюдался и в седьмом пункте сообщения >>184782. Приходится обобщить наблюдения и прийти к выводу о том, что такой рост вообще отличает собою послѣднія версии кодировщика SVT-AV1.

④ Руководясь тѣмъ, что в седьмом пункте сообщения >>184782 рост объёма при обнулении пресета не преодолевался увеличением CRF на единицу, в этот раз я попробовал нулевой пресет при CRF 33 и тѣмъ невозбранно достиг желаемого: объём видеофайла сократился до 4 922 092 байтов и стал годящимся для 410чана. (Здесь вы видите эту видеоцитату приложенною с наращиванием битрейта звука, который во FFmpeg указывался, до 86,67 килобитов в секунду.)

⑤ Чтобы провѣрить, не окажется ли промежуточное значение случайно подходящим для создания пятимегабайтового видеофайла, я также ещё попробовал нулевой пресет при CRF 32, однако увидѣлъ, что объём видеофайла возрос до 5 355 887 байтов (то есть чуть болѣе, чѣмъ до половины между объёмами, при CRF 31 и CRF 33 наблюдавшимися) и оттого потребовал бы такого снижения битрейта звука (чтобы умѣститься в 5 мегабайтов), которое не оправдывается ростом CRF (качество видео и без того достаточно высоко, а качество звука снизилось бы значительно).

Ѿдѣльно ѿмѣчу, что этот эффект измѣненія объёма файла на ≈350 килобайтов из-за измѣненія CRF на единицу (при нулевом пресете и CRF 31→33) согласуется съ примѣромъ >>180820 (там был также нулевой пресет, но CRF 56→54), а на ≈четверть мегабайта (выше, при шестом пресете) — согласуется съ примѣромъ >>180865 (там был также шестой пресет, но CRF 55→54), то есть величины это болѣе или менѣе привычныя.

Предлагаю пожать желание Мицу-нян сжимать вообще всё и вся. Желательно на чём-то старом, чтобы было долго и мявчительно!
прислала верхняя левая булочка кошкодевочки

>>185272
У Мицгола и так старый i7 поколения IvyBridge.

С удовольствием сообщаю, что побѣдилъ досадный рост битрейта, ѿмѣченный в сообщении >>184912 и не дававший видеоклипу https://youtu.be/puRNQbSMEwo опосля видеосжатия, в SVT-AV1 совершённого, достигнуть 410чановского объёма даже в случае крайнего уменьшения битрейта звука.

Достигнута эта побѣда была прибавлением «hierarchical-levels=5» к списку тѣхъ параметров, с которыми SVT-AV1 вызывается из FFmpeg. Тѣмъ самымъ на единицу наращивается количество иерархических уровней внутри мини-групп кадров, длина мини-групп удваивается, предсказуемость кадров наращивается (за счёт болѣе дальняго использования сосѣднихъ кадров как основы для предсказания промежуточных), видеосжатие нарастает (но, кажется, дольше работает кодировщик; а автор рекомендации https://old.reddit.com/r/AV1/comments/v2kguu/how_to_improve_av1_software_decoding_speed_to_the/ предполагает, что и декодировщик также утруждается чуть сильнѣе — хотя и не так значительно, как от других нюансов AV1).

Видеофайл достигает объёма 5 466 231 байтов в MP4, так что для достижения 410чановского объёма достаточно снизить указываемый ФФмпегу битрейт звука с 64 «двоичных» килобайтов до 52,30 и притом ещё смѣнить контейнер на WebM — результат прилагаю.

Ясно вижу, что пока это лучший результат по степени сжатия, поскольку ранѣе видеоролику >>181116 потребовалось сокращение битрейта аж до 35,99 «двоичных» килобитов в секунду, и даже видеоролику >>175216 (кодировашемуся не в libsvtav1, а в libaom-av1) — до 44,57.

Опережая >>175216 по степени видеосжатия, нынѣшній результат всё же не достигает тогдашней степени повреждения тонкоконтурных пляшущих сѵмволовъ над головами у персонажей и персонажиц. Слѣдовательно, дополнительно подтверждается вывод (из первого абзаца сообщения >>181116) о том, что libsvtav1 лучше бережёт мелкие детали: если раньше ещё можно было скептически усумниться и подозрѣвать, что единственно рост видеобитрейта тому причиною, то теперь видеобитрейт меньше на 7¾ килобита в секунду, но всё же менѣе выражены (по сравнению с итогом работы libaom-av1) повреждения тонкоконтурных пляшущих сѵмволовъ над головами у персонажей и персонажиц. Это убедительно и наглядно.

Эффект тѣней, движущихся рывками, остаётся ясно выраженным у нынѣшняго результата (как и у >>181116 и даже >>175216), поэтому я склонен предполагать, что он вызывается предѣльно высоким значением CRF (равным 63) при любом кодировщике AV1 и что поэтому исправления бага https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1847 его не коснулися при таком CRF.

Кроме того, никак нельзя относить на счёт побочного эффекта от исправления бага https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1847 и тот (ещё ранѣе этого исправления происходивший) рѣзкій рост битрейта перекодированного видеоклипа https://youtu.be/puRNQbSMEwo при уменьшении CRF на единицу, который упоминается въ послѣднемъ абзаце сообщения >>181116 (но должен читаться с учётом опечатки, упомянутой в восьмом пункте сообщения >>184782).

Дык вот оказывается, что прибавлением «hierarchical-levels=5» к списку тѣхъ параметров, с которыми SVT-AV1 вызывается из FFmpeg, можно уменьшить и этот рост, то есть при CRF 62 перекодированный видеоклип в формате MP4 приобретает объём 6 489 107 байтов, который, во-первых, больше >>185746 всего-навсего на 1 022 786 байтов (разница менѣе чѣмъ мегабайтовая, то есть сократившаяся примѣрно раза в полтора по сравнению с упомянутою въ послѣднемъ абзаце сообщения >>181116), а во-вторых, теоретически может быть даже засунутым на 410чан, если указываемый битрейт звука уменьшить с 64 до 18,92 «двоичных» килобитов в секунду и перемѣнить видеоконтейнер на WebM.

Я пишу «теоретически» только потомý, что такой битрейт всё же оказывается малым и недостаточным для пѣсни — можете послушать самостоятельно, так как результат я прилагаю.

Правда, зато этой цѣною (вмѣстѣ со всѣми предшествующими трюками, такими как полный отказ от расстановки ключевых кадров, ещё в четвёртом пункте в сообщении >>180818 упоминавшийся и затѣмъ в попытке >>181116 впервые к видеоклипу https://youtu.be/puRNQbSMEwo примѣнённый) достигается такой высокий уровень качества видеопотока, лучше которого при этой силе сжатия ужé не будет.

(А какой силе сжатия? — напоминаю, что ещё в сообщении >>175216 было сказано, что рѣчь идёт о болѣе чѣмъ тринадцатикратном уменьшении объёма файла, в котором видеоклип https://youtu.be/puRNQbSMEwo хранится.)

Наблюдения, изложенные в этом и предшествующем сообщении, убеждают меня в том, что прибавление «hierarchical-levels=5» к списку тѣхъ параметров, с которыми SVT-AV1 вызывается из FFmpeg, оказалось изрядно благотворным (и стóящим того, чтобы сильнѣе утруждать кодировщик и декодировщик), так что и впредь я намѣренъ этот параметр неуклонно использовать.

Дальнѣйшія испытания параметра «hierarchical-levels=5» (показавшего рост отношения качества к объёму файла въ примѣрахъ >>185746 и >>185747) я повёл кодированием видеофайла https://youtu.be/TL9qWmZ7FB4 (основою для обсуждения >>143059 служащего), по-прежнему передавая в FFmpeg указание снабжать видеоряд шестидесятичетырёхкилобитовою аудиодорожкою и кодировать нулевым пресетом libsvtav1.

При CRF 55 получился файл, состоящий из 4 775 201 байта.

При CRF 54 получился файл, состоящий из 5 042 872 байтов.

При CRF 53 получился файл, состоящий из 5 340 170 байтов и поэтому наиболѣе близкий к тому объёму (5 209 699 байтов), который упомянут в третьем абзаце сообщения >>180820 — стало быть, наиболѣе подходящий для сравнения с тогдашним.

Уменьшением битрейта звука доведя этот файл до 410чановского ограничения объёма, я положил его в сообщение >>185938.

По образцу сообщений >>180820 и >>180821 и >>180822 я также вытащил из полученного видео тот видеокадр, который располагается на ѿмѣткѣ времени 3,93 секунды — этот кадр я прилагаю тут.

Сличая этот кадр с предыдущим результатом видеосжатия (к сообщению >>180820 приложенным) и с видеокадром первоисточника (к сообщению >>180822 приложенным), нетрудно видѣть лучше переданными два контура полутѣней (то есть не яркие и не чёрные, а промежуточной яркости):

① В предыдущем результате видеосжатия кончик шарфа на груди исполнителя приобретал геометрическую форму, тяготеющую к прямоугольности, а теперь — болѣе закруглённую или хотя бы болѣе тупоугольную форму.

② В предыдущем результате видеосжатия правая часть нижней губы исполнителя сливалась с фоном (подбородком), а теперь она прорисовывается в кадре точнѣе.

Мне нравятся результаты работы SVT-AV1 с параметром «hierarchical-levels=5» не только ввиду того, что рост объёма файла при убавлении CRF на единицу выглядит разумнѣе. По-видимому, с этим параметром и объём видеофайла, получающегося при шестом пресете, систематически меньше видеофайла, получающегося при нулевом пресете. (Впрочем, я стёр результаты экспериментов и оттого пересказываю то впечатление, которое прямо сейчас нечем подтвердить.)

Подумать только, что впервые на идею использования параметра «hierarchical-levels=5» я набрёл при чтении пункта 2.3 в сообщении https://old.reddit.com/r/AV1/comments/v2kguu/how_to_improve_av1_software_decoding_speed_to_the/ на Reddit.

Это сообщение, появившееся в сáмом начале июня, вообще-то посвящено было настройке другого кодировщика (libaom-av1) и для другой цѣли (не чтобы видео получше сжималося, а чтобы быстрѣе декодировалося), но я увидал там примѣръ параметров «--gf-max-pyr-height=4 --max-reference-frames=4» — и тотчас же понял, что по умолчанию иерархия уровней в libaom-av1 глубже четырёх и что поэтому для достижения противоположной цѣли (лучшей видеосжимаемости) можно и в другом кодировщике (в SVT-AV1) наращивать число уровней.

Сразу скажу ещё, что результаты работы SVT-AV1 с этим параметром не всегда бывают так убедительно хороши, как в сообщениях >>185746 и >>185747 и >>185939.

Так, напримѣръ, динамичный видеоролик >>169016 не содержит столько предсказуемости, чтобы хватало для эффективной работы 2⁵=тридцатидвухкадровых подгрупп кадров. Повторив его кодирование в SVT-AV1 (вмѣсто кодировщика libaom-av1, для приложения к сообщению >>169016 употреблявшегося), я получаю видеопоток съ нѣсколько бóльшим битрейтом (указание битрейта звука приходится понизить до 41,16 килобитов в секунду, чтобы помѣстить видео на 410чан — а в приложении к сообщению >>169016 было 46,54 килобита в секунду), но этот рост видеобитрейта не сопровождается никаким замѣтнымъ измѣненіемъ качества кадров (можете сами поглядѣть: итог работы SVT-AV1 я прилагаю), и формальный показатель качества кадров (CRF 61) также остаётся одним и тѣмъ же при вызове обоих кодировщиков.

К другим новостям: по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/1948 видно, что 19 июня в кодировщик SVT-AV1 добавили поддержку динамического измѣненія матриц квантования. Примѣрный смысл этой фичи хорошо изложен в документе https://datatracker.ietf.org/doc/html/draft-davies-netvc-qmtx-00 восемь лѣтъ назад (в 2016 году) и сводится к тому, чтобы ради нѣсколько лучшей сжимаемости видеофайла (около 3%) подвергнуть кадры нѣкоторому «замыливанию» (хуже передавая высокочастотные пространственные компоненты въ тѣхъ кадрахъ, качество которых достаточно великó и оттого не сильно «замѣтитъ» такое ухудшение).

Но эта трёхпроцентная оцѣнка касается кодека Thor (одного из предшественников AV1). Я попробовал фичу в SVT-AV1 на примѣрѣ видеоролика >>185747 и не замѣтилъ улучшения видеосжимаемости — как раз наоборот: видеофайл так распух, что превзошёл восемь миллионов байтов, так что засунуть его на 410чан нѣтъ никакой возможности. Подозрѣваю либо баг в кодировщике, либо идейную непродуманность всей фичи, либо неподходящесть её под обстоятельства SVT-AV1.

>>186640
Почему я каждый раз так смеюся из этого видео?

>>186642
Потому что все мы Химари-чан. Как если бы она в последний день жизни пыталась проинсталлировать генту и у нее бы не получилось.

>>186663
Предлагаешь опять начать насиловать пассажиров инсталлировать ГНУЛинукс?

>>186664
А тут есть неоплодотворенные? Только если сам Соус. Да и то пытался, хотя и не смог.

>>186665
> А тут есть неоплодотворенные?
Есть девочки, которые таблетки от этого пьют.

>>186668
От ГНУЛинукса не таблеток! Здесь не помогут ни мази ни лекарства...

>>186669
Как хорошо, что я сижу на мастдай и линукс теилс а не ГНУЛинукс.
>>186668
От такого типа оплодотворения данным образом не спастись.

>>186670
>линукс теилс а не ГНУЛинукс
А какой же дистрибутив по вашему наиболее достоен называться ГНУЛинуксом?

>>186672
Извиняюсь, я затупил и принял общее имя ОС на базе линукс, за название конкретного дистрибутива.

>>186672
> достоен
Чего только не напишешь в 6 утра.

>>186665
А кто же с нами постоянно воевал до придушения восстания и вводе прекюр?
>>186675
Осуждать GNUish вещи, это как осуждать systemd. Только systemd вносит кучу bloatware, которое я никогда не использую, а чисто GNUish вещи бывают весьма полезные. GNU это так плохо.

>>186676
>восстания

>>186686
Совус сказал не обсуждать это. Не знаю почему, но не очень-то и хотелось. Вот.

>>186689
Знать бы о каком восстании речь.

>>186690
Ересь Линукса, 0.265.022.М3.

>>186693
Против самих себя восставать что-ли?