[WT] [Архив]  [Поиск] Главная Управление
[Совместно с Ычаном]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 17662)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, OGG, PDF, PNG, PSD, RAR, SVG, SWF, TXT, XCF, ZIP размером до 10000 кБ.
  • Ныне 3052 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 500
151072352512.jpg-(480.67KB, 2369×2000, 1368044744342.jpg)
17662
No. 17662 watch    
Добрый день!
Интересно было бы увидеть реализацию поддержки .webm для Вакабы (на примере Ычана), imagick в качестве внешней программы. Требования к реализации:
- наличие у видео тамбнейла в виде первого кадра, а не просто заглушка;
- запрет на загрузку файлов со звуком;
- поддержка прочих форматов: .mp4, .ogv;
- плеер по нажатию в теле страницы, а не отдельным окном.

Перспектива расширения функционала ресурса при наличии готового решения достаточно высока.
84 сообщений пропущено. Показаны 50 последних сообщений Развернуть все изображения
No. 17833    
151119584143.png-(704.65KB, 686×1043, pizdets[cropped].png)
17833
Слѣдованіе совѣту >>17830 позволило мнѣ увидѣть, что, напримѣръ, видеороликъ http://nowere.net/cg/res/2920.html не искажается по ширинѣ, такъ что вродѣ какъ нечего и пытаться тутъ починить то, что не сломано.
No. 17835    
>>17830
>>17832
О, а я могу-таки себя оправдать.
Иичановская открывалка кортинок использует бгомерзкий calc для максимальной ширины с константой под маргины, от которого можно избавиться, заменив один костыль (в виде нынешнего calc) на другой (в виде box-sizing и всего прочего).
No. 17836    
151120325314.png-(112.75KB, 431×431, 079Slowpoke.png)
17836
>>17835
No. 17837    
151120339297.jpg-(26.76KB, 590×425, няшный котик.jpg)
17837
>>17835

Ну дык WagonOfDoubt это самое по адресу https://github.com/WagonOfDoubt/iichan-extensions/commit/b067eb068f560275bac848100e7c39b600b24ab6#diff-0d5f41f25ce9bcf42091fc838b3d054fR52 и сделал шестнадцатого числа.

Осталось накатить на Ычан.
No. 17838    
>>17836
>>17837
Ну не стукойти!
width:auto там всё равно нету.
No. 17843    
151120691797.jpg-(97.39KB, 1165×777, Позор российским каменщика.jpg)
17843
>>17838

По-видимому, этого не нужно потому, что WagonOfDoubt той же правкою обеспечил задание ширины иллюстрации через JavaScript.
No. 17862    
151131359890.jpg-(212.39KB, 1281×600, Конец мира на нас.jpg)
17862
При рассмотрении кода https://github.com/WagonOfDoubt/iichan-extensions трудно удерживаться (и не удерживаюсь, не удерживаюсь!) от убеждённости в том, что его сложность непомерна по сравнению с той, которой этот исходный код обладал бы в том случае, если бы Ычан использовал jQuery (джаваскриптовую библиотеку, по адресу http://jquery.com/ предлагаемую).

Это касается и каких-то мелочей, вроде ошибки >>17741 с последующею необходимостью использовать длиннокод «parentNode.insertBefore(vp, e.currentTarget.nextSibling)» вместо jQueryйного «$(this).after(vp)» из трёх слов.

Это касается и более крупных архитектурных вещей: например, целый десяток строк кода функции «init» по адресу https://github.com/WagonOfDoubt/iichan-extensions/blob/1564715cb31f7e30ba617b39b7d9192e6334aa23/src/expand-images/expand-images.main.js#L57-L66 и весь внешний цикл в вызываемой функции «addListeners» сочинён для того только, чтобы, во-первых, навесить обработчик жмяка мышою на каждую миниатюру, а во-вторых, при необходимости повторить это навешивание, когда число миниатюр в коде документа увеличивается (при подкачке и развёртывании обсуждений?…) — тогда как в случае jQuery достаточно было бы единственного обработчика, в коде «$('body').on('click', '.thumb', …)» на месте многоточия указанного, и в силу jQueryйного механизма всплытия и делегирования событий эти четыре нехитрых слова заменили бы более дюжины строк нынешнего кода-обёртки.

Более всего неприятны последствия того, что эта обёртка использует конструктор «MutationObserver», который по словам https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver#Browser_compatibility появился только в достаточно новых браузерах (Chrome 26, Firefox 14, Opera 15, IE11, Safari 7, всѣ Edge) — особенно пагубно его отсутствие в Internet Explorer ранее одиннадцатой версии: с остальным-то ещё можно было бы примириться, а тут явное ограничение тех браузеров, в которых ещё могло бы работать развёртывание и миниатюр, и даже видеозаписей.

Такое положение дел нельзя терпеть.

В довершение отмечу, что совершенно того же всплытия и делегирования событий сильно недостаёт, например, тому исходному коду показа родительских реплик в обсуждениях на 410чанѣ, который без jQuery поневоле был сочинён таким менее функциональным способом, от которого при наведении на «>>циферки» хотя и всплывает желаемый прямоугольник с указанною репликою, но зато не всегда: если «>>циферки» появились в документе попозже начальной его загрузки (через нажатие на кнопку «Expand Thread»), то тогда не всплывает.
No. 17863    
151132235528.jpg-(301.78KB, 1683×1200, VelKnVladimir.jpg)
17863
>>17862

> Такое положение дел нельзя терпеть.

Напилил https://github.com/WagonOfDoubt/iichan-extensions/pull/10/files для подкачки и употребления jQuery.
No. 17864    
151132308297.jpg-(74.88KB, 604×508, песец сферический.jpg)
17864
Дополнительно сообщаю, что на Ычане надо отпилить атрибут «type="text/javascript"» ото всех HTML-тегов «script», потому что и без него по умолчанию так.
No. 17866    
151132710454.png-(632.45KB, 715×921, __yakui_futaba_channel_and_nijiura_maids_drawn_by_.png)
17866
>>17863
Давайте может не будем пихать людям в глотку сторонние либы, когда решение уже есть?

Плюс, это прямо противоречит >>15850:
>Желательно, чтобы скрипты были достаточно легковесны, чтобы помещаться в wakaba.js. Минимальными должны быть и предлагаемые правки вёрстки самих страниц (радикально никто ничего перепиливать не будет).
>Предпочтительная лицензия скриптов — общественное достояние (public domain), как у самой «Вакабы».
>Пока всё. Администрация не рассматривает идеи подключения куклоскриптов или чего-то подобного тяжеловесного целиком, так как стремится сохранить минимализм интерфейса сайта.
No. 17881    
151136816446.jpg-(38.30KB, 530×428, Фаустпатрон у бойца из Гитл.jpg)
17881
>>17866

Когда они пришли за работоспособностью дополнений Ычана в подкачиваемой части обсуждения в IE9 и в IE10, я молчал.

Я не был пользователем IE9 или IE10.
No. 17882    
>>17881
Они и без MutationObserver в IE10 вполне работоспособны.
No. 17884    
15114707583.jpg-(258.83KB, 437×678, Существа.jpg)
17884
>>17882

Работоспособны только после того,¹ как WagonOfDoubt внёс в код правку https://github.com/WagonOfDoubt/iichan-extensions/commit/132f8bba2fb2f1af87b21161327ef73053b73d9c для проверки на существование конструктора MutationObserver.

А без этого код функции «init()» выпадал бы в IE9 и в IE10 с ошибкою, я так думаю. Да и как бы не выпасть ему?

____________

¹ Скрипт сырнифицирования потребовал также внесения более поздней правки https://github.com/WagonOfDoubt/iichan-extensions/commit/d37f03a10b0ff638e2735330a3a67666964c6a96 для обеспéчения таковой работоспособности.
No. 17911    
>>17825
Мне кажется, там договорённость такая. Никто не должен говорить о смене Мод-тян. И вообще это всё миф. Хотя Мод-тян образца 2008 сильно отличается от нынешней.
No. 17912    
>>17911
Человек мог измениться за десять лет.
No. 17915    
151169451235.png-(344.61KB, 496×358, nature.png)
17915
>>17912
No. 17950    
151200712192.png-(3.20MB, 1920×1080, Onii-chan no Koto nanka Zenzen Suki Janain Dakara .png)
17950
Через неделю охотно присоединяюсь ко мнению тех читателей доски разработки, которые предлагали не задерживать дыхание в предвкушении реализации вышеозначенной возможности на Ычане.
No. 17971    
>>17950
Мицгол, зачем тебе эти видео? Картинок не хватает?
No. 17975    
>>17971
Картинок, очевидно, не хватает. Никогда не хватало, иначе бы не использовали дикий костыль в виде .gif. Сейчас особенно не хватает, иначе не было бы буквально на 95% ресурсов поддержки хотя бы .webm. Даже на традиционно отстающих в техническом плане на десять лет японских бордах давно поддержка есть, это вообще нонсенс.
No. 17976    
151215852771.png-(124.95KB, 256×256, 1348841890438.png)
17976
>>17971
«Шоб было», очевидно же.
No. 18002    
>>17971

Обсуждать аниме и не иметь возможности видеоцитирования — вот что заслуживает объяснения, а не «зачем?»: появление первого HTML5-видеопроигрывателя относится (как по блогозаписи http://www.wiumlie.no/2007/video/ видно) к 28 февраля 2007 года, и если с тех пор на протяжении десятилетия (десятилетия, カルル!) никто не почесался с реализацией на имиджборде, то это ё█░▓ый стыд.

(Ещё я в /dev/ упомянул одну такую российскую имиджборду, на которой видео поддерживается со звуком, но мою реплику стёрли, вероятно сочтя её нарушением запрета на разжигание межчановской розни. Так что здесь не будет аргумента «берите пример с…», а придётся обойтись аргументом «давно пора и очевидно для чего».)
No. 18014    
151248687966.png-(385.84KB, 841×480, Rei_smiling_(Rebuild).png)
18014
>>18002
Я думал, ты сам стёр
Да, даже на Футабе есть, причём давно.
> одну такую российскую имиджборду
У нас одна крупная имиджборда, и на ней мало что поддерживается вообще.
Кстати, Соус мог бы у себя сделать уже и показать пример.
No. 18015    
151248888694.jpg-(68.72KB, 502×560, 1504149800159.jpg)
18015
>>18014
>Кстати, Соус мог бы у себя сделать уже и показать пример.
А на кой хѣръ оно мне надо?
И с нашими нынешними темпами это всё равно будет позже Ычана, даже если мне напишут код.
No. 18415    
151507498775.png-(2.29MB, 1920×1040, Mononoke Hime.png)
18415
>>18014

> У нас одна крупная имиджборда, и на ней мало что поддерживается вообще.

А что я тогда за гиперссылку по адресу https://krylov.cc/prnt.php?id=18497 вижу на MP4 со звуком? Или это очередной заговор умолчания в духе there's no Tsukihime anime? Ну умалчивайте, чё.
No. 18425    
>>18415
Ну мы подразумеваем имиджборды, а не чаты для гыгыкающих школьников.
No. 18431    
151512358758.png-(502.86KB, 818×641, Katawa Shoujo - Socializing!.png)
18431
>>18425

Возможно.

Надеюсь только на то одно, что аргумент «даже чаты для гыгыкающих школьников возымели поддержку WebM и MP4, а ты — нѣтъ», во-первых, от этого не становится менѣе вѣсомымъ, а во-вторых, никому и в голову не придёт пойти на него в атаку с контраргументом «дык именно поддержка WebM и MP4 превращает имиджборды в чаты для гыгыкающих — и даже, страшно выговорить, для гыгыгыкающих! — школьников» наперевес, потому что это не так, а всё дѣло въ культурѣ модераціи.
No. 18433    
>>18431
Я не против .webm и .mp4, ведь даже японская Футаба ввела поддержку. Просто не надо смотреть на какие-то "сайты для гыгыгыкающих школьников" в качестве примера.
No. 18461    
Приделали эти ваши видосы.

Алсо, просили передать, чтобы вы синхронизировали код скриптов с используемой на Ычане версией, если вдруг будете предлагать правки.
No. 18462    
151524782190.png-(11.96KB, 384×384, 1149375679025.png)
18462
>>18461
>эти ваши
Не наши, а ваши. Я вообще бы в /gf/ сидел.
>чтобы вы синхронизировали код скриптов с используемой на Ычане версией, если вдруг будете предлагать правки.
Яваскриптов? А то я, например, по ним никакие правки предлагать не буду, а яваскриптерам моя тестовая доска для отладки вообще не сдалась.
No. 18464    
>>18462
>Яваскриптов
Да, это про них.
No. 18599    
151573908031.png-(2.66MB, 1920×1080, Kobayashi-san Chi no Maid Dragon - deathma.png)
18599
>>17662

> - запрет на загрузку файлов со звуком;

Этот запрет контрпродуктивен.

По адресу https://iichan.hk/a/res/1364782.html ычаньки обсуждают эндинги, и им даже нельзя позагружать их для прослушивания.
No. 18618    
>>18433
> .mp4, ведь даже японская Футаба ввела поддержку
Предоставь пруф, что именно .mp4 поддерживается на футабе тоже.
No. 18669    
151604019158.png-(1.81MB, 1280×720, Code Geass.png)
18669
>>18618

Футаба поддерживает только WebM.
No. 18670    
151604318888.png-(576.06KB, 1114×1600, Kanojo wa Rokurokubi screenshot 3.png)
18670
Сообщаю тот формат вызова FFmpeg из командной строки, которым сам пользуюсь в пакетных файлах для создания MP4 и WebM без звука и без субтитров:

ffmpeg -hide_banner -i %1 -ss %3 -to %4 -an -sn -c:v libx264 -crf %2 -preset veryslow -tune animation -profile:v baseline -level 3.0 -movflags +faststart ibvideo.%2.mp4


ffmpeg -hide_banner -i %1 -ss %3 -to %4 -an -sn -c:v libvpx-vp9 -crf %2 -b:v 0 -tile-columns 2 -threads 8 ibvideo.%2.webm


Подстановка параметров записана тут в стиле Windows («%» + номер), под неWindows переделывается тривиально.

Предполагается вызов, например, команды «имяПакетногоФайла имяВидеоФайла.mkv 22 3:33 5:55», где «22» — значение CRF (Constant Rate Factor), а «3:33» и «5:55» — отметки времени (откуда и докуда вырезать фрагмент из видеофайла «имяВидеоФайла.mkv»).

Предполагается простая возможность раз за разом вызывать одну и ту же команду с прежними значениями отметок времени, но с разным CRF, значение которого удобно записывается в имени выходного файла, что в дальнейшем позволяет подбирать его шаг за шагом — то есть можно, например, сравнить по размеру файл «ibvideo.40.webm» (с CRF 40) и «ibvideo.38.webm» (с CRF 38) и прийти к выводу, что первый меньше трёхмегабайтового предела, а второй больше его, так что можно запустить команду ещё раз со значением CRF, равным 39, и тогда точно будет видно, какой файл грузить на Ычан.

Дополнительное чтиво:

https://trac.ffmpeg.org/wiki/Encode/H.264 ← пособие по параметрам кодирования H.264 в MP4

https://trac.ffmpeg.org/wiki/Encode/VP9 ← пособие по параметрам кодирования VP9 в WebM

https://developers.google.com/media/vp9/settings/vod/ ← гуглопособие на ту же тему

https://ffmpeg.org/ffmpeg.html ← перечень общих параметров командной строки FFmpeg
No. 18676    
151606449215.png-(1.34MB, 1280×720, Code Geass.png)
18676
За неимением звука у некоторых ычанек возникает желание фигачить субтитры растром в видеозаписи, и фигачат.

В полном объёме этот трюк рассмотрен по адресу https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo в вики FFmpeg, а вкратце достаточно прибавить параметр «-vf subtitles=%1» к любой из двух вышеприведённых командных строк и тем невозбранно достигнуть желаемого.

Файл «%1» («имяВидеоФайла.mkv» или как его там) при этом должен содержать субтитры (а в большинстве видеозаписей аниме так и есть), а имя этого файла должно быть простым (FFmpeg склонен воспринимать как служебный символ, например, апостроф, хотя в названиях некоторых файлов аниме он есть — придётся переименовывать их перед употреблением).
No. 18692    
151620852281.mp3-(8.91MB, TheFatRat - The Calling (feat_ Laura Brehm).mp3)
18692
  >>18015

> И с нашими нынешними темпами это всё равно будет позже Ычана, даже если мне напишут код.

Так и вышло.
No. 18694    
>>18692
Кода-то никто не написал.
No. 18702    
151630770848.mp3-(2.00MB, 2-19 Friendship.mp3)
18702
  >>18694

Ну дык¹ никто и не сказал вместо «на кой хѣръ надо» слова «интересно было бы увидеть», «перспектива внедрения высока», «требования к реализации — такие-то».

__________

¹ К моей реплике присоединена звукозапись «Friendship» из альбома «Enigmatic Box of Sound», прилагаемого к визуальному роману «Katawa Shoujo». Автор мелодии — NicolArmarfi. Источник звукозаписи — страница https://www.katawa-shoujo.com/download.php на сайте визуального романа. Право на распространение звукозаписи даётся лицензией Creative Commons BY-NC-ND, на странице https://www.katawa-shoujo.com/about.php указанной.
No. 18703    
151631178780.mp3-(2.50MB, VanishingHorizon.mp3)
18703
  Кстати, напиливать там всего ничего: в функцию «createThumbnail» в файле /inc/func/posts.php воткнуть наперёд ещё одно условное выражение, которое для видеофайлов будет создавать миниатюру способом, функционально аналогичным приведённой в архиве http://yakuji.moe/wakaba/diffs.zip в файле wakaba.diff строчке 189 — вот только не на Перле, разумеется, а на PHP.¹

(Или я не прав?)

________

¹ К моей реплике присоединена звукозапись «Vanishing Horizon». Её автор — Jason Shaw. Источник звукозаписи — сайт http://audionautix.com/ её автора. Право на распространение звукозаписи даётся лицензией Creative Commons Attribution 3.0 Unported, на сайте указанной.
No. 18704    
Если вы будете использовать загрузку аудио не по назначению (для обсуждения неких ваших проектов, так или иначе использующих звуковые файлы), она будет просто отключена до востребования.

Перспективы видео на 410чане можно обсудить в >>17371, эту нить угонять не надо.
No. 19332    
151967030515.gif-(9.69MB, 1387×780, Knight's & Magic - coding.gif)
19332
В настоящее время по адресу https://iichan.hk/n/ сказано, что загрузка видеофайлов доступна только «в некоторых разделах», список которых даже не приводится там. Автор реплики https://iichan.hk/d/res/244600.html#245044 перечисляет не менее полутора десятков невидеофицированных досок Ычана, и у меня нѣтъ основаній не вѣрить этому списку.

Вот почему изложенные в реплике >>18670 инструкции по созданию WebM и MP4, дополненные в реплике >>18676 рецептом подключения субтитров, не достаточны для Ычана: мне следовало бы опубликовать также инструкцию по созданию GIF-файла из видеозаписи (потому что GIF, в отличие от WebM и MP4, принимают всѣ доски), и опубликую. Вот пакетный командный файл для Windows, создающий GIF из видеозаписи:

@echo off

ffmpeg -hide_banner -i %1 -ss %3 -to %4 -an -sn -c:v libvpx-vp9 -crf 22 -b:v 0 -vf "scale=-1:%2:flags=lanczos" ibsrc4gif.webm
ffmpeg -hide_banner -i ibsrc4gif.webm -vf palettegen ibpalette4gif.png
ffmpeg -hide_banner -i ibsrc4gif.webm -i ibpalette4gif.png -lavfi "paletteuse=dither=bayer:bayer_scale=0" ibgif.%2.gif
del ibpalette4gif.png
del ibsrc4gif.webm


Пояснение термина «пакетный файл» (если кто не знает его) можно прочесть по адресу https://ru.wikipedia.org/wiki/Пакетный_фай?? в Википедии.

Пользователям невиндовых операционных систем перед употреблением придётся внести в текст команд ряд обычных отличий (заменить «%1» на «$1» и проч.).

Примерно как и в случае с репликою >>18670, я предполагал вызов из командной строки в форме «имяПакетногоФайла имяВидеоФайла.mkv 550 14:03 14:05.75», где «14:03» и «14:05.75» — отметки времени (откуда и докуда вырезать фрагмент из видеофайла «имяВидеоФайла.mkv»), но на сей раз третий параметр («550» в данном примере) — это не абстрактный показатель качества, а желаемый размер GIF-файла в высоту, выраженный в пикселах.

Выбран именно показатель высоты, так как почти всѣ анимешники (и оттого очень многие посетители имиджборд) хорошо знакомы с характерными значениями высоты кадра (1440 для QHD, 1080 для FullHD, 720 для «простого» HD, 480 для VGA) и с их влиянием на детализацию кадров видео. Цифры ширины были бы не так удобны, поскольку менее успели навязнуть в уме и притом ситуация устного счёта осложняется там наличием различных размеров кадра — не только 16:9, но также ещё 4:3, 2:1 («16:8») и проч.

Примерно как и в случае с репликою >>18670, величина высоты удобно записывается в название итогового файла, что в дальнейшем позволяет на глаз подбирать величину в зависимости от желаемого объёма — то есть можно, например, сравнить по размеру файл «ibgif.640.gif» (высотою 640 пикселов) и «ibgif.642.gif» (высотою 642 пиксела) и прийти к выводу, что первый меньше полуторамегабайтового предела (сейчас на Ычане у досок /vn/ и /c/ и /au/ и /mi/ действующего), а второй больше его, так что можно запустить команду ещё раз с промежуточным значением высоты (641) и надеяться, что тогда точно будет видно, какой файл грузить на Ычан.

Отличие влияния высоты GIF на объём от влияния качества WebM (или MP4) на его объём заключается в том, что большее качество всегда приводит к росту объёма (так что подбирать качество под объём позволяет простая дихотомия), тогда как зависимость объёма GIF от его высоты не так проста, и некоторые значения высоты (не слишком кратные изначальной высоте кадра) могут создать более «смазанные» пикселы, кодирование которых в GIF приводит (за счёт меньшей повторяемости элементов кадра) к росту объёма файла (в частности, GIF высотою 641 пиксел в примере из предшествующего абзаца легко мог по объёму оказаться больше своих аналогов с соседними значениями высоты, причём не только больше 640-пиксельного, что логично, но и больше 642-пиксельного, что парадоксально на первый взгляд).

В приведённом мною примере отметки времени «14:03» и «14:05.75» разделяют считанные секунды. Как-то так будет и у вас, потому что видео в GIF занимает много больше мегабайтов, чем в WebM, и впихнуть десятки и сотни секунд в GIF не получится, если только не уменьшить высоту кадра до очень небольшого значения, сильно жертвуя детализацией. Совершенно по той же причине высоту кадров всегда приходится делать меньше исходной, а не то объёмы GIFов размера FullHD легко получаются в итоге многодесятимегабайтовыми.
No. 19333    
151967043574.png-(5.44KB, 480×480, FFmpeg default palette.png)
19333
В приведённом мною примере отметка времени «14:05.75» содержит указание доли секунды («.75», что означает «три четверти»). Как-то так может оказаться и у вас в тех случаях, когда на экране происходит циклический процесс и оттого у изготовителя GIF есть шанс сделать последний кадр GIF похожим на первый кадр (а точнее — на такой кадр, который идеально предшествовал бы первому), чтобы анимация плавно зациклилась. Иногда этого не так просто достигнуть, когда в кадре периодических процессов несколько (например, когда слёзы в глазу у плачущей персонажицы имеют один период колебаний, а под глазом — другой период, вдобавок не кратный первому, а длина отрывка меньше наименьшего общего кратного двух периодов), так что поневоле приходится подбирать не идеальный кадр, а первый попавшийся сколько-нибудь сносный, и такой далеко не всегда можно отыскать точно на границе двух соседних секунд.

Третьею из важнейших проблем качества GIF на имиджбордах (причём, возможно, даже превосходящею небольшой размер и небольшую длину анимации) является ограниченность цветовой палитры 256 цветами — приём, который позволил разработчикам формата в конце восьмидесятых годов полагаться на LZW-сжатие данных, но который через тридцать лет представляется идейно устаревшим. Последствия этой ограниченности неприятны: никак нельзя полагаться на то, что стандартная палитра встроенного в FFmpeg GIF-кодировщика (которую я прилагаю к этой реплике в качестве иллюстрации) окажется сколько-нибудь близкою к тем цветам, которые наиболее часто используются в конкретном кодируемом отрывке аниме (и которые поэтому следует использовать в GIF-кодировании для того, чтобы отрывок выглядел сколько-нибудь нормально и гладко, то есть чтобы мешанина точек промежуточных цветов — мешанина, имитирующая нужный цвет, не попавший в палитру — не делалась раздражающе явною от большой разницы между этими промежуточными цветами). Вместо стандартной палитры необходимо всякий раз использовать специальную палитру, автоматически созданную на основе конкретного видеоматериала.

Ввиду этого однократный запуск FFmpeg и создание видеозаписи за один проход (что в реплике >>18670 и >>18676 было достаточно) для GIF-файлов представляется неприемлемым по итоговому качеству, а предлагаемый пакетный файл запускает FFmpeg три раза кряду: первая команда, руководствуясь указанными отметками времени и высоты, вырезает из исходной видеозаписи желаемый отрывок и применяет https://ru.wikipedia.org/wiki/Фильтр_Ланцоша для уменьшения каждого кадра до указанной высоты, вторая команда запускает на этом полученном отрывке палитрогенератор, третья команда создаёт GIF на основе отрывка видео (полученного на первом шаге) и подобранной (на втором шаге) палитры.

Этот подход к делу основан, главным образом, на рецепте http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html 2015 года, который я незначительно улучшил, вынеся получение уменьшенного отрезка видео в отдельный шаг. В рецепте 2015 года предполагалось просто вписать эту операцию в команду вызова палитрогенератора и затем в команду вызова GIF-генератора, но так как проматывание видеофайла к нужной отметке времени — это долгий процесс (иногда несколько десятков секунд), то мне показалось нелепицею повторять его дважды, а затем я заметил также, что создание промежуточного WebM в среднем качестве (CRF 22) слегка компенсирует эффект контраста, привнесённый фильтром Ланцоша, и оттого уменьшает объём итогового файла GIF.
No. 19334    
Автор рецепта http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html сообщает также, что https://en.wikipedia.org/wiki/Ordered_dithering по алгоритму Байера не только устраняет проявления https://en.wikipedia.org/wiki/Colour_banding (появление монотонных цветовых полос на том месте, где в первоисточнике идут переливы цвета между оттенками, отсутствующими в палитре), но и уменьшает объём GIF (хотя в кадре появляется мешанина цветов, она не случайна, а с математическою строгостью выбирает в каждом месте наиболее подходящий из предопределённых узоров, имеющих согласно https://ffmpeg.org/ffmpeg-all.html#paletteuse равные размеры 8×8 пикселов и ввиду предсказуемости хорошо сжимаемых LZW-алгоритмом в GIF), тогда как принятый по умолчанию в GIF-генераторе у FFmpeg алгоритм «Sierra» устраняет узорчатость, но хуже передаёт разницу между оттенками цвета и притом (ввиду случайности и вызванного ею роста информационной избыточности) пагубно влияет на сжатие («it completely kills the compression of GIF»). Наглядно убедившись на опыте в том, что Sierra способна бесследно съесть небольшую разницу между цветовыми оттенками, когда те не настолько популярны в изображении, чтобы заслужить у палитрогенератора каждый по цвету в палитре (а именно таким цветом, например, в кадре у реплики >>19332 выкрашена левая дужка очков, которые носит Цубаса Курата: эту дужку мы видим только в небольшом углу его очков, на которые притом лёг блик от экрана, сквозь который дужка имеет вид, еле отличающийся по цвету), а также убедившись и в том, что байеровские узоры сжимаются лучше, я задал соответствующие параметры GIF-генератору: не только включил алгоритм Байера, но даже и снизил до нуля порог появления узорчатости (чтобы не засорять кадр искусственными границами между узорчатыми и неузорчатыми полосами, притом передвигающимися в ходе анимации, а покрыть вместо того весь кадр узорами 8×8 и дать зрению привыкнуть к наличию этих квадратиков).

Справедливости ради надо отметить, что рецепт http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html оканчивается серией наглядных примеров различного подхода к переводу иллюстрации в ограниченную цветовую палитру, но всѣ они отвратительно далеки от наглядности ввиду того, что первоначальное изображение само по себе содержит неестественные монотонные цветовые полосы (будучи, вероятно, кадром из недесятибитного аниме, павшим жертвою агрессивного видеосжатия).

Так как ограничение цветности является наиболее существенным и заметным ограничением GIF, то я не стал предусматривать в тексте команд никакого способа для экономии объёма файла за счёт дальнейшего уменьшения количества цветов в палитре: уродливые плоды такой экономии слишком заметны, так что уменьшение высоты кадра почти всегда следует предпочесть уменьшению палитры. Предложенный в рецепте http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html способ уменьшения объёма GIF путём искусственного снижения частоты кадров также показался мне дающим некрасивые результаты по отношению к аниме, так как частота кадров многих сцен в аниме и без того невелика, насколько это возможно, а тут они становятся и вовсе какими-то дёргаными.

Примерно как и в случае с репликою >>18676, получающуюся анимацию можно без труда снабдить субтитрами из файла-первоисточника, изменив всего одну команду простою допискою. В данном случае к «flags=lanczos» достаточно приписать «,subtitles=%~nx1» (непременно через запятую); для невиндовых систем аналогом «%~nx1» является, вероятно, опять же «$1». Всѣ оговорки из реплики >>18676 о том, что в таком случае исходный видеофайл не должен содержать спецсимволов в имени, справедливы и в этом случае (то есть много проще дать файлу простенькое имя наподобие «src.mkv», чем разбираться с тем, как у FFmpeg экранируется квадратная скобка или пробел в имени у источника субтитров).

Напоследок уместно подчеркнуть, и подчёркиваю, что указанный способ создания GIF универсален: он годится, разумеется, не для одних только тех досок Ычана, на которых WebM или MP4 не сделались ещё внедрёнными, но также и для других имиджборд в Интернете, лишённых поддержки WebM и MP4, но принимающих GIF и притом нередко ограничивающих размер GIF не таким строгим ограничением, каковы ычанские полтора мегабайта — следовательно, щедро допускающих более длительную анимацию или более крупный размер кадра в GIF.
No. 19377    
Пособие https://trac.ffmpeg.org/wiki/Encode/VP9 оказалось рекомендующим чрезмерно подробные параметры вызова FFmpeg.

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

Соответственно, параметры «-c:v libvpx-vp9» можно исключить (потому что они подразумеваются в FFmpeg) из моих рекомендаций, приведённых в репликах >>18670 и >>19332.
No. 19379    
Остался неохваченным вопрос о том, как создавать видео со звуком, и охвачу.

Проще всего это сделать на примере WebM, для которого FFmpeg (по аналогии с >>19377) автоматически употребляет кодировщик Opus, так что остаётся только выбрать битрейт — например, 256kbps — и вписать в аналогичную >>18670 командную строку:

ffmpeg -hide_banner -i %1 -ss %3 -to %4 -sn -crf %2 -b:v 0 -b:a 256k -tile-columns 2 -threads 8 ibvideo.%2.webm


Впечатывание субтитров в видеокадр достигается аналогичным >>18676 приёмом:

ffmpeg -hide_banner -i %1 -vf "subtitles=%~nx1" -ss %3 -to %4 -sn -crf %2 -b:v 0 -b:a 256k -tile-columns 2 -threads 8 ibvideo.%2.webm


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

Если искать наиболее наглядный пример такого идеала между имиджбордами околоычановского конгломерата, то с неизбежностью приходится торжествующе ткнуть пальцем прежде всего в Nowere.net (открывается как подраздел /tu/ верхней навигационной панели или по гиперссылке «туризм» из раздела «Общее» в левом фрейме на Ычане). Там поддерживается публикация видеозаписей в формате WebM, и не отвергается звук, и допускается размер файла до двадцати мегабайтов.
No. 19601    
Чуть больше трёх недель тому назад (19 марта) автор реплики https://iichan.hk/d/res/244600.html#245388 счёл возможным в обстоятельствах запрета на загрузку звуковых файлов (MP3, Opus) появление таких видеофайлов (MP4, WebM), у которых звуковая дорожка будет содержать желаемый звук (например, Opus в WebM), а видеодорожка будет состоять из повторений одного и того же видеокадра (в качестве примера он упомянул обложку альбома) — такие повторения очень хорошо сжимаются видеокодеком, так что такая видеозапись будет, в общем-то, немногим хуже (неэффективнее) первоначальной звукозаписи (конечно, если видео со звуком вообще разрешено публиковать на имиджборде, то есть если не запрещён звук в видео).

По адресу https://github.com/pituz/webm-thread/wiki/Pro-tips#Создание-видео-из-статичной-картинки-и-музыки можно видеть, что та же идея посещала в позапрошлом (2016) году разработчика, действовавшего на Гитхабе под псевдонимом «Питуз», который предложил для решения её такой рецепт, который может быть скорректирован под нынешние обстоятельства (восторжествование видеокодека VP9 и аудиокодека Opus) и избавлен от некоторых чрезмерных настроек (изменение длины GoP и высоты кадра), после чего принимает следующий вид:

ffmpeg -hide_banner -loop 1 -r 1 -i %1 -i %2 -ss %3 -to %4 -crf 7 -b:v 0 -b:a 256k -pix_fmt yuv420p -tile-columns 2 -threads 8 -shortest ibaudio.webm


Пользователям невиндовых операционных систем перед употреблением придётся внести в эту команду ряд обычных отличий (заменить «%1» на «$1» и проч.).

Предполагается, что команда для удобства лежит в пакетном файле и оттого вызывается в форме «имяПакетногоФайла имяКартинки.png имяЗвуковогоФайла.mp3 14:03 23:15», где «14:03» и «23:15» — отметки времени (то есть откуда и докуда надо вырезать звуковой фрагмент из файла «имяЗвуковогоФайла.mp3»).

Если же такие отметки не нужны (то есть если звук следует помещать в видеоролик весь целиком), то тогда и параметры «-ss %3 -to %4» не нужны в команде.

Параметр «-r 1» (снижение частоты кадров до одного кадра в секунду) очень важен, потому что более чем на порядок уменьшает количество кадров и тем преизрядно ускоряет кодирование.

Напоследок уместно упомянуть (и упоминаю), что содержимое файла https://github.com/pituz/webm-thread/blob/master/message.md как бы говорит нам о том, что сам Питуз не имел времени воспользоваться собственными наработками, так как к концу того же (2016) года вынужденно совершил, как он сам пишет, «покидание сосача», вынужденный к тому двумя обстоятельствами — во-первых, внедрением платного увеличения предельного размера публикуемых файлов (которое умаляло и обесценивало прежний интерес Питуза к достижению максимальной эффективности в рамках общего для всех прокрустового ложа), а во-вторых, конфликтом с администрацией, по каким-то своим соображениям стёршей некий «ОП-пост» (вероятно, текст начальной реплики обсуждения-видеосборника) и гиперссылки на рецепты Питуза по созданию видеороликов.
No. 19616    
Изложенные в рецепте >>19601 параметры «-pix_fmt yuv420p», по-видимому, полезны и во всех предшествующих рецептах, потому что без них FFmpeg может попытаться создать WebM с таким форматом пикселов, который в Firefox восприниматься не сможет (например, в десятибитном цвете) — или, может быть, сможет, но только в какой-нибудь новой последующей версии.

Кроме того, больше двух недель тому назад правка кода https://github.com/FFmpeg/FFmpeg/commit/0dc11d8bbd470db89fbc17b7434e992c9129b310 привела к появлению в FFmpeg поддержки кодека AV1, которому википедическая статья https://en.wikipedia.org/wiki/AV1 пророчит появление также внутри контейнеров WebM. Но до тех пор, пока это появление не состоится (или, вернее, не возымеет широкой поддержки в стабильных последних версиях браузеров), никаких готовых рецептов для командной строки вызова FFmpeg, порождающего видео AV1, я сочинять не стану.
No. 19788    
Всѣ послѣднія версіи FFmpeg (по меньшей мере, от версии 4.0 и до сборки 8 мая включительно) отчего-то начинают генерировать невыносимо большое количество байеровской узорчатости (и даже никак не объяснимой по Байеру хѣрни) в том режиме «bayer_scale=0», который я рекомендовал выше.

По-видимому, это какой-то баг FFmpeg, потому что до этого таких проблем не было.

Единственный известный мне способ избежать его — поставить «bayer_scale=1» вместо этого, но и этот способ не идеален (возникают те границы между узорчатыми и неузорчатыми полосами, которых при нуле не было).
No. 19790    
По поводу бага >>19788 два замечания.

Во-первых, он касается только анимированных GIFов, то есть замена значения «bayer_scale» (временная, для обхода бага в FFmpeg до того момента, когда разработчики исправят его) потребуется только в рецепте >>19332.

Во-вторых, по-видимому, баг в FFmpeg появился ввиду исправления ошибки https://trac.ffmpeg.org/ticket/4443 без последующего исправления ошибки https://trac.ffmpeg.org/ticket/6813 или другой аналогичной. Другой причины в багтрекере у FFmpeg я не мог найти.
No. 19791    
Отдельно подчёркиваю: тот обходной путь, который изложен в реплике >>19788 и уточнён в реплике >>19790, всего лишь маскирует главную проблему: в FFmpeg 4.0 сломан генератор GIFов.

(И маскирует не слишком умело. При «bayer_scale=1» не так много сверхзаметного мусора, но всё равно видно какое-то чрезмерное трепетание узора в кадре там, где его не должно быть.)

Поэтому моя рекомендация сводится не к тому, чтобы применять этот обходной путь (хотя я и изложил его), а к тому, чтобы вообще не использовать FFmpeg 4.0, а оставаться на предшествующей исправной версии — FFmpeg 3.4.2 (или, по крайней мере, пользоваться только ей для создания GIFов). До тех пор, пока четвёртый FFmpeg не исправят.
Удалить сообщение []
Пароль  
[Mod]