>>744 А теперь замени устаревший "-vcodec libvpx" на "-c:v libvpx-vp9 -crf 30 -b:v 0" (30 надо уменьшать для увеличения качества и увеличивать для уменьшения размера) и ещё добавь "-aq 2.9" (2.9 точно так же можно уменьшать/увеличивать), по умолчанию libvorbis проде бы cbr использует, что не есть хорошо.
Можно прям bat-файл создать, где заместо имени файла прописать %1, тогда можно будет прям мышкой перетягивать файлы на батник.
>>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 Спорить не стану, я скорее с теоретической стороны смотрел, вполне возможно, я не прав. А вообще, если кто в теме, было бы интересно знать, передискретизация в большую сторону в действительности искажает исходный вариант или нет?
>>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 не заметил.
>>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 пиксель и как потом соберётся снова при возвращении? Интересно будет посмотреть, в особенности при применении разных алгоритмов масштабирования.
>>759 >Предполагаю, что ты имел в виду constant quality. Я имел ввиду -b:v 0 -crf 30, очевидно же.
>в особенности при применении разных алгоритмов масштабирования. Слева график, как 10 столбиков растягивают до тысячи (для иллюстрации), справа картинка, где одномерная полоска расширяется (с шагом в 2 пикселя) и "совмещается" обратно. Всё что смог придумать. Не знаю есть ли ещё что интересное, но насколько я понял ничего интересного не будет, только мыло. Можно сколько угодно увеличивать размеры в спектральном представлении и оно сохраняет чёткость. Даже если прогнать её 20 тысяч раз - ошибка -5 порядка. Но это если в double держать, если сохранять в 16-бит, то расплывается за сотню итераций или около того.
>Алгоритмов передискретизации звука мне известно меньше, но там тоже есть выбор Пролистал статью на википедии про эту фигню, там большая часть алгоритмов изначально с потерями, в угоду быстродействию или потому что так работает аналоговая электроника. На такой картинке оно всё сразу поплывёт, потому что сигнал максимально контрастный. Можно сразу любой оконный фильтр выкидывать. Угу низкия частоты он сохраниет, но с этим и кубические функции справляются (широкие мыльные полосы почти перестают размываться дальше некоторой степени). Собственно говоря, я не могу придумать больше никаких очевидных или не очевидных алгоритмов увеличения без потерь. Это нужно найти какие-то ещё ортогональные функции или другой вид исходного "изображения", в котором размер теряет смысл - так что это можно изобрать на любом размере. Ортогонализовать то можно что угодно, хоть простой шум - только он ещё должен собственно говоря увеличивать, а не просто кодировать в своём шуме исходный сигнал.
>>760 Ну и последний график можно заменить, наверное. Понятно почему так произошло, но не понятно стоило ли выравнивать другие функции - может быть это стало причиной дополнительных шумов или ещё на что-то повлияло. Но вроде бы не повлияло - переделаю и напишу, если вдруг.
>>762 Толстая - изначальный "сигнал" из 10 столбиков. Он просто рисуется в виде ломаной, а не в виде столбиков. Тонкая - во что он превращается, если пересамплить в 1000 столбиков разными алгоритмами. Соответственно на нижней оси координата или время, как тебе угодно.
>>747 > по умолчанию libvorbis проде бы cbr использует, что не есть хорошо. Это было ошибкой. Чтобы сделать ffmpeg'ом CBR при помощи libvorbis'а, надо зажать битрейт между -minrate:a и -maxrate:a.
Ещё одной ошибкой было предположение об улучшении качества при указании -q:a вместо битрейта: это лишь другой способ указания битрейта, приводящий к тому же результату; управления шириной потока по коэффициенту квантования libvorbis (как и другие известные мне аудиокодеки) не имеет.
>>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 Спасибо. А что есть «спектральное представление»? По сути — временное увеличение частоты дискретизации сигнала на порядок, после чего перенос его на новую частоту, отличающуюся от исходной на единицу?
>>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 Я не знаю что это такое и как называется, у нас тут адепт математики с точными названиями. Вот из аудиосити пример, то что сверху я называю спектральным представлением, а то что снизу - временным. Потому что одно число в спектральном (частотном) представлении отвечает определённой частоте, а одно число во временном отвечает конкретному моменту времени. Но ещё раз повторю, что скорее всего это совсем не спектральное представление и на самом деле это нужно называть совсем по другому.
>>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://…
А вообще смотреть онеме через браузер — себя не уважать, имхо. Отсутствие временной интерполяции и дебандинга в плеере, чрезмерный нагрев процессора, лаги, необходимость бороться с рекламой, обычно пожатая каким ноги видеодорожка, зависимость от работы интернет-соединения и сайта при просмотре — целый букет недостатков. Вариант для максимум нищебродов, короче.
>2645kB time=00:00:05.32 bitrate=4068.5kbits/s speed=0.0283x Вот это -b:v 0 -crf 55.
Почему видео занимает так много места, и почему оно кодируется просто вечность в vp9? Я вот сейчас взял другое видео 1920х1080х60 и оно кодируется со скоростью 0.24х, почти в десять раз быстрее. Да, при этом оно кодируется без каких-либо заметных артефактов в реальном времени с адекватным битрейтом в h264; vp9 не умеет в 3d?
Чёртов маяк, место просто в четыре раза сложнее всех остальных маяков на нефинальных картах.
>>1004 Слишком большое разрешение и коэффициент качества. У меня даже видео это тормозит, обычно я такие даже не открываю. У большинства даже нет таких мониторов, в каком разрешении это видео.
upd: Ошибся, забыл, в какую сторону коэффициент качества работает. Тогда дело просто в большом разрешении и частоте кадров.
>>1016 Почти минимум же. Нет, проблема именно с этим видео. Другое аналогичного разрешения хорошо себя чувствует, кодируется/декодируется значительно эффективнее. А тут, я не знаю что, vp9 просто вешается. Причём уже второй раз на такое наталкиваюсь, и второй раз именно с этой игрой.
>>2224 Какие у тебя ОС и потребности, такую и выбирай. Static-сборка — это когда библиотеки вкомпилены в исполнимый файл, shared — когда они лежат отдельно, dev — когда в архив включены заголовочные файлы для сборки использующих библиотеки ffmpeg'а программ. Всё просто.
По возможности вообще лучше не качать программы с сайтов, а ставить пакетным менеджером из репозиториев своих дистрибутивов.
>>2225 >а ставить пакетным менеджером из репозиториев своих дистрибутивов Старые могут быть. Не все оперативно обновляется. Для винды так вообще не актуально.
>>2226 > Старые могут быть. Не всегда нужна свежая: например, в libvpx и libopus давно не было значительных обновлений. Если же хочется самый свежак, то сборки всяких zeranoe — вряд ли оно самое: свежий там только сам ffmpeg, а библиотеки сжатия он использует стабильных версий. > Для винды так вообще не актуально. Для неё есть msys2 с репозиторием и пакетным менеждером.
>>2416 Можешь тоже использовать ffmpeg, он умеет. Либо ImageMagick/GraphicsMagick, если нужно больше функционала. Есть ещё мелкие утилиты для оптимизации без потерь вроде optipng и jpegoptim.
>>2422 Как его скомпилировать? Необходимо ли для этого пускать систему сборки в сеть, или она может довольствоваться зависимостями из установленных в ОС?
>>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'а, а не этого скрипта.