Главная | Настройки | NSFW
Тема:
Доски


[Ответить в тред] Ответить в тред

[Назад] [Обновить тред] [Вниз] [Каталог] [ Автообновление ] 42 / 8 / 12

Eto No.734
152fb38efdd6b0f[...].jpg (105 KB, 1280x720)
Дайте гайд, как конвертировать видео в шебм, я чота конвертирую онлайн сервисами а их масса увеличивается в два раза
Anonymous No.735
Тут в анибублядский был гайд. Не в последнем, его оп - хуй, а в предпоследнем есть. >>58165
Anonymous No.736
https://2channel.moe/b/res/58165.html
Anonymous No.737
>>734 (OP)
Я делаю так.
1) Качаю здесь https://en.savefrom.net/ или здесь https://www.onlinevideoconverter.com/ в mp4
2) Конвертирую:
ffmpeg -i 1.mp4 -vcodec libvpx -acodec libvorbis "1.webm"
. Такой способ ужимает меньше, чем размер исходника.
3) Ставлю превью.
Anonymous No.738
>>737
>ffmpeg -i 1.mp4 -vcodec libvpx -acodec libvorbis "1.webm"
Как этим пользоваться?
Anonymous No.739
>>738
Это нужно из командной строки запускать.
Anonymous No.740
>>734 (OP)
https://www.youtube.com/user/JavaNNiMON/videos
Здесь человек ясно и понятно объясняет основы.
Anonymous No.741
>>738
Скачай ffmpeg.
Anonymous No.742
>>739
>>740
>>741
Как сложно, будто программированием занимаюсь или взломом пентагона
Eto No.743
34.webm (783 KB, 480x480, 00:00:23)
test
Anonymous No.744
>>743
Уря получилось, спасибо анончики
Anonymous No.745
Фига у вас баннер крутой появился, на теме арисучан потрясно выглядит.
Anonymous No.746
webm-encoding-g[...].webp (323 KB, 2048x2500)
>>734 (OP)
Если будешь гадить низкокачественными webm, мы найдём тебя и отрубим руки.
Вот краткий экскурс в ffmpeg с инструкцией по установке: https://github.com/pituz/webm-thread/wiki/webm-encoding
Вот вики: https://trac.ffmpeg.org/wiki/WikiStart
Тебе нужна вот эта страница: https://trac.ffmpeg.org/wiki/Encode/VP9
Если не хочешь возиться с командной строкой, то существуют графические оболочки. Исходники ищи в лучшем качестве и не кодируй что-либо с постоянным битрейтом. Отдельный тред, думаю, создавать не стоило, можно было просто обратиться к анимублядям.
Anonymous No.747
>>744
А теперь замени устаревший "-vcodec libvpx" на "-c:v libvpx-vp9 -crf 30 -b:v 0" (30 надо уменьшать для увеличения качества и увеличивать для уменьшения размера) и ещё добавь "-aq 2.9" (2.9 точно так же можно уменьшать/увеличивать), по умолчанию libvorbis проде бы cbr использует, что не есть хорошо.

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

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

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


(Хм, я могу редактировать чужие посты? Интересно.)
Пост отредактировал Anonymous
Anonymous No.753
>>752
>Примерно, как это происходит при изменении размера изображения
С помощью фурье преобразования возможно в соответствии 200 столбикам поставить 200 амплитуд, верно? Без каких-либо потерь разложить столбики по ортогональному базису частот. И потом точно так же собрать столбики при необходимости. Ошибки будут только в вычислениях (порядка восьмого знака после запятой даже при использовании 4-байтовых float, что просто смешно по сравнению с 16 битным звуком).
Если я увеличу частоту до 300 (поставлю их нулевыми), и превращу в столбики (то есть растягивать буду в спектральном представлении, а не во временном), то потом я смогу из 300 обратно получить 200 своих частот и 100 нулевых. Соответственно, если я не понижаю частоту ниже исходной - никаких потерь не будет. Что не так?
Давай, если не понятно/не согласен, то сейчас я пойду сгенерирую нужные сигналы/картинки + проверю на реальном аудиофайле, расставим все точки над передискретизицией.
Пост отредактировал Anonymous
Anonymous No.754
>>753
Спорить не стану, я скорее с теоретической стороны смотрел, вполне возможно, я не прав. А вообще, если кто в теме, было бы интересно знать, передискретизация в большую сторону в действительности искажает исходный вариант или нет?
Anonymous No.755
2019-06-30_18-3[...].webm (238 KB, 1300x550, 00:00:03)
>>754
Ну, в ffmpeg разницы вроде бы как нет.
Я сделал страшный батник вида (частота прыгает от 8000 до 48000, при этом акцент в сторону низких значений):
...
ffmpeg -i 3127.wav -vn -dn -sn -map_metadata -1 -ar 14913 -acodec pcm_s24le "3128.wav"
del 3127.wav
ffmpeg -i 3128.wav -vn -dn -sn -map_metadata -1 -ar 20749 -acodec pcm_s24le "3129.wav"
del 3128.wav
ffmpeg -i 3129.wav -vn -dn -sn -map_metadata -1 -ar 11285 -acodec pcm_s24le "3130.wav"
del 3129.wav
...

И разницы между 100 поколением и 3600 (на 4000 чуть-чуть не хватило памяти) на частотах меньше 3400..3500 (в соответствии с теоремой котельникова должно быть ровно 4000 вообще-то) почти нет. На глаз (картинка - плавное переключение фурье-образов) и на слух - я переключаю два трека в аудиосити не останавливая воспроизведения и не могу ощутить момент переключения. То есть при преобразованиях от 44.1 до 48 ни одна из частот ниже 20кгц не пострадает, по видимому. Даже если у меня худшие в мире наушники и худший слух, то ошибку за одну передискретизацию уж точно можно не брать в рассчёт, если я за 3600 не заметил.
Anonymous No.756
>>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 раза — картинку в лучшем случае размоет, а в худшем — обезобразит, рандомно улолщив линии.

Но при увеличении хорошим фильтром фотографии разницы ты не заметишь. Полагаю, к музыке это тоже относится.
Anonymous No.757
WebM for Retard[...].webm (7619 KB, 1280x648, 00:05:39)
Anonymous No.758
>>756
>и указывать его: «-b:v 200k».
сbr проигрывает crf режиму во всех случаях. Если отконвертировать в 18 мб в crf режиме - оно всё равно будет выглядеть лучше, чем видео с b:v 200k ровно в лимит при прочих равных.

>возьми любой скриншот с пиксельным шрифтом или пиксельартом и увеличь его в 1.2 раза
Ещё раз повторю, там принципиально другой алгоритм растяжения. Картинку всё-равно замылит, но набор частот сохранится и если её уменьшить до исходного размера - она будет один в один такой же (если сохранять промежуточные не в 8 бит). Слух воспринимает частоты, потому он не воспринимает это безобразие. Глаз тоже воспринимает частоты, но это перестаёт работать если настолько увеличить пиксели.
Хочешь, возьму одномерную картинку с полосами и попробую это продемонстрировать? Как она расплывётся в молоко при последовательном увеличении размеров с шагом в 1 пиксель и как потом соберётся снова при возвращении?
Anonymous No.759
>>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 пиксель и как потом соберётся снова при возвращении?
Интересно будет посмотреть, в особенности при применении разных алгоритмов масштабирования.
Anonymous No.760
hlam.png (1267 KB, 1120x3580)
>>759
>Предполагаю, что ты имел в виду constant quality.
Я имел ввиду -b:v 0 -crf 30, очевидно же.

>в особенности при применении разных алгоритмов масштабирования.
Слева график, как 10 столбиков растягивают до тысячи (для иллюстрации), справа картинка, где одномерная полоска расширяется (с шагом в 2 пикселя) и "совмещается" обратно. Всё что смог придумать. Не знаю есть ли ещё что интересное, но насколько я понял ничего интересного не будет, только мыло.
Можно сколько угодно увеличивать размеры в спектральном представлении и оно сохраняет чёткость. Даже если прогнать её 20 тысяч раз - ошибка -5 порядка. Но это если в double держать, если сохранять в 16-бит, то расплывается за сотню итераций или около того.

>Алгоритмов передискретизации звука мне известно меньше, но там тоже есть выбор
Пролистал статью на википедии про эту фигню, там большая часть алгоритмов изначально с потерями, в угоду быстродействию или потому что так работает аналоговая электроника. На такой картинке оно всё сразу поплывёт, потому что сигнал максимально контрастный. Можно сразу любой оконный фильтр выкидывать. Угу низкия частоты он сохраниет, но с этим и кубические функции справляются (широкие мыльные полосы почти перестают размываться дальше некоторой степени). Собственно говоря, я не могу придумать больше никаких очевидных или не очевидных алгоритмов увеличения без потерь. Это нужно найти какие-то ещё ортогональные функции или другой вид исходного "изображения", в котором размер теряет смысл - так что это можно изобрать на любом размере. Ортогонализовать то можно что угодно, хоть простой шум - только он ещё должен собственно говоря увеличивать, а не просто кодировать в своём шуме исходный сигнал.
Anonymous No.761
image.png (34 KB, 590x467)
>>760
Ну и последний график можно заменить, наверное.
Понятно почему так произошло, но не понятно стоило ли выравнивать другие функции - может быть это стало причиной дополнительных шумов или ещё на что-то повлияло. Но вроде бы не повлияло - переделаю и напишу, если вдруг.
Пост отредактировал Anonymous
Anonymous No.762
>>761
Что-то вообще не понял эти графики. Что на осях их координат? Что показывают толстая и тонкая линии?
Anonymous No.763
>>762
Толстая - изначальный "сигнал" из 10 столбиков. Он просто рисуется в виде ломаной, а не в виде столбиков. Тонкая - во что он превращается, если пересамплить в 1000 столбиков разными алгоритмами. Соответственно на нижней оси координата или время, как тебе угодно.
Anonymous No.766
>>747
>-aq 2.9
Даёт что полезного?
Anonymous No.772
>>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. Всё.
Anonymous No.775
>>772
>Ещё одной ошибкой было
Да? Ну, может быть, значит я врал всем и себе. Почему-то там битрейт до 50 снижается через aq иногда.
Когда-то давно через какой-то конвертер с gui конвертировал музыку и там режим с качеством давал другие результаты, нежели режим с битрейтом (может быть там это тоже являлось подобной обёрткой). Наверное из-за него я и подумал, что ffmpeg тоже имеет какие-то разные режимы.
Anonymous No.776
>>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
Anonymous No.777
>>760
> сbr проигрывает crf режиму во всех случаях.
Здесь ещё ошибка: libvpx и libaom при указании -b:v как и libvorbis делают не CBR, а ABR. Аналогично, CBR можно получить, ограничив частоту гуляния битрейта при помощи -minrate:v и -maxrate:v, webm for retards это зачем-то делает по умолчанию.
Anonymous No.778
>>763
Спасибо. А что есть «спектральное представление»? По сути — временное увеличение частоты дискретизации сигнала на порядок, после чего перенос его на новую частоту, отличающуюся от исходной на единицу?
Anonymous No.780
Снимок.PNG (211 KB, 1312x602)
>>777
А вот здесь уже точно не ошибка, зануда ты эдакая. Само собой я имел ввиду простое указание битрейта через "-b:v" и "-b:v 0 -crf 30" как альтернативу, что было указано в виде конкретных параметров. Average Bitrate и Constant Quality, если тебе так угодно. Зачем вообще откапывать эти названия, если никто в здравом уме не будет использовать жёсткое ограничение через minrate/maxrate, да и про использование гибридного "Constrained Quality" я тоже что-то ничего не слышал.

>У libvpx / libvpx-vp9 / libaom нет такого, это результат
Там же даже написано ">similar to CRF in the x264 encoder".
По какой причине его нельзя называть crf-режимом, если это нельзя спутать с каким бы то ни было режимом и такое описание однозначно говорит о режиме, который имеется ввиду? Теоретики чёртовы.


>>778
Я не знаю что это такое и как называется, у нас тут адепт математики с точными названиями. Вот из аудиосити пример, то что сверху я называю спектральным представлением, а то что снизу - временным. Потому что одно число в спектральном (частотном) представлении отвечает определённой частоте, а одно число во временном отвечает конкретному моменту времени. Но ещё раз повторю, что скорее всего это совсем не спектральное представление и на самом деле это нужно называть совсем по другому.
Anonymous No.782
>>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, который иначе используется (заменяет собой указание битрейта и конфликтует с ним) и имеет другой диапазон значений.
Anonymous No.789
Чем записываете отрезки видосов? Например аниме, не охото качать всю серию целиком
Anonymous No.791
>>789
>Чем записываете отрезки видосов?
Если это файл в сети (или hls стрим, который почти во всех твоих аниме-проигрывателях) - то через ffmpeg. Командой вида: ffmpeg -ss 6:6:0.234 -i "*.m3u8" -c copy -t 141 -bsf:a aac_adtstoasc 6.mkv можно вырезать отдельную часть не скачивая всё. Он не совсем точно обрезает и потом приходится ещё пилочкой чуть-чуть доводить до ума.
Через obs если это игра или ещё что-то, что нельзя вытянуть без такого костыля. Или если лень.
Anonymous No.793
>>791
Возможно, mpv с его поддержкой youtube-dl тут будет удобнее: если youtube-dl поддерживает видеохостинг, то достаточно указать ссылку на страницу с видео.
mpv --oac=copy --ovc=copy -o out.mkv --start=начало --length=длительность https://…

А вообще смотреть онеме через браузер — себя не уважать, имхо. Отсутствие временной интерполяции и дебандинга в плеере, чрезмерный нагрев процессора, лаги, необходимость бороться с рекламой, обычно пожатая каким ноги видеодорожка, зависимость от работы интернет-соединения и сайта при просмотре — целый букет недостатков. Вариант для максимум нищебродов, короче.
Anonymous No.834
>>789
На smotret-anime-365 через плеер можно вырезать отрезок.

[Назад] [Обновить тред] [Вверх] [Каталог] [ Автообновление ]
42 / 8 / 12

[Ответить в тред] Ответить в тред

Ответ в тред No.734
15000
Файлы. Макс объем: 20 MB, макс кол-во файлов: 4

Ответ в тред No.734X
15000
Файлы. Макс объем: 20 MB, макс кол-во файлов: 4
Кликни/Брось файл/ctrl-v
НастройкиX
X
Избранное
Топ тредов