Ычан: [d | au / b / bro / hr / l / m / mu / o / s / tran / tu / tv / vg / x | a / aa / c / fi / jp / rm / tan / to / vn]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Первые 100 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 20450)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, WEBP, XCF, ZIP размером до 5000 кБ.
  • Ныне 3632 unique user posts. Посмотреть каталог
  • Предельное количество бампов нити: 500
410.png - (34.48KB, 500×500)
20450
No. 20450  
После публикации исходников мы можем обсуждать доработку не только ранее общедоступных частей интерфейса, но и движка в целом.

Репозиторий: https://bitbucket.org/Therapont/fbe-410
1. Для ваших предложений предназначена ветка public.
2. Только администрация 410чана решает, что в этом движке надо, а что не надо. Соответственно, не стоит излишне пропихивать всякие там революционные идеи. Одобренные потенциальные изменения перечислены на багтрекере (записи, созданные владельцами репозитория).
3. Тестирование предложенных изменений и развёртывание принятых ведётся при наличии у администрации свободного времени на это. Обычно это делается по выходным.
4. Код выложен как есть. Никаких неопубликованных скрытых функций и частей не существует.

Предыдущая нить: >>17371
No. 20452  
Pull request - Access denied.png - (90.59KB, 1227×537)
20452
>>20445

> вы можете отослать PR

Вообще-то BitBucket не даёт мне сделать это (скриншот прилагаю) по отношению к репозиторию «891raba».

Однако коммит у меня по адресу https://bitbucket.org/Mithgol/fbe-410/commits/63e06dbffef04c9c30fea721a9b3fe4c94af06f1 подготовлен.

Соответственно, либо владелец репозитория «891raba» сам зафетчит ветвь «webm» из моего репозитория и затем станет мёрджить её к себе в одноимённую ветвь, либо, наверное, владелец репозитория «Therapont» получит от меня PR в ветвь «public» с течением времени (после того, как запрос https://bitbucket.org/Therapont/fbe-410/pull-requests/15 будет принят).

Других путей я пока что не вижу, так как не особенно знаком с Битбакетом.
No. 20453  
>>20452
А~ попробуйте ещё раз PR сделать? Я сам битбакетом второй раз в жизни пользуюсь, но вроде подкрутил нужные настройки. Не выйдет так через час сам возьму.
No. 20454  
>>20453

А не вышло. Снова та же ошибка.

Некоторые реплики на форумах (и на Atlassian, и на StackOverflow) вроде как говорят, что и вообще это нипочём не преодолимая проблема — на BitBucket делать pull request из форкнутого репозитория не в него же и не в направлении первоисточника форка. Конструкцией, дескать, не предусмотрено.

(Может и врут, не знаю.)
No. 20455  
>>20454
Выцепил и применил патч сам. Благодарю за содействие.
No. 20456  
ReLIFE - MD.gif - (4.70MB, 1026×577)
20456
>>20455

Очень хорошо.

Слѣдующая моя мысль в том же направлении состоит в том, что сейчас у нас дѣйствуетъ такой развёртыватель миниатюр, который миниатюры аудиофайлов развёртывает до состояния звукопроигрывателей (что можно посмотреть, например, в репликах >>18692 и >>18702 и >>18703), поэтому заблаговременное формирование аудиопроигрывателей (особенно основанное на SWF Google) ни к чему, поэтому его уместно отпилить вместе с настройками.

Практическим выражением этой мысли служит коммит https://bitbucket.org/Mithgol/fbe-410/commits/d09547dfecb628c34251a81996a2e2c30ece35f2
No. 20458  
>>20456
Принято, но таким образом тип 'audio' не несёт никакой нагрузки, кроме разве смысловой. Может стоит его удалить тогда?
No. 20459  
ReLIFE ED05.png - (2.64MB, 1920×1080)
20459
>>20458

Очень хорошая мысль!
No. 20467  
ReLIFE ED05.png - (2.10MB, 1920×1080)
20467
Некоторое время думал над заданным в реплике >>18814 вопросом о смысле изложенного в реплике >>18805 намерения ограничивать на 410чане не один только объём файла, но также и длительность видеозаписей.

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

Это то самое и есть, о чём я в реплике >>19601 упоминал: 19 марта по адресу https://iichan.hk/d/res/244600.html#245388 на Ычане сказано было, что если звукозаписи MP3 или Opus не давать публиковать, то вместо них явятся такие MP4 и WebM, у которых каждым кадром дана обложка альбома, а звуковая дорожка (в формате AAC для MP4 или в формате Opus для WebM) прилагается та самая, которую нужно послушать.

И сбылось буквально. (Именно такого рода файл WebM можно по адресу https://iichan.hk/a/res/1403230.html#1407488 видеть, и он там вот ужé никак не менее двух недель кряду.)

Но, разумеется, если бы на Ычане было не только ограничение размера (не более 4096 килобайтов), но также и ограничение длительности, то никак нельзя было бы 4 минуты 25 секунд опубликовать — даже вышеозначенным способом нельзя бы было. И это, по-видимому, то самое и есть, к чему намерение >>18805 сводится: устроить такое ограничение на 410чане.

А иначе к чему бы это? — только к этому, понятно же.
No. 20468  
ReLIFE ED05.gif - (4.80MB, 272×153)
20468
Продолжая изложенную автором реплики >>18170 и автором реплики >>20325 мысль о возможности брать пример с расположенного по адресу https://gitgud.io/devarped/instant-0chan репозитория, мне хочется дополнительно упомянуть и о том, что по адресу https://kurisa.ch/sg/res/15697.html и https://kurisa.ch/sg/res/32736.html и https://kurisa.ch/sg/res/48357.html велось обсуждение доработок в другом ещё движке, который назван «Курисаба» (в честь Макисэ Курису из аниме и визуального романа «Steins;Gate» и их сиквелов) и который основывается (если только можно поверить изложенному в реплике https://kurisa.ch/sg/res/32736.html#42134 мнению) «на инстант-нульче, который, в свою очередь, на кусабе х». И упоминаю.
No. 20469  
Так как вновь наступил понедельник, то надо сказать несколько слов о том, с какими новыми возможностями 410чан вступает в эту неделю, и скажу.

Ни с какими.

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

Ждём дальше.
No. 20485  
>>20469

+1.

Соусовый аудиоответ на вопрос >>/b/134916 прилагаю.
No. 20486  
>>20485
Печаль, поддержка видео это очень весомый апдейт для нашего движка, и чана вообще. Например, можно было бы в /а/ и /ts/ создать тред с шебмками и инструкцией по их созданию средствами ffmpeg, и обмениваться там клипами и опенингами. Чуваки в /cu/ могли бы какие-то элементы готовки на видео записывать и выкладывать, урбанисты в /ci/ - урбанистику. В /dev/ бы можно было демонстрции игровых проектов делать правда у нас активно идет разработка только визуальных новелл, не ясно что там показывать на видео
No. 20487  
>>20486
А на практике этим будут пользоваться полтора человека.
No. 20488  
>>20487
Скажу больше: на деле это превратит Автобус в кладбище репостов смищных видосиков и музыки.
No. 20489  
>>20486 >>20488
Пассажир в те же 5 Mib сможет засунуть значительно больше видео в лучшем качестве, нежели в gif. Это хорошо ведь. Пассажиру не нужно будет перекодирывать видеофайлы в gif, он сможет постить их как есть. Это замечательно же. Посетителям иных досок тоже лучше будет, наверное, обитателям /a/ уж точно.
No. 20490  
>>20488
По этой логике Автобус бы уже давно был кладбищем смешных картинок и музыки (картинки и музыку-то прикладывать движок давно умеет)
No. 20494  
>>20490

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

И когда возможность публикации WebM появится, то это ещё вопрос, будет ли она во всех разделах включена, или только в одном-двух.

>>20486

> создать тред с шебмками и инструкцией по их созданию средствами ffmpeg

Не поможет.

Версия >>20487 более всего вероятна.

Для примера можно указать, что в реплике >>19332 и в ряде последующих реплик была дана инструкция по созданию GIFов, но создаёт ли GIFы кто-нибудь, кроме меня? — многие считают, что нѣтъ; напримѣръ, въ репликѣ >>/b/134609 появление GIFа у реплики было буквально названо той чертой, по которой меня можно отличать от других в тех разделах, где анонимность принудительна.

> можно было бы в /а/ и /ts/ (…) обмениваться там клипами и опенингами

> элементы готовки на видео записывать и выкладывать

> урбанистику

> демонстрации игровых проектов делать

Мрачно подозреваю, что для этого мало и недостаточно будет встроить публикацию WebM в движок и даже мало будет разрешить такую публикацию въ нѣкоторомъ раздѣлѣ.

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

Не может, например, в /ts/ быть никакого оупенинга в нормальном качестве (и не будет) до тех пор, пока там ограничение объёма файла остаётся двухмегабайтовым. Потому что частное от деления тех двух мегабайтов на 90 секунд (так как типичная длина оупенинга бывает именно девяностосекундною) равняется почти точно 182kbps. Для упомянутого в реплике >>20467 «звукового видеоформата» (обложка + звуковая дорожка) может и хватить, а для «нормального» видео — отнюдь нѣтъ.

То есть небольшое улучшение произойдёт (где было несколько секунд небольшого GIF, там будет десяток-другой секунд FullHD WebM в не особенно даже вырвиглазном качестве), однако «не стоит излишне пропихивать всякие там революционные идеи».™
No. 20496  
>>20494
>въ репликѣ >>/b/134609 появление GIFа у реплики было буквально названо той чертой, по которой меня можно отличать

Не-не-не-не-не. Так не пойдёт. Было упомянуто появление не некоторого GIF, а большого и тяжёлого GIF с артефактом-мозаикой (как он, артефакт этот, правильно называется, кстати?). Есть разница. Например, эта мозаика отсутствует или менее заметна в следующих постах с GIF: >>/b/133840, >>/b/134764, >>/a/14742, >>/b/93844. Именно по этому артефакту и проще всего отличать.

>создаёт ли GIFы кто-нибудь, кроме меня?
Я.

Наверное, не многие создают GIFы и, опять же, не многие в них перекодирирывают видеоконтент. Большинство, вероятно, имеют эти GIFы скачанными с чанов или откуда-нибудь ещё. Тоже самое частично верно и для видео: немногие нарезают, скажем, аниме на отрывки самостаятельно, многие постят скачаанное ими откуда-то. Поскольку, скорее всего, мало кто будет перекодирывать скачанные видео в GIF, Чиочан же видео (пока) не поддерживает, это ограничивает возможность постинга контента, который, быть может, хотелось бы запостить некоторой чиочаньке. Поддержка видео эту проблему решит.
No. 20497  
>>20496
>на отрывки самостоятельно
fixed
No. 20498  
>>20494
>только гадательно можно утверждать, обрела бы в этом разделе широкую популярность практика репостов музыкальных файлов, или не обрела бы, или сперва обрела бы, а затем была бы пресечена модерациею.
Ну, в /б/ уже существует тред обмена музыкой, и там обмениваются ссылками на музыку. Была бы возможность прикладывать - её бы просто прикладывали. И думаю за рамки этого оно бы не вышло. И учитывая что это 410й, обычно делятся чем-то интересным.

>Не может, например, в /ts/ быть никакого оупенинга в нормальном качестве (и не будет) до тех пор, пока там ограничение объёма файла остаётся двухмегабайтовым.
Есть какие-то объективные причины, по которым с учетом скорости постинга в /ts/, максимальный размер файла не может быть поднят до 5-8-10 мегабайт? Вроде ж в современных условиях диск ничего не стоит. Трафик может стоить больше, но опять же, не так много людей сюда заходят.

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

>>20496
Я думаю что имеется в виду, что не-техническим людям сложно ковыряться в энкодинге и реэнкодинге видео. Можно конечно для них сделать батничек / шелл-файл, который бы в интерактивном режиме помогал просто создавать видео, с учетом ограничения размеров постинга на досках. Т.е. перетаскиваешь на такой батничек файл, и он тебя интерактивно проводит по этапам, выберите доску, укажите время начала, укажите время конца (длительность), оставить / убрать звук, и дальше потом оптимизирует источник по разрешению и битрейту самостоятельно, с учетом ограничения доски. Это бы сильно упростило создание видеоконтента и постоянные посетители могли бы пользоваться, но сколько стало бы пользоваться фактически - вопрос. Впрочем, если идея интересна можно попробовать просто сделать, и посмотреть что будет.

>>20488
Вообще, тут переживают за контент так, как будто у нас посещаемость макача, и если аудитория что-то может сделать, то она обязательно сделает. А на самом деле у нас практически несуществующая аудитория, большинство которой состоит из постоянных многолетних постеров, не забаненных за все это время модерацией сайта, и не ушедших полностью на более посещаемые ресурсы. Т.е. во-первых можно изначально надеяться на то что описанный сценарий находится вне интересов нашей аудитории потому что если вы хотели смешных картинок и вебемок, зачем вы сидите на 410м, где их почти нет? Во-вторых, как и с любым другим контентом который не нравится модерации, если модерации он не понравится, она за него просто забанит, а контент удалит. Так что даже если сюда каким-то чудом попадет коварный репостер вебемочек данкест мемес, то он скорее всего быстро получит бан, после чего пойдет постить куда-то еще.
No. 20499  
Ещё раз вгляделся (на сей раз в том коммите, который по адресу https://bitbucket.org/Therapont/fbe-410/commits/3355e9e1bb4bc267b6c21d3a6962cbfd993790ef расположен) в те правки, которые должны принести нам возможность употребления WebM.

В файле inc/classes/manage.class.php на строке 282 увидел код «<option value="image">Audio</option>».

Много думал.

Не следует ли в духе реплики >>20458 отпилить этот код оттуда?

Если же это почему-либо не удобно, то нельзя ли хотя бы атрибуту «value» придать значение «misc» вместо «image»?
No. 20502  
>>20498

> Есть какие-то объективные причины, по которым с учётом скорости постинга в /ts/, максимальный размер файла не может быть поднят до 5-8-10 мегабайт? Вроде ж в современных условиях диск ничего не стоит. Трафик может стоить больше, но опять же, не так много людей сюда заходят.

Этак можно спросить по аналогии: есть ли какие-то такие объективные причины, по которым с учётом скорости постинга (главным образом — моего постинга) максимальный размер файла не может быть поднят до восьми или десяти мегабайтов в dev/? Нетрудно догадываться, что такие причины имѣются, коль скоро всѣ мы видимъ вꙭчію: максимальный размер файла не только не был поднят, но даже наоборот — он опущен был с 10 мегабайтов до 5 мегабайтов, то есть сразу вдвое. На этом примере приходится увидеть, что рассуждения о возможности пренебречь стоимостью объёмов диска и траффика оказались далековаты от истины, а были какие-то ограничения, и чтобы в те ограничения упереться, даже полутора человек >>20487 не потребовалось, а хватило и одного меня.

(В качестве наглядного сравнения я напоминаю, что чуть менее двух месяцев тому назад в примерно аналогичном обсуждении на Ычане по адресу https://iichan.hk/d/res/244600.html#246336 прозвучал упрёк «за сервера не вам платить», в ответ которому прозвучало несколько вариантов приглашения устроить механизм целевых денежных пожертвований, прямо привязанных к увеличению ограничения размера видеофайлов, но к ним ровным счётом никто не прислушался: так и остаётся для тамошнего /a/ не более четырёх мегабайтов, а для b/ и вовсе не более трёх.)

Есть ли какие-то такие объективные причины, которые администрацию 410чана удерживают от того, чтобы максимальный размер файла уменьшить до ычановских трёх-четырёх мегабайтов (или даже сразу вдвое — до 2500 килобайтов, а в ts/ до 1000 килобайтов, а в cu/ до 500 килобайтов) одновременно с внедрением WebM?
No. 20503  
>>20502
Мне кажется нет смысла внедрять WebM, если вместе с этим вводить такое устаревшее ограничение на размер файла. Хотя может кому-то бы и так было в радость.

Кстати, движок 410го случайно не в базу все файлы загружает? Может в этом и основная проблема? Тогда можно было бы относительно просто отучить движок так делать и хранить в базе только ссылку на файл.

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

Ну, если применительно к нашему чану, то самое простое - открыть Патреон, где будет написано "Администрация 410го чана развивает площадку для анонимного творчества и общения", а увеличение максимального размера файла оформить там как goal, который достигается по определенному количеству пожертвований. Соответственно, прочие улучшения качества жизни туда можно внести тоже. Самое удобное в патреоне для чанеров, что делать пожертвования можно анонимно. Самое удобное в патреоне для администрации, что кушать он не просит, его просто как открыть, так и закрыть. Зато раз и на всегда можно исключить спекуляции на тему "хочет кто-то пожертвовать на автобус на самом деле или нет", если уже даже с таким простым способом не будут, то точно не хотят. И как бы никто ничего не теряет, наоборот все получают возможность улучшить своё качество жизни на автобусе.
No. 20504  
Это нить про разработку движка, а не для порожнего флуда о лимитах и прочей работе сайта.
Упырьте мел.
No. 20508  
>>20503

> Кстати, движок 410го случайно не в базу все файлы загружает?

1) Нѣтъ. Код открыт, там это видно.

2) Особенной проблемы бы и не было. В зависимости от используемой базы данных, как оказывается, хранение файла в базе может быть даже эффективнее, чем в файловой системе. Например, для базы SQLite подсчёт https://sqlite.org/fasterthanfs.html показывает тридцатипятипроцентный рост эффективности. (Правда, Кусаба/FBE использует MySQL, а не SQLite, а для MySQL я аналогичных подсчётов не видывал.)
No. 20517  
>>20496

> GIF с артефактом-мозаикой (как он, артефакт этот, правильно называется, кстати?)

Есть два рода мозаики в тех GIF, которые я публикую на 410чане: мозаика на самóм GIFе и мозаика на его миниатюре.

Мозаика на самóм GIFе представляет собою классическую байеровскую матрицу 8×8 пикселов, которая была предложена Байером сорок пять лет тому назад (в 1973 году) в качестве средства, позволяющего использовать строго определённую мешанину точек двух различных цветов для отображения других цветов, промежуточных между этими двумя.

Первоисточник можно найти по адресу https://web.archive.org/web/20130512190753/http://white.stanford.edu:80/~brian/psy221/reader/Bayer.1973.pdf в Архиве Интернета. (Посканирован он очень хреново, поэтому качество иллюстраций в действительности не отражает настоящее качество достижения Байера.)

По адресу https://en.wikipedia.org/wiki/Ordered_dithering в Википедии находится статья, кратко пересказывающая суть. В настоящее время предпоследний абзац этой статьи гласит: «Additionally, because the location of the dithering patterns stays always the same relative to the display frame, it is less prone to jitter than error-diffusion methods, making it suitable for animations. Because the patterns are more repetitive than error-diffusion method, an image with ordered dithering compresses better» — что означает: «Кроме того, так как расположение узоров диѳеринга всегда остаётся тем же относительно границ кадра, то по сравнению с методами диффузии ошибок они менее склонны вызывать джиттер, что делает их более пригодными для анимаций. Так как узоры являются более повторяющимися, чем результаты метода диффузии ошибок, то изображения с такими узорами лучше сжимаются». (В этом тексте словом «джиттер» называется тот неприятный и раздражающий эффект, проявляющийся при некоторых методах использования точек двух различных цветов для отображения других цветов, промежуточных между этими двумя, который выглядит как склонность пиксела, в первоисточке имевшего промежуточный цвет, во время анимации от кадра к кадру быстро переключаться между этими двумя цветами, что выглядит как «поблёскивание», будто «рябь на воде» и проч. Этот эффект раздражает главным образом тем, что ввиду своей заметности отвлекает на себя изрядную часть внимания зрителя, которую совершенно не заслуживает, так как в первоисточнике отсутствует.)

Того же мнения насчёт «лучше сжимаются» держится и тот рецепт 2015 года, по адресу http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html расположенный, на котором основаны изложенные в реплике >>19332 (и в некоторых дальнейших репликах) мои рецепты изготовления анимированных GIFов посредством FFmpeg. Про методы, основанные на диффузии ошибок (а не на байеровских узорах), там сказано: «While this often provides a much better quality, it completely kills the compression of GIF» — что означает: «Хотя она нередко обеспечивает гораздо лучшее качество, она совершенно убивает сжатие GIF».

Использование байеровского подхода позволяет мне при создании довольно крупных GIFов (нередко имеющих размеры в районе HD или даже FullHD) удерживать их объём внутри 410чановского ограничения, равного 5000 килобайтов (ранее — внутри 10000 килобайтов), чему в архиве обсуждения http://410chan.org/dev/arch/res/17371.html нашлось бы (ближе к концу его) не менее четверти сотни примеров, кабы всѣ они не были уничтожены администрациею (движимою, по-видимому, желанием высвободить около четверти гигабайта жизненного дискового пространства на сёрвере).

Размер байеровского узора, FFmpeg используемого, согласно https://ffmpeg.org/ffmpeg-all.html#paletteuse равен 8×8 пикселов.

Что же касается гораздо более уродливой мозаики на тех миниатюрах, которые Кусабою/FBE создаются из таких GIFов, то это явление не имеет даже названия, а его первопричина заключается в чрезмерном принесении качества в жертву скорости — эта жертва более подробно рассмотрена в реплике http://410chan.org/dev/arch/res/17371.html#19336 и восьми последующих. Устранению этого эффекта я посвятил расположенный по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/12 запрос, суть которого состоит в том, чтобы движок Кусабы/FBE на 410чане не сам тщился создавать миниатюры, а перепоручал бы это занятие опять же в FFmpeg (раз уж FFmpeg на сёрвере 410чана всё равно будет поставлен ввиду необходимости внедрения WebM). Этот мой запроc 5 августа был принят администрацией 410чана, но с той поры не был ещё внедрён непосредственно на сёрвер 410чана, а остаётся на проверке у администрации.
No. 20520  
Упомянутое в реплике >>20517 благотворное влияние узоров Байера на сжимаемость GIFов постепенно сходит на нѣтъ по мѣрѣ уменьшения размеров GIFа, а замѣтность узоров, наоборот, возрастает (квадрат 8×8 занимает меньше одной тридцатидвухтысячной доли площади кадра FullHD 1920×1080, однако по отношению к кадру 320×180 займёт ужé одну девятисотую).

Соответственно, в тех случаях, когда принятое на 410чане ограничение объёма файла (до 5000 килобайтов, а в ts/ до 2000 килобайтов, а в cu/ до 1000 килобайтов) принуждает укладывать некоторые GIFы на прокрустово ложе менее 200 пикселов высотою (во имя сохранения многосекундной продолжительности таких GIFов необрезанною), можно и отказаться от узоров Байера в пользу диффузии ошибок по методу https://en.wikipedia.org/wiki/Floyd–Steinberg_dithering (который был предложен Флойдом и Штейнбергом в 1976 году). Этот их метод использует заметно «мелкозернистую» (3×2) мешанину пикселов и оттого создаёт ощущение более высокого качества тонких деталей изображения по сравнению с «крупноузорчатым» (8×8) байеровским, но вместе с тем для двухсотпиксельных (и меньших того) GIFов всё же создаёт файл либо не особенно большего размера (так что ростом размера можно и пренебречь во имя качества), либо даже несколько меньшего размера (что само по себе повадно). Примером этого подхода могут послужить анимации, приложенные к репликам >>20502 и >>/b/135340.

И так как миниатюры, создаваемые Кусабою/FBE, также по умолчанию имеют двухсотпиксельные размеры, то и в исходном коде запроса https://bitbucket.org/Therapont/fbe-410/pull-requests/12 для создания миниатюр FFmpeg использует именно алгоритм Флойда и Штейнберга, а не Байера.
No. 20521  
Длящееся со дня вторника по вопросу >>20499 молчание я считаю знáком согласия, так что по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/19 сочинил pull request.
No. 20528  
>>20504
Удваиваю этого джентльмена: >>20514
No. 20529  
1429846893905.jpg - (122.74KB, 535×627)
20529
>>20514>>20528
http://410chan.org/d/
No. 20544  
Наступил понедельник 27 августа 2018 года. Позади — последние выходные дни нынешнего лета. Настала пора огласить, с какими изменениями к лучшему 410чан вступает в новую неделю, и оглашу.

Устранена обнаруженная http://410chan.org/dev/arch/res/17371.html#20418 избыточность (теперь kusaba.js полагается на то, что Кусаба не создаёт графических файлов с расширением «jpeg»).

Переработана гиперссылка «Развернуть все изображения», нажатие на которую теперь не действует на звукопроигрыватели (чтобы предотвращать торможение и какофонию от одновременного пуска их) и на те изображения, которые и без того были вручную развёрнуты ранее нажатия на неё. Пожелание http://410chan.org/dev/arch/res/17371.html#20417 исполнено созданием дополнительной гиперссылки, убирающей развёрнутые изображения обратно в миниатюры.

В соответствии с замечанием http://410chan.org/dev/arch/res/17371.html#20422 реакция на гиперссылку «Полный текст» переработана таким образом, чтобы выполнять свои задачи и в начальной реплике из некоторой нити обсуждения, а не только в последующих репликах.

Кэшируется (а не скачивается всякий раз заново) скрипт, обновляющий фапчу.

Сёрвер теперь отдаёт файлы JS и CSS с явным указанием кодировки UTF-8, и это может помочь с отображением русских букв (и других неASCIIшных символов), например, при непосредственном просмотре адреса http://410chan.org/lib/javascript/kusaba.js во браузере.

Ферапонт Соусов устроил так, что SVG-значки в теме «Umnochan» теперь меняют цвѣтъ при наведении (на синий).
No. 20545  
Кроме >>20544 надо отдельно (чтобы не наткнуться на ограничение размера реплики) упомянуть и о том, что администрацией были приняты предложенные мною изменения движка и конфигурационного файла, позволяющие употреблять FFmpeg (а точнее — запуск программы «ffprobe» и затем ещё «ffmpeg» из комплекта FFmpeg) для создания миниатюр графических файлов.

Идея такого употребления была первоначально высказана в реплике https://nullnyan.net/b/thread/20928#P22458 и по замыслу автора реплики https://nullnyan.net/b/thread/20928#P22472 обеспечивает ускорение создания миниатюр по сравнению с принятым в Кусабе по умолчанию способом (GD). Такой подход, кроме роста скорости, обеспечивает также возрастание наблюдаемого качества изображения за счёт возможности употребить фильтр Ланцоша. Так как установка FFmpeg в любом случае планируется (в качестве генератора миниатюр для видеозаписей), то рост скорости и качества достигается к тому же с экономией тех усилий, которых потребовала бы установка ещё и ImageMagick (единственной до сих пор альтернативы для GD) с той же целью.

По сравнению с первоначальной реализацией https://gitgud.io/devarped/instant-0chan/commit/351c5f0230ec52e2738a589c1ee0fefca08639b8 предложенная содержит ряд улучшений.

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

Во-вторых, параметр «quality», вовсе никак не действующий на FFmpeg, заменён указанием «-q 1» для JPEG (согласно приведённым по адресу http://www.ffmpeg-archive.org/Create-high-quality-JPEGs-td4669205.html рекомендациям он обеспечивает качество JPEG около 89%); что же касается PNG, то по умолчанию FFmpeg и так ужé применяет для PNG максимальное сжатие.

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

В-четвёртых, наложен фильтр Ланцоша.

В-пятых, исправлена оплошность, суть которой — указание «scale=» перед кавычками, а не внутри них.

На всякий случай ещё раз напоминаю: во избежание ошибки, в реплике >>19790 упоминаемой, рекомендую избегать употребления версии FFmpeg более новой, чем 3.4.2.
No. 20546  
Впрочем, сравнение миниатюр файлов, приложенных к репликам >>20544 и >>20545 (в первом из которых диѳэрингъ основан на идеях Байера 1973 г., а во втором — на идеях Флойда и Штейнберга 1976 г.), позволяет почти с полною уверенностью утверждать, что эти миниатюры созданы всё ещё тем способом, который используется Кусабою по умолчанию — и, следовательно, упомянутые в реплике >>20545 изменения не были ещё включены на 410чане: либо настройке «$cf['KU_THUMBMETHOD']» ещё не придали значение «'ffmpeg'» в конфигурационном файле, либо даже сам FFmpeg на сёрвере 410чана ещё не ставили (без чего эту настройку в это положение переключать ещё рано и было бы вредно).
No. 20548  
1264526783515.jpg - (681.59KB, 900×1500)
20548
На тесте «ffmpeg» генерировал уменьшенные копии ГИФов целиком анимированными вместо использования начального кадра (хотя в конфиге для них стоит «false»), то есть в таком виде не пригоден для использования.
No. 20550  
>>20548

Пожалуйста, приведите текст результата выполнения на сёрвере команды «ffmpeg» без параметров. Хочу посмотреть на её версию.
No. 20551  
tex_chara_l_567.png - (116.28KB, 1024×1024)
20551
>>20550
Очевидно, что версия из стабильного «Дебиана».
>3.2.12-1~deb9u1
Также очевидно, что она не вырастет в ближайшие пару лет.
No. 20552  
output.gif - (19.22KB, 200×113)
20552
>>20551

Версия 3.2.12-1~deb9u1 вовсе не очень старая, вообще-то она должна работать невозбранно.

Для начала попробуем воспроизвести желаемое поведение не из PHP, а из командной строки.

Вот я скачиваю к себе на Windows архив https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-3.2.4-win64-static.zip (по логикѣ версій онъ старше, чѣмъ 3.2.12-1~deb9u1). Распаковываю, захожу в подкаталог «ffmpeg-3.2.4-win64-static/bin», запускаю команду «fmpeg», убеждаюсь в том, что работает версия 3.2.4 (а не взятая из PATH более новая).

Вот я скачиваю анимированный GIF http://410chan.org/dev/src/153533527866.gif в тот же подкаталог.

Вот я запускаю двѣ команды, имитирующие результат конкатенации, достигнутый строками со 114 по 131 в файле «inc/func/posts.php» (эти номера строк привожу по его нынешней версии в ветви «public»):

Команда №1:

ffmpeg -i 153533527866.gif -vframes 1 -vf "scale=200:-1:flags=lanczos,palettegen" palette.png

Затем — команда №2:

ffmpeg -i 153533527866.gif -i palette.png -vframes 1 -lavfi "scale=200:-1:flags=lanczos [x]; [x][1:v] paletteuse=dither=floyd_steinberg" output.gif

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

После завершения второй команды я могу убедиться, что файл «output.gif» является неанимированным (однокадровым) GIFом. (Для наглядности этот файл я прилагаю тут.) Созданный промежуточный файл «palette.png» после этого не нужен, я его стираю.

А как выглядит результат попытки повторить эти действия в стабильном «Дебиане»?

В идеале он должен выглядеть байт-в-байт как тот файл, который я прилагаю к своей реплике.

Если версия 3.2.12-1~deb9u1 незначительно отличается от 3.2.4, то тогда не байт-в-байт, но всё же такой же GIF — неанимированный (однокадровый) — получиться должен.

А если не получается такой файл, то тогда что-то с FFmpeg не так в Debian.

А если получается в точности такой файл, то что-то не так с формированием командной строки из PHP-кода.

Не может же условное выражение, на строке 117 расположенное, не сработать? — оно там довольно простое для этого.

(Я надеюсь, в кусабовской конфигурации для переменной «KU_ANIMATEDTHUMBS» значение «false» записано без кавычек?)
No. 20554  
Кажется, я нашёл, в чём ошибка.

Причём она была в самом начале существования репозитория https://bitbucket.org/Therapont/fbe-410 (и вообще она появилась никак не позже расположенного по адресу https://github.com/tslocum/kusaba/commit/193ae0c325966f8514eb35cc905dc2452dce145a коммита, датируемого 2 сентября 2007 года — скоро ему ровно 11 лѣтъ).

Кусок кода, создающего миниатюры посредством ImageMagick — тот кусок, который я копировал и переправил для FFmpeg — был сочинён человеком, убеждённом в своём праве сочинять условные выражения наподобие «substr($filename, 0, -3) != 'gif'» для проверки того, не оканчивается ли имя «$filename» расширением «'gif'».

Я воспринял это убеждение некритически (предполагая, может быть наивно, что вряд ли можно наткнуться на грубую ошибку в коде, проработавшем более десятилетия на нескольких известных сайтах). Между тем один лишь взгляд, по адресу https://secure.php.net/manual/en/function.substr.php брошенный, способен открыть печальную истину: функция «substr» в языке PHP работает совсем не так, и вмѣсто «substr($filename, 0, -3)» должно было стоять просто-напросто «substr($filename, -3)».

О, етить.
No. 20555  
Патч: https://bitbucket.org/Therapont/fbe-410/pull-requests/20
No. 20556  
Пристальное вглядывание в код https://gitgud.io/devarped/instant-0chan/blob/5ff12039145d7292cddfcaec67633ea854bc30e5/inc/func/posts.php#L76 убеждает меня в том, что и там эта ошибка до сих пор наличествует, по меньшей мере, в двух местах.

Рекомендую автору реплики http://410chan.org/dev/arch/res/17371.html#18170 и автору реплики http://410chan.org/dev/arch/res/17371.html#20325 (излагавшим мысль о возможности брать пример с расположенного по адресу https://gitgud.io/devarped/instant-0chan репозитория) донести соображения >>20554 до публики, занимающейся исправлением той репы.
No. 20558  
>>20556
Передал, спасибо.
Там, кстати, немного иначе сделали.
No. 20559  
>>20558

Есть определённая логика в том, чтобы код «substr($filename, 0, -3) != 'gif'» поправить не простою заменою на «substr($filename, -3) != 'gif'», а заменою на «substr(strrchr($filename,'.'),1) != 'gif'», как по адресу https://gitgud.io/devarped/instant-0chan/commit/56d38d35fb3cbfb0c78d4d7e54935ecae62382ac сдѣлано.

Однако при бѣгломъ взглядѣ эта логика неочевидна. Даже сам автор через пару-тройку-другую месяцев может начать недоумевать над этаким-то сочетанием «substr» и «strrchr».

Практичнее (потому что нагляднее) выразить совершенно ту же логику исходным кодом «substr($filename, -4) != '.gif'».

И теперь я такъ и сдѣлалъ.
No. 20560  
Leonmichelle_serious.jpg - (113.06KB, 1280×720)
20560
Чем вам mime_content_type() из Fileinfo не угодил, обязательно надо велосипеды городить?
No. 20561  
>>20560

Разве ImageMagick и FFmpeg ориентируются не на расширение файла, а на «магию» анализа контента его? — кажется, всё же на расширение; а раз уж на расширение, то его-то и следует сравнивать с тем или иным.
No. 20564  
К >>20561 следует прибавить ещё два соображения, и прибавлю.

Во-первых, https://secure.php.net/manual/en/function.mime-content-type.php полагается на содержимое «magic.mime», а я не знаю, сколько ему лѣтъ. Может нечто вроде >>20551 быть, несколько лѣтъ без обновлений, и порождать подобные https://nowere.net/d/res/3573.html#4691 и https://nowere.net/d/res/3573.html#4695 ошибки распознавания WebM, напримѣръ, потому что этот формат новѣе.

Во-вторых, внутри функции «createThumbnail» поздновато заниматься анализом контента на соответствие расширению. Такой проверке мѣсто в методе «HandleUpload» у класса «Upload» в файле inc/classes/upload.class.php, и она там есть, хотя и несколько рудиментарная (ограничивающаяся вызовом функции «getimagesize»). Тѣмъ, кому сія рудиментарность не по нраву, придётся сочинить собственный патчъ для ея исправленія. К тому времени, когда «createThumbnail» вызывается, можно считать содержимое файла провѣреннымъ, и соответствие его расширению установленным достовѣрно, и на расширение ориентироваться. (По точно таким же соображениям коммит https://bitbucket.org/Therapont/fbe-410/commits/3355e9e1bb4bc267b6c21d3a6962cbfd993790ef пополняет метод «HandleUpload» проверкой видео через запуск «ffprobe» и последующим анализом результатов, производимым, так сказать, «с пристрастием» — после чего внутри функции «createThumbnail» запускает уж «ffprobe» без всякой проверки, съ полнымъ довѣриемъ к результатам.)
No. 20565  
Файл
удалён
>>20561
Ох, горюшко ты горе... Этот ЯП, похоже, проклят. Ладно, могу ещё понять, что со времён 5.3.0 до 2016 года семь лет был тупой баг в документации, когда при переносе модуля из пекла эту функцию пометили как deprecated (хотя мартыхи документацию обычно не читают, а всё, что реально deprecated, бросает E_DEPRECATED, если раньше не сегфолтится), и подобный вопрос, вброшенный в стадо, неизбежно порождал там срач.

Во-первых, ни один вменяемый разработчик полагаться на честность юзера и ловить сегфолты с RCE не будет. Ты никогда не задумывался, зачем в первых нескольких байтах пишут %PNG, яШяа, MZ, e.t.c.?
Во-вторых, со времён KDE 3.x файлы не обязаны иметь расширений чтобы корректно определяться KDE-шным проводником, поскольку mime.magic — часть NIX-подобных ОС, т.е. юзер в принципе не обязан именовать свои картинки по чужим правилам на прыщавом десктопе. In contrast, Винды, по крайней мере XP и ниже, полагаются на имена файлов, делегируя ответственность ассоциированному с расширением ПО.
В-третьих, есть такая штука, как валидация данных, особенно присланных непойми кем из интернета, особенно если предполагается последующая обработка этих данных на сервере. Хотя бы ради того, чтобы сервер в случае чего не упал.
In the fourth, the browser usually doesn't care about mime-types of transmitting files.
No. 20566  
>>20565

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

А у нас такие особые юзеры, нечестность которых ограничивается постановкой некорректных расширений и не простирается на постановку некорректных байтов в начале файла, так что «mime_content_type() из Fileinfo» внезапно всех спасёт?

И ещё у нас есть пример того, как достигнуть сегфолт+RCE, скормив некорректный файл в GD в PHP, причём либо сразу в «getimagesize» такой сегфолт, либо «getimagesize» даже выдаст не FALSE и позволит сегфолт чуть позже устроить? Причём этот пример можно предотвратить именно благодаря некорректности байтов в начале файла?

> Ты никогда не задумывался, зачем в первых нескольких байтах пишут %PNG, яШяа, MZ, e.t.c.?

Да куда уж мне задумываться над такими высокими материями. Я и адрес https://secure.php.net/manual/en/function.mime-content-type.php в реплике >>20564 привёл без единой мысли: этот адрес просто выделился из организма на чистых инстинктах, всё равно что слюна у собаки Павлова или использование каменных орудий калифорнийскими каланами.

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

Есть такая штука, как повторение ранее изложенной мысли второй раз заново, только другими словами: вместо «ни один вменяемый разработчик полагаться на честность юзера не будет» пишешь «валидация данных, особенно присланных непойми кем из интернета», а вместо «ловить сегфолты с RCE» пишешь «сервер упал». И вот уж новый пункт готов, который «в-третьих», но который от «во-первых» ничем по сути не отличается, только слова другие. Это делает честь тезаурусу.

> In the fourth, the browser usually doesn't care about mime-types of transmitting files.

But when it does, that's https://en.wikipedia.org/wiki/Content_sniffing
No. 20567  
По адресу https://gitgud.io/devarped/instant-0chan/commit/71aca5a666ef7bd069e8b4a59aba825f0c760988 с интересом наблюдал, как в instant-0chan прибавили (ещё 25 апреля) возможность вызова OptiPNG¹ для уменьшения объёма файлов PNG — однако же почему-то только для файлов, содержащих миниатюры, причём созданные не из GD.

Между тем хорошо извѣстно (или должно быть извѣстно), что нѣкоторые видеопроигрыватели (в частности, Media Player Classic Home Cinema) сохраняют кадры аниме в файлах PNG не очень эффективно, так что применение OptiPNG к такому файлу (а не к одной только миниатюре его) в момент загрузки файла на 410чан могло бы способствовать экономии мѣста на сёрверѣ.

Есть ли OptiPNG на сёрверѣ у 410чана? Если есть, то какой версии? Если нѣтъ, то нельзя ли поставить?

Какого мнѣнія держится администрация 410чана насчёт возможности употреблять OptiPNG, будет ли в список желаемых изменений (по адресу https://bitbucket.org/Therapont/fbe-410/issues?status=new&status=open расположенный) прибавлять эту возможность?

А как насчёт возможности загрузки нѣскольких файлов?

А как насчёт возможности указать вмѣсто файла нѣкій URL, ведущий на крупнофайловый хостинг (YouTube, Vimeo, Coub, IPFS, Dropbox, Mega, Google Drive, Яндекс.Диск, etc.)?

А как насчёт тэгов meta для Twitter Cards?²

А как насчёт предупреждающего надписывания видеозаписей, содержащих звук, но зато одновременного включения этого звука вместе с видеозаписью в момент первого же жмяка мышóю по миниатюре видеофайла?

____________

¹ http://optipng.sourceforge.net/

² Например, https://developer.twitter.com/en/docs/tweets/optimize-with-cards/overview/summary-card-with-large-image
No. 20568  
8b36967c7f437900635ee6adbdcf388b.jpg - (713.43KB, 1680×1050)
20568
>>20567
По всем позициям: не нужно.

А конкретно «Ютуб» в виде видосов тут всегда был и есть, просто мы его не используем.
No. 20573  
bg-transparent.gif - (17.22KB, 150×150)
20573
Посмотрел на создание превьюшек через ffmpeg — теряется прозрачность в gif.
No. 20574  
По-видимому, наблюденіе >>20573 совершенно справѣдливо, и багъ https://trac.ffmpeg.org/ticket/6813 (или другой подобный) является первопричиною его.

У меня нѣтъ словъ, господа, для того, чтобы передать вамъ глубину моего разочарованія. До этого дня я имѣлъ основанія надѣяться на то, что ужасное качество миниатюръ гифовъ намъ удастся преодолѣть хотя бы уходомъ на «ФФмпэгъ», но это стремленіе оказалось цѣликомъ безплоднымъ.

Видъ ошибки, въ репликѣ >>19790 упомянутой, какъ бы говорилъ мнѣ, что нельзя и «ФФмпэгъ» считать совершенно свободнымъ отъ оплошностей, но могъ ли я предвидѣть такую-то глубочайшую хѣрню, доходящую по глубинѣ до вещей элементарнѣйшихъ, такихъ какъ обработка прозрачности? — никоимъ образомъ не могъ!

О, етить.
No. 20575  
Остаётся ли какой-нибудь разумный третий путь создания нормальных человеческих миниатюр GIFов?

Прежде всего: установлено ли на сёрвере у 410чана программное обеспéчение ImageMagick или GraphicsMagick? — и если да, то какой версии? — а если нѣтъ, то нельзя ли установить его?
No. 20576  
>>20575 Оба есть, 6.9.7.4, 3.25 (из стабильного дебиана)
No. 20577  
>>20576

Могу ли я считать, что порядок версий «6.9.7.4, 3.25» соответствует порядку упоминания ImageMagick и GraphicsMagick в моей предыдущей реплике?

Но тогда что такое «3.25», если по адресу http://www.graphicsmagick.org/ последней названа версия 1.3.30?

Может быть, GraphicsMagick 1.3.25?
No. 20578  
>>20577 Да, ошибка при копи-пасте. Версия GM 1.3.25.
No. 20579  
example.7z - (29.20KB)
20579
>>20578

Я проверил GraphicsMagick версии 1.3.25 у себя на Windows и убедился, что эта программа не умеет нормально генерировать анимированные миниатюры анимированных GIFов: они то подлагивают, то подёргиваются. Сочинять её поддержку я не стану.

Что же касается ImageMagick, то по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/22 поддержку этой программы я напилил.

Напоследок я должен сознаться, господа, что меня разочаровал расхваливаемый по адресу https://www.imagemagick.org/Usage/quantize/#dither_how алгоритм перераспределения ошибок вдоль кривой Гильберта, потому что на примере GIF-анимации, к реплике >>20577 приложенной, я убедился в склонности этого алгоритма к неспровоцированным однопиксельным выплескам цвета (по сравнению с результатами старого доброго алгоритма, предложенного Флойдом и Штейнбергом в 1976 году).

И сознаюсь.

К этому разочарованию я пришёл, когда подал вот какие двѣ команды:

convert "не время сдаваться (FullHD Bayer).gif"[0] -resize 200x200^> example.gif

convert "не время сдаваться (FullHD Bayer).gif"[0] -resize 200x200^> -dither FloydSteinberg exampleFS.gif

(Если будете повторять их не под Windows, то не позабудьте переменить «^>» на «\>».)

С результатами вы можете ознакомиться в прилагаемом архиве 7-Zip. В файле example.gif (по сравнению с контрольным exampleFS.gif по Флойду и Штейнбергу) на небе видны две дополнительные тёмно-синие точки, а несколько ниже — какие-то турбулентные завихрения на границе между небом и зарёю.

В итоге по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/22 я вызываю именно алгоритм Флойда и Штейнберга.
No. 20581  
locomotion.gif - (4.83MB, 334×188)
20581
Наступил понедельник 3 сентября 2018 года, первый понедельник нынешней осени. Настала пора огласить, с какими изменениями к лучшему 410чан встречает новую неделю, и оглашу.

Во-первых, создание миниатюр изображений возлагается теперь на программу ImageMagick, а не на библиотеку GD языка PHP. Это изменение должно принести нам рост качества результатов миниатюризации, особенно заметный в случае анимированных GIF, содержащих узоры Байера, для которых предшествующий алгоритм создавал довольно досадные низкокачественные миниатюры с резкими изменениями цвета, происходившими в шахматном порядке. Пример прилагаю.

Во-вторых, выявлена и обойдена та проблема, ввиду которой во браузере Mozilla Firefox ещё сохранялся упомянутый в финале реплики http://410chan.org/dev/arch/res/17371.html#20260 недостаток, свойственный первому поколению развёртывателей миниатюр, то есть сохранялась задержка между жмяком мышóю по миниатюре и началом полноразмерного отображения — задержка, равная промежутку времени между отправкою запроса на сёрвер и началом поступления первых пикселов с сайта. (Для устранения этой задержки теперь миниатюра делается не фоном полноразмерной иллюстрации, а второю иллюстрациею, растянутою до того же размера да подложенною под неё, как на Архиваче.

Исключением по-прежнему являются файлы GIF, для которых такого подкладывания не происходит по причинам, изложенным в реплике http://410chan.org/dev/arch/res/17371.html#20261 под конец её.)
No. 20583  
Можетъ ли кто-нибудь понятно объяснить мнѣ, какимъ образомъ получилось такъ, что даже измѣненія https://bitbucket.org/Therapont/fbe-410/commits/0f1aa5969812263c8645707004c7cfa31086bac7 въ кодѣ на сёрверѣ не привели къ устраненію ошибки, по адресу http://410chan.org/dev/arch/res/17371.html#18031 обнаруженной?
No. 20585  
KO.png - (30.01KB, 300×340)
20585
Если администрации нужна какая-нибудь помощь по допиливанию исходного кода видеообработчика, то давайте, по крайней мѣрѣ, поговорим об этом поподробнее.
No. 20586  
>>20585
Пока не тестировали этот код, так что и говорить нечего.
No. 20588  
>>20586 Код пока на локалхосте тестируется.
No. 20591  
Patreon.png - (99.56KB, 788×849)
20591
>>20503

> Самое удобное в патреоне для чанеров, что делать пожертвования можно анонимно.

Разве анонимно? Если на странице https://www.patreon.com/saucenao я нажимаю кнопку «BECOME A PATRON», то оказываюсь переброшенным на страницу https://www.patreon.com/bePatron?c=130578 с приглашением ввести желаемый размер пожертвования, но затем (после нажатия на кнопку «CONTINUE») — на страницу https://www.patreon.com/join/saucenao/signup с приглашением либо регистрироваться, либо через Facebook заходить. Сие не анонимно.
No. 20593  
>>20591
Регистрироваться действительно необходимо, тем не менее само пожертвование можно сделать анонимно.

https://patreon.zendesk.com/hc/en-us/articles/203913579-Can-I-be-anonymous-

>We want you to be whoever you want to be, as long as you provide your real payment info.

Стоит заметить, что патреон также позволяет использовать для пожертвования пейволл, типа того же paypal.

Чтобы пожертвования не было видно:

https://patreon.zendesk.com/hc/en-us/articles/204694855-What-does-it-mean-if-my-account-is-private-

Впрочем, если это всё муторно, можно просто сделать в банке обезличенную карту, и потом пожертвовать с этой карты через интерфейс яндекс денег.
No. 20618  
По работе видосов замечаний пока нет, но на данный момент требуется синхронизировать ветку public-webm с изменениями, принятыми в public.
No. 20619  
C64IhZ9VAAEpVuF.jpg - (455.83KB, 1386×1969)
20619
>>20618
> замечаний пока нет
А, нет, есть. При попытке запостить ogv выдает "Filetype tampering detected"

И да, не помню точно, сделано ли, нужно отсекать видео с двумя и более видеотреками. А то напостят.
No. 20622  
>>20618

Запрос на синхронизацию по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/24 отправлен.

>>20619

Прошу выложить пример OGV, которым это достигнуто, так как собственными примерами OGV не располагаю.

P. S.   А у нас точно есть намерение поддерживать заливку видео OGV, а не одних только WebM и MP4?
No. 20624  
>>20622
>OGV и WEBM как минимум, а также MP4
https://bitbucket.org/Therapont/fbe-410/issues/15/
No. 20625  
そですか。
No. 20626  
Жив Господь!.jpg - (205.85KB, 811×1140)
20626
>>20619

По адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/24 прибавил два коммита, которые должны устранить ошибочное появление сообщения «Filetype tampering detected» и исключить возможность загрузки таких видеофайлов, в которых число видеодорожек отличается от единицы.

Проверяйте.
No. 20628  
yellow vortex.gif - (1.95MB, 450×450)
20628
Кстати, если есть какие-нибудь другие интересные пожелания, порождённые опасением «а не то напостят», то не стесняйтеся как можно ранее высказать и их — например, чтобы и их можно было сразу реализовать на нынешней неделе, если удастся.

Нужно ли проверять, какая https://ru.wikipedia.org/wiki/Цветовая_субдискретизация используется в видеозаписи, и запрещать видеоролики, в которых она не соответствует схеме 4:2:0? Если не запрещать их, то напостят пренепременнейше.

Нужно ли запрещать видео, у которого количество звуковых каналов в звуковой дорожке равно не 1 (моно) и не 2 (стерео), а больше (квадрозвук, или surround sound, или что-то другое в этом же роде)? Если не запрещать, то можно быть совершенно уверенными, что напостят, да ещё в дополнительных звуковых дорожках будут ругаться по матери и по Путину, а модератор не услышит, модератор пропустит.

Нужно ли ограничивать размер кадра снизу (чтобы не напостили слишком небольших) или сверху (чтобы не напостили слишком больших)? А не то беспременно напостят ведь!

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

А как насчёт частоты дискретизации звука: 48000 раз в секунду — это ещё ok, или надо не более 44100? Любители тёплого звука напостят, это они умеют.

Нужно ли проверять в случае MP4, какой из аудиопрофилей https://en.wikipedia.org/wiki/MPEG-4_Part_3#Audio_Profiles используется, и запрещать те видеоролики, в которых он сложнее AAC LC? А не то их напостят, а у кого-то тупой мобильник декодировать не потянет!

Нужно ли проверять https://en.wikipedia.org/wiki/Pixel_aspect_ratio и запрещать видеозаписи с неквадратными пикселами? А не то найдутся и таковские, которые их напостят, чтобы у добрых людей видео перекосило!

Нужно ли принимать видеоролики только с восьмибитными пикселами, а с десятибитными запрещать? Если не запретить, то закономерно напостят десятибитных — хотя бы оттого, что станут десятибитное аниме конвертировать без умаления глубины цветности.

Нужно ли проверять, используется ли https://ru.wikipedia.org/wiki/Прогрессивная_развёртка в видеоролике, и запрещать те, в которых развёртка чересстрочная? А не то ретроанимешники напостят, да и как им тогда было бы не напостить.

Если всѣ эти идеи станут постепенно возникать въ умѣ и высказываться по одной в неделю, и если после каждой идеи страшная догадка «а не то напостят» (впрочем, вполне закономерная, потому что действительно же напостят ведь, это и к гадалке не ходи) начнёт тягостно волновать душу и тормозить внедрение видеовозможностей на 410чане, то тогда можно по календарю догадываться, что видеофайлов на 410чане мы и до второй половины ноября не увидим (и это ещё в лучшем случае!), так что предлагаю администрации сразу высказаться о каждой из них.
No. 20629  
>>20628
Не знаю, видел ли ты это, но Якуй не осилил: https://files.catbox.moe/7o4xyh.mp4 https://files.catbox.moe/a96733.mp4 https://files.catbox.moe/j8n6qg.mp4
No. 20631  
>>20629

Разумеется, всѣ эти файлы я видел: реплики http://410chan.org/dev/res/17371.html#18841 и http://410chan.org/dev/res/17371.html#18855 и http://410chan.org/dev/res/17371.html#18857 об этих файлах, оставленные зимою нынешнего года, принадлежат мнѣ.

Не увѣренъ, что значит «Якуй не осилил», но нынешний код FBE (из ветки public-webm) запрещает публикацию файла https://files.catbox.moe/7o4xyh.mp4 (так как файл настолько битый, что FFmpeg отказывается сделать из него миниатюру), а два других принимает.

Так как по адресу http://410chan.org/dev/res/17371.html#18857 я упоминал способность браузера Mozilla Firefox невозбранно (и безглючно) открывать эти два другие файла, то я пока не вижу никакой особенной проблемы в их публикации. По адресу http://410chan.org/dev/res/17371.html#18855 я сообщал уж, что считаю делом браузера готовность открыть видеофайл (или готовность с ошибкою отказаться открывать его), как это и с неподвижными картинками случается.
No. 20636  
Около десяти минут тому назад исходный код из ветви public-webm был слит в ветвь public.

Это явный знак, позволяющий с изрядною уверенностью утверждать, что администрация 410чана начинает окончательное (предстартовое) тестирование видеохостингового исходного кода.

Возрадуйтеся!
No. 20638  
Опечатка: посты с webm (и т.п.) без превью в rss. Посты с картинками показывает нормально.
No. 20639  
Прошу применить поправку https://bitbucket.org/Therapont/fbe-410/pull-requests/25/ для коррекции стилей медиапроигрывателей.
No. 20640  
>>20638

Там не опечатка, а логическая ошибка автора движка, допущенная в файле inc/classes/rss.class.php на строке 50.

Нельзя просто приписать букву «s» в конце имени файла (перед точкой и расширением) и переменить название его папки «src» на «thumb» и надеяться, что получится адрес миниатюры. Это и раньше работало только с картинками, а с некартиночными файлами не работало и работать не могло, так я это понимаю.
No. 20641  
>>20639 ok.
No. 20642  
1162238297671.gif - (292.22KB, 800×733)
20642
>>20638>>20640
Но это не значит, что это не может быть починено. Сделал PR.
И прошу прощения за продолжительное отсутствие.
No. 20643  
>>20638
У меня с какого-то обновления вообще всё без превью. Учитывая что читалка ревностно относится к стандартам, проблема таки на автобусе.
No. 20645  
Cloudflare по адресу https://blog.cloudflare.com/distributed-web-gateway/ объявляет о начале поддержки IPFS и о запуске расположенного по адресу https://cloudflare-ipfs.com/ собственного гейта.

По адресу https://www.cloudflare.com/distributed-web-gateway/ сообщается, что кэширование контента IPFS происходит более чем на полутора сотнях дэйтацентров Cloudflare. (Скриншот прилагаю.)

С учётом вновь открывшихся обстоятельств не пожелает ли администрация 410чана пересмотреть ранее данный отрицательный ответ >>20568 на вопрос >>20567 о возможности указать вмѣсто файла такой URL, который вёл бы в IPFS?
No. 20646  
>>20645
Вы и так можете указывать любой URL, который не внесён в спамфильтр.
Умерьте пыл. Тут имиджборд, а не файлообменник.
No. 20647  
>>20646
Так понял, Мицгол предлагает использовать как файлообменник как раз не Автобус, а Флару, на Автобусе же контент только подгружать с неё.
No. 20649  
Dream with your eyes open.jpg - (1.25MB, 3914×3250)
20649
>>20647

Закономерные события рано или поздно происходят. Со временем так или иначе Соусов поймёт, что двух небольших команд, поданных в консоли, вполне достаточно, чтобы архив его стрима сохранялся не только пару недель на «Твиче», но и неограниченно долго в IPFS (и открывался в уютном видеопроигрывателе рядом с репликою на имиджборде, если в имиджборде заложена поддержка IPFS, а результат этих команд запостили); если интересно, то вот пример таких двух команд для архива №310805212:

youtube-dl https://www.twitch.tv/videos/310805212

ipfs add -w "Унылый фанарт-v310805212.mp4"

No. 20650  
>>20649
Вот, что думаю: а нельзя ли полностью всю статику в ИПФС перенести, поставив демона на сервере? Это же огромная экономия места получится.
No. 20654  
>>20650

Если поставить демона на сервере и перетащить на сервере всѣ статические файлы из обычной файловой системы в P2P-распределённую систему IPFS, то экономии места не получится (файлы придётся и дальше в IPFS держать, чтобы был хоть один надёжный источник их для P2P). Зато получится экономия траффика и притом ещё достижение ≈100% аптайма, но для того и для другого непременно потребуется, чтобы для WWW хостом файлов указан был не 410чан, а IPFS-гейт Cloudflare.

Если в довершение к этому всё-таки нужна и экономия места на сервере, то её можно достигнуть, например, если статические файлы сохранять (для раздачи их в IPFS) не на сервере у 410чана, а под кроватью у админа на отдельном сервере, который дешевле в обслуживании и от которого не потребуется 100% аптайма. Или, например, если хранить статические файлы всё-таки на сервере в IPFS, но зато после отправки обсуждения в архив стирать всѣ статические файлы, обсуждением употребляемые, тем самым полагаясь на то, что за время жизни обсуждения эти файлы осели в нескольких копиях у читателей (на их собственных, читательских, демонах IPFS; конечно, для того наперёд надо пропагандировать и среди читателей готовность установить IPFS в их системы и притом ещё пропагандировать готовность дополнительно установить также и расширение https://github.com/ipfs-shipyard/ipfs-companion во браузеры, способствующее локальному кэшированию P2P-распределённого контента для последующей раздачи в IPFS) — тогда размер необходимого места на сервере стабилизируется в объёме активных обсуждений, а не будет неуклонно возрастать со временем по мере архивации прежних обсуждений. Это также экономия.

(Можно и комбинировать эти приёмы — например, архив отправлять на выделенный IPFS-сервер к админу под кровать, не полагаясь на одних читателей.)
No. 20655  
>>20654
Идея скорее в недобросовестном использовании предоставляемых Клаудфларой возможностей. А именно того, что они на своих серверах будут кешировать контент, слитый на их гейт. Опять же если я не Мугичкой поперёк прочитал.
То есть можно заливать статику на сервер, скидывать через ИПФС в гейт Флары, держать до какого-то момента, пока контент не закешируется на их серверах, после чего удалять со своего. Вопрос остаётся в доверии Фляре и её надёжности.
В конце концов, поднятие зеркала борды посредством проксирования её через Фляру тоже не очень честно по отношению к последней. Хотя такая практика имела место быть, пока кое-где не появилось хттпс с сертификатом LE.
No. 20656  
>>20655
Ты слишком lawful человек, если задумываешься о честности по отношению к этому крышевателю, подминающему под себя Всемирную паутину.
No. 20657  
>>20656
Если бы был lawful, то вообще не возникло бы идеи. Так я только за эксплуатацию корпораций.
No. 20663  
Mononoke Hime.png - (2.28MB, 1920×1040)
20663
>>20655

> Идея скорее в недобросовестном использовании предоставляемых Клаудфларой возможностей. А именно того, что они на своих серверах будут кешировать контент, слитый на их гейт. Опять же если я не Мугичкой поперёк прочитал.

> То есть можно заливать статику на сервер, скидывать через ИПФС в гейт Флары, держать до какого-то момента, пока контент не закешируется на их серверах, после чего удалять со своего. Вопрос остаётся в доверии Фляре и её надёжности.

Я не уверен, что это вообще можно называть недобросовестным использованием. Их гейт объявлен как предназначенный для показа контента из IPFS и притом кэширующий тот контент, так что делать то и другое никто не запрещает.

Другое дело, что и Cloudflare не обещает держать контент на их 150+ серверах неограниченно долго. Да они, небось, и не смогли бы, так как вряд ли их кэш способен целиком вместить всё содержимое файловой системы IPFS (летом прошлого года в файле https://cloudflare-ipfs.com/ipfs/QmWimYyZHzChb35EYojGduWHBdhf9SD5NHqf8MjZ4n3Qrr/Filecoin-Primer.7-25.pdf на тринадцатой странице было сказано, что число файлов в IPFS ещё тогда превысило пять миллиардов). Это не вопрос доверия к Cloudflare, а вопрос арифметики: каков средний размер файла в IPFS? — какой объём получится, если сперва помножить на пять миллиардов, а затем на вероятность попытки скачать файл именно через гейт Cloudflare (вероятность, возрастающую вместе с популярностью гейта по мере распространения свѣдѣній о нёмъ)?

Вот почему в предшествующих репликах я не рассматривал вопрос о стирании файла сразу после гейтования его на Cloudflare, а рассматривал только две альтернативы: «у админа под кроватью» (дешёвое централизованное хранение с необязательным аптаймом) и «у читателей» (ещё менее надёжное, зато децентрализованное, хранение, но полагающееся на распространённость употребления читателями на их компáх и самогó софта IPFS, и расширения IPFS Companion).

Если обе эти альтернативы представляются малопривлекательными, то можно ещё у Cloudflare по адресу https://developers.cloudflare.com/distributed-web/ipfs-gateway/connecting-website/ прочесть о третьем варианте: есть серверы, предлагающие хранение файлов в IPFS в качестве платной услуги. Среди них там упомянуты два: http://ipfsstore.it (который, по-видимому, от упоминания на Cloudflare сразу и лёг) и https://www.eternum.io (который не лёг и предлагает хранение в IPFS по цене 30 центов за гигабайт в месяц, что по нынешним временам означает рублей двадцать с копейками).

Я допускаю, впрочем, что этот последний вариант покажется ещё менее привлекательным (и даже грабительским), так как с калькулятором в руках кто угодно может сосчитать (а некоторые и без калькулятора, то есть устным счётом или вообще въ умѣ), что 30 центов за гигабайт означает 12 баксов за 40 гигабайтов, тогда как по адресу https://www.leaseweb.com/cloud/virtual-server можно арендовать сорокагигабайтовый VPS за пять евро (а это явно дешевле), после чего останется только самостоятельно поставить на него демон IPFS и запустить. Я привожу Leaseweb просто в качестве наиболее наглядного примера, так как для IP-адреса 410chan.org (95.211.122.44) https://ru.wikipedia.org/wiki/Обратный_просмотр_DNS выдаёт имя «hosted-by.leaseweb.com».
No. 20664  
410chan-spoiler.png - (7.12KB, 200×200)
20664
Если изложенное в реплике >>20663 покажется слишком сложным или порождающим невыносимые мýки выбора, то вдобавок я сейчас ещё раз напомню, что суть моего-то собственного предложения состояла не в том, чтобы сервер и администрация 410чана задумались над собственным идеалом сохранения статических файлов в IPFS, а в том только, чтобы наряду с публикацией файла на имиджборде существовала и возможность приложить к реплике IPFS-адрес от файла, заранее кем-то ужé опубликованного в IPFS.

Откуда такой адрес возьмётся? — нетрудно предположить (и предполагаю), что большинство таких публикаторов в качестве необходимого для P2P источника файла употребят, вероятно, либо установку IPFS на один из собственных многотерабайтных дисков (так как у типичного любителя аниме всегда есть ведь пара-тройка-другая многотерабайтников, не всѣ из которых забиты до конца, причём совокупная ёмкость таких отщипленных за ненадобностью остатков всегда будет больше того объёма, который администрация сайта сумеет централизованно арендовать), либо воспользуются подобными http://ipfs.stadja.net/upload/ интерфейсами для выкладывания файлов в IPFS, совершенно бесплатными, но зато нисколько не гарантирующими срок (и даже факт) хранения — а затем станут полагаться на то, что среди читателей 410чана отыщется достаточно пользователей IPFS Companion для того, чтобы файл сохранялся и у читателей столь же долго, сколь долго он остаётся реально нужным 410чановской публике.

Конечно, для таких файлов сайт 410чана, в общем случае, не станет создавать миниатюру, а оттого принуждён будет указать какую-нибудь общую на всех заглушку с надписью «IPFS». Сейчас такое кажется непривычным, но такое впечатление не будет существовать вечно; напротив, можно догадываться, что после устранения проблемы, по адресу https://bitbucket.org/Therapont/fbe-410/issues/8 обозначенной, на 410чане появятся заглушки спойлеров (пример прилагаю), после чего общественное сознание скоро привыкнет, что миниатюра может и не соответствовать содержанию файла.

Не могу совершенно исключать даже и того, что в дальнейшем можно будет напилить и некий цикл «скачать ➡️ миниатюризировать ➡️ стереть скачанное, начать использовать миниатюру» для тех из хранимых в IPFS файлов, которые не превосходят некоторого доступного на сервере объёма, необходимого для краткого сохранения их после скачивания из IPFS через гейт.
No. 20665  
>>20663
Жаль, что нет точных сроков или алгоритма выбора удаляемых из кеша ИПФС Флары, но если предположить самый вероятный из, то, скорее всего, большие файлы будут храниться совсем недолго, а вот небольшие — достаточно. Насколько помню, те же сайты, которые задудосили со стороны хоста, если Флара закешировала, то с месяц-два могла одна версия висеть. Не знаю, как сейчас, но можно выявить экспериментным путём сей алгоритм хранения и удаления, после чего можно написать скрипт, что будет дёргать файлы из кеша в момент протухания на Фляре, ждать, пока снова не закеширует и обратно удалять.
No. 20666  
сотона.png - (101.51KB, 1459×657)
20666
>>20665

А вот это ужé опасно к https://en.wikipedia.org/wiki/Tragedy_of_the_commons приближается.
No. 20667  
>>20666
Вот потому и говорил, что вовсе не lawful. В конце концов, китайцы убивают много более достойные ресурсы альтруистов, желавших сделать великое добро для человечества, терабайтами трафика, а тут считай корпорация с некислой монетизацией. Это как паразитировать на Гугле — если и заметят маленький зуд с их масштабами, то очень нескоро, как было с хостившими на Драйве порнуху годами.
No. 20671  
Dlx-MAsU8AAscWv_jpg:large.jpg - (195.69KB, 1500×1125)
20671
Одновременно со вчерашними и сегодняшними переделками на сервере, Автобус двинул на PHP7.
No. 20675  
session upload progress.gif - (1.64MB, 1920×1200)
20675
>>20671

А в какой конфигурации?

Например, позволит ли она на основе https://secure.php.net/manual/en/session.upload-progress.php растущую полоску процента закачки напиливать, или там между браузером и PHPшным движком поставлено сёрверное кэширование закачиваемого файла, только затем в PHP начинающего поступать?
No. 20676  
DNpTFymUMAIgL8M.jpg - (425.14KB, 2048×906)
20676
>>20675 В минимальной, практически дефолтной, что на какое-то время сломало загрузку больших файлов.
No. 20687  
IPFS 3D ice text 2016-05-09.png - (36.57KB, 512×512)
20687
Сегодня я возвратился к идее об употреблении IPFS и записал по адресу https://www.pscp.tv/w/1mnxeolgakoGX стрим с рассуждениями и аргументами об этом вопросе длиною 83 минуты. Заинтересованных прошу посмотреть.

Сознавая возможное недостаточное визуальное качество приёма потокового вещания с сайта Periscope, прилагаю альтернативную версию в высоком качестве (командою «youtube-dl https://www.pscp.tv/w/1mnxeolgakoGX» скачанную из Periscope же) на IPFS-гейте Cloudflare в подкаталоге https://cloudflare-ipfs.com/ipfs/QmfYpqAmErJhEtBojjqvUoaemgLrVBZPQNtc53PG6bFp9d (192 660 килобайтов).

Даю ссылку на подкаталог, так как прямую ссылку на сам видеофайл дать не могу: движок 410чана воспринимает адрес https://cloudflare-ipfs.com/ipfs/QmfYpqAmErJhEtBojjqvUoaemgLrVBZPQNtc53PG6bFp9d/Mithgol - Стрим про %D
0%BF%D0%B5%D1%80%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%D1%8B%20%D0%B2%D0%BD%D0%B5%D0%B4%D1%80%D0%B5%D0%BD%D0%B8%D1%8F%20IPFS%20%D0%BD%D0%B0%20410%
D1%87%D0%B0%D0%BD%D1%A3.mp4 как чрезмерно длинный и расчленяет его до неупотребимости, как вы и сами можете видеть.

(仕方がない。)
No. 20692  
>>20671

Одно из двух: или движок FBE пошёл под PHP7 без переделки, или содержимое репозитория больше не отображает настоящее состояние исходного кода.

Первый из этих вариантов необъяснимо противоречит реплике https://410chan.org/dev/arch/res/17371.html#19039

Второй из этих вариантов не радует, так как не ясно, есть ли смысл сочинять pull requests со значительным шансом на безрадостные merge conflicts.
No. 20710  
1149684946054.png - (6.69KB, 384×384)
20710
>>20692
Теоретически, вполне может быть, что необходимые изменения уже были встроены в FBE до этого момента. На практике, я не проверял.
401 сообщений пропущено. Показаны 100 первых сообщений.
Удалить сообщение []
Пароль  
[Mod]