400 Кб, 2000x2000FFmpeg и общий кодирования видео тред №13
В прошлый раз мы чуть не утонули в бамплимите из-за прокрастинации ОПа.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
https://www.youtube.com/watch?v=chOgKT3aHBE
https://www.youtube.com/watch?v=9kaIXkImCAM
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Подробный разбор режимов кодирования основных кодеков читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда (частично устарело): https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s
Актуальный гайд по кодированию от анона из треда №5 (принимается критика, её было много в предыдущих тредах): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и просвещаем неофитов ffmpeg.
P.S. Для проверки отображения на дваче вашего нестандартного медиаконтента специально существует аж целая доска: https://2ch.hk/test/ (
М) Просьба проводить тесты там, а не ИТТ.
Тред №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/arch/2022-03-10/res/3056070.html (М)
Тред №5: https://2ch.hk/s/arch/2022-06-29/res/3101682.html (М)
Тред №6: https://2ch.hk/s/arch/2022-09-16/res/3144406.html (М)
Тред №7: https://2ch.hk/s/arch/2022-11-14/res/3181555.html (М)
Тред №8: https://2ch.hk/s/arch/2023-04-27/res/3205384.html (М)
Тред №9: https://2ch.hk/s/arch/2023-07-25/res/3239508.html (М)
Тред №10: https://2ch.hk/s/arch/2023-12-08/res/3301315.html (М)
Тред №11: https://2ch.hk/s/arch/2024-06-09/res/3365343.html (М)
Тред №12: https://2ch.hk/s/res/3441805.html (М)
В прошлый раз мы чуть не утонули в бамплимите из-за прокрастинации ОПа.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
https://www.youtube.com/watch?v=chOgKT3aHBE
https://www.youtube.com/watch?v=9kaIXkImCAM
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Подробный разбор режимов кодирования основных кодеков читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда (частично устарело): https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s
Актуальный гайд по кодированию от анона из треда №5 (принимается критика, её было много в предыдущих тредах): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и просвещаем неофитов ffmpeg.
P.S. Для проверки отображения на дваче вашего нестандартного медиаконтента специально существует аж целая доска: https://2ch.hk/test/ (
М) Просьба проводить тесты там, а не ИТТ.Тред №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/arch/2022-03-10/res/3056070.html (
М)Тред №5: https://2ch.hk/s/arch/2022-06-29/res/3101682.html (
М)Тред №6: https://2ch.hk/s/arch/2022-09-16/res/3144406.html (
М)Тред №7: https://2ch.hk/s/arch/2022-11-14/res/3181555.html (
М)Тред №8: https://2ch.hk/s/arch/2023-04-27/res/3205384.html (
М)Тред №9: https://2ch.hk/s/arch/2023-07-25/res/3239508.html (
М)Тред №10: https://2ch.hk/s/arch/2023-12-08/res/3301315.html (
М)Тред №11: https://2ch.hk/s/arch/2024-06-09/res/3365343.html (
М)Тред №12: https://2ch.hk/s/res/3441805.html (
М)
>>3600887 →
>>3600898 →
Я не знаю что ты там делаешь, но порядок действий в твоем случае такой:
1)Качаем видео с Youtube.
2)Качаем субтитры оттуда же.
3)Кодируем видео для снижения битрейта если нужно, параллельно пришивая к нему субтитры.
Команда:
Тестировал на том трейлере с прошлого треда, сжатие более чем вдвое, субтитры пришиты, VMAF 93.25.
Нужно понимать что видео с Youtube уже пожато и если ты перекодируешь его с настройками на лучшее качество это повысит битрейт, но не вернет качество, потерянное при изначальном кодирровании.
Твоя команда для пришивания субтитров
не просто их пришивает, а перекодирует видео целиком. Ну а поскольку ты не указал кодек и параметры - используются значения по умолчанию (вроде libx264 crf 28, звук aac с хрен знает каким битрейтом). Думаю раздувание размера файла растет отсюда.
>>3600898 →
Я не знаю что ты там делаешь, но порядок действий в твоем случае такой:
1)Качаем видео с Youtube.
2)Качаем субтитры оттуда же.
3)Кодируем видео для снижения битрейта если нужно, параллельно пришивая к нему субтитры.
Команда:
>ffmpeg -i Input.mp4 -vf subtitles=Sub.srt -c:v libsvtav1 -preset 5 -pix_fmt yuv420p10le -crf 35 -svtav1-params enable-qm=1:qm-min=0:qm-max=8:irefresh-type=1 -c:a libopus -b:a 48k Output.webm
Тестировал на том трейлере с прошлого треда, сжатие более чем вдвое, субтитры пришиты, VMAF 93.25.
Нужно понимать что видео с Youtube уже пожато и если ты перекодируешь его с настройками на лучшее качество это повысит битрейт, но не вернет качество, потерянное при изначальном кодирровании.
Твоя команда для пришивания субтитров
>ffmpeg -i input_video.mp4 -vf subtitles=input_subtitle.srt output_video.mp4
не просто их пришивает, а перекодирует видео целиком. Ну а поскольку ты не указал кодек и параметры - используются значения по умолчанию (вроде libx264 crf 28, звук aac с хрен знает каким битрейтом). Думаю раздувание размера файла растет отсюда.
23,7 Мб, mp4,1280x720, 0:45
2,6 Мб, webm,1280x720, 0:45
842 Кб, webm,1280x720, 0:45
2,6 Мб, webm,1280x720, 0:45
А вот иллюстрация по поводу раздувания битрейта.
1 - просто умеренно пожатое видео с качественного оригинала.
2 - зашакалил в говно видео 1.
3 - пережал видео 2 на настройках даже лучше чем при получении видео 1.
Как видно размеры видео 1 и 3 почти не отличаются, однако лютые шакалы от сжатия на втором этапе никуда не делись.
1 - просто умеренно пожатое видео с качественного оригинала.
2 - зашакалил в говно видео 1.
3 - пережал видео 2 на настройках даже лучше чем при получении видео 1.
Как видно размеры видео 1 и 3 почти не отличаются, однако лютые шакалы от сжатия на втором этапе никуда не делись.
>>01006
Чтобы эффективнее жамать.
Чтобы эффективнее жамать.
>>3600909 →
Все перематывается, скачай и проверь. В браузере перед перемоткой он сначала должен загрузить его целиком. Ну а поскольку двач хостится на мусорном ведре и регулярно лагает - видео может в принципе не грузиться и перемотка будет меньшей из проблем.
Ну и перемотка не моментальная, а на 2-3 секунды нагружает процессор и вызывает подвисание видео. Лично я не вижу в этом ничего криминального, в конце концов шебм не для того нарезаются чтобы анон ползунок дрочил. Если включить и смотреть проблем никаких.
>И ничего не перематывается, зато хорошо сжал, молодец.
Все перематывается, скачай и проверь. В браузере перед перемоткой он сначала должен загрузить его целиком. Ну а поскольку двач хостится на мусорном ведре и регулярно лагает - видео может в принципе не грузиться и перемотка будет меньшей из проблем.
Ну и перемотка не моментальная, а на 2-3 секунды нагружает процессор и вызывает подвисание видео. Лично я не вижу в этом ничего криминального, в конце концов шебм не для того нарезаются чтобы анон ползунок дрочил. Если включить и смотреть проблем никаких.
>>01008
Пчёл...
>Одиннадцать минут видео
>Не перематывается — это нормально
>это же шебем — скачал и перематывай
>не вижу в этом ничего криминального
Пчёл...
>>01012
Когда двач не лагает - видео подгрузится и можно перематывать прямо в браузере. Когда лагает ты его в принципе не посмотришь.
Здесь должна быть шутка про зумеров и тиктоки.
Еще раз - видео перематывается, просто не моментально.
Когда двач не лагает - видео подгрузится и можно перематывать прямо в браузере. Когда лагает ты его в принципе не посмотришь.
>Одиннадцать минут видео
Здесь должна быть шутка про зумеров и тиктоки.
Еще раз - видео перематывается, просто не моментально.
>>01006
Да я без понятия че там у них за формат, кодек создавался в первую очередь для 10-битного кодирования поэтому использую его.
Да я без понятия че там у них за формат, кодек создавался в первую очередь для 10-битного кодирования поэтому использую его.
89 Кб, 951x411Посоветуйте минимальные разрешения для двух ситуаций:
1,чтобы можно было читать текст без особого напряга, но, в принципе, мне ж не книгу читать, так что можно не идеально четко (допустим это поучительные видео про компик и там кто-то вбивает команды)\
2,вообще максимум ужания, но чтобы при этом можно было видеть лица с метров с пяти хотя бы, когда допустим кто-то снимал камерой улицу пока ходил ногами (ну, или это запись геймплея обливиона, где хочется лица видеть (купи облу, кстати))
конечно решает битрейт, но... по большей части можно совет по разрешениям в этих ситуациях? 320 на 240 — это вообще доннище и не вариант.
можно конечно и править соотношения сторон, но мне лучше для 21:9, хотя моник 21:10 тоже есть
1,чтобы можно было читать текст без особого напряга, но, в принципе, мне ж не книгу читать, так что можно не идеально четко (допустим это поучительные видео про компик и там кто-то вбивает команды)\
2,вообще максимум ужания, но чтобы при этом можно было видеть лица с метров с пяти хотя бы, когда допустим кто-то снимал камерой улицу пока ходил ногами (ну, или это запись геймплея обливиона, где хочется лица видеть (купи облу, кстати))
конечно решает битрейт, но... по большей части можно совет по разрешениям в этих ситуациях? 320 на 240 — это вообще доннище и не вариант.
можно конечно и править соотношения сторон, но мне лучше для 21:9, хотя моник 21:10 тоже есть
>>01188
Для текста тебе нужно частоту кадров понижать. Статичный текст и в 0 FPS вообще-то читается, консольки хватит 10 допустим. Тогда ты сможешь битрейт высоким оставить и кадры чёткими.
Но если у тебя там не только текст, но все перемешано, то нужна переменная частота и это уже не так просто, но в целом можно. VFR обычно называется.
Разрешение – последнее что важно.
Для текста тебе нужно частоту кадров понижать. Статичный текст и в 0 FPS вообще-то читается, консольки хватит 10 допустим. Тогда ты сможешь битрейт высоким оставить и кадры чёткими.
Но если у тебя там не только текст, но все перемешано, то нужна переменная частота и это уже не так просто, но в целом можно. VFR обычно называется.
Разрешение – последнее что важно.
>>01190
Ну, не знаю даже. Не с пустого же места обывалы пикабушного уровня компетенций создают картиночки а-ля графики битрейта для качественного видео в разных разрешениях, типа: "для 720 нужно 3000 битов, а вот для 1080 нужно 4000, для 480 можно и 2000...".
Смотрю, что придется осваивать ffmpeg как ни крути. Ведь ни одна программа (мне известны все, буквально любую я попробовал) не может в адекватный и автоматический переменный битрейт. Ни в одной проге нет полной настройки всех характеристик, и ни одна не способна адекватно юзать видеокарту. Но, как же в падлу пользовать консоль.
Правда ли что ваш ffmpeg не будет трогать те характеристики видео и музыки, которые не упомянуты в команде?
Ну, не знаю даже. Не с пустого же места обывалы пикабушного уровня компетенций создают картиночки а-ля графики битрейта для качественного видео в разных разрешениях, типа: "для 720 нужно 3000 битов, а вот для 1080 нужно 4000, для 480 можно и 2000...".
Смотрю, что придется осваивать ffmpeg как ни крути. Ведь ни одна программа (мне известны все, буквально любую я попробовал) не может в адекватный и автоматический переменный битрейт. Ни в одной проге нет полной настройки всех характеристик, и ни одна не способна адекватно юзать видеокарту. Но, как же в падлу пользовать консоль.
Правда ли что ваш ffmpeg не будет трогать те характеристики видео и музыки, которые не упомянуты в команде?
>>01195
Это не константа. Какой битрейт тебе нужен для получения определенного уровня качества зависит от используемого кодека, его настроек, частоты кадров и сложности самого видео.
>Не с пустого же места обывалы пикабушного уровня компетенций создают картиночки а-ля графики битрейта для качественного видео в разных разрешениях, типа: "для 720 нужно 3000 битов, а вот для 1080 нужно 4000, для 480 можно и 2000...".
Это не константа. Какой битрейт тебе нужен для получения определенного уровня качества зависит от используемого кодека, его настроек, частоты кадров и сложности самого видео.
Аноны подскажите пользуюсь ffmpeg для вырезания музыки из видео файл музыки получается только в формате wav, как сделать так что-бы можно было его сохранять в формате mp3?
К слову эту утилиту собирал из исходников, а файл wav мне приходится в Audacity переделывать в mp3.
К слову эту утилиту собирал из исходников, а файл wav мне приходится в Audacity переделывать в mp3.
>>01220
https://trac.ffmpeg.org/wiki/Encode/MP3
>ffmpeg -i Input.mp4 -codec:a libmp3lame -qscale:a 2 output.mp3
https://trac.ffmpeg.org/wiki/Encode/MP3
В общем как-то так. Параметры позволяюют немного подтянуть средний VMAF без роста битрейта и немного сгладить график (особенно заметно на третьем в районе 160-го кадра). Первые два это одно и то же видео на разном битрейте.
Эффект от настроек проявлялся на всех тестовых видео, чем сильнее сжимал - тем больше был прирост VMAF.
Как уже писал в прошлом треде:
enable-qm=1:qm-min=0:qm-max=8 - падение скорости кодирование на 5-10%
irefresh-type=1 - кратковременное подвисание видео при перемотке
Стоит ли оно (несколько десятых VMAF) того судите сами. Других полезных настроек не нашел.
Эффект от настроек проявлялся на всех тестовых видео, чем сильнее сжимал - тем больше был прирост VMAF.
Как уже писал в прошлом треде:
enable-qm=1:qm-min=0:qm-max=8 - падение скорости кодирование на 5-10%
irefresh-type=1 - кратковременное подвисание видео при перемотке
Стоит ли оно (несколько десятых VMAF) того судите сами. Других полезных настроек не нашел.
Кто-нибудь с гита пилит аппаратную поддержку vvc и av1 для карт 10 серии вообще? неужели это убер-сложно, и коли оффициальные жиды решили не выкатывать поддержку, то всё, пиздец?
Зумерская шутеечка про то что карты типа слабые — не смешна, ибо на 1080 часовое видео в hevc конвертится за 5 минут при том, что даже половинной загрузкой этим карты не пахнет, и пароли десятые карты подбирают со скоростью 200к в секунду при щадящем режиме без нагрева. Что за брух, где умельцы? Был бы я гоем, влил бы деньги не в зумзум-говно карту, а в жесткие диски по 6гб, чтобы всё в лослесс хранить на кодеке mpeg2, лааал бля.
Зумерская шутеечка про то что карты типа слабые — не смешна, ибо на 1080 часовое видео в hevc конвертится за 5 минут при том, что даже половинной загрузкой этим карты не пахнет, и пароли десятые карты подбирают со скоростью 200к в секунду при щадящем режиме без нагрева. Что за брух, где умельцы? Был бы я гоем, влил бы деньги не в зумзум-говно карту, а в жесткие диски по 6гб, чтобы всё в лослесс хранить на кодеке mpeg2, лааал бля.
>>01478
Там же отдельный чип для кодировки видосов. Если он не поддерживает, то и не будет
Там же отдельный чип для кодировки видосов. Если он не поддерживает, то и не будет
>>01513
Я уже скомпилированный качал отсюда
https://github.com/AnimMouse/ffmpeg-autobuild/releases
но полагаю что надо компилировать с ключом --enable-libmp3lame.
Я уже скомпилированный качал отсюда
https://github.com/AnimMouse/ffmpeg-autobuild/releases
но полагаю что надо компилировать с ключом --enable-libmp3lame.
>>01478
Да. Для этого надо вслепую раскурить аппаратную часть и обойти все её защиты, буквально хакинг.
>неужели это убер-сложно
Да. Для этого надо вслепую раскурить аппаратную часть и обойти все её защиты, буквально хакинг.
>>01489
>>01538
Ну, то есть, дожили -- да? Упираемся в то, что чипированы неправильным чипом, а чтобы воспользоваться базовыми правами каждого человека на оптимизацию своего дискового пространства, нам нужно заплатить соцрейтинговые монетки с виртуальной карты барену, приобретая новый чип. Охуенно.
Нет, ничего не мешает конвертить vvc/AV1 на gtx1080. Вообще ничего, кроме указки барина, не выделившего тимки из трех челиков на создание простецкого (по меркам конгломерата) драйвера.
>>01538
Ну, то есть, дожили -- да? Упираемся в то, что чипированы неправильным чипом, а чтобы воспользоваться базовыми правами каждого человека на оптимизацию своего дискового пространства, нам нужно заплатить соцрейтинговые монетки с виртуальной карты барену, приобретая новый чип. Охуенно.
Нет, ничего не мешает конвертить vvc/AV1 на gtx1080. Вообще ничего, кроме указки барина, не выделившего тимки из трех челиков на создание простецкого (по меркам конгломерата) драйвера.
Кстати, подскажите, зачем нужен пакет ogv? И есть ли (кроме фришности, конечно) этих инструментов цимес задействовать также и нативный для ogg кодек (не помню его названия)? Так-то у меня в голове мысль крутится, что, может быть, существует кодек из начала 00х, чьи шакалы сжатия более гладки и приятны глазу, нежели сыпящиеся квадраты AVC1 (и, боже упаси, тот клеточный капец, который показывает mpeg2)?
Ну, вот, кста. Что и подтверждается. Я, как человек без нового чипа, вместо пользования благами vvc/av1 пошел ковыряться по помойкам за какими-то там хипстерскими ".ovg", о которых никто не знает.
>>01576
Пакет ogv поддерживает формат контейнеров Ogg, в котором обычно используется видеокодек Theora (в паре со звуком Vorbis). Theora, разработанный в начале 2000-х годов, является открытым кодеком, не требующим лицензионных отчислений. Хотя он менее эффективен, чем современные кодеки типа H.264 (AVC1), некоторые пользователи предпочитают его артефакты сжатия, которые могут выглядеть более плавными и менее блочными по сравнению с MPEG2 или AVC1 с низким битрейтом. Однако сжатие Theora устарело по сегодняшним меркам - современные альтернативы, такие как VP9 или AV1, предлагают более высокую эффективность и визуальное качество, но требуют большей вычислительной мощности.
Пакет ogv поддерживает формат контейнеров Ogg, в котором обычно используется видеокодек Theora (в паре со звуком Vorbis). Theora, разработанный в начале 2000-х годов, является открытым кодеком, не требующим лицензионных отчислений. Хотя он менее эффективен, чем современные кодеки типа H.264 (AVC1), некоторые пользователи предпочитают его артефакты сжатия, которые могут выглядеть более плавными и менее блочными по сравнению с MPEG2 или AVC1 с низким битрейтом. Однако сжатие Theora устарело по сегодняшним меркам - современные альтернативы, такие как VP9 или AV1, предлагают более высокую эффективность и визуальное качество, но требуют большей вычислительной мощности.
>>01571
Во-первых это не софтовая проблема, а железная. Нельзя просто взять и написать драйвер, чтобы у тебя железо новое из воздуха появилось.
Во-вторых твои базовые хуман райтс реализуют простые честные прямые процессорные мощности. Хоть и не обязаны, делают это только из доброты душевной. Не хочешь полагаться на милость — спонсируй свободный софт и свободное железо. Пора бы уже отказаться от идеализма, понимаешь?
Во-первых это не софтовая проблема, а железная. Нельзя просто взять и написать драйвер, чтобы у тебя железо новое из воздуха появилось.
Во-вторых твои базовые хуман райтс реализуют простые честные прямые процессорные мощности. Хоть и не обязаны, делают это только из доброты душевной. Не хочешь полагаться на милость — спонсируй свободный софт и свободное железо. Пора бы уже отказаться от идеализма, понимаешь?
>>01743
Ну я же скидывал выше ссылку. Либо -q:a для переменного битрейта (диапазон 0-9, чем ниже тем лучше качество), либо -b:a для постоянного (допустимые значения 8k/16k/24k/32k/40k/48k/64k/80k/96k/112k/128k/160k/192k/224k/256k/320k).
Ну я же скидывал выше ссылку. Либо -q:a для переменного битрейта (диапазон 0-9, чем ниже тем лучше качество), либо -b:a для постоянного (допустимые значения 8k/16k/24k/32k/40k/48k/64k/80k/96k/112k/128k/160k/192k/224k/256k/320k).
31 Кб, 635x209нахрена ему делить картинку на 2
добавляю пиксель и всё good
буквально..
а ещё кто знает это баг винды или чего, когда ты в батник копируешь путь к файлу, даже если он полностью на английском, консолька ругается и пишет типа у меня там иероглифы и пока ты ручками не перепишешь ничего не поможет это видимо редкий случай когда между дисками\системами переносишь файлы
добавляю пиксель и всё good
буквально..
а ещё кто знает это баг винды или чего, когда ты в батник копируешь путь к файлу, даже если он полностью на английском, консолька ругается и пишет типа у меня там иероглифы и пока ты ручками не перепишешь ничего не поможет это видимо редкий случай когда между дисками\системами переносишь файлы
117 Кб, 956x956>>01940
Ширина и высота видео должны быть кратны 2 по нескольким причинам, связанным с тем, как кодек обрабатывает и сжимает видео.
1. Проверка на четность: Многие видеоформаты и кодеки, включая x264, используют блоки пикселей для обработки. Эти блоки часто имеют размеры 2x2, 4x4 и т.д. Если ширина или высота нечетные, это может привести к проблемам с выравниванием блоков, что затрудняет обработку и может снизить эффективность сжатия.
2. Сжатие и кодирование: Кодеки, такие как x264, используют различные алгоритмы сжатия, которые работают с блоками пикселей. Если размеры видео не кратны 2, это может привести к необходимости дополнительных вычислений для обработки краевых пикселей, что может снизить производительность и увеличить размер файла.
3. Совместимость: Некоторые устройства и плееры могут не поддерживать видео с размерами, не кратными 2, что может привести к проблемам с воспроизведением.
4. Четность для субдискретизации: В H.264 часто используется субдискретизация цветовой информации (например, 4:2:0), где цветовая информация кодируется с меньшим разрешением, чем яркостная. Это также требует, чтобы размеры были четными, чтобы правильно выровнять данные.
Ширина и высота видео должны быть кратны 2 по нескольким причинам, связанным с тем, как кодек обрабатывает и сжимает видео.
1. Проверка на четность: Многие видеоформаты и кодеки, включая x264, используют блоки пикселей для обработки. Эти блоки часто имеют размеры 2x2, 4x4 и т.д. Если ширина или высота нечетные, это может привести к проблемам с выравниванием блоков, что затрудняет обработку и может снизить эффективность сжатия.
2. Сжатие и кодирование: Кодеки, такие как x264, используют различные алгоритмы сжатия, которые работают с блоками пикселей. Если размеры видео не кратны 2, это может привести к необходимости дополнительных вычислений для обработки краевых пикселей, что может снизить производительность и увеличить размер файла.
3. Совместимость: Некоторые устройства и плееры могут не поддерживать видео с размерами, не кратными 2, что может привести к проблемам с воспроизведением.
4. Четность для субдискретизации: В H.264 часто используется субдискретизация цветовой информации (например, 4:2:0), где цветовая информация кодируется с меньшим разрешением, чем яркостная. Это также требует, чтобы размеры были четными, чтобы правильно выровнять данные.
Encode это когда созданный raw файл сжимают в контейнер, а transcode когда из одного контейнера в другой переделывают, нампример ts или mkv в mp4, причем можно это делать без потери качества (т.е. можно разжать контейнер обратно в raw?), а можно кодеками ужать файл с определенной потерей качества?
С какой, примерно, скоростью современный процессор, конкретно 14600k, с помощью libx265 и av1 в ffmpeg будет ужимать 1080p и 1440p видео?
У меня сейчас i7-4771, дефолтный libx265 обрабатывает 720p со скоростью около 2.3х, а 1080p где-то 0.4х. Про av1 пишут, что экономит еще 20% веса при том же качестве, но он у меня скорость в долю секунды выдал и 2 минуты полдня обрабатывал.
Собственно есть КУЧА видео .ts и .mp4, которые не хочу удалять, чуть меньшее визуальное качество не беда, а памяти уже много на это дело выделено, ужать это все в 3-6 раз - то что мне нужно.
Сейчас могу блок питания со скидкой взять, не знаю есть ли смысл поставить нынешний компьютер параллельно ужимать видео, или новый пк будет это делать супер быстро.
С какой, примерно, скоростью современный процессор, конкретно 14600k, с помощью libx265 и av1 в ffmpeg будет ужимать 1080p и 1440p видео?
У меня сейчас i7-4771, дефолтный libx265 обрабатывает 720p со скоростью около 2.3х, а 1080p где-то 0.4х. Про av1 пишут, что экономит еще 20% веса при том же качестве, но он у меня скорость в долю секунды выдал и 2 минуты полдня обрабатывал.
Собственно есть КУЧА видео .ts и .mp4, которые не хочу удалять, чуть меньшее визуальное качество не беда, а памяти уже много на это дело выделено, ужать это все в 3-6 раз - то что мне нужно.
Сейчас могу блок питания со скидкой взять, не знаю есть ли смысл поставить нынешний компьютер параллельно ужимать видео, или новый пк будет это делать супер быстро.
>>02738
Можно поменять контейнер без перекодировки, т.е. без потери качества
ffmpeg -i mocha.mp4 -c copy govno.mkv
> transcode когда из одного контейнера в другой переделывают, нампример ts или mkv в mp4, причем можно это делать без потери качества (т.е. можно разжать контейнер обратно в raw?), а можно кодеками ужать файл с определенной потерей качества?
Можно поменять контейнер без перекодировки, т.е. без потери качества
ffmpeg -i mocha.mp4 -c copy govno.mkv
>>02738
Разумеется, для того они и существуют.
Скорость кодирования сильно зависит от настроек кодека и, в меньшей степени, от сложности видео. Поэтому точную цифру назвать невозможно.
Отмечу лишь что SVT-AV1 разрабатывался для использования на многоядерных процессорах и прирост скорости на 14-ядерном 14600k относительно 4-ядерного i7-4771 должен быть существенным (хотя для самых медленных пресетов 1-3 разница будет менее заметной из-за использования ими алгоритмов которые плохо распараллеливаются).
Это наверное старый AOM-AV1 который на дефолтных настройках невероятно медленный.
>а можно кодеками ужать файл с определенной потерей качества?
Разумеется, для того они и существуют.
>С какой, примерно, скоростью современный процессор, конкретно 14600k, с помощью libx265 и av1 в ffmpeg будет ужимать 1080p и 1440p видео?
Скорость кодирования сильно зависит от настроек кодека и, в меньшей степени, от сложности видео. Поэтому точную цифру назвать невозможно.
Отмечу лишь что SVT-AV1 разрабатывался для использования на многоядерных процессорах и прирост скорости на 14-ядерном 14600k относительно 4-ядерного i7-4771 должен быть существенным (хотя для самых медленных пресетов 1-3 разница будет менее заметной из-за использования ими алгоритмов которые плохо распараллеливаются).
>но он у меня скорость в долю секунды выдал и 2 минуты полдня обрабатывал
Это наверное старый AOM-AV1 который на дефолтных настройках невероятно медленный.
>>02764
Я так ts в mp4 гнал, вес файлов уменьшался до 5%. Чет подозрительно много.
>>02767
Я имел ввиду прирост при тех же условиях.
Я пробовал медленные пресеты для лучшего качества на 1080p, там было 0.2х, даже чуть меньше.
Я пытаюсь на глазок прикинуть. У 4771 8 потоков, у 14600K 20 потоков, т.е. в 2.5 больше. Technical.city (все что есть) дает общий прирост где-то в 5.4 раза, пусть будет 4. Получается 0.2х2.5х4= 2х скорость. Это уже нормально, если за счет хардвере технологий будет еще быстрее, то вообще отлично. А если будет 1.5х и ниже, то это меня не устроит.
> ffmpeg -i mocha.mp4 -c copy govno.mkv
Я так ts в mp4 гнал, вес файлов уменьшался до 5%. Чет подозрительно много.
>>02767
> Скорость кодирования сильно зависит от настроек кодека
Я имел ввиду прирост при тех же условиях.
Я пробовал медленные пресеты для лучшего качества на 1080p, там было 0.2х, даже чуть меньше.
Я пытаюсь на глазок прикинуть. У 4771 8 потоков, у 14600K 20 потоков, т.е. в 2.5 больше. Technical.city (все что есть) дает общий прирост где-то в 5.4 раза, пусть будет 4. Получается 0.2х2.5х4= 2х скорость. Это уже нормально, если за счет хардвере технологий будет еще быстрее, то вообще отлично. А если будет 1.5х и ниже, то это меня не устроит.
>>02787
Ну это тебе надо найти кого-то с 14600K и попросить закодировать какое-нибудь видео, а потом повторить на своем и сравнить. Ну или ищи бенчмарки в интернете вроде этих.
https://www.hwcooling.net/en/intel-core-i5-14600k-in-tests-against-30-processors-review/25/
https://www.anandtech.com/show/21084/intel-core-i9-14900k-core-i7-14700k-and-core-i5-14600k-review-raptor-lake-refreshed/7
Ну это тебе надо найти кого-то с 14600K и попросить закодировать какое-нибудь видео, а потом повторить на своем и сравнить. Ну или ищи бенчмарки в интернете вроде этих.
https://www.hwcooling.net/en/intel-core-i5-14600k-in-tests-against-30-processors-review/25/
https://www.anandtech.com/show/21084/intel-core-i9-14900k-core-i7-14700k-and-core-i5-14600k-review-raptor-lake-refreshed/7
1,2 Мб, 1080x1080Господа ковырятели видеофайлов, видит ли у вас какая-нибудь прога указанный сдвиг аудиодорожки(дорожЕК?) в этом файле?
https://dropmefiles.com/uc77W (847 МБ, скорость скачивания не ограничена)
Avidemux при его открытии автоматически выставляет сдвиг аудио 80 мс, как будто он берет его из исходного файла. При этом вроде бы этот сдвиг 80 мс правильный или близкий к правильному - не могу точно понять на глаз, 80 или 160 было бы верным, но при воспроизведении прямо здесь в окне Avidemux вроде бы один из них является верным сдвигом. А вот 0 мс выглядит как маленький рассинхрон.
Но при этом MediaInfo, gMKVExtractGUI, и MKVToolNixGUI не сообщают ни о каком сдвиге в дорожках.
Но откуда-то же Avidemux берет эту цифру, берет вообще сам факт того, что аудио надо сдвинуть? С другими файлами он так не делает.
Кроме проблемы (если это вообще проблема) с этим файлом, я также в целом пытаюсь понять, как нужно правильно детектить сдвиг аудиодорожек в видеофайлах (в уже существующих, сделанных кем-то), чтобы правильно синхронизировать их с другими видео (например, русскую дорожку с ориг ремуксом, и т.п.)
https://dropmefiles.com/uc77W (847 МБ, скорость скачивания не ограничена)
Avidemux при его открытии автоматически выставляет сдвиг аудио 80 мс, как будто он берет его из исходного файла. При этом вроде бы этот сдвиг 80 мс правильный или близкий к правильному - не могу точно понять на глаз, 80 или 160 было бы верным, но при воспроизведении прямо здесь в окне Avidemux вроде бы один из них является верным сдвигом. А вот 0 мс выглядит как маленький рассинхрон.
Но при этом MediaInfo, gMKVExtractGUI, и MKVToolNixGUI не сообщают ни о каком сдвиге в дорожках.
Но откуда-то же Avidemux берет эту цифру, берет вообще сам факт того, что аудио надо сдвинуть? С другими файлами он так не делает.
Кроме проблемы (если это вообще проблема) с этим файлом, я также в целом пытаюсь понять, как нужно правильно детектить сдвиг аудиодорожек в видеофайлах (в уже существующих, сделанных кем-то), чтобы правильно синхронизировать их с другими видео (например, русскую дорожку с ориг ремуксом, и т.п.)
>>02787
Всё абсолютно правильно и так и должно быть. TS и M2TS - это транспортные потоки, они и должны худеть при перегоне в более привычные консумерские типа MP4 и MKV. Ты также можешь демуксировать их (вытащить из них содержимое в сыром виде) и наглядно убедиться, что сумма размеров всех потоков будет равна размеру MP4 или MKV (плюс крошечный оверхед, типа пары мегабайт), а вот в TS или M2TS будет огромный оверхед размером 5-10%.
>Я так ts в mp4 гнал, вес файлов уменьшался до 5%. Чет подозрительно много.
Всё абсолютно правильно и так и должно быть. TS и M2TS - это транспортные потоки, они и должны худеть при перегоне в более привычные консумерские типа MP4 и MKV. Ты также можешь демуксировать их (вытащить из них содержимое в сыром виде) и наглядно убедиться, что сумма размеров всех потоков будет равна размеру MP4 или MKV (плюс крошечный оверхед, типа пары мегабайт), а вот в TS или M2TS будет огромный оверхед размером 5-10%.
>>02787
Мало скорее.
В TS есть избыточность для корректировки данных, пакетная метадата, а если ты чанки HLSа гонял, то там вообще в каждом ещё и мета кодека.
>Чет подозрительно много.
Мало скорее.
В TS есть избыточность для корректировки данных, пакетная метадата, а если ты чанки HLSа гонял, то там вообще в каждом ещё и мета кодека.
Наткнулся на странную ситуацию. Прошу комментариев и разъяснений.
TL;DR: mkvToolNix в каких-то(?) определенных(?) ситуациях молча откусывает 4 байта именно от видеопотока при перегоне из m2ts в mkv контейнер. Речь НЕ о значительном уменьшении размера всего файла целиком.
Я сверял ремуксы с рутрекера с полными дисками с приватного трекера, чтобы убедиться, что 1) ремукс сделан именно с этого диска, и что 2) русская аудиодорожка из ремукса идеально сюда подойдет, и можно оставить ее и положить рядом с диском.
Делал это так:
eac3to.exe "П:\уть\к\файлу.m2ts" -demux
Это распаковывает видеофайл на его составляющие (видеопоток, аудиопотоки, субтитры). Я делал это с видеофайлом m2ts с блюрея (сначала убедившись, что весь фильм лежит в одном файле, без seamless branching), а потом делал то же самое с ремуксом в mkv. После чего сравнивал хэши распакованных потоков и убеждался, что все совпадает.
Но наткнулся на ремукс, в котором видеопоток на 4 байта укорочен по сравнению с тем, который лежит внутри m2ts на блюрее.
Пожал плечами, отложил пока что в сторону. С парой других ремуксов такого не было, там идеальное совпадение.
А потом решил сравнить полный блюрей еще одного фильма с ремуксом, где сам ремукс тоже в m2ts - то есть выкинуто все остальное содержимое диска, добавлена русская дорожка, но сохранена структура диска и контейнер m2ts - видимо, релизер хотел сделать проигрываемый блюрей-диск только с фильмом. И мне стало интересно сравнить не только эти два m2ts (с нетронутого блюрея и перепакованный), но и mkv, полученные вручную из них обоих.
Сделал mkv так: в mkvToolNix кинул m2ts файл, ничего не менял, нажал "Start multiplexing", получил mkv-файл из тех же дорожек, что и были в m2ts. Ну и потом распаковал все четыре видеофайла на составляющие с помощью eac3to (-demux).
И оказалось, что вот этот результат моего перегона из m2ts в mkv с помощью mkvToolNix тоже откусил 4 байта от видеопотока! Точно такой же результат, какой был в одном ремуксе mkv, найденном на рутрекере.
MKVToolNix в процессе создания этого mkv не сообщал ни о каких ошибках в конце процесса. Eac3to при обработке видеофайлов (при вытаскивании из них потоков) тоже не сообщал ни о каких ошибках, а также написал одинаковое количество кадров для всех видеофайлов.
Но видеопоток на 4 байта короче.
А также по какой-то причине сильно уменьшились файлы PGS-субтитров при перегоне из M2TS в MKV с помощью MKVToolNix.
Что мне обо всем этом думать? Что происходит?
TL;DR: mkvToolNix в каких-то(?) определенных(?) ситуациях молча откусывает 4 байта именно от видеопотока при перегоне из m2ts в mkv контейнер. Речь НЕ о значительном уменьшении размера всего файла целиком.
Я сверял ремуксы с рутрекера с полными дисками с приватного трекера, чтобы убедиться, что 1) ремукс сделан именно с этого диска, и что 2) русская аудиодорожка из ремукса идеально сюда подойдет, и можно оставить ее и положить рядом с диском.
Делал это так:
eac3to.exe "П:\уть\к\файлу.m2ts" -demux
Это распаковывает видеофайл на его составляющие (видеопоток, аудиопотоки, субтитры). Я делал это с видеофайлом m2ts с блюрея (сначала убедившись, что весь фильм лежит в одном файле, без seamless branching), а потом делал то же самое с ремуксом в mkv. После чего сравнивал хэши распакованных потоков и убеждался, что все совпадает.
Но наткнулся на ремукс, в котором видеопоток на 4 байта укорочен по сравнению с тем, который лежит внутри m2ts на блюрее.
Пожал плечами, отложил пока что в сторону. С парой других ремуксов такого не было, там идеальное совпадение.
А потом решил сравнить полный блюрей еще одного фильма с ремуксом, где сам ремукс тоже в m2ts - то есть выкинуто все остальное содержимое диска, добавлена русская дорожка, но сохранена структура диска и контейнер m2ts - видимо, релизер хотел сделать проигрываемый блюрей-диск только с фильмом. И мне стало интересно сравнить не только эти два m2ts (с нетронутого блюрея и перепакованный), но и mkv, полученные вручную из них обоих.
Сделал mkv так: в mkvToolNix кинул m2ts файл, ничего не менял, нажал "Start multiplexing", получил mkv-файл из тех же дорожек, что и были в m2ts. Ну и потом распаковал все четыре видеофайла на составляющие с помощью eac3to (-demux).
И оказалось, что вот этот результат моего перегона из m2ts в mkv с помощью mkvToolNix тоже откусил 4 байта от видеопотока! Точно такой же результат, какой был в одном ремуксе mkv, найденном на рутрекере.
MKVToolNix в процессе создания этого mkv не сообщал ни о каких ошибках в конце процесса. Eac3to при обработке видеофайлов (при вытаскивании из них потоков) тоже не сообщал ни о каких ошибках, а также написал одинаковое количество кадров для всех видеофайлов.
Но видеопоток на 4 байта короче.
А также по какой-то причине сильно уменьшились файлы PGS-субтитров при перегоне из M2TS в MKV с помощью MKVToolNix.
Что мне обо всем этом думать? Что происходит?
Наткнулся на странную ситуацию. Прошу комментариев и разъяснений.
TL;DR: mkvToolNix в каких-то(?) определенных(?) ситуациях молча откусывает 4 байта именно от видеопотока при перегоне из m2ts в mkv контейнер. Речь НЕ о значительном уменьшении размера всего файла целиком.
Я сверял ремуксы с рутрекера с полными дисками с приватного трекера, чтобы убедиться, что 1) ремукс сделан именно с этого диска, и что 2) русская аудиодорожка из ремукса идеально сюда подойдет, и можно оставить ее и положить рядом с диском.
Делал это так:
eac3to.exe "П:\уть\к\файлу.m2ts" -demux
Это распаковывает видеофайл на его составляющие (видеопоток, аудиопотоки, субтитры). Я делал это с видеофайлом m2ts с блюрея (сначала убедившись, что весь фильм лежит в одном файле, без seamless branching), а потом делал то же самое с ремуксом в mkv. После чего сравнивал хэши распакованных потоков и убеждался, что все совпадает.
Но наткнулся на ремукс, в котором видеопоток на 4 байта укорочен по сравнению с тем, который лежит внутри m2ts на блюрее.
Пожал плечами, отложил пока что в сторону. С парой других ремуксов такого не было, там идеальное совпадение.
А потом решил сравнить полный блюрей еще одного фильма с ремуксом, где сам ремукс тоже в m2ts - то есть выкинуто все остальное содержимое диска, добавлена русская дорожка, но сохранена структура диска и контейнер m2ts - видимо, релизер хотел сделать проигрываемый блюрей-диск только с фильмом. И мне стало интересно сравнить не только эти два m2ts (с нетронутого блюрея и перепакованный), но и mkv, полученные вручную из них обоих.
Сделал mkv так: в mkvToolNix кинул m2ts файл, ничего не менял, нажал "Start multiplexing", получил mkv-файл из тех же дорожек, что и были в m2ts. Ну и потом распаковал все четыре видеофайла на составляющие с помощью eac3to (-demux).
И оказалось, что вот этот результат моего перегона из m2ts в mkv с помощью mkvToolNix тоже откусил 4 байта от видеопотока! Точно такой же результат, какой был в одном ремуксе mkv, найденном на рутрекере.
MKVToolNix в процессе создания этого mkv не сообщал ни о каких ошибках в конце процесса. Eac3to при обработке видеофайлов (при вытаскивании из них потоков) тоже не сообщал ни о каких ошибках, а также написал одинаковое количество кадров для всех видеофайлов.
Но видеопоток на 4 байта короче.
А также по какой-то причине сильно уменьшились файлы PGS-субтитров при перегоне из M2TS в MKV с помощью MKVToolNix.
Что мне обо всем этом думать? Что происходит?
TL;DR: mkvToolNix в каких-то(?) определенных(?) ситуациях молча откусывает 4 байта именно от видеопотока при перегоне из m2ts в mkv контейнер. Речь НЕ о значительном уменьшении размера всего файла целиком.
Я сверял ремуксы с рутрекера с полными дисками с приватного трекера, чтобы убедиться, что 1) ремукс сделан именно с этого диска, и что 2) русская аудиодорожка из ремукса идеально сюда подойдет, и можно оставить ее и положить рядом с диском.
Делал это так:
eac3to.exe "П:\уть\к\файлу.m2ts" -demux
Это распаковывает видеофайл на его составляющие (видеопоток, аудиопотоки, субтитры). Я делал это с видеофайлом m2ts с блюрея (сначала убедившись, что весь фильм лежит в одном файле, без seamless branching), а потом делал то же самое с ремуксом в mkv. После чего сравнивал хэши распакованных потоков и убеждался, что все совпадает.
Но наткнулся на ремукс, в котором видеопоток на 4 байта укорочен по сравнению с тем, который лежит внутри m2ts на блюрее.
Пожал плечами, отложил пока что в сторону. С парой других ремуксов такого не было, там идеальное совпадение.
А потом решил сравнить полный блюрей еще одного фильма с ремуксом, где сам ремукс тоже в m2ts - то есть выкинуто все остальное содержимое диска, добавлена русская дорожка, но сохранена структура диска и контейнер m2ts - видимо, релизер хотел сделать проигрываемый блюрей-диск только с фильмом. И мне стало интересно сравнить не только эти два m2ts (с нетронутого блюрея и перепакованный), но и mkv, полученные вручную из них обоих.
Сделал mkv так: в mkvToolNix кинул m2ts файл, ничего не менял, нажал "Start multiplexing", получил mkv-файл из тех же дорожек, что и были в m2ts. Ну и потом распаковал все четыре видеофайла на составляющие с помощью eac3to (-demux).
И оказалось, что вот этот результат моего перегона из m2ts в mkv с помощью mkvToolNix тоже откусил 4 байта от видеопотока! Точно такой же результат, какой был в одном ремуксе mkv, найденном на рутрекере.
MKVToolNix в процессе создания этого mkv не сообщал ни о каких ошибках в конце процесса. Eac3to при обработке видеофайлов (при вытаскивании из них потоков) тоже не сообщал ни о каких ошибках, а также написал одинаковое количество кадров для всех видеофайлов.
Но видеопоток на 4 байта короче.
А также по какой-то причине сильно уменьшились файлы PGS-субтитров при перегоне из M2TS в MKV с помощью MKVToolNix.
Что мне обо всем этом думать? Что происходит?
>>03013
>>03040
Лол, я на всякий случай сохранял в оригинальном ts, хотя проги по умолчанию предлагают преобразовать в mp4
А если при ужатии сразу делать -i video.ts libx265 video.mp4 или аналог в av1, то там все само как надо переделается или лучше сначала сделать -i video.ts -c copy video.mp4 и уже mp4 ужимать?
>>03040
Лол, я на всякий случай сохранял в оригинальном ts, хотя проги по умолчанию предлагают преобразовать в mp4
А если при ужатии сразу делать -i video.ts libx265 video.mp4 или аналог в av1, то там все само как надо переделается или лучше сначала сделать -i video.ts -c copy video.mp4 и уже mp4 ужимать?
>>03274
Стало интересно, что на такое ответит дикпик.
Ваша ситуация действительно интересна и требует детального разбора. Давайте по пунктам разберём возможные причины и последствия наблюдаемых явлений.
---
### 1. 4 байта разницы в видеопотоке
#### Возможные причины:
- NALU-выравнивание в MKV:
Формат Matroska (MKV) может немного модифицировать структуру видеопотока (H.264/H.265), особенно если речь идёт о выравнивании NALU (Network Abstraction Layer Units). Иногда добавляются или удаляются нулевые байты (`00 00 00 01` перед NALU) для корректного размещения в контейнере.
- Если исходный M2TS содержал "лишние" нулевые байты (например, для выравнивания пакетов), MKVToolNix мог их удалить как избыточные.
- Некоторые ремуксеры также могут оптимизировать видеопоток, удаляя технические "артефакты", не влияющие на декодирование.
- Разница в заголовках:
MKV и M2TS по-разному хранят метаданные видеопотока. Например, в MKV может быть изменён `Sequence Parameter Set` (SPS) или `Picture Parameter Set` (PPS), что иногда приводит к небольшой разнице в размере.
- Ошибки в muxing-процессе:
Крайне маловероятно, но теоретически возможны ошибки при перепаковке. Однако если MKVToolNix не выдал ошибок, а eac3to подтвердил идентичное количество кадров, проблема скорее техническая, а не критическая.
#### Проверка:
- Сравните хэши видеопотоков (до и после перепаковки) не целиком, а по NALU:
Используйте `ffprobe -show_frames -i video.h264` (для H.264) или `mediainfo --details video.h265` (для H.265), чтобы убедиться, что структура кадров идентична.
- Если разница только в нулевых байтах или заголовках — это не влияет на качество.
---
### 2. Уменьшение размера PGS-субтитров
#### Возможные причины:
- Удаление пустых сегментов:
PGS (SUP) — это графические субтитры, состоящие из множества сегментов (команд). В оригинальном M2TS они могут содержать "пустые" или избыточные сегменты (например, дублирующиеся команды для синхронизации), которые MKVToolNix удаляет как ненужные.
- Оптимизация времени отображения:
Некоторые инструменты автоматически обрезают субтитры по границам кадров, что может сократить их размер.
- Сжатие в MKV:
Хотя PGS обычно хранятся без сжатия, некоторые муксеры могут применять минимальную оптимизацию.
#### Проверка:
- Откройте оригинальные и перепакованные SUP-файлы в BDSUP2Sub или SubtitleEdit и сравните:
- Количество событий (субтитров).
- Время их появления/исчезновения.
- Графическое содержимое.
- Если визуально разницы нет — проблема исключительно в технической оптимизации.
---
### 3. Выводы и рекомендации
#### Для видеопотока:
- 4 байта — это нестрашно, если:
- Количество кадров совпадает (eac3to это подтвердил).
- Нет артефактов при проигрывании.
- Хэши основных NALU (кроме заголовков) идентичны.
- Что делать?
Если ремукс использует тот же видеопоток (с минимальной правкой), его русскую дорожку можно смело брать. Разница в 4 байта — это погрешность контейнера.
#### Для субтитров:
- Если субтитры отображаются корректно и без задержек, их уменьшенный размер — это результат оптимизации, а не потери данных.
#### Общие советы:
1. Проверяйте целостность:
- Для видео: `ffmpeg -i file.mkv -f null -` (ищите сообщения о corrupt frames).
- Для аудио: `eac3to audio.ac3 verify`.
2. Сравнивайте не только хэши, но и структуру:
- Для видео: `mediainfo --fullscan file.m2ts` и `mediainfo --fullscan file.mkv`.
- Для субтитров: графическое сравнение в SubtitleEdit.
3. Для абсолютной уверенности:
- Если ремукс сделан с того же диска, но видео/аудио потоки имеют минимальные различия (как в вашем случае), это нормально. Контейнеры (M2TS vs MKV) обрабатывают данные по-разному.
---
### Итог:
Ваши наблюдения говорят о технических нюансах перепаковки, а не о проблемах с ремуксами. MKVToolNix и eac3to работают корректно, а разница в 4 байта — это "шум", не влияющий на качество. Субтитры тоже в порядке, если их содержимое не изменилось. Можно смело использовать такие ремуксы!
Стало интересно, что на такое ответит дикпик.
Ваша ситуация действительно интересна и требует детального разбора. Давайте по пунктам разберём возможные причины и последствия наблюдаемых явлений.
---
### 1. 4 байта разницы в видеопотоке
#### Возможные причины:
- NALU-выравнивание в MKV:
Формат Matroska (MKV) может немного модифицировать структуру видеопотока (H.264/H.265), особенно если речь идёт о выравнивании NALU (Network Abstraction Layer Units). Иногда добавляются или удаляются нулевые байты (`00 00 00 01` перед NALU) для корректного размещения в контейнере.
- Если исходный M2TS содержал "лишние" нулевые байты (например, для выравнивания пакетов), MKVToolNix мог их удалить как избыточные.
- Некоторые ремуксеры также могут оптимизировать видеопоток, удаляя технические "артефакты", не влияющие на декодирование.
- Разница в заголовках:
MKV и M2TS по-разному хранят метаданные видеопотока. Например, в MKV может быть изменён `Sequence Parameter Set` (SPS) или `Picture Parameter Set` (PPS), что иногда приводит к небольшой разнице в размере.
- Ошибки в muxing-процессе:
Крайне маловероятно, но теоретически возможны ошибки при перепаковке. Однако если MKVToolNix не выдал ошибок, а eac3to подтвердил идентичное количество кадров, проблема скорее техническая, а не критическая.
#### Проверка:
- Сравните хэши видеопотоков (до и после перепаковки) не целиком, а по NALU:
Используйте `ffprobe -show_frames -i video.h264` (для H.264) или `mediainfo --details video.h265` (для H.265), чтобы убедиться, что структура кадров идентична.
- Если разница только в нулевых байтах или заголовках — это не влияет на качество.
---
### 2. Уменьшение размера PGS-субтитров
#### Возможные причины:
- Удаление пустых сегментов:
PGS (SUP) — это графические субтитры, состоящие из множества сегментов (команд). В оригинальном M2TS они могут содержать "пустые" или избыточные сегменты (например, дублирующиеся команды для синхронизации), которые MKVToolNix удаляет как ненужные.
- Оптимизация времени отображения:
Некоторые инструменты автоматически обрезают субтитры по границам кадров, что может сократить их размер.
- Сжатие в MKV:
Хотя PGS обычно хранятся без сжатия, некоторые муксеры могут применять минимальную оптимизацию.
#### Проверка:
- Откройте оригинальные и перепакованные SUP-файлы в BDSUP2Sub или SubtitleEdit и сравните:
- Количество событий (субтитров).
- Время их появления/исчезновения.
- Графическое содержимое.
- Если визуально разницы нет — проблема исключительно в технической оптимизации.
---
### 3. Выводы и рекомендации
#### Для видеопотока:
- 4 байта — это нестрашно, если:
- Количество кадров совпадает (eac3to это подтвердил).
- Нет артефактов при проигрывании.
- Хэши основных NALU (кроме заголовков) идентичны.
- Что делать?
Если ремукс использует тот же видеопоток (с минимальной правкой), его русскую дорожку можно смело брать. Разница в 4 байта — это погрешность контейнера.
#### Для субтитров:
- Если субтитры отображаются корректно и без задержек, их уменьшенный размер — это результат оптимизации, а не потери данных.
#### Общие советы:
1. Проверяйте целостность:
- Для видео: `ffmpeg -i file.mkv -f null -` (ищите сообщения о corrupt frames).
- Для аудио: `eac3to audio.ac3 verify`.
2. Сравнивайте не только хэши, но и структуру:
- Для видео: `mediainfo --fullscan file.m2ts` и `mediainfo --fullscan file.mkv`.
- Для субтитров: графическое сравнение в SubtitleEdit.
3. Для абсолютной уверенности:
- Если ремукс сделан с того же диска, но видео/аудио потоки имеют минимальные различия (как в вашем случае), это нормально. Контейнеры (M2TS vs MKV) обрабатывают данные по-разному.
---
### Итог:
Ваши наблюдения говорят о технических нюансах перепаковки, а не о проблемах с ремуксами. MKVToolNix и eac3to работают корректно, а разница в 4 байта — это "шум", не влияющий на качество. Субтитры тоже в порядке, если их содержимое не изменилось. Можно смело использовать такие ремуксы!
>>03274
Стало интересно, что на такое ответит дикпик.
Ваша ситуация действительно интересна и требует детального разбора. Давайте по пунктам разберём возможные причины и последствия наблюдаемых явлений.
---
### 1. 4 байта разницы в видеопотоке
#### Возможные причины:
- NALU-выравнивание в MKV:
Формат Matroska (MKV) может немного модифицировать структуру видеопотока (H.264/H.265), особенно если речь идёт о выравнивании NALU (Network Abstraction Layer Units). Иногда добавляются или удаляются нулевые байты (`00 00 00 01` перед NALU) для корректного размещения в контейнере.
- Если исходный M2TS содержал "лишние" нулевые байты (например, для выравнивания пакетов), MKVToolNix мог их удалить как избыточные.
- Некоторые ремуксеры также могут оптимизировать видеопоток, удаляя технические "артефакты", не влияющие на декодирование.
- Разница в заголовках:
MKV и M2TS по-разному хранят метаданные видеопотока. Например, в MKV может быть изменён `Sequence Parameter Set` (SPS) или `Picture Parameter Set` (PPS), что иногда приводит к небольшой разнице в размере.
- Ошибки в muxing-процессе:
Крайне маловероятно, но теоретически возможны ошибки при перепаковке. Однако если MKVToolNix не выдал ошибок, а eac3to подтвердил идентичное количество кадров, проблема скорее техническая, а не критическая.
#### Проверка:
- Сравните хэши видеопотоков (до и после перепаковки) не целиком, а по NALU:
Используйте `ffprobe -show_frames -i video.h264` (для H.264) или `mediainfo --details video.h265` (для H.265), чтобы убедиться, что структура кадров идентична.
- Если разница только в нулевых байтах или заголовках — это не влияет на качество.
---
### 2. Уменьшение размера PGS-субтитров
#### Возможные причины:
- Удаление пустых сегментов:
PGS (SUP) — это графические субтитры, состоящие из множества сегментов (команд). В оригинальном M2TS они могут содержать "пустые" или избыточные сегменты (например, дублирующиеся команды для синхронизации), которые MKVToolNix удаляет как ненужные.
- Оптимизация времени отображения:
Некоторые инструменты автоматически обрезают субтитры по границам кадров, что может сократить их размер.
- Сжатие в MKV:
Хотя PGS обычно хранятся без сжатия, некоторые муксеры могут применять минимальную оптимизацию.
#### Проверка:
- Откройте оригинальные и перепакованные SUP-файлы в BDSUP2Sub или SubtitleEdit и сравните:
- Количество событий (субтитров).
- Время их появления/исчезновения.
- Графическое содержимое.
- Если визуально разницы нет — проблема исключительно в технической оптимизации.
---
### 3. Выводы и рекомендации
#### Для видеопотока:
- 4 байта — это нестрашно, если:
- Количество кадров совпадает (eac3to это подтвердил).
- Нет артефактов при проигрывании.
- Хэши основных NALU (кроме заголовков) идентичны.
- Что делать?
Если ремукс использует тот же видеопоток (с минимальной правкой), его русскую дорожку можно смело брать. Разница в 4 байта — это погрешность контейнера.
#### Для субтитров:
- Если субтитры отображаются корректно и без задержек, их уменьшенный размер — это результат оптимизации, а не потери данных.
#### Общие советы:
1. Проверяйте целостность:
- Для видео: `ffmpeg -i file.mkv -f null -` (ищите сообщения о corrupt frames).
- Для аудио: `eac3to audio.ac3 verify`.
2. Сравнивайте не только хэши, но и структуру:
- Для видео: `mediainfo --fullscan file.m2ts` и `mediainfo --fullscan file.mkv`.
- Для субтитров: графическое сравнение в SubtitleEdit.
3. Для абсолютной уверенности:
- Если ремукс сделан с того же диска, но видео/аудио потоки имеют минимальные различия (как в вашем случае), это нормально. Контейнеры (M2TS vs MKV) обрабатывают данные по-разному.
---
### Итог:
Ваши наблюдения говорят о технических нюансах перепаковки, а не о проблемах с ремуксами. MKVToolNix и eac3to работают корректно, а разница в 4 байта — это "шум", не влияющий на качество. Субтитры тоже в порядке, если их содержимое не изменилось. Можно смело использовать такие ремуксы!
Стало интересно, что на такое ответит дикпик.
Ваша ситуация действительно интересна и требует детального разбора. Давайте по пунктам разберём возможные причины и последствия наблюдаемых явлений.
---
### 1. 4 байта разницы в видеопотоке
#### Возможные причины:
- NALU-выравнивание в MKV:
Формат Matroska (MKV) может немного модифицировать структуру видеопотока (H.264/H.265), особенно если речь идёт о выравнивании NALU (Network Abstraction Layer Units). Иногда добавляются или удаляются нулевые байты (`00 00 00 01` перед NALU) для корректного размещения в контейнере.
- Если исходный M2TS содержал "лишние" нулевые байты (например, для выравнивания пакетов), MKVToolNix мог их удалить как избыточные.
- Некоторые ремуксеры также могут оптимизировать видеопоток, удаляя технические "артефакты", не влияющие на декодирование.
- Разница в заголовках:
MKV и M2TS по-разному хранят метаданные видеопотока. Например, в MKV может быть изменён `Sequence Parameter Set` (SPS) или `Picture Parameter Set` (PPS), что иногда приводит к небольшой разнице в размере.
- Ошибки в muxing-процессе:
Крайне маловероятно, но теоретически возможны ошибки при перепаковке. Однако если MKVToolNix не выдал ошибок, а eac3to подтвердил идентичное количество кадров, проблема скорее техническая, а не критическая.
#### Проверка:
- Сравните хэши видеопотоков (до и после перепаковки) не целиком, а по NALU:
Используйте `ffprobe -show_frames -i video.h264` (для H.264) или `mediainfo --details video.h265` (для H.265), чтобы убедиться, что структура кадров идентична.
- Если разница только в нулевых байтах или заголовках — это не влияет на качество.
---
### 2. Уменьшение размера PGS-субтитров
#### Возможные причины:
- Удаление пустых сегментов:
PGS (SUP) — это графические субтитры, состоящие из множества сегментов (команд). В оригинальном M2TS они могут содержать "пустые" или избыточные сегменты (например, дублирующиеся команды для синхронизации), которые MKVToolNix удаляет как ненужные.
- Оптимизация времени отображения:
Некоторые инструменты автоматически обрезают субтитры по границам кадров, что может сократить их размер.
- Сжатие в MKV:
Хотя PGS обычно хранятся без сжатия, некоторые муксеры могут применять минимальную оптимизацию.
#### Проверка:
- Откройте оригинальные и перепакованные SUP-файлы в BDSUP2Sub или SubtitleEdit и сравните:
- Количество событий (субтитров).
- Время их появления/исчезновения.
- Графическое содержимое.
- Если визуально разницы нет — проблема исключительно в технической оптимизации.
---
### 3. Выводы и рекомендации
#### Для видеопотока:
- 4 байта — это нестрашно, если:
- Количество кадров совпадает (eac3to это подтвердил).
- Нет артефактов при проигрывании.
- Хэши основных NALU (кроме заголовков) идентичны.
- Что делать?
Если ремукс использует тот же видеопоток (с минимальной правкой), его русскую дорожку можно смело брать. Разница в 4 байта — это погрешность контейнера.
#### Для субтитров:
- Если субтитры отображаются корректно и без задержек, их уменьшенный размер — это результат оптимизации, а не потери данных.
#### Общие советы:
1. Проверяйте целостность:
- Для видео: `ffmpeg -i file.mkv -f null -` (ищите сообщения о corrupt frames).
- Для аудио: `eac3to audio.ac3 verify`.
2. Сравнивайте не только хэши, но и структуру:
- Для видео: `mediainfo --fullscan file.m2ts` и `mediainfo --fullscan file.mkv`.
- Для субтитров: графическое сравнение в SubtitleEdit.
3. Для абсолютной уверенности:
- Если ремукс сделан с того же диска, но видео/аудио потоки имеют минимальные различия (как в вашем случае), это нормально. Контейнеры (M2TS vs MKV) обрабатывают данные по-разному.
---
### Итог:
Ваши наблюдения говорят о технических нюансах перепаковки, а не о проблемах с ремуксами. MKVToolNix и eac3to работают корректно, а разница в 4 байта — это "шум", не влияющий на качество. Субтитры тоже в порядке, если их содержимое не изменилось. Можно смело использовать такие ремуксы!
>>03280
Сразу кодируй в нужный формат.
Сразу кодируй в нужный формат.
Всю жизнь нужен был самый простой софт чтобы быстренько обрезать и перекодировать mkv в mp4 для закидывания в премьер.
Наконец дошли руки до FFmpeg но в итоге получивший mp4 премьер нихуя не видит. Не в первый раз уже проблема такая.
Наконец дошли руки до FFmpeg но в итоге получивший mp4 премьер нихуя не видит. Не в первый раз уже проблема такая.
>>05013
Так возьми документацию по премьеру. Разберись, что от mp4 премьер ожидает. Какую версию контейнера, какие кодеки допустимы. Но я бы попобовал прикрктить к премьеру avisynth+64, и уже через него использовать ffmpeg (в виде ffms2).
>Не в первый раз уже проблема такая.
Так возьми документацию по премьеру. Разберись, что от mp4 премьер ожидает. Какую версию контейнера, какие кодеки допустимы. Но я бы попобовал прикрктить к премьеру avisynth+64, и уже через него использовать ffmpeg (в виде ffms2).
В каком контейнере хранить музыку в кодеках aac и opus для прослушивания без видео? Он вообще нужен?
4,3 Мб, mp4,512x512, 4:23
>>06222
ffmpeg -i Input.mp3 -map_metadata -1 -c:a libopus -b:a 128k Output.opus
-map_metadata -1 - чистит метаданные, убери если не нужно.
В mp4 с картинкой в 1 FPS:
ffmpeg -framerate 1/X -i Img.jpg -i Input.mp3 -map_metadata -1 -c:v libx264 -r 1 -c:a libopus -b:a 128k Output.mp4
-framerate 1/X - вместо Х длительность трека в секундах.
В mp4 без картинки:
ffmpeg -vn -i Input.mp3 -c:a libopus -b:a 128k Output.mp4
-vn потому что ругался на разрешение прикрепленной к mp3 картинки.
mp4 без видео и opus на двощ не постятся.
ffmpeg -i Input.mp3 -map_metadata -1 -c:a libopus -b:a 128k Output.opus
-map_metadata -1 - чистит метаданные, убери если не нужно.
В mp4 с картинкой в 1 FPS:
ffmpeg -framerate 1/X -i Img.jpg -i Input.mp3 -map_metadata -1 -c:v libx264 -r 1 -c:a libopus -b:a 128k Output.mp4
-framerate 1/X - вместо Х длительность трека в секундах.
В mp4 без картинки:
ffmpeg -vn -i Input.mp3 -c:a libopus -b:a 128k Output.mp4
-vn потому что ругался на разрешение прикрепленной к mp3 картинки.
mp4 без видео и opus на двощ не постятся.
>>06465
Оо ты то мне и нужен
А как помимо этого ещё и выбрать интервал из трека\обрезать его?
Я так делал
ffmpeg -r 1 -loop 1 ^
-i "pic.jpg" ^
-i "song.mp3" -ss 01:10 -t 20 ^
-vb 6M -crf 18 -quality best -g 360 -q:a 2 ^
-y -shortest "out.mp4"
Без добавления -ss нормально всё, но с этим параметром получается какое-то наложения этого вырезанного участка поверх всего трека, выходит странный файл весом 1мб (трек 10мб) который нормально играется всю продолжительность wtf?
Оо ты то мне и нужен
А как помимо этого ещё и выбрать интервал из трека\обрезать его?
Я так делал
ffmpeg -r 1 -loop 1 ^
-i "pic.jpg" ^
-i "song.mp3" -ss 01:10 -t 20 ^
-vb 6M -crf 18 -quality best -g 360 -q:a 2 ^
-y -shortest "out.mp4"
Без добавления -ss нормально всё, но с этим параметром получается какое-то наложения этого вырезанного участка поверх всего трека, выходит странный файл весом 1мб (трек 10мб) который нормально играется всю продолжительность wtf?
5,4 Мб, mp4,512x512, 5:42
>>06476
Вот такой батник. Сначала вырезаем нужный кусок, потом лепим картинку + копируем аудио без перекодирования, удаляем промежуточный аудиофайл.
Соответственно Х - длительность вырезаемого куска.
>ffmpeg -vn -ss 01:03 -t Х -i Input.mp3 -map_metadata -1 -c:a libopus -b:a 128k Out.opus
>ffmpeg -framerate 1/Х -i Img.jpg -i Out.opus -c:v libx264 -r 1 -c:a copy Output.mp4
>del Out.opus
Вот такой батник. Сначала вырезаем нужный кусок, потом лепим картинку + копируем аудио без перекодирования, удаляем промежуточный аудиофайл.
Соответственно Х - длительность вырезаемого куска.
Кодирую процом в HandBrake...
Даст ли сильный выйгрыш в скорости кодирование одного и того-же ролика с теми-же параметрами напрямую через ffmpeg?
Даст ли сильный выйгрыш в скорости кодирование одного и того-же ролика с теми-же параметрами напрямую через ffmpeg?
>>08628
Нет, но
Кодируй не с теми же.
В ффмпеге их определённо больше, там настроить что-нибудь сможешь чтобы ускорить. Количество ядер например твой гуй умеет выставлять?
Нет, но
> с теми-же параметрами
Кодируй не с теми же.
В ффмпеге их определённо больше, там настроить что-нибудь сможешь чтобы ускорить. Количество ядер например твой гуй умеет выставлять?
39,5 Мб, webm,1920x872, 11:03
Насколько шакально смотрится это видео на разрешениях экрана выше 1920х1080?
>>09170
-c:a copy
-c:a copy
>>01478
Если по какой-то причине кому-то нужно использовать древние кодеки и даже не x264, то лучше mpeg4 (xvid). -c:v mpeg4 -qmin:v 1 -q:v 1 будет вижуалли лосслесс (алмоуст). Mpeg2 хуже даже с единицей - если приглядеться это заметно.
И использовать для этого либо mp4, либо mkv контейнеры - в них флаги колорспейса сохраняются если были изначально выставлены, а в ts и avi проебываются если кодек mpeg4.
Только нахуя? Тот же x264 при -crf 18 (считается visually lossless), или вообще -crf 15, с пресетом veryfast будет весить меньше mpeg4.
>чтобы всё в лослесс хранить на кодеке mpeg2
Если по какой-то причине кому-то нужно использовать древние кодеки и даже не x264, то лучше mpeg4 (xvid). -c:v mpeg4 -qmin:v 1 -q:v 1 будет вижуалли лосслесс (алмоуст). Mpeg2 хуже даже с единицей - если приглядеться это заметно.
И использовать для этого либо mp4, либо mkv контейнеры - в них флаги колорспейса сохраняются если были изначально выставлены, а в ts и avi проебываются если кодек mpeg4.
Только нахуя? Тот же x264 при -crf 18 (считается visually lossless), или вообще -crf 15, с пресетом veryfast будет весить меньше mpeg4.
>>09892
Около 80 минут. Но надо понимать что у меня старый двухядерный процессор, поддерживающий максимум SSE 4.2. Любой более менее современный процессор с 4+ ядрами и поддержкой хотя бы AVX2 (а в идеале AVX-512) справится в разы быстрее.
Я чисто ради эксперимента попробовал закодировать какое-нибудь видео, из тех что я делал в 720p, в большем разрешении практически без повышения битрейта и несколько удивлен тому что заметного падения качества не происходит. Вот старое >>3600870 → для сравнения.
Около 80 минут. Но надо понимать что у меня старый двухядерный процессор, поддерживающий максимум SSE 4.2. Любой более менее современный процессор с 4+ ядрами и поддержкой хотя бы AVX2 (а в идеале AVX-512) справится в разы быстрее.
Я чисто ради эксперимента попробовал закодировать какое-нибудь видео, из тех что я делал в 720p, в большем разрешении практически без повышения битрейта и несколько удивлен тому что заметного падения качества не происходит. Вот старое >>3600870 → для сравнения.
>>09989
Обобщённо говорят, что у новых кодеков степень сжатия повышается с повышением разрешения.
Обобщённо говорят, что у новых кодеков степень сжатия повышается с повышением разрешения.
У меня есть видео, у которых звук со временем начинает отставать от картинки, хотя при этом, если перемотать ролик вперед, то звук подстраивается к видео, но через какое-то время опять начинает отставать. В чем тут проблема? Как можно исправить?
>>10108
Эта проблема может быть связана с рассинхронизацией временных меток (timestamps) аудио и видео, особенностями переменного кадра (VFR) или несовершенной обработкой временной шкалы в контейнере. Ниже приведены несколько способов, как можно попробовать исправить проблему с помощью ffmpeg.
1. Перекодировать аудио с опцией синхронизации (-async):
Если нужно перегенерировать аудио так, чтобы временные метки корректно соответствовали видео, можно попробовать опцию -async. Например:
ffmpeg -i input.mp4 -c:v copy -c:a aac -async 1 output.mp4
Эта команда копирует видеопоток без перекодирования, а аудиопоток перекодирует в формат AAC с автоматической корректировкой временных меток.
2. Применить опцию -vsync:
Если проблема связана с переменным fps, стоит попробовать использовать корректировку синхронизации видео. Например:
ffmpeg -i input.mp4 -c:a copy -c:v libx264 -vsync 1 output.mp4
Здесь аудио копируется без изменений, а видео перекодируется с синхронизацией временных меток.
3. Пересчитать временные метки вручную:
Иногда помогает явное указание опций для аудиодекодера. Например, можно попробовать так:
ffmpeg -i input.mp4 -c:v copy -af aresample=async=1 output.mp4
Здесь с помощью фильтра aresample с параметром async происходит выравнивание аудио по временной шкале.
4. Если источник имеет переменный фреймрейт:
Попробуйте перекодировать видео с постоянным fps, указывая, например:
ffmpeg -i input.mp4 -r 30 -c:a copy -c:v libx264 output.mp4
Это может помочь, если проблема возникает из-за переменного fps.
Обратите внимание:
- Экспериментируйте с комбинациями опций, так как конкретное решение зависит от особенностей исходного файла.
- Если возможно, попробуйте сначала проанализировать входной файл (например, с помощью команды ffprobe) и посмотреть, какие параметры аудио и видео там установлены.
Таким образом, используя ffmpeg можно попробовать исправить рассинхронизацию путем корректировки временных меток аудио (через -async или фильтр aresample), синхронизации видео (-vsync) или перекодирования с принудительным указанием fps.
Эта проблема может быть связана с рассинхронизацией временных меток (timestamps) аудио и видео, особенностями переменного кадра (VFR) или несовершенной обработкой временной шкалы в контейнере. Ниже приведены несколько способов, как можно попробовать исправить проблему с помощью ffmpeg.
1. Перекодировать аудио с опцией синхронизации (-async):
Если нужно перегенерировать аудио так, чтобы временные метки корректно соответствовали видео, можно попробовать опцию -async. Например:
ffmpeg -i input.mp4 -c:v copy -c:a aac -async 1 output.mp4
Эта команда копирует видеопоток без перекодирования, а аудиопоток перекодирует в формат AAC с автоматической корректировкой временных меток.
2. Применить опцию -vsync:
Если проблема связана с переменным fps, стоит попробовать использовать корректировку синхронизации видео. Например:
ffmpeg -i input.mp4 -c:a copy -c:v libx264 -vsync 1 output.mp4
Здесь аудио копируется без изменений, а видео перекодируется с синхронизацией временных меток.
3. Пересчитать временные метки вручную:
Иногда помогает явное указание опций для аудиодекодера. Например, можно попробовать так:
ffmpeg -i input.mp4 -c:v copy -af aresample=async=1 output.mp4
Здесь с помощью фильтра aresample с параметром async происходит выравнивание аудио по временной шкале.
4. Если источник имеет переменный фреймрейт:
Попробуйте перекодировать видео с постоянным fps, указывая, например:
ffmpeg -i input.mp4 -r 30 -c:a copy -c:v libx264 output.mp4
Это может помочь, если проблема возникает из-за переменного fps.
Обратите внимание:
- Экспериментируйте с комбинациями опций, так как конкретное решение зависит от особенностей исходного файла.
- Если возможно, попробуйте сначала проанализировать входной файл (например, с помощью команды ffprobe) и посмотреть, какие параметры аудио и видео там установлены.
Таким образом, используя ffmpeg можно попробовать исправить рассинхронизацию путем корректировки временных меток аудио (через -async или фильтр aresample), синхронизации видео (-vsync) или перекодирования с принудительным указанием fps.
>>10108
Эта проблема может быть связана с рассинхронизацией временных меток (timestamps) аудио и видео, особенностями переменного кадра (VFR) или несовершенной обработкой временной шкалы в контейнере. Ниже приведены несколько способов, как можно попробовать исправить проблему с помощью ffmpeg.
1. Перекодировать аудио с опцией синхронизации (-async):
Если нужно перегенерировать аудио так, чтобы временные метки корректно соответствовали видео, можно попробовать опцию -async. Например:
ffmpeg -i input.mp4 -c:v copy -c:a aac -async 1 output.mp4
Эта команда копирует видеопоток без перекодирования, а аудиопоток перекодирует в формат AAC с автоматической корректировкой временных меток.
2. Применить опцию -vsync:
Если проблема связана с переменным fps, стоит попробовать использовать корректировку синхронизации видео. Например:
ffmpeg -i input.mp4 -c:a copy -c:v libx264 -vsync 1 output.mp4
Здесь аудио копируется без изменений, а видео перекодируется с синхронизацией временных меток.
3. Пересчитать временные метки вручную:
Иногда помогает явное указание опций для аудиодекодера. Например, можно попробовать так:
ffmpeg -i input.mp4 -c:v copy -af aresample=async=1 output.mp4
Здесь с помощью фильтра aresample с параметром async происходит выравнивание аудио по временной шкале.
4. Если источник имеет переменный фреймрейт:
Попробуйте перекодировать видео с постоянным fps, указывая, например:
ffmpeg -i input.mp4 -r 30 -c:a copy -c:v libx264 output.mp4
Это может помочь, если проблема возникает из-за переменного fps.
Обратите внимание:
- Экспериментируйте с комбинациями опций, так как конкретное решение зависит от особенностей исходного файла.
- Если возможно, попробуйте сначала проанализировать входной файл (например, с помощью команды ffprobe) и посмотреть, какие параметры аудио и видео там установлены.
Таким образом, используя ffmpeg можно попробовать исправить рассинхронизацию путем корректировки временных меток аудио (через -async или фильтр aresample), синхронизации видео (-vsync) или перекодирования с принудительным указанием fps.
Эта проблема может быть связана с рассинхронизацией временных меток (timestamps) аудио и видео, особенностями переменного кадра (VFR) или несовершенной обработкой временной шкалы в контейнере. Ниже приведены несколько способов, как можно попробовать исправить проблему с помощью ffmpeg.
1. Перекодировать аудио с опцией синхронизации (-async):
Если нужно перегенерировать аудио так, чтобы временные метки корректно соответствовали видео, можно попробовать опцию -async. Например:
ffmpeg -i input.mp4 -c:v copy -c:a aac -async 1 output.mp4
Эта команда копирует видеопоток без перекодирования, а аудиопоток перекодирует в формат AAC с автоматической корректировкой временных меток.
2. Применить опцию -vsync:
Если проблема связана с переменным fps, стоит попробовать использовать корректировку синхронизации видео. Например:
ffmpeg -i input.mp4 -c:a copy -c:v libx264 -vsync 1 output.mp4
Здесь аудио копируется без изменений, а видео перекодируется с синхронизацией временных меток.
3. Пересчитать временные метки вручную:
Иногда помогает явное указание опций для аудиодекодера. Например, можно попробовать так:
ffmpeg -i input.mp4 -c:v copy -af aresample=async=1 output.mp4
Здесь с помощью фильтра aresample с параметром async происходит выравнивание аудио по временной шкале.
4. Если источник имеет переменный фреймрейт:
Попробуйте перекодировать видео с постоянным fps, указывая, например:
ffmpeg -i input.mp4 -r 30 -c:a copy -c:v libx264 output.mp4
Это может помочь, если проблема возникает из-за переменного fps.
Обратите внимание:
- Экспериментируйте с комбинациями опций, так как конкретное решение зависит от особенностей исходного файла.
- Если возможно, попробуйте сначала проанализировать входной файл (например, с помощью команды ffprobe) и посмотреть, какие параметры аудио и видео там установлены.
Таким образом, используя ffmpeg можно попробовать исправить рассинхронизацию путем корректировки временных меток аудио (через -async или фильтр aresample), синхронизации видео (-vsync) или перекодирования с принудительным указанием fps.
>>09989
Ужал 1080p c твоими параметрами, вес стал почти в 2 раза меньше, качество едва ухудшилось. Просто охуенно.
Есть много 1080p и 720p, которые необходимо сжать, где-то нужно максимальное качество, а где-то минимальный вес при приемлимом качестве. Чтобы разобраться когда и какие параметры использовать, как вообще это все устроено, нужно просто проштудировать все это https://www.ffmpeg.org/ffmpeg-all.html ?
Ужал 1080p c твоими параметрами, вес стал почти в 2 раза меньше, качество едва ухудшилось. Просто охуенно.
Есть много 1080p и 720p, которые необходимо сжать, где-то нужно максимальное качество, а где-то минимальный вес при приемлимом качестве. Чтобы разобраться когда и какие параметры использовать, как вообще это все устроено, нужно просто проштудировать все это https://www.ffmpeg.org/ffmpeg-all.html ?
>>10230
Там буквально парочка параметров, которые полностью меняют соотношение вес/время/качество и которых достаточно рядовому юзверю. Остальное – пердолинг ради незначительных процентов.
Там буквально парочка параметров, которые полностью меняют соотношение вес/время/качество и которых достаточно рядовому юзверю. Остальное – пердолинг ради незначительных процентов.
39,9 Мб, webm,1920x800, 5:40
>>10230
Поэкспериментируй, вероятно можно и лучше. Вот это видео было ужато в 6-6.5 раз.
Все это тебе не нужно, параметры FFmpeg это преимущественно различные манипуляции с видео вроде вырезаня куска видео, обрезания кадров, склейки нескольких видео в одно и т.д.
Непосредственно на кодирование влияют параметры кодека
https://trac.ffmpeg.org/wiki/Encode/H.264
https://trac.ffmpeg.org/wiki/Encode/H.265
https://trac.ffmpeg.org/wiki/Encode/AV1
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md
Если взять конкретно SVT-AV1 которым я пользуюсь - я довольно много экспериментировал с параметрами и большинство из них ухудшали эффективность сжатия (оценка VMAF для заданного битрейта) на значениях отличных от дефолтных. Поэтому я оставил только те что давали улучшение на всех тестовых видео.
enable-qm=1:qm-min=0:qm-max=8 - повышает эффективность сжатия за счет небольшого падения скорости кодирования.
irefresh-type=1 - повышает эффективность сжатия и несколько сглаживает график VMAF за счет падения скорости перемотки видео (кратковременное зависание при установке ползунка в любую точку видео, чем дальше от начала тем дольше). Для моих задач минусы незначимы.
keyint=0 - снимает ограничение на размер GoP (только для режима CRF) что повышает эффективность сжатия в ряде случаев. Для динамичных видео эффект околонулевой, если много статичных сцен - сопоставим с irefresh-type=1. Минусов не заметил.
Опционально можно еще добавить tune=0 - немного поднимает средний VMAF, но мне не понравилось влияние на график для некоторых тестовых видео (улучшал там где и так все хорошо, но усиливал просадки на участках где все не очень).
По сути тебе остается играться со значением -crf (1-63, но мне всегда хватало диапазона 20-48, чем ниже - тем выше битрейт и, соответственно, качество) и выбрать приемлимый по скорости пресет -preset (1-13, чем выше - тем быстрее кодирует, но шакальнее и с худшим сжатием).
Рекомендую выбирать между пресетами 2, 4 и 5. Я использую пятый (четвертый для самых коротких видео) потому что процессор говно, четвертый дает чуть лучшее качество и сжатие, но вдвое медленнее. Второй совсем медленный, но выдает еще лучшие результаты.
>вес стал почти в 2 раза меньше, качество едва ухудшилось
Поэкспериментируй, вероятно можно и лучше. Вот это видео было ужато в 6-6.5 раз.
>Чтобы разобраться когда и какие параметры использовать, как вообще это все устроено, нужно просто
Все это тебе не нужно, параметры FFmpeg это преимущественно различные манипуляции с видео вроде вырезаня куска видео, обрезания кадров, склейки нескольких видео в одно и т.д.
Непосредственно на кодирование влияют параметры кодека
https://trac.ffmpeg.org/wiki/Encode/H.264
https://trac.ffmpeg.org/wiki/Encode/H.265
https://trac.ffmpeg.org/wiki/Encode/AV1
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md
Если взять конкретно SVT-AV1 которым я пользуюсь - я довольно много экспериментировал с параметрами и большинство из них ухудшали эффективность сжатия (оценка VMAF для заданного битрейта) на значениях отличных от дефолтных. Поэтому я оставил только те что давали улучшение на всех тестовых видео.
enable-qm=1:qm-min=0:qm-max=8 - повышает эффективность сжатия за счет небольшого падения скорости кодирования.
irefresh-type=1 - повышает эффективность сжатия и несколько сглаживает график VMAF за счет падения скорости перемотки видео (кратковременное зависание при установке ползунка в любую точку видео, чем дальше от начала тем дольше). Для моих задач минусы незначимы.
keyint=0 - снимает ограничение на размер GoP (только для режима CRF) что повышает эффективность сжатия в ряде случаев. Для динамичных видео эффект околонулевой, если много статичных сцен - сопоставим с irefresh-type=1. Минусов не заметил.
Опционально можно еще добавить tune=0 - немного поднимает средний VMAF, но мне не понравилось влияние на график для некоторых тестовых видео (улучшал там где и так все хорошо, но усиливал просадки на участках где все не очень).
>где-то нужно максимальное качество, а где-то минимальный вес при приемлимом качестве
По сути тебе остается играться со значением -crf (1-63, но мне всегда хватало диапазона 20-48, чем ниже - тем выше битрейт и, соответственно, качество) и выбрать приемлимый по скорости пресет -preset (1-13, чем выше - тем быстрее кодирует, но шакальнее и с худшим сжатием).
Рекомендую выбирать между пресетами 2, 4 и 5. Я использую пятый (четвертый для самых коротких видео) потому что процессор говно, четвертый дает чуть лучшее качество и сжатие, но вдвое медленнее. Второй совсем медленный, но выдает еще лучшие результаты.
39,9 Мб, webm,1920x800, 5:40
>>10230
Поэкспериментируй, вероятно можно и лучше. Вот это видео было ужато в 6-6.5 раз.
Все это тебе не нужно, параметры FFmpeg это преимущественно различные манипуляции с видео вроде вырезаня куска видео, обрезания кадров, склейки нескольких видео в одно и т.д.
Непосредственно на кодирование влияют параметры кодека
https://trac.ffmpeg.org/wiki/Encode/H.264
https://trac.ffmpeg.org/wiki/Encode/H.265
https://trac.ffmpeg.org/wiki/Encode/AV1
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md
Если взять конкретно SVT-AV1 которым я пользуюсь - я довольно много экспериментировал с параметрами и большинство из них ухудшали эффективность сжатия (оценка VMAF для заданного битрейта) на значениях отличных от дефолтных. Поэтому я оставил только те что давали улучшение на всех тестовых видео.
enable-qm=1:qm-min=0:qm-max=8 - повышает эффективность сжатия за счет небольшого падения скорости кодирования.
irefresh-type=1 - повышает эффективность сжатия и несколько сглаживает график VMAF за счет падения скорости перемотки видео (кратковременное зависание при установке ползунка в любую точку видео, чем дальше от начала тем дольше). Для моих задач минусы незначимы.
keyint=0 - снимает ограничение на размер GoP (только для режима CRF) что повышает эффективность сжатия в ряде случаев. Для динамичных видео эффект околонулевой, если много статичных сцен - сопоставим с irefresh-type=1. Минусов не заметил.
Опционально можно еще добавить tune=0 - немного поднимает средний VMAF, но мне не понравилось влияние на график для некоторых тестовых видео (улучшал там где и так все хорошо, но усиливал просадки на участках где все не очень).
По сути тебе остается играться со значением -crf (1-63, но мне всегда хватало диапазона 20-48, чем ниже - тем выше битрейт и, соответственно, качество) и выбрать приемлимый по скорости пресет -preset (1-13, чем выше - тем быстрее кодирует, но шакальнее и с худшим сжатием).
Рекомендую выбирать между пресетами 2, 4 и 5. Я использую пятый (четвертый для самых коротких видео) потому что процессор говно, четвертый дает чуть лучшее качество и сжатие, но вдвое медленнее. Второй совсем медленный, но выдает еще лучшие результаты.
>вес стал почти в 2 раза меньше, качество едва ухудшилось
Поэкспериментируй, вероятно можно и лучше. Вот это видео было ужато в 6-6.5 раз.
>Чтобы разобраться когда и какие параметры использовать, как вообще это все устроено, нужно просто
Все это тебе не нужно, параметры FFmpeg это преимущественно различные манипуляции с видео вроде вырезаня куска видео, обрезания кадров, склейки нескольких видео в одно и т.д.
Непосредственно на кодирование влияют параметры кодека
https://trac.ffmpeg.org/wiki/Encode/H.264
https://trac.ffmpeg.org/wiki/Encode/H.265
https://trac.ffmpeg.org/wiki/Encode/AV1
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md
Если взять конкретно SVT-AV1 которым я пользуюсь - я довольно много экспериментировал с параметрами и большинство из них ухудшали эффективность сжатия (оценка VMAF для заданного битрейта) на значениях отличных от дефолтных. Поэтому я оставил только те что давали улучшение на всех тестовых видео.
enable-qm=1:qm-min=0:qm-max=8 - повышает эффективность сжатия за счет небольшого падения скорости кодирования.
irefresh-type=1 - повышает эффективность сжатия и несколько сглаживает график VMAF за счет падения скорости перемотки видео (кратковременное зависание при установке ползунка в любую точку видео, чем дальше от начала тем дольше). Для моих задач минусы незначимы.
keyint=0 - снимает ограничение на размер GoP (только для режима CRF) что повышает эффективность сжатия в ряде случаев. Для динамичных видео эффект околонулевой, если много статичных сцен - сопоставим с irefresh-type=1. Минусов не заметил.
Опционально можно еще добавить tune=0 - немного поднимает средний VMAF, но мне не понравилось влияние на график для некоторых тестовых видео (улучшал там где и так все хорошо, но усиливал просадки на участках где все не очень).
>где-то нужно максимальное качество, а где-то минимальный вес при приемлимом качестве
По сути тебе остается играться со значением -crf (1-63, но мне всегда хватало диапазона 20-48, чем ниже - тем выше битрейт и, соответственно, качество) и выбрать приемлимый по скорости пресет -preset (1-13, чем выше - тем быстрее кодирует, но шакальнее и с худшим сжатием).
Рекомендую выбирать между пресетами 2, 4 и 5. Я использую пятый (четвертый для самых коротких видео) потому что процессор говно, четвертый дает чуть лучшее качество и сжатие, но вдвое медленнее. Второй совсем медленный, но выдает еще лучшие результаты.
39,9 Мб, webm,1920x800, 16:15
Ну и еще отмечу что по ощущениям преимущественно темные видео сжимаются лучше. Вот это ужималось с ~550Мб, вроде не так плохо вышло.
>>10410
Ладно, хром иногда расчехляется за 10-20 секунд, в mpv только звук продолжает играть, а видео зависает намертво. В логах можно видеть сообщения:
В нормально сделанных вебмках такого нет.
Хотел оценить уровень мыла, впрочем и по первым кадрам можно видеть.
> Начнем с того что они проматываются.
Ладно, хром иногда расчехляется за 10-20 секунд, в mpv только звук продолжает играть, а видео зависает намертво. В логах можно видеть сообщения:
> [cplayer] video EOF (status=4)
В нормально сделанных вебмках такого нет.
> Закончим на том что их не нужно проматывать.
Хотел оценить уровень мыла, впрочем и по первым кадрам можно видеть.
>>10440
Не иногда, а всегда. Вопрос только во времени ожидания, которое пропорционально числу проматываемых кадров от начала видео. Но это все не имеет никакого значения потому что перематывать просто не нужно. Включаешь и смотришь. Если не интересно - выключаешь.
Макака дает мне 40Мб и я запихиваю туда столько качества сколько могу. Заплатить ненужной в данном случае перемоткой за немного лучшее качество - это легкий выбор.
Ну ты учитывай что видео ужато в 6.5 в 7.5 раз относительно оригинала, который тоже наверняка предварительно был сжат. Я не могу оценить уже сделанное видео потому что не помню с какого кадра обрезал, но вот этот кусок ужатый с 9319kbs до 1345kbs на тех же настройках показывает 90 VMAF. По моему приемлимо. Ну и качество оригинала можешь заодно оценить.
>иногда расчехляется
Не иногда, а всегда. Вопрос только во времени ожидания, которое пропорционально числу проматываемых кадров от начала видео. Но это все не имеет никакого значения потому что перематывать просто не нужно. Включаешь и смотришь. Если не интересно - выключаешь.
Макака дает мне 40Мб и я запихиваю туда столько качества сколько могу. Заплатить ненужной в данном случае перемоткой за немного лучшее качество - это легкий выбор.
>Хотел оценить уровень мыла
Ну ты учитывай что видео ужато в 6.5 в 7.5 раз относительно оригинала, который тоже наверняка предварительно был сжат. Я не могу оценить уже сделанное видео потому что не помню с какого кадра обрезал, но вот этот кусок ужатый с 9319kbs до 1345kbs на тех же настройках показывает 90 VMAF. По моему приемлимо. Ну и качество оригинала можешь заодно оценить.
2,8 Мб, mp4,480x480, 0:50
Аноны, поясните за работу кодеков в лисе. Вот есть видос и он не воспроизводится на сосаче хотя в системе есть кодеки mplayer, vlc, mpv воспроизводят. Разве лиса опирается не на кодеки в системе? Профиль в браузере чистый, без всего
>>11086
Какой-то дебик объяснял что опирается на кодеки в системе, а на двощах ругается на MIME тайпы какие-то.
У хрома своя реализация ffmpeg с набором кодеков вроде.
Я хз, всё равно кодеки ставил чтоб видики заработали.
Какой-то дебик объяснял что опирается на кодеки в системе, а на двощах ругается на MIME тайпы какие-то.
У хрома своя реализация ffmpeg с набором кодеков вроде.
Я хз, всё равно кодеки ставил чтоб видики заработали.
>>11086
Ну вот, у меня такая картина: в MPV воспроизводится, в Firefox воспроизводится, хромой - обосрался, говняльди - обосрался.
Ну вот, у меня такая картина: в MPV воспроизводится, в Firefox воспроизводится, хромой - обосрался, говняльди - обосрался.
>>11100
Не надо ничего пересобирать. Тебе опции надо поменять.
https://wiki.archlinux.org/title/Chromium#Hardware_video_acceleration
Не надо ничего пересобирать. Тебе опции надо поменять.
https://wiki.archlinux.org/title/Chromium#Hardware_video_acceleration
799 Кб, 1920x1080>>11101
О, вообще от души, не знал что так просто. А то блядь пишут что там компилить надо ядро, месу, браузер, аллаха.
О, вообще от души, не знал что так просто. А то блядь пишут что там компилить надо ядро, месу, браузер, аллаха.
>>11094
>>11096
Вообщем похоже, что esr версия просто не поддерживает видева с таким кодеком
>>11096
>Поддержка HEVC в Linux появится в Firefox 137!
>Проблема с добавлением поддержки HEVC через VA-API была решена сегодня и запланирована к релизу в Firefox 137 (релиз 1 апреля, согласно календарю).
>В Windows поддержка появилась в Firefox 134, в MacOS — в бета-версии Firefox 136, а в Linux будет в ночной сборке Firefox 137. >Похоже, все ОС будут поддерживаться к 137 версии!
Вообщем похоже, что esr версия просто не поддерживает видева с таким кодеком
2 Кб, 114x28>>11119
Как раз свежий, лол
Как раз свежий, лол
482 Кб, 1534x2048>>11125 (Del)
Как же у додика нигарит с богинь азиаточек лал. Ну и сидеть в местной /v/ыгребной яме тоже как признак неполноценности
Как же у додика нигарит с богинь азиаточек лал. Ну и сидеть в местной /v/ыгребной яме тоже как признак неполноценности
> ffmpeg -i "1.mp4" -ss 00:01 -vf scale=-1:720 -c:v libvpx-vp9 -quality good -b:v 1000k try2.webm
Вопрос от неофита, почему аудиодорожка автоматически добавляется и кодируется? Мне нужно для форчонга без звука
>>12120
В следующий раз используй параметр -map, им можно выбирать различные дорожки. Например:
выбрать видео из первого источника
-map 0:v
или выбрать видео из первого источника и второе аудио со второго
-map 0:v -map 1:a:1
или все субтитры из третьего
-map 2:s
В следующий раз используй параметр -map, им можно выбирать различные дорожки. Например:
выбрать видео из первого источника
-map 0:v
или выбрать видео из первого источника и второе аудио со второго
-map 0:v -map 1:a:1
или все субтитры из третьего
-map 2:s
Использую вот такое:
ffmpeg.exe -loop 1 -framerate 1 -i cover.jpg -i song.opus -r 1 -c:v libvpx-vp9 -crf 32 -b:v 0 -cpu-used 0 -row-mt 1 -pix_fmt yuv420p -c:a copy -shortest result.webm
для создания шебмок.
Вопрос: что надо написать в смд чтобы вместо "song.opus" поочередно бралась вся музыка в папке и с одним и тем же именем выдавались поочередно шебмы?
ffmpeg.exe -loop 1 -framerate 1 -i cover.jpg -i song.opus -r 1 -c:v libvpx-vp9 -crf 32 -b:v 0 -cpu-used 0 -row-mt 1 -pix_fmt yuv420p -c:a copy -shortest result.webm
для создания шебмок.
Вопрос: что надо написать в смд чтобы вместо "song.opus" поочередно бралась вся музыка в папке и с одним и тем же именем выдавались поочередно шебмы?
>>16122
скажи нейросети любой и скинь ей полный путь до папки с файлами
скажи нейросети любой и скинь ей полный путь до папки с файлами
>>16122
@echo off
rem ─────────────── Configuration ───────────────
set "FFMPEG=C:\path\to\ffmpeg.exe"
set "COVER=C:\path\to\cover.jpg"
set "INPUT_DIR=C:\path\to\your\opus_files"
rem ───────────────────────────────────────────────
pushd "\%INPUT_DIR\%"
for \%\%F in (.opus) do (
echo Converting "\%\%F" to "\%\%~nF.webm"…
"\%FFMPEG\%" -loop 1 -framerate 1 -i "\%COVER\%" ^
-i "\%\%F" -r 1 ^
-c:v libvpx-vp9 -crf 32 -b:v 0 -cpu-used 0 -row-mt 1 -pix_fmt yuv420p ^
-c:a copy -shortest "\%\%~nF.webm"
)
popd
echo All done!
pause
Добавь это в huita.bat, в текстовом редакторе сделай автозамену с \% на %
А еще можно так без батника:
cd C:\path\to\your\opus_files
for %F in (.opus) do ffmpeg.exe -loop 1 -framerate 1 -i "C:\path\to\cover.jpg" -i "%F" -r 1 -c:v libvpx-vp9 -crf 32 -b:v 0 -cpu-used 0 -row-mt 1 -pix_fmt yuv420p -c:a copy -shortest "%~nF.webm"
@echo off
rem ─────────────── Configuration ───────────────
set "FFMPEG=C:\path\to\ffmpeg.exe"
set "COVER=C:\path\to\cover.jpg"
set "INPUT_DIR=C:\path\to\your\opus_files"
rem ───────────────────────────────────────────────
pushd "\%INPUT_DIR\%"
for \%\%F in (.opus) do (
echo Converting "\%\%F" to "\%\%~nF.webm"…
"\%FFMPEG\%" -loop 1 -framerate 1 -i "\%COVER\%" ^
-i "\%\%F" -r 1 ^
-c:v libvpx-vp9 -crf 32 -b:v 0 -cpu-used 0 -row-mt 1 -pix_fmt yuv420p ^
-c:a copy -shortest "\%\%~nF.webm"
)
popd
echo All done!
pause
Добавь это в huita.bat, в текстовом редакторе сделай автозамену с \% на %
А еще можно так без батника:
cd C:\path\to\your\opus_files
for %F in (.opus) do ffmpeg.exe -loop 1 -framerate 1 -i "C:\path\to\cover.jpg" -i "%F" -r 1 -c:v libvpx-vp9 -crf 32 -b:v 0 -cpu-used 0 -row-mt 1 -pix_fmt yuv420p -c:a copy -shortest "%~nF.webm"
>>16122
@echo off
rem ─────────────── Configuration ───────────────
set "FFMPEG=C:\path\to\ffmpeg.exe"
set "COVER=C:\path\to\cover.jpg"
set "INPUT_DIR=C:\path\to\your\opus_files"
rem ───────────────────────────────────────────────
pushd "\%INPUT_DIR\%"
for \%\%F in (.opus) do (
echo Converting "\%\%F" to "\%\%~nF.webm"…
"\%FFMPEG\%" -loop 1 -framerate 1 -i "\%COVER\%" ^
-i "\%\%F" -r 1 ^
-c:v libvpx-vp9 -crf 32 -b:v 0 -cpu-used 0 -row-mt 1 -pix_fmt yuv420p ^
-c:a copy -shortest "\%\%~nF.webm"
)
popd
echo All done!
pause
Добавь это в huita.bat, в текстовом редакторе сделай автозамену с \% на %
А еще можно так без батника:
cd C:\path\to\your\opus_files
for %F in (.opus) do ffmpeg.exe -loop 1 -framerate 1 -i "C:\path\to\cover.jpg" -i "%F" -r 1 -c:v libvpx-vp9 -crf 32 -b:v 0 -cpu-used 0 -row-mt 1 -pix_fmt yuv420p -c:a copy -shortest "%~nF.webm"
@echo off
rem ─────────────── Configuration ───────────────
set "FFMPEG=C:\path\to\ffmpeg.exe"
set "COVER=C:\path\to\cover.jpg"
set "INPUT_DIR=C:\path\to\your\opus_files"
rem ───────────────────────────────────────────────
pushd "\%INPUT_DIR\%"
for \%\%F in (.opus) do (
echo Converting "\%\%F" to "\%\%~nF.webm"…
"\%FFMPEG\%" -loop 1 -framerate 1 -i "\%COVER\%" ^
-i "\%\%F" -r 1 ^
-c:v libvpx-vp9 -crf 32 -b:v 0 -cpu-used 0 -row-mt 1 -pix_fmt yuv420p ^
-c:a copy -shortest "\%\%~nF.webm"
)
popd
echo All done!
pause
Добавь это в huita.bat, в текстовом редакторе сделай автозамену с \% на %
А еще можно так без батника:
cd C:\path\to\your\opus_files
for %F in (.opus) do ffmpeg.exe -loop 1 -framerate 1 -i "C:\path\to\cover.jpg" -i "%F" -r 1 -c:v libvpx-vp9 -crf 32 -b:v 0 -cpu-used 0 -row-mt 1 -pix_fmt yuv420p -c:a copy -shortest "%~nF.webm"
>>16205
in ([символ_звездочки].opus) do
in ([символ_звездочки].opus) do
>>17221
Жëско.
Жëско.
6 Кб, 225x225Почему двухпроходное кодирование в x265 дает минимальный профит и занимает x2 времени?
>>18011
Сам догадаешься?
А вот это хз. Может материал такой попался, что от динамического битрейта особого профита нет. А может ты его настроил неправильно
> двухпроходное кодирование
> занимает x2 времени
Сам догадаешься?
> дает минимальный профит
А вот это хз. Может материал такой попался, что от динамического битрейта особого профита нет. А может ты его настроил неправильно
>>18025
Найс, траленк тупостью
Найс, траленк тупостью
>>19467
Цикличным скриптом, где сначала ролик режется на кадры, потом каждому из них с разницей в единицу меняется разрешение и кадры снова склеиваются. Просто вебм по приколу поддерживает динамическое разрешение, а ещё, к слову, альфа-канал.
Цикличным скриптом, где сначала ролик режется на кадры, потом каждому из них с разницей в единицу меняется разрешение и кадры снова склеиваются. Просто вебм по приколу поддерживает динамическое разрешение, а ещё, к слову, альфа-канал.
>>17304
обосрался
обосрался
>>19777
Да нигде, это всё самописное, поэтому подобных роликов единицы. Я хоть и понимаю, как это реализовано, но самому лень заморачиваться ради 2,5 кекнувших анонов. А распространяются такие ролики лишь в дискорде и на некоторых бордах, потому что ни одна другая мало-мальски популярная платформа не поддерживает динамическое разрешение вебм.
Да нигде, это всё самописное, поэтому подобных роликов единицы. Я хоть и понимаю, как это реализовано, но самому лень заморачиваться ради 2,5 кекнувших анонов. А распространяются такие ролики лишь в дискорде и на некоторых бордах, потому что ни одна другая мало-мальски популярная платформа не поддерживает динамическое разрешение вебм.
1,6 Мб, webm,640x360, 0:21
>>19894
>>19926
Спросил у ЖПТ чата, выдал такое:
@echo off
setlocal enabledelayedexpansion
REM === Настройки ===
set "INPUT=input.mp4"
set "FFMPEG=ffmpeg"
if not exist "%INPUT%" (
echo Файл %INPUT% не найден!
pause
exit /b
)
REM === Очистка временных файлов ===
del /Q part*.webm >nul 2>&1
del /Q list.txt output.webm >nul 2>&1
REM === Настройка фрагментов: формат "start duration width height" ===
set count=0
set "segment1=0 7 640 360"
set "segment2=7 7 960 540"
set "segment3=14 7 1280 720"
REM === Обработка фрагментов ===
for S in (1 2 3) do (
set /a count+=1
for /f "tokens=1,2,3,4" a in ("!segmentS!") do (
set "START=a"
set "DUR=b"
set "W=c"
set "H=%%d"
echo → Обработка фрагмента !count!: !START! сек, !DUR! сек, !W!x!H!
%FFMPEG% -y -ss !START! -t !DUR! -i "%INPUT%" ^
-vf scale=!W!:!H! ^
-c:v libvpx-vp9 -crf 32 -b:v 0 -c:a libopus -f webm part!count!.webm
echo file 'part!count!.webm' >> list.txt
)
)
REM === Склейка всех фрагментов через concat demuxer ===
echo → Склейка в WebM...
%FFMPEG% -y -f concat -safe 0 -i list.txt -c copy output.webm
echo.
echo ✅ Готово! Итоговый файл: output.webm
pause
Вроде всё работает(в закрепленном ролике 3 фрагмента по 7 секунд в разном разрешении), но разрешение меняется только при перемотке. Автоматически ролик не менят разрешение.
ЖПТчят пишет что в реальном времени невозможно менять разрешение автоматически)
ХЗ куда копать...
>>19926
Спросил у ЖПТ чата, выдал такое:
@echo off
setlocal enabledelayedexpansion
REM === Настройки ===
set "INPUT=input.mp4"
set "FFMPEG=ffmpeg"
if not exist "%INPUT%" (
echo Файл %INPUT% не найден!
pause
exit /b
)
REM === Очистка временных файлов ===
del /Q part*.webm >nul 2>&1
del /Q list.txt output.webm >nul 2>&1
REM === Настройка фрагментов: формат "start duration width height" ===
set count=0
set "segment1=0 7 640 360"
set "segment2=7 7 960 540"
set "segment3=14 7 1280 720"
REM === Обработка фрагментов ===
for S in (1 2 3) do (
set /a count+=1
for /f "tokens=1,2,3,4" a in ("!segmentS!") do (
set "START=a"
set "DUR=b"
set "W=c"
set "H=%%d"
echo → Обработка фрагмента !count!: !START! сек, !DUR! сек, !W!x!H!
%FFMPEG% -y -ss !START! -t !DUR! -i "%INPUT%" ^
-vf scale=!W!:!H! ^
-c:v libvpx-vp9 -crf 32 -b:v 0 -c:a libopus -f webm part!count!.webm
echo file 'part!count!.webm' >> list.txt
)
)
REM === Склейка всех фрагментов через concat demuxer ===
echo → Склейка в WebM...
%FFMPEG% -y -f concat -safe 0 -i list.txt -c copy output.webm
echo.
echo ✅ Готово! Итоговый файл: output.webm
pause
Вроде всё работает(в закрепленном ролике 3 фрагмента по 7 секунд в разном разрешении), но разрешение меняется только при перемотке. Автоматически ролик не менят разрешение.
ЖПТчят пишет что в реальном времени невозможно менять разрешение автоматически)
ХЗ куда копать...
1,6 Мб, webm,640x360, 0:21
>>19894
>>19926
Спросил у ЖПТ чата, выдал такое:
@echo off
setlocal enabledelayedexpansion
REM === Настройки ===
set "INPUT=input.mp4"
set "FFMPEG=ffmpeg"
if not exist "%INPUT%" (
echo Файл %INPUT% не найден!
pause
exit /b
)
REM === Очистка временных файлов ===
del /Q part*.webm >nul 2>&1
del /Q list.txt output.webm >nul 2>&1
REM === Настройка фрагментов: формат "start duration width height" ===
set count=0
set "segment1=0 7 640 360"
set "segment2=7 7 960 540"
set "segment3=14 7 1280 720"
REM === Обработка фрагментов ===
for S in (1 2 3) do (
set /a count+=1
for /f "tokens=1,2,3,4" a in ("!segmentS!") do (
set "START=a"
set "DUR=b"
set "W=c"
set "H=%%d"
echo → Обработка фрагмента !count!: !START! сек, !DUR! сек, !W!x!H!
%FFMPEG% -y -ss !START! -t !DUR! -i "%INPUT%" ^
-vf scale=!W!:!H! ^
-c:v libvpx-vp9 -crf 32 -b:v 0 -c:a libopus -f webm part!count!.webm
echo file 'part!count!.webm' >> list.txt
)
)
REM === Склейка всех фрагментов через concat demuxer ===
echo → Склейка в WebM...
%FFMPEG% -y -f concat -safe 0 -i list.txt -c copy output.webm
echo.
echo ✅ Готово! Итоговый файл: output.webm
pause
Вроде всё работает(в закрепленном ролике 3 фрагмента по 7 секунд в разном разрешении), но разрешение меняется только при перемотке. Автоматически ролик не менят разрешение.
ЖПТчят пишет что в реальном времени невозможно менять разрешение автоматически)
ХЗ куда копать...
>>19926
Спросил у ЖПТ чата, выдал такое:
@echo off
setlocal enabledelayedexpansion
REM === Настройки ===
set "INPUT=input.mp4"
set "FFMPEG=ffmpeg"
if not exist "%INPUT%" (
echo Файл %INPUT% не найден!
pause
exit /b
)
REM === Очистка временных файлов ===
del /Q part*.webm >nul 2>&1
del /Q list.txt output.webm >nul 2>&1
REM === Настройка фрагментов: формат "start duration width height" ===
set count=0
set "segment1=0 7 640 360"
set "segment2=7 7 960 540"
set "segment3=14 7 1280 720"
REM === Обработка фрагментов ===
for S in (1 2 3) do (
set /a count+=1
for /f "tokens=1,2,3,4" a in ("!segmentS!") do (
set "START=a"
set "DUR=b"
set "W=c"
set "H=%%d"
echo → Обработка фрагмента !count!: !START! сек, !DUR! сек, !W!x!H!
%FFMPEG% -y -ss !START! -t !DUR! -i "%INPUT%" ^
-vf scale=!W!:!H! ^
-c:v libvpx-vp9 -crf 32 -b:v 0 -c:a libopus -f webm part!count!.webm
echo file 'part!count!.webm' >> list.txt
)
)
REM === Склейка всех фрагментов через concat demuxer ===
echo → Склейка в WebM...
%FFMPEG% -y -f concat -safe 0 -i list.txt -c copy output.webm
echo.
echo ✅ Готово! Итоговый файл: output.webm
pause
Вроде всё работает(в закрепленном ролике 3 фрагмента по 7 секунд в разном разрешении), но разрешение меняется только при перемотке. Автоматически ролик не менят разрешение.
ЖПТчят пишет что в реальном времени невозможно менять разрешение автоматически)
ХЗ куда копать...
>>19996
https://github.com/hampta/webm-dynamic-resolution
https://github.com/maniekx86/webm-resolution
попробуй отсюда гпт скормить скрипты
https://github.com/hampta/webm-dynamic-resolution
https://github.com/maniekx86/webm-resolution
попробуй отсюда гпт скормить скрипты
>>19996
и пиши ему на английском обязательно
и пиши ему на английском обязательно
>>19996
Скрипт для тупого склеивания картиночек с разным разрешением в вемб анон кидал ещё давно в предыдущих тредах. Это неинтересно, а твой результат можно склеить вручную в принципе безо всяких скриптов и тем более помощи искусственного идиота.
Скрипт для тупого склеивания картиночек с разным разрешением в вемб анон кидал ещё давно в предыдущих тредах. Это неинтересно, а твой результат можно склеить вручную в принципе безо всяких скриптов и тем более помощи искусственного идиота.
5,1 Мб, webm,640x1138, 0:08
>>20025
Но в этом ролике же, тот что анончик выше кидал, не тупо картинки запакованные в webm, а закодировано в vp8.
А скрипт что я кинул это просто ради примера, там кол-во сегментов надо самому добавлять, если их будет 100+, то в ручную их нарезать, кодировать и клеить неделю будешь.
Но в этом ролике же, тот что анончик выше кидал, не тупо картинки запакованные в webm, а закодировано в vp8.
А скрипт что я кинул это просто ради примера, там кол-во сегментов надо самому добавлять, если их будет 100+, то в ручную их нарезать, кодировать и клеить неделю будешь.
>>20312
ахуеть а че еще такого прикольного есть как вот эта хуйня
ахуеть а че еще такого прикольного есть как вот эта хуйня
Насколько актуальны гугловские параметры сжатия для постинга на дваче? Используется vp9 на выходе получается .webm https://developers.google.com/media/vp9/settings/vod
Пример того что я использую 720р 30фпс:
ffmpeg -i input.mp4 -ss 00:00:09.328 -to 00:00:56.248 -vf scale=1280x720 -b:v 1024k -minrate 512k -maxrate 1485k -tile-columns 2 -g 240 -threads 8 -quality good -crf 32 -c:v libvpx-vp9 -c:a libopus -pass 1 -speed 4 output.webm
&& ffmpeg -i input.mp4 -ss 00:00:09.328 -to 00:00:56.248 -vf scale=1280x720 -b:v 1024k -minrate 512k -maxrate 1485k -tile-columns 2 -g 240 -threads 8 -quality good -crf 32 -c:v libvpx-vp9 -c:a libopus -pass 2 -speed 2 -y output.webm
Пример того что я использую 720р 30фпс:
ffmpeg -i input.mp4 -ss 00:00:09.328 -to 00:00:56.248 -vf scale=1280x720 -b:v 1024k -minrate 512k -maxrate 1485k -tile-columns 2 -g 240 -threads 8 -quality good -crf 32 -c:v libvpx-vp9 -c:a libopus -pass 1 -speed 4 output.webm
&& ffmpeg -i input.mp4 -ss 00:00:09.328 -to 00:00:56.248 -vf scale=1280x720 -b:v 1024k -minrate 512k -maxrate 1485k -tile-columns 2 -g 240 -threads 8 -quality good -crf 32 -c:v libvpx-vp9 -c:a libopus -pass 2 -speed 2 -y output.webm
>>20499
А что нужно? Вот эти настройки нормально работают?
ffmpeg -i "1.mkv" -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -crf 28 -svtav1-params tune=0:irefresh-type=1 svt.mkv
Где тут прописано выходное разрешение, количество кадров, начало и конец обрезки файла или можно всё добавлять самому? Почему никто ещё не сделал простенький гуи ко всему этому, у вебм например есть вебм фор ретардс.
А что нужно? Вот эти настройки нормально работают?
ffmpeg -i "1.mkv" -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -crf 28 -svtav1-params tune=0:irefresh-type=1 svt.mkv
Где тут прописано выходное разрешение, количество кадров, начало и конец обрезки файла или можно всё добавлять самому? Почему никто ещё не сделал простенький гуи ко всему этому, у вебм например есть вебм фор ретардс.
>>20498
Мне кажется хуйня ввыйдет, разное соотношение сторон. VP9 это вчерашний день.
>>20500
Если не указано - значит те же что и во входнном файле.
Если не указано - кодируется весь файл.
-ss 00:00:20 - кодировать с двадцатой секунды до конца
-ss 00:00:05 -t 15 - кодировать с пятой по двадцатую секунды
>Input file 1920x800
>Output file 1280x720
Мне кажется хуйня ввыйдет, разное соотношение сторон. VP9 это вчерашний день.
>>20500
>Где тут прописано выходное разрешение, количество кадров
Если не указано - значит те же что и во входнном файле.
>начало и конец обрезки файла
Если не указано - кодируется весь файл.
-ss 00:00:20 - кодировать с двадцатой секунды до конца
-ss 00:00:05 -t 15 - кодировать с пятой по двадцатую секунды
>>20650
Так этот тред и создан для тех кто не умеет им пользоваться, чтобы задавать тупые вопросы. Копетан.
Так этот тред и создан для тех кто не умеет им пользоваться, чтобы задавать тупые вопросы. Копетан.
>>20650
Нет задач для использования всех его возможностей. Мне хватает обрезки, склейки нескольких кусков и crop фильтра.
Нет задач для использования всех его возможностей. Мне хватает обрезки, склейки нескольких кусков и crop фильтра.
>>20662
так никто на них ответить не может
так никто на них ответить не может
>>20663
я про ютуб
я про ютуб
У меня были файлы продолжительностью по 23-24 минуты. Мне надо было добавить в начало каждого из них по 1 секунде тишины. После этого файлы стали длинной по несколько часов! С того момента, где файл заканчивается фактически, до того момента, где файл заканчивается по мнению проигрывателя, абсолютная пустота, т. е. если ткнуть туда, индикатор шкалы времени мгновенно переместится в самый конец аудио. При этом в консоли cmd продолжительность выходного файла вполне адекватная, увеличенная ровно на секунду, как мне и надо.
>>21380
А, нет. Почему-то но секунд 30 становится длиннее. Причём в начало добавляет 1 секунду, как надо
А, нет. Почему-то но секунд 30 становится длиннее. Причём в начало добавляет 1 секунду, как надо
>>21380
Форумчанин, на этом ресурсе в сети интернет экстрасенсов нет - какие именно файлы, какие кодеки, какие контейнеры? Как добавлял тишину?
Форумчанин, на этом ресурсе в сети интернет экстрасенсов нет - какие именно файлы, какие кодеки, какие контейнеры? Как добавлял тишину?
>>21408
Audio: AAC 44100Hz stereo 128kbps длительностью 24-27 минут. Тишину добавлял командой ffmpeg -i $inputFile -af "adelay=1000|1000" $outputFile
Пробовал ещё командой ffmpeg -f lavfi -i anullsrc=r=44100:cl=mono -t 1 -i input.mp3 -filter_complex "[0:a][1:a]concat=n=2:v=0:a=1[a]" -map "[a]" output.mp3, но тогда файл очень долго обрабатывался и консоли тоже параметр time занял порядка нескольких часов
Audio: AAC 44100Hz stereo 128kbps длительностью 24-27 минут. Тишину добавлял командой ffmpeg -i $inputFile -af "adelay=1000|1000" $outputFile
Пробовал ещё командой ffmpeg -f lavfi -i anullsrc=r=44100:cl=mono -t 1 -i input.mp3 -filter_complex "[0:a][1:a]concat=n=2:v=0:a=1[a]" -map "[a]" output.mp3, но тогда файл очень долго обрабатывался и консоли тоже параметр time занял порядка нескольких часов
>>21421
Попробуй ffmpeg -i $inputFile -af "adelay=1000|1000,asettb=AVTB,asetpts=N/SR/TB" $outputFile
У второй команды -t должно стоять либо между -f и -i (-f lavfi -t 1 -i ...), либо перед -f.
И -filter_complex "[0:a:0]aformat=r=44100:cl=stereo,asettb=AVTB,asetpts=N/SR/TB[frag1]; [1:a:0]aformat=r=44100:cl=stereo,asettb=AVTB,asetpts=N/SR/TB[frag2]; [frag1][frag2]concat=n=2:v=0:a=1[a]" ...
Попробуй ffmpeg -i $inputFile -af "adelay=1000|1000,asettb=AVTB,asetpts=N/SR/TB" $outputFile
У второй команды -t должно стоять либо между -f и -i (-f lavfi -t 1 -i ...), либо перед -f.
И -filter_complex "[0:a:0]aformat=r=44100:cl=stereo,asettb=AVTB,asetpts=N/SR/TB[frag1]; [1:a:0]aformat=r=44100:cl=stereo,asettb=AVTB,asetpts=N/SR/TB[frag2]; [frag1][frag2]concat=n=2:v=0:a=1[a]" ...
>>21425
Через пару часов попробую. Надеюсь, стработает
Через пару часов попробую. Надеюсь, стработает
>>21425
Хоть ты тресни! Обе команды попробовал - та же песня. А я сам не знаю, что в них можно поменять, чтобы избавиться от этой проблемы. Они для меня, как заклинания.
Хоть ты тресни! Обе команды попробовал - та же песня. А я сам не знаю, что в них можно поменять, чтобы избавиться от этой проблемы. Они для меня, как заклинания.
>>21467
Странно, УМВР если встречаются проблемные файлы. asetpts генерирует новые таймстампы с нуля на основе унифицированного таймбейса.
ffmpeg -t 1 -f lavfi -i anullsrc -i ORIG.m4a -filter_complex "[0:a:0]aformat=r=44100:cl=stereo,asettb=AVTB,asetpts=N/SR/TB[frag1]; [1:a:0]aformat=r=44100:cl=stereo,asettb=AVTB,asetpts=N/SR/TB[frag2]; [frag1][frag2]concat=n=2:v=0:a=1[a]" -map "[a]" -c:a pcm_s16le -f s16le - | ffmpeg -f s16le -ar 44100 -ac 2 -i - OUTPUT.mp3
Скопируй это в консолечку предварительно заменив ORIG.m4a и OUTPUT.mp3
Если не поможет, то
ffmpeg -t 1 -f lavfi -i anullsrc -i ORIG.m4a -filter_complex "[0:a:0]aformat=r=44100:cl=stereo,asettb=AVTB,asetpts=N/SR/TB[frag1]; [1:a:0]aresample=async=1,aformat=r=44100:cl=stereo,asettb=AVTB,asetpts=N/SR/TB[frag2]; [frag1][frag2]concat=n=2:v=0:a=1[a]" -map "[a]" OUTPUT.mp3
Может еще добавить -map_metadata -1 map_chapters -1? Или перенести "[1:a:0]aresample=async=1," из второй команды в первую на соответствующее место? Не имея доступа к оригиналам тут можно только гадать что за хуйня.
Странно, УМВР если встречаются проблемные файлы. asetpts генерирует новые таймстампы с нуля на основе унифицированного таймбейса.
ffmpeg -t 1 -f lavfi -i anullsrc -i ORIG.m4a -filter_complex "[0:a:0]aformat=r=44100:cl=stereo,asettb=AVTB,asetpts=N/SR/TB[frag1]; [1:a:0]aformat=r=44100:cl=stereo,asettb=AVTB,asetpts=N/SR/TB[frag2]; [frag1][frag2]concat=n=2:v=0:a=1[a]" -map "[a]" -c:a pcm_s16le -f s16le - | ffmpeg -f s16le -ar 44100 -ac 2 -i - OUTPUT.mp3
Скопируй это в консолечку предварительно заменив ORIG.m4a и OUTPUT.mp3
Если не поможет, то
ffmpeg -t 1 -f lavfi -i anullsrc -i ORIG.m4a -filter_complex "[0:a:0]aformat=r=44100:cl=stereo,asettb=AVTB,asetpts=N/SR/TB[frag1]; [1:a:0]aresample=async=1,aformat=r=44100:cl=stereo,asettb=AVTB,asetpts=N/SR/TB[frag2]; [frag1][frag2]concat=n=2:v=0:a=1[a]" -map "[a]" OUTPUT.mp3
Может еще добавить -map_metadata -1 map_chapters -1? Или перенести "[1:a:0]aresample=async=1," из второй команды в первую на соответствующее место? Не имея доступа к оригиналам тут можно только гадать что за хуйня.
>>21476
Первый скрипт жопа. Вместо звука сплошной радиошум. Чсх файлы-таки с минимальным увеличением времени вышли (кроме одного, который по прежнему 12 часов): всего на 22 секунды длиннее, без учёта того, что одну секунду требовалось добавить. Сейчас второй скрипт буду пробовать
Первый скрипт жопа. Вместо звука сплошной радиошум. Чсх файлы-таки с минимальным увеличением времени вышли (кроме одного, который по прежнему 12 часов): всего на 22 секунды длиннее, без учёта того, что одну секунду требовалось добавить. Сейчас второй скрипт буду пробовать
>>21503
Второй шумов не даёт. По остальному: результат прежний. С утра прогоню с добавлением map metedat-ы
Второй шумов не даёт. По остальному: результат прежний. С утра прогоню с добавлением map metedat-ы
>>21503
ffmpeg -i ORIG.m4a -map 0:a:0 -c:a pcm_s16le -ar 44100 -ac 2 -f s16le - | ffmpeg -t 1 -f lavfi -i anullsrc -f s16le -ar 44100 -ac 2 -i - -filter_complex "[0:a:0]aformat=r=44100:cl=stereo:f=s16,asettb=AVTB,asetpts=N/SR/TB[frag1]; [1:a:0]aformat=r=44100:cl=stereo:f=s16,asettb=AVTB,asetpts=N/SR/TB[frag2]; [frag1][frag2]concat=n=2:v=0:a=1[a]" -map "[a]" OUTPUT.mp3
Если это не поможет - дальше мои полномочия всё. На всякий случай: это одна целая команда с пайплайном, а не две разных. Дефисы (-f s16le - | и -i - ) не убирать.
ffmpeg -i ORIG.m4a -map 0:a:0 -c:a pcm_s16le -ar 44100 -ac 2 -f s16le - | ffmpeg -t 1 -f lavfi -i anullsrc -f s16le -ar 44100 -ac 2 -i - -filter_complex "[0:a:0]aformat=r=44100:cl=stereo:f=s16,asettb=AVTB,asetpts=N/SR/TB[frag1]; [1:a:0]aformat=r=44100:cl=stereo:f=s16,asettb=AVTB,asetpts=N/SR/TB[frag2]; [frag1][frag2]concat=n=2:v=0:a=1[a]" -map "[a]" OUTPUT.mp3
Если это не поможет - дальше мои полномочия всё. На всякий случай: это одна целая команда с пайплайном, а не две разных. Дефисы (-f s16le - | и -i - ) не убирать.
27 Кб, 1248x97>>21380
>>21421
Проблема со встроенным в ffmpeg aac-энкодером, используй libfdk_aac из nonfree сборки.
https://github.com/AnimMouse/ffmpeg-autobuild
Пикрелейтед — рабочая команда, битрейт укажи свой.
>>21421
Проблема со встроенным в ffmpeg aac-энкодером, используй libfdk_aac из nonfree сборки.
https://github.com/AnimMouse/ffmpeg-autobuild
Пикрелейтед — рабочая команда, битрейт укажи свой.
76 Кб, 460x480>>21549
No option near '1'
Error parsing a filter description around:
Error parsing filterchain 'adelay=1s:all=true,apad_dur=1' around:
Error opening output file
Error opening output files: invalid argument
No option near '1'
Error parsing a filter description around:
Error parsing filterchain 'adelay=1s:all=true,apad_dur=1' around:
Error opening output file
Error opening output files: invalid argument
>>21479
Использовал ffmpeg -f concat -safe 0 -i "concat:silence.aac|$inputFile" -c copy $outputFile.
Выдаёт
Line 1: unknown keyword '▢▢▢?▢▢' — да, квадратики. В первой строке у меня комментарий. Если она не считается, то во второй — присвоение переменной $imputFolder директории.
Error opening input: Invalid data found when processing input
Error opening input file concat
>>21545
Опять шумы
Использовал ffmpeg -f concat -safe 0 -i "concat:silence.aac|$inputFile" -c copy $outputFile.
Выдаёт
Line 1: unknown keyword '▢▢▢?▢▢' — да, квадратики. В первой строке у меня комментарий. Если она не считается, то во второй — присвоение переменной $imputFolder директории.
Error opening input: Invalid data found when processing input
Error opening input file concat
>>21545
Опять шумы
>>21632
Ты перемешал конкат демуксер с конкат протоколом.
list.txt должен содержать список файлов каждый на новой строке в формате:
file 'silence.m4a'
file 'ORIG.m4a'
Надо убедиться что silence.m4a имеет тот же самый кодек, сэмпл рейт и количество каналов. И, наверное, тот же самый битрейт, что и у оригинала.
ffmpeg -t 1 -f lavfi -i anullsrc -c:a aac (или libfdk_aac если есть) -b:a 128k -ar 44100 -ac 2 silence.m4a
ffmpeg -f concat -safe 0 -i list.txt -c copy OUTPUT.m4a
Потом попробовать ffmpeg -f concat -safe 0 -i list.txt -c copy -fflags +genpts -async 1 OUTPUT.m4a
Если нужно mp3 то заменить -c copy на -c:a libmp3lame
Ты перемешал конкат демуксер с конкат протоколом.
list.txt должен содержать список файлов каждый на новой строке в формате:
file 'silence.m4a'
file 'ORIG.m4a'
Надо убедиться что silence.m4a имеет тот же самый кодек, сэмпл рейт и количество каналов. И, наверное, тот же самый битрейт, что и у оригинала.
ffmpeg -t 1 -f lavfi -i anullsrc -c:a aac (или libfdk_aac если есть) -b:a 128k -ar 44100 -ac 2 silence.m4a
ffmpeg -f concat -safe 0 -i list.txt -c copy OUTPUT.m4a
Потом попробовать ffmpeg -f concat -safe 0 -i list.txt -c copy -fflags +genpts -async 1 OUTPUT.m4a
Если нужно mp3 то заменить -c copy на -c:a libmp3lame
>>21479
Победитель. Простое и эффективное решение.
Победитель. Простое и эффективное решение.
>>21668
Может быть. У меня просто там уже целая готовая партянка была начиркана и из твоего кода я просто взял последнюю строку, заменив в ней I и O на inpetFile и OutputFile
>>21666
А я смогу использовать $inpetFile вместо конкретного имени файла в .txt? Т. е. это единственная причина, по которой я старался внести список файлов непосредственно в коде
Может быть. У меня просто там уже целая готовая партянка была начиркана и из твоего кода я просто взял последнюю строку, заменив в ней I и O на inpetFile и OutputFile
>>21666
А я смогу использовать $inpetFile вместо конкретного имени файла в .txt? Т. е. это единственная причина, по которой я старался внести список файлов непосредственно в коде
>>21668
Может ли ffmpeg самопроизвольно запускаться не из той папки, которую я указал в переменной среды patch, а из других? Просто у меня подозрение, как-будто он просто не распознал эту команду, как-будто ffmpeg запускался из другой директории (у меня есть gui-шки yt-dlp и у них свой yt-dlp и ffmpeg в своих папках; но эти директории у меня НЕ указаны в patch). В переменной среды patch у меня, если что, указан только путь к ffmpeg по твоей ссылке https://github.com/AnimMouse/ffmpeg-autobuild
Может ли ffmpeg самопроизвольно запускаться не из той папки, которую я указал в переменной среды patch, а из других? Просто у меня подозрение, как-будто он просто не распознал эту команду, как-будто ffmpeg запускался из другой директории (у меня есть gui-шки yt-dlp и у них свой yt-dlp и ffmpeg в своих папках; но эти директории у меня НЕ указаны в patch). В переменной среды patch у меня, если что, указан только путь к ffmpeg по твоей ссылке https://github.com/AnimMouse/ffmpeg-autobuild
>>21794
Убери из команды -hide_banner и посмотри есть ли в выводе «--enable-nonfree --enable-libfdk-aac».
Покажи скриншот консоли со всеми командами что вводишь.
Убери из команды -hide_banner и посмотри есть ли в выводе «--enable-nonfree --enable-libfdk-aac».
Покажи скриншот консоли со всеми командами что вводишь.
>>22153
Анон...
...
....
.....
...анон... оно работает!!!
У меня кстати изначальные-то файлы с кусочками ложного времени в конце, а твой скрипт удалил ложное время в конце файлов! Это... я не знаю. Сегодня оно работает
Анон...
...
....
.....
...анон... оно работает!!!
У меня кстати изначальные-то файлы с кусочками ложного времени в конце, а твой скрипт удалил ложное время в конце файлов! Это... я не знаю. Сегодня оно работает
32 Кб, 489x411>>21900
Забыл
Есть догадка, что квадратные скобки в именах файлов ебали мозги. Я-то думал. что, раз файлы открываются, то всё заебись. Но не тут-то было!
>Покажи скриншот консоли со всеми командами что вводишь.
Забыл
Есть догадка, что квадратные скобки в именах файлов ебали мозги. Я-то думал. что, раз файлы открываются, то всё заебись. Но не тут-то было!
>>22156
PowerShell воспринимает квадратные скобки как часть regex-выражения, чтобы прочитать файл в имени которого содержатся квадратные скобки нужно использовать параметр -LiteralPath.
Get-Item / Get-ChildItem -LiteralPath "Путь к файлу"
>>22157
Всё должно работать как и в обычной сборке.
Можешь использовать stable билд, а не master.
https://github.com/AnimMouse/ffmpeg-stable-autobuild
PowerShell воспринимает квадратные скобки как часть regex-выражения, чтобы прочитать файл в имени которого содержатся квадратные скобки нужно использовать параметр -LiteralPath.
Get-Item / Get-ChildItem -LiteralPath "Путь к файлу"
>>22157
Всё должно работать как и в обычной сборке.
Можешь использовать stable билд, а не master.
https://github.com/AnimMouse/ffmpeg-stable-autobuild
>>22159
Нагугливал ранее эту функцию. Не смог применить. Сейчас попробовал после Гет Чайлдайтем вставить, но ошибка вылазит. Куда её правильно воткнуть надобно?
Нагугливал ранее эту функцию. Не смог применить. Сейчас попробовал после Гет Чайлдайтем вставить, но ошибка вылазит. Куда её правильно воткнуть надобно?
>>22166
Get-ChildItem -LiteralPath вместо Get-ChildItem -Path, но это нужно только если у тебя путь $inputFolder содержит квадратные скобки.
Нейронку поспрашивай, она поможет с такими вопросами.
Get-ChildItem -LiteralPath вместо Get-ChildItem -Path, но это нужно только если у тебя путь $inputFolder содержит квадратные скобки.
Нейронку поспрашивай, она поможет с такими вопросами.
>>22157
Для yt-dlp предпочтительнее использование специальной сборки с патчами https://github.com/yt-dlp/FFmpeg-Builds
Вышеприведенная же версия подойдёт как backend для фубаровского конвертера в aac.
> А как эта версия ffmpeg-а в плане секса скачивания файлов с ютуба с помощью ютуб длп?
Для yt-dlp предпочтительнее использование специальной сборки с патчами https://github.com/yt-dlp/FFmpeg-Builds
Вышеприведенная же версия подойдёт как backend для фубаровского конвертера в aac.
>>22216
Да мне-то и код в целом нейронка написала. А путь в принципе скобок квадратных не имеет. А вот имена файлов...
Да мне-то и код в целом нейронка написала. А путь в принципе скобок квадратных не имеет. А вот имена файлов...
>>22220
Буду иметь ввиду. Но в принципе и эта версия вполне работает.
Буду иметь ввиду. Но в принципе и эта версия вполне работает.
7 Кб, 330x199>>00915 (OP)
Вопрос по микшированию 5.1 в 2.0.
Нужно смешать многококонал в стэрэо пельмень НО с вот этими коэффициентами (скрин из мпс-хс).
Какая строчка надо?
Вопрос по микшированию 5.1 в 2.0.
Нужно смешать многококонал в стэрэо пельмень НО с вот этими коэффициентами (скрин из мпс-хс).
Какая строчка надо?
Бля казалось бы напишите нормальную команду с объяснением всех аргументов для обрезки и сжатия чтобы срать на двач, но нет, мы такого сделать не можем.
Взял из шапки треда: ffmpeg -i "1.mkv" -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -crf 28 -svtav1-params tune=0:irefresh-type=1 svt.mkv
Так оно мне минутный файл который я предварительно прописал -vf scale=1280x720 ужало до... почти 300 мегабайт. Лучше дальше через вебм вп9 буду делать который сто тысяч лет кодирует.
Взял из шапки треда: ffmpeg -i "1.mkv" -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -crf 28 -svtav1-params tune=0:irefresh-type=1 svt.mkv
Так оно мне минутный файл который я предварительно прописал -vf scale=1280x720 ужало до... почти 300 мегабайт. Лучше дальше через вебм вп9 буду делать который сто тысяч лет кодирует.
>>22734
Тред полистай, все разжевано.
Повышай crf, выше значение - ниже битрейт.
Тред полистай, все разжевано.
>ужало до... почти 300 мегабайт
Повышай crf, выше значение - ниже битрейт.
>>22734
Использовать параметры -ss -to
-ss 00:00:00.000
что значит -ss часы:минуты:секунды.милисекунды
или в виде секунд
-ss 000
Команда должна выглядеть вот так: -ss перед -i
ffmpeg -ss 000 -i $file -to 003 -c copy $file_cut.mkv
>для обрезки
Использовать параметры -ss -to
-ss 00:00:00.000
что значит -ss часы:минуты:секунды.милисекунды
или в виде секунд
-ss 000
Команда должна выглядеть вот так: -ss перед -i
ffmpeg -ss 000 -i $file -to 003 -c copy $file_cut.mkv
>>22734
Делай, мне похуй, «Microsoft Windows 10: Chromium based» с выёбистым тоном общения это явный ред флаг и помогать таким не стоит.
> Лучше дальше через вебм вп9 буду делать который сто тысяч лет кодирует.
Делай, мне похуй, «Microsoft Windows 10: Chromium based» с выёбистым тоном общения это явный ред флаг и помогать таким не стоит.
111 Кб, 959x201А что, у всех всё нормально качает? Я хуй проссышь что полетело, но уже пару дней требует на скачивания всех видосов с трубы кукисы. Оно-то, конечно, не конец света, но муторно, через GUI было проще, чем на каждый видос качать куки и вручную вводить через cmd.
979 Кб, webm,702x574, 0:06
>>22884
Если ты не смог осилить даже выбор треда, то мы бессильны в твоей проблеме, которая куда глубже, чем тебе кажется.
Если ты не смог осилить даже выбор треда, то мы бессильны в твоей проблеме, которая куда глубже, чем тебе кажется.
Подскажите, а есть какой-то универсальный способ кроме визуального понять было ли сжато видео до этого или нет? Именно nvenc'ом.
Вот есть допустим видик, он уже сжат, и находится он в папке с другими видиками, которые не сжаты. Как сделать так, чтобы ffmpeg понимал, что имеет смысл сжимать, а что нет? Гпт ничего путного не предложил. Только чекать битрейт или вообще пережимать, а потом сравнивать.
Вот есть допустим видик, он уже сжат, и находится он в папке с другими видиками, которые не сжаты. Как сделать так, чтобы ffmpeg понимал, что имеет смысл сжимать, а что нет? Гпт ничего путного не предложил. Только чекать битрейт или вообще пережимать, а потом сравнивать.
Аноны, первый раз у вас тут в треде, пытаюсь потихоньку осваиваться с ffmpeg'ом. Хочу перекодировать один 4K фильмец (размером с 21 GB, есл это важно) с обрезкой черных полос, чтобы можно было нормально посмотреть его на 16:9 экранею - да, понимаю , что ffmpeg лишних пикселей не нарисует, но я лучше потеряю, в том или ином виде, какую-то долю разрешения, чем соглашусь смотреть черные полосы сверху и снизу экрана.
Но никак не получается подрубить аппаратное ускорение. Софтверный рекодинг работает, но по расчетам (исходя из скорости рекодинга в единцах fps) займет порядка 8 часов - хотя сам ffmpeg прикидывает что понадобится больше суток.
ОС - Arch Linux, пакет amf-amdgpu-pro установлен
CPU - Ryzen 2600
RAM - 16 GB
GPU - RX 580 8GB (архитектура GCN 4.0)
Да, это скорее обычный полубомж десктоп, чем современная рабочая станция, но все же, хотелось бы заставить видяху поработать.
Исходя из документации по адресу https://trac.ffmpeg.org/wiki/Hardware/AMF, запускаю сию команду:
ffmpeg -hwaccel d3d11va -hwaccel_output_format d3d11 -i Venom.mkv -vf "crop=iw:ih*16/9,scale=3840:2160" -c:v hevc_amf -b:v 10M -c:a aac -b:a 192k Venom.mp4
И получаю ошибку:
Device creation failed: -12.
[vist#0:0/hevc @ 0x5601e805de40] [dec:hevc @ 0x5601e806ffc0] No device available for decoder: device type d3d11va needed for codec hevc.
[vist#0:0/hevc @ 0x5601e805de40] [dec:hevc @ 0x5601e806ffc0] Hardware device setup failed for decoder: Cannot allocate memory
Error opening output file Venom.mp4.
Error opening output files: Cannot allocate memory
Что я делаю не так ? Что я должен поменять в опциях и аргументах, скармливаемых ffmpeg'у ?
Но никак не получается подрубить аппаратное ускорение. Софтверный рекодинг работает, но по расчетам (исходя из скорости рекодинга в единцах fps) займет порядка 8 часов - хотя сам ffmpeg прикидывает что понадобится больше суток.
ОС - Arch Linux, пакет amf-amdgpu-pro установлен
CPU - Ryzen 2600
RAM - 16 GB
GPU - RX 580 8GB (архитектура GCN 4.0)
Да, это скорее обычный полубомж десктоп, чем современная рабочая станция, но все же, хотелось бы заставить видяху поработать.
Исходя из документации по адресу https://trac.ffmpeg.org/wiki/Hardware/AMF, запускаю сию команду:
ffmpeg -hwaccel d3d11va -hwaccel_output_format d3d11 -i Venom.mkv -vf "crop=iw:ih*16/9,scale=3840:2160" -c:v hevc_amf -b:v 10M -c:a aac -b:a 192k Venom.mp4
И получаю ошибку:
Device creation failed: -12.
[vist#0:0/hevc @ 0x5601e805de40] [dec:hevc @ 0x5601e806ffc0] No device available for decoder: device type d3d11va needed for codec hevc.
[vist#0:0/hevc @ 0x5601e805de40] [dec:hevc @ 0x5601e806ffc0] Hardware device setup failed for decoder: Cannot allocate memory
Error opening output file Venom.mp4.
Error opening output files: Cannot allocate memory
Что я делаю не так ? Что я должен поменять в опциях и аргументах, скармливаемых ffmpeg'у ?
131 Кб, 1251x454>>24077
Апдейт.
Тут конкретно забыл, что с DirectX'ом мне ничего на линуксе не светит. Но ничего, есть же Vulkan.
Скармливаю следующую команду:
ffmpeg -init_hw_device "vulkan=vk:0" -hwaccel vulkan -hwaccel_output_format vulkan -i Venom.mkv -vf "crop=iw:ih*16/9,scale=3840:2160" -c:v hevc_amf -b:v 10M -c:a aac -b:a 192k Venom.mp4
И опять ловлю ошибку на пикриле
Апдейт.
Тут конкретно забыл, что с DirectX'ом мне ничего на линуксе не светит. Но ничего, есть же Vulkan.
Скармливаю следующую команду:
ffmpeg -init_hw_device "vulkan=vk:0" -hwaccel vulkan -hwaccel_output_format vulkan -i Venom.mkv -vf "crop=iw:ih*16/9,scale=3840:2160" -c:v hevc_amf -b:v 10M -c:a aac -b:a 192k Venom.mp4
И опять ловлю ошибку на пикриле
>>24077
Черные полосы для того и лепят чтобы из широкоформатной киношной картинки (2.4:1) получить телевизионые 16:9 (1.78:1).
>с обрезкой черных полос, чтобы можно было нормально посмотреть его на 16:9 экране
Черные полосы для того и лепят чтобы из широкоформатной киношной картинки (2.4:1) получить телевизионые 16:9 (1.78:1).
Ну и crop фильтр, которым я регулярно пользуюсь, выглядит так
ffmpeg -i Cut.mp4 -vf "crop=1920:816:0:132" -c:v libsvtav1 -preset 5 -pix_fmt yuv420p10le -crf 25 -c:a copy OutputC.webm
А чтобы получить цифры для обрезки
ffmpeg -t 1 -i Input.mp4 -vf cropdetect Out.mp4
ffmpeg -i Cut.mp4 -vf "crop=1920:816:0:132" -c:v libsvtav1 -preset 5 -pix_fmt yuv420p10le -crf 25 -c:a copy OutputC.webm
А чтобы получить цифры для обрезки
ffmpeg -t 1 -i Input.mp4 -vf cropdetect Out.mp4
>>24077
Чтобы просто посмотреть? Это делается зумом на уровне видеоплеера, тебе туда: https://2ch.hk/s/res/3606041.html (М)
Чтобы просто посмотреть? Это делается зумом на уровне видеоплеера, тебе туда: https://2ch.hk/s/res/3606041.html (
М)Где-то читал, что кодирование на видюхе с нвенк даёт качество на выходе хуже, чем если кодировать на цпу. Это рили так?
>>24677
Да
Да
>>24677
С каждым новым поколением видеокарт разрыв в качестве сокращается, но на цпу пока еще лучше, хотя и дольше многократно.
С каждым новым поколением видеокарт разрыв в качестве сокращается, но на цпу пока еще лучше, хотя и дольше многократно.
>>24727
У меня 5000 серия, если слоу пресет выставить, насколько будет заметно, если, допустим, рипнуть 4к ремукс?
У меня 5000 серия, если слоу пресет выставить, насколько будет заметно, если, допустим, рипнуть 4к ремукс?
>>24731
Просто вырежь какую-нибудь сложную сцену на несколько минут длительности и сравни.
Просто вырежь какую-нибудь сложную сцену на несколько минут длительности и сравни.
>>24731
5000 серия на уровне CPU medium preset кодирует в x264, насчёт других кодеков не знаю.
5000 серия на уровне CPU medium preset кодирует в x264, насчёт других кодеков не знаю.
Самый большой байт по теме конвертации, который я испытывал, это ложь оффициальной инструкции гугла о заливе видео на ютаб, в котором грится, что файлы можно сконвертить в vp9: a) юзая -crf и -maxrate и -bufsize одновременно не используя b:v, разумеется (если запустишь, то конверт пойдет, но просто заруинишь конвертацию себе: смысла комбить crf+целевой битрейт – нуль)! b) и в два прохода! Просто сюююююююююр. Вот это маняфристайло воображаемое от квотного негра, писавшего это. Такое даже ни одна кастомная GUIшка не может. Только жадный виннипух со своим разваливающимся под собственным весом кодом смог реализовать подобную ебанину, но он сам не нужен, ибо скамит в код.
>>26731
VP9 это два подхода онли кодек так-то. Максрейт с црфом это разумно, чтобы отдельные участки видео в потолок не улетали, что тебе не нравится?
VP9 это два подхода онли кодек так-то. Максрейт с црфом это разумно, чтобы отдельные участки видео в потолок не улетали, что тебе не нравится?
>>00915 (OP)
Мне на телефоне на андроиде не видно сериалы из-за того что они слишком тёмные. Я смотрю через mx player. Раньше я исправлял это через перекодирования ффмпег с изменением чего-то сейчас не помню. Я вспомню кнешно. Но может уже есть способ повышать яркость видео без перекодирования?
Мне на телефоне на андроиде не видно сериалы из-за того что они слишком тёмные. Я смотрю через mx player. Раньше я исправлял это через перекодирования ффмпег с изменением чего-то сейчас не помню. Я вспомню кнешно. Но может уже есть способ повышать яркость видео без перекодирования?
>>26798
To adjust the brightness in MX Player on an Android device, you can either use the system's brightness controls or MX Player's built-in brightness adjustment. For the system controls, you can swipe down from the top of the screen to access the quick settings and adjust the brightness slider or navigate to Settings > Display > Brightness. Alternatively, MX Player allows you to adjust brightness by swiping up or down on the video screen.
Using MX Player's Brightness Control:
Open the MX Player app and navigate to the video you want to watch.
While playing the video, swipe up on the screen to increase the brightness or swipe down to decrease it
Troubleshooting:
If you're having trouble adjusting brightness, ensure that your phone's auto-brightness feature is disabled, as it might interfere with manual adjustments.
Some devices have a minimum brightness threshold, so you might not be able to make the screen as dark as the system setting allows.
If the screen is still too dim at full brightness, make sure power saving mode is off, as it can reduce brightness to save battery.
If you're still experiencing issues, you might need to check if any third-party apps are interfering with brightness control, as some apps can override MX Player's settings.
This video explains how to adjust brightness within MX Player using its built-in controls:
https://www.youtube.com/watch?v=2_-K7Hffiz8&t=39
To adjust the brightness in MX Player on an Android device, you can either use the system's brightness controls or MX Player's built-in brightness adjustment. For the system controls, you can swipe down from the top of the screen to access the quick settings and adjust the brightness slider or navigate to Settings > Display > Brightness. Alternatively, MX Player allows you to adjust brightness by swiping up or down on the video screen.
Using MX Player's Brightness Control:
Open the MX Player app and navigate to the video you want to watch.
While playing the video, swipe up on the screen to increase the brightness or swipe down to decrease it
Troubleshooting:
If you're having trouble adjusting brightness, ensure that your phone's auto-brightness feature is disabled, as it might interfere with manual adjustments.
Some devices have a minimum brightness threshold, so you might not be able to make the screen as dark as the system setting allows.
If the screen is still too dim at full brightness, make sure power saving mode is off, as it can reduce brightness to save battery.
If you're still experiencing issues, you might need to check if any third-party apps are interfering with brightness control, as some apps can override MX Player's settings.
This video explains how to adjust brightness within MX Player using its built-in controls:
https://www.youtube.com/watch?v=2_-K7Hffiz8&t=39
>>22655
-af "pan=stereo|FL_out=FL1+FC0.71+BL0.71+LFE1.58|FR_out=FR1+FC0.71+BR0.71+LFE1.58"
Не тестировал.
Вообще LFE нахуй не нужен в стерео и отбрасывать его распространенная практика.
-af "pan=stereo|FL_out=FL1+FC0.71+BL0.71+LFE1.58|FR_out=FR1+FC0.71+BR0.71+LFE1.58"
Не тестировал.
Вообще LFE нахуй не нужен в стерео и отбрасывать его распространенная практика.
>>26805
Ой иди нахуй с такими советами. И индуса своего забери.
Ой иди нахуй с такими советами. И индуса своего забери.
2 Кб, 725x17О погодьте, а если просто записать выхлоп экрана? Качество же не теряется?
>>26876
Поправил. Теперь огромный недобор по громкости у итого файла, но ладно то поправить ампом можно.
Но после этого файл идентичен - нехватка баса какая-то.
Поправил. Теперь огромный недобор по громкости у итого файла, но ладно то поправить ампом можно.
Но после этого файл идентичен - нехватка баса какая-то.
Привет, аноны. Пресет veryslow для AVC создает файлы с профилем High@L5. Плохо ли это для видосов для двача, телеги, и в целом для онлайна (ну и просмотра в софтверном видеоплеере)? Так-то они везде воспроизводятся, но мб я упускаю из вида какой-то важный аспект.
>>24077
Я что-то нихуя не понял.
Твой фильм, видимо, с широкоформатным киношным соотношением сторон около 2.4:1 (типа 3840x1600). В нем черные полосы, потому что в исходниках (в блюреях - всегда, в стриминговых вебдл - часто) кадр добивается до 16:9 (3840x2160) для соответствия техническим спецификациям устройств.
Если ты собираешься смотреть на 16:9 экране, то тебе должно быть абсолютно похуй на наличие или отсутствие черных полос в кадрах видеоряда, оно будет буквально выглядеть идентично: и 3840x1600, добитый черными полосами до 3840x2160, и "просто" 3840x1600 заполняют экран 3840x2160 абсолютно одинаково.
Но, судя по вот этому:
Ты, видимо, хочешь обрезать И черные полосы (если они есть в видеоряде), и ТАКЖЕ какую-то часть осмысленной картинки самих кадров слева и справа, чтобы обрезать по ширине свой 2.4:1 в 16:9, типа из 3840x1600 сделать ~2844x1600 (16:9) и затем растянуть этот результат на весь экран?
Тебе для этого не надо перекодировать, для просмотра можешь просто сделать соответствующий зум в своем видеоплеере.
а также это хуевая идея. ты обрежешь слишком много полезной визуальной информации слева и справа, а также картинка в целом будет выглядеть неестественно приближенной, неестественно крупной. лучше поищи, существует ли для твоего фильма open matte версия, раскрывающая кадр вверх и вниз больше по сравнению с театральной версией.
>Хочу перекодировать один 4K фильмец (размером с 21 GB, есл это важно) с обрезкой черных полос, чтобы можно было нормально посмотреть его на 16:9 экранею - да, понимаю , что ffmpeg лишних пикселей не нарисует, но я лучше потеряю, в том или ином виде, какую-то долю разрешения, чем соглашусь смотреть черные полосы сверху и снизу экрана.
Я что-то нихуя не понял.
Твой фильм, видимо, с широкоформатным киношным соотношением сторон около 2.4:1 (типа 3840x1600). В нем черные полосы, потому что в исходниках (в блюреях - всегда, в стриминговых вебдл - часто) кадр добивается до 16:9 (3840x2160) для соответствия техническим спецификациям устройств.
Если ты собираешься смотреть на 16:9 экране, то тебе должно быть абсолютно похуй на наличие или отсутствие черных полос в кадрах видеоряда, оно будет буквально выглядеть идентично: и 3840x1600, добитый черными полосами до 3840x2160, и "просто" 3840x1600 заполняют экран 3840x2160 абсолютно одинаково.
Но, судя по вот этому:
> понимаю , что ffmpeg лишних пикселей не нарисует, но я лучше потеряю, в том или ином виде, какую-то долю разрешения, чем соглашусь смотреть черные полосы сверху и снизу экрана.
Ты, видимо, хочешь обрезать И черные полосы (если они есть в видеоряде), и ТАКЖЕ какую-то часть осмысленной картинки самих кадров слева и справа, чтобы обрезать по ширине свой 2.4:1 в 16:9, типа из 3840x1600 сделать ~2844x1600 (16:9) и затем растянуть этот результат на весь экран?
Тебе для этого не надо перекодировать, для просмотра можешь просто сделать соответствующий зум в своем видеоплеере.
а также это хуевая идея. ты обрежешь слишком много полезной визуальной информации слева и справа, а также картинка в целом будет выглядеть неестественно приближенной, неестественно крупной. лучше поищи, существует ли для твоего фильма open matte версия, раскрывающая кадр вверх и вниз больше по сравнению с театральной версией.
>>27018
Железо, выпущенное до 2016 года примерно (смартфоны, телевизоры), не умеет проигрывать very slow c L5 (в very slow презете на самом деле целая чехарда неподдерживаемых параметров, дело не в L5 как таковом, ты можешь вручную все параметры прописать для сохранения совместимости и улучшения сжатия), поэтому во всём мире до сих пор стандартом идёт normal L4, чтобы нищее быдло могло смотреть.
Если тебе похуй на 2% говна, то сжимай в very slow, и результат будет сильно лучше визуально и компрессия будет при этом выше.
Железо, выпущенное до 2016 года примерно (смартфоны, телевизоры), не умеет проигрывать very slow c L5 (в very slow презете на самом деле целая чехарда неподдерживаемых параметров, дело не в L5 как таковом, ты можешь вручную все параметры прописать для сохранения совместимости и улучшения сжатия), поэтому во всём мире до сих пор стандартом идёт normal L4, чтобы нищее быдло могло смотреть.
Если тебе похуй на 2% говна, то сжимай в very slow, и результат будет сильно лучше визуально и компрессия будет при этом выше.
>>27018
Хуйня без задач на самом деле. Разница в качестве в сравнении с дефолтным medium минимальна, а время кодирования выше в несколько раз. Если сильно сжимать разница в качестве более заметна, но картинка в любом случае будет шакальной потому что AVC на низком битрейте это жалкое зрелище.
>veryslow для AVC
Хуйня без задач на самом деле. Разница в качестве в сравнении с дефолтным medium минимальна, а время кодирования выше в несколько раз. Если сильно сжимать разница в качестве более заметна, но картинка в любом случае будет шакальной потому что AVC на низком битрейте это жалкое зрелище.
>>27110
Это абсолютная ложь от нищего пидораса, никогда не видевшего контент на большом экране, в мелких деталях very slow в x264 с соответствующим битрейтом выглядит НАМНОГО лучше, чем medium и НАМНОГО лучше, чем HEVC (H.265), VP9, или AV1.
Выкрученный в максимум x264 сильно лучше ебаного мыла во всём современном дерьме, рассчитанном на стриминг мыльных сериалов быдлу.
Это абсолютная ложь от нищего пидораса, никогда не видевшего контент на большом экране, в мелких деталях very slow в x264 с соответствующим битрейтом выглядит НАМНОГО лучше, чем medium и НАМНОГО лучше, чем HEVC (H.265), VP9, или AV1.
Выкрученный в максимум x264 сильно лучше ебаного мыла во всём современном дерьме, рассчитанном на стриминг мыльных сериалов быдлу.
>>27201
Ну то есть если дать очень высокий битрейт то картинка будет детализированной. Ого, вот это поворот, кто бы мог подумать!
Во первых если для тебя не важен размер файла то и продвинутые кодеки тебе не нужны, просто храни Remux'ы.
Во вторых тебе четко обозначили условия
то есть никаких больших экранов и космических битрейтов. И в данных условиях пресет veryslow это хуйня без задач.
В третьих
зашивайся, тебя на ровном месте разворотило.
>в мелких деталях very slow в x264 с соответствующим битрейтом выглядит НАМНОГО лучше, чем medium и НАМНОГО лучше, чем HEVC (H.265), VP9, или AV1
>с соответствующим битрейтом
Ну то есть если дать очень высокий битрейт то картинка будет детализированной. Ого, вот это поворот, кто бы мог подумать!
Во первых если для тебя не важен размер файла то и продвинутые кодеки тебе не нужны, просто храни Remux'ы.
Во вторых тебе четко обозначили условия
>для видосов для двача, телеги, и в целом для онлайна
то есть никаких больших экранов и космических битрейтов. И в данных условиях пресет veryslow это хуйня без задач.
В третьих
>абсолютная ложь от нищего пидораса
>ебаного мыла во всём современном дерьме
>стриминг мыльных сериалов быдлу
зашивайся, тебя на ровном месте разворотило.
Пожал примерно в 6.5 раз - medium немного хуже veryslow по качеству и немного больше по размеру, но почти в 9 раз быстрее. Оба выглядят не очень и далеко позади шестого пресета AV1 (который при этом втрое быстрее AVC veryslow).
Звук везде Opus 36k и кодировалось в 10 бит для чистоты эксперимента.
Звук везде Opus 36k и кодировалось в 10 бит для чистоты эксперимента.
То же самое, но поднял битрейт примерно вдвое. Картина принципиально не меняется - только отставание от AV1 подсократилось.
33,4 Мб, mp4,1920x1080, 0:30
Оригинал.
Сравниваем slow и veryslow на помойном битрейте (4 мегабайта для форчана) на сцене с большим количеством мельтешения.
>>27348
На чём и чем сжимал?
Ты же в курсе, что современное железо и алгоритмы сжатия специально подтасованы не для выдачи заебательской картинки, а для выдачи красивых циферок в VMAF тесте и схожих ему? Он давно уже нерелевантен, примерно с момента появления !!!10 лет!!! назад, это буквально наёбка гоев, от которой у всех спецов жопа горит, т.к. инструмента для оценки качества нет, нужно каждое видео глазками смотреть.
А в современных AI моделях вообще сказочное наебалово алгоритмов.
Если мыльцо и полное затирание мелких элементов считается превосходством, то я тут бессилен.
>>27252
Сравнение в FullHD, для которого рекомендованный диапазон начинается с crf 18, с битрейтом 2600, которому соответствует crf 28(нижняя допустимая граница диапазона для этого разрешения), - просто смешно.
6000, 8000 - это не "очень высокий битрейт", это хуйня, высокий для FullHD начинается от 13-16k.
На чём и чем сжимал?
Ты же в курсе, что современное железо и алгоритмы сжатия специально подтасованы не для выдачи заебательской картинки, а для выдачи красивых циферок в VMAF тесте и схожих ему? Он давно уже нерелевантен, примерно с момента появления !!!10 лет!!! назад, это буквально наёбка гоев, от которой у всех спецов жопа горит, т.к. инструмента для оценки качества нет, нужно каждое видео глазками смотреть.
А в современных AI моделях вообще сказочное наебалово алгоритмов.
>далеко позади шестого пресета AV1
Если мыльцо и полное затирание мелких элементов считается превосходством, то я тут бессилен.
>>27252
>если дать очень высокий битрейт
Сравнение в FullHD, для которого рекомендованный диапазон начинается с crf 18, с битрейтом 2600, которому соответствует crf 28(нижняя допустимая граница диапазона для этого разрешения), - просто смешно.
6000, 8000 - это не "очень высокий битрейт", это хуйня, высокий для FullHD начинается от 13-16k.
>>27412
Кстати, ракурс сбоку и немного издалека в середине видоса - это на самом деле 2x зум из хорошего 4K исходника. В оригинале этот кадр выглядит вот так (обвел рамочкой приближение). Спасибо тебе господи за настоящее нативное неапскейльное 4K в 2025 году, благодаря которому можно сильно зумить.
Ну и вот заодно, смотрите какая разница между двумя источниками 4K SDR. У Амазона получился удивительно всратый энкод.
Кстати, ракурс сбоку и немного издалека в середине видоса - это на самом деле 2x зум из хорошего 4K исходника. В оригинале этот кадр выглядит вот так (обвел рамочкой приближение). Спасибо тебе господи за настоящее нативное неапскейльное 4K в 2025 году, благодаря которому можно сильно зумить.
Ну и вот заодно, смотрите какая разница между двумя источниками 4K SDR. У Амазона получился удивительно всратый энкод.
>>27425
Каким зерном, это фильм 2025 года, снятый на цифру.
Амазон ебанули шарпа и сделали "текстуры" более заметными, но при этом потеряли осмысленные детали картинки. А с темными областями произошла совсем пизда. Посмотри на небо на первых двух пнг в том сообщении, на волосы девушки на вторых двух пнг (это вообще получился брак какой-то, в движении эти артефакты вообще мигают на волосах). Или вот еще сравнение - темные области типа неба и внутрянки фургона все в шакалах. На первый взгляд может показаться, что "текстуры" (на не ушатанных в мясо поверхностях) как будто бы заметнее и лучше, но на самом деле деталей больше в канадском источнике, вон даже складка толстовки на спине мужика отлично видна, а у Амазона потонула в шакалах и фейковой текстуре.
Каким зерном, это фильм 2025 года, снятый на цифру.
Амазон ебанули шарпа и сделали "текстуры" более заметными, но при этом потеряли осмысленные детали картинки. А с темными областями произошла совсем пизда. Посмотри на небо на первых двух пнг в том сообщении, на волосы девушки на вторых двух пнг (это вообще получился брак какой-то, в движении эти артефакты вообще мигают на волосах). Или вот еще сравнение - темные области типа неба и внутрянки фургона все в шакалах. На первый взгляд может показаться, что "текстуры" (на не ушатанных в мясо поверхностях) как будто бы заметнее и лучше, но на самом деле деталей больше в канадском источнике, вон даже складка толстовки на спине мужика отлично видна, а у Амазона потонула в шакалах и фейковой текстуре.
>>27418
Начнем с того что сравнивать видео по статичным кадрам и высматривать отдельные пиксели это бред.
Мои субъективные ощущения от просмотра хорошо коррелируют с оценкой VMAF. В динамике AV1 смотрится лучше, разница между пресетами AVC незаметна.
Потеря мелких деталей это абсолютно нормально когда ты роняешь битрейт в 3-6 или больше раз.
Бро, никому не нужно в телеге/на двоще видео с битрейтом 15к. Поэтому совершенно не важно как ведут себя кодеки на таких битрейтах. И я сравниваю в тех битрейтах которые имеют смысл для данной конкретной задачи.
Начнем с того что сравнивать видео по статичным кадрам и высматривать отдельные пиксели это бред.
>а для выдачи красивых циферок в VMAF тесте
Мои субъективные ощущения от просмотра хорошо коррелируют с оценкой VMAF. В динамике AV1 смотрится лучше, разница между пресетами AVC незаметна.
Потеря мелких деталей это абсолютно нормально когда ты роняешь битрейт в 3-6 или больше раз.
>высокий для FullHD начинается от 13-16k
>для видосов для двача, телеги, и в целом для онлайна
Бро, никому не нужно в телеге/на двоще видео с битрейтом 15к. Поэтому совершенно не важно как ведут себя кодеки на таких битрейтах. И я сравниваю в тех битрейтах которые имеют смысл для данной конкретной задачи.
>>27201
Кому ты пиздишь?
https://imgsli.com/NDAyODY3
>в мелких деталях very slow в x264 с соответствующим битрейтом выглядит НАМНОГО лучше, чем medium и НАМНОГО лучше, чем HEVC (H.265), VP9, или AV1.
Кому ты пиздишь?
https://imgsli.com/NDAyODY3
>>27473
Слабоумие и отвага. Медицина бессильна.
Слабоумие и отвага. Медицина бессильна.
>>27420
>>27436
Различия на кадрах минимальны, видны только если целенаправленно их выискивать и никак не влияют на восприятие картины в целом. Вот серьезно, кому не похер на какие-то складки, волоски, текстуру подушки и т.д.?
Ну так наверное стоит выложить видео чтобы можно было оценить в движении. Потому что статичные кадры выглядят одинаково качественными и я не могу сказать что какой-то из них хороший или плохой.
>>27436
Различия на кадрах минимальны, видны только если целенаправленно их выискивать и никак не влияют на восприятие картины в целом. Вот серьезно, кому не похер на какие-то складки, волоски, текстуру подушки и т.д.?
>в движении эти артефакты вообще мигают на волосах
Ну так наверное стоит выложить видео чтобы можно было оценить в движении. Потому что статичные кадры выглядят одинаково качественными и я не могу сказать что какой-то из них хороший или плохой.
>>27473
Да забей, для него соответствующий битрейт это 15М+. А НАМНОГО - это те самые несущественные детали.
Вполне допускаю что в его понимании на таких битрейтах H.264 действительно будет выглядеть лучше AV1 (который создавался и оптимизировался именно для эффективного сжатия видеопотока, а режим кодирования без потерь в нем отсутствует в принципе). Хотя для меня все что имеет VMAF 95+ выглядит одинаково и лучшим является то видео которое имеет самый низкий битрейт. Это вопрос восприятия.
Да забей, для него соответствующий битрейт это 15М+. А НАМНОГО - это те самые несущественные детали.
Вполне допускаю что в его понимании на таких битрейтах H.264 действительно будет выглядеть лучше AV1 (который создавался и оптимизировался именно для эффективного сжатия видеопотока, а режим кодирования без потерь в нем отсутствует в принципе). Хотя для меня все что имеет VMAF 95+ выглядит одинаково и лучшим является то видео которое имеет самый низкий битрейт. Это вопрос восприятия.
18,6 Мб, mp4,3840x2160, 0:10
>>27526
Ладно, да, тут ты прав.
Вот вырезал без перекодирования этот фрагмент. Энкод не мой, это с двух разных стримингов (Амазон vs. неназванный канадский), я просто вырезал по ключевым кадрам.
Но:
Да я не верю, что ты это серьезно. На каком экране ты смотришь? Я без подъеба, потому что не увидеть брак на темных областях кадров (волосы девушки, небо на тех других кадрах на улице и т.д.) - это надо смотреть на какой-нибудь TN матрице, наверное.
Я (при обычном просмотре фильма, еще даже не подозревая о наличии альтернативного источника) смотрел версию с Амазона и эту хуйню видел даже не вглядываясь.
>Ну так наверное стоит выложить видео чтобы можно было оценить в движении.
Ладно, да, тут ты прав.
Вот вырезал без перекодирования этот фрагмент. Энкод не мой, это с двух разных стримингов (Амазон vs. неназванный канадский), я просто вырезал по ключевым кадрам.
Но:
> Потому что статичные кадры выглядят одинаково качественными
Да я не верю, что ты это серьезно. На каком экране ты смотришь? Я без подъеба, потому что не увидеть брак на темных областях кадров (волосы девушки, небо на тех других кадрах на улице и т.д.) - это надо смотреть на какой-нибудь TN матрице, наверное.
Я (при обычном просмотре фильма, еще даже не подозревая о наличии альтернативного источника) смотрел версию с Амазона и эту хуйню видел даже не вглядываясь.
33,3 Мб, mp4,3840x1606, 0:10
>>27546
... а вот канадский (оба вместе не влезли в 40 МБ на пост)
У Амазона волосы превратились в цветное пятно с огромными прыгающими прямоугольниками шакалов). И точно так же на протяжении всего фильма с самыми разными темными областями кадров.
Еще Амазон как-то хуево расставили ключевые кадры, у канадского стриминга они почти всегда присутствуют на смене ракурса, у Амазона стоят хз где.
... а вот канадский (оба вместе не влезли в 40 МБ на пост)
У Амазона волосы превратились в цветное пятно с огромными прыгающими прямоугольниками шакалов). И точно так же на протяжении всего фильма с самыми разными темными областями кадров.
Еще Амазон как-то хуево расставили ключевые кадры, у канадского стриминга они почти всегда присутствуют на смене ракурса, у Амазона стоят хз где.
>>27425
Кстати, анон, скажи, какие из этих кадров тебе кажутся лучше?
Кстати, анон, скажи, какие из этих кадров тебе кажутся лучше?
![Dead Sea 2024 1080p AMZN WEB-DL DDP5 1 H 264-HypStu.mkvsnapshot01.10.46[2024.08.0508.24.49] cropped for comparison.png](https://2ch.life//s/src/3600915/17539859273362.png)
![dead.sea.2024.1080p.bluray.x264-justwatch.mkvsnapshot01.10.43[2024.09.1022.28.29].png](https://2ch.life//s/src/3600915/17539859273473.png)
>>27603
Вот только они буквально нейроретушь. AI enhanced, перерисовка. Обрати внимание: восковые лица, все волосы (в т.ч. усы) превращаются в однородную кашу с проскакивающими тонкими линиями некоторых волосинок, исчезают исошные шумы съемки и превращаются в градиенты, при этом неестественно задранная прорисовка всего, что выглядит как линии или текстуры (например, узор пиджака женщины, кожаное кресло), с нехарактерной для реальной съемки резкостью. И в целом все покрыто такой как бы "пленкой", не совсем буквально, но слой лощености и легкого блума. В результате это выглядит как типичная нейрорисовка, хотя "исходник" здесь - настоящее запечатленное камерой изображение.
И эта ретушь сделана не мной, а производителем немецкого блюрея, откуда взяты эти кадры. В последние года три тамошний немецкий издатель принялся поливать картинку на немецких блюреях вот этой ретушью - это либо инициатива издателя / прокатчика как такового, либо мб это делает контора, которая готовит энкоды / авторинг блюреев.
Это есть уже на куче фильмов. И проблема в том, что Германия - одна из последних стран, где достаточно регулярно выходят блюреи недорогих фильмов. Получается выбор между низкобитрейтным веб-дл (который без этой хуйни) и блюреем, который выглядит вот так. (на моих скринах этого фильма - сравнение итальянского блюрея с немецким, но у большинства других фильмов нет никаких альтернативных блюреев, итальянских или каких-либо еще).
3 и 4 - из другого фильма, та же самая история, разница между "международным" веб-дл и немецким блюреем. (правда, здесь на скрине блюрей-рип (т.е. не ремукс, а энкод), но все равно разница в самом трансфере видна).
>Второй и четвертый выглядят более четкими
Вот только они буквально нейроретушь. AI enhanced, перерисовка. Обрати внимание: восковые лица, все волосы (в т.ч. усы) превращаются в однородную кашу с проскакивающими тонкими линиями некоторых волосинок, исчезают исошные шумы съемки и превращаются в градиенты, при этом неестественно задранная прорисовка всего, что выглядит как линии или текстуры (например, узор пиджака женщины, кожаное кресло), с нехарактерной для реальной съемки резкостью. И в целом все покрыто такой как бы "пленкой", не совсем буквально, но слой лощености и легкого блума. В результате это выглядит как типичная нейрорисовка, хотя "исходник" здесь - настоящее запечатленное камерой изображение.
И эта ретушь сделана не мной, а производителем немецкого блюрея, откуда взяты эти кадры. В последние года три тамошний немецкий издатель принялся поливать картинку на немецких блюреях вот этой ретушью - это либо инициатива издателя / прокатчика как такового, либо мб это делает контора, которая готовит энкоды / авторинг блюреев.
Это есть уже на куче фильмов. И проблема в том, что Германия - одна из последних стран, где достаточно регулярно выходят блюреи недорогих фильмов. Получается выбор между низкобитрейтным веб-дл (который без этой хуйни) и блюреем, который выглядит вот так. (на моих скринах этого фильма - сравнение итальянского блюрея с немецким, но у большинства других фильмов нет никаких альтернативных блюреев, итальянских или каких-либо еще).
3 и 4 - из другого фильма, та же самая история, разница между "международным" веб-дл и немецким блюреем. (правда, здесь на скрине блюрей-рип (т.е. не ремукс, а энкод), но все равно разница в самом трансфере видна).
>>27715
Откуда такая страсть к сохранению шумов? Это же бесполезная информация, на сохранение которой уходит часть битрейта.
>исчезают исошные шумы съемки
Откуда такая страсть к сохранению шумов? Это же бесполезная информация, на сохранение которой уходит часть битрейта.
>>27729
Если стремиться убирать "бесполезную информацию", то можно прийти и к 700 МБ DivX рипам киношек. Ведь полезная информация в них все равно видна (кто говорит и кто кого бьет и какая на них одежда), а все остальное - бесполезная информация.
Шумы, как и остальные прочие описанные там детали - это не бесполезная информация, а то, что делает реально запечатленное фотографическое изображение именно фоткой на вид, а не рисунком или нейрослопом (то есть опять же рисунком). Картинки 1 и 3 в постах >>27549 и >>27715 выглядят как настоящие фото (ну, как кадры из настоящего видео), а картинки 2 и 4 - как рисунок или обработанная фильтрами фотка, то есть рисунок "по мотивам" фотки. Ну они же буквально не выглядят как естественные фото/кадры, ожидаемые от съемки камерой. Угадай, на что мне хочется смотреть при просмотре кинофильма.
Это касается вообще не только особенностей кодирования видео или применения фильтров, но даже и фпс или цветокора. Хуйня, записанная дефолтным образом на телефон, выглядит совершенно не кинематографично. Тут вопрос не в том, при каком варианте запечатлевается больше полезных деталей, а в том, что выглядит как фото или киновидео (соответствует таковому внешнему виду), а что не выглядит.
Если стремиться убирать "бесполезную информацию", то можно прийти и к 700 МБ DivX рипам киношек. Ведь полезная информация в них все равно видна (кто говорит и кто кого бьет и какая на них одежда), а все остальное - бесполезная информация.
Шумы, как и остальные прочие описанные там детали - это не бесполезная информация, а то, что делает реально запечатленное фотографическое изображение именно фоткой на вид, а не рисунком или нейрослопом (то есть опять же рисунком). Картинки 1 и 3 в постах >>27549 и >>27715 выглядят как настоящие фото (ну, как кадры из настоящего видео), а картинки 2 и 4 - как рисунок или обработанная фильтрами фотка, то есть рисунок "по мотивам" фотки. Ну они же буквально не выглядят как естественные фото/кадры, ожидаемые от съемки камерой. Угадай, на что мне хочется смотреть при просмотре кинофильма.
Это касается вообще не только особенностей кодирования видео или применения фильтров, но даже и фпс или цветокора. Хуйня, записанная дефолтным образом на телефон, выглядит совершенно не кинематографично. Тут вопрос не в том, при каком варианте запечатлевается больше полезных деталей, а в том, что выглядит как фото или киновидео (соответствует таковому внешнему виду), а что не выглядит.
>>27735
Шумы как раз являются бесполезной информацией (даже больше - это дефект, связанный с физикой процесса съемки) в отличии от всего остального. Функции шумоподавления добавляются производителями фото-/видеотехники не просто так.
>Шумы, как и остальные прочие описанные там детали - это не бесполезная информация
Шумы как раз являются бесполезной информацией (даже больше - это дефект, связанный с физикой процесса съемки) в отличии от всего остального. Функции шумоподавления добавляются производителями фото-/видеотехники не просто так.
>>27811
Джеймс, мы все уже давно поняли, что ты не любишь зерно и зум, иди дальше перевыпускай свои ремастеры старых фильмов.
Джеймс, мы все уже давно поняли, что ты не любишь зерно и зум, иди дальше перевыпускай свои ремастеры старых фильмов.
зерно и шум*
Кино на диске занимает много места, подскажите нубасу, с помощью каких настроек сжатия можно сократить размер файла без сильных потерь в качестве? Фильмы в основном в 1080p, BD-рипы. Так же размер файла раздувают лишние озвучки, которые мне не нужны. Как можно удалить их из файла?
>>28015
Закодирует кусок с десятой по двенадцатую минуты. Просто чтобы оценить качество видео/звука и скорость кодирования, когда подберешь нужные параметры - удали, тогда перекодируется фильм целиком.
Выбор видеопотока. Формально он один, но если не указать явно то при выборе аудиодорожки видео вообще не будет кодироваться.
Кодирование в 10 бит для лучшего качества.
Используемый кодек и его основные параметры. Поиграйся с ними чтобы найти приемлимый для тебя баланс между качеством, битрейтом и скоростью кодирования.
Пресеты - от 1 до 13, чем ниже - тем лучше качество и сжатие, но выше время кодирования. 1-3 очень медленные, 10-13 дают много артефактов. Я использую только 4, 5 или 6.
crf - от 1 до 63, чем ниже - тем лучше качество, но выше битрейт.
Дополнительные параметры для немного лучшего сжатия, можно пропустить.
Выбор аудиодорожки, вместо N номер нужной, нумерация начинается с нуля.
-ac 6 -c:a libopus -b:a 128k
Звук я кодирую в Opus. Если на твоей дорожке звук двухканальный параметр -ac можно пропустить. Если шестиканальный и ты хочешь его таким и оставить нужно указать -ac 6 (иначе выдаст ошибку), битрейт от 128k (можешь повысить если не устроит качество). Если шестиканальный, но тебе он не нужен - укажи -ac 2 для преобразования в обычное стерео. Для двухканального звука я использую битрейт в диапазоне 36-48k.
Выходной контейнер, можно и в .mp4 запихнуть при желании.
>сократить размер файла без сильных потерь в качестве
>лишние озвучки, которые мне не нужны
>ffmpeg -ss 00:10:00 -t 180 -i Input.mkv -map 0:v:0 -pix_fmt yuv420p10le -c:v libsvtav1 -preset 6 -crf 32 -svtav1-params tune=0:enable-qm=1:qm-min=0:qm-max=8 -map 0:a:0 -ac 6 -c:a libopus -b:a 128k Output.webm
>-ss 00:10:00 -t 120
Закодирует кусок с десятой по двенадцатую минуты. Просто чтобы оценить качество видео/звука и скорость кодирования, когда подберешь нужные параметры - удали, тогда перекодируется фильм целиком.
>-map 0:v:0
Выбор видеопотока. Формально он один, но если не указать явно то при выборе аудиодорожки видео вообще не будет кодироваться.
>-pix_fmt yuv420p10le
Кодирование в 10 бит для лучшего качества.
>-c:v libsvtav1 -preset 6 -crf 32
Используемый кодек и его основные параметры. Поиграйся с ними чтобы найти приемлимый для тебя баланс между качеством, битрейтом и скоростью кодирования.
Пресеты - от 1 до 13, чем ниже - тем лучше качество и сжатие, но выше время кодирования. 1-3 очень медленные, 10-13 дают много артефактов. Я использую только 4, 5 или 6.
crf - от 1 до 63, чем ниже - тем лучше качество, но выше битрейт.
>-svtav1-params tune=0:enable-qm=1:qm-min=0:qm-max=8
Дополнительные параметры для немного лучшего сжатия, можно пропустить.
>-map 0:a:N
Выбор аудиодорожки, вместо N номер нужной, нумерация начинается с нуля.
-ac 6 -c:a libopus -b:a 128k
Звук я кодирую в Opus. Если на твоей дорожке звук двухканальный параметр -ac можно пропустить. Если шестиканальный и ты хочешь его таким и оставить нужно указать -ac 6 (иначе выдаст ошибку), битрейт от 128k (можешь повысить если не устроит качество). Если шестиканальный, но тебе он не нужен - укажи -ac 2 для преобразования в обычное стерео. Для двухканального звука я использую битрейт в диапазоне 36-48k.
>Output.webm
Выходной контейнер, можно и в .mp4 запихнуть при желании.
>>28015
Закодирует кусок с десятой по двенадцатую минуты. Просто чтобы оценить качество видео/звука и скорость кодирования, когда подберешь нужные параметры - удали, тогда перекодируется фильм целиком.
Выбор видеопотока. Формально он один, но если не указать явно то при выборе аудиодорожки видео вообще не будет кодироваться.
Кодирование в 10 бит для лучшего качества.
Используемый кодек и его основные параметры. Поиграйся с ними чтобы найти приемлимый для тебя баланс между качеством, битрейтом и скоростью кодирования.
Пресеты - от 1 до 13, чем ниже - тем лучше качество и сжатие, но выше время кодирования. 1-3 очень медленные, 10-13 дают много артефактов. Я использую только 4, 5 или 6.
crf - от 1 до 63, чем ниже - тем лучше качество, но выше битрейт.
Дополнительные параметры для немного лучшего сжатия, можно пропустить.
Выбор аудиодорожки, вместо N номер нужной, нумерация начинается с нуля.
-ac 6 -c:a libopus -b:a 128k
Звук я кодирую в Opus. Если на твоей дорожке звук двухканальный параметр -ac можно пропустить. Если шестиканальный и ты хочешь его таким и оставить нужно указать -ac 6 (иначе выдаст ошибку), битрейт от 128k (можешь повысить если не устроит качество). Если шестиканальный, но тебе он не нужен - укажи -ac 2 для преобразования в обычное стерео. Для двухканального звука я использую битрейт в диапазоне 36-48k.
Выходной контейнер, можно и в .mp4 запихнуть при желании.
>сократить размер файла без сильных потерь в качестве
>лишние озвучки, которые мне не нужны
>ffmpeg -ss 00:10:00 -t 180 -i Input.mkv -map 0:v:0 -pix_fmt yuv420p10le -c:v libsvtav1 -preset 6 -crf 32 -svtav1-params tune=0:enable-qm=1:qm-min=0:qm-max=8 -map 0:a:0 -ac 6 -c:a libopus -b:a 128k Output.webm
>-ss 00:10:00 -t 120
Закодирует кусок с десятой по двенадцатую минуты. Просто чтобы оценить качество видео/звука и скорость кодирования, когда подберешь нужные параметры - удали, тогда перекодируется фильм целиком.
>-map 0:v:0
Выбор видеопотока. Формально он один, но если не указать явно то при выборе аудиодорожки видео вообще не будет кодироваться.
>-pix_fmt yuv420p10le
Кодирование в 10 бит для лучшего качества.
>-c:v libsvtav1 -preset 6 -crf 32
Используемый кодек и его основные параметры. Поиграйся с ними чтобы найти приемлимый для тебя баланс между качеством, битрейтом и скоростью кодирования.
Пресеты - от 1 до 13, чем ниже - тем лучше качество и сжатие, но выше время кодирования. 1-3 очень медленные, 10-13 дают много артефактов. Я использую только 4, 5 или 6.
crf - от 1 до 63, чем ниже - тем лучше качество, но выше битрейт.
>-svtav1-params tune=0:enable-qm=1:qm-min=0:qm-max=8
Дополнительные параметры для немного лучшего сжатия, можно пропустить.
>-map 0:a:N
Выбор аудиодорожки, вместо N номер нужной, нумерация начинается с нуля.
-ac 6 -c:a libopus -b:a 128k
Звук я кодирую в Opus. Если на твоей дорожке звук двухканальный параметр -ac можно пропустить. Если шестиканальный и ты хочешь его таким и оставить нужно указать -ac 6 (иначе выдаст ошибку), битрейт от 128k (можешь повысить если не устроит качество). Если шестиканальный, но тебе он не нужен - укажи -ac 2 для преобразования в обычное стерео. Для двухканального звука я использую битрейт в диапазоне 36-48k.
>Output.webm
Выходной контейнер, можно и в .mp4 запихнуть при желании.
>>28015
>>28046
Я думаю, ему будет намного лучше просто качать готовые маленькие рипы от групп типа RARBG и YTS/YIFY и им подобных. (которые бывают и в h265/hevc, а не только в h264/avc).
1. AV1 не факт что будет кодироваться с приемлемой скоростью на его машине (а мб и с воспроизведением могут быть проблемы)
2. Пережимать исходник-РИП (который уже был однажды кем-то пережат) еще раз ради уменьшения размера, скажем, всего лишь до 70-80% от оригинала - бессмысленно и будет выглядеть хуевее, чем могло бы (лучше уж тогда брать исходный ремукс и жать его, а анон вряд ли будет настолько аутировать, раз у него даже рипам тесновато на диске). А если ужимать намного больше, то вот же они готовые рипы на пару гигов от указанных групп.
3.
Скачай MKVToolNix -> брось в главное окно программы mkvtoolnix-gui свой видеофайл - убери галочки с ненужных тебе составляющих (лишние аудиодорожки, лишние субтитры) -> нажми Start multiplexing внизу -> получишь новый файл БЕЗ перекодирования видео, просто пересобранный без ненужных потоков типа лишних аудиодорожек. Занимает пару минут (ничего не перекодируется, просто нужное содержимое исходника записывается в новый файл), весит меньше, особенно если аудиодорожек было дохера, а тебе нужны всего 1-2 (ориг англ + рус).
>>28046
Я думаю, ему будет намного лучше просто качать готовые маленькие рипы от групп типа RARBG и YTS/YIFY и им подобных. (которые бывают и в h265/hevc, а не только в h264/avc).
1. AV1 не факт что будет кодироваться с приемлемой скоростью на его машине (а мб и с воспроизведением могут быть проблемы)
2. Пережимать исходник-РИП (который уже был однажды кем-то пережат) еще раз ради уменьшения размера, скажем, всего лишь до 70-80% от оригинала - бессмысленно и будет выглядеть хуевее, чем могло бы (лучше уж тогда брать исходный ремукс и жать его, а анон вряд ли будет настолько аутировать, раз у него даже рипам тесновато на диске). А если ужимать намного больше, то вот же они готовые рипы на пару гигов от указанных групп.
3.
>Так же размер файла раздувают лишние озвучки, которые мне не нужны. Как можно удалить их из файла?
Скачай MKVToolNix -> брось в главное окно программы mkvtoolnix-gui свой видеофайл - убери галочки с ненужных тебе составляющих (лишние аудиодорожки, лишние субтитры) -> нажми Start multiplexing внизу -> получишь новый файл БЕЗ перекодирования видео, просто пересобранный без ненужных потоков типа лишних аудиодорожек. Занимает пару минут (ничего не перекодируется, просто нужное содержимое исходника записывается в новый файл), весит меньше, особенно если аудиодорожек было дохера, а тебе нужны всего 1-2 (ориг англ + рус).
>>28052
Да, возможно. Но надо попробовать чтобы узнать наверняка.
Согласен, если жать - то сразу раза в 3-4. AV1 неплохо с этим справляется.
AVC при таком уровне сжатия сильно теряет в качестве. HEVC надо будет потестить.
>AV1 не факт что будет кодироваться с приемлемой скоростью на его машине
Да, возможно. Но надо попробовать чтобы узнать наверняка.
>всего лишь до 70-80% от оригинала - бессмысленно и будет выглядеть хуевее, чем могло бы
Согласен, если жать - то сразу раза в 3-4. AV1 неплохо с этим справляется.
>которые бывают и в h265/hevc, а не только в h264/avc
AVC при таком уровне сжатия сильно теряет в качестве. HEVC надо будет потестить.
Сравнение AVC, HEVC и AV1 на пресетах сопоставимой скорости и примерно одинаковом битрейте.
1)Медленно, сжатие примерно в 4 раза.
2)Быстро, сжатие примерно в 4 раза.
3)Быстро, сжатие примерно в 2 раза.
1)Медленно, сжатие примерно в 4 раза.
2)Быстро, сжатие примерно в 4 раза.
3)Быстро, сжатие примерно в 2 раза.
как сразу целый сезон сериала перекодировать? нужно вручную каждую серию прописывать?
>>28722
Из батника запусти
for f in (*.mkv) do ffmpeg -i f -pix_fmt yuv420p10le -c:v libsvtav1 -preset 6 -crf 25 -svtav1-params tune=0:enable-qm=1:qm-min=0:qm-max=8 -c:a libopus -b:a 48k %%f.webm
Ну или любые другие параметры кодирования.
Из батника запусти
for f in (*.mkv) do ffmpeg -i f -pix_fmt yuv420p10le -c:v libsvtav1 -preset 6 -crf 25 -svtav1-params tune=0:enable-qm=1:qm-min=0:qm-max=8 -c:a libopus -b:a 48k %%f.webm
Ну или любые другие параметры кодирования.
43 Кб, 1244x85Макаба поломала все. Одной строкой.
>>28810
И зачем? Большинство сорсов в обычном yuv420p и увеличение формата новое качество из воздуха не создаст. Если же у анона что-то действительно высококачественное, то у него вообще может быть yuv422p или yuv444p и твоя хуйня наоборот ухудшит качество.
>yuv420p10le
И зачем? Большинство сорсов в обычном yuv420p и увеличение формата новое качество из воздуха не создаст. Если же у анона что-то действительно высококачественное, то у него вообще может быть yuv422p или yuv444p и твоя хуйня наоборот ухудшит качество.
>>28956
Но при сжатии результат будет немного лучше в том же битрейте.
>Ну или любые другие параметры кодирования
>новое качество из воздуха не создаст
Но при сжатии результат будет немного лучше в том же битрейте.
есть какой-то просто простенький гуи для энтого вашего ффмпега? А то резать видево через командную строку запоминая нужный отрывок напамять это пиздец ясчитаю
>>28988
Avidemux
Avidemux