Это копия, сохраненная 28 июня 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
В прошлый раз мы в кои-то веки не срались за кодеки весь тред, а культурно помогали друг другу с 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 для мейлача и дискорда жать. А нормисам для домашнего использования вполне хватает аппаратного ускорения.
Процессорам не нужно специально поддерживать какой-либо кодек, потому что процессор декодирует и энкодирует программно, а программно можно кодировать любой кодек, хоть 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 (буквально расположение чипов на одной плате)?
Возможно, именно отсюда у меня и началась путаница, а так ответ очень помог разобраться, большое тебе спасибо.
Да, Intel QSV это медиадвижок-асик. Он и декодирует, и энкодирует аппаратно.
Преимущество за счёт близости к CPU – какая-то шизотеория, едва ли это можно измерить и почувствовать.
> а мининг-асики
Давно из 2017? Теперь редивони и в мининге говным-говно с отвалами. Похоже 400 рыксы им не переплюнуть по части всего, простая как топор и эффективная так же как топор, не топ, но дело своё знала.
Что конкретно тебе непонятно? Там же всё элементарно.
Вот выдержка из моей старой шпаргалки по 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, файлы очень жирные. Кристал марк грит винт еще нормально работает, пикрил.
Вопросы еще такой: почему мой пека может записывать качественно только с огромным битрейтом? Потому что на кодирование нужны ресурсы, и вся эффективность кодировки заключается в том, какое будет соотношение размера к качеству?
Какой процессор в шлеме? Там зависит от поддержки аппаратного ускорения в чипе. Посмотри через dxva checker что тянет ГПУ. И попробуй через mpv.net с включённым ускорением посмотреть
Это конечно да, но мне важнее вопрос с моими дисками.
Судя по ошибке ты про ОБС студио? Если ты пишешь стрим, то нехватка ввода-вывода может привести к ошибке. Это логично, потому что буферы не бесконечные и рано или поздно переполнятся.
SoC: Qualcomm® Snapdragon™ XR2 Platform. MPV так же плохо воспроизводит, как mpc. Я уже забил. Железо короче не тянет.
>Судя по ошибке ты про ОБС студио?
Да
>Если ты пишешь стрим
Нет, просто записываю игрушку для монтажа. И это меня как раз удивляет, так как чтение-запись у винта достаточные. Тут нужно сказать, что игра и система на ссд, так что во время процесса записи винт ничем другим не занят вообще, туда только пишется видео.
>>06139
Дополню. Я, наверное, тупой. Да, действительно, CQP хорош для работы с уже готовым видео и его дальнейшим пережатием, но оптимален ли он для записи - вопрос, на который я ответа не нашел.
> Потому что на кодирование нужны ресурсы, и вся эффективность кодировки заключается в том, какое будет соотношение размера к качеству?
Ну в общем-то да, срать огромным битрейтом дело не хитрое, а вот достигать аналогичного качества с меньшим выходным размером – это и есть суть сложности сжатия.
Для последующего монтажа при записи нет смысла нагружать кодировщик сложными методами. Просто выставляй высокий постоянный битрейт, а уже на этапе финального рендера сжимай как хочешь.
Я просто опирался на данный гайд, когда начинал записывать: https://www.nvidia.com/en-us/geforce/guides/broadcasting-guide/
Сказали ставь CQP, я поставил без задней мысли. Только там есть хуйня - сказано выставить 15, но на практике ниже 20 разницы не будет никакой, а вот размер файла будет ебический. Короче да, буду пробовать проще, спасибо за совет.
Этот гайд наверно рассчитан на запись сразу конечного результата. У меня самого в ОБСе настроено несколько профилей для разных ситуаций. Иногда надо записать и сразу отправить, а иногда записать для монтажа с минимумом потерь.
Ну дык сам посчитай. 50мбит это 410 мегабайт в секунду на диск пишет. Попробуй с пресетами поиграть. может у тебя HQ какой-нибудь стоит. Может в карте дело, ты же не сказал какая. Я писал на своей 1063 в 50мб без лагов, а geforce experince 100проц без лагов пишет, но вес большой.
Хотя туплю это всего 6 мегабайт в секунду, что получается
Пресет стоит 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.
Ух ты, про встроенный AAC encoder не забыли и улучшают его качество. Надо будет потестить.
>чел рассказывает, что NVENC на новых картах (я так понял речь про Turing и Amper) = x264 Slow.
Пиздеж. Там до слов как раком до луны еще. Чел выше правильно написал h264 medium максимум. Я вообще через проц пишу, в x264 fast в 12000кбит. Попробую nvenc для теста в cq 24.
Можешь еще streamFX скачать и потестить. Там более тонкие настройки, также есть nvenc h264-h265,prores_aw и даже AV1 через aom.
Не вышел еще что ли? Даже исходники с офф.сайта еще старые.
Это скорее всего для продукции аппле сделано
Этот аппаратный вп9 на инцеловстройке говно по уровню сжатия, хоть и весьма быстро. А нахер тогда вообще нужен вп9, если не для максимального сжатия?
Я думал он примерно на уровне с libvpx-vp9, но сравнить так и не довелась возможность.
А сейчас уже можно кодировать в libsvtav1
Ну тут я так понимаю замечание в том, что аппаратно ускоренный vp9 может выглядеть не лучше vp8, что вызывает вопросы к его уместности.
> А нахер тогда вообще нужен вп9
Даже гугл этим вопросом после его создания задался и за десять лет нормальный энкодер к нему так и не завёз.
>Ты нихуя не понял. Есть два видео, разные. Размер первого, допустим, 400 мб, второго - 600. Я прогоняю их через одни и те же параметры. В итоге получаю - первое видео - 150 мб, второе - 610 мб. В первом случае все успешно, во втором - размер файла только увеличился. Вот это непонятно, какого хуя.
Очевидно твои настройки кодирования слабее оригинала.
Пробуй preset veryslow
А может ты вообще через жопу что-то делаешь. Кто тебя знает если ты страницу из гкгла осилить не можешь.
Что mediainfo говорит о твоих исходных файлах?
Можно скачать с Ютуба вебм без конвертации
Какова цель перепердоливания?
ffmpeg -i video.mp4 out.webm
>Тетя Лиза грит НИНУЖНО
Каким же конченым долбоёбом нужно быть, чтобы сравнивать околотоповую видеокарту за $200 до кризиса с затычкой за $200 в разгар кризиса.
Сравнивай ХОТЯ БЫ с 6700 XT, она $450 стоила на старте, долбоёб.
Скорее всего, первое видео пару секунд, а второе минут на 5. Поэтому и размер разный, потому что crf юзает.
Какая разница кризис не кризис, офф цена одна и позиционирование тоже. Такое жидовское говно, которое слабее карты 6 летней давности, показывает отношение и как они хотят срубить бабла отбраковками на гоях.
Говновидия хотя бы высрала ртх 3050, с которой хоть что-то можно делать. Новые игры фуллхд на ультрах 60 фпс, длссы длдсары, для кодирования и работы 8гб, еще и мощнее 6500хт на 110%-120%.
Нет, полно тестов на ютабе с pci3, просто там из-за урезанных линий предсказуемо производительность совсем невыгодная по сравнению с конкурентом, с 1650 насколько помню её сравнивают.
Да полно тестов, где с pci 3 у нее падает производительность в 2 раза буквально, достаточно на канал бороды зайти.
576x1024, 0:13
Это объемный звук? При проигровании этого видео на телефоне, сначала использовалось оба динамика, затем только разговорный, а потом только обычный. Как добиться такого же эффекта?
Все резко поняли, что ты имел в виду. Либо по английски пиши, либо штаны одень.
И что мне этот анимешный высер даст?
Еба что за пиздец, для этого придумали режим 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.
> CRF предполагает повышение квантователя для динамичных сцен, за счёт чего и осуществляеться экономия битрейта
И понижение в статичных.
> CQ это про постоянный квантователь
Вот, кстати, относительно этого, я понимаю, почему у некоторых могут возникать недопонимания, дело в том, что гугл решил, что ну его нахер эти стандартизированные абревиатуры, изобрету свои, и cq в их понимании другое, не то, чтобы это относилось к делу в данном случае, но нужно учитывать, мало какие документации читал чиловек
Собственно с 'q' у них таже история, постоянный квантайзер my ass, если qmax и qmin укажешь идентичные(чего в vpenc сделать нельзя, он требует минимум +-4, а вот ffmpeg кушает за обе щёки) то может и будет постоянный.
>Параллельно с этим в условиях ограниченного размера видеофайла одним из наилучших методов сохранения качества видео признаётся использование параметра сжатия 'Constant Rate Factor'.
Нет, лучший метод это для сохранения качества VBR с мануальным вычислением битрейта каждого отдельного видево. CRF настолько знаю просто держит определенную планку качества и ему похуй какой будет размер в итоге.
>Программа подойдёт пользователям, любящим выжимать максимум из доступного ограничения на размер файла, что в условиях постинга на АИБ вполне оправдано.
Вау, пориджи придумали vp9 CQ - constrained quality.
>В период примерно 2015-16 гг [бум популярности кодирования WebM как технического новшества] показателем мастерства считалось кодирование WebM
С этого конечно описялся.
> меняет тамошний Q на VBR режим
Или на CBR, но я не разбирался, а вот с режимом 'q' пару лет назад были обсуждения в вебм треде, с учётом, что гугл vp9 забросил, не думаю, что что-то изменилось.
Про tune grain знаю, конечно two-pass, главное чтобы пиздеца в кадрах почти не было
Скачать уже готовые хевк 10бит фильмы. сделанные мастерами пердолинга, нужного тебе размера и не ебать себе мозги?
Не ебать себе мозг и скачать mp3tag.
Как известно есть два аппаратных способа конвертации. На 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 обработкой?
Разве файлы не должны получаться идентичными при равных настройках кодирования одним кодеком? Почему так сильно падает качество при гпу обработке и как его можно улучшить?
Как известно есть два аппаратных способа конвертации. На 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
А если ты кидал ссылку чтобы дать мне значения RF, то спасибо, я воспользуюсь. Выглядит правдоподобно.
> Выглядит правдоподобно.
Это я говорил про уменьшение реуомендуемых значений с падением разрешения.
А вот то что они советуют одинаковые значения для x264 и x265 - говорит мне о том, что остается 2 возможности:
- гайд писал чел, который не шарит
- Handbrake ввел свой RF и переводит в ffmpeg'овские CRF для x264 и x265, то есть этот RF ничего не значит для меня
В теории crf должен выдавать одинаковое качество у любого кодека. x264 и x265 довольно схожи и могут принимать одинаковые значения
Нет, не должен. Принимать могут, но уровень сжатия разный.
Ренжи одинаковые, как у qp, но проводить какую-то параллель между значениями crf у кодеков разного поколения навряд ли адекватно.
Короче это ближайший тред про редактирование видео, поэтому спрашиваю здесь: В видео аудиодорожка при проигрывании ее с динамиков ноута например еле слышна, но она же заебись слышится в наушниках затычках. Как называется эта проблема и каковы пути ее решения? "верха повышать низы занижать"?
> Как известно есть два аппаратных способа конвертации. На 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 кодируется разными кодировщиками.
> Почему так сильно падает качество при гпу обработке и как его можно улучшить?
Потому что гпу
Поступила в пту.
Цпу же молодец,
В вузе он отличный спец.
Таково аппаратное ускорение, просто прими это как данность. А чтобы его улучшить, выставляй самые медленные настройки.
> Как известно есть два аппаратных способа конвертации. На 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 кодируется разными кодировщиками.
> Почему так сильно падает качество при гпу обработке и как его можно улучшить?
Потому что гпу
Поступила в пту.
Цпу же молодец,
В вузе он отличный спец.
Таково аппаратное ускорение, просто прими это как данность. А чтобы его улучшить, выставляй самые медленные настройки.
>Почему так сильно падает качество при гпу обработке и как его можно улучшить?
Вроде как из-за того, что при аппаратном кодировании картинка делится на участки и картинка в этих областях кодируется изолированно. То есть задача распараллеливается и потому быстрее выполняется, но из-за изолированности каждого участка качество выходит хуже. Вроде бы так.
Спасибо, но заскриптую сам, хотя если на питоне, то кинь
Звучит логично.
>фильмы олдовые и в таком виде в принципе не существуют?
Да большинство фильмом более менее популярных 100% есть, могут не быть разве что какие-нибудь авторские короткометражки, и по их тоже полно перекодированных уже.
менять
Чет слишком комбайн какой-то, нужен именно для ффмпега гуй с окошком для своих команд
Сделай сам.
Как же досадно, что во многих видео перемотка работает плохо! Настроил на одну секунду, а плеер перематывает на 5, 8, 10 или 20. Ютуб, ВК, bdrip с торрентов - там можно это увидеть. Если перематывать точным способом, то это ахуеть можно с задержек (зависит от видео - где-то они почти незаметные, а где-то долгие). Как быть тогда? Не всегда есть возможность скачать в лучшем качестве (в более тяжёлых раздачах такой проблемы с перемотками нет). Плеер mpv.
Какой кодек выставлять?
Указывайте Win это или Lin
Блять, забыл сказать самое важное - на GPU AMD все это будет
> Плеер mpv.
Впиши в конфиг и попробуй
vd-queue-enable=yes
ad-queue-enable=yes
vd-queue-max-bytes=6000MiB
vd-queue-max-samples=2000000
vd-queue-max-secs=50
cache=yes
demuxer-max-bytes=2000M
demuxer-max-back-bytes=1000M
Boram. Но он не поддерживается c 2019 и я помню у меня были проблемы с переносом команды оттуда в актуальный ffmpeg. Но конкретно кроп, возоможно, работает как надо.
x264 fast
Серьезно? Я всегда знал, что аппаратное кодирование шакалит, но ожидал 0..5% потери качества за размер.
Или это у Амуде так все хуево как обычно?
Ему и искал альтернативу
https://sourceforge.net/projects/ffmpeg-batch/
даже больше.
Переконвертировал игровые звуковые файлы новеллы с этой штукой примерно 32к файлов.
А предпросмотри я видел только в вебмретардс.
Ну еще и как говорил анон avidemux. Также юзаю на постоянке Hybrid от selur, но там именно для avisynth/vapoursynth предпросмотр, но он итак работает.
Этой тоже пользуюсь. Походу нет того, чего хотел, да и пох.
Тогда еще вопрос, есть такая команда, чтобы во время энкодинга рядом с командной строкой в реалтайме отображалась выходная картинка, т.е. последний обработанный кадр?
Ну да, амд похуже. Ну не прям сильно
Возможно перемотка стала чуть быстрее, но всё-равно долго. Бывает, что несколько перемоток подряд всё довольно быстро, а потом опять с большой задержкой.
В одном видео именно так. В другом всё ок и без этого конфига.
Сука, ну плеер же знает время. Если поставить на плей а потом поставить на паузу, тогда он может дойти до любого времени, и покажет с точностью до миллисекунд. А чтобы перемотать - тут уже ждать надо. Грустно, очень грустно.
Не, хотелось бы при каждом кодировании наблюдать результат
Битрейт рассчитывай. Допустим фильм 1 час = 3600 с, 4 мб, например, оставляем для звука, для видео есть 16 мб = 16384 кб = 131072 кбит
131072/3600 = 36 кбит/с
Для таких пожатий лучше av1
Что-то вроде этого, только у меня собственный скрипт, который кодирует сегмент указанный в AB-loop:
https://github.com/occivink/mpv-scripts/blob/master/scripts/encode.lua
В том же репе есть crop.lua, сначала кропаешь видео в mpv, потом жмешь хоткей для encode.lua, последний учитывает текущие параметры кропа.
Потому что при воспроизведении плеер декодирует все кадры, а при перемотке проходится лишь по ключевым.
Сделай себе калькулятор битрейта в экселе, всё просто.
Лол, классика. Будто мой заскринил.
Ну так раскрой подробнее. Я читаю и не понимаю. Бывает такое. Объясни на пальцах. С ffmpeg я занимался, представление о нём имею.
Разные. Но их задачи и функции пересекаются. Они в чём-то похожи. Но avisynth не кодирует и не декодирует, а ffmpeg плохо приспособлен для нелинейного монтажа.
Формула на скриншоте
Тогда перекодируй, Москва не сразу строилась. Не пердолик что ли? А если разница с 20 МБ небольшая, то можно отдельно перекодировать только аудиопоток, чтобы уложиться в лимит либо повысить качество звука на оставшиеся килобайты.
Через любой редактор субтитров можно подвинуть
А отрицательное?
Сейчас проверил, libvpx VP9 при прочих равных сжалось примерно на 5% хуже на 4 потоках, чем на 1.
Этот кривой кодек будет сжимать хуже если увеличить размер tiles
Ага. Когда абу обновит ффмпег никогда, да и вп9 вроде такое же качество даёт, тогда будут миниатюры.
За одинаковое время кодирования и одинаковый битрейт ав1 будет выглядеть лучше но это не точно
Это единственная команда для склеивания однородных файлов?
А то есть программа, которая ффмпегом соединяет, я попробовал сам соединить, вроде все нормально, но итоговые файлы совсем чуть-чуть различаются. Может лучше как-то иначе делать?
Да, остальные криво работают
ffmpeg -i hetero.mp4 -ss 00:39:08.685 -to 00:48:12.509 -c:v copy -c:a copy gay.mp4
Но если со звуком норм, то видео проебывает секунд по 20.
Точно по миллисекундам – никак, начало должно быть на ключевом кадре. Не ебись с ffmpeg, нарезать без перекодирования проще в avidemux.
Куча патентов, нет свободных реализаций, требуют деньги за использование. И это когда есть полностью свободный opus который совсем чуть-чуть хуже
Внезапно у новых вебм'ок перестало появляться превью. Команда простейшая -вход -выход. Здесь, как видите, превью у них есть. В чём проблема?
Вроде как проблема появилась после установки программы для достройки промежуточных кадров. Её уже удалил.
>после установки
Запишу твою проблему в список доводов против установочного софта и запуска разной параши от имени администратора. Спасибо.
Запишись лучше сразу в дурку, там обязательно помогут, после курса галоперидола.
icaros shell extensions
Ну, на некоторых затычках у nvenc есть режим без потерь, которого пока больше нет ни у синих, ни у красных. Если бы невидия работала без выебонов, то это был бы ого-го какой аргумент для меня.
> на некоторых затычках у nvenc есть режим без потерь
На каких затычках и что за лосслесс? Вот тут поподробнее.
Обычный без потерь. Как crf 0 у x264. Причём тут crf вообще
>На каких затычках и что за лосслесс?
Преимущественно не на дешёвых.
Подробности тут https://en.m.wikipedia.org/wiki/Nvidia_NVENC#Versions
Полгода назад обсуждали в этой ветке. Тогда ценник на 264-ку без потерь начинался от 20 тыс. руб., а на 265-ку от 30 тыс. руб. Сейчас дороже.
Сап, аноны. Нужна помощь. Делал в проге boram webm'ку, поставил кодек AV1. При его использовании видео рендерится, но потом когда постишь на 2ch — то не видно превью, пикрил. Что делать? При юзании кодека VP9 всё ок, но хуже качество.
Уебан Абу уже сколько лет не может прикрутить к своей конченной хуйне поддержку этого супер годного кодека
Чушь.
Можно сохранять из премьера в нормальные кодеки
Поиграйся с dehalo, если это то, о чём я думаю
Ну и dering до кучи глянь
Что за source filters?
LAV или мелкософт?
Или не нужно ебать себе мозги, актуальный максимальный к-лайт конфликтной хуйни не ставит? Или есть мануалы?
не знаю куда писать, наверное, надо идти на профильные форумы видеоредакторов
Да ничего не надо ставить. Все эти кодеки были актуальны лет 15 назад. Сейчас система и программы давно изменились, они даже не берут их оттуда, а тащат свои.
aom хуита
Потому что с ним работают бесплатные опенсорс ffmpeg и mpv.
Из-за того, что он всегда был стандартом для Blu-ray видео.
А почему тогда всем похуй на evc?
> Причём современный 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.
Второй день экспериментирую. Ничего не получается.
Вместо 2 дней экспериментов мог бы уже сделать это в 2 строки отдельно в yt-dl и ffmpeg, пердоля.
Ебать ты поехавший, щяс бы два дня потратить на этот ебанутый способ. Неудивительно что у тебя линукс стоит, но странно что убунту, он старается быть на нормальных людей.
Ради тебя встал и скопировал команду
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 со своим дефолтным (?) сжатием диск особо не насилует, но тут уже реалтаймовое сжатие видео не вывозит процессор.
Места на жёстком диске дофига.
Какие есть решения, которые бы сжимали несильно, чтобы успевало в реалтайме, но при этом не в ущерб визуальному качеству видео, а в ущерб объему? Десятки и сотни гигов получившегося видео - не вопрос, после записи пережму нормально.
Lagarith.
Ну и в чем он ебанутый?
По-моему, как раз удобно в одну строчку скачать отрывок + сжать его.
>Неудивительно что у тебя линукс стоит, но странно что убунту, он старается быть на нормальных людей.
Лол. Щас бы сидя на дваче рассуждать про нормальных людей.
В любом случае, спасибо за помощь. Получилось типа такого:
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
>>24121
>CQP 23
По умолчанию стоит 20, так что его можно и оставить.
Зачем ты перегоняешь в vp9, если настройки по умолчанию в фф невероятно ужасные, когда на Ютубе и так можно скачать этот кодек??? ПИЗДЕЦ
Не надо использовать cqp, ставь cbr где-то 50000 КБ, и вообще лучше через Nvidia experience
В клоуна решил поиграть?
CQP тем и хорош, что сам рассчитает, как пользователю будет заебись исходя из сцены.
>Expirience
Не забудь зарегистрироваться где-нибудь, чтобы блядь еще воздухом подышать. Ни разу на дваче не видел сравнения в лоб нвенка от обс и нвенка от хуйвидии, а никому это не упало потому что и разницу не увидишь, потому что ее и нет. Обс замечательный инструмент и точка, никуда дергаться не нужно.
> CQP тем и хорош, что сам рассчитает, как пользователю будет заебись исходя из сцены.
Нихуя cqp не рассчитывает, это crf рассчитывает который нвидиа не поддерживает
> Ни разу на дваче не видел сравнения в лоб нвенка от обс и нвенка от хуйвидии, а никому это не упало потому что и разницу не увидишь, потому что ее и нет
Ебать дебил. У экспиренса намного меньше накладные расходы за счёт того что он не строит 3д сцену и использует специальные интерфейсы, без копирования картинки. Обс не нужен для простой записи игры.
> Хочу записать видео прохождения некоторых её кусков в 1920x1080 @ 60 fps или мб даже 3840x2160 @ 60, если мне дадут погонять 4K-монитор
Кстати ты можешь записать его и без 4к монитора, через DSR
NVFBC называется. Разница есть, и более чем заметная
>Нихуя cqp не рассчитывает, это crf рассчитывает который нвидиа не поддерживает
У них одинаковое предназначение - целевое качество выходного видео, об устройстве каждого я не знаю, мне и не нужно. Если процессор не тянет запись, то просто пишешь на карте, только и всего
Нет, ни одинаковое. Cqp работает по другому и делает хуже картинку чем у crf.
Ладно, выстави тогда нормальные настройки, например обязательно quality good и mt-row 1, и пресет тройку где-то. Могу скинуть конкретно
скинь, плиз.
У меня тут другая проблема - в самом начале низкий битрейт. Может как раз в настройках дело.
Так и должно быть в начале с битрейтом. Установи windows terminal
И я вспомнил, vp9 так вообще нельзя конвертировать. Обязательно нужно два прохода, если один качество будет намного хуже! Так что скачивай видео и только после этого его конвертируй
https://0bin.net/paste/BWVblfKe#AscsdMVvgVqEEldRPxSrEXZvDrmV7eiBQm5QKHTaoyA
понял. Ну значит так и придется поступить.
Спасибо за настройки, анон.
>Так и должно быть в начале с битрейтом. Установи windows terminal
Да я практически все время на линухе. Если буду на винде, то поставлю.
>кспиренса намного меньше накладные расходы за счёт того что он не строит 3д сцену и использует специальные интерфейсы
Почему обс не может просто взять и делать то же самое?
Для этого придётся выпилить из обс все эти сцены и разными источниками. Да и наверное можно это добавить, но никто этим не занялся, нужно заплатить денег за работу
мимо обнял
Свинья перешла на визг, а я на ор!
На фамилию обрати внимание, либо поляк, который трясётся за свою жопу, либо пидорнутый из Беларуси змагар.
Это не много, но с этого можно начать дальнейший поиск: 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"
Переменный битрейт и прочие умные методы – не то, потому что дело не в динамике, а в субъективной важности определённых моментов.
В голову приходит только отдельное кодирование нескольких фрагментов с последующим склеиванием, но это топорный костыль, к тому же на склейках будет резкое изменение качества, а снижение и повышение хотелось бы делать плавным и незаметным.
1ffmpeg media encoder, охуенно работает, он же сразу с гуем
2shutter encoder боат жив, всем советую
3качай в newpipe или yt dlp и режь уже скачанное, иначе никак, либо будет рваная хуета. Ютуб это очень хитрый видеохостинг, а не радикал.
Мне посоветовали ffmpeg, но я что-то ничего не понимаю.
До это с кодированием был никак не связан.
Посоветуйте гайд чтобы просто сделать музыкальную вебмку.
Ну или если просто не получится, то хотя-бы основы чтобы начать понимать суть.
ffmpeg -r 1 -loop 1 -i pic.png -i music.flac -map 0:v -map 1:a -c:a libopus -b:a 128 -c:v libvpx-vp9 -b:v 0 -crf 16 -g 9999 -pix_fmt yuv420p shortest output.webm
Где -quality good? По умолчанию стоит хуйня из-за которой кодирует намного медленнее
Захват экрана через gdigrab плохо работает. Какой-то дикий пропуск кадров. Как фиксить?
Ну если по умолчанию для libx264 -preset medium, то попробуй fast, faster, veryfast, superfast, ultrafast. А вообще ffmpeg gpu-ускорением не обделён, попробуй h264_nvenc / h264_amf / h264_qsv.
Да, я не дочитал, извини.
На ультрафаст получше, но все равно пропускает кадры. На hd3600 можно ускориться? Не нашел команду.
Она должно быть не умеет энкодировать. Твоя некропека особо не годится для записи, придётся смириться с пропуском кадров. Попробуй снизить fps до 15-10-5..
А, ну тогда буду читать.
ffmpeg -loop 1 -r 1 -i "cover.jpg" -i "music.flac" -t 00:04:05.23 (длина музыки) -c:v libvpx-vp9 -pix_fmt yuv420p -colorspace bt709 -g 360 -c:a libopus -b:a 128k -map_metadata 1 -shortest "output.webm"
А мы будем
У тебя айпад пердежных лет? Тем более, в софтварном режиме любое видео должно воспроизводится. Кто виноват, что в сафариговно не добавили-то.
>>26501
Потому что в 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%
>А у меня не багуется, и что ты мне сделаешь?
Разве что залупой по лбу дать.
В командную строку куда еще. Как установить ffmpeg и прописать в переменные среды винды, полно гайдов на ютабах.
Понял тебя.
А, я сейчас проверил старую шебму, а там действительно тишина на 20 секунд, а я даже не замечал.
> Разве что залупой по лбу дать.
Тебя там отец на ошибки наказывал? Соболезную.
Почему gop только на 6 минут?
И команда которую ты пишешь?
То есть вместо приведения полной команды ты предлагаешь нам искать гайд какого-то пидаруза?
> поясни в чем дело
Ты даун, для начала.
И конвертирует ли ффмпег картинки?
Всё дело в инструкциях, а не в ядрах.
Да, современные камни уже довольно давно растут в производительности не экспоненциально. Каждое следующее поколение добавляет по 10...20% 5...10% производительности на ядро. И прирост год от года снижается.
Сап, кодировальщики, прям не знаю, где ещё спросить.
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
Спасибо, что указал и на подробную тему с Reddit. Было бы приятно и здесь указать анонам, что не так
хз. Фотки какие-нибудь обычные jpeg, еще есть jpeg-xl, webp, avif, но ты с ними быстро не сможешь поделится.
Видео x265/hevc 10bit, или vp9. Хотя тут смотря что ты подразумеваешь под хранением.
Jpeg xl лучший для картинок, без конкурентов
Для видео libaom лучший, но сжимает в десятки раз дольше, непрактично, лучше SVT-AV1 или x265 10 bit slow
https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.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/
>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/
Что-то я проверил на большом 4к фильме и оно даже медленнее так кодирует, иногда хеши сходятся, а иногда нет.. Уберу эту опцию тогда
Не понял, расшифруй мысль, он гайдит по кодированию, ты приносишь информацию о просёре полимеров аппаратными декодерами. Что ты питаешься донести?
> Как-то глупо ставить медленный пресет, изначально портя качество аппаратным декодированием
Ой бля, ты кодирование с декодированием путаешь, выдержка из мануала mpv здесь ни при чём, там о вреде аппаратного декодирования, а не кодирования. Аппаратное кодирование ничего страшного за собой не несёт.
Чтобы закодировать, самому кодировщику нужно неожиданно прочитать исходник, то есть декодировать его. -hwaccel auto даёт команду делать это аппаратно, а вред аппаратного декодирования расписан в мануале mpv.
>>31230
> ты кодирование с декодированием путаешь
Не путаю.
> там о вреде аппаратного декодирования, а не кодирования
Знаю.
> Аппаратное кодирование ничего страшного за собой не несёт
Толсто.
> Чтобы закодировать, самому кодировщику нужно неожиданно прочитать исходник, то есть декодировать его
Теперь понял, я изначальной команды не видел, потому и удивился, что анон пишет
>hwaccel
>preset slow
и я допереть не мог к чему это
> https://web.archive.org/web/20210401103230/http://www.3ivx.com/support/calculator/index.html
Не нужен. Делается в экселе за минуту.
Дааа охуенно придумал, каждый раз ждать пока запускается эксель вместо удобной страницы которая открывается секунду, в которой ничего лишнего
Хром всегда запущен, страницу открыть в нём займет менее секунды, а огромный эксель на любом компьютере запускается десяток секунд
Зря ты накатил офис 2021 на свою корудуба. У эксель открывается за секунду.
Давайте теперь смотреть видео без аппаратного декодирования, если качество старадает прям пиздец. По факту разницы не будет
Сейчас бы беспруфный высер мпвшизов выслушивать, который на каждый пиксель с лупой дрочат. Объективного сравнения не было. Я вообще с nvdec cuda декодирую за секунды и похуй.
> беспруфный высер
У тебя в башке, разве что. А ffmpeg это часть mpv, шизло, поэтому, всё, что там есть и к ffmpeg относится.
Очевидный пук в ответ от мпвдибила. Это не я опровергаю тем более, а ты начал челу выше доказывать бепруфным кукареком от мпвшизов, что нинужно. Не учитывая, что актуальная там инфа или нет вообще и когда писалась.
> Это не я опровергаю тем более, а ты начал челу выше доказывать бепруфным кукареком от мпвшизов, что нинужно.
Конечно не нужно, нужно аппаратно декодировать на камне, а не на чипе видяхи, за камнями зашкваров не наблюдалось.
> нужно аппаратно декодировать на камне
На интеловской встройке что ли? Ты оговорился или я чего-то недопонял?
На процессоре.
ffmpeg -i "1.mkv" -c:v libvpx-vp9 -quality good -cpu-used 4 -b:v 5000k -pix_fmt yuv420p -lag-in-frames 25 -tile-columns 2 -tile-rows 0 -threads 8 -row-mt 1 -auto-alt-ref 1
потому что они говно. Зачем мне юзать вп9 и не юзать при этом максимальные параметры сжатия. Даже mp4 veryslow будет лучше чем спид 4.
У уого такое было, что
ffmpeg -i input.mkv -vf reverse output.mkv
вызывает огромную утечку памяти?
Четырехминутное видео с ютуба, размером в 3мб. Озу 12 гб.
Это не совсем можно назвать мемори ликом, потому что оно использует памать согласно документации в нужных целях. Не знаю, почему эта операция требует столько, но это нормально
Склеивать можно по списку в тхт файле. Сам файл сгенерировать питоном, но ты, вероятно, не умеешь. Попробуй экселем, он же сечёт закономерности в росте чисел. А потом скопируешь в тхт.
> Хотя интересно, выйдет ли экселем.
Любым текстовым редактором с поддержкой регулярок выйдет
s#(^.*$)#\1\n\1#
Экселем тем более.
Всего 12 гб. После переполнения ффмпег крашнулся. Собстенно, проблема скорее не в утечке, а в том, что от нее ффмпег крашится.
БАМП
Есть один файл.
В формате wav, 1.4 секунды.
Который отказывается воспроизводится на телефоне в качестве сигнала уведомления или так.
На ПК он воспроизводится без проблем, но ни один анализатор спектра ничего не показывает.
Конвертация в ogg, acc, opus, mp3, flac в ffmpeg c изменением частоты дискретизации не помогает.
Добавление секунды тишины в конец, изменение темпа, компрессия, перезапись с помощью плеера и wat u hear в Audacity тоже ничего не меняет.
На ПК воспроизводится, на телефоне нет. Анализаторы спектра молчат.
Что за чёрная магия?
Что ещё можно попробовать?
Что о нём пишет mediainfo?
wav - это всё же не формат, а контейнер, как и avi, и внутри может быть что угодно.
Я имел в виду не формулой, а просто растянуть, чтобы он сам угадал закономерность.
Сам файл вот.
https://anonfiles.com/F0H8JeRbx4/RadioMessage_wav
В нём битый счётчик сэмплов и как следствие неправильно показывается его продолжительность, но это-то исправляется при конвертации в другой формат.
Вот он открыт в редакторе, никаких проблем. Но анализ спектра покажет пустое место.
Что такого там может быть, что не уходит при преобразованиях?
При этом у меня несколько телефонов, и на одном из них (sony) всё работает. А на других нет.
Хм, хуй его знает. Сейчас тоже чего только ни делал с этим в вейвлабе, питч туда-сюда, эквалайзер - похеру. Не хватает познаний, видимо.
Или лучше ffmpeg -i 1.aiff -c:a alac track.m4a
Конкатенирую стандартной командой с вики несколько вебемок в одну длинную
Использовал [code]ffmpeg -f concat -safe 0 -i fileList.txt -c copy mergedVideo.webm[/code]
Сначала видео было с нормальным звуком,потом, начиная одной вебемки ,звук испортился. Попробовал переставить эту вебемку в начало и склеил заново. В результате у этой вебемки звук нормальный,но во всем остальном видео звук испортился. Не понимаю в чем причина. Может нужно привести все вебемки к одному аудио кодеку ,но как это сделать?
Так нельзя соединять разные кодеки вообще чел
Решение одно сконвертировать их, но потеряется качество
Вроде норм файл. Только в заголовке присутствовала непонятная секция, нетипичная, не знаю такую. Удалил ее, короче в гекс-редакторе. Ну и тишину в начале вырезал, аж 17 семплов. И еще до кучи добавил вариант отнормированный по громкости, то есть громкость усилена до предела. Фикшенные файлы внутре картинки, в zip-архиве. Распакуй чем нибудь.
Почитал про эту секцию. Она добавляется только к сжатым форматам, а у тебя нормальный PCM, то есть она не нужна. В этой секции указывается количество семплов. У тебя указан 1 семпл. То есть, проигрыватели, редакторы, конвертеры, которые читают эту секцию, думают что в файле 1 семпл. Такие дела...
Так как сконвертировать-то? Сами они в вебем,получается нужно перекодировать звук,как сделать это?
Как можно применить это к большому количеству файлов, в стиле того, как это делается при конкатенации, через txt файл?
Насколько много файлов? Если не слишком, то для начала следует отобрать для перекодирования только те, у которых звук в vorbis.
Блять я знаю что это, там неработающие способны написаны
10-30 в зависимости от папки. Я не знаю, какие кодеки в каждом видео. Думаю, что можно было бы просто перекодировать звук под один кодек, например opus , одновременно склеивая. Есть ли такая команда? Я нуб просто, много чего не знаю.
Да можно, просто напиши -c:a opus -b:a 160k вместе когда ты склеиваешь, но он пережмёт вообще все видео
В какое место этой команды
>ffmpeg -f concat -safe 0 -i fileList.txt -c copy mergedVideo.webm
вставлять
> -c:a opus -b:a 160k
или, как еще предложили
>-c:v copy -c:a libopus
> >ffmpeg -f concat -safe 0 -i fileList.txt -c:v copy -c:a libopus -b:a 160k mergedVideo.webm
Да легко. Макаба отрезает архивы если их клеить в конец картинко-файла. Но есть способы запихнуть архив внутрь файла. Например в jpg есть секция для комментария - можно пихануть в нее, но там размер секции указывается в два байта, то есть архивы больше 65533 байта не влезут. Но есть еще png-картинки, в них размер секции пишется в 4 байта, значит можно пихануть большие архивы. У пнг тоже есть секции под комментарий - вот, пихаю туда. Для этого напейсал всякие приблуды, которые автоматом все делают. Зацени.
Можно открыть в 7z-опвском файовом менеджере. Можно добавить расширение rar, 7z, zip и открыть/распаковать как обычно. Ну а я открываю в total commander-е напичканом плагинами.
Не. Если добавить расширение .rar, то 7z не открывает, и не распаковывает. С расширениями .7z и .zip норм открывает, даже если там rar. Щас попробовал.
Я обнаружил через 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
В чем разница? Метаданные влияют?
Я обнаружил через 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
В чем разница? Метаданные влияют?
Возможно и правда влияют. Начал склеивать в другой папке,там такая же ситуация. Если у видоса портится звук,значит у него отличаются метаданные. Как это исправить?
> Да легко. Макаба отрезает архивы если их клеить в конец картинко-файла.
А если пикрил отключить, то отрезает?
Может в энкодерах разница? Сколько не смотрю на метаданные из поста, не понятно в чем беда
Только что скачанные - не обрезанные. Но со временем макаба вроде оптимизирует картинки и все лишнее отрезает. Позже надо проверить.
>>32927
> попробуй так https://dropmefiles.com/aDY8v
> Фикшенные файлы внутре картинки, в zip-архиве.
Ничего не изменилось.
Как было пусто в анализаторах спектра, так и на телефоне не воспроизводится.
Откройте в foobar2000 визуализацию (например спектрограмма) при воспроизведении — будет пусто, хотя файл воспроизводится будет.
Единственный положительный эффект, который я наблюдал — это то что при конвертации в AAC или vorbis появляется слабый хрип на грани слышимости, какая-то часть частот просачивается и на спектр и при воспроизведении.
При конвертировании в mp3 например все проблемы должны уходить, но не уходит.
При записи в редакторе с "what u hear" тем более, но тоже не уходят.
Как не понимал что за фигня, так и не понимаю.
Я бы списал всё это на какую-то неотключаемую DSP обработку в телефоне, которая почему-то агрессивно режет именно этот узкий диапазон частот, что имеется в файле, но почему визуализации в плеерах на ПК тоже молчат?
>Откройте в foobar2000 визуализацию (например спектрограмма) при воспроизведении — будет пусто, хотя файл воспроизводится будет.
Нормально все.
>>34528
В общем вся проблема была в том что в файле ложное стерео, в котором дорожки в противофазе.
При сложении дороже в противофазе в моно получается тишина.
Телефон при воспроизведении тоже складывает в моно. А божественная сони воспроизводит стерео, ай да сони.
Вырезал дорожку псевдостерео в audicity, пересохранил и всё заработало.
Потрясающе.
О как. Точно. Если сложить каналы в один, то тишина получается - в файле одни нолики.
Не понял, почему нужно качать с джандев, если есть BtBN.
По сабжу пикрил, вот тебе конкретика. Сиди изучай, че где есть, чего где нет.
Со слов самого Джана разница в каких-то внешних библиотеках. Я по приколу про BtBN написал.
ААС вроде бы и так есть.
Ты про это? https://en.wikipedia.org/wiki/Fraunhofer_FDK_AAC
Ой короче, качаю от gyan и похуй. Еще хотел спросить, есть ли какая-то мизерная разница скорости в использовании shared и static версий?
Не, разницы нет.
Непонятно по какой причине и зачем он так странно отмечает билды, если это априори git. Latest и pre-release, типо у git версий тоже есть stable и unstable ветки? ну что за лол, только путаницы больше.
В соседнем поиске программ треде анон говорил, что final cut божественен и вообще лучше, что случалось с видеоредакторами.
Вот у меня вопрос, какой видеоредактор является таким же божественным в винде
Как раз на винде ничего подобного нет. Я сам ради этого ставил хакинтош. И вообще это я писал.
> Медленнее чем AV1?
По адресу https://old.reddit.com/r/AV1/comments/r1sv22/av1_the_opus_of_video_codecs_discuss/ приводится график Intel, согласно которому при равном качестве видео кодировщик libsvtav1 (он же SVT-AV1) работает быстрѣе libvpx (то есть быстрѣе кодировщика VP9) НА ПОРЯДОК.
(График прилагаю.)
Другое дѣло, что нам от него не скорость работы нужна, как правило. Так что разумно заставлять libsvtav1 работать гораздо медленнѣе, но выдавать гораздо большѣе качество видео, недосягаемое для VP9 при том же битрейте.
Почему это? Vp9 используют потому что он выглядит чуть лучше h264, и поддерживается в браузерах. Av1 подходит для этого ещё лучше
> Вот у меня вопрос, какой видеоредактор является таким же божественным в винде
Avid Media Composer. Стандарт в индустрии.
У тебя в башке насрано просто.
Может кто знает, можно ли в ОБС кодировщик видео и аудио выбрать такие, чтобы запись не крашилась с ошибкой? Я вроде все вариации пробовал из доступных - выдаёт ошибку? Или по старинке делать что-ли: сначала в 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.
Смысла сразу снимать в vp9 нет, только уже перекодировать в него. Насчет svt не знаю, да и он только на последних интелах.
> Насчет 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 года.
Ну фиг знает, я как-то пытался, потом увидел харки, что зеоны только с v4 и забил. У меня-то 2678v3+16гб рам.
Писать-то можешь, но вот качество говно будет. А vp9 нужен только с настройками для максимального сжатия.
Напишите пару строчек по теме, чтобы тред не удолили. Думаю тред будет полезным
>>3136277 (OP)
А есть чо менее дрочерское (с нормальный интерфейсом) для простейших задач (обрезка, склейка, конвертирование), но все же минималистичное (Premiere и прочее будет оверкиллом)
Avidemux
Сможет ли видеокарта сжать видео так же эффективно, как процессор, но при этом в разы быстрее? Если нет, то почему так?
Не сможет, чудес не бывает. Или быстро или качественно. У нвидии ещё более менее качество, на уровне x265 medium
А давай сделаем тесты? Аноны, подскажите, как это организовать! Хочу сравнить libx264 и h264_nvenc.
Шкрепты напиши для ffmeg да сравни. Я как-то делал - качество сильно хуже чем процем жать почему-то.
В staxrip есть функция сравнения видео по кадрам рядом с друг другом. Там же можно и сжать по разному
Я вот как-то еще не дорос до скриптов, все обычно руками прописываю. На чем пишешь, бат небось какой или пш1?
>>36472
>ставить еще одну программу
>осваивать ее
Мне ЛЕНЬ не столько руками писать параметры и затем сравнивать скрины, сколько осваивать новое по. Прямо фу. А еще я почитал мануалы по предустановкам использования (fast, medium etc), crf, профили и мне стало лень делать вообще что-либо.
Я не знаю, чего именно я хочу. Не знаю, как сравнить два энкодера - по битрейту? Я что, должен его руками задавать?
Кароч чето муторно все это, я ибал.
Мне хотелось простого ответа - nvenc ебет или не ебет? А оказалось, что придется ебаться самому.
> Мне хотелось простого ответа
Новый нвенк весьма хорош, но этим сказано далеко не всё. Везде разный баланс между уровнем сжатия и затраченным временем, однако баланс ничего не решает, когда у тебя есть определённые приоритеты. Мы тут собрались в основном пердолики и топим за максимальное сжатие любой ценой, но мы двачеры-максималисты, каждому из которых по отдельности доверять не стоит. Под разные задачи и сценарии использования лучше подходят разные кодеки, методы и их настройки. Если поваришься в теме сжатия подольше, это всё быстро станет для тебя интуитивно понятно.
Бамп. Почему gop только на 6 минут?
Мне мало утверждения
>на уровне
что это вообще значит? Выходной размер такой же при одинаковом заданном битрейте и выходном качестве? А как сравнивать x264 в режиме CRF с nvenc?
Я почитал еще с прошлого треда про квантизацию и понял, что cqp куда тупее, так как обрабатывает вообще все кадры одинаково, тогда как crf анализирует уровень движения или что-то такое, поэтому разные кадры сжимаются тоже по-разному.
>>36537
Да я и так с вами сижу уже черт знает сколько, а голова все равно пустая и понимания нет. Зато интерес есть, неподдельный.
Типа алгоритм 264 он же одинаков что для карты, что для камня. Так почему одно хуже, а другое лучше!?
> Типа алгоритм 264 он же одинаков что для карты, что для камня.
Нет, общий только стандарт, а кодировщики разные.
Сжать прям также эффективно как процессор нет. Но на высоких битрейтах nvenc давно равен x264. НО считаю кодирование в 300 фпс на моей 1063 стоит того.
У меня в obs стоит пресет quality с vbr 10000k max 12000k бфреймов 4. Удовлетворительное качество при минимальном весе. За 20 минут где-то 1.5 гига всего набегает.
Это может зависеть от сложности отдельных участков видео по динамике.
Без перекодирования только по ключевым же
ffmpeg -i video.mp4 -ss 00:10:30 -to 00:11:30 -avoid_negative_ts 1 -c:v copy -c:a copy output.mp4
Я в курсе, сам им пользуюсь, но про эту команду не знал. В какую сторону смещение?
576x1024, 0:15
Вот этот видос он вроде клеил.
Обычный метод подходит скорее для дискорда, который берёт для превью первый кадр, а не случайный, как мейлач. Мне сейчас некогда экспериментировать, но по твоему мп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 кб/с? И между какими командами нужно вставить (команду для изменения качества)?
>Как увеличить аудио битрейт хотя бы до 128 кб/с?
-b:a 128k
>И между какими командами нужно вставить (команду для изменения качества)?
После -acodec aac в параметрах кодирования этого кодека.
128 не сработало (получил те же 81 кб секс), а вот когда выставил 256 то получилось, спасибо.
Не должно быть такого. Используй обычный самый обновленный ffmpeg. В старых версиях полно багов. Буквально во всех кодеках каждый день исправления. А ты видимо какое-то старое говно юзаешь из гуев и прочих.
>Прога позволяет создавать подобные видики буквально в два клика.
Можно просто батник написать кинуть в shell:to и делать такие видосы в настоящие 2-5 кликов.
Полный пиздец, ты используешь ужасный кодировщик . Прочитай faq
Накатал тут целую паста какой до этого большой пердежный сложный и хуевый скрипт. Удалил к хуям всё.
Полностью новый написал короче. Тупо граббит имя файла и вставляет его в metadata title. легко и просто.
https://0bin.net/paste/uMpDdfPp#YmWIMeIvEVOuUNHJOwpsg-Dp4pOPCHn0XuxUW2Ec2LC
Он кодирует быстрее и с лучшим качеством, при одинаковом размере
https://www.opennet.ru/opennews/art.shtml?num=57068
Кодирую 4к спокойно с 8 Гб оперативки, это написано если кодируешь много видео одновременно
Да, svt-av1
Когда я кодирую ффмпегом - в моей webm пишет yuv420p(tv, progressive).
Но я встречаю шебм с двачей yuv420p(tv). Это подразумевает progressive, interlaced, что-то еще?
Это ничего не подразумевает, для определения воспользуйся http://www.aktau.be/2013/09/22/detecting-interlaced-video-with-ffmpeg/
Есть еще дофига разновидностей интерлейсед по типу mbaff и прочих. Обычно такие файлы пишутся с камер на капоп концертах и тв программы. А так в инете везде прогрессивная развертка.
Если есть p значит прогрессивная.
Не мой кейс, мне нужно определить чисто формально, так сказать, не опираясь на контент. Этот фильтр не работает для видео из одной статической картинки, потому что разворачивать нечего, хех, но ведь interlaced/progressive определен даже для такого видео.
>>42636
Тип интерлейсинга мне пока не важен.
Мда, видимо, херней страдаю
> Я сделал vf=tinterlace, все равно yuv420p.
Как бы у тебя может видео физически быть прогрессивным, а пиксели на самом деле рисуются черезстрочно
пздц как сложна жызнь
> x265 ОФИЦИАЛЬНО больше не нужен
> Он кодирует быстрее и с лучшим качеством, при одинаковом размере
А если у меня 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
Да я через media suite. Забыл добавить походу новый параметр enable-jxl, с ним тоже не робит. Придется ждать пока добавят туда, либо самому скрипт переписывать.
> -cpu-used 0..8 (синоним: -speed, по умолчанию 1) — профили энкодера для -quality good, от более ресурсоёмких и эффективных к менее
Правильно ли я понимаю из этого, что в libvpx-vp9 при -quality best игнорируется -speed?
Нет, не игнорируется.
Гайд из шапки устарел, читай этот https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md
> 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.
Quality best можно не прописывать, потому что эта хуйня сжимает в десятки раз медленнее без особого прироста качества
В процентах насколько больше сжатие и время относительно good?
-quality best вроде даже выглядит хуже, чем -good -cpu-used 0-2. На него вообще походу с самого выхода забили.
Да ничем в принципе. Раньше в бест всегда делал, потом рыскал на форумах и нашел такую инфу. Да и кодирует в 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.
Так он и скинул, что на дискоропомойку уже 2 года поддержку не могут добавить, которая делается в 2 строки.
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
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 для разных целей предназначены.
Каких?
> хз хоть какая-то конкуренция, гугел не может нормально запердолить все кодеки свои.
Запатентованное проприетарное говно не нужно. После релиза божественного svt-av1 данный кодек показал свое совершенство
Мне даже интересно гугл на ютуб через свой косячный аом кодируют видео, или через их СВТ.
> Запатентованное проприетарное говно не нужно.
Не нужно только дебилам, которые смотрят видео в браузере. На носителях везде будет VVC, как сейчас HEVC, как был H.264. Запомните это, мрази, и не отсвечивайте своей тупостью.
> Скорее плакать
Запретит профсоюз твиттерастов? У них его вроде и нет. К тому же "покупатЬ" не значит купить, нвиде за армово ярмо предложили такие условия взятия жепы, что они отказались от этой идеи.
> Запатентованное проприетарное говно не нужно
В том то и проблема, что кодеки ла-мпег не говно и имеют крайне годную аналитическую часть, в отличии от гуглоговна, который срёт жёсткой неоднородностью видеоряда и это заметно даже не вооружённым вщглядом любому, кроме мобилкодаунов.
Это копия, сохраненная 28 июня 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.