Этого треда уже нет.
Это копия, сохраненная 28 июня 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 28 июня 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
24 Кб, 256x256FFmpeg и общий кодирования видео тред №5
В прошлый раз мы в кои-то веки не срались за кодеки весь тред, а культурно помогали друг другу с 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 (М)
В прошлый раз мы в кои-то веки не срались за кодеки весь тред, а культурно помогали друг другу с 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) на процессорах, но ведь когда мы говорим про ускорение, то имеется ввиду видеокарта, на которую перекладываются вычисления!?
И что из себя представляет эта самая поддержка? Блоки, инструкции?
Зачем тогда нужна эта самая поддержка? А насчет видеокарт - неужели им тоже нужны именно аппаратные блоки для работы с кодеками, почему нельзя просто обновить дрова и добавить поддержку программно?
Столько вопросов, а в голове мешанина. Буду крайне признателен, если вы проведете мне ликбез.
В прошлых тредах много писали про нативную поддержку конкретных кодеков (типа VP9, AV1) на процессорах, но ведь когда мы говорим про ускорение, то имеется ввиду видеокарта, на которую перекладываются вычисления!?
И что из себя представляет эта самая поддержка? Блоки, инструкции?
Зачем тогда нужна эта самая поддержка? А насчет видеокарт - неужели им тоже нужны именно аппаратные блоки для работы с кодеками, почему нельзя просто обновить дрова и добавить поддержку программно?
Столько вопросов, а в голове мешанина. Буду крайне признателен, если вы проведете мне ликбез.
>>02726
Процессорам не нужно специально поддерживать какой-либо кодек, потому что процессор декодирует и энкодирует программно, а программно можно кодировать любой кодек, хоть 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 для мейлача и дискорда жать. А нормисам для домашнего использования вполне хватает аппаратного ускорения.
>>02726
Процессорам не нужно специально поддерживать какой-либо кодек, потому что процессор декодирует и энкодирует программно, а программно можно кодировать любой кодек, хоть 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 для мейлача и дискорда жать. А нормисам для домашнего использования вполне хватает аппаратного ускорения.
>>02767
А такой вопрос - на процессорах с интегрированной графикой есть эти самые асики? Например, если мы говорим о технологии Intel QSV, это же про аппаратное декодирование? Есть ли преимущества у такого декодирования за счет непосредственной близости к CPU (буквально расположение чипов на одной плате)?
Возможно, именно отсюда у меня и началась путаница, а так ответ очень помог разобраться, большое тебе спасибо.
А такой вопрос - на процессорах с интегрированной графикой есть эти самые асики? Например, если мы говорим о технологии Intel QSV, это же про аппаратное декодирование? Есть ли преимущества у такого декодирования за счет непосредственной близости к CPU (буквально расположение чипов на одной плате)?
Возможно, именно отсюда у меня и началась путаница, а так ответ очень помог разобраться, большое тебе спасибо.
>>02776
Да, Intel QSV это медиадвижок-асик. Он и декодирует, и энкодирует аппаратно.
Преимущество за счёт близости к CPU – какая-то шизотеория, едва ли это можно измерить и почувствовать.
Да, Intel QSV это медиадвижок-асик. Он и декодирует, и энкодирует аппаратно.
Преимущество за счёт близости к CPU – какая-то шизотеория, едва ли это можно измерить и почувствовать.
>>02940
Давно из 2017? Теперь редивони и в мининге говным-говно с отвалами. Похоже 400 рыксы им не переплюнуть по части всего, простая как топор и эффективная так же как топор, не топ, но дело своё знала.
> а мининг-асики
Давно из 2017? Теперь редивони и в мининге говным-говно с отвалами. Похоже 400 рыксы им не переплюнуть по части всего, простая как топор и эффективная так же как топор, не топ, но дело своё знала.
145 Кб, 720x960А ведь я её одно время долго руал за присущие ей косяки, а оно вон оно как вышло, что это фактически пик подразделения АТИ
/hw/ протёк
Если за два месяца автор сообщения >>3081689 → ещё не покинул нас, то я хочу донести до него ту мысль, что автор сообщения >>3081671 → с первых слов упомянул «говённый кирпич 2014 года», поэтому рекомендовать ему формат AV1 было неостроумно.
>>04393
Что конкретно тебе непонятно? Там же всё элементарно.
Вот выдержка из моей старой шпаргалки по 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
Что конкретно тебе непонятно? Там же всё элементарно.
Вот выдержка из моей старой шпаргалки по 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, подобно тому как ютюб их транскодирует в VP9 и AV1?
Только сегодня заметил и удивился, по большей части потому что браузеры в основном не поддерживают HEVC, насколько я знаю, хром например. Там какой-то особый плеер?
Только сегодня заметил и удивился, по большей части потому что браузеры в основном не поддерживают HEVC, насколько я знаю, хром например. Там какой-то особый плеер?
>>04779
А всё, уже сам разобрался. В хром тикток выдаёт AVC, а HEVC наверно идёт на мобильные приложения, их траффик в приоритете. И yt-dlp в mpv автоматически подхватывает поток в лучшем качестве. Это и по наличию/отсутствию вотермарки можно заметить, выше на скриншоте yt-dlp выдал кучу разных вариаций с различными вариантами перекодировки.
А всё, уже сам разобрался. В хром тикток выдаёт AVC, а HEVC наверно идёт на мобильные приложения, их траффик в приоритете. И yt-dlp в mpv автоматически подхватывает поток в лучшем качестве. Это и по наличию/отсутствию вотермарки можно заметить, выше на скриншоте yt-dlp выдал кучу разных вариаций с различными вариантами перекодировки.
А можно без тонны гайдов просто мне объяснить как сжать видео в ffmpeg чтобы на двач кидать. Его я установил, что дальше делать
Сап аноны. Хочу цензурить видео выключая звук и/или накладывая картинку в определенный момент видео а то и несколько моментов чтоб не кодировать сотню раз. Но я совершенно не знаю как это сделать а нагуглить готовых решений не вышло. Нуждаюсь в аноне что скинет пару команд для решения моей задачки. С меня как обычно
>>04813
Зависит от разрешения, длины видео, и нужного тебе размера.
Зависит от разрешения, длины видео, и нужного тебе размера.
>>05378
А где собсна пердолинг тут? Как по мне проще вставить в сосноль одну команду с определенными таймингами нежели жрать каловые видеоредакторы. Тут сложность только в создании такой команды собсна зачем я здесь
А где собсна пердолинг тут? Как по мне проще вставить в сосноль одну команду с определенными таймингами нежели жрать каловые видеоредакторы. Тут сложность только в создании такой команды собсна зачем я здесь
>>05383
Ну и как ты это представляешь. тем более с равными таймингами и вставками картинок? Тем более с несколькими отрезками. Пердоль питона или батник тогда сам, когда можно просто кинуть видосик, картинку и удалить звукв нужным местах в любом редакторе. Пердолинг ради пердолинга.
>Как по мне проще вставить в сосноль одну команду с определенными таймингами нежели жрать каловые видеоредакторы.
Ну и как ты это представляешь. тем более с равными таймингами и вставками картинок? Тем более с несколькими отрезками. Пердоль питона или батник тогда сам, когда можно просто кинуть видосик, картинку и удалить звукв нужным местах в любом редакторе. Пердолинг ради пердолинга.
>>05387
Да особо равных таймингов не надо я за идеалом не гонюсь просто увеличу время исчезновения звука и вставки картинки. Мне много не надо хочу просто пару команд. Если у тебя есть овер простой бесплатный редактор то кидай я чекну
Да особо равных таймингов не надо я за идеалом не гонюсь просто увеличу время исчезновения звука и вставки картинки. Мне много не надо хочу просто пару команд. Если у тебя есть овер простой бесплатный редактор то кидай я чекну
>>05388
Я премьер с афтерэффектс юзаю вообще, а ффпмег чисто для транскодирования и видеофильтров по быстрому. Легче уж какой-нибудь гуй на ффпмеге найти тогда в визуализацией, чем строку пердолить.
Я премьер с афтерэффектс юзаю вообще, а ффпмег чисто для транскодирования и видеофильтров по быстрому. Легче уж какой-нибудь гуй на ффпмеге найти тогда в визуализацией, чем строку пердолить.
Что делать, если у шебмки не видно длины, т. е. На двачах её длина показана как дохуя цифр, плюс саму шебм можно перематывать на пару секунд вперед, но по времени нет так как браузер пишет что видео длится 0 секунд. Это типа проёб с разметкой?
>>01682 (OP)
Как мне сделать, чтобы запись была не целым файлом, а дробилось на файлы по 30-60 минут? Использую эту команду:
ffmpeg.exe -f dshow -i audio="Line In (High Definition Audio Device)" G:/output.wav
Как мне сделать, чтобы запись была не целым файлом, а дробилось на файлы по 30-60 минут? Использую эту команду:
ffmpeg.exe -f dshow -i audio="Line In (High Definition Audio Device)" G:/output.wav
28 Кб, 583x267Привет.
Может ли скорость записи на диск каким-то образом влиять на работу кодировщика? Проблема такая: когда запись ведется на ссд, все ок. Когда на винт - обс выдает ошибку "кодировщик перегружен".
Средний битрейт видео - 40-50мб, потому что использую NVENC с CQP 25-27, файлы очень жирные. Кристал марк грит винт еще нормально работает, пикрил.
Вопросы еще такой: почему мой пека может записывать качественно только с огромным битрейтом? Потому что на кодирование нужны ресурсы, и вся эффективность кодировки заключается в том, какое будет соотношение размера к качеству?
Может ли скорость записи на диск каким-то образом влиять на работу кодировщика? Проблема такая: когда запись ведется на ссд, все ок. Когда на винт - обс выдает ошибку "кодировщик перегружен".
Средний битрейт видео - 40-50мб, потому что использую NVENC с CQP 25-27, файлы очень жирные. Кристал марк грит винт еще нормально работает, пикрил.
Вопросы еще такой: почему мой пека может записывать качественно только с огромным битрейтом? Потому что на кодирование нужны ресурсы, и вся эффективность кодировки заключается в том, какое будет соотношение размера к качеству?
>>02455
Какой процессор в шлеме? Там зависит от поддержки аппаратного ускорения в чипе. Посмотри через dxva checker что тянет ГПУ. И попробуй через mpv.net с включённым ускорением посмотреть
Какой процессор в шлеме? Там зависит от поддержки аппаратного ускорения в чипе. Посмотри через dxva checker что тянет ГПУ. И попробуй через mpv.net с включённым ускорением посмотреть
>>06139
Это конечно да, но мне важнее вопрос с моими дисками.
Это конечно да, но мне важнее вопрос с моими дисками.
>>06102
Судя по ошибке ты про ОБС студио? Если ты пишешь стрим, то нехватка ввода-вывода может привести к ошибке. Это логично, потому что буферы не бесконечные и рано или поздно переполнятся.
Судя по ошибке ты про ОБС студио? Если ты пишешь стрим, то нехватка ввода-вывода может привести к ошибке. Это логично, потому что буферы не бесконечные и рано или поздно переполнятся.
>>06134
SoC: Qualcomm® Snapdragon™ XR2 Platform. MPV так же плохо воспроизводит, как mpc. Я уже забил. Железо короче не тянет.
SoC: Qualcomm® Snapdragon™ XR2 Platform. MPV так же плохо воспроизводит, как mpc. Я уже забил. Железо короче не тянет.
>>06208
Да
Нет, просто записываю игрушку для монтажа. И это меня как раз удивляет, так как чтение-запись у винта достаточные. Тут нужно сказать, что игра и система на ссд, так что во время процесса записи винт ничем другим не занят вообще, туда только пишется видео.
>>06139
Дополню. Я, наверное, тупой. Да, действительно, CQP хорош для работы с уже готовым видео и его дальнейшим пережатием, но оптимален ли он для записи - вопрос, на который я ответа не нашел.
>Судя по ошибке ты про ОБС студио?
Да
>Если ты пишешь стрим
Нет, просто записываю игрушку для монтажа. И это меня как раз удивляет, так как чтение-запись у винта достаточные. Тут нужно сказать, что игра и система на ссд, так что во время процесса записи винт ничем другим не занят вообще, туда только пишется видео.
>>06139
Дополню. Я, наверное, тупой. Да, действительно, CQP хорош для работы с уже готовым видео и его дальнейшим пережатием, но оптимален ли он для записи - вопрос, на который я ответа не нашел.
>>06102
Ну в общем-то да, срать огромным битрейтом дело не хитрое, а вот достигать аналогичного качества с меньшим выходным размером – это и есть суть сложности сжатия.
> Потому что на кодирование нужны ресурсы, и вся эффективность кодировки заключается в том, какое будет соотношение размера к качеству?
Ну в общем-то да, срать огромным битрейтом дело не хитрое, а вот достигать аналогичного качества с меньшим выходным размером – это и есть суть сложности сжатия.
>>06248
Для последующего монтажа при записи нет смысла нагружать кодировщик сложными методами. Просто выставляй высокий постоянный битрейт, а уже на этапе финального рендера сжимай как хочешь.
Для последующего монтажа при записи нет смысла нагружать кодировщик сложными методами. Просто выставляй высокий постоянный битрейт, а уже на этапе финального рендера сжимай как хочешь.
28 Кб, 988x167>>06295
Я просто опирался на данный гайд, когда начинал записывать: https://www.nvidia.com/en-us/geforce/guides/broadcasting-guide/
Сказали ставь CQP, я поставил без задней мысли. Только там есть хуйня - сказано выставить 15, но на практике ниже 20 разницы не будет никакой, а вот размер файла будет ебический. Короче да, буду пробовать проще, спасибо за совет.
Я просто опирался на данный гайд, когда начинал записывать: https://www.nvidia.com/en-us/geforce/guides/broadcasting-guide/
Сказали ставь CQP, я поставил без задней мысли. Только там есть хуйня - сказано выставить 15, но на практике ниже 20 разницы не будет никакой, а вот размер файла будет ебический. Короче да, буду пробовать проще, спасибо за совет.
>>06320
Этот гайд наверно рассчитан на запись сразу конечного результата. У меня самого в ОБСе настроено несколько профилей для разных ситуаций. Иногда надо записать и сразу отправить, а иногда записать для монтажа с минимумом потерь.
Этот гайд наверно рассчитан на запись сразу конечного результата. У меня самого в ОБСе настроено несколько профилей для разных ситуаций. Иногда надо записать и сразу отправить, а иногда записать для монтажа с минимумом потерь.
>>06102
Ну дык сам посчитай. 50мбит это 410 мегабайт в секунду на диск пишет. Попробуй с пресетами поиграть. может у тебя HQ какой-нибудь стоит. Может в карте дело, ты же не сказал какая. Я писал на своей 1063 в 50мб без лагов, а geforce experince 100проц без лагов пишет, но вес большой.
Ну дык сам посчитай. 50мбит это 410 мегабайт в секунду на диск пишет. Попробуй с пресетами поиграть. может у тебя HQ какой-нибудь стоит. Может в карте дело, ты же не сказал какая. Я писал на своей 1063 в 50мб без лагов, а geforce experince 100проц без лагов пишет, но вес большой.
>>06429
Хотя туплю это всего 6 мегабайт в секунду, что получается
Хотя туплю это всего 6 мегабайт в секунду, что получается
103 Кб, 301x517>>06429
Пресет стоит Quality, CQ 25.
Media Info грит пикрил. Я тут покурил, чего именно CQP, а не CBR. Ну он типа умнее и у него нет ограничений на моментальный битрейт, то есть если сцена сложная, то он будет хуячить по максимуму чтобы было ВМЕНЯЕМОЕ качество, а оно мне и нужно.
Можно конечно попробовать и CBR, конечно. Я примерно всегда одно и то же пишу.
А почему не VBR? Вроде можно получить россыпь пикселей в лицо в переходах от одних сцен к более сложным.
Карта десятой серии, говно, о котором в приличном месте не говорят вслух. В рекламном ролике https://www.youtube.com/watch?v=bpoDanWJ4Cw чел рассказывает, что NVENC на новых картах (я так понял речь про Turing и Amper) = x264 Slow. Да пиздец сладкие сказки, у меня все равно нет возможности это проверить.
Пресет стоит Quality, CQ 25.
Media Info грит пикрил. Я тут покурил, чего именно CQP, а не CBR. Ну он типа умнее и у него нет ограничений на моментальный битрейт, то есть если сцена сложная, то он будет хуячить по максимуму чтобы было ВМЕНЯЕМОЕ качество, а оно мне и нужно.
Можно конечно попробовать и CBR, конечно. Я примерно всегда одно и то же пишу.
А почему не VBR? Вроде можно получить россыпь пикселей в лицо в переходах от одних сцен к более сложным.
Карта десятой серии, говно, о котором в приличном месте не говорят вслух. В рекламном ролике https://www.youtube.com/watch?v=bpoDanWJ4Cw чел рассказывает, что NVENC на новых картах (я так понял речь про Turing и Amper) = x264 Slow. Да пиздец сладкие сказки, у меня все равно нет возможности это проверить.
>>06484
Конечно сказки. Старый h.264 nvenc (до 1000-ой серии nvidia) примерно равен x264 на пресете fast, а новый (от 2000-серии nvidia) – x264 на пресете medium.
> чел рассказывает, что NVENC на новых картах (я так понял речь про Turing и Amper) = x264 Slow
Конечно сказки. Старый h.264 nvenc (до 1000-ой серии nvidia) примерно равен x264 на пресете fast, а новый (от 2000-серии nvidia) – x264 на пресете medium.
>>06596
Ух ты, про встроенный AAC encoder не забыли и улучшают его качество. Надо будет потестить.
Ух ты, про встроенный AAC encoder не забыли и улучшают его качество. Надо будет потестить.
>>06484
Пиздеж. Там до слов как раком до луны еще. Чел выше правильно написал h264 medium максимум. Я вообще через проц пишу, в x264 fast в 12000кбит. Попробую nvenc для теста в cq 24.
Можешь еще streamFX скачать и потестить. Там более тонкие настройки, также есть nvenc h264-h265,prores_aw и даже AV1 через aom.
>чел рассказывает, что NVENC на новых картах (я так понял речь про Turing и Amper) = x264 Slow.
Пиздеж. Там до слов как раком до луны еще. Чел выше правильно написал h264 medium максимум. Я вообще через проц пишу, в x264 fast в 12000кбит. Попробую nvenc для теста в cq 24.
Можешь еще streamFX скачать и потестить. Там более тонкие настройки, также есть nvenc h264-h265,prores_aw и даже AV1 через aom.
>>06596
Не вышел еще что ли? Даже исходники с офф.сайта еще старые.
Не вышел еще что ли? Даже исходники с офф.сайта еще старые.
>>04779
Это скорее всего для продукции аппле сделано
Это скорее всего для продукции аппле сделано
Сук, у меня 7700к у которого встроенная графика может аппаратно кодировать VP9, но это только на люпиксе через VAAPI. Я думал поставить WSL2 и через него попробовать пробросить iGPU чтобы там через VAAPI кодировать но это невозможно. Бля, нахуй этот WSL вообще существует? Его ставить заебёшься, лучше виртуалку с люпиксом поставить и не ебать себе мозги.
>>06765
Этот аппаратный вп9 на инцеловстройке говно по уровню сжатия, хоть и весьма быстро. А нахер тогда вообще нужен вп9, если не для максимального сжатия?
Этот аппаратный вп9 на инцеловстройке говно по уровню сжатия, хоть и весьма быстро. А нахер тогда вообще нужен вп9, если не для максимального сжатия?
>>06774
Я думал он примерно на уровне с libvpx-vp9, но сравнить так и не довелась возможность.
А сейчас уже можно кодировать в libsvtav1
Я думал он примерно на уровне с libvpx-vp9, но сравнить так и не довелась возможность.
А сейчас уже можно кодировать в libsvtav1
>>06804
Ну тут я так понимаю замечание в том, что аппаратно ускоренный vp9 может выглядеть не лучше vp8, что вызывает вопросы к его уместности.
Ну тут я так понимаю замечание в том, что аппаратно ускоренный vp9 может выглядеть не лучше vp8, что вызывает вопросы к его уместности.
>>06774
Даже гугл этим вопросом после его создания задался и за десять лет нормальный энкодер к нему так и не завёз.
> А нахер тогда вообще нужен вп9
Даже гугл этим вопросом после его создания задался и за десять лет нормальный энкодер к нему так и не завёз.
1 Мб, 1125x1393>>3106238 →
Очевидно твои настройки кодирования слабее оригинала.
Пробуй preset veryslow
А может ты вообще через жопу что-то делаешь. Кто тебя знает если ты страницу из гкгла осилить не можешь.
Что mediainfo говорит о твоих исходных файлах?
>Ты нихуя не понял. Есть два видео, разные. Размер первого, допустим, 400 мб, второго - 600. Я прогоняю их через одни и те же параметры. В итоге получаю - первое видео - 150 мб, второе - 610 мб. В первом случае все успешно, во втором - размер файла только увеличился. Вот это непонятно, какого хуя.
Очевидно твои настройки кодирования слабее оригинала.
Пробуй preset veryslow
А может ты вообще через жопу что-то делаешь. Кто тебя знает если ты страницу из гкгла осилить не можешь.
Что mediainfo говорит о твоих исходных файлах?
Котаны, покажите готовую строчку, чтобы видео с ютуба (скачанное уже) перепердолить в шебм. С меня сотни нефти.
>>06959
Можно скачать с Ютуба вебм без конвертации
Можно скачать с Ютуба вебм без конвертации
>>06959
Какова цель перепердоливания?
Какова цель перепердоливания?
>>06959
ffmpeg -i video.mp4 out.webm
ffmpeg -i video.mp4 out.webm
>>02939
Каким же конченым долбоёбом нужно быть, чтобы сравнивать околотоповую видеокарту за $200 до кризиса с затычкой за $200 в разгар кризиса.
Сравнивай ХОТЯ БЫ с 6700 XT, она $450 стоила на старте, долбоёб.
>Тетя Лиза грит НИНУЖНО
Каким же конченым долбоёбом нужно быть, чтобы сравнивать околотоповую видеокарту за $200 до кризиса с затычкой за $200 в разгар кризиса.
Сравнивай ХОТЯ БЫ с 6700 XT, она $450 стоила на старте, долбоёб.
>>06897
Скорее всего, первое видео пару секунд, а второе минут на 5. Поэтому и размер разный, потому что crf юзает.
Скорее всего, первое видео пару секунд, а второе минут на 5. Поэтому и размер разный, потому что crf юзает.
>>07021
Какая разница кризис не кризис, офф цена одна и позиционирование тоже. Такое жидовское говно, которое слабее карты 6 летней давности, показывает отношение и как они хотят срубить бабла отбраковками на гоях.
Говновидия хотя бы высрала ртх 3050, с которой хоть что-то можно делать. Новые игры фуллхд на ультрах 60 фпс, длссы длдсары, для кодирования и работы 8гб, еще и мощнее 6500хт на 110%-120%.
Какая разница кризис не кризис, офф цена одна и позиционирование тоже. Такое жидовское говно, которое слабее карты 6 летней давности, показывает отношение и как они хотят срубить бабла отбраковками на гоях.
Говновидия хотя бы высрала ртх 3050, с которой хоть что-то можно делать. Новые игры фуллхд на ультрах 60 фпс, длссы длдсары, для кодирования и работы 8гб, еще и мощнее 6500хт на 110%-120%.
>>07041
Нет, полно тестов на ютабе с pci3, просто там из-за урезанных линий предсказуемо производительность совсем невыгодная по сравнению с конкурентом, с 1650 насколько помню её сравнивают.
Нет, полно тестов на ютабе с pci3, просто там из-за урезанных линий предсказуемо производительность совсем невыгодная по сравнению с конкурентом, с 1650 насколько помню её сравнивают.
>>07054
Да полно тестов, где с pci 3 у нее падает производительность в 2 раза буквально, достаточно на канал бороды зайти.
Да полно тестов, где с pci 3 у нее падает производительность в 2 раза буквально, достаточно на канал бороды зайти.
2,6 Мб, mp4,576x1024, 0:13
>>01682 (OP)
Это объемный звук? При проигровании этого видео на телефоне, сначала использовалось оба динамика, затем только разговорный, а потом только обычный. Как добиться такого же эффекта?
Это объемный звук? При проигровании этого видео на телефоне, сначала использовалось оба динамика, затем только разговорный, а потом только обычный. Как добиться такого же эффекта?
>>07273
Все резко поняли, что ты имел в виду. Либо по английски пиши, либо штаны одень.
Все резко поняли, что ты имел в виду. Либо по английски пиши, либо штаны одень.
>>07352
И что мне этот анимешный высер даст?
И что мне этот анимешный высер даст?
1,2 Мб, 1440x3200>>07411
Еба что за пиздец, для этого придумали режим CBR который делает ТОЖЕ САМОЕ
Еба что за пиздец, для этого придумали режим CBR который делает ТОЖЕ САМОЕ
>>07483
CRF сжимает гораздо эффективнее CBR в плане субъективного восприятия качества за счёт применения психовизуальной модели. Минусом является то, что предугадать размер выходного файла очень сложно. Можно ограничить максимальный битрейт, но это костыль. Другими словами: CBR не делает то же самое, даже сложно представить откуда ты это взял.
CRF сжимает гораздо эффективнее CBR в плане субъективного восприятия качества за счёт применения психовизуальной модели. Минусом является то, что предугадать размер выходного файла очень сложно. Можно ограничить максимальный битрейт, но это костыль. Другими словами: CBR не делает то же самое, даже сложно представить откуда ты это взял.
>>07483
Нет, вот вообще не тоже самое. Они преследуют взаимно исключающие цели.
CRF это как вы поняли некоторый постоянный уровень качества (это смотря какая психовизуальная модель в encoder. За CRF может скрываться обычный постоянный квантователь (CQ)).
CBR расшифровываеться как Constant Bit Rate, то есть постоянная ширина потока дынных. То есть битрейт фиксируеться на некотором значении и не меняеться ни в зависимости от типа кадра, ни в зависимости от его сжимаемости. Из этого следует что качество видео меняеться самым непредсказуемым образом. Нужно такое либо когда стабильность канала передачи данных важнее качества видео (обычно такое бывает на стримах или видеозвонках при конференциях), либо когда у тебя медленный диск и нужно уложиться в его скорость чтения/записи, что-бы не перегружать буферы, или когда ширина потока данных слишком мала что-бы передать медиа поток в сколько нибуть приемлемом качестве и нужно выжать максимум из размера файла.
Единственное, что более менее похожее на CRF по сути это двухпроходное VBR кодирование. Ты наверняка имел в виду именно это, но в виду своей глупости сказал совершенно другое, из-за чего тебя тут никто не понимает.
Нет, вот вообще не тоже самое. Они преследуют взаимно исключающие цели.
CRF это как вы поняли некоторый постоянный уровень качества (это смотря какая психовизуальная модель в encoder. За CRF может скрываться обычный постоянный квантователь (CQ)).
CBR расшифровываеться как Constant Bit Rate, то есть постоянная ширина потока дынных. То есть битрейт фиксируеться на некотором значении и не меняеться ни в зависимости от типа кадра, ни в зависимости от его сжимаемости. Из этого следует что качество видео меняеться самым непредсказуемым образом. Нужно такое либо когда стабильность канала передачи данных важнее качества видео (обычно такое бывает на стримах или видеозвонках при конференциях), либо когда у тебя медленный диск и нужно уложиться в его скорость чтения/записи, что-бы не перегружать буферы, или когда ширина потока данных слишком мала что-бы передать медиа поток в сколько нибуть приемлемом качестве и нужно выжать максимум из размера файла.
Единственное, что более менее похожее на CRF по сути это двухпроходное VBR кодирование. Ты наверняка имел в виду именно это, но в виду своей глупости сказал совершенно другое, из-за чего тебя тут никто не понимает.
>>07624
Неверно, постоянный уровень качества это CQ
Да да, это. Причём два прохода тоже не имеют смысла, потому что x264 и x265 отлично оптимизированы и выдадут максимально возможное качество при одном проходе, только размер может немного не совпадать. Смысла в программе от этого не прибавляется.
> CRF это как вы поняли некоторый постоянный уровень качества
Неверно, постоянный уровень качества это CQ
> CRF по сути это двухпроходное VBR кодирование
Да да, это. Причём два прохода тоже не имеют смысла, потому что x264 и x265 отлично оптимизированы и выдадут максимально возможное качество при одном проходе, только размер может немного не совпадать. Смысла в программе от этого не прибавляется.
>>07644
CQ это про постоянный квантователь (буквально Constant Quantizer). CRF предполагает повышение квантователя для динамичных сцен, за счёт чего и осуществляеться экономия битрейта.
Говорят что в libvpx за опцией CRF скрываеться CQ. Поэтому я так размыто и описал этот режим. К тому же, не во всех кодеках реализован CRF, у них только CQ.
Речь про WEBM, а следовательно, про libvpx.
> Неверно, постоянный уровень качества это CQ
CQ это про постоянный квантователь (буквально Constant Quantizer). CRF предполагает повышение квантователя для динамичных сцен, за счёт чего и осуществляеться экономия битрейта.
Говорят что в libvpx за опцией CRF скрываеться CQ. Поэтому я так размыто и описал этот режим. К тому же, не во всех кодеках реализован CRF, у них только CQ.
> Причём два прохода тоже не имеют смысла, потому что x264 и x265 отлично оптимизированы
Речь про WEBM, а следовательно, про libvpx.
>>07644
В говноэнкодерах -- безусловно, в энкодерах с психовизуальной моделью нет. Если вывести лог квантователя lib-vpx/9, то он тоже в режиме cq не придерживается указанного кванта, так что какая-то, пусть и херовая, но психовизульная модель там имеется.
Только причём тут вебм, о котором идёт речь, он не умеет ни в h264, ни в h265.
> постоянный уровень качества это CQ
В говноэнкодерах -- безусловно, в энкодерах с психовизуальной моделью нет. Если вывести лог квантователя lib-vpx/9, то он тоже в режиме cq не придерживается указанного кванта, так что какая-то, пусть и херовая, но психовизульная модель там имеется.
> Причём два прохода тоже не имеют смысла, потому что x264 и x265
Только причём тут вебм, о котором идёт речь, он не умеет ни в h264, ни в h265.
>>07658
И понижение в статичных.
> CRF предполагает повышение квантователя для динамичных сцен, за счёт чего и осуществляеться экономия битрейта
И понижение в статичных.
38 Кб, 1092x378>>07658
Вот, кстати, относительно этого, я понимаю, почему у некоторых могут возникать недопонимания, дело в том, что гугл решил, что ну его нахер эти стандартизированные абревиатуры, изобрету свои, и cq в их понимании другое, не то, чтобы это относилось к делу в данном случае, но нужно учитывать, мало какие документации читал чиловек
> CQ это про постоянный квантователь
Вот, кстати, относительно этого, я понимаю, почему у некоторых могут возникать недопонимания, дело в том, что гугл решил, что ну его нахер эти стандартизированные абревиатуры, изобрету свои, и cq в их понимании другое, не то, чтобы это относилось к делу в данном случае, но нужно учитывать, мало какие документации читал чиловек
>>07665
Собственно с 'q' у них таже история, постоянный квантайзер my ass, если qmax и qmin укажешь идентичные(чего в vpenc сделать нельзя, он требует минимум +-4, а вот ffmpeg кушает за обе щёки) то может и будет постоянный.
Собственно с 'q' у них таже история, постоянный квантайзер my ass, если qmax и qmin укажешь идентичные(чего в vpenc сделать нельзя, он требует минимум +-4, а вот ffmpeg кушает за обе щёки) то может и будет постоянный.
>>07483
Нет, лучший метод это для сохранения качества VBR с мануальным вычислением битрейта каждого отдельного видево. CRF настолько знаю просто держит определенную планку качества и ему похуй какой будет размер в итоге.
Вау, пориджи придумали vp9 CQ - constrained quality.
С этого конечно описялся.
>Параллельно с этим в условиях ограниченного размера видеофайла одним из наилучших методов сохранения качества видео признаётся использование параметра сжатия 'Constant Rate Factor'.
Нет, лучший метод это для сохранения качества VBR с мануальным вычислением битрейта каждого отдельного видево. CRF настолько знаю просто держит определенную планку качества и ему похуй какой будет размер в итоге.
>Программа подойдёт пользователям, любящим выжимать максимум из доступного ограничения на размер файла, что в условиях постинга на АИБ вполне оправдано.
Вау, пориджи придумали vp9 CQ - constrained quality.
>В период примерно 2015-16 гг [бум популярности кодирования WebM как технического новшества] показателем мастерства считалось кодирование WebM
С этого конечно описялся.
25 Кб, 877x233>>07675
Или на CBR, но я не разбирался, а вот с режимом 'q' пару лет назад были обсуждения в вебм треде, с учётом, что гугл vp9 забросил, не думаю, что что-то изменилось.
> меняет тамошний Q на VBR режим
Или на CBR, но я не разбирался, а вот с режимом 'q' пару лет назад были обсуждения в вебм треде, с учётом, что гугл vp9 забросил, не думаю, что что-то изменилось.
Аноны, как массово прописывать метадату для мп3? Допустим есть альбом, но без метаданных вообще. Я пишу текстовый файлик с определённой структурой, навроде автора, год выпуска, кол-вол песен и тд, а потом ффмпег эти данные записывает в файлы в текущей директории.
1,2 Мб, 1415x1415Посоветуйте экономно-приемлемый CRF для libx265 и фильмов в дорогу, с мобилы 5.6". Разрешение самих фильмов и экрана 720p, сейчас все в жутком оверсайзе.
Про tune grain знаю, конечно two-pass, главное чтобы пиздеца в кадрах почти не было
Про tune grain знаю, конечно two-pass, главное чтобы пиздеца в кадрах почти не было
123 Кб, 512x452>>08043
Скачать уже готовые хевк 10бит фильмы. сделанные мастерами пердолинга, нужного тебе размера и не ебать себе мозги?
Скачать уже готовые хевк 10бит фильмы. сделанные мастерами пердолинга, нужного тебе размера и не ебать себе мозги?
>>07932
Не ебать себе мозг и скачать mp3tag.
Не ебать себе мозг и скачать 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 обработкой?
Разве файлы не должны получаться идентичными при равных настройках кодирования одним кодеком? Почему так сильно падает качество при гпу обработке и как его можно улучшить?
Я тупенький, поэтому мой вопрос будет соответствующий.
Как известно есть два аппаратных способа конвертации. На 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 обработкой?
Разве файлы не должны получаться идентичными при равных настройках кодирования одним кодеком? Почему так сильно падает качество при гпу обработке и как его можно улучшить?
>>08043
Это не влияет на качество, время впустую
https://handbrake.fr/docs/en/1.3.0/workflow/adjust-quality.html
> конечно two-pass
Это не влияет на качество, время впустую
https://handbrake.fr/docs/en/1.3.0/workflow/adjust-quality.html
>>08095
А если ты кидал ссылку чтобы дать мне значения RF, то спасибо, я воспользуюсь. Выглядит правдоподобно.
А если ты кидал ссылку чтобы дать мне значения RF, то спасибо, я воспользуюсь. Выглядит правдоподобно.
>>08104
Это я говорил про уменьшение реуомендуемых значений с падением разрешения.
А вот то что они советуют одинаковые значения для x264 и x265 - говорит мне о том, что остается 2 возможности:
- гайд писал чел, который не шарит
- Handbrake ввел свой RF и переводит в ffmpeg'овские CRF для x264 и x265, то есть этот RF ничего не значит для меня
> Выглядит правдоподобно.
Это я говорил про уменьшение реуомендуемых значений с падением разрешения.
А вот то что они советуют одинаковые значения для x264 и x265 - говорит мне о том, что остается 2 возможности:
- гайд писал чел, который не шарит
- Handbrake ввел свой RF и переводит в ffmpeg'овские CRF для x264 и x265, то есть этот RF ничего не значит для меня
>>08106
В теории crf должен выдавать одинаковое качество у любого кодека. x264 и x265 довольно схожи и могут принимать одинаковые значения
В теории crf должен выдавать одинаковое качество у любого кодека. x264 и x265 довольно схожи и могут принимать одинаковые значения
>>08110
Нет, не должен. Принимать могут, но уровень сжатия разный.
Нет, не должен. Принимать могут, но уровень сжатия разный.
>>08110
Ренжи одинаковые, как у qp, но проводить какую-то параллель между значениями crf у кодеков разного поколения навряд ли адекватно.
Ренжи одинаковые, как у qp, но проводить какую-то параллель между значениями crf у кодеков разного поколения навряд ли адекватно.
Ладно, интент вопроса был прощупать тред я здесь не сижу на анонов, которые экспериментировали со значениями CRF. Таковых не обнаружено, буду набивать шишки сам.
>>01682 (OP)
Короче это ближайший тред про редактирование видео, поэтому спрашиваю здесь: В видео аудиодорожка при проигрывании ее с динамиков ноута например еле слышна, но она же заебись слышится в наушниках затычках. Как называется эта проблема и каковы пути ее решения? "верха повышать низы занижать"?
Короче это ближайший тред про редактирование видео, поэтому спрашиваю здесь: В видео аудиодорожка при проигрывании ее с динамиков ноута например еле слышна, но она же заебись слышится в наушниках затычках. Как называется эта проблема и каковы пути ее решения? "верха повышать низы занижать"?
>>08089
Нет, на CPU – это программный способ. И вместо конвертации правильнее говорить о кодировании.
В общих чертах да. Хотя и стримить можно на процессоре, если он тянет x264 на пресете slow в реалтайме. И оффлайн рендерить можно на видеокарте, если конечный сервис всё равно ещё раз пережмёт видео на сервере самостоятельно.
VP8 мог бы не откапывать, его труп уже разложился. VP9 – его продолжение.
Ну да, всё так. Хорошо что не радеон, он разочаровал бы в кодировании ещё сильнее, чем нвидия. Причём в рамках самой нвидии важна конкретная модель. От 1650 super до 3090 ti – новый нвенк, в h.264 он примерно равен x264 на пресете medium. Все модели до них имеют старый нвенк, он в h.264 он примерно равен x264 на пресете fast.
Верно. И не всё ещё плохо, а в принципе плохо, потому что это несвободный кодек, требующий паевые отчисления.
Вот тут чушь написал. Проблема на твоей стороне, что-то не так делаешь или криво настроил. Конкретно здесь нормально поддерживается и смотрится онлайн.
Плюс-минус так. Но ты ещё AV1 не пробовал, он по ресурсозатратности лидирует.
VP8 не нужен, это уже архаизм.
Есть в кодировании такая вещь, как баланс качества и скорости. Качественнее – значит медленнее, быстрее – значит шакальнее. Этот баланс ты должен найти исходя из своих приоритетов. Но ты хочешь и то и другое одновременно. И судя по тому, что ты остановился на нетребовательных 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 кодируется разными кодировщиками.
> Почему так сильно падает качество при гпу обработке и как его можно улучшить?
Потому что гпу
Поступила в пту.
Цпу же молодец,
В вузе он отличный спец.
Таково аппаратное ускорение, просто прими это как данность. А чтобы его улучшить, выставляй самые медленные настройки.
>>08089
Нет, на CPU – это программный способ. И вместо конвертации правильнее говорить о кодировании.
В общих чертах да. Хотя и стримить можно на процессоре, если он тянет x264 на пресете slow в реалтайме. И оффлайн рендерить можно на видеокарте, если конечный сервис всё равно ещё раз пережмёт видео на сервере самостоятельно.
VP8 мог бы не откапывать, его труп уже разложился. VP9 – его продолжение.
Ну да, всё так. Хорошо что не радеон, он разочаровал бы в кодировании ещё сильнее, чем нвидия. Причём в рамках самой нвидии важна конкретная модель. От 1650 super до 3090 ti – новый нвенк, в h.264 он примерно равен x264 на пресете medium. Все модели до них имеют старый нвенк, он в h.264 он примерно равен x264 на пресете fast.
Верно. И не всё ещё плохо, а в принципе плохо, потому что это несвободный кодек, требующий паевые отчисления.
Вот тут чушь написал. Проблема на твоей стороне, что-то не так делаешь или криво настроил. Конкретно здесь нормально поддерживается и смотрится онлайн.
Плюс-минус так. Но ты ещё AV1 не пробовал, он по ресурсозатратности лидирует.
VP8 не нужен, это уже архаизм.
Есть в кодировании такая вещь, как баланс качества и скорости. Качественнее – значит медленнее, быстрее – значит шакальнее. Этот баланс ты должен найти исходя из своих приоритетов. Но ты хочешь и то и другое одновременно. И судя по тому, что ты остановился на нетребовательных 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 кодируется разными кодировщиками.
> Почему так сильно падает качество при гпу обработке и как его можно улучшить?
Потому что гпу
Поступила в пту.
Цпу же молодец,
В вузе он отличный спец.
Таково аппаратное ускорение, просто прими это как данность. А чтобы его улучшить, выставляй самые медленные настройки.
>>08089
Вроде как из-за того, что при аппаратном кодировании картинка делится на участки и картинка в этих областях кодируется изолированно. То есть задача распараллеливается и потому быстрее выполняется, но из-за изолированности каждого участка качество выходит хуже. Вроде бы так.
>Почему так сильно падает качество при гпу обработке и как его можно улучшить?
Вроде как из-за того, что при аппаратном кодировании картинка делится на участки и картинка в этих областях кодируется изолированно. То есть задача распараллеливается и потому быстрее выполняется, но из-за изолированности каждого участка качество выходит хуже. Вроде бы так.
>>08123
Спасибо, но заскриптую сам, хотя если на питоне, то кинь
Спасибо, но заскриптую сам, хотя если на питоне, то кинь
>>08207
Звучит логично.
Звучит логично.
>>08100
Да большинство фильмом более менее популярных 100% есть, могут не быть разве что какие-нибудь авторские короткометражки, и по их тоже полно перекодированных уже.
>фильмы олдовые и в таком виде в принципе не существуют?
Да большинство фильмом более менее популярных 100% есть, могут не быть разве что какие-нибудь авторские короткометражки, и по их тоже полно перекодированных уже.
Не обращайте внимания...
подскажите пожалуйста все команды для субтитров, мне нужно будет их местоположение размер и тд и тп
>>08777
менять
менять
59 Кб, 985x632Пчелы, уже изобрели такой простецкий гуй, чтобы как на пике?
603 Кб, 1024x700>>08824
Чет слишком комбайн какой-то, нужен именно для ффмпега гуй с окошком для своих команд
Чет слишком комбайн какой-то, нужен именно для ффмпега гуй с окошком для своих команд
>>08826
Сделай сам.
Сделай сам.
>>01682 (OP)
Как же досадно, что во многих видео перемотка работает плохо! Настроил на одну секунду, а плеер перематывает на 5, 8, 10 или 20. Ютуб, ВК, bdrip с торрентов - там можно это увидеть. Если перематывать точным способом, то это ахуеть можно с задержек (зависит от видео - где-то они почти незаметные, а где-то долгие). Как быть тогда? Не всегда есть возможность скачать в лучшем качестве (в более тяжёлых раздачах такой проблемы с перемотками нет). Плеер mpv.
Как же досадно, что во многих видео перемотка работает плохо! Настроил на одну секунду, а плеер перематывает на 5, 8, 10 или 20. Ютуб, ВК, bdrip с торрентов - там можно это увидеть. Если перематывать точным способом, то это ахуеть можно с задержек (зависит от видео - где-то они почти незаметные, а где-то долгие). Как быть тогда? Не всегда есть возможность скачать в лучшем качестве (в более тяжёлых раздачах такой проблемы с перемотками нет). Плеер mpv.
Кто врубал аппаратный кодинг HEVC в ffmpeg на Win/Lin?
Какой кодек выставлять?
Указывайте Win это или Lin
Какой кодек выставлять?
Указывайте Win это или Lin
>>08855
Блять, забыл сказать самое важное - на GPU AMD все это будет
Блять, забыл сказать самое важное - на GPU AMD все это будет
как в LosslessCut добавить эффект размытия на задний фон для вертикального видео ?
>>08835
Впиши в конфиг и попробуй
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
> Плеер 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
>>08814
Boram. Но он не поддерживается c 2019 и я помню у меня были проблемы с переносом команды оттуда в актуальный ffmpeg. Но конкретно кроп, возоможно, работает как надо.
Boram. Но он не поддерживается c 2019 и я помню у меня были проблемы с переносом команды оттуда в актуальный ffmpeg. Но конкретно кроп, возоможно, работает как надо.
>>08928
x264 fast
x264 fast
>>08921
Серьезно? Я всегда знал, что аппаратное кодирование шакалит, но ожидал 0..5% потери качества за размер.
Или это у Амуде так все хуево как обычно?
Серьезно? Я всегда знал, что аппаратное кодирование шакалит, но ожидал 0..5% потери качества за размер.
Или это у Амуде так все хуево как обычно?
>>08927
Ему и искал альтернативу
Ему и искал альтернативу
>>08814
https://sourceforge.net/projects/ffmpeg-batch/
даже больше.
Переконвертировал игровые звуковые файлы новеллы с этой штукой примерно 32к файлов.
А предпросмотри я видел только в вебмретардс.
https://sourceforge.net/projects/ffmpeg-batch/
даже больше.
Переконвертировал игровые звуковые файлы новеллы с этой штукой примерно 32к файлов.
А предпросмотри я видел только в вебмретардс.
>>09076
Ну еще и как говорил анон avidemux. Также юзаю на постоянке Hybrid от selur, но там именно для avisynth/vapoursynth предпросмотр, но он итак работает.
Ну еще и как говорил анон avidemux. Также юзаю на постоянке Hybrid от selur, но там именно для avisynth/vapoursynth предпросмотр, но он итак работает.
16 Кб, 201x251>>09076
Этой тоже пользуюсь. Походу нет того, чего хотел, да и пох.
Тогда еще вопрос, есть такая команда, чтобы во время энкодинга рядом с командной строкой в реалтайме отображалась выходная картинка, т.е. последний обработанный кадр?
Этой тоже пользуюсь. Походу нет того, чего хотел, да и пох.
Тогда еще вопрос, есть такая команда, чтобы во время энкодинга рядом с командной строкой в реалтайме отображалась выходная картинка, т.е. последний обработанный кадр?
>>08960
Ну да, амд похуже. Ну не прям сильно
Ну да, амд похуже. Ну не прям сильно
>>08920
Возможно перемотка стала чуть быстрее, но всё-равно долго. Бывает, что несколько перемоток подряд всё довольно быстро, а потом опять с большой задержкой.
В одном видео именно так. В другом всё ок и без этого конфига.
Сука, ну плеер же знает время. Если поставить на плей а потом поставить на паузу, тогда он может дойти до любого времени, и покажет с точностью до миллисекунд. А чтобы перемотать - тут уже ждать надо. Грустно, очень грустно.
Возможно перемотка стала чуть быстрее, но всё-равно долго. Бывает, что несколько перемоток подряд всё довольно быстро, а потом опять с большой задержкой.
В одном видео именно так. В другом всё ок и без этого конфига.
Сука, ну плеер же знает время. Если поставить на плей а потом поставить на паузу, тогда он может дойти до любого времени, и покажет с точностью до миллисекунд. А чтобы перемотать - тут уже ждать надо. Грустно, очень грустно.
>>09168
Не, хотелось бы при каждом кодировании наблюдать результат
Не, хотелось бы при каждом кодировании наблюдать результат
Тут давно какой-то анон сжимал фильмы до 20мб. Как он это делал? Vp9 же не умеет кодировать в указанный размер, как мпеги. Может есть какие-нибудь фокусы с шебм?
>>09184
Битрейт рассчитывай. Допустим фильм 1 час = 3600 с, 4 мб, например, оставляем для звука, для видео есть 16 мб = 16384 кб = 131072 кбит
131072/3600 = 36 кбит/с
Для таких пожатий лучше av1
Битрейт рассчитывай. Допустим фильм 1 час = 3600 с, 4 мб, например, оставляем для звука, для видео есть 16 мб = 16384 кб = 131072 кбит
131072/3600 = 36 кбит/с
Для таких пожатий лучше av1
>>08820
Что-то вроде этого, только у меня собственный скрипт, который кодирует сегмент указанный в AB-loop:
https://github.com/occivink/mpv-scripts/blob/master/scripts/encode.lua
В том же репе есть crop.lua, сначала кропаешь видео в mpv, потом жмешь хоткей для encode.lua, последний учитывает текущие параметры кропа.
Что-то вроде этого, только у меня собственный скрипт, который кодирует сегмент указанный в AB-loop:
https://github.com/occivink/mpv-scripts/blob/master/scripts/encode.lua
В том же репе есть crop.lua, сначала кропаешь видео в mpv, потом жмешь хоткей для encode.lua, последний учитывает текущие параметры кропа.
>>09179
Потому что при воспроизведении плеер декодирует все кадры, а при перемотке проходится лишь по ключевым.
Потому что при воспроизведении плеер декодирует все кадры, а при перемотке проходится лишь по ключевым.
>>09184
Сделай себе калькулятор битрейта в экселе, всё просто.
Сделай себе калькулятор битрейта в экселе, всё просто.
>>09188
Лол, классика. Будто мой заскринил.
Лол, классика. Будто мой заскринил.
Анон, объясни в чём разница ffmpeg и avisynth. Это аналоги или это вообще разные инструменты?
>>09229
Ну так раскрой подробнее. Я читаю и не понимаю. Бывает такое. Объясни на пальцах. С ffmpeg я занимался, представление о нём имею.
Ну так раскрой подробнее. Я читаю и не понимаю. Бывает такое. Объясни на пальцах. С ffmpeg я занимался, представление о нём имею.
>>09228
Разные. Но их задачи и функции пересекаются. Они в чём-то похожи. Но avisynth не кодирует и не декодирует, а ffmpeg плохо приспособлен для нелинейного монтажа.
Разные. Но их задачи и функции пересекаются. Они в чём-то похожи. Но avisynth не кодирует и не декодирует, а ffmpeg плохо приспособлен для нелинейного монтажа.
>>09219
Формула на скриншоте
Формула на скриншоте
>>09305
Тогда перекодируй, Москва не сразу строилась. Не пердолик что ли? А если разница с 20 МБ небольшая, то можно отдельно перекодировать только аудиопоток, чтобы уложиться в лимит либо повысить качество звука на оставшиеся килобайты.
Тогда перекодируй, Москва не сразу строилась. Не пердолик что ли? А если разница с 20 МБ небольшая, то можно отдельно перекодировать только аудиопоток, чтобы уложиться в лимит либо повысить качество звука на оставшиеся килобайты.
подскажите пожалуйста, файл с сабами срт нужно чтобы одни сабы были в нижней части видео изначально, а затем сабы бы появлялись в верхней части видео, как сделать такое?
>>09492
Через любой редактор субтитров можно подвинуть
Через любой редактор субтитров можно подвинуть
>>10101
А отрицательное?
А отрицательное?
Сверху была дискуссия насчёт влияния многопоточности на качество сжатия.
Сейчас проверил, libvpx VP9 при прочих равных сжалось примерно на 5% хуже на 4 потоках, чем на 1.
Сейчас проверил, libvpx VP9 при прочих равных сжалось примерно на 5% хуже на 4 потоках, чем на 1.
>>10564
Этот кривой кодек будет сжимать хуже если увеличить размер tiles
Этот кривой кодек будет сжимать хуже если увеличить размер tiles
>>11909
Ага. Когда абу обновит ффмпег никогда, да и вп9 вроде такое же качество даёт, тогда будут миниатюры.
Ага. Когда абу обновит ффмпег никогда, да и вп9 вроде такое же качество даёт, тогда будут миниатюры.
>>12041
За одинаковое время кодирования и одинаковый битрейт ав1 будет выглядеть лучше но это не точно
За одинаковое время кодирования и одинаковый битрейт ав1 будет выглядеть лучше но это не точно
ffmpeg -f concat -safe 0 -i mylist.txt -c copy output.wav
Это единственная команда для склеивания однородных файлов?
А то есть программа, которая ффмпегом соединяет, я попробовал сам соединить, вроде все нормально, но итоговые файлы совсем чуть-чуть различаются. Может лучше как-то иначе делать?
Это единственная команда для склеивания однородных файлов?
А то есть программа, которая ффмпегом соединяет, я попробовал сам соединить, вроде все нормально, но итоговые файлы совсем чуть-чуть различаются. Может лучше как-то иначе делать?
>>14663
Да, остальные криво работают
Да, остальные криво работают
Как нормально вырезать без конвертации? Я пробовал
ffmpeg -i hetero.mp4 -ss 00:39:08.685 -to 00:48:12.509 -c:v copy -c:a copy gay.mp4
Но если со звуком норм, то видео проебывает секунд по 20.
ffmpeg -i hetero.mp4 -ss 00:39:08.685 -to 00:48:12.509 -c:v copy -c:a copy gay.mp4
Но если со звуком норм, то видео проебывает секунд по 20.
>>14781
Точно по миллисекундам – никак, начало должно быть на ключевом кадре. Не ебись с ffmpeg, нарезать без перекодирования проще в avidemux.
Точно по миллисекундам – никак, начало должно быть на ключевом кадре. Не ебись с ffmpeg, нарезать без перекодирования проще в avidemux.
Что не так с xhe aac? Вроде уже кодеку 4 года, а энкодеров всего две штуки, его даже в ффмпег нет
>>15680
Куча патентов, нет свободных реализаций, требуют деньги за использование. И это когда есть полностью свободный opus который совсем чуть-чуть хуже
Куча патентов, нет свободных реализаций, требуют деньги за использование. И это когда есть полностью свободный opus который совсем чуть-чуть хуже
Сап.
Внезапно у новых вебм'ок перестало появляться превью. Команда простейшая -вход -выход. Здесь, как видите, превью у них есть. В чём проблема?
Вроде как проблема появилась после установки программы для достройки промежуточных кадров. Её уже удалил.
Внезапно у новых вебм'ок перестало появляться превью. Команда простейшая -вход -выход. Здесь, как видите, превью у них есть. В чём проблема?
Вроде как проблема появилась после установки программы для достройки промежуточных кадров. Её уже удалил.
>>16310
Запишу твою проблему в список доводов против установочного софта и запуска разной параши от имени администратора. Спасибо.
>после установки
Запишу твою проблему в список доводов против установочного софта и запуска разной параши от имени администратора. Спасибо.
>>16654
Запишись лучше сразу в дурку, там обязательно помогут, после курса галоперидола.
Запишись лучше сразу в дурку, там обязательно помогут, после курса галоперидола.
>>16704
icaros shell extensions
icaros shell extensions
>>16941
Ну, на некоторых затычках у nvenc есть режим без потерь, которого пока больше нет ни у синих, ни у красных. Если бы невидия работала без выебонов, то это был бы ого-го какой аргумент для меня.
Ну, на некоторых затычках у nvenc есть режим без потерь, которого пока больше нет ни у синих, ни у красных. Если бы невидия работала без выебонов, то это был бы ого-го какой аргумент для меня.
>>17046
На каких затычках и что за лосслесс? Вот тут поподробнее.
> на некоторых затычках у nvenc есть режим без потерь
На каких затычках и что за лосслесс? Вот тут поподробнее.
>>17058
Обычный без потерь. Как crf 0 у x264. Причём тут crf вообще
Обычный без потерь. Как crf 0 у x264. Причём тут crf вообще
>>17058
Преимущественно не на дешёвых.
Подробности тут https://en.m.wikipedia.org/wiki/Nvidia_NVENC#Versions
Полгода назад обсуждали в этой ветке. Тогда ценник на 264-ку без потерь начинался от 20 тыс. руб., а на 265-ку от 30 тыс. руб. Сейчас дороже.
>На каких затычках и что за лосслесс?
Преимущественно не на дешёвых.
Подробности тут https://en.m.wikipedia.org/wiki/Nvidia_NVENC#Versions
Полгода назад обсуждали в этой ветке. Тогда ценник на 264-ку без потерь начинался от 20 тыс. руб., а на 265-ку от 30 тыс. руб. Сейчас дороже.
8 Кб, 260x146>>01682 (OP)
Сап, аноны. Нужна помощь. Делал в проге boram webm'ку, поставил кодек AV1. При его использовании видео рендерится, но потом когда постишь на 2ch — то не видно превью, пикрил. Что делать? При юзании кодека VP9 всё ок, но хуже качество.
Сап, аноны. Нужна помощь. Делал в проге boram webm'ку, поставил кодек AV1. При его использовании видео рендерится, но потом когда постишь на 2ch — то не видно превью, пикрил. Что делать? При юзании кодека VP9 всё ок, но хуже качество.
>>17321
Уебан Абу уже сколько лет не может прикрутить к своей конченной хуйне поддержку этого супер годного кодека
Уебан Абу уже сколько лет не может прикрутить к своей конченной хуйне поддержку этого супер годного кодека
>>13304
Чушь.
Чушь.
>>19184
Можно сохранять из премьера в нормальные кодеки
Можно сохранять из премьера в нормальные кодеки
снова выхожу на связь, как побороть эффект небольшого контура вокруг объекта находящегося на статичном фоне, например головы на фоне неба?
>>19291
Поиграйся с dehalo, если это то, о чём я думаю
Поиграйся с dehalo, если это то, о чём я думаю
>>19291
Ну и dering до кучи глянь
Ну и dering до кучи глянь
как убрать ошибку rc buffer underflow?
3 Кб, 487x89Вот пишут, что кодекпаки плохо, из-за них проблемы и всё такое. В вегасе и премьере я сталкивался с проблемами, похожими на неправильные кодеки, но это не точно. Сейчас вот переустановил систему, решил ставить из k-lite кодеки по мере необходимости, но вот возникла необходимость и я не понимаю, а что ставить-то, блять? Как мне не поставить взаимоисключающего?
Что за source filters?
LAV или мелкософт?
Или не нужно ебать себе мозги, актуальный максимальный к-лайт конфликтной хуйни не ставит? Или есть мануалы?
не знаю куда писать, наверное, надо идти на профильные форумы видеоредакторов
Что за source filters?
LAV или мелкософт?
Или не нужно ебать себе мозги, актуальный максимальный к-лайт конфликтной хуйни не ставит? Или есть мануалы?
не знаю куда писать, наверное, надо идти на профильные форумы видеоредакторов
>>19677
Да ничего не надо ставить. Все эти кодеки были актуальны лет 15 назад. Сейчас система и программы давно изменились, они даже не берут их оттуда, а тащат свои.
Да ничего не надо ставить. Все эти кодеки были актуальны лет 15 назад. Сейчас система и программы давно изменились, они даже не берут их оттуда, а тащат свои.
Что не так с vvc? Он же вроде год как зарелизился, но всё ещё нет нормальных энкодеров
aom хуита
aom хуита
>>20270
Потому что с ним работают бесплатные опенсорс ffmpeg и mpv.
Потому что с ним работают бесплатные опенсорс ffmpeg и mpv.
>>20270
Из-за того, что он всегда был стандартом для Blu-ray видео.
Из-за того, что он всегда был стандартом для Blu-ray видео.
>>20268
А почему тогда всем похуй на evc?
А почему тогда всем похуй на evc?
>>20584
MPC-HC не тянет за собой vfw-кодеки, их нужно отдельно устанавливать. MPC-HC тянет за собой LAV Filters, а это не vfw-кодеки.
vfw-кодеки пикрил выглядят.
x264vfw, x265vfw, av1vfw, lagarith, etc. Именно такие и используют программы для видеоредактирования, чтобы энкодить. Ну это конечно же, ffmpeg можно решить всё, если программа вменяемая и имеет функцию подгрузки внешних энкодеров.
> Причём современный mpc тянет свои кодеки за собой, ничего устанавливать не надо
MPC-HC не тянет за собой vfw-кодеки, их нужно отдельно устанавливать. MPC-HC тянет за собой LAV Filters, а это не vfw-кодеки.
vfw-кодеки пикрил выглядят.
x264vfw, x265vfw, av1vfw, lagarith, etc. Именно такие и используют программы для видеоредактирования, чтобы энкодить. Ну это конечно же, ffmpeg можно решить всё, если программа вменяемая и имеет функцию подгрузки внешних энкодеров.
Аноны, может кто знает как скачать часть видео из vk с помощью 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.
Второй день экспериментирую. Ничего не получается.
Например для 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.
Второй день экспериментирую. Ничего не получается.
>>23202
Вместо 2 дней экспериментов мог бы уже сделать это в 2 строки отдельно в yt-dl и ffmpeg, пердоля.
Вместо 2 дней экспериментов мог бы уже сделать это в 2 строки отдельно в yt-dl и ffmpeg, пердоля.
>>23202
Ебать ты поехавший, щяс бы два дня потратить на этот ебанутый способ. Неудивительно что у тебя линукс стоит, но странно что убунту, он старается быть на нормальных людей.
Ради тебя встал и скопировал команду
yt-dlp --downloader ffmpeg --downloader-args "ffmpeg_i:-ss 1:29:32 -to 1:30:42"
Ебать ты поехавший, щяс бы два дня потратить на этот ебанутый способ. Неудивительно что у тебя линукс стоит, но странно что убунту, он старается быть на нормальных людей.
Ради тебя встал и скопировал команду
yt-dlp --downloader ffmpeg --downloader-args "ffmpeg_i:-ss 1:29:32 -to 1:30:42"
Не реально, что не так с aom? Почему качество при vbr хуже чем на x265?
Возможно, мне с этим не совсем в ваш тред, но...
Есть старая игра 20-летней давности. Есть несвежий пека средней паршивости. Игра на нём идет отлично, 200+ фпс в 1920x1080.
Хочу записать видео прохождения некоторых её кусков в 1920x1080 @ 60 fps или мб даже 3840x2160 @ 60, если мне дадут погонять 4K-монитор (игра поддерживает такое разрешение). Летсплеером и стримером становиться не планирую, видеоряд нужен для других целей, акция одноразовая (запишу часов 5 игрового процесса и успокоюсь).
Фрапс тянет запись 1920x1080 @ 30 fps, но при фпс выше (где-то от ~40) упирается в производительность жесткого диска.
OBS со своим дефолтным (?) сжатием диск особо не насилует, но тут уже реалтаймовое сжатие видео не вывозит процессор.
Места на жёстком диске дофига.
Какие есть решения, которые бы сжимали несильно, чтобы успевало в реалтайме, но при этом не в ущерб визуальному качеству видео, а в ущерб объему? Десятки и сотни гигов получившегося видео - не вопрос, после записи пережму нормально.
Есть старая игра 20-летней давности. Есть несвежий пека средней паршивости. Игра на нём идет отлично, 200+ фпс в 1920x1080.
Хочу записать видео прохождения некоторых её кусков в 1920x1080 @ 60 fps или мб даже 3840x2160 @ 60, если мне дадут погонять 4K-монитор (игра поддерживает такое разрешение). Летсплеером и стримером становиться не планирую, видеоряд нужен для других целей, акция одноразовая (запишу часов 5 игрового процесса и успокоюсь).
Фрапс тянет запись 1920x1080 @ 30 fps, но при фпс выше (где-то от ~40) упирается в производительность жесткого диска.
OBS со своим дефолтным (?) сжатием диск особо не насилует, но тут уже реалтаймовое сжатие видео не вывозит процессор.
Места на жёстком диске дофига.
Какие есть решения, которые бы сжимали несильно, чтобы успевало в реалтайме, но при этом не в ущерб визуальному качеству видео, а в ущерб объему? Десятки и сотни гигов получившегося видео - не вопрос, после записи пережму нормально.
>>24100
Lagarith.
Lagarith.
>>23311
Ну и в чем он ебанутый?
По-моему, как раз удобно в одну строчку скачать отрывок + сжать его.
Лол. Щас бы сидя на дваче рассуждать про нормальных людей.
В любом случае, спасибо за помощь. Получилось типа такого:
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
Ну и в чем он ебанутый?
По-моему, как раз удобно в одну строчку скачать отрывок + сжать его.
>Неудивительно что у тебя линукс стоит, но странно что убунту, он старается быть на нормальных людей.
Лол. Щас бы сидя на дваче рассуждать про нормальных людей.
В любом случае, спасибо за помощь. Получилось типа такого:
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
67x33Только заметил, что появились новые покемоны
>>24121
По умолчанию стоит 20, так что его можно и оставить.
>>24121
>CQP 23
По умолчанию стоит 20, так что его можно и оставить.
>>24116
Зачем ты перегоняешь в vp9, если настройки по умолчанию в фф невероятно ужасные, когда на Ютубе и так можно скачать этот кодек??? ПИЗДЕЦ
Зачем ты перегоняешь в vp9, если настройки по умолчанию в фф невероятно ужасные, когда на Ютубе и так можно скачать этот кодек??? ПИЗДЕЦ
>>24121
Не надо использовать cqp, ставь cbr где-то 50000 КБ, и вообще лучше через Nvidia experience
Не надо использовать cqp, ставь cbr где-то 50000 КБ, и вообще лучше через Nvidia experience
>>24140
В клоуна решил поиграть?
В клоуна решил поиграть?
>>24140
CQP тем и хорош, что сам рассчитает, как пользователю будет заебись исходя из сцены.
Не забудь зарегистрироваться где-нибудь, чтобы блядь еще воздухом подышать. Ни разу на дваче не видел сравнения в лоб нвенка от обс и нвенка от хуйвидии, а никому это не упало потому что и разницу не увидишь, потому что ее и нет. Обс замечательный инструмент и точка, никуда дергаться не нужно.
CQP тем и хорош, что сам рассчитает, как пользователю будет заебись исходя из сцены.
>Expirience
Не забудь зарегистрироваться где-нибудь, чтобы блядь еще воздухом подышать. Ни разу на дваче не видел сравнения в лоб нвенка от обс и нвенка от хуйвидии, а никому это не упало потому что и разницу не увидишь, потому что ее и нет. Обс замечательный инструмент и точка, никуда дергаться не нужно.
>>24229
Нихуя cqp не рассчитывает, это crf рассчитывает который нвидиа не поддерживает
Ебать дебил. У экспиренса намного меньше накладные расходы за счёт того что он не строит 3д сцену и использует специальные интерфейсы, без копирования картинки. Обс не нужен для простой записи игры.
> CQP тем и хорош, что сам рассчитает, как пользователю будет заебись исходя из сцены.
Нихуя cqp не рассчитывает, это crf рассчитывает который нвидиа не поддерживает
> Ни разу на дваче не видел сравнения в лоб нвенка от обс и нвенка от хуйвидии, а никому это не упало потому что и разницу не увидишь, потому что ее и нет
Ебать дебил. У экспиренса намного меньше накладные расходы за счёт того что он не строит 3д сцену и использует специальные интерфейсы, без копирования картинки. Обс не нужен для простой записи игры.
>>24100
Кстати ты можешь записать его и без 4к монитора, через DSR
> Хочу записать видео прохождения некоторых её кусков в 1920x1080 @ 60 fps или мб даже 3840x2160 @ 60, если мне дадут погонять 4K-монитор
Кстати ты можешь записать его и без 4к монитора, через DSR
>>24229
NVFBC называется. Разница есть, и более чем заметная
NVFBC называется. Разница есть, и более чем заметная
>>24255
У них одинаковое предназначение - целевое качество выходного видео, об устройстве каждого я не знаю, мне и не нужно. Если процессор не тянет запись, то просто пишешь на карте, только и всего
>Нихуя cqp не рассчитывает, это crf рассчитывает который нвидиа не поддерживает
У них одинаковое предназначение - целевое качество выходного видео, об устройстве каждого я не знаю, мне и не нужно. Если процессор не тянет запись, то просто пишешь на карте, только и всего
>>24267
Нет, ни одинаковое. Cqp работает по другому и делает хуже картинку чем у crf.
Нет, ни одинаковое. Cqp работает по другому и делает хуже картинку чем у crf.
>>24374
Ладно, выстави тогда нормальные настройки, например обязательно quality good и mt-row 1, и пресет тройку где-то. Могу скинуть конкретно
Ладно, выстави тогда нормальные настройки, например обязательно quality good и mt-row 1, и пресет тройку где-то. Могу скинуть конкретно
119 Кб, 1043x363>>24379
скинь, плиз.
У меня тут другая проблема - в самом начале низкий битрейт. Может как раз в настройках дело.
скинь, плиз.
У меня тут другая проблема - в самом начале низкий битрейт. Может как раз в настройках дело.
>>24400
Так и должно быть в начале с битрейтом. Установи windows terminal
И я вспомнил, vp9 так вообще нельзя конвертировать. Обязательно нужно два прохода, если один качество будет намного хуже! Так что скачивай видео и только после этого его конвертируй
https://0bin.net/paste/BWVblfKe#AscsdMVvgVqEEldRPxSrEXZvDrmV7eiBQm5QKHTaoyA
Так и должно быть в начале с битрейтом. Установи windows terminal
И я вспомнил, vp9 так вообще нельзя конвертировать. Обязательно нужно два прохода, если один качество будет намного хуже! Так что скачивай видео и только после этого его конвертируй
https://0bin.net/paste/BWVblfKe#AscsdMVvgVqEEldRPxSrEXZvDrmV7eiBQm5QKHTaoyA
>>24592
понял. Ну значит так и придется поступить.
Спасибо за настройки, анон.
Да я практически все время на линухе. Если буду на винде, то поставлю.
понял. Ну значит так и придется поступить.
Спасибо за настройки, анон.
>Так и должно быть в начале с битрейтом. Установи windows terminal
Да я практически все время на линухе. Если буду на винде, то поставлю.
>>24255
Почему обс не может просто взять и делать то же самое?
>кспиренса намного меньше накладные расходы за счёт того что он не строит 3д сцену и использует специальные интерфейсы
Почему обс не может просто взять и делать то же самое?
>>24640
Для этого придётся выпилить из обс все эти сцены и разными источниками. Да и наверное можно это добавить, но никто этим не занялся, нужно заплатить денег за работу
Для этого придётся выпилить из обс все эти сцены и разными источниками. Да и наверное можно это добавить, но никто этим не занялся, нужно заплатить денег за работу
>>24982
мимо обнял
мимо обнял
Поясните за NVFBC по человечески пж. Что такое есть преимущества? Почитав в инете не поняв.
482 Кб, 1015x1274>>25092
Свинья перешла на визг, а я на ор!
Свинья перешла на визг, а я на ор!
>>19181
На фамилию обрати внимание, либо поляк, который трясётся за свою жопу, либо пидорнутый из Беларуси змагар.
На фамилию обрати внимание, либо поляк, который трясётся за свою жопу, либо пидорнутый из Беларуси змагар.
>>25098
Это не много, но с этого можно начать дальнейший поиск: https://www.reddit.com/r/nvidia/comments/5mes9h/shadowplay_nvenc_nvfbc_nvifr_what_do_they_mean/
Это не много, но с этого можно начать дальнейший поиск: https://www.reddit.com/r/nvidia/comments/5mes9h/shadowplay_nvenc_nvfbc_nvifr_what_do_they_mean/
>>25169
Ну теперь стало понятней. Видел какие-то патчи для дров нвиде есть, якобы чтобы nvFBC можно было использовать на обычных потребильских картах.
nvFBC где-то можно юзать вообще? Либо эта шняга чисто для линуха из-за их кастрированной ОС.
https://github.com/keylase/nvidia-patch/tree/master/win
Ну теперь стало понятней. Видел какие-то патчи для дров нвиде есть, якобы чтобы nvFBC можно было использовать на обычных потребильских картах.
nvFBC где-то можно юзать вообще? Либо эта шняга чисто для линуха из-за их кастрированной ОС.
https://github.com/keylase/nvidia-patch/tree/master/win
SVT-AV1 уже стал выдавать лучше качество чем старый x265 medium при такой же скорости?
>>01682 (OP)
1. Эта херня есть на андроиде?
2. Есть ли у неё гуй?
3. Можно ли с её помошью вырезать кусок с ютубного видео, не скачивая его?
1. Эта херня есть на андроиде?
2. Есть ли у неё гуй?
3. Можно ли с её помошью вырезать кусок с ютубного видео, не скачивая его?
>>25829
Напиздели тебе. Можно спокойно себе на андроиде собрать, либо через termux установить.
На андроид есть FFmpeg Media Encoder, он же как и гуи с пресетами, так и строка обычная есть.
Кусок не скачивая только, если через termux наверное. Команда выше есть.
yt-dlp --downloader ffmpeg --downloader-args "ffmpeg_i:-ss 1:29:32 -to 1:30:42"
Напиздели тебе. Можно спокойно себе на андроиде собрать, либо через termux установить.
На андроид есть FFmpeg Media Encoder, он же как и гуи с пресетами, так и строка обычная есть.
Кусок не скачивая только, если через termux наверное. Команда выше есть.
yt-dlp --downloader ffmpeg --downloader-args "ffmpeg_i:-ss 1:29:32 -to 1:30:42"
96 Кб, 900x350А можно ли как-то вручную задавать изменение битрейта для разных временных отрезков одного видеофайла? Например, для важного, кульминационного момента задать повышенный битрейт, а для остальной части видео – пониженный.
Переменный битрейт и прочие умные методы – не то, потому что дело не в динамике, а в субъективной важности определённых моментов.
В голову приходит только отдельное кодирование нескольких фрагментов с последующим склеиванием, но это топорный костыль, к тому же на склейках будет резкое изменение качества, а снижение и повышение хотелось бы делать плавным и незаметным.
Переменный битрейт и прочие умные методы – не то, потому что дело не в динамике, а в субъективной важности определённых моментов.
В голову приходит только отдельное кодирование нескольких фрагментов с последующим склеиванием, но это топорный костыль, к тому же на склейках будет резкое изменение качества, а снижение и повышение хотелось бы делать плавным и незаметным.
>>25829
1ffmpeg media encoder, охуенно работает, он же сразу с гуем
2shutter encoder боат жив, всем советую
3качай в newpipe или yt dlp и режь уже скачанное, иначе никак, либо будет рваная хуета. Ютуб это очень хитрый видеохостинг, а не радикал.
1ffmpeg media encoder, охуенно работает, он же сразу с гуем
2shutter encoder боат жив, всем советую
3качай в newpipe или yt dlp и режь уже скачанное, иначе никак, либо будет рваная хуета. Ютуб это очень хитрый видеохостинг, а не радикал.
Хотел сделать музыкальную вебмку.
Мне посоветовали ffmpeg, но я что-то ничего не понимаю.
До это с кодированием был никак не связан.
Посоветуйте гайд чтобы просто сделать музыкальную вебмку.
Ну или если просто не получится, то хотя-бы основы чтобы начать понимать суть.
Мне посоветовали ffmpeg, но я что-то ничего не понимаю.
До это с кодированием был никак не связан.
Посоветуйте гайд чтобы просто сделать музыкальную вебмку.
Ну или если просто не получится, то хотя-бы основы чтобы начать понимать суть.
>>26356
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
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
>>26362
Где -quality good? По умолчанию стоит хуйня из-за которой кодирует намного медленнее
Где -quality good? По умолчанию стоит хуйня из-за которой кодирует намного медленнее
5 Кб, 644x108ffmpeg -f gdigrab -framerate 30 -i desktop output.mp4
Захват экрана через gdigrab плохо работает. Какой-то дикий пропуск кадров. Как фиксить?
Захват экрана через gdigrab плохо работает. Какой-то дикий пропуск кадров. Как фиксить?
591 Кб, 1600x2133>>26401
Ну если по умолчанию для libx264 -preset medium, то попробуй fast, faster, veryfast, superfast, ultrafast. А вообще ffmpeg gpu-ускорением не обделён, попробуй h264_nvenc / h264_amf / h264_qsv.
Ну если по умолчанию для libx264 -preset medium, то попробуй fast, faster, veryfast, superfast, ultrafast. А вообще ffmpeg gpu-ускорением не обделён, попробуй h264_nvenc / h264_amf / h264_qsv.
>>26386
Да, я не дочитал, извини.
Да, я не дочитал, извини.
>>26402
На ультрафаст получше, но все равно пропускает кадры. На hd3600 можно ускориться? Не нашел команду.
На ультрафаст получше, но все равно пропускает кадры. На hd3600 можно ускориться? Не нашел команду.
>>26444
Она должно быть не умеет энкодировать. Твоя некропека особо не годится для записи, придётся смириться с пропуском кадров. Попробуй снизить fps до 15-10-5..
Она должно быть не умеет энкодировать. Твоя некропека особо не годится для записи, придётся смириться с пропуском кадров. Попробуй снизить fps до 15-10-5..
>>26462
А, ну тогда буду читать.
А, ну тогда буду читать.
>>26356
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"
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"
49 Кб, 604x450>>26500
А мы будем
А мы будем
>>26500
У тебя айпад пердежных лет? Тем более, в софтварном режиме любое видео должно воспроизводится. Кто виноват, что в сафариговно не добавили-то.
>>26501
Потому что в ffmpeg баг, который после окончания музыки с шортест все равно добавляет пустой звук на 30-60 секунл дополнительно. Так что надо в ручную указывать.
У тебя айпад пердежных лет? Тем более, в софтварном режиме любое видео должно воспроизводится. Кто виноват, что в сафариговно не добавили-то.
>>26501
Потому что в ffmpeg баг, который после окончания музыки с шортест все равно добавляет пустой звук на 30-60 секунл дополнительно. Так что надо в ручную указывать.
>>26517
Литералли вывод самого нового 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
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%
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 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%
>А у меня не багуется, и что ты мне сделаешь?
Разве что залупой по лбу дать.
>>26526
В командную строку куда еще. Как установить ffmpeg и прописать в переменные среды винды, полно гайдов на ютабах.
В командную строку куда еще. Как установить ffmpeg и прописать в переменные среды винды, полно гайдов на ютабах.
>>26531
Понял тебя.
Понял тебя.
>>26525
А, я сейчас проверил старую шебму, а там действительно тишина на 20 секунд, а я даже не замечал.
Тебя там отец на ошибки наказывал? Соболезную.
А, я сейчас проверил старую шебму, а там действительно тишина на 20 секунд, а я даже не замечал.
> Разве что залупой по лбу дать.
Тебя там отец на ошибки наказывал? Соболезную.
>>26492
Почему gop только на 6 минут?
Почему gop только на 6 минут?
объясни ффмпач, я делаю превью для вебмк по гайду питуза, когда создал док.txt вставил в него пути на шебемку и превью к ниму, ффмпег ругается что не может открыть этот ткст файл, я подозреваю что дело в синтаксе, какие то там ебаные блэксэши или ковычи не туда поставил, поясни в чем дело, windows 10
>>27141
И команда которую ты пишешь?
И команда которую ты пишешь?
>>27141
То есть вместо приведения полной команды ты предлагаешь нам искать гайд какого-то пидаруза?
Ты даун, для начала.
То есть вместо приведения полной команды ты предлагаешь нам искать гайд какого-то пидаруза?
> поясни в чем дело
Ты даун, для начала.
Есть такой же конвертер,как ффмпег,но для конвертации doc в pdf и прочих форматов текстовых и околотекстовых документов?
И конвертирует ли ффмпег картинки?
И конвертирует ли ффмпег картинки?
Почему мой старый 4 ядерный комп кодирует всего где-то в два раза медленнее более современного 6 ядерного 12 поточного монстра? Разве нету разницы раза в 3, 4? Проверял на i5-6500 и i5-12400, у обоих 8 Гб одноканал, у второго разогнан 3200. Нагрузка на проц 100%, кодек x265
>>27737
Всё дело в инструкциях, а не в ядрах.
Всё дело в инструкциях, а не в ядрах.
>>27737
Да, современные камни уже довольно давно растут в производительности не экспоненциально. Каждое следующее поколение добавляет по 10...20% 5...10% производительности на ядро. И прирост год от года снижается.
Да, современные камни уже довольно давно растут в производительности не экспоненциально. Каждое следующее поколение добавляет по 10...20% 5...10% производительности на ядро. И прирост год от года снижается.
>>01682 (OP)
Сап, кодировальщики, прям не знаю, где ещё спросить.
Wondershare Uniconverter не хочет конвертить на видяхе - тупо не даёт включить опцию "ускорение gpu", трабла видна на первом скрине. Видяха ноутбучная, подключена, как я понимаю через встройку проца (стандартно для ноутбука).
Не спрашивайте, почему мокрописька, сам не в восторге. Обычно юзаю нормальный софт вроде того же ffmpeg
Сап, кодировальщики, прям не знаю, где ещё спросить.
Wondershare Uniconverter не хочет конвертить на видяхе - тупо не даёт включить опцию "ускорение gpu", трабла видна на первом скрине. Видяха ноутбучная, подключена, как я понимаю через встройку проца (стандартно для ноутбука).
Не спрашивайте, почему мокрописька, сам не в восторге. Обычно юзаю нормальный софт вроде того же ffmpeg
>>01682 (OP)
Добрый день, аноны. Я решил создать пару вебмок для порно-тредов и заодно понять как эта перекодировка работает. В интернете нашёл гайд, где советуют использовать данные две команды по очереди:
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"
Результат мне понравился, однако у меня теряется звук при кодировке. С чем это может быть связано?
Добрый день, аноны. Я решил создать пару вебмок для порно-тредов и заодно понять как эта перекодировка работает. В интернете нашёл гайд, где советуют использовать данные две команды по очереди:
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"
Результат мне понравился, однако у меня теряется звук при кодировке. С чем это может быть связано?
>>29835
Команда полное говно потому что
https://0bin.net/paste/BWVblfKe#AscsdMVvgVqEEldRPxSrEXZvDrmV7eiBQm5QKHTaoyA
Команда полное говно потому что
https://0bin.net/paste/BWVblfKe#AscsdMVvgVqEEldRPxSrEXZvDrmV7eiBQm5QKHTaoyA
>>29844
Спасибо, что указал и на подробную тему с Reddit. Было бы приятно и здесь указать анонам, что не так
Спасибо, что указал и на подробную тему с Reddit. Было бы приятно и здесь указать анонам, что не так
>>30713
хз. Фотки какие-нибудь обычные jpeg, еще есть jpeg-xl, webp, avif, но ты с ними быстро не сможешь поделится.
Видео x265/hevc 10bit, или vp9. Хотя тут смотря что ты подразумеваешь под хранением.
хз. Фотки какие-нибудь обычные jpeg, еще есть jpeg-xl, webp, avif, но ты с ними быстро не сможешь поделится.
Видео x265/hevc 10bit, или vp9. Хотя тут смотря что ты подразумеваешь под хранением.
>>30713
Jpeg xl лучший для картинок, без конкурентов
Для видео libaom лучший, но сжимает в десятки раз дольше, непрактично, лучше SVT-AV1 или x265 10 bit slow
Jpeg xl лучший для картинок, без конкурентов
Для видео libaom лучший, но сжимает в десятки раз дольше, непрактично, лучше SVT-AV1 или x265 10 bit slow
Сделал справку по всем ходовым кодекам с дополнительной полезной инфой, оценивайте и говорите что можно дополнить
https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md
https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md
>>31113
Или крестик сними, или трусы надень. Как-то глупо ставить медленный пресет, изначально портя качество аппаратным декодированием, чтобы выиграть совсем немного времени. В мануале 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/
>>31113
Или крестик сними, или трусы надень. Как-то глупо ставить медленный пресет, изначально портя качество аппаратным декодированием, чтобы выиграть совсем немного времени. В мануале 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/
>>31148
Что-то я проверил на большом 4к фильме и оно даже медленнее так кодирует, иногда хеши сходятся, а иногда нет.. Уберу эту опцию тогда
Что-то я проверил на большом 4к фильме и оно даже медленнее так кодирует, иногда хеши сходятся, а иногда нет.. Уберу эту опцию тогда
>>31148
Не понял, расшифруй мысль, он гайдит по кодированию, ты приносишь информацию о просёре полимеров аппаратными декодерами. Что ты питаешься донести?
Не понял, расшифруй мысль, он гайдит по кодированию, ты приносишь информацию о просёре полимеров аппаратными декодерами. Что ты питаешься донести?
>>31148
Ой бля, ты кодирование с декодированием путаешь, выдержка из мануала mpv здесь ни при чём, там о вреде аппаратного декодирования, а не кодирования. Аппаратное кодирование ничего страшного за собой не несёт.
> Как-то глупо ставить медленный пресет, изначально портя качество аппаратным декодированием
Ой бля, ты кодирование с декодированием путаешь, выдержка из мануала mpv здесь ни при чём, там о вреде аппаратного декодирования, а не кодирования. Аппаратное кодирование ничего страшного за собой не несёт.
>>31188
Чтобы закодировать, самому кодировщику нужно неожиданно прочитать исходник, то есть декодировать его. -hwaccel auto даёт команду делать это аппаратно, а вред аппаратного декодирования расписан в мануале mpv.
>>31230
Не путаю.
Знаю.
Толсто.
Чтобы закодировать, самому кодировщику нужно неожиданно прочитать исходник, то есть декодировать его. -hwaccel auto даёт команду делать это аппаратно, а вред аппаратного декодирования расписан в мануале mpv.
>>31230
> ты кодирование с декодированием путаешь
Не путаю.
> там о вреде аппаратного декодирования, а не кодирования
Знаю.
> Аппаратное кодирование ничего страшного за собой не несёт
Толсто.
>>31300
Теперь понял, я изначальной команды не видел, потому и удивился, что анон пишет
и я допереть не мог к чему это
> Чтобы закодировать, самому кодировщику нужно неожиданно прочитать исходник, то есть декодировать его
Теперь понял, я изначальной команды не видел, потому и удивился, что анон пишет
>hwaccel
>preset slow
и я допереть не мог к чему это
17 Кб, 593x268>>31113
Не нужен. Делается в экселе за минуту.
> https://web.archive.org/web/20210401103230/http://www.3ivx.com/support/calculator/index.html
Не нужен. Делается в экселе за минуту.
>>31324
Дааа охуенно придумал, каждый раз ждать пока запускается эксель вместо удобной страницы которая открывается секунду, в которой ничего лишнего
Дааа охуенно придумал, каждый раз ждать пока запускается эксель вместо удобной страницы которая открывается секунду, в которой ничего лишнего
>>31421
Хром всегда запущен, страницу открыть в нём займет менее секунды, а огромный эксель на любом компьютере запускается десяток секунд
Хром всегда запущен, страницу открыть в нём займет менее секунды, а огромный эксель на любом компьютере запускается десяток секунд
>>31445
Зря ты накатил офис 2021 на свою корудуба. У эксель открывается за секунду.
Зря ты накатил офис 2021 на свою корудуба. У эксель открывается за секунду.
>>31148
Давайте теперь смотреть видео без аппаратного декодирования, если качество старадает прям пиздец. По факту разницы не будет
Давайте теперь смотреть видео без аппаратного декодирования, если качество старадает прям пиздец. По факту разницы не будет
>>31459
Сейчас бы беспруфный высер мпвшизов выслушивать, который на каждый пиксель с лупой дрочат. Объективного сравнения не было. Я вообще с nvdec cuda декодирую за секунды и похуй.
Сейчас бы беспруфный высер мпвшизов выслушивать, который на каждый пиксель с лупой дрочат. Объективного сравнения не было. Я вообще с nvdec cuda декодирую за секунды и похуй.
>>31460
У тебя в башке, разве что. А ffmpeg это часть mpv, шизло, поэтому, всё, что там есть и к ffmpeg относится.
> беспруфный высер
У тебя в башке, разве что. А ffmpeg это часть mpv, шизло, поэтому, всё, что там есть и к ffmpeg относится.
>>31465
Очевидный пук в ответ от мпвдибила. Это не я опровергаю тем более, а ты начал челу выше доказывать бепруфным кукареком от мпвшизов, что нинужно. Не учитывая, что актуальная там инфа или нет вообще и когда писалась.
Очевидный пук в ответ от мпвдибила. Это не я опровергаю тем более, а ты начал челу выше доказывать бепруфным кукареком от мпвшизов, что нинужно. Не учитывая, что актуальная там инфа или нет вообще и когда писалась.
>>31470
Конечно не нужно, нужно аппаратно декодировать на камне, а не на чипе видяхи, за камнями зашкваров не наблюдалось.
> Это не я опровергаю тем более, а ты начал челу выше доказывать бепруфным кукареком от мпвшизов, что нинужно.
Конечно не нужно, нужно аппаратно декодировать на камне, а не на чипе видяхи, за камнями зашкваров не наблюдалось.
>>31473
На интеловской встройке что ли? Ты оговорился или я чего-то недопонял?
> нужно аппаратно декодировать на камне
На интеловской встройке что ли? Ты оговорился или я чего-то недопонял?
>>31492
На процессоре.
На процессоре.
47 Кб, 380x250>>31113
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
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
>>31496
потому что они говно. Зачем мне юзать вп9 и не юзать при этом максимальные параметры сжатия. Даже mp4 veryslow будет лучше чем спид 4.
потому что они говно. Зачем мне юзать вп9 и не юзать при этом максимальные параметры сжатия. Даже mp4 veryslow будет лучше чем спид 4.
>>01682 (OP)
У уого такое было, что
ffmpeg -i input.mkv -vf reverse output.mkv
вызывает огромную утечку памяти?
Четырехминутное видео с ютуба, размером в 3мб. Озу 12 гб.
У уого такое было, что
ffmpeg -i input.mkv -vf reverse output.mkv
вызывает огромную утечку памяти?
Четырехминутное видео с ютуба, размером в 3мб. Озу 12 гб.
>>31576
Это не совсем можно назвать мемори ликом, потому что оно использует памать согласно документации в нужных целях. Не знаю, почему эта операция требует столько, но это нормально
Это не совсем можно назвать мемори ликом, потому что оно использует памать согласно документации в нужных целях. Не знаю, почему эта операция требует столько, но это нормально
Имеется n видеороликов, проименнованных в по порядку. Хочу склеить их в один и так,чтобы каждый повторялся дважды. Как это сделать?
>>31623
Склеивать можно по списку в тхт файле. Сам файл сгенерировать питоном, но ты, вероятно, не умеешь. Попробуй экселем, он же сечёт закономерности в росте чисел. А потом скопируешь в тхт.
Склеивать можно по списку в тхт файле. Сам файл сгенерировать питоном, но ты, вероятно, не умеешь. Попробуй экселем, он же сечёт закономерности в росте чисел. А потом скопируешь в тхт.
Кто-нибудь пробовал биндить ffmpeg с помощью media suite build, чтобы добавить поддержку jpegxl. Я пробовал, но он не появился, сейчас специально в ffmpeg_options.txt добавил --enable-jxl и даже патч скачал. Не знаю сработает ли.
>>31635
Любым текстовым редактором с поддержкой регулярок выйдет
s#(^.*$)#\1\n\1#
Экселем тем более.
> Хотя интересно, выйдет ли экселем.
Любым текстовым редактором с поддержкой регулярок выйдет
s#(^.*$)#\1\n\1#
Экселем тем более.
>>31607
Всего 12 гб. После переполнения ффмпег крашнулся. Собстенно, проблема скорее не в утечке, а в том, что от нее ффмпег крашится.
Всего 12 гб. После переполнения ффмпег крашнулся. Собстенно, проблема скорее не в утечке, а в том, что от нее ффмпег крашится.
>>31646
БАМП
БАМП
Не знаю где написать.
Есть один файл.
В формате wav, 1.4 секунды.
Который отказывается воспроизводится на телефоне в качестве сигнала уведомления или так.
На ПК он воспроизводится без проблем, но ни один анализатор спектра ничего не показывает.
Конвертация в ogg, acc, opus, mp3, flac в ffmpeg c изменением частоты дискретизации не помогает.
Добавление секунды тишины в конец, изменение темпа, компрессия, перезапись с помощью плеера и wat u hear в Audacity тоже ничего не меняет.
На ПК воспроизводится, на телефоне нет. Анализаторы спектра молчат.
Что за чёрная магия?
Что ещё можно попробовать?
Есть один файл.
В формате wav, 1.4 секунды.
Который отказывается воспроизводится на телефоне в качестве сигнала уведомления или так.
На ПК он воспроизводится без проблем, но ни один анализатор спектра ничего не показывает.
Конвертация в ogg, acc, opus, mp3, flac в ffmpeg c изменением частоты дискретизации не помогает.
Добавление секунды тишины в конец, изменение темпа, компрессия, перезапись с помощью плеера и wat u hear в Audacity тоже ничего не меняет.
На ПК воспроизводится, на телефоне нет. Анализаторы спектра молчат.
Что за чёрная магия?
Что ещё можно попробовать?
>>31966
Что о нём пишет mediainfo?
wav - это всё же не формат, а контейнер, как и avi, и внутри может быть что угодно.
Что о нём пишет mediainfo?
wav - это всё же не формат, а контейнер, как и avi, и внутри может быть что угодно.
>>31662
Я имел в виду не формулой, а просто растянуть, чтобы он сам угадал закономерность.
Я имел в виду не формулой, а просто растянуть, чтобы он сам угадал закономерность.
>>31967
Сам файл вот.
https://anonfiles.com/F0H8JeRbx4/RadioMessage_wav
В нём битый счётчик сэмплов и как следствие неправильно показывается его продолжительность, но это-то исправляется при конвертации в другой формат.
Вот он открыт в редакторе, никаких проблем. Но анализ спектра покажет пустое место.
Что такого там может быть, что не уходит при преобразованиях?
При этом у меня несколько телефонов, и на одном из них (sony) всё работает. А на других нет.
Сам файл вот.
https://anonfiles.com/F0H8JeRbx4/RadioMessage_wav
В нём битый счётчик сэмплов и как следствие неправильно показывается его продолжительность, но это-то исправляется при конвертации в другой формат.
Вот он открыт в редакторе, никаких проблем. Но анализ спектра покажет пустое место.
Что такого там может быть, что не уходит при преобразованиях?
При этом у меня несколько телефонов, и на одном из них (sony) всё работает. А на других нет.
>>32019
Хм, хуй его знает. Сейчас тоже чего только ни делал с этим в вейвлабе, питч туда-сюда, эквалайзер - похеру. Не хватает познаний, видимо.
Хм, хуй его знает. Сейчас тоже чего только ни делал с этим в вейвлабе, питч туда-сюда, эквалайзер - похеру. Не хватает познаний, видимо.
>>32408
Или лучше ffmpeg -i 1.aiff -c:a alac track.m4a
Или лучше ffmpeg -i 1.aiff -c:a alac track.m4a
При конкатенации портится звук у части склееных видео. В чем проблема?
Конкатенирую стандартной командой с вики несколько вебемок в одну длинную
Конкатенирую стандартной командой с вики несколько вебемок в одну длинную
>>32707
Использовал [code]ffmpeg -f concat -safe 0 -i fileList.txt -c copy mergedVideo.webm[/code]
Сначала видео было с нормальным звуком,потом, начиная одной вебемки ,звук испортился. Попробовал переставить эту вебемку в начало и склеил заново. В результате у этой вебемки звук нормальный,но во всем остальном видео звук испортился. Не понимаю в чем причина. Может нужно привести все вебемки к одному аудио кодеку ,но как это сделать?
Использовал [code]ffmpeg -f concat -safe 0 -i fileList.txt -c copy mergedVideo.webm[/code]
Сначала видео было с нормальным звуком,потом, начиная одной вебемки ,звук испортился. Попробовал переставить эту вебемку в начало и склеил заново. В результате у этой вебемки звук нормальный,но во всем остальном видео звук испортился. Не понимаю в чем причина. Может нужно привести все вебемки к одному аудио кодеку ,но как это сделать?
>>32791
Так нельзя соединять разные кодеки вообще чел
Решение одно сконвертировать их, но потеряется качество
Так нельзя соединять разные кодеки вообще чел
Решение одно сконвертировать их, но потеряется качество
122 Кб, 382x365>>32019
Вроде норм файл. Только в заголовке присутствовала непонятная секция, нетипичная, не знаю такую. Удалил ее, короче в гекс-редакторе. Ну и тишину в начале вырезал, аж 17 семплов. И еще до кучи добавил вариант отнормированный по громкости, то есть громкость усилена до предела. Фикшенные файлы внутре картинки, в zip-архиве. Распакуй чем нибудь.
Вроде норм файл. Только в заголовке присутствовала непонятная секция, нетипичная, не знаю такую. Удалил ее, короче в гекс-редакторе. Ну и тишину в начале вырезал, аж 17 семплов. И еще до кучи добавил вариант отнормированный по громкости, то есть громкость усилена до предела. Фикшенные файлы внутре картинки, в zip-архиве. Распакуй чем нибудь.
>>32019
Почитал про эту секцию. Она добавляется только к сжатым форматам, а у тебя нормальный PCM, то есть она не нужна. В этой секции указывается количество семплов. У тебя указан 1 семпл. То есть, проигрыватели, редакторы, конвертеры, которые читают эту секцию, думают что в файле 1 семпл. Такие дела...
Почитал про эту секцию. Она добавляется только к сжатым форматам, а у тебя нормальный PCM, то есть она не нужна. В этой секции указывается количество семплов. У тебя указан 1 семпл. То есть, проигрыватели, редакторы, конвертеры, которые читают эту секцию, думают что в файле 1 семпл. Такие дела...
>>32890
Так как сконвертировать-то? Сами они в вебем,получается нужно перекодировать звук,как сделать это?
Так как сконвертировать-то? Сами они в вебем,получается нужно перекодировать звук,как сделать это?
>>32958
Как можно применить это к большому количеству файлов, в стиле того, как это делается при конкатенации, через txt файл?
Как можно применить это к большому количеству файлов, в стиле того, как это делается при конкатенации, через txt файл?
>>32967
Насколько много файлов? Если не слишком, то для начала следует отобрать для перекодирования только те, у которых звук в vorbis.
Насколько много файлов? Если не слишком, то для начала следует отобрать для перекодирования только те, у которых звук в vorbis.
>>32959
Блять я знаю что это, там неработающие способны написаны
Блять я знаю что это, там неработающие способны написаны
>>32976
10-30 в зависимости от папки. Я не знаю, какие кодеки в каждом видео. Думаю, что можно было бы просто перекодировать звук под один кодек, например opus , одновременно склеивая. Есть ли такая команда? Я нуб просто, много чего не знаю.
10-30 в зависимости от папки. Я не знаю, какие кодеки в каждом видео. Думаю, что можно было бы просто перекодировать звук под один кодек, например opus , одновременно склеивая. Есть ли такая команда? Я нуб просто, много чего не знаю.
>>33036
Да можно, просто напиши -c:a opus -b:a 160k вместе когда ты склеиваешь, но он пережмёт вообще все видео
Да можно, просто напиши -c:a opus -b:a 160k вместе когда ты склеиваешь, но он пережмёт вообще все видео
>>33040
В какое место этой команды
вставлять
или, как еще предложили
В какое место этой команды
>ffmpeg -f concat -safe 0 -i fileList.txt -c copy mergedVideo.webm
вставлять
> -c:a opus -b:a 160k
или, как еще предложили
>-c:v copy -c:a libopus
>>33051
> >ffmpeg -f concat -safe 0 -i fileList.txt -c:v copy -c:a libopus -b:a 160k mergedVideo.webm
11 Кб, 121x74>>32948
Да легко. Макаба отрезает архивы если их клеить в конец картинко-файла. Но есть способы запихнуть архив внутрь файла. Например в jpg есть секция для комментария - можно пихануть в нее, но там размер секции указывается в два байта, то есть архивы больше 65533 байта не влезут. Но есть еще png-картинки, в них размер секции пишется в 4 байта, значит можно пихануть большие архивы. У пнг тоже есть секции под комментарий - вот, пихаю туда. Для этого напейсал всякие приблуды, которые автоматом все делают. Зацени.
Да легко. Макаба отрезает архивы если их клеить в конец картинко-файла. Но есть способы запихнуть архив внутрь файла. Например в jpg есть секция для комментария - можно пихануть в нее, но там размер секции указывается в два байта, то есть архивы больше 65533 байта не влезут. Но есть еще png-картинки, в них размер секции пишется в 4 байта, значит можно пихануть большие архивы. У пнг тоже есть секции под комментарий - вот, пихаю туда. Для этого напейсал всякие приблуды, которые автоматом все делают. Зацени.
>>33105
Можно открыть в 7z-опвском файовом менеджере. Можно добавить расширение rar, 7z, zip и открыть/распаковать как обычно. Ну а я открываю в total commander-е напичканом плагинами.
Можно открыть в 7z-опвском файовом менеджере. Можно добавить расширение rar, 7z, zip и открыть/распаковать как обычно. Ну а я открываю в total commander-е напичканом плагинами.
>>33121
Не. Если добавить расширение .rar, то 7z не открывает, и не распаковывает. С расширениями .7z и .zip норм открывает, даже если там rar. Щас попробовал.
Не. Если добавить расширение .rar, то 7z не открывает, и не распаковывает. С расширениями .7z и .zip норм открывает, даже если там rar. Щас попробовал.
>>33055
Я обнаружил через ffprobe, что у всех файлов звук через vorbis,каких-то отличий не нашел,кроме битрейта,различие в котором не мешает соединению других файлов. Может ли влиять наличие метаданных?
Вот вывод того,который склеивается
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)
А вот того,который приклеивается с порченным звуком
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
В чем разница? Метаданные влияют?
>>33055
Я обнаружил через ffprobe, что у всех файлов звук через vorbis,каких-то отличий не нашел,кроме битрейта,различие в котором не мешает соединению других файлов. Может ли влиять наличие метаданных?
Вот вывод того,который склеивается
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)
А вот того,который приклеивается с порченным звуком
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
В чем разница? Метаданные влияют?
>>33219
Возможно и правда влияют. Начал склеивать в другой папке,там такая же ситуация. Если у видоса портится звук,значит у него отличаются метаданные. Как это исправить?
Возможно и правда влияют. Начал склеивать в другой папке,там такая же ситуация. Если у видоса портится звук,значит у него отличаются метаданные. Как это исправить?
18 Кб, 386x330>>33059
А если пикрил отключить, то отрезает?
> Да легко. Макаба отрезает архивы если их клеить в конец картинко-файла.
А если пикрил отключить, то отрезает?
>>33311
Может в энкодерах разница? Сколько не смотрю на метаданные из поста, не понятно в чем беда
Может в энкодерах разница? Сколько не смотрю на метаданные из поста, не понятно в чем беда
>>34485
Только что скачанные - не обрезанные. Но со временем макаба вроде оптимизирует картинки и все лишнее отрезает. Позже надо проверить.
Только что скачанные - не обрезанные. Но со временем макаба вроде оптимизирует картинки и все лишнее отрезает. Позже надо проверить.
>>32896
>>32927
Ничего не изменилось.
Как было пусто в анализаторах спектра, так и на телефоне не воспроизводится.
Откройте в foobar2000 визуализацию (например спектрограмма) при воспроизведении — будет пусто, хотя файл воспроизводится будет.
Единственный положительный эффект, который я наблюдал — это то что при конвертации в AAC или vorbis появляется слабый хрип на грани слышимости, какая-то часть частот просачивается и на спектр и при воспроизведении.
>>32927
> попробуй так https://dropmefiles.com/aDY8v
> Фикшенные файлы внутре картинки, в zip-архиве.
Ничего не изменилось.
Как было пусто в анализаторах спектра, так и на телефоне не воспроизводится.
Откройте в foobar2000 визуализацию (например спектрограмма) при воспроизведении — будет пусто, хотя файл воспроизводится будет.
Единственный положительный эффект, который я наблюдал — это то что при конвертации в AAC или vorbis появляется слабый хрип на грани слышимости, какая-то часть частот просачивается и на спектр и при воспроизведении.
>>32939
При конвертировании в mp3 например все проблемы должны уходить, но не уходит.
При записи в редакторе с "what u hear" тем более, но тоже не уходят.
Как не понимал что за фигня, так и не понимаю.
Я бы списал всё это на какую-то неотключаемую DSP обработку в телефоне, которая почему-то агрессивно режет именно этот узкий диапазон частот, что имеется в файле, но почему визуализации в плеерах на ПК тоже молчат?
При конвертировании в mp3 например все проблемы должны уходить, но не уходит.
При записи в редакторе с "what u hear" тем более, но тоже не уходят.
Как не понимал что за фигня, так и не понимаю.
Я бы списал всё это на какую-то неотключаемую DSP обработку в телефоне, которая почему-то агрессивно режет именно этот узкий диапазон частот, что имеется в файле, но почему визуализации в плеерах на ПК тоже молчат?
109 Кб, 972x559>>34514
Нормально все.
>Откройте в foobar2000 визуализацию (например спектрограмма) при воспроизведении — будет пусто, хотя файл воспроизводится будет.
Нормально все.
>>31966
>>34528
В общем вся проблема была в том что в файле ложное стерео, в котором дорожки в противофазе.
При сложении дороже в противофазе в моно получается тишина.
Телефон при воспроизведении тоже складывает в моно. А божественная сони воспроизводит стерео, ай да сони.
Вырезал дорожку псевдостерео в audicity, пересохранил и всё заработало.
Потрясающе.
>>34528
В общем вся проблема была в том что в файле ложное стерео, в котором дорожки в противофазе.
При сложении дороже в противофазе в моно получается тишина.
Телефон при воспроизведении тоже складывает в моно. А божественная сони воспроизводит стерео, ай да сони.
Вырезал дорожку псевдостерео в audicity, пересохранил и всё заработало.
Потрясающе.
71 Кб, 935x604>>34561
О как. Точно. Если сложить каналы в один, то тишина получается - в файле одни нолики.
О как. Точно. Если сложить каналы в один, то тишина получается - в файле одни нолики.
77 Кб, 935x419>>34839
Не понял, почему нужно качать с джандев, если есть BtBN.
По сабжу пикрил, вот тебе конкретика. Сиди изучай, че где есть, чего где нет.
Не понял, почему нужно качать с джандев, если есть BtBN.
По сабжу пикрил, вот тебе конкретика. Сиди изучай, че где есть, чего где нет.
5 Кб, 793x57>>34945
Со слов самого Джана разница в каких-то внешних библиотеках. Я по приколу про BtBN написал.
Со слов самого Джана разница в каких-то внешних библиотеках. Я по приколу про BtBN написал.
>>34951
ААС вроде бы и так есть.
Ты про это? https://en.wikipedia.org/wiki/Fraunhofer_FDK_AAC
Ой короче, качаю от gyan и похуй. Еще хотел спросить, есть ли какая-то мизерная разница скорости в использовании shared и static версий?
ААС вроде бы и так есть.
Ты про это? https://en.wikipedia.org/wiki/Fraunhofer_FDK_AAC
Ой короче, качаю от gyan и похуй. Еще хотел спросить, есть ли какая-то мизерная разница скорости в использовании shared и static версий?
>>34955
Не, разницы нет.
Не, разницы нет.
>>34961
Непонятно по какой причине и зачем он так странно отмечает билды, если это априори git. Latest и pre-release, типо у git версий тоже есть stable и unstable ветки? ну что за лол, только путаницы больше.
Непонятно по какой причине и зачем он так странно отмечает билды, если это априори git. Latest и pre-release, типо у git версий тоже есть stable и unstable ветки? ну что за лол, только путаницы больше.
>>35828
В соседнем поиске программ треде анон говорил, что final cut божественен и вообще лучше, что случалось с видеоредакторами.
Вот у меня вопрос, какой видеоредактор является таким же божественным в винде
В соседнем поиске программ треде анон говорил, что final cut божественен и вообще лучше, что случалось с видеоредакторами.
Вот у меня вопрос, какой видеоредактор является таким же божественным в винде
>>35830
Как раз на винде ничего подобного нет. Я сам ради этого ставил хакинтош. И вообще это я писал.
Как раз на винде ничего подобного нет. Я сам ради этого ставил хакинтош. И вообще это я писал.
203 Кб, 1288x747>>12041
По адресу https://old.reddit.com/r/AV1/comments/r1sv22/av1_the_opus_of_video_codecs_discuss/ приводится график Intel, согласно которому при равном качестве видео кодировщик libsvtav1 (он же SVT-AV1) работает быстрѣе libvpx (то есть быстрѣе кодировщика VP9) НА ПОРЯДОК.
(График прилагаю.)
Другое дѣло, что нам от него не скорость работы нужна, как правило. Так что разумно заставлять libsvtav1 работать гораздо медленнѣе, но выдавать гораздо большѣе качество видео, недосягаемое для VP9 при том же битрейте.
> Медленнее чем AV1?
По адресу https://old.reddit.com/r/AV1/comments/r1sv22/av1_the_opus_of_video_codecs_discuss/ приводится график Intel, согласно которому при равном качестве видео кодировщик libsvtav1 (он же SVT-AV1) работает быстрѣе libvpx (то есть быстрѣе кодировщика VP9) НА ПОРЯДОК.
(График прилагаю.)
Другое дѣло, что нам от него не скорость работы нужна, как правило. Так что разумно заставлять libsvtav1 работать гораздо медленнѣе, но выдавать гораздо большѣе качество видео, недосягаемое для VP9 при том же битрейте.
>>35907
Почему это? Vp9 используют потому что он выглядит чуть лучше h264, и поддерживается в браузерах. Av1 подходит для этого ещё лучше
Почему это? Vp9 используют потому что он выглядит чуть лучше h264, и поддерживается в браузерах. Av1 подходит для этого ещё лучше
>>35830
Avid Media Composer. Стандарт в индустрии.
> Вот у меня вопрос, какой видеоредактор является таким же божественным в винде
Avid Media Composer. Стандарт в индустрии.
>>35835
У тебя в башке насрано просто.
У тебя в башке насрано просто.
169 Кб, 1371x769Из треда вопросов послали сюда
Может кто знает, можно ли в ОБС кодировщик видео и аудио выбрать такие, чтобы запись не крашилась с ошибкой? Я вроде все вариации пробовал из доступных - выдаёт ошибку? Или по старинке делать что-ли: сначала в mp4, потом в ffmpeg в webm переделывать? Хотелось бы сразу чтобы ОБС в webm конвертировал
Может кто знает, можно ли в ОБС кодировщик видео и аудио выбрать такие, чтобы запись не крашилась с ошибкой? Я вроде все вариации пробовал из доступных - выдаёт ошибку? Или по старинке делать что-ли: сначала в mp4, потом в ffmpeg в webm переделывать? Хотелось бы сразу чтобы ОБС в webm конвертировал
>>36064
Я порекомендовал бы кодировщик 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.
Я порекомендовал бы кодировщик 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.
>>36064
Смысла сразу снимать в vp9 нет, только уже перекодировать в него. Насчет svt не знаю, да и он только на последних интелах.
Смысла сразу снимать в vp9 нет, только уже перекодировать в него. Насчет svt не знаю, да и он только на последних интелах.
25 Кб, 449x470>>36233
По адресу 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 года.
> Насчет 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 года.
>>36237
Ну фиг знает, я как-то пытался, потом увидел харки, что зеоны только с v4 и забил. У меня-то 2678v3+16гб рам.
Ну фиг знает, я как-то пытался, потом увидел харки, что зеоны только с v4 и забил. У меня-то 2678v3+16гб рам.
>>36234
Писать-то можешь, но вот качество говно будет. А vp9 нужен только с настройками для максимального сжатия.
Писать-то можешь, но вот качество говно будет. А vp9 нужен только с настройками для максимального сжатия.
Я создал тред нелинейных видеоредакторов.
Напишите пару строчек по теме, чтобы тред не удолили. Думаю тред будет полезным
>>3136277 (OP)
Напишите пару строчек по теме, чтобы тред не удолили. Думаю тред будет полезным
>>3136277 (OP)
>>01682 (OP)
А есть чо менее дрочерское (с нормальный интерфейсом) для простейших задач (обрезка, склейка, конвертирование), но все же минималистичное (Premiere и прочее будет оверкиллом)
А есть чо менее дрочерское (с нормальный интерфейсом) для простейших задач (обрезка, склейка, конвертирование), но все же минималистичное (Premiere и прочее будет оверкиллом)
>>36355
Avidemux
Avidemux
Вот есть у меня условная запись геймплея с огромный битрейтом, мне нужно ее пожать, чтобы меньше места занимало.
Сможет ли видеокарта сжать видео так же эффективно, как процессор, но при этом в разы быстрее? Если нет, то почему так?
Сможет ли видеокарта сжать видео так же эффективно, как процессор, но при этом в разы быстрее? Если нет, то почему так?
>>36361
Не сможет, чудес не бывает. Или быстро или качественно. У нвидии ещё более менее качество, на уровне x265 medium
Не сможет, чудес не бывает. Или быстро или качественно. У нвидии ещё более менее качество, на уровне x265 medium
>>36369
А давай сделаем тесты? Аноны, подскажите, как это организовать! Хочу сравнить libx264 и h264_nvenc.
А давай сделаем тесты? Аноны, подскажите, как это организовать! Хочу сравнить libx264 и h264_nvenc.
>>36412
Шкрепты напиши для ffmeg да сравни. Я как-то делал - качество сильно хуже чем процем жать почему-то.
Шкрепты напиши для ffmeg да сравни. Я как-то делал - качество сильно хуже чем процем жать почему-то.
>>36412
В staxrip есть функция сравнения видео по кадрам рядом с друг другом. Там же можно и сжать по разному
В staxrip есть функция сравнения видео по кадрам рядом с друг другом. Там же можно и сжать по разному
>>36426
Я вот как-то еще не дорос до скриптов, все обычно руками прописываю. На чем пишешь, бат небось какой или пш1?
>>36472
Мне ЛЕНЬ не столько руками писать параметры и затем сравнивать скрины, сколько осваивать новое по. Прямо фу. А еще я почитал мануалы по предустановкам использования (fast, medium etc), crf, профили и мне стало лень делать вообще что-либо.
Я не знаю, чего именно я хочу. Не знаю, как сравнить два энкодера - по битрейту? Я что, должен его руками задавать?
Кароч чето муторно все это, я ибал.
Мне хотелось простого ответа - nvenc ебет или не ебет? А оказалось, что придется ебаться самому.
Я вот как-то еще не дорос до скриптов, все обычно руками прописываю. На чем пишешь, бат небось какой или пш1?
>>36472
>ставить еще одну программу
>осваивать ее
Мне ЛЕНЬ не столько руками писать параметры и затем сравнивать скрины, сколько осваивать новое по. Прямо фу. А еще я почитал мануалы по предустановкам использования (fast, medium etc), crf, профили и мне стало лень делать вообще что-либо.
Я не знаю, чего именно я хочу. Не знаю, как сравнить два энкодера - по битрейту? Я что, должен его руками задавать?
Кароч чето муторно все это, я ибал.
Мне хотелось простого ответа - nvenc ебет или не ебет? А оказалось, что придется ебаться самому.
>>36479
Новый нвенк весьма хорош, но этим сказано далеко не всё. Везде разный баланс между уровнем сжатия и затраченным временем, однако баланс ничего не решает, когда у тебя есть определённые приоритеты. Мы тут собрались в основном пердолики и топим за максимальное сжатие любой ценой, но мы двачеры-максималисты, каждому из которых по отдельности доверять не стоит. Под разные задачи и сценарии использования лучше подходят разные кодеки, методы и их настройки. Если поваришься в теме сжатия подольше, это всё быстро станет для тебя интуитивно понятно.
> Мне хотелось простого ответа
Новый нвенк весьма хорош, но этим сказано далеко не всё. Везде разный баланс между уровнем сжатия и затраченным временем, однако баланс ничего не решает, когда у тебя есть определённые приоритеты. Мы тут собрались в основном пердолики и топим за максимальное сжатие любой ценой, но мы двачеры-максималисты, каждому из которых по отдельности доверять не стоит. Под разные задачи и сценарии использования лучше подходят разные кодеки, методы и их настройки. Если поваришься в теме сжатия подольше, это всё быстро станет для тебя интуитивно понятно.
>>26492
Бамп. Почему gop только на 6 минут?
Бамп. Почему gop только на 6 минут?
>>36497
Мне мало утверждения
что это вообще значит? Выходной размер такой же при одинаковом заданном битрейте и выходном качестве? А как сравнивать x264 в режиме CRF с nvenc?
Я почитал еще с прошлого треда про квантизацию и понял, что cqp куда тупее, так как обрабатывает вообще все кадры одинаково, тогда как crf анализирует уровень движения или что-то такое, поэтому разные кадры сжимаются тоже по-разному.
>>36537
Да я и так с вами сижу уже черт знает сколько, а голова все равно пустая и понимания нет. Зато интерес есть, неподдельный.
Типа алгоритм 264 он же одинаков что для карты, что для камня. Так почему одно хуже, а другое лучше!?
Мне мало утверждения
>на уровне
что это вообще значит? Выходной размер такой же при одинаковом заданном битрейте и выходном качестве? А как сравнивать x264 в режиме CRF с nvenc?
Я почитал еще с прошлого треда про квантизацию и понял, что cqp куда тупее, так как обрабатывает вообще все кадры одинаково, тогда как crf анализирует уровень движения или что-то такое, поэтому разные кадры сжимаются тоже по-разному.
>>36537
Да я и так с вами сижу уже черт знает сколько, а голова все равно пустая и понимания нет. Зато интерес есть, неподдельный.
Типа алгоритм 264 он же одинаков что для карты, что для камня. Так почему одно хуже, а другое лучше!?
>>36564
Нет, общий только стандарт, а кодировщики разные.
> Типа алгоритм 264 он же одинаков что для карты, что для камня.
Нет, общий только стандарт, а кодировщики разные.
>>36361
Сжать прям также эффективно как процессор нет. Но на высоких битрейтах nvenc давно равен x264. НО считаю кодирование в 300 фпс на моей 1063 стоит того.
У меня в obs стоит пресет quality с vbr 10000k max 12000k бфреймов 4. Удовлетворительное качество при минимальном весе. За 20 минут где-то 1.5 гига всего набегает.
Сжать прям также эффективно как процессор нет. Но на высоких битрейтах nvenc давно равен x264. НО считаю кодирование в 300 фпс на моей 1063 стоит того.
У меня в obs стоит пресет quality с vbr 10000k max 12000k бфреймов 4. Удовлетворительное качество при минимальном весе. За 20 минут где-то 1.5 гига всего набегает.
Во время кодирования постепенно падает скорость, например если в начале было 1.5 то к концу кодирования может упасть до 1, это нормально или у меня какие то проблемы?
>>37350
Это может зависеть от сложности отдельных участков видео по динамике.
Это может зависеть от сложности отдельных участков видео по динамике.
Как вырезать кусок видео без перекодировки, чтобы кадры не проебывались? Вырезаю кусок, там звук нормальный, а видео не двигается несколько секунд.
>>37466
Без перекодирования только по ключевым же
ffmpeg -i video.mp4 -ss 00:10:30 -to 00:11:30 -avoid_negative_ts 1 -c:v copy -c:a copy output.mp4
Без перекодирования только по ключевым же
ffmpeg -i video.mp4 -ss 00:10:30 -to 00:11:30 -avoid_negative_ts 1 -c:v copy -c:a copy output.mp4
>>37574
Я в курсе, сам им пользуюсь, но про эту команду не знал. В какую сторону смещение?
Я в курсе, сам им пользуюсь, но про эту команду не знал. В какую сторону смещение?
![78c0b119-9dc2-4682-b368-b28573226bfd-dc1f92a6-950f-47eb-9c7[...].mp4](https://2ch.life/s/thumb/3101682/16499334000870s.jpg)
647 Кб, mp4,576x1024, 0:15
Ребят, как клеить превью на видео на дваче? По сути через обычный метод на дваче не работает, и тут анон давно говорил, что можно как-то через манипуляцию временем или таймкодом, но не сказал как именно.
Вот этот видос он вроде клеил.
Вот этот видос он вроде клеил.
>>38601
Обычный метод подходит скорее для дискорда, который берёт для превью первый кадр, а не случайный, как мейлач. Мне сейчас некогда экспериментировать, но по твоему мп4релейтед видно, что имеется 2 видеодорожки. Первая, основная, должна быть короткой, чтобы с минимальной вероятностью быть выбранной для превью, а вторая, для превью, должна быть длинной и для компактности растянутой через большой gop. Проверяй сам, я побежал.
Обычный метод подходит скорее для дискорда, который берёт для превью первый кадр, а не случайный, как мейлач. Мне сейчас некогда экспериментировать, но по твоему мп4релейтед видно, что имеется 2 видеодорожки. Первая, основная, должна быть короткой, чтобы с минимальной вероятностью быть выбранной для превью, а вторая, для превью, должна быть длинной и для компактности растянутой через большой gop. Проверяй сам, я побежал.
>>38638
Ты о чем? Обычный это когда вторую дорожку с чуть большим разрешением вставляешь в файл и ставишь ее как основную. Тогда показывается превью, но запускается сам файл. Но макака убрал этот метод, чтобы скримеры не вставляли на мейлаче. На 2channel moe работает например.
Это итак понятно.
Нихрена непонятно что ты имеешь ввиду под короткой и длинной. Надо лучше выражаться и понятнее.
Сам метод про который я говорю буквально на превью видео нарисованно.
Вот это я пытаюсь понять как сделать.
>Обычный метод подходит скорее для дискорда, который берёт для превью первый кадр, а не случайный, как мейлач.
Ты о чем? Обычный это когда вторую дорожку с чуть большим разрешением вставляешь в файл и ставишь ее как основную. Тогда показывается превью, но запускается сам файл. Но макака убрал этот метод, чтобы скримеры не вставляли на мейлаче. На 2channel moe работает например.
>Мне сейчас некогда экспериментировать, но по твоему мп4релейтед видно, что имеется 2 видеодорожки
Это итак понятно.
>Первая, основная, должна быть короткой, чтобы с минимальной вероятностью быть выбранной для превью, а вторая, для превью, должна быть длинной и для компактности растянутой через большой gop.
Нихрена непонятно что ты имеешь ввиду под короткой и длинной. Надо лучше выражаться и понятнее.
Сам метод про который я говорю буквально на превью видео нарисованно.
>Превью работают но способ другой с кривой продолжительстью
Вот это я пытаюсь понять как сделать.
>>01682 (OP)
И так, нужно добавить тег "Название" ко множеству mkv файлов. Преимущественно аниме-сериалы. Если выделить все mkv в папке на дурачка, например при помощи консольной проги sharkdp/fd, командой fd -e mkv -E "Bonus" -x mkvpropedit.exe {} -s title="Anime Title", то у всех серий будет одинаковое название. А я хочу в названии сохранить информацию о серии. Что мне сделать ради этого?
И так, нужно добавить тег "Название" ко множеству mkv файлов. Преимущественно аниме-сериалы. Если выделить все mkv в папке на дурачка, например при помощи консольной проги sharkdp/fd, командой fd -e mkv -E "Bonus" -x mkvpropedit.exe {} -s title="Anime Title", то у всех серий будет одинаковое название. А я хочу в названии сохранить информацию о серии. Что мне сделать ради этого?
>>01682 (OP)
Как увеличить аудио битрейт хотя бы до 128 кб/с? И между какими командами нужно вставить (команду для изменения качества)?
Как увеличить аудио битрейт хотя бы до 128 кб/с? И между какими командами нужно вставить (команду для изменения качества)?
>>40157
-b:a 128k
После -acodec aac в параметрах кодирования этого кодека.
>Как увеличить аудио битрейт хотя бы до 128 кб/с?
-b:a 128k
>И между какими командами нужно вставить (команду для изменения качества)?
После -acodec aac в параметрах кодирования этого кодека.
3 Кб, 299x87>>40169
128 не сработало (получил те же 81 кб секс), а вот когда выставил 256 то получилось, спасибо.
128 не сработало (получил те же 81 кб секс), а вот когда выставил 256 то получилось, спасибо.
>>40217
Не должно быть такого. Используй обычный самый обновленный ffmpeg. В старых версиях полно багов. Буквально во всех кодеках каждый день исправления. А ты видимо какое-то старое говно юзаешь из гуев и прочих.
Не должно быть такого. Используй обычный самый обновленный ffmpeg. В старых версиях полно багов. Буквально во всех кодеках каждый день исправления. А ты видимо какое-то старое говно юзаешь из гуев и прочих.
>>40231
Можно просто батник написать кинуть в shell:to и делать такие видосы в настоящие 2-5 кликов.
>Прога позволяет создавать подобные видики буквально в два клика.
Можно просто батник написать кинуть в shell:to и делать такие видосы в настоящие 2-5 кликов.
>>40157
Полный пиздец, ты используешь ужасный кодировщик . Прочитай faq
Полный пиздец, ты используешь ужасный кодировщик . Прочитай faq
>>40286
Накатал тут целую паста какой до этого большой пердежный сложный и хуевый скрипт. Удалил к хуям всё.
Полностью новый написал короче. Тупо граббит имя файла и вставляет его в metadata title. легко и просто.
https://0bin.net/paste/uMpDdfPp#YmWIMeIvEVOuUNHJOwpsg-Dp4pOPCHn0XuxUW2Ec2LC
Накатал тут целую паста какой до этого большой пердежный сложный и хуевый скрипт. Удалил к хуям всё.
Полностью новый написал короче. Тупо граббит имя файла и вставляет его в metadata title. легко и просто.
https://0bin.net/paste/uMpDdfPp#YmWIMeIvEVOuUNHJOwpsg-Dp4pOPCHn0XuxUW2Ec2LC
x265 ОФИЦИАЛЬНО больше не нужен
Он кодирует быстрее и с лучшим качеством, при одинаковом размере
https://www.opennet.ru/opennews/art.shtml?num=57068
Он кодирует быстрее и с лучшим качеством, при одинаковом размере
https://www.opennet.ru/opennews/art.shtml?num=57068
>>41881
Кодирую 4к спокойно с 8 Гб оперативки, это написано если кодируешь много видео одновременно
Кодирую 4к спокойно с 8 Гб оперативки, это написано если кодируешь много видео одновременно
>>42218
Да, svt-av1
Да, svt-av1
470 Кб, 778x962Для любой вебмки видеопоток в ней - он либо progressive, либо interlaced - или есть еще возможности?
Когда я кодирую ффмпегом - в моей webm пишет yuv420p(tv, progressive).
Но я встречаю шебм с двачей yuv420p(tv). Это подразумевает progressive, interlaced, что-то еще?
Когда я кодирую ффмпегом - в моей webm пишет yuv420p(tv, progressive).
Но я встречаю шебм с двачей yuv420p(tv). Это подразумевает progressive, interlaced, что-то еще?
>>42505
Это ничего не подразумевает, для определения воспользуйся http://www.aktau.be/2013/09/22/detecting-interlaced-video-with-ffmpeg/
Это ничего не подразумевает, для определения воспользуйся http://www.aktau.be/2013/09/22/detecting-interlaced-video-with-ffmpeg/
>>42500
Есть еще дофига разновидностей интерлейсед по типу mbaff и прочих. Обычно такие файлы пишутся с камер на капоп концертах и тв программы. А так в инете везде прогрессивная развертка.
Если есть p значит прогрессивная.
Есть еще дофига разновидностей интерлейсед по типу mbaff и прочих. Обычно такие файлы пишутся с камер на капоп концертах и тв программы. А так в инете везде прогрессивная развертка.
Если есть p значит прогрессивная.
>>42523
Не мой кейс, мне нужно определить чисто формально, так сказать, не опираясь на контент. Этот фильтр не работает для видео из одной статической картинки, потому что разворачивать нечего, хех, но ведь interlaced/progressive определен даже для такого видео.
>>42636
Тип интерлейсинга мне пока не важен.
Мда, видимо, херней страдаю
Не мой кейс, мне нужно определить чисто формально, так сказать, не опираясь на контент. Этот фильтр не работает для видео из одной статической картинки, потому что разворачивать нечего, хех, но ведь interlaced/progressive определен даже для такого видео.
>>42636
Тип интерлейсинга мне пока не важен.
Мда, видимо, херней страдаю
>>42620
Как бы у тебя может видео физически быть прогрессивным, а пиксели на самом деле рисуются черезстрочно
> Я сделал vf=tinterlace, все равно yuv420p.
Как бы у тебя может видео физически быть прогрессивным, а пиксели на самом деле рисуются черезстрочно
1,2 Мб, 1415x1415>>42690
пздц как сложна жызнь
пздц как сложна жызнь
>>41875
А если у меня Ryzen вместо интела?
> x265 ОФИЦИАЛЬНО больше не нужен
> Он кодирует быстрее и с лучшим качеством, при одинаковом размере
А если у меня Ryzen вместо интела?
>>42750
Всё работает
Всё работает
Скомпилировал новый билд ffmpeg с jpeg-xl, но поддержки декодера и энкодера все равно нет в кодеках. ЧЯДНТ?
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
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
>>43291
Видимо неправильно скомпилировал https://github.com/megapro17/FFmpeg-Builds/releases/tag/latest
Видимо неправильно скомпилировал https://github.com/megapro17/FFmpeg-Builds/releases/tag/latest
>>43304
Да я через media suite. Забыл добавить походу новый параметр enable-jxl, с ним тоже не робит. Придется ждать пока добавят туда, либо самому скрипт переписывать.
Да я через media suite. Забыл добавить походу новый параметр enable-jxl, с ним тоже не робит. Придется ждать пока добавят туда, либо самому скрипт переписывать.
> -cpu-used 0..8 (синоним: -speed, по умолчанию 1) — профили энкодера для -quality good, от более ресурсоёмких и эффективных к менее
Правильно ли я понимаю из этого, что в libvpx-vp9 при -quality best игнорируется -speed?
>>43863
Нет, не игнорируется.
Гайд из шапки устарел, читай этот https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md
Нет, не игнорируется.
Гайд из шапки устарел, читай этот https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md
>>43899
Значит -speed всё равно можно не прописывать, если нужно лучшее качество, достаточно -quality best.
> 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.
>>43948
Quality best можно не прописывать, потому что эта хуйня сжимает в десятки раз медленнее без особого прироста качества
Quality best можно не прописывать, потому что эта хуйня сжимает в десятки раз медленнее без особого прироста качества
>>44026
В процентах насколько больше сжатие и время относительно good?
В процентах насколько больше сжатие и время относительно good?
>>43948
-quality best вроде даже выглядит хуже, чем -good -cpu-used 0-2. На него вообще походу с самого выхода забили.
-quality best вроде даже выглядит хуже, чем -good -cpu-used 0-2. На него вообще походу с самого выхода забили.
>>44061
Да ничем в принципе. Раньше в бест всегда делал, потом рыскал на форумах и нашел такую инфу. Да и кодирует в 10 раз медленнее, чем -cpu-used 0.
Да ничем в принципе. Раньше в бест всегда делал, потом рыскал на форумах и нашел такую инфу. Да и кодирует в 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.
>>44270
Так он и скинул, что на дискоропомойку уже 2 года поддержку не могут добавить, которая делается в 2 строки.
Так он и скинул, что на дискоропомойку уже 2 года поддержку не могут добавить, которая делается в 2 строки.
Ну когда там уже будет божественный h266 vvc. Уже 2 года пердолят и никаких результатов. Даже интел заделал каличный av1 в svt с хорошим результатом.
400 Кб, 2000x2000ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
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 (М)
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ ПЕРЕКАТ
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 (
М)>>44400
А зачем он сейчас нужен? Пока из 8К контента только панорамы природы, да городов в тестовых демо-роликах. HEVC для 4К вполне избыточен, да даже H.264 всё ещё на хорошем счету из-за своей многопрофильности.
Так AV1 и VVC для разных целей предназначены.
> Ну когда там уже будет божественный h266 vvc
А зачем он сейчас нужен? Пока из 8К контента только панорамы природы, да городов в тестовых демо-роликах. HEVC для 4К вполне избыточен, да даже H.264 всё ещё на хорошем счету из-за своей многопрофильности.
> av1
Так AV1 и VVC для разных целей предназначены.
>>44497
хз хоть какая-то конкуренция, гугел не может нормально запердолить все кодеки свои.
АВ1 вроде тоже для 8к всё готовили, ну и 4к в придачу. Для того же нетфликса, хотя до 8к все равно далеко еще.
Что это значит, не понял. Избыточен для чего, должен быть какой-то предел?
В 4к VVC в 25-40% меньше размер, чем hevc при том же качестве.
Скорее, для поддержки даже на тостере.
Каких?
>А зачем он сейчас нужен?
хз хоть какая-то конкуренция, гугел не может нормально запердолить все кодеки свои.
>Пока из 8К контента только панорамы природы, да городов в тестовых демо-роликах.
АВ1 вроде тоже для 8к всё готовили, ну и 4к в придачу. Для того же нетфликса, хотя до 8к все равно далеко еще.
>HEVC для 4К вполне избыточен
Что это значит, не понял. Избыточен для чего, должен быть какой-то предел?
В 4к VVC в 25-40% меньше размер, чем hevc при том же качестве.
>да даже H.264 всё ещё на хорошем счету из-за своей многопрофильности.
Скорее, для поддержки даже на тостере.
>Так AV1 и VVC для разных целей предназначены.
Каких?
>>44530
Запатентованное проприетарное говно не нужно. После релиза божественного svt-av1 данный кодек показал свое совершенство
> хз хоть какая-то конкуренция, гугел не может нормально запердолить все кодеки свои.
Запатентованное проприетарное говно не нужно. После релиза божественного svt-av1 данный кодек показал свое совершенство
>>44543
Мне даже интересно гугл на ютуб через свой косячный аом кодируют видео, или через их СВТ.
Мне даже интересно гугл на ютуб через свой косячный аом кодируют видео, или через их СВТ.
>>44543
Не нужно только дебилам, которые смотрят видео в браузере. На носителях везде будет VVC, как сейчас HEVC, как был H.264. Запомните это, мрази, и не отсвечивайте своей тупостью.
> Запатентованное проприетарное говно не нужно.
Не нужно только дебилам, которые смотрят видео в браузере. На носителях везде будет VVC, как сейчас HEVC, как был H.264. Запомните это, мрази, и не отсвечивайте своей тупостью.
Какой стандартный пресет у SVT-AV1? На 0 конечно мемно на моей рязани 2600 делает, 2 секунды в полчаса. На амуде вообще нет смысла или от поколения зависит?
>>43032
Запретит профсоюз твиттерастов? У них его вроде и нет. К тому же "покупатЬ" не значит купить, нвиде за армово ярмо предложили такие условия взятия жепы, что они отказались от этой идеи.
> Скорее плакать
Запретит профсоюз твиттерастов? У них его вроде и нет. К тому же "покупатЬ" не значит купить, нвиде за армово ярмо предложили такие условия взятия жепы, что они отказались от этой идеи.
>>44543
В том то и проблема, что кодеки ла-мпег не говно и имеют крайне годную аналитическую часть, в отличии от гуглоговна, который срёт жёсткой неоднородностью видеоряда и это заметно даже не вооружённым вщглядом любому, кроме мобилкодаунов.
> Запатентованное проприетарное говно не нужно
В том то и проблема, что кодеки ла-мпег не говно и имеют крайне годную аналитическую часть, в отличии от гуглоговна, который срёт жёсткой неоднородностью видеоряда и это заметно даже не вооружённым вщглядом любому, кроме мобилкодаунов.
Тред утонул или удален.
Это копия, сохраненная 28 июня 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 28 июня 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.