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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

_____________

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

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

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

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

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

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

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

Нѣтъ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>160968

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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