[WT] [Архив]  [Поиск] Главная Управление
[Совместно с Ычаном]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 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;
- плеер по нажатию в теле страницы, а не отдельным окном.

Перспектива расширения функционала ресурса при наличии готового решения достаточно высока.
Развернуть все изображения
No. 17663    
Достаточно для чего? Реализация из других мест не подходит или вообще не смотрелась?
No. 17664    
Насколько я понимаю, поддержку вебм по крайней мере в том виде, в котором она запрошена не получится сделать без модификации серверного кода. Вакаба имеет какую-то возможность расширения без редактирования основных исходников?
No. 17665    
>>17663
Каких «других мест»? Речь идёт о конкретном движке.
Уже есть какая-то реализация на базе Вакабы?
No. 17666    
151076863651.png-(208.56KB, 700×810, 7484114.png)
17666
Давайте, я переведу.
ОП хочет, чтобы вы взяли публично доступные исходники «Вакабы» и, поковыряв их, написали для них поддержку видео.
При наличии такой реализации, этот код потом могут позаимствовать на Ычан для введения поддержки видосов там. Да, речь именно про него.
Такая вероятность действительно существует.

Если кто-то где-то уже такое делал, тоже тащите сюда.
No. 17667    
>>17665
Есть, но исходники никто не даст.
>>17664
Тут что-то может быть, но я не смотрел.
No. 17669    
>>17662
> Вакабы (на примере Ычана)
Исходники модабы ведь закрыты и никому не выдаются.
No. 17670    
> наличие у видео тамбнейла в виде первого кадра, а не просто заглушка
convert input.webm[1] thumbnail.png

No. 17671    
> imagick в качестве внешней программы

Изрядная нелепость.

В качестве внешней программы для этой задачи гораздо лучше подходит ffmpeg.
No. 17672    
>>17669
Эта Ужасно Измененная Модаба, В Которой Нет и Следа Вакабы действительно интригует.
No. 17674    
151079628544.jpg-(100.88KB, 600×600, 1149375574592.jpg)
17674
>>17665
Людей, внезапно, на земле много, есть реализация почти всего на основе почти всего. https://github.com/ernstchan/phutaba , например, вполне-таки перепиленная вакаба, только ogv не поддерживает, плеер не встроенный и не отсеивает аудио. Или https://github.com/marlencrabapple/Glaukaba . Или даже https://github.com/lisanyan/wakaba ...хотя, мне кажется, там у них почти одинаковый код, поэтому достаточно было одной ссылки.
Отображение, я вполовину уверен, можно слизать с какого форчонга и всё будет хорошо. У меня до сих пор претензии к развороту картинок на Ычане: при сворачивании обратно вид за ними не утягивается к посту.

>>17666
>ОП хочет, чтобы вы взяли публично доступные исходники «Вакабы»
Дружественное напоминание всем желающим, что последняя версия Вакабы - 3.0.9, хоть и вышла она после создания Ычана. А Ваху надо подвесить за ноги и долго спрашивать, чому у него нет нормального чейнджлога. Вобще никакого чейнджлога.

>>17671
Вообще, я понимаю, отчасти: Вакаба - параноидальный движок, и проверяет даже картинки ручками перед тем как отправить их в комбайн imagemagick. Чем обезопасила Ычан от некоторых уязвимостей. Но не настолько параноидалный, чтобы ручками выковыривать картинку из первого кадра, при, сколько, десятке различных вариантов форматов видео в контейнере? По крайней мере мне ради "существующей вероятности" в совсем байтолюбство лезть неохото, ибо затянется это на месяц, наверное.
No. 17675    
> плеер по нажатию в теле страницы, а не отдельным окном

https://github.com/WagonOfDoubt/iichan-extensions/pull/1/files
No. 17677    
>>17674

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

Каким образом эту идею («ручками выковыривать картинку из первого кадра») можно было вычитать в реплике >>17671? Я уж не говорю о том, что решение проблемы «выковыривать картинку из первого кадра» в реплике >>17670 только что было дано.

Поясняю мысль: реплика >>17671 была о том, что попытка использовать ImageMagick для того, для чего ffmpeg подходит гораздо больше, рано или поздно наткнётся на труднопреодолимое препятствие.

Или без примера не понятно?

Вот пример: для добычи первого кадра можно попробовать «convert input.webm[1] thumbnail.png» вместо «ffmpeg -frames:v 1 -i input.webm thumbnail.png» (я, впрочем, не пробовал, но по адресу https://stackoverflow.com/a/5430762 это советуют). Однако задача №2 (запрет на загрузку файлов со звуком) ужé может вызвать проблемы, так как ImageMagick вряд ли содержит штучки-дрючки для обращения к звуковой дорожке: это графическая библиотека.
No. 17680    
Даже сраные япошки со своим ультраконсерватизмом сделали поддержу шебм.
На задачи нужно смотреть как на возможные алгоритмы, а не как на готовое решение, zdelot-khorosho.js, например. Нет такого понятия, как «реализация поддержки х на у», есть инструмент з, который может делать х и который можно заставить работать в связке с у.
No. 17681    
151080145214.png-(6.15KB, 384×384, 1154292169118.png)
17681
>>17677
>Каким образом эту идею («ручками выковыривать картинку из первого кадра») можно было вычитать в реплике >>17671?
Эта идея из ОП-поста, в котором из сторонних программ указан только ImageMagick, который не может напрямую открывать видео, и использует для этого сторонние программы (http://www.imagemagick.org/Usage/formats/ ). Собственно, по ссылке на stackoverflow говорят ровно об этом же, а именно об ffmpeg. И я считаю, что установка на сервер ещё одного мультемедийного комбайна - достаточно большое отступление от ТЗ ОП-поста.

А дальше в тексте я наоборот соглашаюсь с >>17671.
No. 17682    
151080484465.png-(53.34KB, 531×531, 1265065408995.png)
17682
А ежели всё-таки можно ставить свои комбайны, то я бы добавил сверху Image::ExifTool, и тогда список поддерживаемых форматов ограничивается только самим exiftool.

Ежели это всё дозволительно, то я хоть сегодня (завтра) могу выкатить рабочую версию, с готовым >>17675 тем более что.
No. 17683    
>>17682
В принципе, допустимо всё, что есть в репозиториях Debian Strech и CPAN.
No. 17684    
>>17682
Please do.
No. 17686    
>>17675
Раз все равно будут сайт ковырять, шепните мод-тян чтоб обновила
iichan-expand-images.min.escaped.js

iichan-hide-threads.min.escaped.js

Улучшено юзабилити раскрытия картинок плюс косметические правки кода с учетом пожеланий из прошлых тредов.
No. 17687    
>>17662

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

> плеер по нажатию в теле страницы, а не отдельным окном.

Напрашиваются уточняющие вопросы, и задам:

1) Должен ли видеопроигрыватель автозапускать воспроизведение видеозаписи?

2) Должно ли воспроизведение видеозаписи быть зацикленным (переходить к началу при достижении конца видеоролика)?

3) Точно ли необходим запрет на загрузку файлов со звуком? Может быть, достаточно одного того, чтобы видеопроигрыватель был с приглушённым (до нулевой громкости) звуком?

4) Должен ли видеопроигрыватель иметь пользовательский интерфейс для управления воспроизведением, в том числе перемоткою, паузою и продолжением воспроизведения?

3+4) Точно ли необходим запрет на загрузку файлов со звуком? Может быть, достаточно одного того, чтобы видеопроигрыватель изначально был с приглушённым (до нулевой громкости) звуком, но пользовательский интерфейс его содержал включатель звука?
No. 17688    
>>17686
А прoгесс загрузки появился наконец? А то тычешь тычешь и непонятно, разворачивается или нет.
No. 17689    
Зачем оно нужно без звука?
No. 17691    
>>17688
Да, теперь оно сразу разворачивается в нужный размер.
Можно сразу начать этим пользоваться, если заблокировать адблоком существующий скрипт, добавив правило
iichan.hk/extras/*
, и установить раскрывалку как юзерскрипт отсюда: https://github.com/WagonOfDoubt/iichan-extensions/raw/master/dist/userscript/iichan-expand-images.user.js
No. 17692    
>>17687
Думаю, кастомный ГУЙ к видеоплееру не нужен, браузеры и так нормально с этим справляются. Без звука можно смотреть только порноролики, как на Форчане, и то не все. Приглушение тоже не нужно, как никак все умеют пользоваться ползунком громкости.
No. 17693    
>>17689

> Зачем оно нужно без звука?

Когда эту идею впервые реализовывал 4chan (о чём примерно 7 апреля 2014 года¹ упоминает по адресу http://blog.4chan.org/post/81896300203/webm-support-on-4chan блогозапись «WebM support on 4chan»), то о WebM помышляли, главным образом, как о замене анимированных GIFов, лишённой недостатков анимированных GIFов, то есть допускающей употребление больше 256 цветов и применение более эффективных алгоритмов сжатия (так что можно надеяться на естественную цветность и на изрядную частоту кадров при сохранении разумного качества и притом при непревышении разумного объёма, каковым в том году сочли объём трёхмегабайтовый). И так как в анимированных GIFах никакого звука не было, то на 4chan и в WebM также решили никакого звука не допускать.

Инерция сознания столь велика, что беззвучными сделались видеозаписи не только на некоторых других таких имиджбордах, которые собезьянничали с Форчана, но также и на таких «не вполне имиджбордах», каков, например, imgur.

Надо сказать, что imgur не только оперативно последовал примеру Форчана в октябре того же (2014) года по адресу https://blog.imgur.com/2014/10/09/introducing-gifv/ во блогозаписи «Introducing GIFV», но и изобрёл для видеозамены анимированных GIFов собственное название (GIFV), а также выбрал для себя противоположный подход к делу: не пользователям позволил загружать видеозаписи в формате WebM на сервер, а на сервере перекодировал загружаемые анимированные GIF в два различных формата (WebM и MP4) и скармливал их пользователю в зависимости от поддержки того или другого во браузере.

Примерно к тому же подходу (видео на основе GIF) склонился по адресу https://telegram.org/blog/gif-revolution 4 января прошлого (2016) года и Telegram.

Недостаток очевиден: и цветность, и вообще визуальное качество таких видеороликов ужасно (потому что в основе их — анимированный GIF).

Почему же тогда такой подход казался разумным?

Дело в том, что тогда (в 2014 году) некоторые операционные системы не поддерживали просмотр WebM (например, macOS, для которой с тех пор появились кодеки, по умолчанию, впрочем, не установленные — или, например, iOS, в которой до сих пор нѣтъ никакой надежды на просмотр WebM ни на айподах, ни на айфонах, ни на айпэдах), а некоторые браузеры не поддерживали просмотр MP4 (например, Firefox, для которого с тех пор в Cisco соорудили кодек http://www.openh264.org/ небывалой лицензионной и патентной чистоты — или, например, браузеры на движке Chromium, который служит основою Google Chrome, но отличается от него открытостью кода и полным отсутствием поддержки патентно-нечистых форматов).

А насколько разумным такой подход кажется сейчас?

Сейчас проблемы в macOS и в Firefox решены, а в iOS и в Chromium остались: до сих пор нельзя посмотреть WebM на iOS или MP4 в Chromium. Вероятно, можно забить на Chromium (в силу малораспространённости) и фигачить MP4.

Со звуком также есть досадная проблема запатентованности форматов, но я не смею долее испытывать терпение читателей /dev/ и предлагаю желающим ознакомиться с четырьмя краткими репликами по адресу https://twitter.com/FidonetRunes/status/929111203355521024 и https://twitter.com/FidonetRunes/status/929111348939804672 и https://twitter.com/FidonetRunes/status/929111538501341186 и https://twitter.com/FidonetRunes/status/929113346279985157 в свободное время, если у кого отыщется оно. Практическое же следствие этой проблемы заключается в том, что Chromium звук AAC не воспроизводит вообще никогда, а Firefox — только в видео MP4 и только при наличии кодеков в операционной системе, как это по адресу https://caniuse.com/#search=aac утверждают.

______________

¹ Точная дата в той блогозаписи не указана (пишут просто «3 года назад»), но о дате нетрудно догадываться, так как «The Washington Post» по адресу http://wapo.st/1qgDoYl в статье «Meet the technology that could make GIFs obsolete» упоминает о новинке как о появившейся в понедельник, а статья эта датируется восьмым апреля 2014 года.
No. 17694    
>>17692

> Думаю, кастомный ГУЙ к видеоплееру не нужен, браузеры и так нормально с этим справляются.

Поясняю: я спрашивал не о том, нужен ли кастомный GUI, а о том только, нужен ли браузерный (иными словами, нужен ли атрибут «controls» в теге «video»).
No. 17695    
151085025568.jpg-(60.52KB, 1280×720, maxresdefault.jpg)
17695
>>17693
> например, iOS, в которой до сих пор нѣтъ никакой надежды на просмотр WebM ни на айподах, ни на айфонах, ни на айпэдах
Это просто пипец. Зачем они живут вообще?
No. 17696    
В общем, я тут подумал и по адресу https://github.com/WagonOfDoubt/iichan-extensions/pull/3/files ещё полдесятка атрибутов прибавил к видеопроигрывателю:

1) Автозапуск, чтобы после тычка по предпросмотру не требовалось ещё и с видеопроигрывателем возёхаться для запуска видео.

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

3) Закольцовывание, чтобы после окончания видео просмотр автоматически начинался заново.

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

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

Этот последний пункт представляет собою отход от вышеупомянутой позиции фанатов беззвучных анимированных GIF, но одновременно он позволяет на серверной стороне экономить и усилия программиста (не возёхаться с созданием механизма проверки для запрета на загрузку файлов со звуком), и усилия (да и время) сервера (не запускать механизм проверки для запрета на загрузку файлов со звуком), однако всё же достигнуть желаемого (то есть избежать немедленного воспроизведения каких-нибудь скримеров или NSFW-звуков без прямого предварительного вмешательства читателя сайта, вручную включающего звук себе).
No. 17698    
151085654446.mp3-(5.98MB, 2-16 Moment of Decision.mp3)
17698
  Теоретически можно было бы, между прочим, вообще не возёхаться с изобретением клиентского джаваскрипта, создающего видеопроигрыватель, а прямо на сервере вместо миниатюры с самого начала на страницу класть видеопроигрыватель, просто-напросто стоящий на паузе без автозапуска и использующий графический файл миниатюры (в котором первый кадр) в качестве своего постера (отображаемого мгновенно, то есть ещё до момента нажатия на кнопку «Пуск», до начала какого-либо скачивания видеозаписи).

Но это теоретически. На практике, если на 500 реплик будет приходиться пара-тройка-другая десятков видеопроигрывателей, то браузер на слабом устройстве (например, на старом компе или на недорогом мобильнике) может ведь и тормознуть изрядно.

Ещё сразу скажу, что кроме видеопрогрывателей (на основе тега «video») не помешали бы на имиджбордах и звукопроигрыватели (на основе тега «audio»). А не то даже и стыдно: более десяти лет прошло¹ со дня первых звукопроигрывателей в Интернете, и даже можно файлы MP3 и OGG загружать кое-где (вот здесь², например), но звукопроигрывателей, как назло, нету.

________________

¹ Точная дата появления в Интернете первого звукопроигрывателя мне не известна, однако появление первого видеопроигрывателя относится блогозаписью http://www.wiumlie.no/2007/video/ к 28 февраля 2007 года, а звукопроигрыватели шли в HTML5 рука об руку с видеопроигрывателями, так что и они где-то в это же время были реализованы.

² В качестве примера к моей реплике присоединена звукозапись «Moment of Decision» из альбома «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. 17699    
Контролсы нужно, пусть будут стандартные.
No. 17700    
410чан использует флэшёвый звукопроигрыватель из числа тех, происхождение которых восходит к ещё более седой древности Интернета, чем упомянутый выше десяток лет — но увы! флэшёвка в современных Файерфоксах имеет обыкновение обрушиваться (лично у меня этот звукопроигрыватель нормально заработал только с пятого раза).

Кроме того, этому звукопроигрывателю (по сравнению с типичным результатом работы HTML5 audio) сильно недостаёт полосы прокрутки звукозаписи.
No. 17703    
>>17680
>Даже сраные япошки со своим ультраконсерватизмом сделали поддержу шебм.
И на форчке тоже есть. Но тоже без звука. А что тут такого, если .gif и так поддерживался?
No. 17706    
>>17689
Думаю, для экономии места на сервере и трафика. Часто шебмки делают люди не шибко технически продвинутые и засовывают звук с очень большим битрейтом, недоумевая, отчего их минутный ролик в 360 на 480 пикселей весит больше двадцати мегабайт. Только для этого не нужно детектить звук. Достаточно в два (если не в один) флага ффмпега сделать выпиливание звуковой дороги. Это проще для реализации, сервера и пользователей.

>>17703
На Форчке есть /gif/ и /wsg/. В связи с чем реквестирую расширения /hr/ до полноценной файлопомойки.
Но не об этом. Имелось в виду, что даже они осилили ффмпег и прикрутили его к Футабе.
No. 17707    
>>17706
Для экономии места ограничение веса файла до 10 Мб. Юзер сам разберется, что там пережать. А вот загружать музыкальный клип со статичной картинкой, чтобы он оказался без звука довольно глупо.
No. 17708    
>>17707
Нехрен борду как плеер использовать, Ютуб и прочее есть.
No. 17709    
>>17708
Так и для картинок есть imgur.
No. 17710    
>>17709
А для текстов Пастбин.
Моття, сделай!
No. 17711    
>>17708
Вот зайдем в любой нормальный webm-тред. Какой контекст имеет например это https://krautchan.net/download/1510837594002.webm/1505676909001.webm видео со звуком и без.
No. 17714    
151089393535.png-(169.25KB, 456×628, nijiura_maid_yakui_by_naupathique-d2zhx16.png)
17714
http://yakuji.moe/wakaba/diffs.zip - диффы.
Собственно, wakaba.html в той же папке - работающая Вакаба 3.0.9 на свежайшем Debian Sid.
Весь жс взят от Мицгола/вагона сомнений. Для работы требует установленных ffmpeg и libimage-exiftool-perl помимо всего прочего, что требуется для работы Вакабы.

Собственно, как я озвучил на месте, проблем с нынешней реализацией три:
1. Нет сворачивания плеера обратно в картинку.
2. У меня едут миниатюры, но это проблемы моего юзерстиля, так что это не проблема.
3. Я не тестировал это на чём-то кроме webm, отчего могут быть сюрпризы.
4. Я хочу спать.
No. 17716    
>>17714
> Нет сворачивания плеера обратно в картинку.
Это должно быть. И Дебиан нужен стабильный, если мы об Ычане говорим.
No. 17717    
>>17716
>И Дебиан нужен стабильный, если мы об Ычане говорим.
Я не буду даунгрейдить свой сервер, но что ffmpeg, что libimage-exiftool-perl в Stretch есть, я гарантирую это. Даже в Wheezy. В последнем только самого webm может не быть.
No. 17718    
>>17717
Вопрос в том, работают ли эти версии аналогично более новым из тестинга.
Ну, и виртуалку никто не отменял.
No. 17719    
>>17718
>Вопрос в том, работают ли эти версии аналогично более новым из тестинга.
Перловская либа выпадает из вопроса, так как она в крайнем случае берётся из CPAN, что разрешено >>17683. Стречевскому ffmpeg меньше года и на оффсайтеничего про глобальные изменения с того периода нет.
>Ну, и виртуалку никто не отменял.
Ну и флаг вам в руки, если мне веры нет. А я вернусь часов через 16-20.
No. 17725    
>>17714

> Нет сворачивания плеера обратно в картинку.

>>17716

> Это должно быть.

Ну хорошо.

https://github.com/WagonOfDoubt/iichan-extensions/pull/4/files
No. 17734    
>>17671
>>17674
Передача видеофайла в ffmpeg, ImageMagick или любой другой "комбайн" с поддержкой десятков форматов файлов и кодеков практически равнозначна разрешению кому угодно выполнять произвольный код с теми же правами, с которыми будет запускаться этот "комбайн". Поэтому важно откомпилировать ffmpeg с поддержкой только WebM, MP4 и OGV и обеспечить его запуск с минимальными правами в "песочнице" SELinux/Apparmor или в виртуальной машине либо на отдельном сервере.
No. 17736    
>>17734

Перекомпилировать-то нафига?

Насколько я помню, в прошлом году уязвимость https://imagetragick.com/ отключалась просто-напросто таким изменением конфигурации в файле «policy.xml», которое отключало уязвимые «кодеры».
No. 17739    
151097023265.png-(8.61KB, 384×384, 1151937463710.png)
17739
>>17725
>insertAfter
Нет такого в дефолтном ЖС.

Поправил кое-как у себя локально. Заодно проверил другие форматы и тестово разрешил звук.

Писать версию с удалением звуковой дорожки ннадо кому, или мы уже закончили с этими вероятностными играми?
No. 17741    
>>17739

Благодарю за замечание, по адресу https://github.com/WagonOfDoubt/iichan-extensions/pull/6/files скинул поправку.
No. 17743    
15110154511.jpg-(60.79KB, 500×500, 1160910058211.jpg)
17743
>>17741
Ах да, забыл добавить: dataset хранит информацию в DOMString. Поэтому условие в строке 16 всегда истинно после первого открытия видео, а строка 19 не работает вообще. JSON.stringify с последующим JSON.parse не решает вторую проблему, ибо removeChild оперирует на DOMNode, а JSON возвращает Node.
Первое я решил проверкой на undefined с последующим
delete e.currentTarget.dataset.videoMode;
, второе через позиционирование:
parentNode.removeChild(e.currentTarget.previousSibling);
. Но может у вас есть идеи получше. Скажем, генерировать id видеоплееру через a.name, и удалять по getElementByID.

Да, я есть на гитхабе, но бегаю от sparky4, и слишком мало знаю ЖС, чтобы разбираться в правильности и красивости своих решений.
No. 17759    
Файл
удалён
>>17743

Подумавши над таким поведением «dataset», я решил внести изменения https://github.com/WagonOfDoubt/iichan-extensions/pull/7/files в свой код, то есть не только перейти к хранению текстовых строк, но и хранить их в «левых» атрибутах объектов DOM, а не в «dataset», так как MDN по адресу https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset сообщает о том, что «dataset» не поддерживается в Internet Explorer ранее версии IE11 (тогда как тег «video» согласно https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video поддерживается от версии IE9).

Приходится признать, что на меня дурно повлиял пример WagonOfDoubt с появлением использования «dataset» в изменениях, внесённых коммитом https://github.com/WagonOfDoubt/iichan-extensions/commit/b067eb068f560275bac848100e7c39b600b24ab6 в исходный код развёртывания иллюстраций на Ычане. Я некритически решил, что если там так делается, то и ладно; а отнюдь не ладно то было.
No. 17762    
151104038024.png-(177.65KB, 1828×943, Фридкин.png)
17762
>>17714

Смотрел http://yakuji.moe/wakaba/diffs.zip

Много думал.

Вид файла wakaba3.diff начиная от строки 31 создаёт уверенность в том, что там используется код, соответствующий стандарту ECMAScript 2015 и оттого нифигушеньки не поддерживаемый в более ранних браузерах.

Возможно, есть смысл наперёд собрать его тем способом, который WagonOfDoubt упомянул по адресу https://github.com/WagonOfDoubt/iichan-extensions#Сборка-для-продвинутых-бак (или, иными словами, в последнем из разделов в readme.md).

Этот способ потребует (в качестве сборочных инструментов) Node.js и Gulp и ещё четырнадцать штук тех модулей, которые командою npm install будут установлены (они по адресу https://github.com/WagonOfDoubt/iichan-extensions/blob/d854d58843a3d5c3b69a20e06bb1f5188779451d/package.json#L24-L39 перечислены), но в итоге должен получиться (в подкаталоге «dist») исходный код, пропущенный через Babel для перевода на более раннюю версию JavaScript.
No. 17769    
151105717419.png-(8.66KB, 384×384, 1151937730491.png)
17769
>>17762
Благодарю за инструкцию. Собрал, оставил только нужный функционал, переархивировал. Взял iichan-video-player.min.escaped.js , ибо на самом Ычане, похоже, также использован min.js, а не es5. Но всегда можно поправить ещё раз.

diff'ы такие большие, ибо я подозреваю, что состояние Вакабы Ычана достаточно отличается от ванильной, чтобы разумнее было ориентироваться по именам функций и всем близлежащим строкам, чем по номеру строки или только имени функции.
No. 17771    
Нужна реализация, аналогичная тому, как это сделано на Форчане, где файлы со звуком просто не допускаются. Никаких игр с ползунком громкости\редактированием файла не нужно.
No. 17773    
>>17769
На Ычане не использован es5.js так как хоть babel может заставить заработать js-код на более старых браузерах, с css-свойствами он такого сделать не может, а на css завязан основной функционал этих скриптов. Таким образом, более вероятна ситуация, когда код работает как надо, а css не работает вообще, либо работает неправильно, в результате имеем поломавшийся функционал. С esNext же получается graceful degradation, когда код, обернутый в try...catch тихо падает, а пользователь видит ванильную Вакабу образца 2007 года и ничего не замечает. Впрочем, как знаете. Все версии есть в наличии.
Еще по поводу video-player.js:
margin: 2px 20px;

Точно ли тут должен быть margin, а не padding?
No. 17774    
>>17771
Звук нужен. .webm не только замена анимированному .gif, который и так можно постить, но и замена уже не поддерживающемся нигде флешу, который в свою очередь в свое время и воспринимался как "гифки со звуком".
No. 17777    
>>17774
Я ещё раз повторяю, в рамках описанной в ОП-посте реализации звук в .webm не нужен. Варианты со звуком на Ычан ставить никто не будет.
No. 17778    
151110708358.jpg-(24.17KB, 228×368, 106402_p0.jpg)
17778
>>17777>>17774
Специально для вас написана версия, где допускание звука настраивается константой в конфиге, и в диффе версия "не допускать звук".
>Варианты со звуком на Ычан ставить никто не будет.
[citation needed]. Я-то в треде вижу кучу анонимов и одного Соус-куна, что хоть какую-то гарантию может дать (да, есть ещё Мицгол, но это иррелевантно к теме обсуждения). И он про звук ничего не сказал. Как и про другие требования ОП-поста.
А то про вебм вообще я помню, что не будет, но про конкретно звук нет.
No. 17779    
>>17773
>Точно ли тут должен быть margin, а не padding?
Я не знаю, ололо, я просто скопипастил Мицголовский код. На глаз разницы не вижу.
>Все версии есть в наличии.
И ВагонСомнений на момент написания принял патч, так что они есть даже на гитхабе. Вот и славно.
No. 17782    
151110868496.png-(1.30MB, 1700×884, Voldemort circle.png)
17782
Пока что я увѣренъ, что margin.

(Если у кого-нибудь есть аргументы в пользу padding, то я готов их послушать.)

Аргумент >>17773 о неправильной работе CSS представляется мне по отношению к моему исходному коду видеопроигрывателя преувеличенным и неверным. Рассмотрим использованные мною правила CSS по одному:

правило «max-width: 100%» согласно https://developer.mozilla.org/en-US/docs/Web/CSS/max-width#Browser_Compatibility работает, начиная от Chrome 1, Firefox 1, Opera 4, IE7, Safari 2.0.2, во всѣхъ Edge,

правило «height: auto» согласно https://developer.mozilla.org/en-US/docs/Web/CSS/height#Browser_compatibility работает, начиная от Chrome 1, Firefox 1, Opera 7, IE4, Safari 1, во всѣхъ Edge,

правило «margin: 2px 20px» согласно https://developer.mozilla.org/en-US/docs/Web/CSS/margin#Browser_compatibility работает, начиная от Chrome 1, Firefox 1, Opera 3.5, IE3, Safari 1, во всѣхъ Edge,

правило «box-sizing: border-box» согласно https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing#Browser_compatibility работает, начиная от Chrome 10, Firefox 29, Opera 7, IE8, Safari 5.1, во всѣхъ Edge —

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

Страница https://caniuse.com/#search=box-sizing называет это большинство равным 97½% в мире и 83½% в России.

К тому же, если уж у кого-то до сих пор IE7, например, то у него (в силу дырявости браузера) много больше проблем, чем отсутствие видео на Ычане, так что вряд ли есть смысл от этого человека дополнительно ограждаться — в особенности если речь идёт об ограждении употреблением ECMAScript 2015.

Ведь это же недавняя штука — ECMAScript 2015.

Возьмём, например, такую функцию ECMAScript 2015, какою являются стрелочные функции. По адресу https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions#Browser_compatibility нетрудно видеть, что она вообще не поддерживается в Internet Explorer, а также требует Chrome 45, Firefox 22, Opera 32 и Safari 10 или Edge.

Сравним это с поддержкою тега «video» — и мы увидим, что по адресу https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video#Browser_compatibility имеющею её названы браузеры Chrome 3, Firefox 3.5, Opera 10.5, IE9, Safari 3.1 и всѣ Edge.

Я понимаю, что Internet Explorer можно не любить; я и сам не очень-то к нему расположен.

Но так-то уж зачем.
No. 17784    
151110996230.png-(50.86KB, 267×266, 15029304_p0.png)
17784
>>17782
Я думаю, >>17773-кун говорит больше об уже поставленных на Ычане скрытии треда и раскрытии картинок.

http://yakuji.moe/wakaba/diffs_es5.zip - версия с es5. На сервере на данный момент тоже она.
No. 17787    
151111028436.jpg-(156.35KB, 857×603, Trolli.jpg)
17787
Хочу подчеркнуть, и̲ ̲п̲о̲д̲ч̲ё̲р̲к̲и̲в̲а̲ю̲, что WagonOfDoubt своим коммитом https://github.com/WagonOfDoubt/iichan-extensions/commit/de5b64605a5fbe8ace94f51384ce887d04dc4e7d напилил генерирование минифицированных версий на языке ES5, вот как https://github.com/WagonOfDoubt/iichan-extensions/blob/5ad9cee75f557037bdf947f7f87de43a4f1eebb1/dist/es5/minified/iichan-video-player.es5.min.js например.

Именно их рекомендую употреблять на Ычане.
No. 17791    
151111158636.jpg-(64.97KB, 458×536, 331486_p0.jpg)
17791
>>17787
¯\_(ツ)_/¯

Обновил архив, взял iichan-video-player.es5.min.escaped.js просто потому что могу.
No. 17792    
>>17782
Самое криминальное правило там это pointer-events в hide-threads.js, которое поддерживается в IE11 и выше. https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events
В принципе, ничего особенного в этом нет. Не поддерживаемое правило приведет к тому, что треды будут раскрываться по наведению на всю заглушку, а не только на ссылку с номером. Так что действительно, пусть будет es5.
No. 17793    
151111218950.png-(229.28KB, 1000×1000, b756bd652d1a.png)
17793
>>17778
Что вам от меня надо? Я, вроде, ясно написал, что ОП легитимен, хоть и криво изъясняется.
Да, по умолчанию требуется без звука. Если в конфиге есть опция для звука, то пусть будет, я не знаю.

Алсо, просили передать, что неизвестно, когда это будут прикручивать. Но сама возможность прикручивания одобрена.
No. 17794    
15111139257.png-(1.37MB, 1280×720, Chaos;Head.png)
17794
Очень хорошо.
No. 17795    
151111421822.jpg-(39.11KB, 500×459, 92933_p0.jpg)
17795
>Я, вроде, ясно написал, что ОП легитимен
"Давайте, я переведу. ОП хочет" и "Такая вероятность действительно существует" не легитимность, а жест доброй воли и совпадение в моём словаре. Или криво изъясняется не только он, или криво устроен я, что тоже бывает.

>Алсо, просили передать, что неизвестно, когда это будут прикручивать. Но сама возможность прикручивания одобрена.
Вот и славно. Ждать, как всегда, осталось недолго.
No. 17796    
151111439227.png-(11.44KB, 754×88, iiwebm.png)
17796
Я даже не буду говорить, кто тут продажный женщин.
No. 17797    
151111468240.png-(118.56KB, 329×278, 1462008290860.png)
17797
>>17796
>2015
>в ближайшей перспективе
No. 17799    
151111498258.png-(14.57KB, 306×159, poetry.png)
17799
>>17797

Вот точно. 2¼ года прошло, какая уж тут «ближайшая перспектива».
No. 17800    
151111501591.png-(276.18KB, 586×634, 1460487745156.png)
17800
>>17797
>пять лет прикручивали прозрачность превьюхам
No. 17801    
>>17800
Её когда решили прикрутить, прикрутили очень быстро.
Это вот видео решили прикрутить только сейчас, и прикрутят неизвестно когда.
No. 17802    
>>17801
Тут должна быть цитата из нубтайпового интервью Мт про дальнейшее развитие Иичана, за которую там пару лет назад банили почему-то.
No. 17803    
>>17802
В интервью хотелки были абстрактные (вспомнить хоть торренты и музыку, которую из-за копирайтоты никто бы в здравом уме прикручивать и не стал). И в то время вообще мало что осмысленное делалось по любым направлениям.
А когда прозрачность всё-таки действительно решили приделать, её приделали быстро. Каталог, вроде, тоже.
No. 17805    
151111926785.png-(0.96MB, 1280×720, Log Horizon - Shiroe with a contract.png)
17805
>>17802

Правильно ли я понимаю, что рѣчь идётъ объ интервью въ номерѣ http://ichan.ru/NT11.pdf и о слѣдующихъ въ нёмъ словахъ:

> Вот те из видимых посетителям изменений, которые мне хотелось бы добавить в первую очередь: поддержка .torrent файлов в /t/, .pdf в /sci/, возможно, сейвов в /to/, музыкальных форматов в /mu/, .flv и роликов с Youtube в /gf/ (?), канакапча, EXIF’ы в /ph/, LaTeX в /sci/, анимация в /o/, исправление ошибок в CSS и в обработке «^ H» в Wakabamark’е, список досок во фрейме, который можно сворачивать, новая титульная страница.
No. 17806    
>>17803
Ну, там были и вполне ясные и чёткие цели.
В любом случае, понятия о времени и временных рамках с Иичаном слабо коррелируют.

>>17805
Да.
No. 17808    
151112098792.png-(812.74KB, 1280×720, Fate Stay Night - 20.png)
17808
По причинам, в обсуждении >>/d/958 изложенным, предвижу много более частое употребление MP4, нежели WebM.
No. 17817    
15111634563.png-(1.06MB, 1064×1283, Screenshot-2017-11-20 Бред.png)
17817
>>17782
> (Если у кого-нибудь есть аргументы в пользу padding, то я готов их послушать.)
No. 17820    
>>17796
Как будто Мод-тян - не переходящая должность, и нынешняя несёт ответственность за слова прошлой.
No. 17822    
151117821373.png-(441.55KB, 728×409, Screenshot-2017-11-20 Rick and Morty S03E10 The Ri.png)
17822
>>17820
Они как раки-отшельники.
No. 17825    
151118046615.jpg-(89.49KB, 500×572, Волгоград.jpg)
17825
>>17820

Если не совершают широкого объявления «Моконы и Сырны! С вчерашнего дня я правлю над вами — другая Мод-тня!», то тогда, значитца, последующая Мод-тяночка желает возыметь репутацию предыдущей и как бы играть впредь роль её.

Но ведь и воспоминания о прежних декларациях намерений — часть той репутации. Иначе и быть не может.
No. 17826    
151118136011.png-(2.80MB, 1920×1040, Mononoke Hime.png)
17826
>>17817

По адресу https://github.com/WagonOfDoubt/iichan-extensions/commit/37e5e52040d80b18fc012c800c18693cd4e57c5c видно, что WagonOfDoubt напилил padding куда надо, а также придал поля гиперссылке, свёртывающей видеопроигрыватель.
No. 17828    
151118173979.jpg-(198.05KB, 675×675, собаченьки.jpg)
17828
Что же касается меня, то после пристального вглядывания в >>17817 я принимаю мнение о том, что именно padding там надо.

До этого у меня были определённые иллюзии (которые я уж не стану тут пересказывать) о том, как работают поля (и вообще box model) у видеопроигрывателей.
No. 17829    
>>17826
Там, кстате, надо ещё width:auto, чтоб не було ак в >>17744.
No. 17830    
>>17829
По адресу https://github.com/WagonOfDoubt/iichan-extensions/raw/master/dist/userscript/iichan-video-player.user.js можно установить юзерскрипт, и тестировать его на nowere.net, так как там тоже wakaba и есть поддержка .webm
No. 17832    
15111948469.png-(130.46KB, 477×666, I-am-a-hacker.png)
17832
>>17829

Пристальное вглядывание в то обсуждение, которое за репликою >>17744 последовало, приводит меня к убеждённости в том, что всѣ проблемы вызывались изначальным указанием другой ширины (не «auto») в стилях для класса «.thumb» в Кусабе — или, во всяком случае, именно вмешательством в стили, для этого класса указанные, проблема была успешно устранена.

Именно в силу такой убеждённости я могу небезосновательно надеяться на то, что уж моего-то видеопроигрывателя это обстоятельство нисколько не коснётся — прежде всего потому, что вызов в строке https://github.com/WagonOfDoubt/iichan-extensions/blob/aaa2c661e548323e7b0e56bac4105d1dbcff91f3/src/video-player/video-player.main.js#L36 располагает видеопроигрыватель вне того элемента, который помечен классом «.thumb» (и даже вне окаймляющей этот элемент гиперссылки).

Разумеется, если у кого-нибудь есть контраргументы, способные всерьёз поколебать эту убеждённость и порождённую ею надежду, то прошу высказываться; но до тѣхъ поръ — — —
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]