FFmpeg и общий кодирования видео тред №2 /ffmpeg/
Аноним (Microsoft Windows 10: Chromium based)
06/05/21 Чтв 14:53:45
№1
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички в step-by-step how-to стиле для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также очень много вопросов отвечено на стековерфло.
Самые ходовые видео-кодеки на данный момент - VP9 и H.264. Подробный разбор их режимов кодирования читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда: https://github.com/pituz/webm-thread/wiki
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода батла HEVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
Бонусом сразу вброшу youtube-dl - утилита для нормального выкачивания видео с ютуба, вк, порнхаба и ещё миллиона других видеосервисов. Не совсем кодирование, но скорее всего ты тоже этим дерьмом занимаешься, если что-то делаешь с видео, т.ч. давай осваивай тоже нормальную утилиту вместо просмотра рекламы и установки зондов. Тоже опенсорс подо всё, что способно выполнять AND NOT и XOR.
Тред №..: https://2ch.hk/s/arch/2020-08-05/res/2591244.html
Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html
Для h265 hvec_amf пишется, если его умеет видюха конечно. Старые не умеют.
Сраная зелень работает через h264_nvenc
Перекодировка там будет занимать примерно вечность?
Какой кодек имеет наилучшее сжатие с наименьшими потерями? Какой кодек имеет наилучшее сжатие с наименьшими потерями и адекватной нагрузкой на железо?
Потому что в нем не реализована даже половина того, что в хуй264 есть. Нет нормального деблокинга, нет оценки и компенсации движения, нет предсказания кадров, за 6 лет, сука, не смогли сделать нормальный однопроходный алгоритм. Я еще что-то про квантизацию хотел написать, но о мертвых либо хорошо, либо никак. Я тут один видос на ютабе смотрел, так там темная сцена в вп9 просто засрана ебучим бандингом. Гугл там вообще это говно разрабатывает или че?
>>2982134
>А почему av1 - это хбз?
Потому что для адекватного кодирования тебе нужен суперкомпьютер.
>266
Говно без задач, но лучше ав1.
А когда-то давно, ещё до MP4 AVC / h264, в сравнении с MP4 ASP / Xvid, его дальний предок On2 VP5 - давал наименее артефачную картинку на репаках DVD9 снятых проф.видеокамерой в сложных концертных условиях. А потом их купили и чёт всё скатили.
Ну ок. К примеру на пресете эквивалентным пресету medium и veryslow для h.264(не в курсе как они у vvc обзываются)
Про crfв курсе. Не знаю, какой выбрать. Пусть будет 25, например.
Мне просто нужно оценить пиздецовость времени на кодировку
..\ffmpeg -ss 00:47:00 -i %FILE% -to 00:02:00 ^
-codec:v mpeg2video -g 15 ^
-mbd rd -mbcmp satd -precmp satd -cmp satd -subcmp satd -b_strategy 2 ^
-vf scale=1024:-1:flags=lanczos,pad=1024:576:(ow-iw)/2:(oh-ih)/2,scale=720:576:flags=lanczos -r 25 ^
-b:v 5700k -maxrate 9000k -bufsize 1835008 ^
-packetsize 2048 -muxrate 10080000 -an -pass 1 -y out.mpg
..\ffmpeg -ss 00:47:00 -i %FILE% -to 00:02:00 ^
-codec:v mpeg2video -g 15 ^
-mbd rd -mbcmp satd -precmp satd -cmp satd -subcmp satd -b_strategy 2 ^
-vf scale=1024:-1:flags=lanczos,pad=1024:576:(ow-iw)/2:(oh-ih)/2,scale=720:576:flags=lanczos -r 25 ^
-b:v 5700k -maxrate 9000k -bufsize 1835008 ^
-packetsize 2048 -muxrate 10080000 -an -pass 2 -y out.mpg
нет, дефекты пленки действительно есть в оригинале, но в видео которое получается после кодирования явные дрожания квадратиков которых нет вообще в оригинале. на гифке это может не так заметно(и это еще не самый худший вариант видео получился).
Я тебе наперëд скажу, что есть две хитрых причины:
- частная - у модуля rdo в libavcodec с mpeg2 есть баг, проявляющийся при кое-каком сочетании настроек; я нашëл его давно, за детали не поясню, адекватного средства воспроизведения под рукой нет, чтобы в твоëм видео идентифицировать;
- общая - дрожание может быть следствием эффекта Гиббса при передискретизации ( scale).
Хорошо, что само видео дал. Попробую на работе завтра глянуть.
я не понимаю базовых вещей.
вот если у меня есть скачанный ролик в кодеке H.264.
Я хочу его перекодировать другой кодек VVC или AV1. При перекодировке качество в любом случае упадёт, какие бы настройки я не выбрал? Простите за тупой вопрос - я правда не понимаю.
Как при перекодировке выбрать такие параметры, чтобы не потерять в качестве для нескольких файлов сразу?
Спасибо
Когда-то в 2005-ом году на актуальном железе libx264 давал на SD+PAL около 5 кадров/с на умеренных настройках и с почти вдвое (на самом деле, в добрых 1,5 раза) меньшей шириной потока по сравнению с h.263 или ASP. Но тогда производительность x86 процессоров росла гораздо быстрее, чем сейчас. Сегодня на HD+NTSC у libx265 и прочих HEVC скорость кодирования тоже 5 кадров/с при эффективности сжатия едва ли превосходящей h.264 раза в полтора. А есть ещё более нагруженные по вычислениям AV1 и VVC.
Сегодня я бы сказал, что H.264 — это всерьёз и надолго. Медленное новое — это предмет для моего скепсиса.
это всё так важно?
ну ладно
проц 8700, память(не знаю, надо нет) 32гб
разрешение 1920x1080
изначально было
File size : 1.61 GiB
Duration : 22 min 29 s
Overall bit rate : 10.3 Mb/s
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 3 Ref Frames
стало
File size : 961 MiB
Duration : 22 min 29 s
Overall bit rate : 5 971 kb/s
Format : AV1
Format/Info : AOMedia Video 1
Format profile : Main@L4.0
перекодировал через xmedia recode, так как с ffmpeg пока не сильно разобралс(какие там ключи нужны, какие нет): Quantizer 25; CPU-Used 12; Tile Columns 4; Tile Raws 4 - это параметры не записывал, поэтому мог не совсем точно вспомнить
>H.264 — это всерьёз и надолго
Только потому что хуй264 не обложен патентами. В идеале мы сейчас должны были все сидеть на хуй265 и облизываться на хуй266. А по факту остается только какой-то революции в отведении тепла ждать, чтобы инцеловская кукуруза в 100 ядер могла ебашить, а чем больше это откладывается, тем дольше займет дальнейший переход на более продвинутые форматы, ведь хуй264 сейчас разве что моя жопа не воспроизводит.
>>2984959
>CPU-Used 12; Tile Columns 4; Tile Raws 4
Читать как:
>я потратил 3 часа своей жизни, чтобы транскодировать в уебищном качестве 22 минуты
АВ1 победа.
>хуй264 не обложен патентами
Вообще-то тоже обложен и довольно густо.
> В идеале мы сейчас должны были все сидеть на хуй265 и облизываться на хуй266.
Если бы производительность бытовых процессоров в расчëте на одно ядро росла также как в нулевых или хотя бы в начале десятых. Но по факту имеем то, что производительность одного ядра где-то с три годика назад упëрлась в потолок и растëт на жалкие единицы процентов. Облизываться даже на следующее поколение можно только во влажных снах. Оно уже сейчас непрактично.
> А по факту остается только какой-то революции в отведении тепла ждать, чтобы инцеловская кукуруза в 100 ядер могла ебашить, а чем больше это откладывается
Влажно, да.
>youtube-dl -g URL
на некоторых видео высирается вместо ссылки на видеопоток ссылка на какой-то manifest.googlevideo.com/api/videpla... как вернуть на первое место видеопоток или заставить youtube-dl выдавать 3 ссылки?
>с три годика назад
Десять лет как. Посмотри на сенди бриджи и иви средней руки, если ты вставишь вместо 2500k современное аналогичное говно9 1488К, ты не заметишь разницы в производительности. То же самое с видеокартами. Флагман 2011 года по производительности в играх чуть слабее "народного" говна в виде 1060, а этого уже достаточно для ебы. А с учетом уменьшения техпроцесса, а следовательно температуры, а следовательно износ вентиляторов будет нулевой большую часть рабочего времени (поскольку они не работают в простое), все эти 1060 будут актуальны еще 10-15 лет.
Если резануть вебмку так, без перекодирования: ffmpeg -ss 00:56.248 -to 01:33.274 -i input.webm -c copy out.webm То на выходе мы получаем рассинхрон звука с видео.
Тот же mkvtoolnix режет неточно, зато без рассинхрона, что меня вполне устраивает.
ищу ses2sesx софтину, нашёл только один на варезнике старый варик, вирустотал говорит там салти
мне нужен именно ses2sesx, НЕ sesх2sesx
не в видеомонтаж тред же идтить
есть вообще такие или это недостижимая технология будущего?
может есть какая-то простая обёртка для ffmpeg которая делает то же самое не зависая и не крашась?
virtualdubmod
А на ntsc dvd как хранится видео? Закодировал видео также как и для pal, только изменив частоту на 29.97 и размер изображения, и sony dvd architect нормально воспринимает такое видео для ntsc dvd, т.е. видео может храниться закодированное прогрессивными кадрами, а откуда тогда будут браться чересстрочные поля?
В результате pulldown-а кадры всегда преобразуются в поля? А если я хочу pal dvd сделать то что тогда?
Инстаграм gallery-dl
Тикток YouTube dl качает, но с водяным знаком. Лучше через сайт https://ssstik.io/ru/
1080p60fps.
Контейнер — mp4.
Аудиокодек — AAC-LC, 48 кГц, стерео, битрейт до 384 кбит/сек.
Видеокодек — H.264, прогрессивная развертка, высокий профиль, два последовательных B-кадра, GOP равняется половинной частоте кадров, CABAC, переменный битрейт (до 24 мбит/сек), цветовая субдискретизация 4:2:0, цветовое пространство BT.709 (значение H.273: 1).
https://www.ffmpeg.org/ffmpeg-all.html
Ctrl+F нужный_тебе_параметр
> А на ntsc dvd как хранится видео?
В пределах каждой gop для mpeg-es можно для ntsc определить поток как видео на 60 полей или как фильм на 24 кадра с pulldown-флагами, определяющими способ сборки 60 полей из 24 кадров (есть варианты). В последнем случае в потоке кодированы полные кадры (с построчной развëрткой), а телекино должно делаться на стороне воспроизводящего устройства. В пределах одного потока mpeg-ps или mpeg-ts (на основе которого сделаны vob) можно такие фрагменты чередовать: например, есть у тебя документальная картина, где чередуются сцены снятые на видео (интервью режиссëра), развëртка в которых чересстрочная, и сцены из фильма, которые из скана киноленты с построчной развëрткой и pulldown-флагами. Технически приведëнный пример осуществить сложно, поэтому, зачастую в таком материале телекино делается ещë при монтаже, а материал кодируется как чересстрочный ntsc. Любители переменной частоты кадров иногда декодированный с таких dvd материал разбивают на сцены и применяют по месту либо фильтр преобразования развëртки, либо обратного телекино.
>>2987746
>т.е. видео может храниться закодированное прогрессивными кадрами, а откуда тогда будут браться чересстрочные поля?
То, что исходный материал был построчный на 30 кадров, ещë не значит, что mpeg2-кодер не закодировал его как 60 полей. НЯП, у mpeg2 (стандартом h.262, можешь почитать ради интереса, текст должен быть доступен чуть ли не прямо на сайте ITU) не предусмотрено режима кодирования построчного изображения для ntsc. Если ты материал уже закодировал, то можно глянуть отчëт mediainfo о файле с mpeg-es или mpeg-ts - в отчëте должен быть указат тип развëртки. Наперëд скажу, что для чересстрочного материала у mpeg2 есть кое-какие особенности представления изображения и поиска движения.
> В результате pulldown-а кадры всегда преобразуются в поля?
Вполне возможно. Тут тебе или стандарт глядеть, чтобы получить исчерпывающую информацию, или только отчëт mediainfo, чтобы разобаться в своëм результате.
>>2987746
>А если я хочу pal dvd сделать то что тогда?
Для pal точно помню, что стандартом предусмотрено представление построчного изображения, как и чересстрочного. Если материал построчеый, то не забывай об этом программе кодирования сообщить. Если материал чересстрочный, то не забывай той же программе кодирования правильно сообщить, какое поле первое. И то и другое важно, т.к. влияет на алгоритм поиска движения.
вот например пробовал закодировать ntsc видео для dvd, частоту кадров при кодировании оставил неизменной, потом файл прогнал через dgpulldown.
из mediainfo:
Frame rate : 23.976 (24000/1001) FPS
Scan type : Progressive
Scan order : 2:3 Pulldown
>>2989577
>для ntsc определить поток как видео на 60 полей или как фильм на 24 кадра с pulldown-флагами
>у mpeg2 не предусмотрено режима кодирования построчного изображения для ntsc
тут нет противоречия?
>>2989577
>Если материал построчеый, то не забывай об этом программе кодирования сообщить.
Как?
А ну и расширение файла как нибудь влияет на результат? Если ставить m2v, ts? Сейчас ставлю mpg.
ланчоз вроде лучше
>Какой режим скалирования для даунскейла из 4к?
Я дам неожиданную рекомендацию. Bilinear spline.
Между ФНЧ при передискретизации есть следующая разница.
Наименьшие искажения даёт гауссовский фильтр из-за того, что гауссовская функция является собственной функцией преобразования Фурье; наименьшие искажения достигаются при большом размере окна, т.к. гауссовская функция не финитная, на практике из соображения производительности выбирают окно из 32...64 отсчётов, что даёт СКО за счёт эффекта Гиббса в районе -40 дБ; плюс при малой ширине лепестка (для более чёткой картинки) на изображении вблизи границы между статичной текстурой и резким краем другого объекта будут заметны изкажения, воспринимаемые как шум; требуется внимательный подбор пареметра ширины лепестка и, если предоставляется, ширины окна. Фильтр почти не обогощает спектр и не даёт переколебаний вблизи резких колебаний яркости.
Способ интерполяции по ближайшему смежному отсчёту - это такой сверхбыстрый способ передискретизации. Затычка. Очень сильно обогощает спектр сигнала и добавляет в пространственной области заметные искажения. При подготовке материаорв использовать смысла нет.
Билинейная фильтрация. Быстрый способ интерполяции. Имеет смысл только при повышении частоты дискретизации. Обогащает спектр сигнала чуть меньше, чем метод по ближайшему смежному, и пространственных исаажений вносит сильно меньше. Оптимум в смысле СКО, насколько я помню, достигается при кратном изменении частоты дискретизации. Последнее не имеет смысла в большинстве приктических задач подготовки изображений. Тоже фильтр-затычка, когда вычислительная производительность любой ценой.
А ты как хотел? Мы так-то сложную хуйню обсуждаем, в которой матана до страшной страсти. И это мы пока ещё в евклидовых гилбертовых пространствах и с теоремой Котельникова-Найквиста-Шеннона, а могли бы начать с другой теоремы отсчётов, например, с Хургина-Яковлева, а закончить более физически корректным пространством Соболева.
Тем более, я и практические рекомендации всё-таки привожу.
Бикубическая интерполяция - это достаточно быстрый способ, компромисс между высокой вычислительной производительностью (раза в полтора ниже, чем у билинейной) и неплохим приближением в смысле СКО (лучше, чем у билинейной). Уже не затычка, но условия оптимального применения те же, что у билинкйной - кратное повышение частоты дискретизации. При понижении частоты дискретизации, особенно при отношении частот, близком к единице (например, 1,2...1,5), из-за наложения спектров и наложения сигналов смежных окон, даёт сильные пространственные искажения. В реальной практике используется при сверхбыстрой обработке изображений (например, при демонстрации эффектов в графических редакторах). При подготовке материалов использовать нецелесообразно.
Вариант с бикубической интерполяцией по яркостной составляющкй и билинейрой по цветоразеостной - чуть быстрее, чем простой бикубический, за счёт роста искажений в цветоразностных составляющих изображения. Червеческое зрение более терпимо к искажениям в цветоразностных составляющих.
Бикубический сплайн - это финитная поверхность, приближающая исходный сигнал в нескольких смежных окнах многочленами (в каждом окне определён многочлен третьей степени, как правило согласованный с многочленом в смежном окне через естественные граничные условия - равенство первой и второй производных в граничной точке). Это существенно более затратный способ интерполяции по сравнению с бикубическим, и даже по сравнению с фильтром Ланцоша. На практике имеет существенно меньшие искажения по сравнению с бикубической интерполяцией и существенно меньшие переколебания по сравнению с фильтром Ланцоша. Дополнительным преимуществом является устойчиврсть при отношении частот дискретизации в диапазоне 1...1,5 - искажения при высоком порядке фильтра (64 точки, например) дают существенно меньшие искажения по сравнению с фильтром Ланцоша при той же воспринимаемой резкозти.
>Bicubic spline.
fix.
>>2989980
Про area сходу не расскажу - нужно разбираться.
Фильтры Ланцоша и sinc являются родственниками. Фильтр sinc представляет собой окно отсчётов функции sin(x)/x, ширина которого определяется через отношения частоты дискретизации и частоты среза АЧХ фильтра. У бесконечно длинной последовательности sin(x)/x АЧХ является прямоугольной и содержит единственный лепесток вокруг нулевой частоты; у окна спектр сразу становится периодическим, что увеличивает искажения, связанные с наложением спектров исходного сигнала и окна; плюс спады АЧХ становятся не вертикальными, а пологими, что на практике приводит к необходимости сузить основной лепесток АЧХ. Последнее приводит к эффекту переколебания яркости вблизи резких границ на итоговом изображении. Фильтр вычислительно производительнее, чем бикубический сплайн, такой же по производительности, как Ланцоша, и уступает в разы билинейному.
Фильтр Ланцоша использует более хитрое окно. Расскажу чуть позже.
На всякий случай поясню, что способы интерполяции, основанные на полиномиальных приближениях (>>2989957>>2989967>>2989980) на бытовом уровне можно представить как способы провести на координатной плоскости через последовательность точек контур из отрезков линий или полиномиальных кривых, а затем на полученных контурах отметить новые точки, соответствующие новой частоте дискретизации.
Способы интерполяции, основанные на свëртке с окном (основным финитным участком импульсной характеристики) какого-нибудь фильтра (гауссова, фильтра Ланцоша, фильтров Слепиана, прямоугольного и т.д.) можно представить себе следующим образом. Допустим, есть в виде кривой некоторый симметричный (относительно вертикальной оси координатной плоскости) колебательный процесс, интенсивность которого быстро убывает по мере удаления от начала координат. Теперь представь точки, расположенные равномерно вдоль горизонтальной, и отстоящие от горизонтальной оси на всякие разные расстояния. Измеряешь эти расстояния, это будут интенсивности отсчëтов исходного сигнала. Дальше масштабируешь упомянутый ранее колебательный процесс в соответствии с интенсивностью каждого отсчëта и перемещаешь увеличенную копию процесса горизонтально из начала координат к координате соответствующего отсчëта. Получилась целая куча накладывающихся друг на друга кривых. Дальше строишь вертикальные прямые, соответствующие новой частоте дискретизации, для каждой из которых находишь точки пересечения с кривыми и алгебраически суммируешь все отклонения точек пересечения от горизонтальной оси (суперпозиция). Вот это суть операции свëртки. Как нетрудно догадаться, окно фильтра можно построить по известным параметрам со сколь угодно высокой частотой дискретизации и сколь угодно большой длины. Вот по этому для такого способа интерполяции соотношения частот дискретизации ограничены только допустимыми искажениями финитности (эффектом Гиббса) и допустимыми искажениями при наложении спектров.
Теперь о том, Что касается фильтра с прямоугольной АЧХ; он же sinc, т.к. обратное преобразование Фурье от прямоугольного спектра - это функция sin(t)/t. Свëртка его импульсной характеристики с исходным дискретным сигналом - это практически лобовое решение восстановительной задачи теоремы Котельникова (т.е. восстановления по дискретным отсчëтам исходного непрерывного сигнала с финитным спектром и ограниченной энергией). Далее в большом алгоритме интерполяции остаëтся только повторно дискретизировать восстановленную модель непрерывного сигнала уже с целевой частотой дискретизации.
Чем отличаются прямоугольный фильтр и фильтр Ланцоша? Окно фильтра Ланцоша состоит из поотсчëтного произвндения двух окон прямоугольных фильтров с разной частотой среза (и, соответственно, разной шириной основного лепестка). Дополнительно отсчëты, близкие к краям окна сделаны нулевыми. Фильтр Ланцоша является улучшением sinc-фильтра, которое при незначительном снижении резкости (за счëт относительного расширенич основного лепестка) значительно снижает переколебания и эффект от наложения смежных окон (за счëт подавления колебательного процесса вблизи краëв окна).
>>2989957
>>2989958
>>2989967
>>2989980
>>2990032
Охуенная простыня, очень интересно, спасибо что постарался, это действительно важно знать в треде про ffmpeg, программе для кодирования видео и аудио. Все прочитали от начала до конца, математика это же не тупейшая поебень для конченных, и вообще не наука, а хорошее занятие развивающее мозг
> тут нет противоречия?
Нет. Я имел в виду, что у mpeg2 не предусмотрено режима кодирования построчного изображения на 30 полных кадров. Только на 60 полей или фильм на 24 кадра с pulldown-флагами.
Итак, чтобы быть точным, я заглянул в стандарт ISO/IEC 13818-2:1995 (E), он же ITU-T Rec. H.262 (1995 E). На 42-ой странице смотрим таблицу 6-4, из которой узнаём, что MPEG-2 поддерживает следующие частоты кадров (кадр определён на 4-ой странице как совокупность всех строк изображения, т. е. совокупность верхнего и нижнего полей — это тоже кадр) и полей:
- 24000/1001 (23.976...) — это тот самый NTSC FILM (т.е. обычный 24-кадровый скан киноплёнки, немного замедленный для совместимости с NTSC-телевидением); поддерживается в вещательной системе ATSC и через программное телекино на DVD/BD и в вещательной системе DVB;
- 24 — это простой FILM; поддерживается в вещательной системе ATSC;
- 25 — это, понятное дело, PAL (построчный и чересстрочный); поддерживается на DVD/BD и в вещательных системах ATSC, DTMB и DVB;
- 30000/1001 (29.97...) — это NTSC; поддерживается на DVD/BD в чересстрочном (и явно не запрещено кодировать материал как построчный) варианте, также поддерживается вещательными системами ATSC, ISDB и DVB;
- 30 — это не предназначено для DVD (для BD нужно уточнить), поддерживается вещательной системой ATSC;
- 50 и 60 — это не предназначено для DVD (редко встречается на UHD BD 60 и 48 кадров/с, но не с MPEG-2), поддерживается вещательными системами ATSC и DVB;
60000/1001 (59.94...) — это не предназначено для DVD/BD, поддерживается вещательными системами ATSC и DVB.
То, что вещательные системы поддерживают, ещё не значит, что реально используется. Подавляющее большинство последовательностей в вещательных системах пытаются сохранять обратную совместимость с частотами кадровой развёртки 25 и 29,97 кадров/с (для PAL и NTSC соответственно).
> А ну и расширение файла как нибудь влияет на результат? Если ставить m2v, ts? Сейчас ставлю mpg.
Никак. Следует различать три формата потока: MPEG-ES (это тот поток, который генерирует кодер, совместимый со стандартом H.262), MPEG-PS (это то, что хранится, например, на DVD в VOB-ах) и MPEG-TS (это то, что предназначено для вещания). MPEG-PS и MPEG-TS — это форматы контейнеров, внутрь которых может с раскладкой и разметкой инкапсулироваться MPEG-ES. Некоторые программы для сборки DVD требуют на свой вход исключительно MPEG-PS, например, dvdauthor. Некоторые программы требуют исключительно MPEG-ES, например, mplex.
Есть нюанс, состоящий в том, что многие пользовательские программы пытаются по расширению файла угадать содержимое. Иногда возникают с этим проблемы.
> вот например пробовал закодировать ntsc видео для dvd, частоту кадров при кодировании оставил неизменной, потом файл прогнал через dgpulldown.
Для подготовки видео под DVD можно сформулировать основные цепочки:
- (PAL-камера, чересстрочная, 25 кадров/с) -> монтаж чересстрочного видео с соблюдением порядка полей, определённого камерой -> кодирование чересстрочного видео с флагами progressive_sequence=0 и top_field_first=1 (если первое должно выводится верхнее полее) или top_field_first=0 (если первым должно выводится нижнее поле) -> поток с чересстрочным PAL-видео;
- (NTSC-камера, чересстрочная, 29,97 кадров/с) -> монтаж чересстрочного видео с соблюдением порядка полей, определённого камерой -> кодирование чересстрочного видео с флагами progressive_sequence=0 и top_field_first=1 или top_field_first=0 -> поток с чересстрочным NTSC-видео;
- (PAL-совместимая камера, прогрессивная, 25 или 50 кадров/с) -> монтаж построчного видео с преобразованием частоты кадров из 50 в 25 Гц -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 и repeat_first_field=0 -> поток с построчным PAL-видео;
- (NTSC-совместимая камера, прогрессивная, 29,97 или 59,94 кадра/с) -> монтаж построчного видео с преобразованием частоты кадров из 59,94 в 29,97 Гц -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 и repeat_first_field=0 -> поток с построчным NTSC-видео;
- (FILM-совместимая камера, прогрессивная, 24 кадра/с) -> монтаж построчного видео с установкой частоты кадров на 23,976 Гц и уменьшением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным FILM-видео -> расстановка pulldown-флгов, т. е. установка в секции PCE каждого кадра флагов top_field_first и repeat_first_field в зависимости от положения кадра в шаблоне 3:2, такая операция иногда совмещается кодером с кодированием построчного материала;
- (FILM-совместимая камера, прогрессивная, 24 кадра/с) -> монтаж построчного видео с установкой частоты кадров на 25 Гц и увеличением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным PAL-видео;
- (FILM-совместимая камера, прогрессивная, 30 кадров/с) -> монтаж построчного видео с установкой частоты кадров на 29,97 Гц и уменьшением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным NTSC-видео.
Ты используешь какую цепочку преобразований?
> Между ФНЧ при передискретизации есть следующая разница.
> Наименьшие искажения даёт гауссовский фильтр из-за того, что гауссовская функция является собственной функцией преобразования Фурье; наименьшие искажения достигаются при большом размере окна, т.к. гауссовская функция не финитная, на практике из соображения производительности выбирают окно из 32...64 отсчётов, что даёт СКО за счёт эффекта Гиббса в районе -40 дБ; плюс при малой ширине лепестка (для более чёткой картинки) на изображении вблизи границы между статичной текстурой и резким краем другого объекта будут заметны изкажения, воспринимаемые как шум; требуется внимательный подбор пареметра ширины лепестка и, если предоставляется, ширины окна. Фильтр почти не обогощает спектр и не даёт переколебаний вблизи резких колебаний яркости.
>>Если материал построчеый, то не забывай об этом программе кодирования сообщить.
>Как?
В свойствах видеопоследовательности, если у тебя комбайн. В настройках кодера, если у тебя отдельный кодер.
Приведу пример с hcenc на картинке.
В ffmpeg кодер mpeg2video из состава libavcodec по умолчанию кодирует построчный материал. Чтобы кодировать чересстрочный материал нужно явно сообщить ffmpeg опции «-ilme», «-ildct» и «-ildctcmp». Последняя опция должна быть с параметром. Кроме того, в зависимости от входного материала, может потребоваться указать явно порядок полей «-field_order» (тоже с параметром).
Для построчного видео последний раз использовал такие строчки для двух проходов:
wine avs2yuv ed-film.avs - | \
ffmpeg -i pipe:0 \
-vcodec mpeg2video -strict strict -profile:v 4 -level:v 8 \
-pass 1 \
-b:v 4800k -maxrate 8700k -minrate 0 -bufsize 1835k \
-g 12 -bf 2 -b_strategy 2 -brd_scale 0 -b_sensitivity 40 \
-qmin 1 -qmax 28 -qdiff 3 -dc 10 -non_linear_quant 1 \
-luma_elim_threshold -4 -chroma_elim_threshold 7 -qcomp 0.6 -qblur 0.5 -rc_strategy 0 \
-lmin 59 -lmax 3658 \
-i_qfactor -0.8 -i_qoffset 0 -ibias 96 -pbias 0 \
-b_qfactor -4 -b_qoffset 1.25 \
-sc_threshold 0 \
-me_method dia -me_range 0 -dia_size 6 -pre_dia_size 6 \
-preme 1 -bidir_refine 4 -mv0_threshold 256 \
-mbd rd -cmp 2 -subcmp 2 -mbcmp 2 -precmp 2 -skipcmp 2 \
-nr 0 \
-aspect 16/9 -threads 2 \
-f dvd \
-passlogfile pass.log \
/dev/null -y && \
wine avs2yuv ed-film.avs - | \
ffmpeg -i pipe:0 \
-vcodec mpeg2video -strict strict -profile:v 4 -level:v 8 \
-pass 2 \
-b:v 4800k -maxrate 8700k -minrate 0 -bufsize 1835k \
-g 12 -bf 2 -qmin 1 -qmax 28 -qdiff 3 -dc 10 -non_linear_quant 1 \
-luma_elim_threshold -4 -chroma_elim_threshold 7 -qcomp 0.6 -qblur 0.5 -rc_strategy 0 \
-lmin 59 -lmax 3658 \
-i_qfactor -0.8 -i_qoffset 0 -ibias 96 -pbias 0 \
-b_qfactor -4 -b_qoffset 1.25 \
-sc_threshold 0 \
-me_method dia -me_range 0 -dia_size 6 -pre_dia_size 6 \
-preme 1 -bidir_refine 4 -mv0_threshold 256 \
-mbd rd -cmp 2 -subcmp 2 -mbcmp 2 -precmp 2 -skipcmp 2 \
-nr 0 \
-aspect 16/9 -threads 2 \
-f dvd \
-passlogfile pass.log \
ed-film.vob -y
Как ты лихо всех, кого ты не понимаешь, относишь к категории «ебанутые»?
Чтобы понимать то, о чём я говорю, можно, например почитать вот эти две книжки:
- Чобану М. К. Многомерные многоскоростные системы обработки сигналов. М.: Техносфера, 2009;
- Дворкович В.П., Дворкович А.В. Оконные функции для гармонического анализа сигналов /Издание второе, переработанное и дополненное/ М.: Техносфера, 2016.
>>2990111
Здесь, скорее, случай на картинке.
Дополнительно сообщу, что есть отличный обзор в документации к ImageMagick:
https://legacy.imagemagick.org/Usage/filter/
> параметры немного отличаются это норм?
Если ты про
> -b_strategy 2 -brd_scale 0 -b_sensitivity 40
То имею сказать следующее
> -b_strategy 2
> mpegvideo_enc.c, 723
> b_frame_strategy only affects the first pass
> -b_sensitivity 40
> mpegvideo_enc.c, 1561
Читаем функцию select_input_picture(MpegEncContext s) и убеждаемся, что b_frame_strategy и b_sensitivity используются одновременно, а brd_scale используется в вызываемой там же функции estimate_best_b_count(MpegEncContext s).
Но только при b_frame_strategy==1 используется b_sensitivity. Следовательно, можно опцию смело исключить и написать правильно сразу:
-b_strategy 2 -brd_scale 0
И это опция только для первого прохода.
Плюс в 2016 году опции b_strategy и brd_scale перевели в устаревшие (в смысле, что из общей структуры AVCodecContext её нужно перенести в структуру MpegEncContext)
https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2016-January/097741.html
Т. е. как правильно использовать, нужно узнавать такой командой:
ffmpeg -h encoder=mpeg2video
Я использую правильно, за исключением избыточного указания опции b_sensitivity.
Такие дела.
>Пытаюсь сконвертировать скачанный bdrip у которого кадры прогрессивные и fps 23.976
Тогда идём по схеме
> (FILM-совместимая камера, прогрессивная, 24 кадра/с) -> монтаж построчного видео с установкой частоты кадров на 23,976 Гц и уменьшением скорости воспроизведения звука -> кодирование построчного видео с флагами progressive_sequence=1, top_field_first=0 -> поток с построчным FILM-видео -> расстановка pulldown-флгов, т. е. установка в секции PCE каждого кадра флагов top_field_first и repeat_first_field в зависимости от положения кадра в шаблоне 3:2, такая операция иногда совмещается кодером с кодированием построчного материала
с той разницей, что звук у нас уже нужной длины, и правильная частота кадров выставлена. Т. е. просто кодируем построчное видео. Т.к. ты собираешься расставлять pulldown-флаги при помощи dgpulldown, то тебе понадобиться на выходе кодера иметь чистый MPEG-ES (или MPEG-2 Video Stream). Если заставлять ffmpeg такой поток записывать, то указать ей нужно опцию
-f mpeg2video
Но можно и из любого другого контейнера raw MPEG-2 Video достать. Например, той же dgindex или mpegdemux или ffmpeg.
Как-то так.
>леттербокс
«Сверху и сниху телеэкрана невыносимо темнеют полоски».
У меня в тестовом видео кадр 720×480 с отношением сторон 16:9, без полосок. Такой исходник.
> где у тебя происходит изменение размера изображения
В скрипте avisynth. Я считаю, что объявить фильтры и монтажные процедуры в avisynth проще, чем в параметрах ffmpeg. Подумываю перейти на vapoursynth.
>А на ntsc dvd как хранится видео?
> а откуда тогда будут браться чересстрочные поля?
После того, как я освежил в памяти текст стандарта, расскажу, что для твоего случая (23,976 построчных кадра в секунду) в заголовке потока будет стоять флаг progressive_sequence==1, а в структуре «Picture coding extension» в заголовке каждого кадра будет установлен флаг progressive_frame==1 и определена пара флагов top_field_first и repeat_first_field, которые будут определять способ сборки дополнительных пар полей из чётных и нечётных строк построчного кадра.
Вот цитата из обзорной части стандарта:
> A decoder can implement 3:2 pull down when a sequence of progressive pictures is encoded. Each encoded movie picture can independently specify whether it is displayed for two or three video field periods, so “irregular” 3:2 pull down source material can be transmitted as progressive video. Two flags, top_field_first and repeat_first_field, are transmitted with the Picture Coding Extensions and adequately describe the necessary display timing.
> спасибо за развернутые ответы.
Пожалуйста. Рад помочь.
> а для преобразования 23.976 в 25 fps (для pal dvd) pulldown будет работать?
Для начала нужно будет картинку 720x576 подготовить. Способ повторить строки по шаблону 23,976->25 есть, и о нëм знает dgpulldown. Просто результат такого преобразоаания на телевизоре будет выглядеть не очень. Рваное движение заметно и на 23,976->29,97, а на 23,976->25 будет явно бросаться в глаза. При подготовке изданий в PAL, как правило, ускоряют звук и видео до 25 кадров. Сильно раньше было ещë заметно по музыке ускорение, а сегодня есть преобразователи с сохранением тона. Опять же, ты делаешь не официальное издание, бытовую копию - наверняка для тебя небольшое смещение тонов вверх в звуковой дорожке будет терпимо.
> есть какой то особый смысл в том чтобы задавать его явно
Нет. Никакого нет смысла. Эту строчку я взял из своего исследования кодера libavcoec::mpeg2video там я пытался решить оптимизационную задачу с критерием SSIM относительно параметров. Поскольку в скрипте они все указаны явно (т. к. я веду поиск по множеству допустимых для них значений), то и в строчку попали в том же виде. Два года или три даже прошло — я уже плохо помню, какие значения по умолчанию там. Но да, те, которые совпадают с умолчаниями, можно опустить.
Для чего нужна? Скажи, что ты собирался смотреть, я сам посмотрю. Мне главное понять, как пачку видео под нужные параметры кодировать. Лагают видео от 1980 до 4K. Битрейт по моему предыдущему опыту где то от 1000 лучше ставить.
DXVA Checker показывает поддерживаемые кодеки и максимальное разрешение. Вот выбираешь какой-нибудь из них и кодируешь в него, будет воспроизводиться без лагов
Лагает в зависимости от битрейта только если видеокарта не поддерживает кодек, и его обрабатывает процессор
> высоким разрешением и битрейтом, которые плохо проигрываются на моём некрокомпе
> комфортный для твоей машины битрейт
Ну, есть на твой вопрос три варианта ответа:
- научный,
- научно-популярный и
- бытовой.
Тебя, как я понимаю, интересует бытовой.
Чтобы бытовой (и при этом не тривиальный вроде, «купи уже мощный комплюктер в спальню») ответ сформулировать, нужно уточнить кое-какие множества из твоей задачи:
- модель центрального процессора,
-модель видеоадаптера графического ускорителя;
- характеристики файлов (по mediainfo, в текстовом виде) — нужно как минимум два файла: тот, который играется невыносимо медленно, и тот, который играется ещё сносно, но уже начинает притормаживать.
Существует ли аналог ffmpeg для изображений?
Существуют ли хоть сколько-нибудь годные GUI для сабжа под винду, раскрывающие как можно больше его потанцевала?
Натыкался пару раз на MeGUI и HandBrake, но это как я понимаю, немного из другой темы, ведь они только де/кодируют видео?
Это-то понятно, MeGUI вроде тоже так умеет (но для этого проще взять AviDemux). Но меня интересуют также другие свистоперделки, например создание и редактирование видео (эффекты там всякие, или что сабж умеет), захват экрана.
Из того что успел сам попробовать и остановился на них:
https://www.shutterencoder.com/en/
https://www.xmedia-recode.de/en/download.php
Что именно не сработало? Между файлами задержки и т.д.? Этих задержек случайно нет в самих файлах? Или выдаёт ошибку? Тогда какую? В общем, подробностей бы.
В документации https://trac.ffmpeg.org/wiki/Concatenate советуют этот метод:
> создаёшь текстовый файл mylist.txt
file 'c:\documents\001.flac'
file 'c:\documents\002.flac'
file 'c:\documents\003.flac'
Если не проходит, попробуй указать относительные пути либо сменить "\" на "/"
> ffmpeg -f concat -safe 0 -i mylist.txt -c copy output.flac
Не забываем запускать команду из папки с лежащим текстовиком либо указываем к нему путь
у меня похожая задача.
но есть проблема.
есть много видеофайлов, но у них отличаются частота кадров и разрешение. кодек один.
при попытке конкатнуть с изменением разрешения и частоты кадров, появляются ошибки.
как соединить эти видюхи?
Ну дак, определяем параметры исходного видео - каким будет размер/фреймрейт - максимальные/минимальные из всех видео, ну либо свои параметры. И перегоняем каждое видео к нужному размеру/фреймрейту. Потом склеиваем. Надеюсь не нужно пояснять, как менять размер и частоту кадров у одного видео? Да и простого ответа тут нет, зависит от задачи
Ещё раз, сначала нужно привести все видео к одинаковым параметрам, и только потом склеить, базовое правило видеомонтажа. Естественно не обойдётся без перекодирования.
Вот тут рассказывают, как ресайзнуть (фиксированно, либо с соотношением сторон, думаю тебе подойдёт именно фиксированный ресайз + обрезка кадра при несовпадении пропорций если не нужна деформация {я на самом деле хз, фиксированный ресайз обрезает или искажает, лучше перепроверить}): https://poweruser.guru/q/624563/#624564 , с изменением фреймрейта всё сложнее, тут лучше самому погуглить.
Одной командой сделать это наверняка нельзя, но точно я не знаю дилетант ещё тот, поэтому утверждать не буду.
Вот есть объяснения на английском для прилежного выпускника средней школы >>2990625.
>>2996778
Нет, окошко Ланцоша не является «лучшим».
Оно среди родственников является твëрдым середнячком.
>>2997513
Чем тебе mediainfo не нравится?
>>2997778
Я с годами понял, что GUI для ffmpeg - это что-то противоестественное. Тем более, НЯП, cmd.exe наконец-то научилась в drag-n-drop (вставлять в строчку имя файла при перетаскивании значка в окошко).
>>2998621
> отличаются частота кадров и разрешение
Разрешение придëтся приводить к одному. Воспроизводящие устройства к такому, как правило, не готовы, программы то же. С частотой кадров всë ещë хуже. Нет годного способа еë преобразования - все чем-нибудь плохи. Пока сама задача слишком плоха, чтобы было хорошее решение.
>>2998728
Нет. Двухпроходная стратегия контроллера ширины потока ставит задачу получить среднюю ширину потока при малой дисперсии квантователя. CRF-стратегия удерживает малые отклонения квантователя (по Чебышëву), увеличивая его только при предельных характеристиках потока, определëнных для профиля и уровня.
Почему не нужен?
>>2998732
>Нет. Двухпроходная стратегия контроллера ширины потока ставит задачу получить среднюю ширину потока при малой дисперсии квантователя. CRF-стратегия удерживает малые отклонения квантователя (по Чебышëву), увеличивая его только при предельных характеристиках потока, определëнных для профиля и уровня.
Что это значит?
> Нет, окошко Ланцоша не является «лучшим».
> Оно среди родственников является твëрдым середнячком.
В ffmpeg другого нет. И какие ещё родственники?
>>2998740
> Почему не нужен?
От него лучше качество не становится. Это требуется только когда у тебя ограничение по размеру файла. Но 264 и 265 умеют нормально его соблюдать с первого раза.
> В ffmpeg другого нет.
https://pastebin.com/iVjMRr7s
Это выхлоп ffmpeg 2.8. В нём указаны следующие фильтры: fast_bilinear, bilinear, bicubic, experimental, neighbor, area, gauss, sinc, lanczos, spline.
Для современного ffmpeg можно посмотреть хотябы исходный код:
https://ffmpeg.org/doxygen/trunk/swscale_8h_source.html#l00057
В нём указаны уже следующие фильтры: fast_bilinear, bilinear, bicubic, experimental, point (он же neighbor), area, gauss, sinc, lanczos, spline. То же самое.
Даже для масштабирования не обязательно использовать только ffmpeg. Можно использовать, например, VapourSynth (несколько встроенных, плюс jinc, nnedi3, варианты waifu2x и прочего нейросетевого).
> И какие ещё родственники?
Окна свёртки. Импульсные характеристики линейных фильтров с похожими свойствами. Между собой родственниками являются: sinc, lanczos и в меньшей степени jinc. Ещё есть варианты фильтра Ланцоша в взвешивающим окном не sin(x)/x, а Блекмана, Хемминга, Ханна и т. д. См. https://legacy.imagemagick.org/Usage/filter/#windowed
Работают примерно как фильтр Ланцоша, но позволяют оценить другие варианты компромисса между резкостью и «звоном» (уровнем боковых лепестков спектра).
> Что это значит?
Если моё объяснение не устраивает, то можно обратиться к варианту в Википедии или к книжке Ричардсона «Видеокодирование. H.264 и MPEG-4 — стандарты нового поколения».
Если говорить сильно упрощённо, то кодер (H.262, H.263, H.264 или H.265) работает так:
- есть основные задачи алгоритма — дискретное косинусное преобразование (ДКП), поиск и компенсация движения, квантование ДКП-коэффициентов, линеаризация последовательности квантованных ДКП-коэффициентов, формирование потока данных и его энтропийное кодирование;
- ДКП позволяет преобразовать элементы исходного изображения (матрицы 4✕4 или 8✕8 точек растра) из амплитудно-пространственной области в амплитудно-частотную (с вырожденной фазой); такая форма обладает компактностью коэффициентов для сигналов, характерных для естественного происхождения (с выраженными автокорреляционными свойствами) а также выгодна для последующей обработки на предмет снижения избыточности, не воспринимаемой человеческим зрением — в менее заметных высокочастотных составляющих сосредоточено наименьшее количество энергии (в смысле модулей ДКП-коэффициентов) и наименьшее количество воспринимаемой зрением человека информации;
- поиск и компенсация движения позволяют снижать временную избыточность изображения, сопоставляя в разных кадрах исходной последовательности по признаку похожести два (или три для двустороннего предсказания) макроблока (опорный и предсказанный) и подвергая ДКП не два полных блока, а опорный блок и его разность (ошибка предсказания) с предсказанным; т. о. в разностном блоке будет содержаться меньше информации, чем в предсказанном; в потоке для восстановления предсказанного блока будет храниться вектор движения (из разности координат между опорным и предсказанным блоками) и ДКП-коэффициенты ошибки предсказания; макроблок (как единица предсказания и компенсации движения) может состоять из нескольких ДКП-блоков, описание макроблока я опущу, т. к. это только запутает объяснения;
- квантование ДКП-коэффициентов позволяет снижать избыточность восстановленного изображения путём огрубления значений ДКП-коэффициентов и отбрасывания коэффициентов с наименьшим модулем; в результате квантования большая часть коэффициентов вырождается в ноль, а у остальных значительно сужается динамический диапазон, что позволяет кодировать числа меньшим числом бит; в потоке помимо квантованных ДКП-коэффициентов для закодированного кадра и ДКП-блока хранятся квантователь кадра и смещение квантователя блока; при кодировании вычисляется для хранения в потоке частное от матрицы исходных ДКП-коэффициентов и суммы квантоветелей, при восстановлении перед обратным ДКП осуществляется перемножение суммы квантователя кадра и квантователя блока с матрицей ДКП-коэффициентов, последнее необходимо для сохранения энергии в блоке;
- формирование потока данных осуществляется из ранее упомянутых примитивов — квантователей, квантованных и линеаризованных последовательностей ДКП-коэффициентов, векторов движения и ещё кучи более хитрых штуковин; большую часть ширины потока (т. е. частного от количества информации и единицы времени воспроизведения последовательности) занимают квантованные ДКП-коэффициенты, большая часть которых нулевая; поток данных, т. о., имеет автокорреляционные характеристики, располагающие к эффективному (в смысле коэффициента сжатия) энтропийному кодированию, которое и завершает весь процесс работы кодера.
В соответствии с приведёнными выше задачами есть модули программы-кодировщика:
- энтропийный кодировщик и компоновщик потока;
- контроллер ширины потока и значений квантователя;
- модуль поиска и компенсации движения;
- модуль ДКП.
Пользователю разрешено устанавливать параметры для всех модулей, но на близость решения к оптимуму (в смысле противоречия между доступной шириной потока данных и желаемой точностью передачи изображения) наибольшее влияние оказывают параметры контроллера ширины потока и поиска движения.
Вопрос в >>2998728 касался конкретно параметров контроллера ширины потока. Функцией контроллера является определение для каждого закодированного кадра значения квантователя (и ещё квантователей каждого макроблока в кадре, если стандартом и реализацией кодера предусмотрено квантование решетом — trellis). Значение подбирается итерационно в соответствии с критериями:
- указанным значением CRF, которое суть — математическое ожидание нормализованного (в соответствии с поправочными коэффициентами для P- и B-кадров) квантователя кадра;
- доступным (по стандарту) рядом значений квантователей;
- шириной потока закодированного (пробного) фрагмента и соответствующими требованиям стандарта предельными значениями; как правило, предельные значения определены профилем и уровнем в стандарте;
- целевым средним значением ширины потока;
- для двух смежных итераций соотношением между выигрышем в коэффициенте сжатия и изменением показателя искажений — RDO;
- способом предсказания нормализованного значения квантователя следующего кадра.
Основное правило интерпретации результата работы контроллера ширины потока простое: больше квантователь — больше искажений и, весьма вероятно, меньше ширина потока.
Работа контроллера ширины потока определена как оптимизационная задача, основными компонентами которой являются: начальное приближение значения квантователя, функция штрафов. Начальное приближение определяется указанным значением CRF или предсказанным нормализованным значением квантователя следующего кадра. Функцию штрафов можно определить через ряд критериев, который для простоты объяснения я опущу.
Т. к. начальное приближение возможно определить двумя способами, то у большинства контроллеров ширины потока есть две стратегии:
- основанная на CRF — кодер будет стремиться соблюдать постоянное нормализованное значение квантователя кадра (определённое через указанное значение CRF), пиковые отклонения для которого допустимы, например, только при достижении максимальной разрешённой стандартом ширины потока; в составляющие функции штрафов будет добавлен критерий чебышевского (т. е. абсолютного линейного) отклонения значений квантователя;
- основанные на ширине потока (с постоянной шириной потока, или со средней шириной потока) — для постоянной ширины потока кодер будет подбирать такое значение квантователей, чтобы ширина потока не превышала наперёд установленное значение; для достижения средней ширины потока кодер будет подбирать на первом (или единственном проходе) начальные значения квантователей путём предсказания на короткой дистанции (в пределах группы кадров — GOP — или или нескольких групп; ограничивается, как правило, параметров упреждающего анализа — lookahaed frames), а в функцию штрафов будут включены отклонение средней ширины потока от указанного наперёд номинального значения и среднеквадратичное отклонение (СКО) квантователей; что касается второго прохода, то его цель заключается в уточнении субоптимального решения при переходе от небольшого множества анализируемых за раз кадров (lookahaed frames) ко всей кодируемой последовательности целиком.
Теперь по частям.
> малой дисперсии квантователя
Дисперсия — кадрат СКО. Здесь указана дополнительная для данного режима и важная часть функции штрафов контроллера ширины потока.
> удерживает малые отклонения квантователя (по Чебышëву)
Критерий Чебышёва линейный (а СКО — квадратичный), т. о. он более чувствителен к одиночным большим отклонениям от среднего значения. Такие отклонения получают больший штраф, а кодер, соответственно, будет стремиться избежать такого решения.
> предельных характеристиках потока, определëнных для профиля и уровня
В стандартах H.262 и H.264, например, приведены ряд профилей и уровней, которым должны соответствовать кодер, декодер и поток данных. Уровни различаются целевым применением и соответствующими ограничениями на разнообразие примитивов, количество примитивов в единице потока, пределами ширины потока и предельными параметрами исходных последовательностей.
> и ещё квантователей каждого макроблока в кадре, если стандартом и реализацией кодера предусмотрено квантование решетом — trellis
Здесь ошибка закралась.
Требуются пояснения. Я спутал два разных инструмента: инструмент ROI стандарта H.264 и инструмент кодера — trellis R-D quantization. Последнее является техникой оптимизации при квантовании ДКП-коэффициентов в пределах макроблока.
А для ROI (region-of-interest) действительно можно определить отдельные параметры квантования.
В описанном тобой ранее случае искажений всё равно не избежать, так как там у тебя надо склеить и 24 fps и 24 000 / 1001 fps, и кратную частоту кадров для них всех хуй подберешь.
> что будет, если я буду конвертировать 23.97 в 60?
Хуйня у тебя будет. Ближайшее кратное к 24 000 / 1001 fps будет 48 000 / 1001, оно же 47.95 fps.
> 23.97 24 29.97 30 50 60
Допустим, целевая у нас будет 60. Обратной совместимости с вещательными системами нет, но она, скорее всего, не нужна. Зато под массовый современный монитор годна.
30 -> 60 простым дублированием кадров получится, искажений нет, но и плавности движений нет.
29,97 -> 30 можно сделать небольшим ускорением звука и назначением новой частоты кадров; дальше до 60 дублировать кадры.
23,976 -> 24 можно также сделать ускорением звука.
24 догонять до 30 или 60 можно попробовать каким-нибудь современным интерполятором с поиском и компенсацией движения — через VapourSynth и svpflow1+svpflow2, через Avisynth и FrameRateConverter+MaskTools2+MvTools2, можно через RIFE-нейросетку и VapourSynth.
См.
https://www.svp-team.com/wiki/Manual:SVPflow
https://github.com/mysteryx93/FrameRateConverter
https://github.com/HomeOfVapourSynthEvolution/VapourSynth-RIFE-ncnn-Vulkan
Коммерческие (ну, в смысле, сосвем дорогие) решения тоже стоит рассмотреть. Они чудес, ясное дело, не творят, но разрабы бесплатных и недорогих решений скромно упоминают, что среди коммерческих решений могут достигаться результаты более высокого качества.
>floating-point 32 бита
А если я открою mp3 в редакторе (открылось в 32 bit floating point и 44100 Hz), и пересохраню его через редактор во flac с оригинальной частотой дискретизации (44100) и в 16 бит, то что будет? При экспорте во flac редактор не даёт выставить 32 бит, максимум 24. Но 24 не кратно 32.
Или как то заставить его использовать из папки
надеюсь скоро введут его поддержу на двач, на других бордах есть
От других кодеков есть исходный код, а qaac закрытый. В теории, можно добавить поддержку в ffmpeg через общую dll, но наврядил это кто-то сделает. Fdk примерно такого же качества, только не забудь написать -cutoff 20000. Вот готовый билд, он собирается гитхабом так что вирусы невозможно добавить https://github.com/AnimMouse/ffmpeg-stable-autobuild/releases
Так что или отдельно прогоняй qaac, а потом вставляй файл в ffmpeg, или пользуйся fdk
>>3004244
Не введут, браузеры не поддерживают. Av1 годнота, бесплатный и лучше чем h265
> qaac закрытый
Не закрытый https://github.com/nu774/qaac/releases просто от эппловских компонентов зависит, в чём проблема аудиодорожку через него прогнать, а видео через ffmpeg я вообще не представляю.
Там нужно пердолится с visual studio и cmake.
я не хочу visual studio ставить только ради этого
может у кого-то есть скомпиленная версия
> Твое ухо даже больше 14 бит не услышит, лол
А это тут внезапно не причем.
Клипинг - это такое искажение звуковой волны, из ряда нелинейных искажений, когда усиленный сигнал не влазит в сетку квантования, и вышедшие за пределы сетки отчеты квантуються максимальным или минимальных значением из этой сетки, что и порождает необратимые нелинейные искажения.
При декодировании lossy они появляются из-за того что при lossy кодировании волна кодируеться не точно, возникает как правило на месте отчетов с близкой к максимальной амплитудой. Но есть способ избежать клипирования при декодировании из lossy: декодировать в floating-point формат. И разрядность 32 бита здесь из-за особенностей представления чисел во float, так как точность представления числа в нем нелинейна, и чем больше число -тем меньше точность его записи во float. Потому для корректного представления отчетов с оригинальной глубиной 16 бит до lossy кодирования, 16 разрядного float будет мало, надо переходить на 32-х разрядный.
>>3003926
Не могу ручаться за твой редактор, поэтому позаботься предварительно сделать лимитироване (разновидность компрессии), или нормализацию, что-бы сигнал никогда не превышал уровня 0 Дб.
> H.265 не будет в браузерах. Твёрдо и чётко
Он как раз и нужен так как жмёт без артефактов хорошо с малым размером файла
Однако, хороший вопрос был.
> mp3 во flac
Я так понимаю, стоит задача привести закодированную звуковую дорогу в вид, понимаемый почти любым видео- или звуковым редактором.
Попробую дать исчерпывающий ответ на вопрос.
Итак,
> чтобы не потерять в качестве
Я так понимаю, что стоит задача избежать (или минимизировать) дополнительных искажений при восстановлении сигнала.
> частоты дискретизации
Стандарт ISO/IEC 11172-3:1993 (тот самый MPEG-1 Layer III) предусматривает (нет на руках учтённой или полной копии стандарта — на страницу и пункт указать не могу) следующие варианты частот дискретизации: 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100 и 48000 Гц.
Вот эти почтенные доны >>3002864>>3003338 правы, когда рекомендуют оригинальную частоту дискретизации сохранить. Разумеется, если целевой формат позволяет (например, некоторые применения не позволяют использовать частоту дискретизации, отличную от 48 кГц).
> sample_fmt s16
> floating-point 32
А сколько это в битах. Для начала скажу, что стандарт ISO/IEC 11172-3:1993 не устанавливает конкретного числового представления восстановленного сигнала. Т. о. можно этот самый MP3 декодировать через обратное модифицированное ДКП хоть в целочисленные выборки, хоть в выборки дробные. Конкретно ffmpeg имеет на этот случай два декодера: https://pastebin.com/act3bafA — mp3 и mp3float. Последний используется по умолчанию. Т. о. во избежание дополнительных ошибок округления, следует использовать (как рекомендовал >>3003338) flt или fltp — https://pastebin.com/YehZeeZ6
Мантисса в дробном числе одинарной точности будет целых 23 бита занимать. Опять же, необходимо иметь в виду, что не все программы поддерживают представление отсчётов звуковых дорожек в дробных числах с плавающей запятой.
Впрочем, если нужна звуковая дорожка с целочисленными отсчётами, то для ffmpeg можно указать целочисленный декодер явно:
$ ffmpeg -c:a mp3 -i input.mp3
Имя декодера указывается ДО имени входного файла.
>>3003338
> Здравствуй клипинг
Не обязательно. Целочисленный декодер должен уметь в нормализацию.
>>3003311
Ну, не все монтажки такие же всеядные как ffmpeg.
>>3003926
https://en.wikipedia.org/wiki/FLAC
> The FLAC format supports only integer samples, not floating-point.
Опять же:
$ ffmpeg -h encoder=flac -hide_banner
> А если я открою mp3 в редакторе (открылось в 32 bit floating point и 44100 Hz)
В памяти будет лежать дробными числами.
> пересохраню его через редактор во flac с оригинальной частотой дискретизации (44100) и...
Преобразование дробных чисел в целые с округлением.
> Как внести в базу ффмпега аудио библеотеку qaac?
Никак. Кодер qaac — это CLI-обёртка для библиотек Яббла.
> как то заставить его использовать из папки
Если хочется qaac, то берёшь WINE настоящий Шиндовс, ставишь на него библиотечки Яббла, ставишь qaac. Потом, указываешь и тому и другому, что обмен пойдёт через формат ADTS/WAV (обе программы его понимают и умеют правильно записать и прочитать заголовок, что избавит тебя от явного указания расположения каналов, частот дискретизации и всего такого), указываешь, что ffmpeg будет в stdout писать, а qaac будет из stdin читать, собираешь конвейер, кодируешь.
>>3004202
>Твое ухо даже больше 14 бит не услышит, лол
Специалисты по психоакустике в треде — все в Институт им. Фраунгофера!
>>3004243
>А другие кодеки как там оказались
Свободные программисты понаписали.
> встроенный аас говно
Говно у тебя в головушке. А встроенный вполне. Он убогий, да, но вполне. Если не хватает встроенного, то (как уже сообщил >>3004296) есть внешний слинкованный libfdk_aac — полнофункциональный и весьма качественный кодер из libfdk от той самой лаборатории из Института им. Фраунгофера.
> Я гуглил и нашел как чел закинул в папку qaac ффмпег библеотеки, но не могу понять как выполнить команды
Сам по инструкции не можешь элементарный конвейер собрать, а встроенный кодек уже критиковать научился.
>>3004297
> в чём проблема аудиодорожку через него прогнать, а видео через ffmpeg я вообще не представляю.
Нет никакой проблемы. Берёшь и прогоняешь.
>>3004357
> При декодировании lossy они появляются из-за того что при lossy кодировании волна кодируеться не точно, возникает как правило на месте отчетов с близкой к максимальной амплитудой. Но есть способ избежать клипирования при декодировании из lossy: декодировать в floating-point формат.
Не мог бы ты предоставить ссылки на источники столь увлекательной информации???
>>3004454
Кстати, да. Тоже часто задаю этот вопрос гражданам с ограниченной вменяемостью.
>>3004457
Это по границам единиц потока. Для видео с компенсацией движения такой единицей будет группа изображений (GOP), для звуковых дорожек будет окно преобразования (frame).
>>3004637
Тоже пишешь пост по секретным документам???
совсем ничего не понимаю в ffmpeg,
пытаюсь соединить много файлов в один видео файл путём такой компанды
ffmpeg -f concat -safe 0 -i list.txt -c copy out.mp4
но получается Non-monotonous DTS
Если использую программу MP4Joiner, то итоговое видео имеет глюки со звуком и изображением
как соединить ролики в один, чтобы не было глюков со звуком и изображением.
перед соединением конвертировал частоту кадров у всех до 60, и разрешение до 1080p
помогите, пожалуйста
> Не мог бы ты предоставить ссылки на источники столь увлекательной информации???
Все источники помнить не могу, но вот который я еще помню
https://audiophilesoft.ru/publ/my/aimp3_vs_foobar2000/11-1-0-255
Статья старая, те косяки которые там перечислены в AIMP наверно уже подправили.
Вот интересующий фрагмент:
> Здесь я хотел бы еще раз вернуться к декодированию. В AIMP поток от декодера идет в формате 16 бит, а следовательно, при наличии превышения уровня в источнике (скажем, MP3), сразу же происходит клиппинг, и никакие лимитеры уж не помогут. У foobar2000 же есть масса методов борьбы с клиппингом — ReplayGain, Advanced Limiter и другие DSP, регулятор громкости. В случае вывода через WASAPI shared (DS) сработает лимитер Windows, или опять же можно воспользоваться занижением громкости для приложения в микшере Windows. AIMP же лишен всех этих возможностей (несмотря на наличие поддержки ReplayGain и ограничителя — всё это сводится на нет из-за декодирования с фиксированной точкой).
Кроме того, я специально для тебя погуглил, что-бы найти ещё источники.
https://forum.audacityteam.org/viewtopic.php?t=96603
> MP3 is an inexact format. If the peak level before encoding is close to 0 dB, then the peak level after encoding may be a little over 0 dB. This is particularly the case if the audio has been heavily limited or compressed. The actual amount of clipping caused by this effect is usually just isolated samples, though there may be a lot of them, so the clipping can look bad while not actually being audible.
https://audiophilesoft.ru/forum/3-141-1
> При кодировании любого файла в lossy формат происходит повышение уровня пиков и чем выбранный битрейт ниже, тем выше этот пик становится. Например при кодировании в MP3 кодером LAME с параметром -V 0 для того, чтобы пиковая громкость не выходила за "0" я нормализую средний трек до -1db. Объясните пожалуйста почему это происходит и необходимо ли с этим бороться? На слух вроде бы не слышно, но если вдруг потребуется провести новое кодирование с этим треком, то что выше "0" не будет учтено при кодировании, если например не нормализовать предварительно MP3 Gain.
> потому что при кодировании происходит квантование составляющих по амплитуде, в итоге получается ошибка квантования, которая может суммироваться и при декодировании сигнал будет иметь большую амплитуду, чем исходный. декодирование lossy - это синтез.
Ладно, допустим источники недостоверные. Но это можно проверить и самостоятельно (см. пикрелейтед, красные линии - индикатор клиппинга).
Изначально в вещательной системе NTSC была частота кадровой развëртки ровно 60 Гц (60 полей в секунду). При разработке цветного варианта NTSC выяснилось, что частоту следования полей необходимо немного понизить, чтобы сузить полосу сигнала цветовых компонент, и спектры цветовых компонент и звукового сигнала не пересекались. Стала частота следования полей 60000/1001 Гц. А потом благодаря хитрой схеме телекино аналогично пришлось замедлить показ кинофильмов, подготавливаемых к демонстрации в вещательных системах NTSC.
>>3005299
по-человечески это без пердолинга с консолью http://ffqueue.bruchhaus.dk
https://audiophilesoft.ru/load/coders_utils/qaac/7-1-0-50
Только в ней нет библиотек FLAC, WAV и др, она просто не откроет входные файлы
Например вот тут:
> ffmpeg -i input.mp4 -i image.jpg -filter_complex "[0:v][1:v] overlay=400:200:enable='between(t,0,10)'" -pix_fmt yuv420p -c:a copy output.mp4
О какой хороший тред.
И тут явно сидят спецы по смежной софтине - YOUTUBE-DL
Собсна, вопрос. Давече напердолил скрипт для автоматической подгрузки новых видео с каналов (спасибо 4k video downloader что поломал эту функцию), но как всегда что-то пошло не так.
С начала работы вылезает вот такая вот залупень:
[youtube:tab] Downloading login page
[youtube:tab] Looking up account info
WARNING: Unable to look up account info: HTTP Error 400: Bad Request
Дальше работает, но я незалогиненый. Хотя я про куки не забыл, логин-пароль правильный.
ЧЯДНТ?
FFmpeg может работать с несколькими медиа файлами одновременно. Медиа файл представляет собой контейнер, содержащий медиа потоки.
Каждый файл на входе пронумерован. Нумерация файлов в FFmpeg начинаеться с нуля.
Нумерация потоков также начинаеться с нуля. Но потоки также различаються типом:
аудио-поток: a
графический поток (видео или изображение): v
поток субтитров: s
Потоки каждого типа тоже нумеруються. Если номер не указан, беруться все потоки даного файла или все потоки даного типа.
К чему я всё это расказываю? В FFmpeg есть ключ -map. Он выбирает входной медиа поток для выходного потока. Примеры:
-map 0 - взять все медиапотоки из первого файла
-map 0:0 - взять перный поток из первого файла
-map 0:a - взять все аудиопотоки из первого файла
-map 0:a:1 - взять вторую аудио дорожку из первого файла
-map 0:v:0 -map 0:a -map 1:s - взять первый видеопоток из первого файла, взять все аудиопотоки из первого файла, взять все субтитры из второго файла.
-map 0 -map 1:s - взять все медиапотоки из первого файла, и взять все субтитры из второго файла.
Этот код в фигурных скобках означает то-же, что и аргументы ключа map.
> [0:v][1:v]
> -map 0:v -map 1:v
берет все видеопотоки (изображения) из первого и второго файла.
Я тупой
(Гуманитарий)
Напишите скрипт для сабжа чтобы переделать все файлы mp4 в папке из 1080p в 720p
С меня как обычно
"C:\Youtube-dl\youtube-dl.exe" --skip-download --username example@gmail.com --password HuyTebeANePassword --cookies "D:\Desktop\Apps\Youtube-dl\youtube.com_cookies.txt" --ignore-errors --no-continue --no-overwrites --download-archive "D:\Desktop\Apps\Youtube-dl\archive.txt" --output "D:\Downloads\Youtube\(title)s.(ext)s" --format "bestvideo[height<=1080]+bestaudio/[height<=1080]" --batch-file "D:\Desktop\Apps\Youtube-dl\Channels.txt" > D:\Desktop\Apps\Youtube-dl\log.txt 2>&1
Пытаюсь кропать видео:
> ffplay -i .\input.mp4 -filter:v "crop=1080:800:415:130" out.mp4
выдает: Failed to set value 'crop=1080:800:415:130' for option 'filter:v': Option not found
Приходится ffmpeg'ом, но хочется сразу на результат смотреть.
блин, ну я точно помню что уже так делал. применял эффект к воспроизведению через ffplay. просто недавно переустановил шиндовс (новый ссд купил, все такое) и чет перестало.
видео в котором чел показывает что такое бывает https://www.youtube.com/watch?v=0CqBRUirGOA
Спасибо за столь развёрнутый ответ.
>Преобразование дробных чисел в целые с округлением.
Получается мне никак не избежать округления, если я хочу использовать flac? Но поскольку
>Целочисленный декодер должен уметь в нормализацию.
я не потеряю в качестве, верно?
При каких обстоятельствах целочисленный декодер может не уметь в нормализацию? Нормализацию имеет всё достойное современное ПО?
Может вопрос вызовет попоболь у пердоликов, но всё же.
Посоветуйте хороших, годных конвертеров. Сам юзал только Wondershare и FormatFactory, но первый иногда пидорасит папки BD и DVD и вообще надо подбирать версию чтоб не крашилась. Второй вообще годится максимум для конвертирования из видео в mp3.
Может есть что-то более универсальное, кроме сабжа?
вондершар - это же редактор фильмора э. н больше для вставки свистоперлелок в видосы
формат фактори - не ебу, что это часто слышу.
да. проще всего конверлить через ffmpeg. если ты не знаешь/не хочешь использовать специфичные опции, которые нужно гуглить.
а колдовать и играться с настройками видео можно в XMediaRecode
Давайте по факту. Лично у меня 2 конечной цели сжатия: 2ch с ограничением 20 мб в /b/ и discord с ограничением 8 мб на серверах без бустов. Ни тот, ни другой не поддерживают hevc, вроде потому что на html5 (поправьте), так что выбор у меня из avc и vp9, поэтому я ставлю на ночь vp9 veryslow и иду спать.
Youtube в размере не ограничивает, поэтому если бы я был блоггером, то просто просирался бы большим битрейтом на avc через gpu, благо youtube сам его рекомендует.
Twitch просто ничего кроме avc не поддерживает и до кучи ограничивает битрейт 6 мбит/с, так что у стримеров вопрос не в кодеке, а в железе.
Куда ещё жать-то?
Книжки читать умеют все. Этому в школах учат.
А как работать с безгуйными приложениями не научат нигде, этому надо долгие месяцы обучаться, не отвлекаясь ни на что другое. Ну или вернуться на 20 лет назад и попросить родителей чтобы тебя отдали в школу где этому учат, а таких немного.
>А как работать с безгуйными приложениями не научат нигде, этому надо долгие месяцы обучаться, не отвлекаясь ни на что другое.
И там текст и там текст. Читаешь, понимаешь, пишешь. И понимать прочитанное, и следовать определённым правилам при написании в школе учат.
>У ffmpeg за 20 лет гуя нет, как им пользоваться?
https://ffmpeg.org/ffmpeg-all.html
Вот тут все команды. Просто вводишь в консоль нужную. Если не нашёл/не понял - обращайся к поисковику, на сторонних сайтах бывают готовые решения под конкретные прикладные задачи.
>>3007992
Потому что это поколение и правда ничему такому не учили, тяжело им будет на готовых скриптах жить в эпоху говнософта.
>>3007904
Проблема-то ещё в том что всё это коммьюнити секта свидетелей опенсорса и "безгуйных" приложений - самое токсичное во всём Интернете. Если чего-то не нагуглишь или не поймёшь - хуй тебе кто поможет, ещё и неосилятором назовут, а то и пидором (а это хуже всего, потом кличка такая будет).
Я сжимаю хэндбрейком, а тут говорили, что это гуи ффмпега >>2998143
>Потому что это поколение и правда ничему такому не учили
Чему там учить? Открыть cmd и вписать команду? жмешь win+r и пишешь cmd. Все. Ты гуру.
>секта свидетелей опенсорса и "безгуйных" приложений - самое токсичное во всём Интернете
Сравни здешние треды винды и линукса по "токсичности". На гитхабе в issues так вообще лепота и милота.
Но никто талдычить и разжевывать одно и то же человеку не способному в мануалы ленивому пользователю с желанием сделайте мне хорошо не будет. Народ же не индусы поддержки майкрософта/яблока, а программисты/продвинутые пользователи с альтруистическими настроениями. Прост лентяя, не могущего инструкцию вводную прочитать никто не держит, ибо он не нужен, только время крадет. С вменяемыми людьми всегда просто и легко все получается.
>>3007904
меня тоже никто ничему такому не учил. просто не для всего софта выполняющего задачи эффективно, есть гуй. и с этим рано или поздно сталкиваешься.
ключевое тут "эффективно".
можно для элементарнейших, по сути, задач типа обрезки или кропа видео загружать пиздецки прожорливый комбайн от Adobe.
при использовании ffmpeg со временем набивается рука и в черновик записываются типовые сниппеты нужные только тебе и это сильно упрощает всё.
пока найдешь в том гуе где какую галочку нажать и куда значение вводить с ума сойдешь. а если оно еще и не вводится по какой то причине или все работает "не так как должно" по тому что где то что то не так нажал и/или не в том порядке. оой бля. можно бесконечно продолжать.
> этому надо долгие месяцы обучаться
нет, надо просто столкнуться с проблемой. премьер про тоже долго надо обучаться. да и в общем, всему надо долго обучаться.
>>3008106
>Прост лентяя, не могущего инструкцию
двачую адеквата
Двачую, набил руку в онемешных вебм тредах, по работе несколько раз пригождалось быстро сделать всякую хуйню типа обрезки, наложения сабов, конвертирования в заданные размеры с макс качеством. С гуевым софтом ебался бы значительно дольше
>жмешь win+r и пишешь cmd
С зажатой клавишей шифт кликаешь правой кнопкой мыши по папке где лежит софтина и кликаешь на пункт "открыть командную строку здесь."
Или же открываешь саму папку, в адресной строке пишешь cmd и enter.
В Classic Shell вообще божественная фича есть, кнопки "открыть командную строку" и "открыть командную строку от админа".
Когда совсем юзверем был долго думал над тем как путь к эксешнику нужному указать, там же по дефолту System32 открывается.
Я не знаю, может только мне такие мудаки попадались, но с проблемой выше мне только один человек из целого чата помог разобраться. Хотя может и правда чат такой был.
А еще лучше используешь пикрил. Я от себя рекомендую PRE версию. Пока до релиза штуки дойдут (если дойдут), поседеешь. Ну как обычно.
https://github.com/microsoft/terminal
Пытаюсь заставить современную аниму (mkv hevc + flac+встроенные субтитры .ass) работать на встроенном плеере старого самсунг смарт тв.
Подобрал подходящие видео и аудио кодеки (-c:v libx264 -c:a aac) но вот с субтитрами какая-то хуйня.
Ели их вырезать (-sn) то все работает, а вот если оставить то телевизор просто вырубается к ебени матери при попытке проиграть файл (на компе все работает)
И хотя в документации и написано что встроенные в .mkv .ass должны поддерживаться, но судя по результату - нихуя.
Может это я туплю и при изменении видео\аудиокодека нужно каким-то образом переформатировать и субтитры?
Что можно с ними сделать чтобы они таки заработали?
>>3008322
ffmpeg -hwaccel dxva2 -i "1.mp4" -c:v libaom-av1 -cpu-used 6 -crf 24 -b:v 0 -pix_fmt yuv420p10le -lag-in-frames 19 -tile-columns 2 -tile-rows 1 -threads 8 -aom-params enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1 -pass 1 -an -f null -
ffmpeg -hwaccel dxva2 -i "1.mp4" -c:v libaom-av1 -cpu-used 6 -crf 24 -b:v 0 -pix_fmt yuv420p10le -lag-in-frames 19 -tile-columns 2 -tile-rows 1 -threads 8 -aom-params enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1 -pass 2 -c:a libopus -b:a 160k -filter:a "aresample=48000:resampler=soxr:precision=33" "out.webm"
https://www.reddit.com/r/AV1/comments/lfheh9/encoder_tuning_part_2_making_aomencav1libaomav1/
>>3008452
-vf выдавал ошибки поэтому в результате сделал через -filter_complex "subtitles=видос.mkv"
Все работает.
>>3008480
Да я сначала тоже думал что ебал я в рот каждый раз этим заниматься, да еще и для каждого файла.
Но после десяти минут гугла наткнулся вот на этот гуй sourceforge.net/projects/ffmpeg-batch/ в котором без особых проблем запилил себе универсальный пресет, способный любую современную аниму (в любом количестве) переварить в подходящий для моего тв вариант за два клика.
Мне нраица.
> Как?
Два прохода, сначала создастся промежуточный файл transforms.trf, потом непосредственно штабилизация:
ffmpeg -i video.mp4 -vf vidstabdetect -f null -
ffmpeg -i video.mp4 -vf vidstabtransform=smoothing=5:input="transforms.trf" -c:v libvpx-vp9 -b:v xxxK -crf 4 -c:a libopus -b:a xxK video_stab.webm
понятно, если в шебм пожать хочешь
> Охуеть, оказывается ффмпег может взять и неплохо стабилизировать трясущийся видос, гамму может подкрутить, обрезать кусок кадра. А может ли он превратить дёрганые 30фпс в плавненькие 60? Древние 176х144 апскейльнуть в фуллхд лол? Или это нейросеть нужна, чтобы недостающие кадры и детали дорисовывать? А эффект типа HDR у него есть, чтобы не было пересветов и затемнённых участков? А подавление шума без "целлофана"?
>А, ты ещё
Какое "ещё"? Я только один пост в вашем обсуждении написал.
>ты ещё и этим божественным магазином не пользуешься
Конечно не пользуюсь. После удаления службы центра обновлений эта хуйня не работает. В принципе он бесполезен, так что похуй.
>10 говноедов из 10
Говноеды - это любители магазинов приложений. В магазине нет portable версий, чтобы иметь на устройстве несколько копий программы с независимыми настройками. При переустановки системы абсолютно не ясно, каким образом будут синхронизироваться данные. Ведь в случае с обычными бинарями я могу переписать файлы, а там наверняка какие-то облачные службы, которые могут не сработать, могут сработать криво, или могут не сработать потому-что моё поведение не понравилось барину и он счёл меня пердолей. И всё это говно привязано к кучи компонентов, которые так и норовят сломаться, и если это произойдёт, то ты потеряешь доступ к установке, переустановке и обновлениям приложений.
Не говоря уже о том, что там практически нет нормального ПО. Какая-то адварь, какие-то детские игрушки, браузеры мошенников, payware-мусор не умеющий ничего, uwp от Micro$oft, унылый кал от васяна - больше там ничего нет. Из +/- достойного софта могу выделить только EarTrumped и Windows Terminal. Первый является альтернативой дефолтному микшеру громкости, и я не вижу в нём ничего хорошего кроме дизайна, и сильно сомневаюсь в том, что он умеет в управление с клавиатуры и быстрый mute по нажатию клавиши. Второй лучше дефолтного cmd - красивее, можно gif-ки на задний фон ставить, вкладки есть, но сильно уступает ConEmu - нет поиска по тексту и нет размещения нескольких консолей внутри одного окна.
Чтобы компьютер служил мне, а не я служил компьютеру, постоянно переучиваясь к новым фичам/редизайну и постоянно решая проблемы вызванные обновами. Алсо, по несколько раз в месяц, вместо начала/завершения работы, ждать пока Windows завершит обновление - терпилизм-куколдизм, у меня есть более лучшие способы потратить время.
>многооконности нет
Ты про split panes? Так они есть, привет. https://docs.microsoft.com/en-us/windows/terminal/panes
> Поиска по тексту нет
И он тоже есть, деточка https://docs.microsoft.com/en-us/windows/terminal/search
И с вкладками тоже все впорядке. Они в том же окне открываются.
Хотя блять я же говорю с шизоидом который нахуято удалил службы центра обновлений (если я правильно понимаю о чем они).
Спойлер: а с появлением WSL все эти ConEmu и MinGW стали нахуй не нужны.
значит тебе не нужен. я же сказал что с его выходом всякие mingw нахуй стали не нужны. а вообще с выходом WSL2 для большинства задач теперь нет необходимости ставить виртуальную машину. там щас и аппаратное ускорение и возможность запустить гуй приложение линуксовое и все такое.
>>3009533
ну если ты такой еблан что тебе проще собирать руками из исходников чем установить из маркета то на гитхабе есть инструкция по сборке:
https://github.com/microsoft/terminal
и сходи к доктору. обязательно
> ungoogled-chromium
Странная хуйня происходит.
На виртуальной машине, по гайду с ютуба у меня получилось включить обновления и установить Windows Terminal (оказывается нужно было восстановить повреждённый реестр). Потом я пытался повторить успех на основной системе, но нихуя не вышло. Вернее служба обновлений заработала, метро настройки начали что-то качать, но Windows Terminal не хотел устанавливаться. Раньше при установке из того хитровыебанного файла он распаковывал свои файлы, у него изменялся прогресс-бар, а по окончанию приложение не запускалось. Сейчас же установщик вылетает в самом начале установке, после нажатия главной кнопки. Я решил скопировать каталоги, в которых Windows Terminal лежит на виртуальной машине, в основную систему. Я знал, что у меня это не получится. Но, как не странно, получилось.
они готовые msixbundle пакеты в ассетах выкладывают оказывается
For users who are unable to install Windows Terminal from the Microsoft Store
https://github.com/microsoft/terminal/releases/tag/v1.9.1445.0
https://github.com/microsoft/terminal/releases/download/v1.9.1445.0/Microsoft.WindowsTerminalPreview_1.9.1445.0_8wekyb3d8bbwe.msixbundle
но тогда обновления сами прилетать не будут
TL;DR: есть несколько видеофайлов, контейнер MP4, внутри видеопоток x264, настройки кодирования одинаковые. При склейке без перекодирования разные тулзы (Avidemux и MP4Joiner) выдают склеенное видео, в котором некоторые из кусков (разные, в зависимости от тулзы) повреждены. Первый ключевой кадр серый или фиолетовый, последующие ожидаемо идут по пизде. Отчего такое происходит? Какая-то проблема в исходных склеиваемых?
Полный текст, скопировано из соседнего треда:
Есть несколько файлов MP4, внутри которых видеопоток в x264. Все файлы с одинаковым фпс, одинаковым размером кадра, и закодированы с одними и теми же настройками (отвечаю, лично делал). Знаю, что в таком случае можно склеить их в один видеофайл без перекодирования.
Но это ожидание. А реальность:
Avidemux (в режиме copy для видеопотока) выдает файл, в котором некоторые из этих кусков (именно некоторые) заполнены мусором вместо реального содержимого кадров. Такое впечатление, что первый ключевой кадр в начале такого куска просто залит серым, и все остальные кадры за ним идут по пизде. Потом картинка снова становится нормальной в момент переключения на следующий кусок, который обработан нормально.
MP4Joiner из MP4Tools (который является просто гуишной оберткой над какой-то cli-утилитой для работы с mp4) часто делает то же самое, но при этом "поврежденными" оказываются некоторые другие куски из того же набора. Какой-либо зависимости, какие именно куски повреждаются, я не увидел.
Если склеенный видеофайл был создан MP4Joiner'ом и там каким-то чудом все куски не повреждены, то в видеоплеере (любом, по дефолту юзаю MPC-HC) он воспроизводится нормально, а вот при открытии Avidemux'ом вижу ту же хуету с серыми кадрами.
Если закинуть все куски в Avidemux и склеить их С перекодированием (режим не copy, а выбор одного из кодировщиков), то получается нормальное видео, но в моменты переключения с одного куска на другой видео при воспоизведении как будто подвисает на пару кадров (в том же MPC-HC). "Зависание" заметно невооруженным глазом. Шагал по нему покадрово - там нету дублирующих кадров. Может быть такое, что у какого-то кадра (например, первого или последнего в куске) длина отлична от указанного фпс?
Вот залил для примера четыре куска: MP4Joiner справляется, Avidemux делает поврежденные куски в итоговом видео (кадр залит хуетой). Если их совместить в MP4Joiner и открыть в Avidemux, видео там начнется с поврежденного куска, залитого серым, хотя видеоплеер справляется.
Куски 1, 2 и 4 - пикрелейтед, 3-й не влез в пост (лимит 40 МБ), так что вот 3-й отдельно: https://www106.zippyshare.com/v/PRc4ujMt/file.html
(да, это тот самый жанр видео ¯\_(ツ)_/¯)
Предупреждая вопрос: нахуя я вообще с этим ебусь, почему не делать в видеоредакторе - потому что хочу взять поток кадров из видео и просто создать видео с 15 фпс, т.е. замедлить и заодно сделать сам "проект" в 15 фпс. В простых редакторах типа Avidemux и VirtualDub это делается легко, в тяжеловесных - более муторно, к тому же фпс у исходных видеофайлов с телефона почему-то равен примерно 29.xxx и является variable, колеблется от 29.xxx до 30.xxx. Я хз, что это за хуета, и не является ли она источником проблемы.
Апдейт:
В соседнем треде посоветовали склеить ffmpeg'ом. Сделал по инструкции отсюда: http://trac.ffmpeg.org/wiki/Concatenate#demuxer
ffmpeg -f concat -safe 0 -i D:\folder\list.txt -c copy result.mp4
Вроде бы все прошло успешно, ffmpeg осилил эти исходные куски, проблем с воспроизведением и артефактами в получившемся файле вроде бы не наблюдаю.
Однако почему-то у склеенного ffmpeg'ом файла характеристики fps такие:
Frame rate mode : Variable
Frame rate : 15.000 FPS
Minimum frame rate : 14.851 FPS
Maximum frame rate : 15.000 FPS
В то время как у всех четырех исходных, из которых склеивал, они такие:
Frame rate mode : Constant
Frame rate : 15.000 FPS
Исходные четыре файла - см. предыдущий пост >>3010546 . Склеенный ffmpeg'ом файл: https://www25.zippyshare.com/v/kihcYvT3/file.html . Как так получилось, чем это грозит и как (и надо ли) исправлять?
Спасибо, помогло. MKV действительно получился с constant frame rate.
Но если я потом ремуксю его в MP4, снова вылезает эта хуйня:
Frame rate mode : Variable
Frame rate : 15.000 FPS
Minimum frame rate : 14.856 FPS
Maximum frame rate : 15.152 FPS
делал так: ffmpeg -i concatenated.mkv -codec copy remuxed.mp4
При этом длительность в миллисекундах одинаковая (в данном случае, 50.333 с)
Если же я открываю получившийся MKV в Avidemux'е и ремуксю в нем (режим для видео: copy, аудиодорожки нету), то таки получается MP4 с константным фпс:
Frame rate mode : Constant
Frame rate : 15.000 FPS
... но зато длительность превращается в 50 s 334 ms . Откуда, если с константным фпс 15.000 может получиться 50.333 с, но никак не 50.334?!
Понимаю, что это невероятная мелочь, и в принципе получившийся MP4 меня устраивает – 15.000 фпс, нет фризов, как описывал выше, везде воспроизводится – но уже просто спортивный интерес докопаться до сути проблемы.
В этом примере result.mp4 - тот файл, который получился после
ffmpeg -f concat -safe 0 -i mylist.txt -c copy concatenated.mp4
... или тот, который получился ремуксом из mkv в mp4?
ffmpeg -i concatenated.mkv -codec copy remuxed.mp4
Насчет именно ффмпега не знаю, но в целом проблема в том, что в кодировании видео (почти) любым кодеком некоторые кадры - так называемые ключевые - сохраняются полностью, а остальные - только как разница между этим кадром и предыдущим. Поэтому если у тебя поврежден (или вовсе отсутствует) ключевой кадр, все остальные кадры до следующего ключевого будут также повреждены.
Если ффмпег насильно разрезает видео ровно по указанному таймкоду, то, скорее всего, начало фрагмента попадает на обычный (не ключевой) кадр, поэтому наблюдается то, что ты описал. Нужно резать с ключевого кадра, если хочешь вырезать без перекодирования.
Как посмотреть точный номер ближайшего ключевого кадра - хз, думаю, тебе кто-нибудь подскажет для ффмпега, но вообще лично я для вырезания кусков из фильмов использую MKVToolNix, в нем принудительно режется начиная с ключевого кадра.
Нет, ты можешь вырезать кусок без перекодирования с небольшим запасом (секунд 5-10 до нужной тебе точки и секунды 3 после). После чего работать уже с этим небольшим файлом и делать с ним что угодно, в т.ч. взять из него кусок ровно-ровно с нужного тебе кадра и закодировать его в вебм, ну или что там тебе надо.
Вебм (вернее, кодек внутри вебм) тоже содержит в себе ключевые кадры и обычные кадры. Практически все кодеки для повседневного применения так устроены. Это не баг, это фича.
- 2 дорожки без перекодирования в оригинальном формате (ac3)
- субтитры (хуй знает что за формат).
Как достать? Что писать?
Думаю записать просто прохождение эпизодами до определенных моментов БЕЗ микрофона и голос записывать отдельно. Как идея? Как бы вы это дело организовали?
Ну и собственно если я все таки решу делать так как сказал выше, есть какая-нибудь более lighweight альтернатива для Premiere Pro комбайна которая подойдет для этих целей? Так чтобы звук можно было записывать там же, как в премьере и вот это все.
Поясните за AV1. В частности, его ресурсоемкость. Всюду приводят его как самый лучший по сжатию формат с графиками, показывающими его охуенность, но эту характеристику почему-то обходят стороной. В общем, попробовал я это шило и не могу понять: в чем СЕЙЧАС его профиты, в практическом плане? Скорость кодирования неоправданно низкая, даже на разогнанном до усрачки i7 последних лет, 0.2-0.3 фпс для 1080p. Профит в 30% лучшего сжатия по сравнению с VP9 не стоит таких мучений. Даже 10-минутное видео можно кодировать сутки и более, как нехуй. В этом плане напоминает разновидности чисто академических алгоритмов lossless сжатия данных, таких как PAQ: максимальное сжатие при совершенно непрактичных объемах затрачиваемого процессорного времени.
Собственно, интересует, почему именно AV1 считают массовым форматом будущего? Существуют ли уже аппаратные реализации кодирования, обеспечивающие приемлемую скорость кодирования при том же качестве и степени сжатия, какие обеспечивает референсная программная реализация (libaom)? Хотел бы увидеть список, а то инфа гуглится противоречивая.
Ящитаю, никогда ПК не осилит реализацию AV1 на уровне референсного соотношения битрейта/качества, выдаваемого libaom. Даже всякие серверные камни с 300+ Вт TDP тут мало чем помогут. Будет так же как было с VP9: например, intel добавили в свои камни аппаратный энкодер, который кодирует очень быстро, но сжатие очень плохое, файл будет на ~60% больше размером чем программный энкод с libvpx-vp9, при том же качестве видео. От чего профиты формата в значительной мере нивелируются.
>>3015372
h264 скоро уже 20 лет будет, между прочим. Он как mp3 в сфере аудио. Плюсы и минусы соответствующие.
>>3015484
Не согласен. Гугл и нетфликс не стали бы вкладывать вагоны денег в разработку AV1, если бы не было значительных экономических профитов от пониженного битрейта. Учитывая объемы трафика и постоянный рост популярности стриминговых сервисов, их можно понять. А энкод для всяких ютубов быстро и эффективно делается на ASIC'ах, недоступных массовому рынку.
> Не согласен. Гугл и нетфликс не стали бы вкладывать вагоны денег в разработку AV1, если бы не было значительных экономических профитов от пониженного битрейта
А какие экономические выгоды от видео, которые пользователь не может посмотреть ввиду сложности декодирования? Профит тут скорее для тех, кто может себе позволить 32к телевизор и ферму для декодирования 32к видео в реальном реалтайм времени, чтобы подрочить на чёткость. А смешные видео с котиками как казали в 480p на ультрафасте, так и будут казать, не смотря на то, что можно кратно сэкономить трафика.
Jpg не поддерживает сжатие без потерь. Лучшее качество это 100%, но оно с очень маленькими потерями
>>3015305
AV1 не стоит на месте. Постоянно вводятся улучшения ускоряющие кодирование или улучшающие качество при таком же времени. Создаются новые кодировщики, которые работают ещё быстрее (rav1e, svt-av1). При некоторых настройках они уже обгоняют x265 по скорости. Дай этому кодеку время, и он оправдает себя.
> Профит в 30% лучшего сжатия по сравнению с VP9 не стоит таких мучений
VP9 не развивается, он давно заброшен. Av1 кодирует намного лучше и быстрее него. Справедливее сравнивать с x265
>не может посмотреть ввиду сложности декодирования?
Лолшто? AV1 поддерживается всеми более-менее актуальными браузерами, плеерами и устройствами последних 2-3 лет, и практически всеми новыми.
>>3015682
>ускоряющие кодирование или улучшающие качество при таком же времени
На том же железе? Нет. Это так не работает.
>Создаются новые кодировщики, которые работают ещё быстрее (rav1e, svt-av1)
Сравни их с libaom по битрейту при том же качестве. Это компромиссы, чудес не бывает.
>VP9 не развивается, он давно заброшен.
Совсем ебанулся? Его не "забросили", а финализировали. С целью чтобы все будущие программно-аппаратные энкодеры и декодеры были полностью совместимы друг с другом. Так рано или поздно делают с любым массовым форматом. Фактически, до финализации - это не готовый продукт.
AV1, безусловно, еще ждут допилы, но до того же VP9 ему как до Луны, в плане скорости он уступает на пару порядков, и никогда не приблизится. VP9 еще много лет останется стандартом де-факто для многих современных онлайн видеосервисов.
> плеерами и устройствами последних 2-3 лет
Ты очень слабо представляешь себе процент владельцев устройств "последних 2-3 лет" от общего числа пользователей, а что-то вроде 2650v2 дропает кадры всеми своими 16 потоками от 1080p av1
> На том же железе? Нет. Это так не работает.
Это так работает
> Сравни их с libaom по битрейту при том же качестве. Это компромиссы, чудес не бывает.
Вполне сравнимо, svt совсем немного хуже, но намного быстрее
> Совсем ебанулся? Его не "забросили", а финализировали. С целью чтобы все будущие программно-аппаратные энкодеры и декодеры были полностью совместимы друг с другом. Так рано или поздно делают с любым массовым форматом. Фактически, до финализации - это не готовый продукт.
Ты что несёшь, поехавший? Причём тут финализация? Av1 давно финализировали, но эндодеры продолжают допиливаться. Хуя ты шизоид
> AV1, безусловно, еще ждут допилы, но до того же VP9 ему как до Луны, в плане скорости он уступает на пару порядков, и никогда не приблизится. VP9 еще много лет останется стандартом де-факто для многих современных онлайн видеосервисов.
Он уже давно обогнал vp9, и в скорости кодирования, и в качестве, и в удобстве использования
Какой кодек эффективнее всего подходит для сжатия музыки с наименьшими потерями - aac или opus? Может быть ogg? Возможно ли улучшение сжатия и уменьшение потерь при использовании сторонних енкодеров, или ffmpeg жмёт хорошо? Если кодек не поддерживает частоту дискретизации оригинального файла, нужно ли перед кодированием этим кодеком менять частоту дискретизации у файла, и если да, то в каком ПО?
qaac
tvbr q100-127
https://github.com/nu774/makeportable
Скачиваешь сам qaac, батник, cкачиваешь айтюнс, скачаный айтюнс кидаешь в папку с батником, запускаешь батник. Далее в папку на скрине кидаешь qaac. Устанавливаем фубар, указываем где кодер, кодируем
> Возможно ли улучшение сжатия и уменьшение потерь при использовании сторонних енкодеров
В случае с opus, ffmpeg именно что сторонний, за кодирование opus отвечает opustools.
https://opus-codec.org/downloads/
Если пугает консолька, то можешь в фубаре добавить этот кодировщик с параметрами и всё делать мышкой.
Рекомендации по параметрам здесь:
https://audiophilesoft.ru/load/coders_utils/opus/7-1-0-66
Opus лучший вариант, лучше только xhe-aac
> Если кодек не поддерживает частоту дискретизации оригинального файла, нужно ли перед кодированием этим кодеком менять частоту дискретизации у файла, и если да, то в каком ПО?
Желательно поменять с помощью Sox, немного лучше качество. Это работает прям в ffmpeg, одну команду дописать
>>3018219
Ебанутый, зачем ты высираешь инструкцию когда есть готовый архив? https://audiophilesoft.ru/load/coders_utils/qaac/7-1-0-50
И вообще есть сомнения что aac лучше opus, судя по многочисленным тестам с hydrogenaudio
>>3018232
> В случае с opus, ffmpeg именно что сторонний, за кодирование opus отвечает opustools.
Ничего подобного, там используется один и тот же энкодер
чем ты его кодировать будешь?
> есть сомнения что aac лучше opus
у opus был обсёр по некоторым киллер семплам до версии libopus 1.3 на любом битрейте вплоть до 256 kbps.
> Ничего подобного, там используется один и тот же энкодер
Ты путаешь. libopus это сторонний кодировщик который можно скомпилировать с ffmpeg. Также у самого ffmpeg есть свой экспериментальный кодировщик opus.
>>2988393
Тикток лучше скачивать через утилиту из тикток треда https://2ch.hk/media/res/159114.html
Она как-то сурсы достаёт, вот https://ssstik.io и их прога
> чем ты его кодировать будешь?
Easy CD ripper
> Ты путаешь. libopus это сторонний кодировщик который можно скомпилировать с ffmpeg. Также у самого ffmpeg есть свой экспериментальный кодировщик opus.
Этот сторонний является официальным, точно такой же как в opustools. Этот экспериментальный не используется
Этот конкретно
>>3018644
Шиз, не понимающий разницу между encoder и converter, успокойся. Сейчас я сам тебе её разжую.
Encoder это программа или библиотека которая преобразует несжатые данные (WAV PCM) в данные закодированные (сжатые) в определенном формате. Encoder не умеет декодировать данные других типов, так как не содержит их декодеров.
Converter это программа, которая содержит в себе множество encoders, decoders, и управляет процессами декодирования и кодирования. Множество встроенных декодеров позволяет конвертеру принимать на вход данные из множества форматов, а множество встроенных encoders позволяет конвертеру выдавать на выходе файл одного из множества форматов.
Если сейчас начинать, к новому столетию дожму?
Проверяли уже с сжатие-тредах.
Повторное пережатие шкальных картинок как минимум не портит результат, как максимум - может сгладить артефакты старых алгоритмов.
> Суть в том, что это мыло гарантированно несёт не меньше инфы, чем шакальный оригинал. Этого знания достаточно, чтобы смело пережимать паки.
Оно гарантировано несёт меньше инфы, чем оригинал. Потеря поколений, не, не слышал. Покормил
Зелёный, эти дефекты не только остаются, а ещё добавляются новые
Cейчас взял vp9 и переконвертировал в av1. На первом графике видно, что общее качество видео стало незначительно, но лучше. Это как раз и есть исключения дефектов алгоритма, как я полагаю. Потом уже, отвечая на это >>3020266 , это и так очевидно, что никакого чуда не происходит и при повторном конвертировании av1 уже потеря качества.
К слову, тот факт, что при пережатии в av1 может вдруг стать меньше шакалов, виден невооруженным глазом с некоторыми файлами. Однако, не всегда это идет на пользу
> Это как раз и есть исключения дефектов алгоритма
Это дефекты алгоримов сравнения, которые мыло считают меньшим дефектом, чем квадрат.
> виден невооруженным глазом с некоторыми файлами
У тебя 4 картинки в пост помещаются, можно было и добавить для невооружённых глаз.
> кукарекаем о магии
Полагаю, для некоторых замена блочности и пикселей на мыльцо это действительно в каком-то роде маленькая чудо. Есть же солнечные люди, которые ветерочку радуются, или там, скажем, дождичку, кто сказал что в мире софтваре не может быть подобных?
>которые мыло считают меньшим дефектом, чем квадрат.
Как и наши глаза в некоторых случаях. И ты можешь сколько угодно читать мантры, что это не так и рассказывать свои фантазии про речки, но для меня в самом прямом смысле этого слова очевидно, что абу №2 выглядит лучше, чем абу №1
>Это дефекты алгоримов сравнения
This. Но мыло действительно меньший дефект - чем блочность. Просто ты к ней привык, как протобумеры привыкли к интелейсу.
> Потц, модель строится на несжатом видео. Несжатому видео не свойственны высокочастотные переходы между блоками. Эти высокочастотные переходы модель отправляет на мороз.
Здесь от высокочастотного перехода и не осталось ничего, о чём и речь.
Когда дефект - это видимая невооружённым взглядом блочность прямиком из 98, то дефектовка таких дефектов приводит к численно подтверждённому росту метрик и визуальному улучшению.
Что ав1 из воздуха вернёт потерянную информацию - это ты сам себе додумал.
>Добавление дефекта
О добавление дефекта речь может идти в случае аддитивной помехи. В случае со сжатием дефект - это декомпозиция изображения и отбрасывание маловажных, по мнению модели, элементов. И в этом контексте твои наивные умозаключения становятся не столь стройными.
Что ещё спизданёшь?
>сжатие
>отбрасывание
Бахни от av1)
Был бы он в обиходе может и бахнули бы, это недостатки вп9 ютуб тебе прямо с монитора на лицо спускает и отрицать хуёвость энкодера перестали уже самые отбитые фанатики, ав1 многие даже не начинали использовать, ввиду отсутствия поддержки, да и исжили себя вебм треды, в которых велась борьба за килобайты какчества. Потому и бахать не с чего.
Понадобилось микшировать несколько аудиофайлов в один. Использовал для этой цели sox с ключом -m - итоговый файл получился очень тихим, каждый из отдельных его исходников звучит громче. В ffmpeg с командой ffmpeg -i alex.aiff -i fred.aiff -i whisper.aiff -filter_complex "[0:0][1:0] amix=inputs=3:duration=longest" out.mp3 (вместо этих имён файлов у меня были другие, в количестве 8 штук) громкость осталась такой же тихой. Audacity предложил микшировать в моно, мне это не нужно, так как исходники в стерео. В другом редакторе получается клипинг. Есть ли способ микшировать несколько файлов с нормальной громкостью?
на левой вемб не моей внизу отображается тайтл.
через ffmpeg поставил тайтл правой вебм, но он не отображается.
что я делаю не так?
я вот об этом
Для этого нужно предварительно произвести интерполяция ближайшим соседом в 2 раза, а затем вручную подобрать уровень сжатия, который будет сглаживать лесенки правда, эфект от сглаживания будет нивелирован повышенной блочностью джипега.
Первая картинка сжималась с качеством 10, вторая с качеством 50.
Я додумался до использования пользовательской матрицы квантования для улучшения фильтрации и снижения потерь от сжатия.
Матрица квантования:
# This is table 0 (the luminance table):
4 3 2 4 99 99 99 99
3 3 3 5 99 99 99 99
3 3 4 6 99 99 99 99
3 4 6 7 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
# This is table 1 (the chrominance table):
4 5 6 12 99 99 99 99
4 5 7 13 99 99 99 99
6 6 14 99 99 99 99 99
12 13 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
Матрицы надо сохранить в текстовой файл и указать в качестве аргумента -qtables програмы cjpeg:
convert upsampled_nearest_neighbor.png ppm:- | cjpeg -qtables jpeg_qtable7.txt -sample 1x1 -quality %УРОВЕНЬ КАЧЕСТВА% -outfile test203.jpg
Первая сжималась с уровнем качества 5, вторая: 25.
>>3024480
В отм посте предсталено 2 пары картинок. Первая картинка в паре: оригинал в низком разрешени, вторая: интерполяция оригинала ближайшим соседом, пожатая джипегом. Джипег в даном случае выступает в качестве НЧ фильтра.
Не надо их конвертировать совершенно. Исходники для того и созданны, чтобы хранить их в оригинальном качестве, без пересжатия в хлам криворукими сжимальщиками. Сразу качай сжатое говно, например с 1337 в кодеке AV1 куча раздач. И лучше в него конвертировать, с помощью av1an какого-нибудь
На кого это рассчитано, лол.
> а как пойдёт в массы ввс?
VVC он не для веб-лохов, он для 8К блуреев, не боись, хорошо пойдёт, Декод HEVC запилили же. Просто браузероделы больны патентошизой, поэтому свои мыльные поделки пилят, а вот не было бы их, повторилась бы история с H.264.
>>3025866
Кодек в разработке, ебло. Этот кодек пилит серьёзный институт, сторудники которого собаку на медиа съели, это не веб-макаки говношлёпы, поэтому такая медленная разработка.
Пишу сюда оптимальные crf для популярных кодеков
Avc - 24-25
HEVC -26-28 если сильно места жалко, то можно и 30-32, разницу видно только если сложные сцены и с лупой смотреть
Vp8 - 24-26
Vp9 - 26-27
AV1 - 28-30 не люблю этот кодек, почему-то нормально кодировать в него умеют только сервера ютуба, а через ффмпег получается в десять - двадцать раз медленнее, а результат такой же что у хевк
avc кодек на ютубе ВСЕ!
Если раньше битрейт у 1080p avc всегда был выше на 10%-40% чем у vp9, то теперь он всегда ниже на 5%-20% чем vp9
Учитывая что и раньше битрейт у avc был занижен до предела, теперь качество станет ниже плинтуса.
Интернет становится быстрее, а гугл продолжает дешманить видео
Что за хуйню ты написал? crf зависит от разрешения, а не от кодека. Он по идее не отличается для разных кодеков. более новые кодеки будут выдавать лучше картинку при таком же размере. Чем больше разрешение, тем лучше оно сжимается
https://trac.ffmpeg.org/wiki/Encode/H.264#crf
Вот неплохие значения:
RF 18-22 for 480p/576p Standard Definition
RF 19-23 for 720p High Definition
RF 20-24 for 1080p Full High Definition
RF 22-28 for 2160p 4K Ultra High Definition
Вот неплохие параметры для AV1, кодирует не супер долго, но зато можно сжать качественнее чем x265. Можешь увеличить crf. Чем сильнее сжатие, тем больше AV1 выигрывает. Какой у тебя процессор?
ffmpeg -hwaccel dxva2 -i "1.mp4" -c:v libaom-av1 -cpu-used 4 -crf 24 -b:v 0 -pix_fmt yuv420p10le -lag-in-frames 35 -tile-columns 2 -tile-rows 1 -threads 8 -aom-params enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1 -pass 1 -an -f null -
ffmpeg -hwaccel dxva2 -i "1.mp4" -c:v libaom-av1 -cpu-used 4 -crf 24 -b:v 0 -pix_fmt yuv420p10le -lag-in-frames 35 -tile-columns 2 -tile-rows 1 -threads 8 -aom-params enable-qm=1:enable-chroma-deltaq=1:quant-b-adapt=1 -pass 2 -c:a libopus -b:a 160k -filter:a "aresample=48000:resampler=soxr:precision=33" "out.webm"
Прикладываю 6 минутное 720p видео с весом 8 мегабайт, сжатое с максимальными настройками AV1, с таким сильным сжатием практически весь текст читается! x265 вообще не вывозит такое, там кроме мыла ничего не остаётся.
>>3026606
StaxRip, куча настроек, опций, есть сравнение разных видео, очень крутая штука.
>>3026635
На каких видео ты это заметил? На новых? Даже с более низким битрейтом avc будет выглядеть лучше, он не размывает видео как ебаный vp9
График с битрейтами и 8 мб файл
>На каких видео ты это заметил? На новых? Даже с более низким битрейтом avc будет выглядеть лучше, он не размывает видео как ебаный vp9
Возраст видео роли не играет.
Из всех видео (около 20) которые я скачивал за последние пару дней, только один ролик имел битрейт у avc выше чем vp9 (~2600k vs ~1500k)
https://github.com/AnimMouse/ffmpeg-stable-autobuild
Тут ещё и FDK есть, вообще годнота