Тут в анибублядский был гайд. Не в последнем, его оп - хуй, а в предпоследнем есть. >>58165

https://2channel.moe/b/res/58165.html

>>734 (OP)
Я делаю так.
1) Качаю здесь https://en.savefrom.net/ или здесь https://www.onlinevideoconverter.com/ в mp4
2) Конвертирую:
ffmpeg -i 1.mp4 -vcodec libvpx -acodec libvorbis "1.webm"
. Такой способ ужимает меньше, чем размер исходника.
3) Ставлю превью.

>>737
>ffmpeg -i 1.mp4 -vcodec libvpx -acodec libvorbis "1.webm"
Как этим пользоваться?

>>738
Это нужно из командной строки запускать.

>>734 (OP)
https://www.youtube.com/user/JavaNNiMON/videos
Здесь человек ясно и понятно объясняет основы.

>>738
Скачай ffmpeg.

>>739
>>740
>>741
Как сложно, будто программированием занимаюсь или взломом пентагона

>>743
Уря получилось, спасибо анончики

Фига у вас баннер крутой появился, на теме арисучан потрясно выглядит.

>>744
А теперь замени устаревший "-vcodec libvpx" на "-c:v libvpx-vp9 -crf 30 -b:v 0" (30 надо уменьшать для увеличения качества и увеличивать для уменьшения размера) и ещё добавь "-aq 2.9" (2.9 точно так же можно уменьшать/увеличивать), по умолчанию libvorbis проде бы cbr использует, что не есть хорошо.

Можно прям bat-файл создать, где заместо имени файла прописать %1, тогда можно будет прям мышкой перетягивать файлы на батник.

>>747
Для чего нужен -aq? Что он делает?

>>748
audio quality или как там это пишется. Да, я кстати перепутал, там шкала прямая в отличие от crf.
0 - минимум, что-то порядка 50 кб/с для двухканального ogg/vorbis (по качеству что-то около mp3 на 150 кб/с)
10 - максимум, что-то порядка 450 кб/с
В действительности в каких угодно наушниках всё что угодно с aq больше 3 я не в состоянии отличить от lossless оригинала во флеке (чтобы кто-то другой отличил даже на своём компьютере со своими аудиопричиндалами я тоже не видел). И для большинства аудиозаписей без специальных звуков отличить aq 0 от оригинала тоже довольно затруднительно.

Но вообще многие сейчас libopus запускают, и слепые тесты в каких-то исследованиях показывают что opus лучше, чем vorbis. Я просто адепт vorbis-а.

>>749
>Но вообще многие сейчас libopus запускают, и слепые тесты в каких-то исследованиях показывают что opus лучше, чем vorbis.
Тут фишка в том, что opus работает только частотой дискретизации 48к и записи в 44.1к принудительно преобразует в 48к, что сказывается на качестве в худшую сторону. В каком-то треде тут уже это разбирали. А вообще да, эффективен, позволяет сохранить отличное качество звука при минимальном битрейте.

>>750
>opus работает только частотой дискретизации 48к
Вот этого я тоже не понял. Все cd диски с музыкой в 44.1. Какая ему вообще разница - он последовательности столбиков сохраняет, которую можно с любой частотой воспроизводить. Всего то нужно поправку на особенности слуха транспонировать на более высокие/низкие частоты.

>В каком-то треде тут уже это разбирали
Угу, возможно это я там и оглашал эту идею. Потом ещё пост написал в оправдание 48 кгц.
>что сказывается на качестве в худшую сторону
А кто-то это проверял? По идее, если я сейчас одну аудиозапись 40 раз передискретизирую в произвольную частоту от 44 до 50 и потом верну обратно - ничего не поменяется. Это же не алгоритм растяжения изображения из пеинта. В действительности он считает амплитуды первых 20к частот и потом выставляет столбики для другой частоты, из которых можно получить те же самые 20к амплитуд. То есть на каждом шаге никаких потерь не должно быть. Не буду говорить за opus и его алгоритмы, конечно, но в теории это так работает, если я правильно в ней разобрался.

>>751
>А кто-то это проверял? По идее, если я сейчас одну аудиозапись 40 раз передискретизирую в произвольную частоту от 44 до 50 и потом верну обратно - ничего не поменяется.
Поменяется. При передискретизиции может теряться часть данных. Примерно, как это происходит при изменении размера изображения. Если картинку растянуть до большего разрешения, часть данных потеряется, а если вернуть ее к старому разрешению, ее качество будет хуже, чем у изначальной.


(Хм, я могу редактировать чужие посты? Интересно.)

>>752
>Примерно, как это происходит при изменении размера изображения
С помощью фурье преобразования возможно в соответствии 200 столбикам поставить 200 амплитуд, верно? Без каких-либо потерь разложить столбики по ортогональному базису частот. И потом точно так же собрать столбики при необходимости. Ошибки будут только в вычислениях (порядка восьмого знака после запятой даже при использовании 4-байтовых float, что просто смешно по сравнению с 16 битным звуком).
Если я увеличу частоту до 300 (поставлю их нулевыми), и превращу в столбики (то есть растягивать буду в спектральном представлении, а не во временном), то потом я смогу из 300 обратно получить 200 своих частот и 100 нулевых. Соответственно, если я не понижаю частоту ниже исходной - никаких потерь не будет. Что не так?
Давай, если не понятно/не согласен, то сейчас я пойду сгенерирую нужные сигналы/картинки + проверю на реальном аудиофайле, расставим все точки над передискретизицией.

>>753
Спорить не стану, я скорее с теоретической стороны смотрел, вполне возможно, я не прав. А вообще, если кто в теме, было бы интересно знать, передискретизация в большую сторону в действительности искажает исходный вариант или нет?

>>737
> ffmpeg -i 1.mp4 -vcodec libvpx -acodec libvorbis "1.webm"
В результате получается говно с квадратами и лишним весом.

Во первых, ты используешь устаревший формат VP8, который не позволяет упаковывать видео эффективно. Уже давно везде поддерживается VP9, так что в использовании VP8 нет смысла. Чтобы использовать vp9, нужно убрать из строчки «-vcodec libvpx», тогда для формата webm по умолчанию будет использоваться кодек libvpx-vp9. Также уже доступен libaom-av1, но чтобы им пользоваться сейчас, нужно много терпения или возможность оставлять кодирование на ночь.

Во вторых, ты не указываешь настройки контроля качества, из-за чего используются дефолтные 200кбит/с, что портит картинку. Для небольших роликов следует отключить ограничение битрейта и указывать уровень качества: «-b:v 0 -crf 30». Для больших нужно считать битрейт таким образом, чтобы результат попал точно в лимит:
битрейт_видео = 20480KiB × 8bit ÷ длительность_в_секундах – битрейт_звука
и указывать его: «-b:v 200k».

В третьих, ты кодируешь одним проходом. Из-за этого кодек не использует часть своих фич, в т.ч. не может оптимально расставить ключевые кадры, из-за чего картинка на твоих вебмах периодически рассыпается на квадраты. Нужно запускать команду кодирования дважды, указывая в ней сначала «-pass 1', потом '-pass 2».

В четвёртых, ты используешь устаревший аудиокодек libvorbis. Используемый по умолчанию libopus во всех отношениях лучше, на низких битрейтах разница вообще огромна. Чтобы его заюзать, достаточно убрать «-acodec libvorbis».

Все перечисленные параметры следует ставить перед именем выходного файла, это важно.

>>746
Низкокачественных вебм полно в тредах >>/b/37857 (OP) и >>/b/37857 (OP). Во втором вообще какой-то лютый пиздец не только по качеству, но и по содержанию. Пойдём отрубать руки?

>>750
Потери от передискретизации по сравнению с потерями при сжатии ничтожно малы. К тому же большинство потребительских звуковух работают не на 44100Гц, а на кратных 48КГц частотах, так что передискретизация используется в любом случае.

>>754
> передискретизация в большую сторону в действительности искажает исходный вариант или нет?
Если в исходнике присутствует какая либо интерференция между сигналом и частотой дискретизации, то искажения будут. Возьми любой скриншот с пиксельным шрифтом или пиксельартом и увеличь его в 1.2 раза — картинку в лучшем случае размоет, а в худшем — обезобразит, рандомно улолщив линии.

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

>>756
>и указывать его: «-b:v 200k».
сbr проигрывает crf режиму во всех случаях. Если отконвертировать в 18 мб в crf режиме - оно всё равно будет выглядеть лучше, чем видео с b:v 200k ровно в лимит при прочих равных.

>возьми любой скриншот с пиксельным шрифтом или пиксельартом и увеличь его в 1.2 раза
Ещё раз повторю, там принципиально другой алгоритм растяжения. Картинку всё-равно замылит, но набор частот сохранится и если её уменьшить до исходного размера - она будет один в один такой же (если сохранять промежуточные не в 8 бит). Слух воспринимает частоты, потому он не воспринимает это безобразие. Глаз тоже воспринимает частоты, но это перестаёт работать если настолько увеличить пиксели.
Хочешь, возьму одномерную картинку с полосами и попробую это продемонстрировать? Как она расплывётся в молоко при последовательном увеличении размеров с шагом в 1 пиксель и как потом соберётся снова при возвращении?

>>758
> crf режим
У libvpx / libvpx-vp9 / libaom нет такого, это результат прикручивания к ним скотчем крутилки от x264.
Есть режимы cbr, vbr, constant quality и constrained quality. Предполагаю, что ты имел в виду constant quality.

> Если отконвертировать в 18 мб в crf режиме - оно всё равно будет выглядеть лучше, чем видео с b:v 200k ровно в лимит при прочих равных.
Но подобрать параметр качества для достижения нужного размера сходу принципиально невозможно, нужно каждый раз идти путём проб и ошибок.

Можно пойти по компромиссному пути и использовать режим constrained quality (это когда ffmpeg'у указываешь и битрейт, и crf): тогда и качество может быть выше, чем при указании только битрейта, и приемлемый результат скорее всего получится с первой попытки.

> там принципиально другой алгоритм растяжения.
Но алгоритмов масштабирования картинок существует уйма. Алгоритмов передискретизации звука мне известно меньше, но там тоже есть выбор.

> Хочешь, возьму одномерную картинку с полосами и попробую это продемонстрировать? Как она расплывётся в молоко при последовательном увеличении размеров с шагом в 1 пиксель и как потом соберётся снова при возвращении?
Интересно будет посмотреть, в особенности при применении разных алгоритмов масштабирования.

>>761
Что-то вообще не понял эти графики. Что на осях их координат? Что показывают толстая и тонкая линии?

>>762
Толстая - изначальный "сигнал" из 10 столбиков. Он просто рисуется в виде ломаной, а не в виде столбиков. Тонкая - во что он превращается, если пересамплить в 1000 столбиков разными алгоритмами. Соответственно на нижней оси координата или время, как тебе угодно.

>>747
>-aq 2.9
Даёт что полезного?

>>747
> по умолчанию libvorbis проде бы cbr использует, что не есть хорошо.
Это было ошибкой. Чтобы сделать ffmpeg'ом CBR при помощи libvorbis'а, надо зажать битрейт между -minrate:a и -maxrate:a.

Ещё одной ошибкой было предположение об улучшении качества при указании -q:a вместо битрейта: это лишь другой способ указания битрейта, приводящий к тому же результату; управления шириной потока по коэффициенту квантования libvorbis (как и другие известные мне аудиокодеки) не имеет.

>>766
Указывает битрейт согласно таблице http://wiki.hydrogenaud.io/index.php?title=Recommended_Ogg_Vorbis#Recommended_Encoder_Settings. Всё.

>>772
>Ещё одной ошибкой было
Да? Ну, может быть, значит я врал всем и себе. Почему-то там битрейт до 50 снижается через aq иногда.
Когда-то давно через какой-то конвертер с gui конвертировал музыку и там режим с качеством давал другие результаты, нежели режим с битрейтом (может быть там это тоже являлось подобной обёрткой). Наверное из-за него я и подумал, что ffmpeg тоже имеет какие-то разные режимы.

>>775
> Почему-то там битрейт до 50 снижается через aq иногда.
Он и через -b:a может снижаться: и то, и другое — сжатие в режиме ABR, с той только разницей, что с -b:a можно ещё указывать -minrate:a и -maxrate:a. Если же их не указывать, то результат получается идентичен до байта:
~ » ffmpeg -loglevel error -i audio/IOSYS\ -\ Doutei\ Korose.mp3 -c:a libvorbis -b:a 128k -f md5 -
MD5=3bf4e05ed407249ab17838976becd82d
~ » ffmpeg -loglevel error -i audio/IOSYS\ -\ Doutei\ Korose.mp3 -c:a libvorbis -q:a 4 -f md5 -
MD5=3bf4e05ed407249ab17838976becd82d

>>760
> сbr проигрывает crf режиму во всех случаях.
Здесь ещё ошибка: libvpx и libaom при указании -b:v как и libvorbis делают не CBR, а ABR. Аналогично, CBR можно получить, ограничив частоту гуляния битрейта при помощи -minrate:v и -maxrate:v, webm for retards это зачем-то делает по умолчанию.

>>763
Спасибо. А что есть «спектральное представление»? По сути — временное увеличение частоты дискретизации сигнала на порядок, после чего перенос его на новую частоту, отличающуюся от исходной на единицу?

>>780
> никто в здравом уме не будет использовать жёсткое ограничение через minrate/maxrate
Проблема в том, что не все находятся в здравом уме. Перемотай >>757 на 2:30 и посмотри там на нижнюю строчку — они там именно в CBR кодируют с этим самым жёстким ограничением!

Поэтому CBR и ABR/VBR путать не следует, и обзывание управления битрейтом через -b:v CBR'ом — ошибка. Ошибка, которую и я заметил далеко не сразу, а не слишком разбирающийся в матчасти человек вообще проглотит и выдаст перлы вроде того, что на том обучающем видео.

> По какой причине его нельзя называть crf-режимом
Например, по причине того, что этот параметр используется в двух режимах — constant quality (который действительно аналогичен режиму crf x254/x265) и constrained quality (которого в x264/x265 нет).

Вообще не вполне понятна мотивация разработчиков ffmpeg, которые к параметру libvpx'а cq-level привинтили не очевидное -q:v, а эксклюзивный для x264/x265 -crf, который иначе используется (заменяет собой указание битрейта и конфликтует с ним) и имеет другой диапазон значений.

Чем записываете отрезки видосов? Например аниме, не охото качать всю серию целиком

>>789
>Чем записываете отрезки видосов?
Если это файл в сети (или hls стрим, который почти во всех твоих аниме-проигрывателях) - то через ffmpeg. Командой вида: ffmpeg -ss 6:6:0.234 -i "*.m3u8" -c copy -t 141 -bsf:a aac_adtstoasc 6.mkv можно вырезать отдельную часть не скачивая всё. Он не совсем точно обрезает и потом приходится ещё пилочкой чуть-чуть доводить до ума.
Через obs если это игра или ещё что-то, что нельзя вытянуть без такого костыля. Или если лень.

>>791
Возможно, mpv с его поддержкой youtube-dl тут будет удобнее: если youtube-dl поддерживает видеохостинг, то достаточно указать ссылку на страницу с видео.
mpv --oac=copy --ovc=copy -o out.mkv --start=начало --length=длительность https://…

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

>>789
На smotret-anime-365 через плеер можно вырезать отрезок.

>>734 (OP)
ffmpeg.

>>926
Спасибо, капитан.

>>1004
Слишком большое разрешение и коэффициент качества. У меня даже видео это тормозит, обычно я такие даже не открываю. У большинства даже нет таких мониторов, в каком разрешении это видео.

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

>>1016
Почти минимум же.
Нет, проблема именно с этим видео. Другое аналогичного разрешения хорошо себя чувствует, кодируется/декодируется значительно эффективнее. А тут, я не знаю что, vp9 просто вешается. Причём уже второй раз на такое наталкиваюсь, и второй раз именно с этой игрой.

>>734 (OP)
возьми https://www.xmedia-recode.de/

>>2225
>а ставить пакетным менеджером из репозиториев своих дистрибутивов
Старые могут быть. Не все оперативно обновляется. Для винды так вообще не актуально.

>>2226
> Старые могут быть.
Не всегда нужна свежая: например, в libvpx и libopus давно не было значительных обновлений. Если же хочется самый свежак, то сборки всяких zeranoe — вряд ли оно самое: свежий там только сам ffmpeg, а библиотеки сжатия он использует стабильных версий.
> Для винды так вообще не актуально.
Для неё есть msys2 с репозиторием и пакетным менеждером.

>>2225
20200403-52523b6, 4.2.2 чем эти версий отличаются?

>>2228
4.2.2 — стабильный релиз, в нём больше исправлений ошибок; 52523b6 — срез master-ветки, в нём больше новых фич.
https://git.ffmpeg.org/gitweb/ffmpeg.git/blobdiff/n4.2.2..52523b6:/Changelog

Для сжатия видео используют ffmpeg, а для картинок какая прога нужна?

>>2416
Можешь тоже использовать ffmpeg, он умеет. Либо ImageMagick/GraphicsMagick, если нужно больше функционала. Есть ещё мелкие утилиты для оптимизации без потерь вроде optipng и jpegoptim.

>>2416
Из imagemagick: convert img0.jpg -quality 0...100 img1.jpg
Можешь объеденить имейджмаджик и ффмпег и сделать видеоредактор в скриптах.

>>2417
>>2418
Ого спасибо

https://github.com/Kagami/boram/releases

>>2422
Как его скомпилировать? Необходимо ли для этого пускать систему сборки в сеть, или она может довольствоваться зависимостями из установленных в ОС?

>>2423
Там же бинарники есть, зачем компилировать.

>>2424
Мне не нужны бинарники, я им не доверяю. Хочу собрать из исходников.

Добавить превью к шебм без текстового редактора и тайминга возможно?

>>2572
Да, см. скрипт >>/b/67541.

>>2580
add-preview -s время_кадра файл.webm

Разве ключ -s не указывает разрешение файла?
Тогда получается
ffmpeg -i q.webm add-preview -i picture.webm -s 0.01 q1.webm?

>>2581
> ffmpeg -i q.webm add-preview -i picture.webm -s 0.01 q1.webm?
Ты что-то совсем не то написал. add-preview — это скрипт, который сам запускает ffmpeg. Этот скрипт выполняется с помощью шелла zsh, что написано в его заголовке (т.н. shebang). В >>/b/67786 показан пример его использования.

Если ты под unix-подобной ОС, то ставь zsh, делай скрипт исполнимым и запускай. Если под щиндовсом — ставь msys2, в нём ставь zsh и ffmpeg и из него запускай скрипт.

> Разве ключ -s не указывает разрешение файла?
Ключ -s ffmpeg'а, а не этого скрипта.

>>2584
А я могу zsh поставить на cmd? у меня щиндовс

>>2585
msys2 смотрел? Кажется, zsh там из коробки даже идёт с как-то настроенным интерактивным режимом.

111