>>2178
Можно было бы даже первьюшки в png генерить, но они как правило в 2-3 раза больше места занимает при том же размере картинки, безлимитки же есть не у всех.

>>2179
На новере есть хоть один не безлимитчик? Просьба отписаться в треде.

>>2180
Да, есть.

>>2178
>>2180
Лол, превьюшка больше оригинала.

>>2181
Насколько всё плохо? Если ограничить помимо разрешения, ещё и размер, к примеру, в 30кб? Я не настаиваю, если что.

>>2183
Учитывая что средний размер тумбнейла в /b/ 11 кб, если это все пережать в png то получится 56 кб в среднем. Если не для кого не критичен такой размер тумбнейла то можно будет сделать их и в png.

Тумбнейлы теперь в png. Тестируем.

>>2185

>>2186
Тест с ресайзом

Здорово, работает. Спасибо.

так погодите, модкун, что ты запилил?

>>2189
Тумбнейлы теперь генерятся в png а не jpg.

>>2190
и что? прозрачность типа будет нормальная?

>>2191
Типа того.

>>2191
Ну вот же например: >>2187 >>2188 >>2186

>>2194
бля. сделай апнг, модкун.

>>2196
Ни в коем случае. У некоторых не безлимит. Это только в случае мячика 70кб вместо 5, apng очень большие, да и постоянная анимация ни к чему.

А можно в список допустимых форматов внести svg и webp?

>>2198
А еще pcx, bmp, psd, xcf, xpm, ico, pnm, cur, ani, avi, mkv, ogm, ogv, ts, exe, tiff, raw, psp, ai, swf, wmf, pns, jps, djvu, pdf, ps, img, bin, без них ведь просто невозможно жить!

Кстати превью в png это вин. Такой контраст ранее загруженных картинок и новых.

>>2199
Большая часть перечисленного не поддерживается браузерами.

>>2201
Если пропатчить самописным патчем то будет работать.

>>2202
svg и webp пропихиваются как будущий веб-стандарт от w3c и google. Впрочем ты прав, пока рано о них говорить, дождёмся когда станут популярны. Opera Turbo 11.10 уже конвертирует в webp вместо jpg http://news.softpedia.com/news/Opera-Turbo-Employs-Google-s-WebP-Image-Format-for-Faster-Load-Times-194902.shtml

SVG опасен тем, что может содержать JavaScript.

mp4 было бы неплохо добавить в связи с повальной конвертацией gif->mp4 на некоторых сайтах

В роли некоторых сайтов — imgur и Twitter и Telegram.

>>4611

ffmpeg -i source.mp4 -b:v 5M destination.webm

>>4614
Может, мне ещё тамбнейлы к картинкам самому генерировать?

>>4614

Тогда уж «ffmpeg -hide_banner -i source.mp4 -c:v libvpx-vp9 -crf 18 -b:v 0 -tile-columns 2 -threads 8 destination.webm», для того чтобы и распараллеливалося, и новый высококачественный формат VP9, и контроль качества по CRF вместо битрейта.

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

>>4616
vp9 по дефолту в webm давно, распараллеливание на любителя, с одной стороны быстрее, с другой - увеличивает размер файла при тех же параметрах

> исходник MP4 на таких сайтах обыкновенно бывает преизрядно фиговатый

Всегда можно поискать оригинал

>>4617

> vp9 по дефолту в webm давно

А насколько давно FFmpeg начал по умолчанию использовать VP9 для WebM? (В их вики https://trac.ffmpeg.org/wiki/Encode/VP9 до сих пор предлагается вручную указывать этот кодировщик.)

>>4619
Неужели так сложно Changelog почитать?
https://github.com/FFmpeg/FFmpeg/blob/master/Changelog#L335

>>4620

Понятно. Это отвечает на мой вопрос: так как правка https://github.com/FFmpeg/FFmpeg/commit/2392da164a02e4e4f7e1b933018d14afcb13ddc1 была внесена 28 августа 2015 года, то и VP9 действует по умолчанию с того же времени.

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

>>4617

> распараллеливание на любителя: с одной стороны, быстрее, с другой — увеличивает размер файла при тех же параметрах

Это наблюдение совершенно справедливо, однако при наличии двадцати мегабайтов (как на Nowere) редкий видеофайл станет вплотную упираться в них, так что на первый план выходит ускорение кодирования, потому что это одна из важных частей удобства кодирования: она позволяет не утомлять себя сверх меры ожиданием до такой психологической крайности неуюта, за которою даже приступать к видеокодированию придётся без удовольствия, а не то и с надрывом, чего доброго.

Ѿдѣльно ѿмѣчу, что на сайтѣ https://animeloop.org/ предлагаютъ GIF и MP4, но не WebM.

Ещё раз подчёркиваю, что и Telegram поддерживает MP4, но не WebM, так что видео из Telegram (даже подходящие по размеру) нипочём нельзя будет класть на Nowere (без перекодировки) до тех пор, пока Nowere не начнёт поддерживать MP4.

То же самое касается и Твиттера.

>>4891
Проприентарно
@
ненужно

>>4897

Што проприетарно?

>>4899

>>4901

Чей сървъръ?

>>4899
MP4 несвободен, поддерживать его на линукс-ориентированном ресурсе я считаю неправильным.

По адресу https://bugs.chromium.org/p/chromium/issues/detail?id=746579 я вижу упоминание о том, что юристы Google сочли, что контейнер MP4 (MOV) перестал быть проприетарным.

Думаю, что смысл реплики >>4903 должен быть поэтому отнесён скорее к видеопотоку H.264 и аудиопотоку AAC внутри такого контейнера.

Пожалуй, в этом отношении указание на проприетарность справедливо.

Впрочем, ему недолго осталось быть таковым. На этот счёт по адресу https://people.xiph.org/~negge/NAB2019.pdf сорок пятый «слайд» обещает нам скорый приход видеопотоков AV1 в MP4. (Скриншот прилагаю.) Что же касается аудиопотоков, то формально списочек http://mp4ra.org/#/codecs на сайте MP4 Registration Authority довольно широк (и включает, например, Opus), так что недостаёт только некоего толчка для того, чтобы употребление их обрело силу обычая и перестало наталкиваться на «это не принято делать, так что такой файл не воспроизведётся».

Запасёмся терпением.

>>4904
Но ведь av1 можно и в webm заворачивать.

>>4905

Нѣтъ, нельзя. В настоящее время по адресу https://www.webmproject.org/docs/container/ ясно сказано, что видеопотоком может быть только VP8 или VP9.

Ну то есть разработчики родительского формата (MKV) вроде бы родили по адресу https://matroska-org.github.io/matroska-specification/codec/av1.html документ о том, как можно засунуть AV1 в MKV (и, следовательно, в WebM — потому что WebM является переименованным MKV с ограничениями использованных возможностей MKV), но с этим две проблемы:

во-первых, никакой из поддерживаемых MKV видеокодеков не становится новинкою WebM до тех пор, пока не одобрен авторами WebM (то есть Гуглом) в явном виде, а пока что этого не произошло;

во-вторых, в Википедии по адресу https://en.wikipedia.org/wiki/AV1#Supported_container_formats сообщается (хотя и без приведения каких-либо ссылок на первоисточник этого мнения), что документ https://matroska-org.github.io/matroska-specification/codec/av1.html в действительности не был окончательным и что продолжается внесение потенциально обратно-несовместимых изменений в спецификацию, так что она далека ещё от окончательности. И если это википедическое сообщение соответствует действительности (а не представляет собою продукт беспочвенного викивандализма), то тогда, быть может, именно эта нефинальность и удерживает Google от одобрения новинки в WebM.

>>4906

> то тогда, быть может, именно эта нефинальность и удерживает Google от одобрения новинки в WebM.

Значит это просто вопрос времени.

Время покажет, было ли это в действительности вопросом времени.

Предлагаю посмотрѣть по адресу https://evilmartians.com/chronicles/better-web-video-with-av1-codec#how-to-use-av1-right-now на блогозапись с упоминанием того именно, что видеоролики AV1 слѣдуетъ засовывать в контейнер MP4 — именно это там называется поддерживаемым новѣйшими версіями браузера Chrome и браузера Firefox, число пользователей которых автор блогозаписи в августе 2019 года счёл равным 31%, а теперь их уж и 34%.

>>5048
Там он выбран как наиболее популярный.

Ну дык ить вот:

принимая во внимание наибольшую популярность размѣщенія видеопотока AV1 со звуком Opus в контейнере MP4,

и принимая во внимание то, что другой вариант: размѣщеніе видеопотока AV1 со звуком Opus в контейнере WebM — и менѣе популярен, и противоречит расположенному по адресу https://www.webmproject.org/docs/container/ требованию создателей стандарта WebM не совать в WebM никаких других видопотоков, кроме VP8 и VP9 (а требование это они с 2017 года не мѣняли, а если хотели бы — перемѣнили бы, включив в него AV1: раньше же перемѣнили, когда включили VP9),

и принимая во внимание то, что сомнения >>4897 и >>4903 о несвободе MP4 уничтожаются (для рассматриваемого частного случая) свѣдѣніями >>4904 о том, что контейнер MP4 (MOV) перестал быть проприетарным, а также изначальною свободою AV1 и Opus,

предлагаю администрации Nowere впредь допускать публикацию файлов MP4 с видеопотоком AV1 и со звуком Opus на имиджборде.

Если нужен наперёд технический совѣтъ о том, как такие файлы MP4 отличать от других файлов MP4, то пожалуйста: вызов команды «ffprobe -v error -show_entries stream=codec_name -of default=noprint_wrappers=1:nokey=1 имяФайла.mp4» для такого файла должен выводить (и выводит) ряд текстовых строк, одна из которых непремѣнно будет «av1» (без кавычек), а другая — «opus» (без кавычек же). При этом на остальных строках может быть что-нибудь ещё болѣе другое — напримѣръ, упомянутое по адресу https://trac.ffmpeg.org/ticket/2149 сообщение об ошибке «Referenced QT chapter track not found» с префиксом в квадратных скобках, шестнадцатеричное число внутри которого зависит от сборки FFprobe.

>>5055
Помоему проще будет av1 в стандарт webm протолкнуть.

Послѣдній ѳезисъ реплики >>5055 можно и усилить: вызов команды «ffprobe -v quiet -show_entries stream=codec_name -of default=noprint_wrappers=1:nokey=1 имяФайла.mp4» для такого файла должен выводить (и выводит) только двѣ текстовые строки, одна из которых (чаще всего — первая) непремѣнно будет «av1» (без кавычек), а другая — «opus» (без кавычек же).

Остаётся лишь порадоваться тому, что onus probandi по отношению къ ѳэзису >>5056 лежит не на мнѣ.

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

>>5064
Вот-вот, пихать AV1 в WebM — это проявление бесстыдного антисемитизма. А ты какой-то неправильный антисемит, раз этого делать не хочешь.

>>5065

Не надо словами «вот-вот» дѣлать вид, что этот странный тезис как-то слѣдуетъ из моего предшествующего рассуждения.

Рѣчь у меня прежде всего идёт о том, чтобы,

во-первых, использовать видеопоток AV1 наиболѣе общепринятым (наиболѣе популярным) способом, то есть внутри контейнера MP4,

во-вторых, дать возможность тѣмъ посетителям Nowere, которые раз за разом сѣтуютъ о невозможности открыть тот или иной файл WebM (потому что в нём находится AV1), простую и ясную возможность отличать видеофайлы AV1 по расширению файла, то есть создать правило: если на Nowere лежит файл MP4, то тогда видеопоток в нём — непремѣнно, непремѣнно AV1.

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

Впрочем, как я это по адресу https://t.me/ReadMithgol/330 наблюдаю (растровую копию сообщения прилагаю), в контейнере WebM видеозапись оказывается на пару-тройку килобитов в секунду покомпактнѣе, чѣмъ въ MP4.

(Доводов >>5055 это не ѿмѣняетъ, однако же. Просто помогает меньше досадовать по поводу того, что к ним не прислушалися.)

В пользу mp4 могу сказать, что youtube-dl качает именно в него, вследствии чего приходится дополнительно переконвертировать как и в случае с >>4611 так что некоторый смысл добавить имеется, несмотря на мицгола

>>5351
youtube-dl качает в тот фотрмат, который ты выберешь.

>>5352
Нет, но он умеет сам конвертировать в выбранный формат после скачки.

>>5352
Возможность такая есть, но бывает так, что видеопоток лучшего качества в H.264 закодирован. Изредка натыкался ещё и на то, что VP версий вовсе нет.

>>5351
Ещё можно было бы упомянуть, что с некоторых других борд есть контент в MP4. Постить его, соответственно, будет проблема.

>>5354

> есть контент в MP4

Я был бы только рад его поддержке на Nowere.

Но увы: насколько я понимаю, выше в репликах >>4897 и >>4903 сообщалось, что видео AVC (H.264) поддерживаться не будет ввиду проприетарности, невзирая даже на объявление https://www.mpegla.com/wp-content/uploads/n-10-08-26.pdf (ещё 2010 года) о том, что MPEG LA не будет облагать платежами интернетовские видеозаписи AVC, бесплатныя для конечных пользователей (то есть, надо думать, для зрителей — но, может быть, непремѣнно и для выкладывающих также).

Реплики >>4897 и >>4903 поданы были без шапки администратора, но онѣ, и это по всему видать, дѣйствительно отражают собою направление администрирования сайта Nowere.

Сам-то я изложил (год назад и притом также 14 марта) компромиссный рецепт >>5058, позволяющий несложно узнавать, когда в контейнере MP4 (а этот контейнер вслѣдствіе >>4904 перестал быть проприетарным, так что вопросы теперь могут быть не к контейнеру, а только к содержимому) находится лицензионно чистый видеопоток AV1 со звуком Opus, «но воз и ныне там».

Тѣмъ временем я повторил наблюдение >>5350, но на сей раз надъ тѣмъ видеофайлом, который по адресу https://410chan.org/b/src/161560781245.mp4 располагается — и вижу, что его WebM-вариант (который тут прилагаю) позволяет засунуть в одно и то же пространство (5000 килобайтов) всего-навсего на полкилобита в секунду больше, чѣмъ въ MP4 (при идентичном видеоряде AV1 прилагаемый файл WebM содержит звук Opus с битрейтом 81,43 килобита в секунду, тогда как в файле https://410chan.org/b/src/161560781245.mp4 всего лишь 80,93 килобита в секунду — и это опять же «десятичные килобиты» по счёту FFmpeg, то есть по 125 байтов в килобите).

Как нетрудно видѣть, это в 5½ раз меньше, чѣмъ наблюдавшийся въ примѣрѣ >>5350 выигрыш ѿ перемѣны форматов (там было 2¾ килобита в секунду, а тут — только половина килобита в секунду). И если по адресу https://twitter.com/FidonetRunes/status/1368009422275047426 я ещё мог рассуждать, что каждый килобит на счету, то вот полукилобитом я ужé готов пренебречь безъ малѣйшаго угрызенія совѣсти.

Ещё можно указать, что и объём файла также меньше ≈вчетверо (поскольку 410чан куда сильнѣе экономит дисковое пространство); но мнѣ очень трудно вообразить себе такой механизм, благодаря дѣйствію которого прибыток битрейта файла оказывался бы примѣрно прямо пропорционален объёму его (даже настолько примѣрно, насколько 4≈5½), так что я считаю это простым совпадением, а не свидѣтельствомъ зависимости битрейта ѿ объёма.

>>5367
Твои рассуждения об экономии позволю себе прервать единственным заявлением о том, что наибольшего эффекта можно достичь просто забанив мицгола, а поскольку этого не происходит рискну предположить, что дисковое пространство не является значимым ресурсом.

>>5365
mp4 без h264 не нужен, потому что проебётся весь профит от его использования >>4611

ИМХО, уже поздно героически сдерживать распространение h264, он, сука, везде. Проблема поддержки в других контейнерах яйца выеденного не стоит: если вебм это часть от матрёшки, просто разрешить матрёшку https://bugzilla.mozilla.org/attachment.cgi?id=9079385&action=diff

По-моему, в комментарии https://bugzilla.mozilla.org/show_bug.cgi?id=1562862#c12 насчёт идеи >>5370 ясно сказали (скриншот прилагаю), что впиливать в Firefox поддержку тѣхъ кодеков, за которые надо платить патентные отчисления, никто не собирается, поэтому поддержка MKV ограничится рамками WebM.

То и другое, впрочем, никак не мѣшаетъ поддержать на Nowere сочетание AV1 и Opus в контейнере MP4, так что тут угадывается единственно политическая воля администрации, как и в случае с неподдержкою WebP и AVIF.

>>5390
Хитрый мод просто ждёт, когда возня с форматами закончится и все перейдут на JPEG XL, поддержку которого добавлять не потребуется, так как он и так совместим с jpeg и отображается (в обычном jpeg-качестве) на любом устройстве.

>>5391

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

Никакой возможности открыть произвольный JPEG XL в приложении, понимающем только JPEG, не существует, что нетрудно самостоятельно провѣрить на примѣрѣ семидесятидевятибайтового файла JPEG XL, по адресу https://twitter.com/jonsneyers/status/1382631163995512841 приведённого в формате data-адреса (RFC 2397).

Растровую копию прилагаю.

>>5392
Блджад, развели жыпегов https://jpeg.org/jpegxt/ имелся в виду.

Мне лично http://ds.jpeg.org/whitepapers/jpeg-xs-whitepaper.pdf больше всего интересен в контексте стриминга на VR, но смысла поддерживать его на новере я не вижу.

>>5393

JPEG XT не вызвал интереса браузеропроизводителей, так как не предлагал лучшего сжатия, чѣмъ предшествующий формат JPEG.

Источник: десятый кадр презентации https://www.slideshare.net/cloudinarymarketing/imagecon-2019-jon-sneyer

Интерес же браузеропроизводителей вызывает JPEG XL — новая версия JPEG, которая способна обеспечивать пересохранение прежних JPEG без потерь с улучшенным сжатием. Те же изображения, которые никогда не были прежними JPEGами, а вместо того создаются в формате JPEG XL с сáмого начала, получают целую полудюжину возможностей:

① Поддержка не только канала прозрачности, но и дополнительных каналов различного предназначения (инфракрасность, показания дальномера, etc.).

② Поддержка повышенной битности цвета (не хуже, чем в AVIF).

③ Возможность сжатия без потерь, по силе сжатия оставляющего остальные форматы такого сжатия далеко позади, за исключением разве что WebP в некоторых частных случаях (прежде всего такими случаями являются скриншоты текста без цветных картинок).

④ Возможность сжатия с потерями, по силе сжатия при равном качестве опережающего прежний JPEG чуть более, чем в два раза, но отстающего от AVIF при сильном сжатии (особенно когда битов в файле становится меньше, чем пикселов).

⑤ Для всех тех блоков сжатия, на которые делится изображение (то есть для квадратиков 8×8 пикселов или более крупных), их значения усреднённого цвета хранятся в начале файла, поэтому размытое предпросмотровое изображение (уменьшенное по ширине и по высоте в восемь раз) поступает из Сети гораздо раньше остального файла, даже когда отображение файла задумано как построчное, а не как «progressive JPEG XL».

⑥ Progressive JPEG XL заметно распухает по объёму, зато позволяет использовать недокачанный файл как уменьшенный по размеру в два раза, в четыре раза и так далее. Экономия для тех, кто заботится об экономии траффика мобильных пользователей и умных часов, но не желает для этого напрягаться, создавая и храня отдельные файлы с версиями картинки, предназначенными для экранов QHD (1440p), HD (720p) и qHD (360p). Ну или для тех, кто закладывается на рост разрешения больших экранов, но не хочет отдельно создавать и хранить версии картинки для 8K (4320p), 4K (2160p) и FullHD (1080p).

На скриншотах по адресу https://i.redd.it/s3l1g2b40jt61.png и https://i.imgur.com/ezQPsaW.png ясно видно, что Google Chrome (в тестовой версии Canary) ужé содержит поддержку JPEG XL, просто сокрытую за флагом в настройках. Один из скриншотов прилагаю.