FFmpeg и общий кодирования видео тред №5 /ffmpeg/
Аноним (Microsoft Windows 10: Chromium based)
15/01/22 Суб 01:37:51
№1
В прошлый раз мы в кои-то веки не срались за кодеки весь тред, а культурно помогали друг другу с ffmpeg.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Самые ходовые видео-кодеки на данный момент - VP9 и H.264. Подробный разбор их режимов кодирования читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда: https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё медленнее.
Бонусом в треде обсуждается yt-dlp, если отдельного треда про него нет на доске в данный момент. Это опенсорс утилита для нормального выкачивания видео с ютуба, вк, порнхаба и ещё миллиона других видеосервисов. Не совсем кодирование, но скорее всего ты тоже этим занимаешься, если что-то делаешь с видео, так что давай осваивай тоже нормальную утилиту вместо просмотра рекламы и установки зондов.
Тред №0: https://2ch.hk/s/arch/2020-08-05/res/2591244.html
Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html
Тред №2: https://2ch.hk/s/arch/2021-09-23/res/2979843.html
Тред №3: https://2ch.hk/s/arch/2021-11-13/res/3029626.html
Тред №4: https://2ch.hk/s/res/3056070.html
В прошлых тредах много писали про нативную поддержку конкретных кодеков (типа VP9, AV1) на процессорах, но ведь когда мы говорим про ускорение, то имеется ввиду видеокарта, на которую перекладываются вычисления!?
И что из себя представляет эта самая поддержка? Блоки, инструкции?
Зачем тогда нужна эта самая поддержка? А насчет видеокарт - неужели им тоже нужны именно аппаратные блоки для работы с кодеками, почему нельзя просто обновить дрова и добавить поддержку программно?
Столько вопросов, а в голове мешанина. Буду крайне признателен, если вы проведете мне ликбез.
Процессорам не нужно специально поддерживать какой-либо кодек, потому что процессор декодирует и энкодирует программно, а программно можно кодировать любой кодек, хоть av1 на pentium 4. "Нативной поддержки конкретных кодеков (типа VP9, AV1) на процессорах" нет.
Под аппаратным ускорением имеется ввиду перекладывание части вычислений на видеокарту. Современные видеокарты имеют для этого специальный медиадвижок для декодирования и энкодирования на отдельных от общих блоках. Этот медиадвижок – ASIC (подробнее в вики и гугле), то есть он аппаратно узкоспециализирован для выполнения конкретных алгоритмов определённых кодеков, поэтому программно обновить возможности медиадвижка нельзя.
Насчёт аппаратного ускорения видеокартой, но на общих блоках, а не специальных, я сам не особо понимаю, да и не особо нужно. Это бессмысленно, потому что медиадвижки есть уже во всех картах. Причём медиадвижок почти всегда один и то же на все карты одного поколения от млада до стара. Например, все nvidia от 1650 super до 2080 ti имеют одинаковый медиадвижок, и соответственно их возможности в энкодировании и декодировании равны. Медиадвижок в 3000-ой серии nvidia почти такой же, лишь добавилось аппаратное декодирование av1.
По аналогии майнить можно и на видеокартах, и на асиках для майнинга, на последних это в разы эффективнее, но по различным причинам менее рентабельно. А в случае с аппаратным ускорением кодеков о рентабельности речи не идёт, это просто норма современности.
К слову, программное энкодирование и декодирование всё равно качественнее аппаратного. Программный кодировщик x264 имеет гораздо больше возможностей и тонкостей настройки, чем аппаратные nvidia nvenc и amd amf/vce. Но программный путь куда более затратный. Старый h.264 nvenc (до 1000-ой серии nvidia) был примерно равен x264 на пресете fast, а новый (от 2000-серии nvidia) – x264 на пресете medium. Так что программное энкодирование остаётся профессионалам и пердоликам-перфекционистам. Ну ещё vp9 для мейлача и дискорда жать. А нормисам для домашнего использования вполне хватает аппаратного ускорения.
А такой вопрос - на процессорах с интегрированной графикой есть эти самые асики? Например, если мы говорим о технологии Intel QSV, это же про аппаратное декодирование? Есть ли преимущества у такого декодирования за счет непосредственной близости к CPU (буквально расположение чипов на одной плате)?
Возможно, именно отсюда у меня и началась путаница, а так ответ очень помог разобраться, большое тебе спасибо.
> потому что медиадвижки есть уже во всех картах
Тетя Лиза грит НИНУЖНО
Что конкретно тебе непонятно? Там же всё элементарно.
Вот выдержка из моей старой шпаргалки по ffmpeg, разжёвывал её сам себе для запоминаемости, может тебе поможет:
-vf crop=0:0:0:0
Обрезка фрагмента, где значение – ширина, высота и координаты верхней левой точки.
Можно вычитать (вычислять) прямо в значении. Например, вырезать 600x400 из 1280x720 из нижней правой части: -vf crop=600:400:1280-600:720-400.
При вычитании можно использовать константы ширины и высоты исходника: in_w и in_h: -vf crop=600:400:in_w-600:in_h-400.
Вырезать центральную часть: -vf crop=600:400:in_w/2-300:in_h/2-200
Только сегодня заметил и удивился, по большей части потому что браузеры в основном не поддерживают HEVC, насколько я знаю, хром например. Там какой-то особый плеер?
А всё, уже сам разобрался. В хром тикток выдаёт AVC, а HEVC наверно идёт на мобильные приложения, их траффик в приоритете. И yt-dlp в mpv автоматически подхватывает поток в лучшем качестве. Это и по наличию/отсутствию вотермарки можно заметить, выше на скриншоте yt-dlp выдал кучу разных вариаций с различными вариантами перекодировки.
>Как по мне проще вставить в сосноль одну команду с определенными таймингами нежели жрать каловые видеоредакторы.
Ну и как ты это представляешь. тем более с равными таймингами и вставками картинок? Тем более с несколькими отрезками. Пердоль питона или батник тогда сам, когда можно просто кинуть видосик, картинку и удалить звукв нужным местах в любом редакторе. Пердолинг ради пердолинга.
Да особо равных таймингов не надо я за идеалом не гонюсь просто увеличу время исчезновения звука и вставки картинки. Мне много не надо хочу просто пару команд. Если у тебя есть овер простой бесплатный редактор то кидай я чекну
Как мне сделать, чтобы запись была не целым файлом, а дробилось на файлы по 30-60 минут? Использую эту команду:
ffmpeg.exe -f dshow -i audio="Line In (High Definition Audio Device)" G:/output.wav
Может ли скорость записи на диск каким-то образом влиять на работу кодировщика? Проблема такая: когда запись ведется на ссд, все ок. Когда на винт - обс выдает ошибку "кодировщик перегружен".
Средний битрейт видео - 40-50мб, потому что использую NVENC с CQP 25-27, файлы очень жирные. Кристал марк грит винт еще нормально работает, пикрил.
Вопросы еще такой: почему мой пека может записывать качественно только с огромным битрейтом? Потому что на кодирование нужны ресурсы, и вся эффективность кодировки заключается в том, какое будет соотношение размера к качеству?
>Судя по ошибке ты про ОБС студио?
Да
>Если ты пишешь стрим
Нет, просто записываю игрушку для монтажа. И это меня как раз удивляет, так как чтение-запись у винта достаточные. Тут нужно сказать, что игра и система на ссд, так что во время процесса записи винт ничем другим не занят вообще, туда только пишется видео.
>>3106139
Дополню. Я, наверное, тупой. Да, действительно, CQP хорош для работы с уже готовым видео и его дальнейшим пережатием, но оптимален ли он для записи - вопрос, на который я ответа не нашел.
> Потому что на кодирование нужны ресурсы, и вся эффективность кодировки заключается в том, какое будет соотношение размера к качеству?
Ну в общем-то да, срать огромным битрейтом дело не хитрое, а вот достигать аналогичного качества с меньшим выходным размером – это и есть суть сложности сжатия.
Я просто опирался на данный гайд, когда начинал записывать: https://www.nvidia.com/en-us/geforce/guides/broadcasting-guide/
Сказали ставь CQP, я поставил без задней мысли. Только там есть хуйня - сказано выставить 15, но на практике ниже 20 разницы не будет никакой, а вот размер файла будет ебический. Короче да, буду пробовать проще, спасибо за совет.
Этот гайд наверно рассчитан на запись сразу конечного результата. У меня самого в ОБСе настроено несколько профилей для разных ситуаций. Иногда надо записать и сразу отправить, а иногда записать для монтажа с минимумом потерь.
Ну дык сам посчитай. 50мбит это 410 мегабайт в секунду на диск пишет. Попробуй с пресетами поиграть. может у тебя HQ какой-нибудь стоит. Может в карте дело, ты же не сказал какая. Я писал на своей 1063 в 50мб без лагов, а geforce experince 100проц без лагов пишет, но вес большой.
Пресет стоит Quality, CQ 25.
Media Info грит пикрил. Я тут покурил, чего именно CQP, а не CBR. Ну он типа умнее и у него нет ограничений на моментальный битрейт, то есть если сцена сложная, то он будет хуячить по максимуму чтобы было ВМЕНЯЕМОЕ качество, а оно мне и нужно.
Можно конечно попробовать и CBR, конечно. Я примерно всегда одно и то же пишу.
А почему не VBR? Вроде можно получить россыпь пикселей в лицо в переходах от одних сцен к более сложным.
Карта десятой серии, говно, о котором в приличном месте не говорят вслух. В рекламном ролике https://www.youtube.com/watch?v=bpoDanWJ4Cw чел рассказывает, что NVENC на новых картах (я так понял речь про Turing и Amper) = x264 Slow. Да пиздец сладкие сказки, у меня все равно нет возможности это проверить.
> чел рассказывает, что NVENC на новых картах (я так понял речь про Turing и Amper) = x264 Slow
Конечно сказки. Старый h.264 nvenc (до 1000-ой серии nvidia) примерно равен x264 на пресете fast, а новый (от 2000-серии nvidia) – x264 на пресете medium.
>чел рассказывает, что NVENC на новых картах (я так понял речь про Turing и Amper) = x264 Slow.
Пиздеж. Там до слов как раком до луны еще. Чел выше правильно написал h264 medium максимум. Я вообще через проц пишу, в x264 fast в 12000кбит. Попробую nvenc для теста в cq 24.
Можешь еще streamFX скачать и потестить. Там более тонкие настройки, также есть nvenc h264-h265,prores_aw и даже AV1 через aom.
>Ты нихуя не понял. Есть два видео, разные. Размер первого, допустим, 400 мб, второго - 600. Я прогоняю их через одни и те же параметры. В итоге получаю - первое видео - 150 мб, второе - 610 мб. В первом случае все успешно, во втором - размер файла только увеличился. Вот это непонятно, какого хуя.
Очевидно твои настройки кодирования слабее оригинала.
Пробуй preset veryslow
А может ты вообще через жопу что-то делаешь. Кто тебя знает если ты страницу из гкгла осилить не можешь.
Что mediainfo говорит о твоих исходных файлах?
Какая разница кризис не кризис, офф цена одна и позиционирование тоже. Такое жидовское говно, которое слабее карты 6 летней давности, показывает отношение и как они хотят срубить бабла отбраковками на гоях.
Говновидия хотя бы высрала ртх 3050, с которой хоть что-то можно делать. Новые игры фуллхд на ультрах 60 фпс, длссы длдсары, для кодирования и работы 8гб, еще и мощнее 6500хт на 110%-120%.
Это объемный звук? При проигровании этого видео на телефоне, сначала использовалось оба динамика, затем только разговорный, а потом только обычный. Как добиться такого же эффекта?
> 2k22
> зумеры изобрели стерео
Еба что за пиздец, для этого придумали режим CBR который делает ТОЖЕ САМОЕ
CRF сжимает гораздо эффективнее CBR в плане субъективного восприятия качества за счёт применения психовизуальной модели. Минусом является то, что предугадать размер выходного файла очень сложно. Можно ограничить максимальный битрейт, но это костыль. Другими словами: CBR не делает то же самое, даже сложно представить откуда ты это взял.
Нет, вот вообще не тоже самое. Они преследуют взаимно исключающие цели.
CRF это как вы поняли некоторый постоянный уровень качества (это смотря какая психовизуальная модель в encoder. За CRF может скрываться обычный постоянный квантователь (CQ)).
CBR расшифровываеться как Constant Bit Rate, то есть постоянная ширина потока дынных. То есть битрейт фиксируеться на некотором значении и не меняеться ни в зависимости от типа кадра, ни в зависимости от его сжимаемости. Из этого следует что качество видео меняеться самым непредсказуемым образом. Нужно такое либо когда стабильность канала передачи данных важнее качества видео (обычно такое бывает на стримах или видеозвонках при конференциях), либо когда у тебя медленный диск и нужно уложиться в его скорость чтения/записи, что-бы не перегружать буферы, или когда ширина потока данных слишком мала что-бы передать медиа поток в сколько нибуть приемлемом качестве и нужно выжать максимум из размера файла.
Единственное, что более менее похожее на CRF по сути это двухпроходное VBR кодирование. Ты наверняка имел в виду именно это, но в виду своей глупости сказал совершенно другое, из-за чего тебя тут никто не понимает.
> CRF это как вы поняли некоторый постоянный уровень качества
Неверно, постоянный уровень качества это CQ
> CRF по сути это двухпроходное VBR кодирование
Да да, это. Причём два прохода тоже не имеют смысла, потому что x264 и x265 отлично оптимизированы и выдадут максимально возможное качество при одном проходе, только размер может немного не совпадать. Смысла в программе от этого не прибавляется.
> Неверно, постоянный уровень качества это CQ
CQ это про постоянный квантователь (буквально Constant Quantizer). CRF предполагает повышение квантователя для динамичных сцен, за счёт чего и осуществляеться экономия битрейта.
Говорят что в libvpx за опцией CRF скрываеться CQ. Поэтому я так размыто и описал этот режим. К тому же, не во всех кодеках реализован CRF, у них только CQ.
> Причём два прохода тоже не имеют смысла, потому что x264 и x265 отлично оптимизированы
Речь про WEBM, а следовательно, про libvpx.
> постоянный уровень качества это CQ
В говноэнкодерах -- безусловно, в энкодерах с психовизуальной моделью нет. Если вывести лог квантователя lib-vpx/9, то он тоже в режиме cq не придерживается указанного кванта, так что какая-то, пусть и херовая, но психовизульная модель там имеется.
> Причём два прохода тоже не имеют смысла, потому что x264 и x265
Только причём тут вебм, о котором идёт речь, он не умеет ни в h264, ни в h265.
> CQ это про постоянный квантователь
Вот, кстати, относительно этого, я понимаю, почему у некоторых могут возникать недопонимания, дело в том, что гугл решил, что ну его нахер эти стандартизированные абревиатуры, изобрету свои, и cq в их понимании другое, не то, чтобы это относилось к делу в данном случае, но нужно учитывать, мало какие документации читал чиловек
>Параллельно с этим в условиях ограниченного размера видеофайла одним из наилучших методов сохранения качества видео признаётся использование параметра сжатия 'Constant Rate Factor'.
Нет, лучший метод это для сохранения качества VBR с мануальным вычислением битрейта каждого отдельного видево. CRF настолько знаю просто держит определенную планку качества и ему похуй какой будет размер в итоге.
>Программа подойдёт пользователям, любящим выжимать максимум из доступного ограничения на размер файла, что в условиях постинга на АИБ вполне оправдано.
Вау, пориджи придумали vp9 CQ - constrained quality.
>В период примерно 2015-16 гг [бум популярности кодирования WebM как технического новшества] показателем мастерства считалось кодирование WebM
С этого конечно описялся.
Ага, у них там CQ это даже не CRF, а особенный режим, который при выходе за рамки битрейта меняет тамошний Q на VBR режим.
>>3107667
То есть у них даже Constant Quantizer нет. Тупо чёрный ящик какой-то.
Про tune grain знаю, конечно two-pass, главное чтобы пиздеца в кадрах почти не было
Скачать уже готовые хевк 10бит фильмы. сделанные мастерами пердолинга, нужного тебе размера и не ебать себе мозги?
Как известно есть два аппаратных способа конвертации. На CPU и на GPU.
Так как очевидно, что CPU гораздо более медленный вариант, то для каких-нибудь стримов выгодней использовать GPU, а когда время не столь критично, то CPU.
Так вот вопросец, но чтобы было понятно распишу что как я к нему пришёл.
Я пробовал прогонять видос размером чуть больше 100МБ в разрешении 1080P кодеками H265, H264, VP8, VP9.
При этом стремился получать в итоге файлы схожего размера. Чекал качество и время. Так же у первых двух кодеков я прогонял в разной битности 10 и 12 бит, а так же по умолчанию (я так понимаю 8 бит) и так же на GPU.
Так вот самое хуёвое качество при таком же размере дало GPU (nvenc). Оно прямо на голову хуже выходило, а если я увеличивал качество, файлы уже проигрывали по размеру очень сильно. Вплоть до того, что файл сжимался только на 10-15%, что никуда не годится.
H265 давал одно из лучших сжатий по отношению к чёткости я бы её так назвал или резкости. Но проблема оказалась в том, что кодек всё ещё плохо поддерживается в интернетах. Например данным сайтом. Если сюда загрузить видео в H265 кодеке, оно не воспроизводится.
Аналогично было с VP9 тоже плохая поддержка конкретно здесь. Приходится скачивать видео, чтобы посмотреть вместо просмотра онлайн. Так же V9 оказался более чистым чем H265, но гораздо более долгим в плане конвертации. Можно сказать что он лучший, но самый ресурсозатратный на мой взгляд.
В итоге я остановился на H264 и VP8. Оба кодека отлично поддерживаются почти везде в сети, включая данный сайт. Оба дают удовлетворительное качество при схожем размере. Но вот стоит мне прогнать H264 через GPU он сосёт с проглотом просто как черепаха проигрывает ракете.
Так вот мне безумно нравится идея GPU обработки, но я не понимаю возможно ли как-то приблизить качество и размер выходного файла между CPU и GPU обработкой?
Разве файлы не должны получаться идентичными при равных настройках кодирования одним кодеком? Почему так сильно падает качество при гпу обработке и как его можно улучшить?
> конечно two-pass
Это не влияет на качество, время впустую
https://handbrake.fr/docs/en/1.3.0/workflow/adjust-quality.html
> Выглядит правдоподобно.
Это я говорил про уменьшение реуомендуемых значений с падением разрешения.
А вот то что они советуют одинаковые значения для x264 и x265 - говорит мне о том, что остается 2 возможности:
- гайд писал чел, который не шарит
- Handbrake ввел свой RF и переводит в ffmpeg'овские CRF для x264 и x265, то есть этот RF ничего не значит для меня
Короче это ближайший тред про редактирование видео, поэтому спрашиваю здесь: В видео аудиодорожка при проигрывании ее с динамиков ноута например еле слышна, но она же заебись слышится в наушниках затычках. Как называется эта проблема и каковы пути ее решения? "верха повышать низы занижать"?
> Как известно есть два аппаратных способа конвертации. На CPU и на GPU.
Нет, на CPU – это программный способ. И вместо конвертации правильнее говорить о кодировании.
> Так как очевидно, что CPU гораздо более медленный вариант, то для каких-нибудь стримов выгодней использовать GPU, а когда время не столь критично, то CPU.
В общих чертах да. Хотя и стримить можно на процессоре, если он тянет x264 на пресете slow в реалтайме. И оффлайн рендерить можно на видеокарте, если конечный сервис всё равно ещё раз пережмёт видео на сервере самостоятельно.
> Я пробовал прогонять видос размером чуть больше 100МБ в разрешении 1080P кодеками H265, H264, VP8, VP9.
VP8 мог бы не откапывать, его труп уже разложился. VP9 – его продолжение.
> Так вот самое хуёвое качество при таком же размере дало GPU (nvenc). Оно прямо на голову хуже выходило, а если я увеличивал качество, файлы уже проигрывали по размеру очень сильно. Вплоть до того, что файл сжимался только на 10-15%, что никуда не годится.
Ну да, всё так. Хорошо что не радеон, он разочаровал бы в кодировании ещё сильнее, чем нвидия. Причём в рамках самой нвидии важна конкретная модель. От 1650 super до 3090 ti – новый нвенк, в h.264 он примерно равен x264 на пресете medium. Все модели до них имеют старый нвенк, он в h.264 он примерно равен x264 на пресете fast.
> H265 давал одно из лучших сжатий по отношению к чёткости я бы её так назвал или резкости. Но проблема оказалась в том, что кодек всё ещё плохо поддерживается в интернетах. Например данным сайтом. Если сюда загрузить видео в H265 кодеке, оно не воспроизводится.
Верно. И не всё ещё плохо, а в принципе плохо, потому что это несвободный кодек, требующий паевые отчисления.
> Аналогично было с VP9 тоже плохая поддержка конкретно здесь. Приходится скачивать видео, чтобы посмотреть вместо просмотра онлайн.
Вот тут чушь написал. Проблема на твоей стороне, что-то не так делаешь или криво настроил. Конкретно здесь нормально поддерживается и смотрится онлайн.
> Так же V9 оказался более чистым чем H265, но гораздо более долгим в плане конвертации. Можно сказать что он лучший, но самый ресурсозатратный на мой взгляд.
Плюс-минус так. Но ты ещё AV1 не пробовал, он по ресурсозатратности лидирует.
> В итоге я остановился на H264 и VP8. Оба кодека отлично поддерживаются почти везде в сети, включая данный сайт. Оба дают удовлетворительное качество при схожем размере.
VP8 не нужен, это уже архаизм.
> Так вот мне безумно нравится идея GPU обработки, но я не понимаю возможно ли как-то приблизить качество и размер выходного файла между CPU и GPU обработкой?
Есть в кодировании такая вещь, как баланс качества и скорости. Качественнее – значит медленнее, быстрее – значит шакальнее. Этот баланс ты должен найти исходя из своих приоритетов. Но ты хочешь и то и другое одновременно. И судя по тому, что ты остановился на нетребовательных H.264 и VP8 и тебе безумно нравится идея GPU-обработки, в приоритете у тебя всё-таки скорость. И ты считаешь, что с их скоростью можно вот так просто взять и начать кодировать ещё и так же качественно, как ресурсозатратными кодеками на процессоре? А все, кто ими пользуется, типа лохи, да? Это наивно.
> Разве файлы не должны получаться идентичными при равных настройках кодирования одним кодеком?
Нет, не должны. О равных настройках тут в принципе речь идти не может, потому что один и тот же кодек на CPU и GPU кодируется разными кодировщиками.
> Почему так сильно падает качество при гпу обработке и как его можно улучшить?
Потому что гпу
Поступила в пту.
Цпу же молодец,
В вузе он отличный спец.
Таково аппаратное ускорение, просто прими это как данность. А чтобы его улучшить, выставляй самые медленные настройки.
>Почему так сильно падает качество при гпу обработке и как его можно улучшить?
Вроде как из-за того, что при аппаратном кодировании картинка делится на участки и картинка в этих областях кодируется изолированно. То есть задача распараллеливается и потому быстрее выполняется, но из-за изолированности каждого участка качество выходит хуже. Вроде бы так.
Не нужен.
Как же досадно, что во многих видео перемотка работает плохо! Настроил на одну секунду, а плеер перематывает на 5, 8, 10 или 20. Ютуб, ВК, bdrip с торрентов - там можно это увидеть. Если перематывать точным способом, то это ахуеть можно с задержек (зависит от видео - где-то они почти незаметные, а где-то долгие). Как быть тогда? Не всегда есть возможность скачать в лучшем качестве (в более тяжёлых раздачах такой проблемы с перемотками нет). Плеер mpv.
Какой кодек выставлять?
Указывайте Win это или Lin
https://sourceforge.net/projects/ffmpeg-batch/
даже больше.
Переконвертировал игровые звуковые файлы новеллы с этой штукой примерно 32к файлов.
А предпросмотри я видел только в вебмретардс.
Этой тоже пользуюсь. Походу нет того, чего хотел, да и пох.
Тогда еще вопрос, есть такая команда, чтобы во время энкодинга рядом с командной строкой в реалтайме отображалась выходная картинка, т.е. последний обработанный кадр?
Возможно перемотка стала чуть быстрее, но всё-равно долго. Бывает, что несколько перемоток подряд всё довольно быстро, а потом опять с большой задержкой.
В одном видео именно так. В другом всё ок и без этого конфига.
Сука, ну плеер же знает время. Если поставить на плей а потом поставить на паузу, тогда он может дойти до любого времени, и покажет с точностью до миллисекунд. А чтобы перемотать - тут уже ждать надо. Грустно, очень грустно.
Что-то вроде этого, только у меня собственный скрипт, который кодирует сегмент указанный в AB-loop:
https://github.com/occivink/mpv-scripts/blob/master/scripts/encode.lua
В том же репе есть crop.lua, сначала кропаешь видео в mpv, потом жмешь хоткей для encode.lua, последний учитывает текущие параметры кропа.
Сделай себе калькулятор битрейта в экселе, всё просто.
Тогда перекодируй, Москва не сразу строилась. Не пердолик что ли? А если разница с 20 МБ небольшая, то можно отдельно перекодировать только аудиопоток, чтобы уложиться в лимит либо повысить качество звука на оставшиеся килобайты.
Сейчас проверил, libvpx VP9 при прочих равных сжалось примерно на 5% хуже на 4 потоках, чем на 1.
Ну тест
Это единственная команда для склеивания однородных файлов?
А то есть программа, которая ффмпегом соединяет, я попробовал сам соединить, вроде все нормально, но итоговые файлы совсем чуть-чуть различаются. Может лучше как-то иначе делать?
ffmpeg -i hetero.mp4 -ss 00:39:08.685 -to 00:48:12.509 -c:v copy -c:a copy gay.mp4
Но если со звуком норм, то видео проебывает секунд по 20.
Внезапно у новых вебм'ок перестало появляться превью. Команда простейшая -вход -выход. Здесь, как видите, превью у них есть. В чём проблема?
Вроде как проблема появилась после установки программы для достройки промежуточных кадров. Её уже удалил.
>На каких затычках и что за лосслесс?
Преимущественно не на дешёвых.
Подробности тут https://en.m.wikipedia.org/wiki/Nvidia_NVENC#Versions
Полгода назад обсуждали в этой ветке. Тогда ценник на 264-ку без потерь начинался от 20 тыс. руб., а на 265-ку от 30 тыс. руб. Сейчас дороже.
Сап, аноны. Нужна помощь. Делал в проге boram webm'ку, поставил кодек AV1. При его использовании видео рендерится, но потом когда постишь на 2ch — то не видно превью, пикрил. Что делать? При юзании кодека VP9 всё ок, но хуже качество.
А зачем он был нужен?
Что за source filters?
LAV или мелкософт?
Или не нужно ебать себе мозги, актуальный максимальный к-лайт конфликтной хуйни не ставит? Или есть мануалы?
не знаю куда писать, наверное, надо идти на профильные форумы видеоредакторов
aom хуита
> Причём современный mpc тянет свои кодеки за собой, ничего устанавливать не надо
MPC-HC не тянет за собой vfw-кодеки, их нужно отдельно устанавливать. MPC-HC тянет за собой LAV Filters, а это не vfw-кодеки.
vfw-кодеки пикрил выглядят.
x264vfw, x265vfw, av1vfw, lagarith, etc. Именно такие и используют программы для видеоредактирования, чтобы энкодить. Ну это конечно же, ffmpeg можно решить всё, если программа вменяемая и имеет функцию подгрузки внешних энкодеров.
Например для youtube связка youtube-dl и ffmpeg работает прекрасно: ffmpeg $(youtube-dl -g ''URL"' | sed 's/^/-ss 08:00 -to 08:30 -i /') -b:v 0 -crf 30 output.webm
Для vk выдает ошибку HTTP error 400 Bad Request.
Второй день экспериментирую. Ничего не получается.
Ебать ты поехавший, щяс бы два дня потратить на этот ебанутый способ. Неудивительно что у тебя линукс стоит, но странно что убунту, он старается быть на нормальных людей.
Ради тебя встал и скопировал команду
yt-dlp --downloader ffmpeg --downloader-args "ffmpeg_i:-ss 1:29:32 -to 1:30:42"
Есть старая игра 20-летней давности. Есть несвежий пека средней паршивости. Игра на нём идет отлично, 200+ фпс в 1920x1080.
Хочу записать видео прохождения некоторых её кусков в 1920x1080 @ 60 fps или мб даже 3840x2160 @ 60, если мне дадут погонять 4K-монитор (игра поддерживает такое разрешение). Летсплеером и стримером становиться не планирую, видеоряд нужен для других целей, акция одноразовая (запишу часов 5 игрового процесса и успокоюсь).
Фрапс тянет запись 1920x1080 @ 30 fps, но при фпс выше (где-то от ~40) упирается в производительность жесткого диска.
OBS со своим дефолтным (?) сжатием диск особо не насилует, но тут уже реалтаймовое сжатие видео не вывозит процессор.
Места на жёстком диске дофига.
Какие есть решения, которые бы сжимали несильно, чтобы успевало в реалтайме, но при этом не в ущерб визуальному качеству видео, а в ущерб объему? Десятки и сотни гигов получившегося видео - не вопрос, после записи пережму нормально.
Ну и в чем он ебанутый?
По-моему, как раз удобно в одну строчку скачать отрывок + сжать его.
>Неудивительно что у тебя линукс стоит, но странно что убунту, он старается быть на нормальных людей.
Лол. Щас бы сидя на дваче рассуждать про нормальных людей.
В любом случае, спасибо за помощь. Получилось типа такого:
yt-dlp --downloader ffmpeg --downloader-args "ffmpeg_i:-ss 00:00 -to 00:20" --downloader-args "ffmpeg_o:-c:v vp9 -b:v 0 -crf 30 -o output.webm
Пикрил настройки должны удовлетворить твой запрос.
>>3124121
>CQP 23
По умолчанию стоит 20, так что его можно и оставить.
CQP тем и хорош, что сам рассчитает, как пользователю будет заебись исходя из сцены.
>Expirience
Не забудь зарегистрироваться где-нибудь, чтобы блядь еще воздухом подышать. Ни разу на дваче не видел сравнения в лоб нвенка от обс и нвенка от хуйвидии, а никому это не упало потому что и разницу не увидишь, потому что ее и нет. Обс замечательный инструмент и точка, никуда дергаться не нужно.
> CQP тем и хорош, что сам рассчитает, как пользователю будет заебись исходя из сцены.
Нихуя cqp не рассчитывает, это crf рассчитывает который нвидиа не поддерживает
> Ни разу на дваче не видел сравнения в лоб нвенка от обс и нвенка от хуйвидии, а никому это не упало потому что и разницу не увидишь, потому что ее и нет
Ебать дебил. У экспиренса намного меньше накладные расходы за счёт того что он не строит 3д сцену и использует специальные интерфейсы, без копирования картинки. Обс не нужен для простой записи игры.
>Нихуя cqp не рассчитывает, это crf рассчитывает который нвидиа не поддерживает
У них одинаковое предназначение - целевое качество выходного видео, об устройстве каждого я не знаю, мне и не нужно. Если процессор не тянет запись, то просто пишешь на карте, только и всего
скинь, плиз.
У меня тут другая проблема - в самом начале низкий битрейт. Может как раз в настройках дело.
Так и должно быть в начале с битрейтом. Установи windows terminal
И я вспомнил, vp9 так вообще нельзя конвертировать. Обязательно нужно два прохода, если один качество будет намного хуже! Так что скачивай видео и только после этого его конвертируй
https://0bin.net/paste/BWVblfKe#AscsdMVvgVqEEldRPxSrEXZvDrmV7eiBQm5QKHTaoyA
Свинья перешла на визг, а я на ор!
Это не много, но с этого можно начать дальнейший поиск: https://www.reddit.com/r/nvidia/comments/5mes9h/shadowplay_nvenc_nvfbc_nvifr_what_do_they_mean/
Ну теперь стало понятней. Видел какие-то патчи для дров нвиде есть, якобы чтобы nvFBC можно было использовать на обычных потребильских картах.
nvFBC где-то можно юзать вообще? Либо эта шняга чисто для линуха из-за их кастрированной ОС.
https://github.com/keylase/nvidia-patch/tree/master/win
1. Эта херня есть на андроиде?
2. Есть ли у неё гуй?
3. Можно ли с её помошью вырезать кусок с ютубного видео, не скачивая его?
Напиздели тебе. Можно спокойно себе на андроиде собрать, либо через termux установить.
На андроид есть FFmpeg Media Encoder, он же как и гуи с пресетами, так и строка обычная есть.
Кусок не скачивая только, если через termux наверное. Команда выше есть.
yt-dlp --downloader ffmpeg --downloader-args "ffmpeg_i:-ss 1:29:32 -to 1:30:42"
Переменный битрейт и прочие умные методы – не то, потому что дело не в динамике, а в субъективной важности определённых моментов.
В голову приходит только отдельное кодирование нескольких фрагментов с последующим склеиванием, но это топорный костыль, к тому же на склейках будет резкое изменение качества, а снижение и повышение хотелось бы делать плавным и незаметным.
У libx264 есть зоны с множителями для битрейта.
https://superuser.com/a/919198
Такие дела.
1ffmpeg media encoder, охуенно работает, он же сразу с гуем
2shutter encoder боат жив, всем советую
3качай в newpipe или yt dlp и режь уже скачанное, иначе никак, либо будет рваная хуета. Ютуб это очень хитрый видеохостинг, а не радикал.
Мне посоветовали ffmpeg, но я что-то ничего не понимаю.
До это с кодированием был никак не связан.
Посоветуйте гайд чтобы просто сделать музыкальную вебмку.
Ну или если просто не получится, то хотя-бы основы чтобы начать понимать суть.
Ну если по умолчанию для libx264 -preset medium, то попробуй fast, faster, veryfast, superfast, ultrafast. А вообще ffmpeg gpu-ускорением не обделён, попробуй h264_nvenc / h264_amf / h264_qsv.
А мы будем
У тебя айпад пердежных лет? Тем более, в софтварном режиме любое видео должно воспроизводится. Кто виноват, что в сафариговно не добавили-то.
>>3126501
Потому что в ffmpeg баг, который после окончания музыки с шортест все равно добавляет пустой звук на 30-60 секунл дополнительно. Так что надо в ручную указывать.
Литералли вывод самого нового ffmpeg 5 версии из сорцов февраля.
ffmpeg version N-105377-ga8f1779a25-gb2421c4f26+3 Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 11.2.0 (Rev8, Built by MSYS2 project)
Сам флак
Duration: 00:03:09.92, start: 0.000000, bitrate: 970 kb/s
Stream #1:0: Audio: flac, 44100 Hz, stereo, s16
>HHShortest.webm
frame= 215 fps= 18 q=0.0 Lsize= 3308kB time=00:03:34.00 bitrate= 126.6kbits/s speed=17.8x
video:238kB audio:3002kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.096969%
>HHTime.webm
frame= 190 fps= 17 q=0.0 Lsize= 3307kB time=00:03:09.93 bitrate= 142.6kbits/s speed=17.4x
video:237kB audio:3002kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.091706%
>А у меня не багуется, и что ты мне сделаешь?
Разве что залупой по лбу дать.
gyan уже скомпилировал v5.0, если что
https://www.gyan.dev/ffmpeg/builds/
И конвертирует ли ффмпег картинки?
Сап, кодировальщики, прям не знаю, где ещё спросить.
Wondershare Uniconverter не хочет конвертить на видяхе - тупо не даёт включить опцию "ускорение gpu", трабла видна на первом скрине. Видяха ноутбучная, подключена, как я понимаю через встройку проца (стандартно для ноутбука).
Не спрашивайте, почему мокрописька, сам не в восторге. Обычно юзаю нормальный софт вроде того же ffmpeg
Добрый день, аноны. Я решил создать пару вебмок для порно-тредов и заодно понять как эта перекодировка работает. В интернете нашёл гайд, где советуют использовать данные две команды по очереди:
ffmpeg -i <file> -c:v libvpx-vp9 -b:v <X>k -c:a libopus -b:a <X>k -speed 1 -lag-in-frames 25 -auto-alt-ref 1 -frame-parallel 0 -tile-columns 6 -quality good -sn -ac 2 -an -y -threads 4 -g 9999 -colorspace bt709 -pix_fmt yuv420p -f webm -pass 1 NUL
ffmpeg -i <file> -c:v libvpx-vp9 -b:v <X>k -c:a libopus -b:a <X>k -speed 1 -lag-in-frames 25 -auto-alt-ref 1 -frame-parallel 0 -tile-columns 6 -quality good -sn -ac 2 -an -y -threads 4 -g 9999 -colorspace bt709 -pix_fmt yuv420p -f webm -pass 2 "<filename>.webm"
Результат мне понравился, однако у меня теряется звук при кодировке. С чем это может быть связано?
Команда полное говно потому что
https://0bin.net/paste/BWVblfKe#AscsdMVvgVqEEldRPxSrEXZvDrmV7eiBQm5QKHTaoyA
Какие форматы сейчас лучшие для хранения фото и видео?
https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20%D0%BA%D0%BE%D0%B4%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%20%D0%B3%D0%B0%D0%B9%D0%B4.md
>hwaccel
>preset slow
Или крестик сними, или трусы надень. Как-то глупо ставить медленный пресет, изначально портя качество аппаратным декодированием, чтобы выиграть совсем немного времени. В мануале mpv написано:
Quality reduction with hardware decoding
In theory, hardware decoding does not reduce video quality (at least for the codecs h264 and HEVC). However, due to restrictions in video output APIs, as well as bugs in the actual hardware decoders, there can be some loss, or even blatantly incorrect results.
In some cases, RGB conversion is forced, which means the RGB conversion is performed by the hardware decoding API, instead of the shaders used by --vo=gpu. This means certain colorspaces may not display correctly, and certain filtering (such as debanding) cannot be applied in an ideal way. This will also usually force the use of low quality chroma scalers instead of the one specified by --cscale. In other cases, hardware decoding can also reduce the bit depth of the decoded image, which can introduce banding or precision loss for 10-bit files.
vdpau always does RGB conversion in hardware, which does not support newer colorspaces like BT.2020 correctly. However, vdpau doesn't support 10 bit or HDR encodings, so these limitations are unlikely to be relevant.
vaapi and d3d11va are safe. Enabling deinterlacing (or simply their respective post-processing filters) will possibly at least reduce color quality by converting the output to a 8 bit format.
dxva2 is not safe. It appears to always use BT.601 for forced RGB conversion, but actual behavior depends on the GPU drivers. Some drivers appear to convert to limited range RGB, which gives a faded appearance. In addition to driver-specific behavior, global system settings might affect this additionally. This can give incorrect results even with completely ordinary video sources.
rpi always uses the hardware overlay renderer, even with --vo=gpu.
cuda should usually be safe, but depending on how a file/stream has been mixed, it has been reported to corrupt the timestamps causing glitched, flashing frames. It can also sometimes cause massive framedrops for unknown reasons. Caution is advised, and nvdec should always be preferred.
crystalhd is not safe. It always converts to 4:2:2 YUV, which may be lossy, depending on how chroma sub-sampling is done during conversion. It also discards the top left pixel of each frame for some reason.
All other methods, in particular the copy-back methods (like dxva2-copy etc.) should hopefully be safe, although they can still cause random decoding issues. At the very least, they shouldn't affect the colors of the image.
In particular, auto-copy will only select "safe" modes (although potentially slower than other methods), but there's still no guarantee the chosen hardware decoder will actually work correctly.
In general, it's very strongly advised to avoid hardware decoding unless absolutely necessary, i.e. if your CPU is insufficient to decode the file in questions. If you run into any weird decoding issues, frame glitches or discoloration, and you have --hwdec turned on, the first thing you should try is disabling it.
https://mpv.io/manual/master/
> Как-то глупо ставить медленный пресет, изначально портя качество аппаратным декодированием
Ой бля, ты кодирование с декодированием путаешь, выдержка из мануала mpv здесь ни при чём, там о вреде аппаратного декодирования, а не кодирования. Аппаратное кодирование ничего страшного за собой не несёт.
Чтобы закодировать, самому кодировщику нужно неожиданно прочитать исходник, то есть декодировать его. -hwaccel auto даёт команду делать это аппаратно, а вред аппаратного декодирования расписан в мануале mpv.
>>3131230
> ты кодирование с декодированием путаешь
Не путаю.
> там о вреде аппаратного декодирования, а не кодирования
Знаю.
> Аппаратное кодирование ничего страшного за собой не несёт
Толсто.
> Чтобы закодировать, самому кодировщику нужно неожиданно прочитать исходник, то есть декодировать его
Теперь понял, я изначальной команды не видел, потому и удивился, что анон пишет
>hwaccel
>preset slow
и я допереть не мог к чему это
> https://web.archive.org/web/20210401103230/http://www.3ivx.com/support/calculator/index.html
Не нужен. Делается в экселе за минуту.
> Это не я опровергаю тем более, а ты начал челу выше доказывать бепруфным кукареком от мпвшизов, что нинужно.
Конечно не нужно, нужно аппаратно декодировать на камне, а не на чипе видяхи, за камнями зашкваров не наблюдалось.
У уого такое было, что
ffmpeg -i input.mkv -vf reverse output.mkv
вызывает огромную утечку памяти?
Четырехминутное видео с ютуба, размером в 3мб. Озу 12 гб.
Есть один файл.
В формате wav, 1.4 секунды.
Который отказывается воспроизводится на телефоне в качестве сигнала уведомления или так.
На ПК он воспроизводится без проблем, но ни один анализатор спектра ничего не показывает.
Конвертация в ogg, acc, opus, mp3, flac в ffmpeg c изменением частоты дискретизации не помогает.
Добавление секунды тишины в конец, изменение темпа, компрессия, перезапись с помощью плеера и wat u hear в Audacity тоже ничего не меняет.
На ПК воспроизводится, на телефоне нет. Анализаторы спектра молчат.
Что за чёрная магия?
Что ещё можно попробовать?
Сам файл вот.
https://anonfiles.com/F0H8JeRbx4/RadioMessage_wav
В нём битый счётчик сэмплов и как следствие неправильно показывается его продолжительность, но это-то исправляется при конвертации в другой формат.
Вот он открыт в редакторе, никаких проблем. Но анализ спектра покажет пустое место.
Что такого там может быть, что не уходит при преобразованиях?
При этом у меня несколько телефонов, и на одном из них (sony) всё работает. А на других нет.
Как это сделать через ffmpeg?
Конкатенирую стандартной командой с вики несколько вебемок в одну длинную
Использовал [code]ffmpeg -f concat -safe 0 -i fileList.txt -c copy mergedVideo.webm[/code]
Сначала видео было с нормальным звуком,потом, начиная одной вебемки ,звук испортился. Попробовал переставить эту вебемку в начало и склеил заново. В результате у этой вебемки звук нормальный,но во всем остальном видео звук испортился. Не понимаю в чем причина. Может нужно привести все вебемки к одному аудио кодеку ,но как это сделать?
попробуй так https://dropmefiles.com/aDY8v
Вроде норм файл. Только в заголовке присутствовала непонятная секция, нетипичная, не знаю такую. Удалил ее, короче в гекс-редакторе. Ну и тишину в начале вырезал, аж 17 семплов. И еще до кучи добавил вариант отнормированный по громкости, то есть громкость усилена до предела. Фикшенные файлы внутре картинки, в zip-архиве. Распакуй чем нибудь.
Почитал про эту секцию. Она добавляется только к сжатым форматам, а у тебя нормальный PCM, то есть она не нужна. В этой секции указывается количество семплов. У тебя указан 1 семпл. То есть, проигрыватели, редакторы, конвертеры, которые читают эту секцию, думают что в файле 1 семпл. Такие дела...
10-30 в зависимости от папки. Я не знаю, какие кодеки в каждом видео. Думаю, что можно было бы просто перекодировать звук под один кодек, например opus , одновременно склеивая. Есть ли такая команда? Я нуб просто, много чего не знаю.
Да легко. Макаба отрезает архивы если их клеить в конец картинко-файла. Но есть способы запихнуть архив внутрь файла. Например в jpg есть секция для комментария - можно пихануть в нее, но там размер секции указывается в два байта, то есть архивы больше 65533 байта не влезут. Но есть еще png-картинки, в них размер секции пишется в 4 байта, значит можно пихануть большие архивы. У пнг тоже есть секции под комментарий - вот, пихаю туда. Для этого напейсал всякие приблуды, которые автоматом все делают. Зацени.
Я обнаружил через ffprobe, что у всех файлов звук через vorbis,каких-то отличий не нашел,кроме битрейта,различие в котором не мешает соединению других файлов. Может ли влиять наличие метаданных?
Вот вывод того,который склеивается
>Input #0, matroska,webm, from 'rit.webm':
Metadata:
encoder : Lavf56.36.100
Duration: 00:00:15.00, start: 0.000000, bitrate: 6335 kb/s
Stream #0:0: Video: vp8, yuv420p(progressive), 1280x720, SAR 1:1 DAR 16:9, 48 fps, 48 tbr, 1k tbn (default)
Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp (default)
А вот того,который приклеивается с порченным звуком
>Input #0, matroska,webm, from 'tyu5_720p.webm':
Metadata:
TCDO : 122500000
TCOD : 2500000
ENCODER : Lavf58.29.100
Duration: 00:00:12.00, start: 0.000000, bitrate: 6463 kb/s
Stream #0:0: Video: vp8, yuv420p(progressive), 1280x720, SAR 1:1 DAR 16:9, 48 fps, 48 tbr, 1k tbn (default)
Metadata:
ENCODER : Lavc58.54.100 libvpx
DURATION : 00:00:12.003000000
Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp (default)
Metadata:
ENCODER : Lavc58.54.100 libvorbis
DURATION : 00:00:12.003000000
В чем разница? Метаданные влияют?
Ща проверим.
>>3132927
> попробуй так https://dropmefiles.com/aDY8v
> Фикшенные файлы внутре картинки, в zip-архиве.
Ничего не изменилось.
Как было пусто в анализаторах спектра, так и на телефоне не воспроизводится.
Откройте в foobar2000 визуализацию (например спектрограмма) при воспроизведении — будет пусто, хотя файл воспроизводится будет.
Единственный положительный эффект, который я наблюдал — это то что при конвертации в AAC или vorbis появляется слабый хрип на грани слышимости, какая-то часть частот просачивается и на спектр и при воспроизведении.
При конвертировании в mp3 например все проблемы должны уходить, но не уходит.
При записи в редакторе с "what u hear" тем более, но тоже не уходят.
Как не понимал что за фигня, так и не понимаю.
Я бы списал всё это на какую-то неотключаемую DSP обработку в телефоне, которая почему-то агрессивно режет именно этот узкий диапазон частот, что имеется в файле, но почему визуализации в плеерах на ПК тоже молчат?
>Откройте в foobar2000 визуализацию (например спектрограмма) при воспроизведении — будет пусто, хотя файл воспроизводится будет.
Нормально все.
>>3134528
В общем вся проблема была в том что в файле ложное стерео, в котором дорожки в противофазе.
При сложении дороже в противофазе в моно получается тишина.
Телефон при воспроизведении тоже складывает в моно. А божественная сони воспроизводит стерео, ай да сони.
Вырезал дорожку псевдостерео в audicity, пересохранил и всё заработало.
Потрясающе.
О как. Точно. Если сложить каналы в один, то тишина получается - в файле одни нолики.
Не понял, почему нужно качать с джандев, если есть BtBN.
По сабжу пикрил, вот тебе конкретика. Сиди изучай, че где есть, чего где нет.
BtBN лучше? В первоисточнике он первый в списке просто
https://www.ffmpeg.org/download.html
Со слов самого Джана разница в каких-то внешних библиотеках. Я по приколу про BtBN написал.
ААС вроде бы и так есть.
Ты про это? https://en.wikipedia.org/wiki/Fraunhofer_FDK_AAC
Ой короче, качаю от gyan и похуй. Еще хотел спросить, есть ли какая-то мизерная разница скорости в использовании shared и static версий?
Качай отсюда и похуй https://github.com/AnimMouse/ffmpeg-autobuild
Адобе или давинчи?
> Медленнее чем AV1?
По адресу https://old.reddit.com/r/AV1/comments/r1sv22/av1_the_opus_of_video_codecs_discuss/ приводится график Intel, согласно которому при равном качестве видео кодировщик libsvtav1 (он же SVT-AV1) работает быстрѣе libvpx (то есть быстрѣе кодировщика VP9) НА ПОРЯДОК.
(График прилагаю.)
Другое дѣло, что нам от него не скорость работы нужна, как правило. Так что разумно заставлять libsvtav1 работать гораздо медленнѣе, но выдавать гораздо большѣе качество видео, недосягаемое для VP9 при том же битрейте.
Может кто знает, можно ли в ОБС кодировщик видео и аудио выбрать такие, чтобы запись не крашилась с ошибкой? Я вроде все вариации пробовал из доступных - выдаёт ошибку? Или по старинке делать что-ли: сначала в mp4, потом в ffmpeg в webm переделывать? Хотелось бы сразу чтобы ОБС в webm конвертировал
Я порекомендовал бы кодировщик SVT-AV1, кабы с ним не была та проблема, что он весь компьютер способен повѣсить собою:
https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1836
Там очень замѣтно, что тому человѣку, который повѣдалъ разработчикам о проблеме, разработчики въ ѿвѣтъ порекомендовали пересобрать OBS с новой версией SVT-AV1.
А как он пересоберёт? — это ему придётся сидѣть и дожидаться того, когда авторы OBS пересоберут под Windows-то. А авторы OBS, если правду сказать о них, не то чтобы были склонны в прошлом активно обновлять версии употребляемого в OBS программного обеспéчения. Только недавно (в версии OBS 27.2) встроенный Chrome обновили с версии 75 до версии 95 — это, стало быть, почти 2½ года не трогали его.
Если такими темпами и тут, то тогда дай-то Боже к концу 2024 года дождаться нормальнаго человѣческаго поведения видеокодировщика SVT-AV1 в OBS.
>>3136233
Блин, это что же, в 2022 до сих пор никто кодировщика для ОБС чтобы сразу в webm конвертировать не изобрёл что-ли получается
> Насчет svt не знаю, да и он только на последних интелах.
По адресу https://gitlab.com/AOMediaCodec/SVT-AV1 и https://github.com/AOMediaCodec/SVT-AV1 указаны довольно мощные технические требования: дескать, нужен Intel Core не менѣе чѣмъ пятого поколения, а работа SVT-AV1 провѣряется разработчиками на Windows не старѣе 2016 года, а при попытке удѣлить менѣе шести гигабайтов RAM кодированию fullHD с десятибитными компонентами цвѣта будет вылетать ошибка.
Однако, едва попробовав libsvtav1 мѣсяцъ назад, я тотчас же вполне убедился в том, что всё это была хѣрня, то есть что на моём i7-3770 под седьмою виндою, кушая не болѣе двух-трёх гигабайтов RAM (но зато ≈9 гигов с учётом виртуальной памяти), именно fullHD и именно с десятибитными компонентами цвѣтовъ способен обрабатываться движком libsvtav1 невозбранно.
Рѣчь идёт, повторяю, о десятилѣтней давности процессоре i7-3770, продажи которого начались въ апрѣлѣ 2012 года.
Напишите пару строчек по теме, чтобы тред не удолили. Думаю тред будет полезным
>>3136277 (OP)
А есть чо менее дрочерское (с нормальный интерфейсом) для простейших задач (обрезка, склейка, конвертирование), но все же минималистичное (Premiere и прочее будет оверкиллом)
Сможет ли видеокарта сжать видео так же эффективно, как процессор, но при этом в разы быстрее? Если нет, то почему так?
Я вот как-то еще не дорос до скриптов, все обычно руками прописываю. На чем пишешь, бат небось какой или пш1?
>>3136472
>ставить еще одну программу
>осваивать ее
Мне ЛЕНЬ не столько руками писать параметры и затем сравнивать скрины, сколько осваивать новое по. Прямо фу. А еще я почитал мануалы по предустановкам использования (fast, medium etc), crf, профили и мне стало лень делать вообще что-либо.
Я не знаю, чего именно я хочу. Не знаю, как сравнить два энкодера - по битрейту? Я что, должен его руками задавать?
Кароч чето муторно все это, я ибал.
Мне хотелось простого ответа - nvenc ебет или не ебет? А оказалось, что придется ебаться самому.
> Мне хотелось простого ответа
Новый нвенк весьма хорош, но этим сказано далеко не всё. Везде разный баланс между уровнем сжатия и затраченным временем, однако баланс ничего не решает, когда у тебя есть определённые приоритеты. Мы тут собрались в основном пердолики и топим за максимальное сжатие любой ценой, но мы двачеры-максималисты, каждому из которых по отдельности доверять не стоит. Под разные задачи и сценарии использования лучше подходят разные кодеки, методы и их настройки. Если поваришься в теме сжатия подольше, это всё быстро станет для тебя интуитивно понятно.
Мне мало утверждения
>на уровне
что это вообще значит? Выходной размер такой же при одинаковом заданном битрейте и выходном качестве? А как сравнивать x264 в режиме CRF с nvenc?
Я почитал еще с прошлого треда про квантизацию и понял, что cqp куда тупее, так как обрабатывает вообще все кадры одинаково, тогда как crf анализирует уровень движения или что-то такое, поэтому разные кадры сжимаются тоже по-разному.
>>3136537
Да я и так с вами сижу уже черт знает сколько, а голова все равно пустая и понимания нет. Зато интерес есть, неподдельный.
Типа алгоритм 264 он же одинаков что для карты, что для камня. Так почему одно хуже, а другое лучше!?
Сжать прям также эффективно как процессор нет. Но на высоких битрейтах nvenc давно равен x264. НО считаю кодирование в 300 фпс на моей 1063 стоит того.
У меня в obs стоит пресет quality с vbr 10000k max 12000k бфреймов 4. Удовлетворительное качество при минимальном весе. За 20 минут где-то 1.5 гига всего набегает.
Вот этот видос он вроде клеил.
Обычный метод подходит скорее для дискорда, который берёт для превью первый кадр, а не случайный, как мейлач. Мне сейчас некогда экспериментировать, но по твоему мп4релейтед видно, что имеется 2 видеодорожки. Первая, основная, должна быть короткой, чтобы с минимальной вероятностью быть выбранной для превью, а вторая, для превью, должна быть длинной и для компактности растянутой через большой gop. Проверяй сам, я побежал.
>Обычный метод подходит скорее для дискорда, который берёт для превью первый кадр, а не случайный, как мейлач.
Ты о чем? Обычный это когда вторую дорожку с чуть большим разрешением вставляешь в файл и ставишь ее как основную. Тогда показывается превью, но запускается сам файл. Но макака убрал этот метод, чтобы скримеры не вставляли на мейлаче. На 2channel moe работает например.
>Мне сейчас некогда экспериментировать, но по твоему мп4релейтед видно, что имеется 2 видеодорожки
Это итак понятно.
>Первая, основная, должна быть короткой, чтобы с минимальной вероятностью быть выбранной для превью, а вторая, для превью, должна быть длинной и для компактности растянутой через большой gop.
Нихрена непонятно что ты имеешь ввиду под короткой и длинной. Надо лучше выражаться и понятнее.
Сам метод про который я говорю буквально на превью видео нарисованно.
>Превью работают но способ другой с кривой продолжительстью
Вот это я пытаюсь понять как сделать.
И так, нужно добавить тег "Название" ко множеству mkv файлов. Преимущественно аниме-сериалы. Если выделить все mkv в папке на дурачка, например при помощи консольной проги sharkdp/fd, командой fd -e mkv -E "Bonus" -x mkvpropedit.exe {} -s title="Anime Title", то у всех серий будет одинаковое название. А я хочу в названии сохранить информацию о серии. Что мне сделать ради этого?
Как увеличить аудио битрейт хотя бы до 128 кб/с? И между какими командами нужно вставить (команду для изменения качества)?
Прога позволяет создавать подобные видики буквально в два клика. Любые другие варианты просто не стоят своего времени.
>>3140219
>Не должно быть такого.
>проверять надо через mediainfo
Хм, точно.
Накатал тут целую паста какой до этого большой пердежный сложный и хуевый скрипт. Удалил к хуям всё.
Полностью новый написал короче. Тупо граббит имя файла и вставляет его в metadata title. легко и просто.
https://0bin.net/paste/uMpDdfPp#YmWIMeIvEVOuUNHJOwpsg-Dp4pOPCHn0XuxUW2Ec2LC
Он кодирует быстрее и с лучшим качеством, при одинаковом размере
https://www.opennet.ru/opennews/art.shtml?num=57068
Когда я кодирую ффмпегом - в моей webm пишет yuv420p(tv, progressive).
Но я встречаю шебм с двачей yuv420p(tv). Это подразумевает progressive, interlaced, что-то еще?
Это подразумевает цветовой охват, 0-255 -pc, 16-235 - tv
Это ничего не подразумевает, для определения воспользуйся http://www.aktau.be/2013/09/22/detecting-interlaced-video-with-ffmpeg/
Не мой кейс, мне нужно определить чисто формально, так сказать, не опираясь на контент. Этот фильтр не работает для видео из одной статической картинки, потому что разворачивать нечего, хех, но ведь interlaced/progressive определен даже для такого видео.
>>3142636
Тип интерлейсинга мне пока не важен.
Мда, видимо, херней страдаю
> x265 ОФИЦИАЛЬНО больше не нужен
> Он кодирует быстрее и с лучшим качеством, при одинаковом размере
> https://www.opennet.ru/opennews/art.shtml?num=57068
А если у меня Ryzen вместо интела?
Codecs:
D..... = Decoding supported
.E.... = Encoding supported
..V... = Video codec
..A... = Audio codec
..S... = Subtitle codec
...I.. = Intra frame-only codec
....L. = Lossy compression
.....S = Lossless compression
..VILS jpegxl JPEG XL
Видимо неправильно скомпилировал https://github.com/megapro17/FFmpeg-Builds/releases/tag/latest
> -cpu-used 0..8 (синоним: -speed, по умолчанию 1) — профили энкодера для -quality good, от более ресурсоёмких и эффективных к менее
Правильно ли я понимаю из этого, что в libvpx-vp9 при -quality best игнорируется -speed?
Нет, не игнорируется.
Гайд из шапки устарел, читай этот https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20%D0%BA%D0%BE%D0%B4%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%20%D0%B3%D0%B0%D0%B9%D0%B4.md
> https://trac.ffmpeg.org/wiki/Encode/VP9
> When the deadline/quality parameter is good or best, values for -cpu-used can be set between 0 and 5. The default is 0.
Значит -speed всё равно можно не прописывать, если нужно лучшее качество, достаточно -quality best.
Да ничем в принципе. Раньше в бест всегда делал, потом рыскал на форумах и нашел такую инфу. Да и кодирует в 10 раз медленнее, чем -cpu-used 0.
>best: This usually gives the best quality output but is extremely slow. In general this is not a recommended setting unless you have a lot of time on your hands.
>good: This will probably be what most users use most of the time. Within the scope of "good" quality there are 6 further speed steps that are set through the --cpu-used parameter (values from 0 to 5). Setting --good quality and --cpu-used=0 will give quality that is usually very close to and even sometimes better than that obtained with --best but the encoder will typically run about twice as fast. Setting --cpu-used=1 or --cpu-used=2 will give further significant boosts to encode speed, but will start to have a more noticeable impact on quality and may also start to effect the accuracy of the data rate control. Setting a value of 4 or 5 will turn off "rate distortion optimisation" which has a big impact on quality, but also greatly speeds up the encoder.
>real time: Real-time mode allows the encoder to auto adjust the speed vs. quality trade-off in order to try and hit a particular cpu utilisation target. In this mode the --cpu-used parameter controls the %cpu target as follows: target cpu utilisation = (100116-cpu-used)/16)%. Legal values for -cpu-used when combined with --rt mode are (0-15). It is worth nothing that in --rt mode the encode quality will depend on how hard a particular clip or section of a clip is and how fast the encoding machine is. In this mode the results will thus vary from machine to machine and even from run to run depending on what else you are doing.
>>3144364
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
https://2ch.hk/s/res/3144406.html
https://2ch.hk/s/res/3144406.html
https://2ch.hk/s/res/3144406.html
https://2ch.hk/s/res/3144406.html
https://2ch.hk/s/res/3144406.html
> Ну когда там уже будет божественный h266 vvc
А зачем он сейчас нужен? Пока из 8К контента только панорамы природы, да городов в тестовых демо-роликах. HEVC для 4К вполне избыточен, да даже H.264 всё ещё на хорошем счету из-за своей многопрофильности.
> av1
Так AV1 и VVC для разных целей предназначены.
>А зачем он сейчас нужен?
хз хоть какая-то конкуренция, гугел не может нормально запердолить все кодеки свои.
>Пока из 8К контента только панорамы природы, да городов в тестовых демо-роликах.
АВ1 вроде тоже для 8к всё готовили, ну и 4к в придачу. Для того же нетфликса, хотя до 8к все равно далеко еще.
>HEVC для 4К вполне избыточен
Что это значит, не понял. Избыточен для чего, должен быть какой-то предел?
В 4к VVC в 25-40% меньше размер, чем hevc при том же качестве.
>да даже H.264 всё ещё на хорошем счету из-за своей многопрофильности.
Скорее, для поддержки даже на тостере.
>Так AV1 и VVC для разных целей предназначены.
Каких?
> Запатентованное проприетарное говно не нужно.
Не нужно только дебилам, которые смотрят видео в браузере. На носителях везде будет VVC, как сейчас HEVC, как был H.264. Запомните это, мрази, и не отсвечивайте своей тупостью.
> Запатентованное проприетарное говно не нужно
В том то и проблема, что кодеки ла-мпег не говно и имеют крайне годную аналитическую часть, в отличии от гуглоговна, который срёт жёсткой неоднородностью видеоряда и это заметно даже не вооружённым вщглядом любому, кроме мобилкодаунов.
> Имеет ли смысл 2pass при crf
> vp9
>>3147652
> Смысла 0 - размер файла и качество идентичные
Метрики какие использовал или оценочное суждение? С другой стороны раньше оно точно было нужно и без второго прохода качество отличалось значительно. В х264 не нужно, на doom9 сами кодеры подтверждали.