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 почти не отличаются, однако лютые шакалы от сжатия на втором этапе никуда не делись.
>>1006
Чтобы эффективнее жамать.
Чтобы эффективнее жамать.
>>3600909 →
Все перематывается, скачай и проверь. В браузере перед перемоткой он сначала должен загрузить его целиком. Ну а поскольку двач хостится на мусорном ведре и регулярно лагает - видео может в принципе не грузиться и перемотка будет меньшей из проблем.
Ну и перемотка не моментальная, а на 2-3 секунды нагружает процессор и вызывает подвисание видео. Лично я не вижу в этом ничего криминального, в конце концов шебм не для того нарезаются чтобы анон ползунок дрочил. Если включить и смотреть проблем никаких.
>И ничего не перематывается, зато хорошо сжал, молодец.
Все перематывается, скачай и проверь. В браузере перед перемоткой он сначала должен загрузить его целиком. Ну а поскольку двач хостится на мусорном ведре и регулярно лагает - видео может в принципе не грузиться и перемотка будет меньшей из проблем.
Ну и перемотка не моментальная, а на 2-3 секунды нагружает процессор и вызывает подвисание видео. Лично я не вижу в этом ничего криминального, в конце концов шебм не для того нарезаются чтобы анон ползунок дрочил. Если включить и смотреть проблем никаких.
>>1008
Пчёл...
>Одиннадцать минут видео
>Не перематывается — это нормально
>это же шебем — скачал и перематывай
>не вижу в этом ничего криминального
Пчёл...
>>1012
Когда двач не лагает - видео подгрузится и можно перематывать прямо в браузере. Когда лагает ты его в принципе не посмотришь.
Здесь должна быть шутка про зумеров и тиктоки.
Еще раз - видео перематывается, просто не моментально.
Когда двач не лагает - видео подгрузится и можно перематывать прямо в браузере. Когда лагает ты его в принципе не посмотришь.
>Одиннадцать минут видео
Здесь должна быть шутка про зумеров и тиктоки.
Еще раз - видео перематывается, просто не моментально.
>>1006
Да я без понятия че там у них за формат, кодек создавался в первую очередь для 10-битного кодирования поэтому использую его.
Да я без понятия че там у них за формат, кодек создавался в первую очередь для 10-битного кодирования поэтому использую его.
89 Кб, 951x411Посоветуйте минимальные разрешения для двух ситуаций:
1,чтобы можно было читать текст без особого напряга, но, в принципе, мне ж не книгу читать, так что можно не идеально четко (допустим это поучительные видео про компик и там кто-то вбивает команды)\
2,вообще максимум ужания, но чтобы при этом можно было видеть лица с метров с пяти хотя бы, когда допустим кто-то снимал камерой улицу пока ходил ногами (ну, или это запись геймплея обливиона, где хочется лица видеть (купи облу, кстати))
конечно решает битрейт, но... по большей части можно совет по разрешениям в этих ситуациях? 320 на 240 — это вообще доннище и не вариант.
можно конечно и править соотношения сторон, но мне лучше для 21:9, хотя моник 21:10 тоже есть
1,чтобы можно было читать текст без особого напряга, но, в принципе, мне ж не книгу читать, так что можно не идеально четко (допустим это поучительные видео про компик и там кто-то вбивает команды)\
2,вообще максимум ужания, но чтобы при этом можно было видеть лица с метров с пяти хотя бы, когда допустим кто-то снимал камерой улицу пока ходил ногами (ну, или это запись геймплея обливиона, где хочется лица видеть (купи облу, кстати))
конечно решает битрейт, но... по большей части можно совет по разрешениям в этих ситуациях? 320 на 240 — это вообще доннище и не вариант.
можно конечно и править соотношения сторон, но мне лучше для 21:9, хотя моник 21:10 тоже есть
>>1188
Для текста тебе нужно частоту кадров понижать. Статичный текст и в 0 FPS вообще-то читается, консольки хватит 10 допустим. Тогда ты сможешь битрейт высоким оставить и кадры чёткими.
Но если у тебя там не только текст, но все перемешано, то нужна переменная частота и это уже не так просто, но в целом можно. VFR обычно называется.
Разрешение – последнее что важно.
Для текста тебе нужно частоту кадров понижать. Статичный текст и в 0 FPS вообще-то читается, консольки хватит 10 допустим. Тогда ты сможешь битрейт высоким оставить и кадры чёткими.
Но если у тебя там не только текст, но все перемешано, то нужна переменная частота и это уже не так просто, но в целом можно. VFR обычно называется.
Разрешение – последнее что важно.
>>1190
Ну, не знаю даже. Не с пустого же места обывалы пикабушного уровня компетенций создают картиночки а-ля графики битрейта для качественного видео в разных разрешениях, типа: "для 720 нужно 3000 битов, а вот для 1080 нужно 4000, для 480 можно и 2000...".
Смотрю, что придется осваивать ffmpeg как ни крути. Ведь ни одна программа (мне известны все, буквально любую я попробовал) не может в адекватный и автоматический переменный битрейт. Ни в одной проге нет полной настройки всех характеристик, и ни одна не способна адекватно юзать видеокарту. Но, как же в падлу пользовать консоль.
Правда ли что ваш ffmpeg не будет трогать те характеристики видео и музыки, которые не упомянуты в команде?
Ну, не знаю даже. Не с пустого же места обывалы пикабушного уровня компетенций создают картиночки а-ля графики битрейта для качественного видео в разных разрешениях, типа: "для 720 нужно 3000 битов, а вот для 1080 нужно 4000, для 480 можно и 2000...".
Смотрю, что придется осваивать ffmpeg как ни крути. Ведь ни одна программа (мне известны все, буквально любую я попробовал) не может в адекватный и автоматический переменный битрейт. Ни в одной проге нет полной настройки всех характеристик, и ни одна не способна адекватно юзать видеокарту. Но, как же в падлу пользовать консоль.
Правда ли что ваш ffmpeg не будет трогать те характеристики видео и музыки, которые не упомянуты в команде?
>>1195
Это не константа. Какой битрейт тебе нужен для получения определенного уровня качества зависит от используемого кодека, его настроек, частоты кадров и сложности самого видео.
>Не с пустого же места обывалы пикабушного уровня компетенций создают картиночки а-ля графики битрейта для качественного видео в разных разрешениях, типа: "для 720 нужно 3000 битов, а вот для 1080 нужно 4000, для 480 можно и 2000...".
Это не константа. Какой битрейт тебе нужен для получения определенного уровня качества зависит от используемого кодека, его настроек, частоты кадров и сложности самого видео.
Аноны подскажите пользуюсь ffmpeg для вырезания музыки из видео файл музыки получается только в формате wav, как сделать так что-бы можно было его сохранять в формате mp3?
К слову эту утилиту собирал из исходников, а файл wav мне приходится в Audacity переделывать в mp3.
К слову эту утилиту собирал из исходников, а файл wav мне приходится в Audacity переделывать в mp3.
>>1220
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, лааал бля.
>>1513
Я уже скомпилированный качал отсюда
https://github.com/AnimMouse/ffmpeg-autobuild/releases
но полагаю что надо компилировать с ключом --enable-libmp3lame.
Я уже скомпилированный качал отсюда
https://github.com/AnimMouse/ffmpeg-autobuild/releases
но полагаю что надо компилировать с ключом --enable-libmp3lame.
>>1478
Да. Для этого надо вслепую раскурить аппаратную часть и обойти все её защиты, буквально хакинг.
>неужели это убер-сложно
Да. Для этого надо вслепую раскурить аппаратную часть и обойти все её защиты, буквально хакинг.
>>1489
>>1538
Ну, то есть, дожили -- да? Упираемся в то, что чипированы неправильным чипом, а чтобы воспользоваться базовыми правами каждого человека на оптимизацию своего дискового пространства, нам нужно заплатить соцрейтинговые монетки с виртуальной карты барену, приобретая новый чип. Охуенно.
Нет, ничего не мешает конвертить vvc/AV1 на gtx1080. Вообще ничего, кроме указки барина, не выделившего тимки из трех челиков на создание простецкого (по меркам конгломерата) драйвера.
>>1538
Ну, то есть, дожили -- да? Упираемся в то, что чипированы неправильным чипом, а чтобы воспользоваться базовыми правами каждого человека на оптимизацию своего дискового пространства, нам нужно заплатить соцрейтинговые монетки с виртуальной карты барену, приобретая новый чип. Охуенно.
Нет, ничего не мешает конвертить vvc/AV1 на gtx1080. Вообще ничего, кроме указки барина, не выделившего тимки из трех челиков на создание простецкого (по меркам конгломерата) драйвера.
Кстати, подскажите, зачем нужен пакет ogv? И есть ли (кроме фришности, конечно) этих инструментов цимес задействовать также и нативный для ogg кодек (не помню его названия)? Так-то у меня в голове мысль крутится, что, может быть, существует кодек из начала 00х, чьи шакалы сжатия более гладки и приятны глазу, нежели сыпящиеся квадраты AVC1 (и, боже упаси, тот клеточный капец, который показывает mpeg2)?
Ну, вот, кста. Что и подтверждается. Я, как человек без нового чипа, вместо пользования благами vvc/av1 пошел ковыряться по помойкам за какими-то там хипстерскими ".ovg", о которых никто не знает.
>>1576
Пакет 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, предлагают более высокую эффективность и визуальное качество, но требуют большей вычислительной мощности.
>>1571
Во-первых это не софтовая проблема, а железная. Нельзя просто взять и написать драйвер, чтобы у тебя железо новое из воздуха появилось.
Во-вторых твои базовые хуман райтс реализуют простые честные прямые процессорные мощности. Хоть и не обязаны, делают это только из доброты душевной. Не хочешь полагаться на милость — спонсируй свободный софт и свободное железо. Пора бы уже отказаться от идеализма, понимаешь?
Во-первых это не софтовая проблема, а железная. Нельзя просто взять и написать драйвер, чтобы у тебя железо новое из воздуха появилось.
Во-вторых твои базовые хуман райтс реализуют простые честные прямые процессорные мощности. Хоть и не обязаны, делают это только из доброты душевной. Не хочешь полагаться на милость — спонсируй свободный софт и свободное железо. Пора бы уже отказаться от идеализма, понимаешь?
>>1743
Ну я же скидывал выше ссылку. Либо -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>>1940
Ширина и высота видео должны быть кратны 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 раз - то что мне нужно.
Сейчас могу блок питания со скидкой взять, не знаю есть ли смысл поставить нынешний компьютер параллельно ужимать видео, или новый пк будет это делать супер быстро.
>>2738
Можно поменять контейнер без перекодировки, т.е. без потери качества
ffmpeg -i mocha.mp4 -c copy govno.mkv
> transcode когда из одного контейнера в другой переделывают, нампример ts или mkv в mp4, причем можно это делать без потери качества (т.е. можно разжать контейнер обратно в raw?), а можно кодеками ужать файл с определенной потерей качества?
Можно поменять контейнер без перекодировки, т.е. без потери качества
ffmpeg -i mocha.mp4 -c copy govno.mkv
>>2738
Разумеется, для того они и существуют.
Скорость кодирования сильно зависит от настроек кодека и, в меньшей степени, от сложности видео. Поэтому точную цифру назвать невозможно.
Отмечу лишь что 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 который на дефолтных настройках невероятно медленный.
>>2764
Я так ts в mp4 гнал, вес файлов уменьшался до 5%. Чет подозрительно много.
>>2767
Я имел ввиду прирост при тех же условиях.
Я пробовал медленные пресеты для лучшего качества на 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%. Чет подозрительно много.
>>2767
> Скорость кодирования сильно зависит от настроек кодека
Я имел ввиду прирост при тех же условиях.
Я пробовал медленные пресеты для лучшего качества на 1080p, там было 0.2х, даже чуть меньше.
Я пытаюсь на глазок прикинуть. У 4771 8 потоков, у 14600K 20 потоков, т.е. в 2.5 больше. Technical.city (все что есть) дает общий прирост где-то в 5.4 раза, пусть будет 4. Получается 0.2х2.5х4= 2х скорость. Это уже нормально, если за счет хардвере технологий будет еще быстрее, то вообще отлично. А если будет 1.5х и ниже, то это меня не устроит.
>>2787
Ну это тебе надо найти кого-то с 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 берет эту цифру, берет вообще сам факт того, что аудио надо сдвинуть? С другими файлами он так не делает.
Кроме проблемы (если это вообще проблема) с этим файлом, я также в целом пытаюсь понять, как нужно правильно детектить сдвиг аудиодорожек в видеофайлах (в уже существующих, сделанных кем-то), чтобы правильно синхронизировать их с другими видео (например, русскую дорожку с ориг ремуксом, и т.п.)
>>2787
Всё абсолютно правильно и так и должно быть. TS и M2TS - это транспортные потоки, они и должны худеть при перегоне в более привычные консумерские типа MP4 и MKV. Ты также можешь демуксировать их (вытащить из них содержимое в сыром виде) и наглядно убедиться, что сумма размеров всех потоков будет равна размеру MP4 или MKV (плюс крошечный оверхед, типа пары мегабайт), а вот в TS или M2TS будет огромный оверхед размером 5-10%.
>Я так ts в mp4 гнал, вес файлов уменьшался до 5%. Чет подозрительно много.
Всё абсолютно правильно и так и должно быть. TS и M2TS - это транспортные потоки, они и должны худеть при перегоне в более привычные консумерские типа MP4 и MKV. Ты также можешь демуксировать их (вытащить из них содержимое в сыром виде) и наглядно убедиться, что сумма размеров всех потоков будет равна размеру MP4 или MKV (плюс крошечный оверхед, типа пары мегабайт), а вот в TS или M2TS будет огромный оверхед размером 5-10%.
>>2787
Мало скорее.
В 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.
Что мне обо всем этом думать? Что происходит?
>>3013
>>3040
Лол, я на всякий случай сохранял в оригинальном ts, хотя проги по умолчанию предлагают преобразовать в mp4
А если при ужатии сразу делать -i video.ts libx265 video.mp4 или аналог в av1, то там все само как надо переделается или лучше сначала сделать -i video.ts -c copy video.mp4 и уже mp4 ужимать?
>>3040
Лол, я на всякий случай сохранял в оригинальном ts, хотя проги по умолчанию предлагают преобразовать в mp4
А если при ужатии сразу делать -i video.ts libx265 video.mp4 или аналог в av1, то там все само как надо переделается или лучше сначала сделать -i video.ts -c copy video.mp4 и уже mp4 ужимать?
>>3274
Стало интересно, что на такое ответит дикпик.
Ваша ситуация действительно интересна и требует детального разбора. Давайте по пунктам разберём возможные причины и последствия наблюдаемых явлений.
---
### 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 байта — это "шум", не влияющий на качество. Субтитры тоже в порядке, если их содержимое не изменилось. Можно смело использовать такие ремуксы!
>>3274
Стало интересно, что на такое ответит дикпик.
Ваша ситуация действительно интересна и требует детального разбора. Давайте по пунктам разберём возможные причины и последствия наблюдаемых явлений.
---
### 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 байта — это "шум", не влияющий на качество. Субтитры тоже в порядке, если их содержимое не изменилось. Можно смело использовать такие ремуксы!
>>3280
Сразу кодируй в нужный формат.
Сразу кодируй в нужный формат.
Всю жизнь нужен был самый простой софт чтобы быстренько обрезать и перекодировать mkv в mp4 для закидывания в премьер.
Наконец дошли руки до FFmpeg но в итоге получивший mp4 премьер нихуя не видит. Не в первый раз уже проблема такая.
Наконец дошли руки до FFmpeg но в итоге получивший mp4 премьер нихуя не видит. Не в первый раз уже проблема такая.
>>5013
Так возьми документацию по премьеру. Разберись, что от mp4 премьер ожидает. Какую версию контейнера, какие кодеки допустимы. Но я бы попобовал прикрктить к премьеру avisynth+64, и уже через него использовать ffmpeg (в виде ffms2).
>Не в первый раз уже проблема такая.
Так возьми документацию по премьеру. Разберись, что от mp4 премьер ожидает. Какую версию контейнера, какие кодеки допустимы. Но я бы попобовал прикрктить к премьеру avisynth+64, и уже через него использовать ffmpeg (в виде ffms2).
В каком контейнере хранить музыку в кодеках aac и opus для прослушивания без видео? Он вообще нужен?
4,3 Мб, mp4,512x512, 4:23
>>6222
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 на двощ не постятся.
>>6465
Оо ты то мне и нужен
А как помимо этого ещё и выбрать интервал из трека\обрезать его?
Я так делал
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
>>6476
Вот такой батник. Сначала вырезаем нужный кусок, потом лепим картинку + копируем аудио без перекодирования, удаляем промежуточный аудиофайл.
Соответственно Х - длительность вырезаемого куска.
>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?
>>8628
Нет, но
Кодируй не с теми же.
В ффмпеге их определённо больше, там настроить что-нибудь сможешь чтобы ускорить. Количество ядер например твой гуй умеет выставлять?
Нет, но
> с теми-же параметрами
Кодируй не с теми же.
В ффмпеге их определённо больше, там настроить что-нибудь сможешь чтобы ускорить. Количество ядер например твой гуй умеет выставлять?
39,5 Мб, webm,1920x872, 11:03
Насколько шакально смотрится это видео на разрешениях экрана выше 1920х1080?
>>9170
-c:a copy
-c:a copy
>>1478
Если по какой-то причине кому-то нужно использовать древние кодеки и даже не 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.
>>9892
Около 80 минут. Но надо понимать что у меня старый двухядерный процессор, поддерживающий максимум SSE 4.2. Любой более менее современный процессор с 4+ ядрами и поддержкой хотя бы AVX2 (а в идеале AVX-512) справится в разы быстрее.
Я чисто ради эксперимента попробовал закодировать какое-нибудь видео, из тех что я делал в 720p, в большем разрешении практически без повышения битрейта и несколько удивлен тому что заметного падения качества не происходит. Вот старое >>3600870 → для сравнения.
Около 80 минут. Но надо понимать что у меня старый двухядерный процессор, поддерживающий максимум SSE 4.2. Любой более менее современный процессор с 4+ ядрами и поддержкой хотя бы AVX2 (а в идеале AVX-512) справится в разы быстрее.
Я чисто ради эксперимента попробовал закодировать какое-нибудь видео, из тех что я делал в 720p, в большем разрешении практически без повышения битрейта и несколько удивлен тому что заметного падения качества не происходит. Вот старое >>3600870 → для сравнения.