400 Кб, 2000x2000FFmpeg и общий кодирования видео тред №12
В прошлый раз мы обсуждали азы и тонкости сжатия, даже обошлись без срачей.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
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/res/3365343.html (М)
В прошлый раз мы обсуждали азы и тонкости сжатия, даже обошлись без срачей.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
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/res/3365343.html (
М)
4,9 Мб, mp4,720x1280, 0:12
h265 в ближайшие годы сравнится по популярности с h264, av1 удел гугла с их датацентрами и асиками, они нужны чтобы не платить миллиарды за патенты и экономить трафик, обычный пользователь уже заплатил за кодек при покупке смартфона\пк
>>442129
Большинство людей не будет заморачиваться этим, не работает из коробки - считай не поддерживается.
Большинство людей не будет заморачиваться этим, не работает из коробки - считай не поддерживается.
>>442139
Там лежит уже готовый Chromium с поддержкой, можешь сам проверить. Только установить надо.
https://github.com/StaZhu/enable-chromium-hevc-hardware-decoding/releases
Проверить можешь тут:
https://lf-tk-sg.ibytedtos.com/obj/tcs-client-sg/resources/video_demo_hevc.html
Там лежит уже готовый Chromium с поддержкой, можешь сам проверить. Только установить надо.
https://github.com/StaZhu/enable-chromium-hevc-hardware-decoding/releases
Проверить можешь тут:
https://lf-tk-sg.ibytedtos.com/obj/tcs-client-sg/resources/video_demo_hevc.html
>>442145
Я исхожу с точки зрения человека, который хочет выложить клип и хочет чтобы его посмотрело как можно больше людей.
Я не стану выкладывать видео в неподдерживаемом формате и просить людей установить левую сборку браузера.
Я как-то прошелся ffprobe'ом по вебм треду в /mov/, там половина была h264, половина vp8/9, два h265 и еще несколько av1.
Я нашел те два h265, превью были поломаны и автор тут же их переделал на другой кодек, не помню какой именно.
Я исхожу с точки зрения человека, который хочет выложить клип и хочет чтобы его посмотрело как можно больше людей.
Я не стану выкладывать видео в неподдерживаемом формате и просить людей установить левую сборку браузера.
Я как-то прошелся ffprobe'ом по вебм треду в /mov/, там половина была h264, половина vp8/9, два h265 и еще несколько av1.
Я нашел те два h265, превью были поломаны и автор тут же их переделал на другой кодек, не помню какой именно.
17 Кб, 510x903>>441997
Абсолютли
Абсолютли
>>441997
Имеешь в виду, что так же уйдёт на вторые роли? Ну да.
Google не для того вкладывался в разработку и скупал патенты, чтобы доходами делиться с конкурентом. Декодер HEVC в Android появился 10 лет назад (при покупке лицензии на программное или аппаратное декодирование производителем), а вот в Chrome поддержку передачи видео системному декодеру добавили только в конце 2022 года. Совершенно случайно так вышло, да.
Само собой, Apple, очень давно крутящий шашни с MPEG, стоит на противоположных позициях. HEVC официально лучший кодек, всё остальное побоку.
80% малограмотных пользователей (не блокирующих StatCounter) могут декодировать AV1, остальные — под вопросом. Большая часть этих 80% — стадо в коровнике Chrome. 20% малограмотных пользователей могут декодировать HEVC, остальные — под вопросом. Большая часть этих 80% — стадо в коровнике Safari. Вот и всё, никаких сюрпризов. Любой крупный сервис, который не может позволить себе игнорировать десятки процентов аудитории, всё равно вынужден кодировать в несколько форматов, так что выгода «сообщества» не так очевидна, как выгода Google.
> h265 в ближайшие годы сравнится по популярности с h264
Имеешь в виду, что так же уйдёт на вторые роли? Ну да.
Google не для того вкладывался в разработку и скупал патенты, чтобы доходами делиться с конкурентом. Декодер HEVC в Android появился 10 лет назад (при покупке лицензии на программное или аппаратное декодирование производителем), а вот в Chrome поддержку передачи видео системному декодеру добавили только в конце 2022 года. Совершенно случайно так вышло, да.
Само собой, Apple, очень давно крутящий шашни с MPEG, стоит на противоположных позициях. HEVC официально лучший кодек, всё остальное побоку.
80% малограмотных пользователей (не блокирующих StatCounter) могут декодировать AV1, остальные — под вопросом. Большая часть этих 80% — стадо в коровнике Chrome. 20% малограмотных пользователей могут декодировать HEVC, остальные — под вопросом. Большая часть этих 80% — стадо в коровнике Safari. Вот и всё, никаких сюрпризов. Любой крупный сервис, который не может позволить себе игнорировать десятки процентов аудитории, всё равно вынужден кодировать в несколько форматов, так что выгода «сообщества» не так очевидна, как выгода Google.
Есть у кого-нибудь готовая сборка фмпепега с включенными аппаратно-ускоренными энкодерами от амд - AMF? Или только самому собирать...
3,2 Мб, 3840x2160>>445643
он по дефолту там есть
он по дефолту там есть
>>441997
Так а гугл не заплатил и нарезать в нём контент не будет.
>>442259
Да, VP9 и H.264. Очень крупный может к VP9 добавить AV1.
265 нахуй никому не сдался кроме эппла.
мимо инженер очень крупного видеосервиса
>обычный пользователь уже заплатил за кодек при покупке смартфона\пк
Так а гугл не заплатил и нарезать в нём контент не будет.
>>442259
>Любой крупный сервис, который не может позволить себе игнорировать десятки процентов аудитории, всё равно вынужден кодировать в несколько форматов
Да, VP9 и H.264. Очень крупный может к VP9 добавить AV1.
265 нахуй никому не сдался кроме эппла.
мимо инженер очень крупного видеосервиса
Анончики, сорри, если не по теме, но мб тут поскажут: как называется эффект "приглушения" звука на первом вебм? Видео2 - оригинал.
>>454359
fade in/out?
fade in/out?
>>454359
Он называется, не поверишь... эквалайзер!. В данном случае похоже на lowpass начиная с ~1kHz.
Он называется, не поверишь... эквалайзер!. В данном случае похоже на lowpass начиная с ~1kHz.
>>454359
Высокие частоты обрезали
Высокие частоты обрезали
Сап двач. Как скачать сразу обрезанное видео с ютуба?
Как сделал я:
yt-dlp -g "ссылка на видео"
Мне выдало две длинные ссылки на видео и аудио
Далее пробовал вот это и не совсем понимаю как оно работает:
ffmpeg -i "ссылка" -ss 00:10:10 -to 00:10:20 -c copy test.webm
ffmpeg -ss 00:10:10 -i "ссылка" -to 00:10:20 -c copy test.webm
В обоих случаях получалась ебанина с непонятными таймингами.
В итоге сделал так
ffmpeg -ss 00:10:10 -i "ссылка" -t 10 -c copy test.webm
Но сука видео и аудио скачались разной продолжительностью.
Что я делаю не так и как нужно?
Как сделал я:
yt-dlp -g "ссылка на видео"
Мне выдало две длинные ссылки на видео и аудио
Далее пробовал вот это и не совсем понимаю как оно работает:
ffmpeg -i "ссылка" -ss 00:10:10 -to 00:10:20 -c copy test.webm
ffmpeg -ss 00:10:10 -i "ссылка" -to 00:10:20 -c copy test.webm
В обоих случаях получалась ебанина с непонятными таймингами.
В итоге сделал так
ffmpeg -ss 00:10:10 -i "ссылка" -t 10 -c copy test.webm
Но сука видео и аудио скачались разной продолжительностью.
Что я делаю не так и как нужно?
>>455088
Режешь мимо ключевого кадра.
yt-dlp [ссылка] --downloader ffmpeg --downloader-args "ffmpeg_i:-ss [время начала] -to [время конца]"
>Что я делаю не так
Режешь мимо ключевого кадра.
>как нужно
yt-dlp [ссылка] --downloader ffmpeg --downloader-args "ffmpeg_i:-ss [время начала] -to [время конца]"
182 Кб, 1004x911>>455088
Вот это. Поиск при копировании потока ориентируется на I-фреймы, а они разбросаны в потоке по воле того кодека, которым этот поток был создан.
Так что без перекодирования тут не обойдешься, если тебе нужна точность
А вообще, вот мануал на эту тему
https://trac.ffmpeg.org/wiki/Seeking
> Что я делаю не так и как нужно?
> -c copy
Вот это. Поиск при копировании потока ориентируется на I-фреймы, а они разбросаны в потоке по воле того кодека, которым этот поток был создан.
Так что без перекодирования тут не обойдешься, если тебе нужна точность
А вообще, вот мануал на эту тему
https://trac.ffmpeg.org/wiki/Seeking
Как лучше вырезать определенный отрезок времени? Варианты из гугла мне криво режут или с рассинхроном, зависанием кадра.
>>455174
avidemux
avidemux
>>455148
>>455160
Вот это попробовал, вообще ебанина получилась, и в середине скачки ошибка вылазила.
Спасибо за помощь аноны, но это всё похоже слишком сложно для меня. Наверно было проще сразу 12 часов стрима выкачать и спокойно нарезать, чем весь день с красными глазами сидеть тестировать, благо интернет позволяет.
>>455160
> yt-dlp [ссылка] --downloader ffmpeg --downloader-args "ffmpeg_i:-ss [время начала] -to [время конца]"
Вот это попробовал, вообще ебанина получилась, и в середине скачки ошибка вылазила.
Спасибо за помощь аноны, но это всё похоже слишком сложно для меня. Наверно было проще сразу 12 часов стрима выкачать и спокойно нарезать, чем весь день с красными глазами сидеть тестировать, благо интернет позволяет.
>>455088
Попробуй юзать --download-sections.
Попробуй юзать --download-sections.
115 Кб, 438x347>>459750
Получается AV1 по дефолту кодировал в три прохода ?
И как на скорости\качестве отразится нововведение ?
Получается AV1 по дефолту кодировал в три прохода ?
И как на скорости\качестве отразится нововведение ?
>>459895
Поправка: SVT AV1. Конкретно этот кодировщик.
libaom умел в два прохода и ранее. Просто это референсный кодировщик, корнями из libvpx, кодовую базу которого мало кто желает поддерживать. Поэтому большинство кодирует в SVT AV1.
Поправка: SVT AV1. Конкретно этот кодировщик.
libaom умел в два прохода и ранее. Просто это референсный кодировщик, корнями из libvpx, кодовую базу которого мало кто желает поддерживать. Поэтому большинство кодирует в SVT AV1.
>>459903
>Актуальный гайд по кодированию от анона из треда №5 (принимается критика, её было много в предыдущих тредах): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
>>441805 (OP)
Когда он там появился? Я что-то пропустил? Последний раз когда я гуглил эту тему, у режима 5 не было установленного среза. И получается, что ты установил срез агрессивнее чем он был. Зачем?
Ну я устанавливал срез на 18k когда кодировал в режиме 4, чтобы получить файл с битрейтом около 160kbps. Но и кодировал я музыку не через ffmpeg, а через консольную утилиту fdkaac. Хотя и qaac под wine тоже работает.
> -vbr 5 -cutoff 20000
> Слишком агрессивный фильтр частот по умолчанию я рекомедную отключить.
Когда он там появился? Я что-то пропустил? Последний раз когда я гуглил эту тему, у режима 5 не было установленного среза. И получается, что ты установил срез агрессивнее чем он был. Зачем?
Ну я устанавливал срез на 18k когда кодировал в режиме 4, чтобы получить файл с битрейтом около 160kbps. Но и кодировал я музыку не через ffmpeg, а через консольную утилиту fdkaac. Хотя и qaac под wine тоже работает.
>>460059
Да там вообще хуйня какая-то. Вот здесь например автор пишет "Можно написать чтобы первый проход был качественее -fastfirstpass false", а куда дописать, зачем там первый вариант недописан, зачем второй вариант, зачем вообще делать проходы никакой инфы. Но уже не надо, спросил у чатжпт и он ответил одним постом, пока кожаный мешок разродился целой документацией с ебанутыми командами.
Да там вообще хуйня какая-то. Вот здесь например автор пишет "Можно написать чтобы первый проход был качественее -fastfirstpass false", а куда дописать, зачем там первый вариант недописан, зачем второй вариант, зачем вообще делать проходы никакой инфы. Но уже не надо, спросил у чатжпт и он ответил одним постом, пока кожаный мешок разродился целой документацией с ебанутыми командами.
>>460070
Но он тебе тоже не ответил ни на один вопрос.
>Как сжать webm размером с 200мб до 40, с минимальной потерей качества?
>зачем там первый вариант недописан
>зачем второй вариант
>зачем вообще делать проходы
>спросил у чатжпт и он ответил
Но он тебе тоже не ответил ни на один вопрос.
>>460088
Не, ответил, просто мы не поняли его вопроса. Просто он настолько сверхразум, что его понять может только чатбот.
Не, ответил, просто мы не поняли его вопроса. Просто он настолько сверхразум, что его понять может только чатбот.
26 Кб, 1026x212Как фиксить? Пытался сделать вот это: -i input.webm -c:v libx265 -crf 30 -preset medium -pix_fmt yuv420p10le output.webm
>>460095
Я вижу в чём проблема.
Меняй на
Но если ты хочешь постить на двачах, тогда вместо этого учись кодировать в libvpx-vp9.
> -c:v libx265
> output.webm
Я вижу в чём проблема.
Меняй на
> output.mp4
Но если ты хочешь постить на двачах, тогда вместо этого учись кодировать в libvpx-vp9.
>>460057
Нет, нельзя. Ты как малое дитя требуешь от реальности соответствия твоим инфантильным хотелкам. Реальность работает не так.
Так-то там короткая заметка на минут 20 вдумчивого чтения. Если для тебя это за пределом сложности, то у меня про твои когнитивные способности плохие новости.
>>460070
Это, скорее всего, косяк инструкции. Так-то должно было быть сформулировано как
В целом, так бывает, когда пытаются просто и коротко рассказать про сложное и большое. Возможно, что в ffmpeg есть возможность опцию «fastfirstpass» библиотеке libx264 передать не через специальный ключ в строке-параметре опции «-x264opts», а через обычную опцию ffmpeg «-fastfirstpass» со строкой-параметром «false». Тогда команда была бы примерно:
Ты уже давай определись — тебе объяснять нужно долго и печально, или на скорую руку.
Он тебе ответил формально верную, но не соответствующую твоему вопросу ерунду.
>>460095
H.265 не поддерживается доброй половиной браузеров. И про это в той короткой заметке написано.
Ты там что собрался делать-то? Каков конечный результат? Куда ты его собрался деть? Какие свойства у исходной последовательности? Почему не приложен отчёт mediainfo?
>Блин, а можно просто пример команды
Нет, нельзя. Ты как малое дитя требуешь от реальности соответствия твоим инфантильным хотелкам. Реальность работает не так.
> а не эти километровые гайды?
Так-то там короткая заметка на минут 20 вдумчивого чтения. Если для тебя это за пределом сложности, то у меня про твои когнитивные способности плохие новости.
>>460070
> Можно написать чтобы первый проход был качественее -fastfirstpass false
Это, скорее всего, косяк инструкции. Так-то должно было быть сформулировано как
> передать библиотеке libx264 параметр «fastfirstpass=false», добавив его через двоеточие в конец строки-параметра для опции «-x264opts». Например так
> ffmpeg -i input.avi -b:v 3000 -c:v libx264 -x264opts ref=4:fastfirstpass=false
В целом, так бывает, когда пытаются просто и коротко рассказать про сложное и большое. Возможно, что в ffmpeg есть возможность опцию «fastfirstpass» библиотеке libx264 передать не через специальный ключ в строке-параметре опции «-x264opts», а через обычную опцию ffmpeg «-fastfirstpass» со строкой-параметром «false». Тогда команда была бы примерно:
> ffmpeg -i input.avi -b:v 3000 -c:v libx264 -x264opts ref=4 -fastfirstpass false
> зачем вообще делать проходы никакой инфы
Ты уже давай определись — тебе объяснять нужно долго и печально, или на скорую руку.
> Но уже не надо, спросил у чатжпт и он ответил одним постом, пока кожаный мешок разродился целой документацией с ебанутыми командами.
Он тебе ответил формально верную, но не соответствующую твоему вопросу ерунду.
>>460095
H.265 не поддерживается доброй половиной браузеров. И про это в той короткой заметке написано.
Ты там что собрался делать-то? Каков конечный результат? Куда ты его собрался деть? Какие свойства у исходной последовательности? Почему не приложен отчёт mediainfo?
Посоветуйте гуй для монтажа наподобе LosslessCut но чтоб можно было сразу несколько файлов в сплитскрине
>>460414
Головушка твоя не работает.
https://pastebin.com/9fdkqbiF
>Все равно ошибка, ладно похуй, не работает эта пердольская хуита кароч, чисто ебля с кодеками ради ебли с кодеками
Головушка твоя не работает.
https://pastebin.com/9fdkqbiF
>>460104
Не поддерживается полноценно он только копробздоксом (нет поддержки 10 бит, в чём основная соль кодека), всеми остальными поддерживается.
https://caniuse.com/hevc
> H.265 не поддерживается доброй половиной браузеров.
Не поддерживается полноценно он только копробздоксом (нет поддержки 10 бит, в чём основная соль кодека), всеми остальными поддерживается.
https://caniuse.com/hevc
>>460563
По твоей ссылочке как раз сказано, что поддержка для большинства обозревателей как раз частичная (в основном, ограничена чисто аппаратным декодером). Ты надеялся, что труъ по ссылкам не ходят?
По твоей ссылочке как раз сказано, что поддержка для большинства обозревателей как раз частичная (в основном, ограничена чисто аппаратным декодером). Ты надеялся, что труъ по ссылкам не ходят?
>>460572
Чтобы декодировать контент железо(будь то процессор или видеокарта) должно поддерживать его аппаратно. Истории для самых маленьких.
Фикси кал в башке, лол.
> в основном, ограничена чисто аппаратным декодером
Чтобы декодировать контент железо(будь то процессор или видеокарта) должно поддерживать его аппаратно. Истории для самых маленьких.
> Ты надеялся, что труъ по ссылкам не ходят?
Фикси кал в башке, лол.
>>460574
> Чтобы декодировать контент железо(будь то процессор или видеокарта) должно поддерживать его аппаратно.
>>460576
Опежнатор, съеби.
Опежнатор, съеби.
>>460574
Попробую снова пофиксить это самое непотребство в твоей голове, заменяющее тебе орган мышления. Смотри, как у нас вышло. Ты выдвинул тезис вот здесь >>460563, настаивая на том, что данные, на которые ты ссылаешься, подтверждают его. Затем в >>460572 я напомнил, что:
- данные по ссылке подтверждают скорее мой тезис, который ты собирался опровергать,
- твой вывод спекулятивный, для него не достаточно фактических оснований.
В ответ на критику ты разразился в >>460574 негодованием, оскорблениеми и по-детски наивной и жалкой попыткой выкрутиться из очевидной и для тебя тоже логической ловушки.
Ты это делаешь на анонимном форуме зачем? Здесь у тебя ни кармы нет, ни авторитета. Здесь нет необходимости притворяться умным — твоя глупость в твоих же мыслях видна непосредственно.
>Фикси кал в башке, лол
Попробую снова пофиксить это самое непотребство в твоей голове, заменяющее тебе орган мышления. Смотри, как у нас вышло. Ты выдвинул тезис вот здесь >>460563, настаивая на том, что данные, на которые ты ссылаешься, подтверждают его. Затем в >>460572 я напомнил, что:
- данные по ссылке подтверждают скорее мой тезис, который ты собирался опровергать,
- твой вывод спекулятивный, для него не достаточно фактических оснований.
В ответ на критику ты разразился в >>460574 негодованием, оскорблениеми и по-детски наивной и жалкой попыткой выкрутиться из очевидной и для тебя тоже логической ловушки.
Ты это делаешь на анонимном форуме зачем? Здесь у тебя ни кармы нет, ни авторитета. Здесь нет необходимости притворяться умным — твоя глупость в твоих же мыслях видна непосредственно.
Опять зелень на тред набигает
>>460632
Хуя манявры бессмысленные. Кто-нибудь дайте почитать этим болезням датащиты видеокарт и процессоров, ещё о таком явлении как однлплатники ака андроид-приставки не забудьте упомянуть.
Хуя манявры бессмысленные. Кто-нибудь дайте почитать этим болезням датащиты видеокарт и процессоров, ещё о таком явлении как однлплатники ака андроид-приставки не забудьте упомянуть.
>>460636
Причём здесь блядь ваше железо? Разработчики софта говорят «не хотим мы лицензии платить на h265, не будет у пользователей этого кодека» — вот его и нет.
Вы вот проводили реальное тестирование ваших браузеров? Вот например здесь? https://tools.woolyss.com/html5-audio-video-tester/
У меня вот например стоит 1650. Она может декодировать h265 аппаратно. И чё? Ни нативно установленный firefox, ни chromium из flatpack этого кодека не понимают.
Что? Винду поставить? Браузер сменить и ещё до кучи ядро пересобрать?
А почему меня, как пользователя, вообще должны волновать проблемы лицензирования кодеков? Вы, господа, слишком многого от меня хотите. Нет у меня в браузере h265, ну и не надо. Что в ваших вебэмах может быть такого, что заставит меня пойти на такое? Да понятно что ничего. Мне проще проигнорировать дурачка и посмотреть другие вебэмы, которых полно.
Причём здесь блядь ваше железо? Разработчики софта говорят «не хотим мы лицензии платить на h265, не будет у пользователей этого кодека» — вот его и нет.
Вы вот проводили реальное тестирование ваших браузеров? Вот например здесь? https://tools.woolyss.com/html5-audio-video-tester/
У меня вот например стоит 1650. Она может декодировать h265 аппаратно. И чё? Ни нативно установленный firefox, ни chromium из flatpack этого кодека не понимают.
Что? Винду поставить? Браузер сменить и ещё до кучи ядро пересобрать?
А почему меня, как пользователя, вообще должны волновать проблемы лицензирования кодеков? Вы, господа, слишком многого от меня хотите. Нет у меня в браузере h265, ну и не надо. Что в ваших вебэмах может быть такого, что заставит меня пойти на такое? Да понятно что ничего. Мне проще проигнорировать дурачка и посмотреть другие вебэмы, которых полно.
>>460670
>>460756
И на андроиде Edge, и на компе Edge. Там Microsoft наверняка держит патенты на Hevc. Так что ничего удивительного в том что их браузеры это поддерживают я не вижу.
Это как спрашивать с Apple за внедрение того-же Hevc/Heic и xHE-AAC. Они всегда так делали. И патентами они тоже владеют. Им тупо выгодно внедрять такие технологии.
>>460756
И на андроиде Edge, и на компе Edge. Там Microsoft наверняка держит патенты на Hevc. Так что ничего удивительного в том что их браузеры это поддерживают я не вижу.
Это как спрашивать с Apple за внедрение того-же Hevc/Heic и xHE-AAC. Они всегда так делали. И патентами они тоже владеют. Им тупо выгодно внедрять такие технологии.
>>460781
Копротивление Apple с кодеками в 2024 году выглядят очень смешно. Уже не то время, когда отказ от Флешплеера уничтожал его.
Копротивление Apple с кодеками в 2024 году выглядят очень смешно. Уже не то время, когда отказ от Флешплеера уничтожал его.
474 Кб, 869x1012>>460916
При чём здесь Apple, если патентодержателем хевка является Broadcom, а Apple лишь отчисляет как и МС? Флеешплеер это вообще Adobe. У Apple так-то годные есть кодеки вроде ALAC и AAC.
Сам же HEVC поддерживается солидным спектром устройств на ОС Android/Windows/macOS. На линуксе через VAAnusPI на хромых. Копробздоксич же 10 бит не держит, а смысла в хевке 8 бит нет, для этого х264 есть. Если говорить о хардвари, то даже одноплатниками на рокчипе хэвк поддерживается.
При чём здесь Apple, если патентодержателем хевка является Broadcom, а Apple лишь отчисляет как и МС? Флеешплеер это вообще Adobe. У Apple так-то годные есть кодеки вроде ALAC и AAC.
Сам же HEVC поддерживается солидным спектром устройств на ОС Android/Windows/macOS. На линуксе через VAAnusPI на хромых. Копробздоксич же 10 бит не держит, а смысла в хевке 8 бит нет, для этого х264 есть. Если говорить о хардвари, то даже одноплатниками на рокчипе хэвк поддерживается.
>>460918
Перефразирую. Копротивление Apple с кодеками выглядятят сегодня как "на зло маме отморожу уши". Эплотехника единственная где сегодня надо думать о форматах.
Перефразирую. Копротивление Apple с кодеками выглядятят сегодня как "на зло маме отморожу уши". Эплотехника единственная где сегодня надо думать о форматах.
>>461119
Следи за логикой
1) Гугл устаревший формат поиска информации в годы нейросетей
2) Нейросети компилируют инфу с сотен сайтов за раз и выдают лучший ответ сразу. Нейросети либо заменять поисковые энжины либо поглотят их
3) Двач это не гугл
4) На дваче пишут одни боты
5) Судя по качеству ботов они пользуют минимум гпт 4.0 и платят за нее
6) Спросить на дваче = Прогрессивной бесплатно спросить у гпт 4.0 ответ, вместо того чтобы пользоваться устаревшим гуглом, который скоро вообще перестанет существовать
Следи за логикой
1) Гугл устаревший формат поиска информации в годы нейросетей
2) Нейросети компилируют инфу с сотен сайтов за раз и выдают лучший ответ сразу. Нейросети либо заменять поисковые энжины либо поглотят их
3) Двач это не гугл
4) На дваче пишут одни боты
5) Судя по качеству ботов они пользуют минимум гпт 4.0 и платят за нее
6) Спросить на дваче = Прогрессивной бесплатно спросить у гпт 4.0 ответ, вместо того чтобы пользоваться устаревшим гуглом, который скоро вообще перестанет существовать
>>461157
Заебись шутканул, можешь пройти за медалью Петросяна вне очереди
Заебись шутканул, можешь пройти за медалью Петросяна вне очереди
1) Вырезаю часть видео, первые секунды черный экран, потом появляется изображение. Как сделать, что бы изображение было при обрезании с любой секунды?
2) Как вырезать кусок из середины видео, т.е. начало и конец соединились автоматом?
2) Как вырезать кусок из середины видео, т.е. начало и конец соединились автоматом?
>>461195
О, наивный новичок. Иди читай про I-фреймы и группы зависимых кадров. Без перекодирования ты можешь резать видео только по конкретным точкам, где декодер может быть инициализирован полной картинкой (если, конечно, не хранишь исходные материалы в специфических форматах сжатия с независимыми кадрами).
О, наивный новичок. Иди читай про I-фреймы и группы зависимых кадров. Без перекодирования ты можешь резать видео только по конкретным точкам, где декодер может быть инициализирован полной картинкой (если, конечно, не хранишь исходные материалы в специфических форматах сжатия с независимыми кадрами).
>>461198
Это уже понял.
Может есть статьи с примерами, как там чего перекодировать?
>только по конкретным точкам
Это уже понял.
>Иди читай про I-фреймы и группы зависимых кадров
Может есть статьи с примерами, как там чего перекодировать?
298 Кб, webm,406x720, 0:04
Когда вырезаю кусок видео, у меня картинка зависает на первых секундах, как на этой шебм, юзаю обычную команду ffmpeg -i input.webm -ss 00:01:04 -to 00:01:09 -c:v copy -c:a copy output.webm
Почему так, как резать чтобы кадр не зависал?
Почему так, как резать чтобы кадр не зависал?
>>461206
Целиком перекодируешь всё видео.
Целиком перекодируешь всё видео.
Блядь, неужеле нет нормального гуя для ffprobe? Чтобы было точное время до миллисекунд и количество фреймов для каждого стрима?
Аж пришлось расчехлить лазарус и самому писать.
Аж пришлось расчехлить лазарус и самому писать.
>>462348
А зачем, когда половина тех, кому нужно его статистику анализировать, умеет в какой-нибудь python?
>Блядь, неужеле нет нормального гуя для ffprobe?
А зачем, когда половина тех, кому нужно его статистику анализировать, умеет в какой-нибудь python?
>>462362
Да ладно, будто тут такие есть. Сейчас накидаю приложение на делфи, охуеете.
>кому нужно его статистику анализировать, умеет в какой-нибудь python?
Да ладно, будто тут такие есть. Сейчас накидаю приложение на делфи, охуеете.
Зачем существует что-то кроме av1? Это же топчик, даже на preset 8
>>463471
В разных вариантах вставки команды -ss относительно инпута.
https://trac.ffmpeg.org/wiki/Seeking
В разных вариантах вставки команды -ss относительно инпута.
https://trac.ffmpeg.org/wiki/Seeking
>>463602
Уже который раз задают одни и те же вопросы, которые сводятся к этому мануалу. Хоть в шапку добавляй, задолбали
мимо
Уже который раз задают одни и те же вопросы, которые сводятся к этому мануалу. Хоть в шапку добавляй, задолбали
мимо
Все кто хочет нарезать видосики через ffmpeg, используйте https://github.com/mifi/lossless-cut/releases 3.61+
По умолчанию начинает резать с ключевых кадров, но не всегда точно определяет нужный ключевой кадр, при экспорте там можно выставить Shift all start times и тогда отрежет точно. Также там есть лог с командами ffmpeg
По умолчанию начинает резать с ключевых кадров, но не всегда точно определяет нужный ключевой кадр, при экспорте там можно выставить Shift all start times и тогда отрежет точно. Также там есть лог с командами ffmpeg
Профаны, поясните пожалуйста, в чем разница между Storage size и Display Size?
Smplayer показывает, что разрешение 720x576, но скрины получаются в 1024x576, а handbrake пытается изменить размер в 720x406.
Smplayer показывает, что разрешение 720x576, но скрины получаются в 1024x576, а handbrake пытается изменить размер в 720x406.
>>464231
Storage size — это размер растра, под который изображение дискретизировано, который кодируется и декодируется.
Display size — это размер растра, в который изображение должно быть развёрнуто с учётом отношения сторон, указанного флагами в потоке данных.
Например, на PAL-совместимых DVD максимальный размер растра — 720×576 точек, а в потоке данных MPEG-ES есть два разрешённых отношения геометрических сторон кадра — 4:3 или 16:9. Соответственно, при воспроизведении, если телевизор, например, имеет отношение сторон светящейся части экрана 16:9, то при развёртке потока с соотношением 16:9 каждую из 576 строк телевизор развернёт в полную длину светящейся части экрана, а если соотношение в потоке было 4:3, то для каждой строки телевизор сделает справа и слева чёрные отступы и развернёт кадр с геометрическим соотношением 4:3 и чёрными полосками слева и справа.
Вообще подобное является типичным способом хранения изображений для стандартизованных систем телевидения — пиксель растра имеет с в проекции конечного изображения разную пространственную плотность по вертикали и по горизонтали. В современной вычислительной технике при отображении синтезированных изображений графического интерфейса пользователя, как правило, пиксель и, соответственно, растр имеют одинакую плотность по вертикали и горизонтали.
Теперь к твоему примеру.
1. Размер хранимого растра — 720×576.
2. Указано, что геометрическое соотношение сторон кадра 16:9.
3. Для разворачивания такого изображения на экране монитора с квадратными пикселями необходимо провести аффинное преобразование.
4. Программа-отрисовщик передискретизирует каждую строку из 720 отсчётов в строку из 1024 отсчётов и выводит её. Таким образом изображение "растягивается по горизонтали, чтобы при его отрисовке на экране монитора картинка имелв целевое соотношение сторон 16:9.
Примерно так.
Storage size — это размер растра, под который изображение дискретизировано, который кодируется и декодируется.
Display size — это размер растра, в который изображение должно быть развёрнуто с учётом отношения сторон, указанного флагами в потоке данных.
Например, на PAL-совместимых DVD максимальный размер растра — 720×576 точек, а в потоке данных MPEG-ES есть два разрешённых отношения геометрических сторон кадра — 4:3 или 16:9. Соответственно, при воспроизведении, если телевизор, например, имеет отношение сторон светящейся части экрана 16:9, то при развёртке потока с соотношением 16:9 каждую из 576 строк телевизор развернёт в полную длину светящейся части экрана, а если соотношение в потоке было 4:3, то для каждой строки телевизор сделает справа и слева чёрные отступы и развернёт кадр с геометрическим соотношением 4:3 и чёрными полосками слева и справа.
Вообще подобное является типичным способом хранения изображений для стандартизованных систем телевидения — пиксель растра имеет с в проекции конечного изображения разную пространственную плотность по вертикали и по горизонтали. В современной вычислительной технике при отображении синтезированных изображений графического интерфейса пользователя, как правило, пиксель и, соответственно, растр имеют одинакую плотность по вертикали и горизонтали.
Теперь к твоему примеру.
1. Размер хранимого растра — 720×576.
2. Указано, что геометрическое соотношение сторон кадра 16:9.
3. Для разворачивания такого изображения на экране монитора с квадратными пикселями необходимо провести аффинное преобразование.
4. Программа-отрисовщик передискретизирует каждую строку из 720 отсчётов в строку из 1024 отсчётов и выводит её. Таким образом изображение "растягивается по горизонтали, чтобы при его отрисовке на экране монитора картинка имелв целевое соотношение сторон 16:9.
Примерно так.
>>464349
То есть если коротко, это не тот эффект, когда берут исходник в 4:3 и для экрана 16:9, вместо растягивания всей картинки, берут часть боковой стороны и растягивают до краев?
То есть если коротко, это не тот эффект, когда берут исходник в 4:3 и для экрана 16:9, вместо растягивания всей картинки, берут часть боковой стороны и растягивают до краев?
>>464432
Ты описываешь другой совсем случай. То, о чём говоришь ты — это в англоязычных источниках называется panscan и letterbox. Это способы отображения картинки с одним отношением сторон на устройствах с другим отношением сторон. Как правило, центры светящейся поверхности отображающего устройства и центр отображаемой картинки совпадают (но, насколько помню, в потоке по h.264 есть возможность сместить центр определёнными флагами). При этом пропорциональные (в том смысле, что имеющие при отображении правильные геометрические пропорции) изображения можно развернуть с чёрными полями вокруг полного изображения (letterbox) или с частичным показом изображения (panscan), когда изображение масштабируется до полного заполнения размера светящейся поверхности по одной из сторон с отбрасыванием части изображения с краёв вдоль другой стороны.
Опять же, в технике кино используются отношения сторон кадра, отличные от 16:9 и 4:3, в частности ранее были популярны соотношения 2,4, 1,85, 2,35 для сторон кадра. Такие даже на устройствах 16:9 будут отображены либо с полосками, либо с усечением. В потоках на носителях, изготовленных в соответствии с телевизионными стандартами, для фильмов с тамими соотношениями размеров кадра, изображение кодируется сразу вместе с полосками, чтобы сформировать растр стандартного отношения сторон 16:9.
А ещё в качестве художественного приёма в кино используется и переменное соотношение сторон изображения в кадре — тут, как правило, только полоски и выручают.
Хотел коротко. Но там ситуация слишком запутанная, чтобы а двух словах рассказать. Если коротко, то на тёплых ламповых телевизорах пиксели не были квадратными, как на современных мониторах. А в действительности, как тебе может быть известно, светящиеся устройства сомтоят не из непосредственно прямоугольной таблицы цветных пикселей прямоугольной формы, а скорее являются массивом нефазированных излучателей, направление диаграммообразующих элементов в каждом из которых зависит от длины волны доминирующего излучения.
Ты описываешь другой совсем случай. То, о чём говоришь ты — это в англоязычных источниках называется panscan и letterbox. Это способы отображения картинки с одним отношением сторон на устройствах с другим отношением сторон. Как правило, центры светящейся поверхности отображающего устройства и центр отображаемой картинки совпадают (но, насколько помню, в потоке по h.264 есть возможность сместить центр определёнными флагами). При этом пропорциональные (в том смысле, что имеющие при отображении правильные геометрические пропорции) изображения можно развернуть с чёрными полями вокруг полного изображения (letterbox) или с частичным показом изображения (panscan), когда изображение масштабируется до полного заполнения размера светящейся поверхности по одной из сторон с отбрасыванием части изображения с краёв вдоль другой стороны.
Опять же, в технике кино используются отношения сторон кадра, отличные от 16:9 и 4:3, в частности ранее были популярны соотношения 2,4, 1,85, 2,35 для сторон кадра. Такие даже на устройствах 16:9 будут отображены либо с полосками, либо с усечением. В потоках на носителях, изготовленных в соответствии с телевизионными стандартами, для фильмов с тамими соотношениями размеров кадра, изображение кодируется сразу вместе с полосками, чтобы сформировать растр стандартного отношения сторон 16:9.
А ещё в качестве художественного приёма в кино используется и переменное соотношение сторон изображения в кадре — тут, как правило, только полоски и выручают.
>если коротко
Хотел коротко. Но там ситуация слишком запутанная, чтобы а двух словах рассказать. Если коротко, то на тёплых ламповых телевизорах пиксели не были квадратными, как на современных мониторах. А в действительности, как тебе может быть известно, светящиеся устройства сомтоят не из непосредственно прямоугольной таблицы цветных пикселей прямоугольной формы, а скорее являются массивом нефазированных излучателей, направление диаграммообразующих элементов в каждом из которых зависит от длины волны доминирующего излучения.
>>464432
Ты описываешь другой совсем случай. То, о чём говоришь ты — это в англоязычных источниках называется panscan и letterbox. Это способы отображения картинки с одним отношением сторон на устройствах с другим отношением сторон. Как правило, центры светящейся поверхности отображающего устройства и центр отображаемой картинки совпадают (но, насколько помню, в потоке по h.264 есть возможность сместить центр определёнными флагами). При этом пропорциональные (в том смысле, что имеющие при отображении правильные геометрические пропорции) изображения можно развернуть с чёрными полями вокруг полного изображения (letterbox) или с частичным показом изображения (panscan), когда изображение масштабируется до полного заполнения размера светящейся поверхности по одной из сторон с отбрасыванием части изображения с краёв вдоль другой стороны.
Опять же, в технике кино используются отношения сторон кадра, отличные от 16:9 и 4:3, в частности ранее были популярны соотношения 2,4, 1,85, 2,35 для сторон кадра. Такие даже на устройствах 16:9 будут отображены либо с полосками, либо с усечением. В потоках на носителях, изготовленных в соответствии с телевизионными стандартами, для фильмов с тамими соотношениями размеров кадра, изображение кодируется сразу вместе с полосками, чтобы сформировать растр стандартного отношения сторон 16:9.
А ещё в качестве художественного приёма в кино используется и переменное соотношение сторон изображения в кадре — тут, как правило, только полоски и выручают.
Хотел коротко. Но там ситуация слишком запутанная, чтобы а двух словах рассказать. Если коротко, то на тёплых ламповых телевизорах пиксели не были квадратными, как на современных мониторах. А в действительности, как тебе может быть известно, светящиеся устройства сомтоят не из непосредственно прямоугольной таблицы цветных пикселей прямоугольной формы, а скорее являются массивом нефазированных излучателей, направление диаграммообразующих элементов в каждом из которых зависит от длины волны доминирующего излучения.
Ты описываешь другой совсем случай. То, о чём говоришь ты — это в англоязычных источниках называется panscan и letterbox. Это способы отображения картинки с одним отношением сторон на устройствах с другим отношением сторон. Как правило, центры светящейся поверхности отображающего устройства и центр отображаемой картинки совпадают (но, насколько помню, в потоке по h.264 есть возможность сместить центр определёнными флагами). При этом пропорциональные (в том смысле, что имеющие при отображении правильные геометрические пропорции) изображения можно развернуть с чёрными полями вокруг полного изображения (letterbox) или с частичным показом изображения (panscan), когда изображение масштабируется до полного заполнения размера светящейся поверхности по одной из сторон с отбрасыванием части изображения с краёв вдоль другой стороны.
Опять же, в технике кино используются отношения сторон кадра, отличные от 16:9 и 4:3, в частности ранее были популярны соотношения 2,4, 1,85, 2,35 для сторон кадра. Такие даже на устройствах 16:9 будут отображены либо с полосками, либо с усечением. В потоках на носителях, изготовленных в соответствии с телевизионными стандартами, для фильмов с тамими соотношениями размеров кадра, изображение кодируется сразу вместе с полосками, чтобы сформировать растр стандартного отношения сторон 16:9.
А ещё в качестве художественного приёма в кино используется и переменное соотношение сторон изображения в кадре — тут, как правило, только полоски и выручают.
>если коротко
Хотел коротко. Но там ситуация слишком запутанная, чтобы а двух словах рассказать. Если коротко, то на тёплых ламповых телевизорах пиксели не были квадратными, как на современных мониторах. А в действительности, как тебе может быть известно, светящиеся устройства сомтоят не из непосредственно прямоугольной таблицы цветных пикселей прямоугольной формы, а скорее являются массивом нефазированных излучателей, направление диаграммообразующих элементов в каждом из которых зависит от длины волны доминирующего излучения.
>>460096
двач поддерживает hevc
двач поддерживает hevc
![STALKER Fan film - Contract [스토커 팬영상] [GvJ91D-N29g].mp4](https://2ch.life/s/thumb/3441805/17169088182700s.jpg)
52,6 Мб, mp4,1280x720, 14:11
>>460670
в андроидах поддержка hevc есть с 2015, но только недавно его включили в хроме
в андроидах поддержка hevc есть с 2015, но только недавно его включили в хроме
Там VK переходит на VP9+Opus. Но только для роликов в высоком разрешении и с большим количеством просмотров, насколько я заметил, а остальные по-прежнему в AVC+AAC. Битрейт даже ниже, чем на YouTube, но выглядит чётенько.
>>466844
я ебу лол
я ебу лол
>>466927
Хз хз, только сегодня заметил, хотя ролики всегда перетягиваю в mpv и вижу при запуске статистическую инфу.
Хз хз, только сегодня заметил, хотя ролики всегда перетягиваю в mpv и вижу при запуске статистическую инфу.
Нужно конвертировать 4к в 1080p.
Сразу скажу, я не разбираюсь в форматах, кодеках и вот этом вот всем. Сам видос с кодеком h.264
1) ffmpeg -i input.mp4 -vf scale=1920:1080 -c:a copy output.mp4
2) ffmpeg -i input.mp4 -c:v libx265 -vf scale=1920:1080 -c:a copy output.mp4
1й вариант быстрее конвертирует, но и размер больше. 2й вариант дольше конвертация, но размер меньше. НО, во втором случае, у видоса пропадает иконка/превьюшка, как это исправить? А в остальном все правильно делаю?
Сразу скажу, я не разбираюсь в форматах, кодеках и вот этом вот всем. Сам видос с кодеком h.264
1) ffmpeg -i input.mp4 -vf scale=1920:1080 -c:a copy output.mp4
2) ffmpeg -i input.mp4 -c:v libx265 -vf scale=1920:1080 -c:a copy output.mp4
1й вариант быстрее конвертирует, но и размер больше. 2й вариант дольше конвертация, но размер меньше. НО, во втором случае, у видоса пропадает иконка/превьюшка, как это исправить? А в остальном все правильно делаю?
Кто-нибудь занимался картами захвата?
Я могу на лету через ffmpeg захватывать 4k30fps и сразу кодировать его в файл x264, а не raw-видео?
В raw видео много ошибок input buffer overrun и битрейт сумасшедший, там спустя 2 секунды уже виснет захват, проседает FPS.
Может просто пека не справляется?
Я могу на лету через ffmpeg захватывать 4k30fps и сразу кодировать его в файл x264, а не raw-видео?
В raw видео много ошибок input buffer overrun и битрейт сумасшедший, там спустя 2 секунды уже виснет захват, проседает FPS.
Может просто пека не справляется?
>>468618
#1 тебе конвертирует енкодером по умолчанию потому что ты ничего не указал, то есть libx264. Поэтому размер больше и превьюшка работает. #2 превьюшка не работает потому что эксплорер не умеет по умолчанию в h.265.
Ну и вообще - дефолтные значения такие себе. Хотябы preset и crf укажи поприличней. Хотя, если качество устраивает - и так сойдет.
#1 тебе конвертирует енкодером по умолчанию потому что ты ничего не указал, то есть libx264. Поэтому размер больше и превьюшка работает. #2 превьюшка не работает потому что эксплорер не умеет по умолчанию в h.265.
Ну и вообще - дефолтные значения такие себе. Хотябы preset и crf укажи поприличней. Хотя, если качество устраивает - и так сойдет.
>>468775
Поприличней будет 20-21 для 264 и ~23 для 265.
Пресет slow или slower, но это если ждать не лень и размер важен.
Ничем его вариант не лучше, это просто сокращенный синтаксис. Через vf ты ко всему прочему можешь указать порядок фильтров если у тебя их несколько.
Ставь кодек из MS Store. Ну или сторонние. Или кодируй только в 264 - размер будет больше, но не надо ебаться.
> А какие значения идут по умолчанию и какие считаются поприличней?
> H.264
> The range of the CRF scale is 0–51, where 0 is lossless (for 8 bit only, for 10 bit use -qp 0), 23 is the default, and 51 is worst quality possible. A lower value generally leads to higher quality, and a subjectively sane range is 17–28. Consider 17 or 18 to be visually lossless or nearly so; it should look the same or nearly the same as the input but it isn't technically lossless.
> H.265/HEVC
> Choose a CRF. CRF affects the quality. The default is 28, and it should visually correspond to libx264 video at CRF 23, but result in about half the file size. CRF works just like in x264, so choose the highest value that provides an acceptable quality.
Поприличней будет 20-21 для 264 и ~23 для 265.
Пресет slow или slower, но это если ждать не лень и размер важен.
> А твой вариант чем лучше?
Ничем его вариант не лучше, это просто сокращенный синтаксис. Через vf ты ко всему прочему можешь указать порядок фильтров если у тебя их несколько.
> Так а превью то как оставить?
Ставь кодек из MS Store. Ну или сторонние. Или кодируй только в 264 - размер будет больше, но не надо ебаться.
>>468791
Рекомендованные значения CRF варьируются от разрешения видео же, то что ты привёл, это для Full HD.
Рекомендованные значения CRF варьируются от разрешения видео же, то что ты привёл, это для Full HD.
63 Кб, 248x203>>468711
Никто не захватывал с BlackMagic Decklink?
Собрал ffmpeg с поддержкой decklink устройств(подтянул нативный sdk).
https://ffmpeg.org/ffmpeg-devices.html#Options-4
При попытке указать опцию
format_code <FourCC>
оно захватывает цветные-дебаг-полосы, а не сам поток с HDMI.
Если формат не указывать, он определяется автоматически, и захват идёт нормально.
Но ни один из доступных в списке форматов не работает если указывать вручную.
Что там определяется автоматически и работает - непонятно.
Никто не захватывал с BlackMagic Decklink?
Собрал ffmpeg с поддержкой decklink устройств(подтянул нативный sdk).
https://ffmpeg.org/ffmpeg-devices.html#Options-4
При попытке указать опцию
format_code <FourCC>
оно захватывает цветные-дебаг-полосы, а не сам поток с HDMI.
Если формат не указывать, он определяется автоматически, и захват идёт нормально.
Но ни один из доступных в списке форматов не работает если указывать вручную.
Что там определяется автоматически и работает - непонятно.
>>468836
Лучше будет всё же -vf scale=1920:-2 или -vf scale=-2:1080, т. к. ещё прореживание по цвету есть и большинство кодеров ожидает на входе не RGB, а какой-нибудь YUY2 или YV12.
>Лучше будет -vf scale=-1:1080 чтобы не распидорасить соотношение сторо
Лучше будет всё же -vf scale=1920:-2 или -vf scale=-2:1080, т. к. ещё прореживание по цвету есть и большинство кодеров ожидает на входе не RGB, а какой-нибудь YUY2 или YV12.
Как так получилось, что ваша говнософтина требует больше обучения, чем сраный премьер, в котором в сотни раз больше функционала?
>>469954
Потому что это низкоуровневый манипулятор, который в твоём премьере спрятан за красивым интерфейсом. Если тебе достаточно последнего, то и не заморачивайся, никто не заставляет
Потому что это низкоуровневый манипулятор, который в твоём премьере спрятан за красивым интерфейсом. Если тебе достаточно последнего, то и не заморачивайся, никто не заставляет
580 Кб, 1426x1020два дня не могу решить проблему помогите
почему у меня плеер MPC не использует аппаратное ускорение?
почему у меня плеер MPC не использует аппаратное ускорение?
>>470038
сейчас снес самый полный и поставил стандарт - абсолютно ничего не поменялось
может какая то проблема вновых драйверах нвидиа или проблема в новом паке K-Lite
нужны подсказки специалиста, я не могу перебирать все старые драйвера
помню что раньше аппаратное ускорение работало, на старом компе, на сокете 775
сейчас сокет 1150 и ничего не работает
сейчас снес самый полный и поставил стандарт - абсолютно ничего не поменялось
может какая то проблема вновых драйверах нвидиа или проблема в новом паке K-Lite
нужны подсказки специалиста, я не могу перебирать все старые драйвера
помню что раньше аппаратное ускорение работало, на старом компе, на сокете 775
сейчас сокет 1150 и ничего не работает
>>470205
эта карта на платформе зион 775 работала нормально
после замены материнки пришлось ставить новые драйвера
старый драйвер не устанавливается изза проблем совместимости с новой материнкой
короче пизда
эта карта на платформе зион 775 работала нормально
после замены материнки пришлось ставить новые драйвера
старый драйвер не устанавливается изза проблем совместимости с новой материнкой
короче пизда
50 Кб, 1365x710>>470041
как минимум должен был поменяться рендерер и панель статистики
как минимум должен был поменяться рендерер и панель статистики
>>470246
Какая разница что выставленно, если я два дня потратил на переустановку кучи драйверов и плееров и пробовал все декодеры и разницы в фпс по сравнению с софтовым декодингом не было
Думаю проблема в том что свежия драйвера нвидиа не дают старой видеокарте работать при воспроизведении видео
А старый драйвер работал, но он сейчас не устанавливеется потому что система поменялась, при установке пишет что винда не подерживает версию драйвера 4хх
Какая разница что выставленно, если я два дня потратил на переустановку кучи драйверов и плееров и пробовал все декодеры и разницы в фпс по сравнению с софтовым декодингом не было
Думаю проблема в том что свежия драйвера нвидиа не дают старой видеокарте работать при воспроизведении видео
А старый драйвер работал, но он сейчас не устанавливеется потому что система поменялась, при установке пишет что винда не подерживает версию драйвера 4хх
405 Кб, 1903x838Такая картина в любом проигрывателе
ХЗ что делать
ХЗ что делать
9,4 Мб, mp4,3840x1920, 0:01
короче отбой
у меня работает аппаратное ускорение везде кроме этого файла из телеги, и ему подобных
как образец кидаю фрагмент
может кто нибудь обьяснит что в нем такого что он не декодируется аппаратно
у меня работает аппаратное ускорение везде кроме этого файла из телеги, и ему подобных
как образец кидаю фрагмент
может кто нибудь обьяснит что в нем такого что он не декодируется аппаратно
46 Кб, 544x629>>470402
Цветность наверняка, или профиль выше чем поддерживает кодировщик, загугли таблицу для своего GPU
Цветность наверняка, или профиль выше чем поддерживает кодировщик, загугли таблицу для своего GPU
>>469954
Прежде всего, нпомню, что объяснение коренным образом будет отличаться, в зависимости от познавательной позиции объясняющего. Моё объяснение основано на материалистическом мировоззрении. Если есть сомнения в объективности мироздания или его познаваемости — то проходи мимо.
Во-первых, не обучения, а изучения. Во-вторых, в ffmpeg, как и в большинстве проектов свободного ПО имеется сам предмет для изучения. В отличии от коммерческого ПО, СПО предоставляет не сервис с предельным отчуждением пользователя от всего, что отчуждаемо, а инструмент, доступный, насколько квалификация пользователя позволяет, для изучения и модификации. Поставщик коммерческого ПО стремится сузить роль пользователя по-возможности тотально до потребителя, а авторы СПО держат пользователя за равного. Так творческий коллектив ffmpeg ставит себе задачу обеспечить специалистов высококачественным и удобным инструментом, а не дать среднему обывателю в руки легкоосваиваемую игрушку. Вот так и выходит, что у ffmpeg требования к квалификации пользователя выше.
У тебя какая-то фекальная фиксация. Поговори с психиатром об этом что-ли.
Премьер — хорошая нелинейная монтажка, удобная, промышленная, обеспечивает высокую производительность труда на автоматизированном рабочем месте монтажёра. К вопррсу о лёгкости освоения я бы сразу дал уточнения относительно требований к качеству готовой продукции в смысле грамотности применения монтажных приёмов.
С другой стороны, есть преимущественно технические средства вроде ffmpeg, avisynth (vapoursynth), которые позволяют детально вникнуть в работу с видеопоследовательностями, конкретно формулировать требования в терминах математически достоверных элементарных операций, или близко к ним. Естественно, предполагается, что пользователь имеет специальную подготовку, чтобы он мог в применяемых понятиях разобраться. В таком случае пользователю доступны абстракции, специфические для технического уровня реализации.
Функционал — это математическая функция, являющаяся отображением из произвольного множества в кольцо. Осторожно предположу, что ошибочное применение тобой категорий имеет причиной твою безграмотность, а следствием — несостоятельность твоих суждений о количественных характеристиках.
Теперь попробую понять, что ты пытался высказать со своего бытового обывательского уровня сознания. Ты хочешь сказать, что количество предлагаемых программой Adobe Premiere приёмов автоматизации рабочего места превышает количество таковых у ffmpeg в сотни раз. Но не определяешь точно ни одной общей категории и ни одного точного критерия сравнения не даёшь. Поздравляю — ты получил произвольный бессмысленный результат, грубо нарушая элементарные требования к методу.
>>469956
Не просто спрятан, а умышленно скрыт и почти недоступен в обход красивого интерфейса.
Вот это вопоос философский. Точного ответа на него человечество пока не знает. И из текущего состояния философии ответ даже не просматривается.
>>470372
Невидия в своём репертуаре. У меня тоже есть портативный компьютер, в котором хорошо работает всё, кроме ненужной мне микромхемы невидии.
Прежде всего, нпомню, что объяснение коренным образом будет отличаться, в зависимости от познавательной позиции объясняющего. Моё объяснение основано на материалистическом мировоззрении. Если есть сомнения в объективности мироздания или его познаваемости — то проходи мимо.
>требует больше обучения
>Как так получилось
Во-первых, не обучения, а изучения. Во-вторых, в ffmpeg, как и в большинстве проектов свободного ПО имеется сам предмет для изучения. В отличии от коммерческого ПО, СПО предоставляет не сервис с предельным отчуждением пользователя от всего, что отчуждаемо, а инструмент, доступный, насколько квалификация пользователя позволяет, для изучения и модификации. Поставщик коммерческого ПО стремится сузить роль пользователя по-возможности тотально до потребителя, а авторы СПО держат пользователя за равного. Так творческий коллектив ffmpeg ставит себе задачу обеспечить специалистов высококачественным и удобным инструментом, а не дать среднему обывателю в руки легкоосваиваемую игрушку. Вот так и выходит, что у ffmpeg требования к квалификации пользователя выше.
>говнософтина
>сраный премьер
У тебя какая-то фекальная фиксация. Поговори с психиатром об этом что-ли.
Премьер — хорошая нелинейная монтажка, удобная, промышленная, обеспечивает высокую производительность труда на автоматизированном рабочем месте монтажёра. К вопррсу о лёгкости освоения я бы сразу дал уточнения относительно требований к качеству готовой продукции в смысле грамотности применения монтажных приёмов.
С другой стороны, есть преимущественно технические средства вроде ffmpeg, avisynth (vapoursynth), которые позволяют детально вникнуть в работу с видеопоследовательностями, конкретно формулировать требования в терминах математически достоверных элементарных операций, или близко к ним. Естественно, предполагается, что пользователь имеет специальную подготовку, чтобы он мог в применяемых понятиях разобраться. В таком случае пользователю доступны абстракции, специфические для технического уровня реализации.
>в сотни раз больше функционала?
Функционал — это математическая функция, являющаяся отображением из произвольного множества в кольцо. Осторожно предположу, что ошибочное применение тобой категорий имеет причиной твою безграмотность, а следствием — несостоятельность твоих суждений о количественных характеристиках.
Теперь попробую понять, что ты пытался высказать со своего бытового обывательского уровня сознания. Ты хочешь сказать, что количество предлагаемых программой Adobe Premiere приёмов автоматизации рабочего места превышает количество таковых у ffmpeg в сотни раз. Но не определяешь точно ни одной общей категории и ни одного точного критерия сравнения не даёшь. Поздравляю — ты получил произвольный бессмысленный результат, грубо нарушая элементарные требования к методу.
>>469956
>спрятан за красивым интерфейсом
Не просто спрятан, а умышленно скрыт и почти недоступен в обход красивого интерфейса.
>никто не заставляет
Вот это вопоос философский. Точного ответа на него человечество пока не знает. И из текущего состояния философии ответ даже не просматривается.
>>470372
>Думаю проблема в том что свежия драйвера нвидиа не дают старой видеокарте работать при воспроизведении видео
>А старый драйвер работал, но он сейчас не устанавливеется потому что система поменялась, при установке пишет что винда не подерживает версию драйвера 4хх
Невидия в своём репертуаре. У меня тоже есть портативный компьютер, в котором хорошо работает всё, кроме ненужной мне микромхемы невидии.
>>469954
Прежде всего, нпомню, что объяснение коренным образом будет отличаться, в зависимости от познавательной позиции объясняющего. Моё объяснение основано на материалистическом мировоззрении. Если есть сомнения в объективности мироздания или его познаваемости — то проходи мимо.
Во-первых, не обучения, а изучения. Во-вторых, в ffmpeg, как и в большинстве проектов свободного ПО имеется сам предмет для изучения. В отличии от коммерческого ПО, СПО предоставляет не сервис с предельным отчуждением пользователя от всего, что отчуждаемо, а инструмент, доступный, насколько квалификация пользователя позволяет, для изучения и модификации. Поставщик коммерческого ПО стремится сузить роль пользователя по-возможности тотально до потребителя, а авторы СПО держат пользователя за равного. Так творческий коллектив ffmpeg ставит себе задачу обеспечить специалистов высококачественным и удобным инструментом, а не дать среднему обывателю в руки легкоосваиваемую игрушку. Вот так и выходит, что у ffmpeg требования к квалификации пользователя выше.
У тебя какая-то фекальная фиксация. Поговори с психиатром об этом что-ли.
Премьер — хорошая нелинейная монтажка, удобная, промышленная, обеспечивает высокую производительность труда на автоматизированном рабочем месте монтажёра. К вопррсу о лёгкости освоения я бы сразу дал уточнения относительно требований к качеству готовой продукции в смысле грамотности применения монтажных приёмов.
С другой стороны, есть преимущественно технические средства вроде ffmpeg, avisynth (vapoursynth), которые позволяют детально вникнуть в работу с видеопоследовательностями, конкретно формулировать требования в терминах математически достоверных элементарных операций, или близко к ним. Естественно, предполагается, что пользователь имеет специальную подготовку, чтобы он мог в применяемых понятиях разобраться. В таком случае пользователю доступны абстракции, специфические для технического уровня реализации.
Функционал — это математическая функция, являющаяся отображением из произвольного множества в кольцо. Осторожно предположу, что ошибочное применение тобой категорий имеет причиной твою безграмотность, а следствием — несостоятельность твоих суждений о количественных характеристиках.
Теперь попробую понять, что ты пытался высказать со своего бытового обывательского уровня сознания. Ты хочешь сказать, что количество предлагаемых программой Adobe Premiere приёмов автоматизации рабочего места превышает количество таковых у ffmpeg в сотни раз. Но не определяешь точно ни одной общей категории и ни одного точного критерия сравнения не даёшь. Поздравляю — ты получил произвольный бессмысленный результат, грубо нарушая элементарные требования к методу.
>>469956
Не просто спрятан, а умышленно скрыт и почти недоступен в обход красивого интерфейса.
Вот это вопоос философский. Точного ответа на него человечество пока не знает. И из текущего состояния философии ответ даже не просматривается.
>>470372
Невидия в своём репертуаре. У меня тоже есть портативный компьютер, в котором хорошо работает всё, кроме ненужной мне микромхемы невидии.
Прежде всего, нпомню, что объяснение коренным образом будет отличаться, в зависимости от познавательной позиции объясняющего. Моё объяснение основано на материалистическом мировоззрении. Если есть сомнения в объективности мироздания или его познаваемости — то проходи мимо.
>требует больше обучения
>Как так получилось
Во-первых, не обучения, а изучения. Во-вторых, в ffmpeg, как и в большинстве проектов свободного ПО имеется сам предмет для изучения. В отличии от коммерческого ПО, СПО предоставляет не сервис с предельным отчуждением пользователя от всего, что отчуждаемо, а инструмент, доступный, насколько квалификация пользователя позволяет, для изучения и модификации. Поставщик коммерческого ПО стремится сузить роль пользователя по-возможности тотально до потребителя, а авторы СПО держат пользователя за равного. Так творческий коллектив ffmpeg ставит себе задачу обеспечить специалистов высококачественным и удобным инструментом, а не дать среднему обывателю в руки легкоосваиваемую игрушку. Вот так и выходит, что у ffmpeg требования к квалификации пользователя выше.
>говнософтина
>сраный премьер
У тебя какая-то фекальная фиксация. Поговори с психиатром об этом что-ли.
Премьер — хорошая нелинейная монтажка, удобная, промышленная, обеспечивает высокую производительность труда на автоматизированном рабочем месте монтажёра. К вопррсу о лёгкости освоения я бы сразу дал уточнения относительно требований к качеству готовой продукции в смысле грамотности применения монтажных приёмов.
С другой стороны, есть преимущественно технические средства вроде ffmpeg, avisynth (vapoursynth), которые позволяют детально вникнуть в работу с видеопоследовательностями, конкретно формулировать требования в терминах математически достоверных элементарных операций, или близко к ним. Естественно, предполагается, что пользователь имеет специальную подготовку, чтобы он мог в применяемых понятиях разобраться. В таком случае пользователю доступны абстракции, специфические для технического уровня реализации.
>в сотни раз больше функционала?
Функционал — это математическая функция, являющаяся отображением из произвольного множества в кольцо. Осторожно предположу, что ошибочное применение тобой категорий имеет причиной твою безграмотность, а следствием — несостоятельность твоих суждений о количественных характеристиках.
Теперь попробую понять, что ты пытался высказать со своего бытового обывательского уровня сознания. Ты хочешь сказать, что количество предлагаемых программой Adobe Premiere приёмов автоматизации рабочего места превышает количество таковых у ffmpeg в сотни раз. Но не определяешь точно ни одной общей категории и ни одного точного критерия сравнения не даёшь. Поздравляю — ты получил произвольный бессмысленный результат, грубо нарушая элементарные требования к методу.
>>469956
>спрятан за красивым интерфейсом
Не просто спрятан, а умышленно скрыт и почти недоступен в обход красивого интерфейса.
>никто не заставляет
Вот это вопоос философский. Точного ответа на него человечество пока не знает. И из текущего состояния философии ответ даже не просматривается.
>>470372
>Думаю проблема в том что свежия драйвера нвидиа не дают старой видеокарте работать при воспроизведении видео
>А старый драйвер работал, но он сейчас не устанавливеется потому что система поменялась, при установке пишет что винда не подерживает версию драйвера 4хх
Невидия в своём репертуаре. У меня тоже есть портативный компьютер, в котором хорошо работает всё, кроме ненужной мне микромхемы невидии.
А я не верю, что нашелся дегенерат, полном серьезе написавший вот этот >>470425 высер. Абушные боты сошли с ума окончательно.
Анон, подскажи куда деваются миллисекунду? Точнее так, чаще всего они теряются, но вот есть видео, которое стало длинее на доли миллисекунд. Первый оригинальный файл, а второй уже после сжатия.
Причем количество фреймов одинаковое (nb_read_packets).
[STREAM]
width=1120
height=476
duration=N/A
nb_read_packets=133920
TAG:DURATION=01:33:05.536000000
[/STREAM]
-------------------
[STREAM]
width=1024
height=436
duration=N/A
nb_read_packets=133920
TAG:DURATION=01:33:05.550000000
[/STREAM]
Причем количество фреймов одинаковое (nb_read_packets).
[STREAM]
width=1120
height=476
duration=N/A
nb_read_packets=133920
TAG:DURATION=01:33:05.536000000
[/STREAM]
-------------------
[STREAM]
width=1024
height=436
duration=N/A
nb_read_packets=133920
TAG:DURATION=01:33:05.550000000
[/STREAM]
>>470561
Милисекунды всегда будут плавать, забей. То гопы по-разному нарежутся, то ошибка флота накопится. Внутри контейнеров вообще нет никаких милисекунд, даже они слишком не точные и время там считается в условных единицах специфичных для каждой дорожки.
Милисекунды всегда будут плавать, забей. То гопы по-разному нарежутся, то ошибка флота накопится. Внутри контейнеров вообще нет никаких милисекунд, даже они слишком не точные и время там считается в условных единицах специфичных для каждой дорожки.
>>470434
Жрать захочешь - ещё не так раскорячишься.
Жрать захочешь - ещё не так раскорячишься.
33 Кб, 815x325Каково состояние VVC, а то в MPC-BE вон декодер поменяли.
>>470562
То есть можно рассчитывать на одинаковое количество фреймов? Короче есть большие видофайлы, конвертнул только видеопоток, а аудио не трогал и все закинул в mkv контейнер. Вот теперь боюсь что где-то может быть рассинхрон.
То есть можно рассчитывать на одинаковое количество фреймов? Короче есть большие видофайлы, конвертнул только видеопоток, а аудио не трогал и все закинул в mkv контейнер. Вот теперь боюсь что где-то может быть рассинхрон.
Анон, выручай
Есть два видео с разными параметрами и фпс
Надо объединить их в одно чтобы все корректно воспроизводилось.
Как я понял, нужно их оба реинкоднуть. Но какие настройки прописывать? Пропишите пожалуйста команду, буду признателен.
Видео mp4 оба если что.
Есть два видео с разными параметрами и фпс
Надо объединить их в одно чтобы все корректно воспроизводилось.
Как я понял, нужно их оба реинкоднуть. Но какие настройки прописывать? Пропишите пожалуйста команду, буду признателен.
Видео mp4 оба если что.
>>470658
Отчёты mediainfo, пожалуйста. И ответь на вопрос, как ты результат использовать собрался (закодированное же где-то воспроизводится должно).
>Есть два видео
Отчёты mediainfo, пожалуйста. И ответь на вопрос, как ты результат использовать собрался (закодированное же где-то воспроизводится должно).
>>470578
Иногда допускалась потеря последнего кадра даже при упаковке mpeg-es в mpeg-ps через те же ffmeg или mplex. Возможно, что коммерческие программы тоже грешат подобным, но я не исследовал достаточно плотно.
Есть у ffmpeg флажок genpts. Используй его! Он заставит ffmpeg заново вычислить для каждого кадра время воспроизведения. Оно будет использовано по правилам целевого контейнера. Должно, с большой вероятностью, помочь.
>То есть можно рассчитывать на одинаковое количество фреймов?
Иногда допускалась потеря последнего кадра даже при упаковке mpeg-es в mpeg-ps через те же ffmeg или mplex. Возможно, что коммерческие программы тоже грешат подобным, но я не исследовал достаточно плотно.
>Вот теперь боюсь что где-то может быть рассинхрон.
Есть у ffmpeg флажок genpts. Используй его! Он заставит ffmpeg заново вычислить для каждого кадра время воспроизведения. Оно будет использовано по правилам целевого контейнера. Должно, с большой вероятностью, помочь.
>>470827
Благодарю, анон.
>Есть у ffmpeg флажок genpts. Используй его! Он заставит ffmpeg заново вычислить для каждого кадра время воспроизведения.
Благодарю, анон.
>>441805 (OP)
Я ламер поэтому у меня только один вопрос VP8 или VP9? Что лучше в плане кроссплатформенности, я хочу точно знать что шебм откроется у всех и будет звучать как задумано.
Я ламер поэтому у меня только один вопрос VP8 или VP9? Что лучше в плане кроссплатформенности, я хочу точно знать что шебм откроется у всех и будет звучать как задумано.
>>471481
Выбери два любых пункта.
VP9, если устройства после 2018 года выпуска.
Вёб-приложения.
Не уверен, но возможно, что Opus.
Я уже четыре насчитал.
>шебм
>откроется
>у всех
Выбери два любых пункта.
>VP8 или VP9
VP9, если устройства после 2018 года выпуска.
>Что лучше в плане кроссплатформенности
Вёб-приложения.
>будет звучать как задумано
Не уверен, но возможно, что Opus.
>только один вопрос
Я уже четыре насчитал.
>>471481
VP9
H.264
У всех точно не откроется, в сафари до сих пор приключения что с Vorbis что с Opus
Opus
>VP8 или VP9
VP9
>Что лучше в плане кроссплатформенности
H.264
>я хочу точно знать что шебм откроется у всех
У всех точно не откроется, в сафари до сих пор приключения что с Vorbis что с Opus
>будет звучать как задумано
Opus
>>471481
H.265 как преемник H.264.
С H.265 на нормальных ОС (пик 1 Android, пик 2 Windows 10/11, пик 3 macOS) проблем не будет, прыщавых дегенератов и пердиксов-ретардов на утятичах, офк в расчёт не берём, там необходимо применение медикаментозного лечения.
> Я ламер поэтому у меня только один вопрос VP8 или VP9
H.265 как преемник H.264.
> Что лучше в плане кроссплатформенности, я хочу точно знать что шебм откроется у всех и будет звучать как задумано.
С H.265 на нормальных ОС (пик 1 Android, пик 2 Windows 10/11, пик 3 macOS) проблем не будет, прыщавых дегенератов и пердиксов-ретардов на утятичах, офк в расчёт не берём, там необходимо применение медикаментозного лечения.
Что лучше для дваче вебм, svt или aom? вебм или мп4? А то давно пилил свт кажется и косяк был с превью. И конвертер графический подскажите, буквы вводить для меня слишком сложно. handbrake не понравился.
52 Кб, 380x380Можете дауну на пальцах объяснить разницу между кодеком и контейнером?
Все ли кодеки можно упаковать во все контейнеры?
Если я Raw видео записал yuv/argb(буквально только биты видеоданных), в какой контейнер его можно засунуть?
Все ли кодеки можно упаковать во все контейнеры?
Если я Raw видео записал yuv/argb(буквально только биты видеоданных), в какой контейнер его можно засунуть?
>>472455
Кодек - это файл.
Контейнер - это папка.
В папке много файлов может быть.
>Можете дауну на пальцах объяснить разницу между кодеком и контейнером?
Кодек - это файл.
Контейнер - это папка.
В папке много файлов может быть.
13 Кб, 242x208Если я ffmpeg соберу в докер-контейнере и собранный бинарник вытащу в хостовую OS, он будет работать, или один хуй он тянет зависимости/либы из системы напрямую и самодостаточный standallone бинарник собрать невозможно?
Нужно чтобы один жирный особый билд под карту захвата собрать, со всякими x265, фильтрами, но не хочется кучу говна в хостовую тачку ставить.
Нужно чтобы один жирный особый билд под карту захвата собрать, со всякими x265, фильтрами, но не хочется кучу говна в хостовую тачку ставить.
>>472457
Ну зачем ты настолько все упростил?
>>472455
Кодек — это в первую очередь алгоритм, которым исходные данные сжимаются, чтобы не весили килотонны, а также восстанавливаются при воспроизведении.
А медиаконтейнер — это как раз формат файла, содержащий данные, преобразованные кодеками. Например, типичный MKV файл с фильмом, который ты скачал с торрента — это контейнер, в котором содержится видеоряд сжатый кодеком "А", несколько аудиодорожек, сжатые кодеками "B", "C", "D", ..., и субтитры, которые есть текст с временными метками.
Нет, зависит от того, какой контейнер что поддерживает.
Вот тут хрен знает. Если в твоём файле действительно нет никаких метаданных — то ни в какой, поскольку контейнеру непонятно как это воспроизводить.
Если тебе нужна помощь по этому конкретному вопросу, то опиши подробнее, что за файл, откуда он у тебя взялся, и зачем тебе его засовывать в контейнер?
Ну зачем ты настолько все упростил?
>>472455
> Можете дауну на пальцах объяснить разницу между кодеком и контейнером?
Кодек — это в первую очередь алгоритм, которым исходные данные сжимаются, чтобы не весили килотонны, а также восстанавливаются при воспроизведении.
А медиаконтейнер — это как раз формат файла, содержащий данные, преобразованные кодеками. Например, типичный MKV файл с фильмом, который ты скачал с торрента — это контейнер, в котором содержится видеоряд сжатый кодеком "А", несколько аудиодорожек, сжатые кодеками "B", "C", "D", ..., и субтитры, которые есть текст с временными метками.
> Все ли кодеки можно упаковать во все контейнеры?
Нет, зависит от того, какой контейнер что поддерживает.
> Если я Raw видео записал yuv/argb(буквально только биты видеоданных), в какой контейнер его можно засунуть?
Вот тут хрен знает. Если в твоём файле действительно нет никаких метаданных — то ни в какой, поскольку контейнеру непонятно как это воспроизводить.
Если тебе нужна помощь по этому конкретному вопросу, то опиши подробнее, что за файл, откуда он у тебя взялся, и зачем тебе его засовывать в контейнер?
>>472458
Навереое возможно, если включить статическую линковку для всех зависимостей. Только ещё и сами зависимости придётся пересобрать чтобы они могли линковаться статически
Вот нашлось что-то похожее
https://github.com/zimbatm/ffmpeg-static
> Если я ffmpeg соберу в докер-контейнере и собранный бинарник вытащу в хостовую OS, он будет работать, или один хуй он тянет зависимости/либы из системы напрямую и самодостаточный standallone бинарник собрать невозможно?
Навереое возможно, если включить статическую линковку для всех зависимостей. Только ещё и сами зависимости придётся пересобрать чтобы они могли линковаться статически
Вот нашлось что-то похожее
https://github.com/zimbatm/ffmpeg-static
>>472455
Берёшь тристра jpg картинок с последовательными кадрами и пакуешь в zip архив – ты у мамы кодек.
Этот архив и mp3 файл с музыкой запаковываешь в tar.gz – это контейнер.
Однако ещё в tar.gz пожалуй надо положить txt файл в котором написано что за зип и мп3 в нём лежат.
И да и нет. По спеке обычно наборы ограничены. Технически – берёшь и запаковываешь AV1 в ISOBMFF, полиция кодеков к тебе не придёт. Но играть это скорее всего никто кроме тебя конечно же не будет.
Вот хуй знает, такое в индустрии практикуется только чтобы с камеры снять.
Сильно сомневаюсь что тебе такое на самом деле надо. Ты посчитай сколько у тебя секунда весить будет умножив битность даже на пососные уже 1920 х 1080 х 30 фпс.
Берёшь тристра jpg картинок с последовательными кадрами и пакуешь в zip архив – ты у мамы кодек.
Этот архив и mp3 файл с музыкой запаковываешь в tar.gz – это контейнер.
Однако ещё в tar.gz пожалуй надо положить txt файл в котором написано что за зип и мп3 в нём лежат.
>Все ли кодеки можно упаковать во все контейнеры?
И да и нет. По спеке обычно наборы ограничены. Технически – берёшь и запаковываешь AV1 в ISOBMFF, полиция кодеков к тебе не придёт. Но играть это скорее всего никто кроме тебя конечно же не будет.
>буквально только биты видеоданных
Вот хуй знает, такое в индустрии практикуется только чтобы с камеры снять.
Сильно сомневаюсь что тебе такое на самом деле надо. Ты посчитай сколько у тебя секунда весить будет умножив битность даже на пососные уже 1920 х 1080 х 30 фпс.
122 Кб, 800x800>>472467
Файл - захват 4K видеопотока с карты захвата, а в карту захвата её шлёт другой пека по HDMI играя фуллскрин видос 4k.
В контейнер raw-видео хотелось засунуть чтобы проще воспроизводить, чтобы метадата о формате пикселей, FPS и разрешении была вместе с видеопотоком, и я не указывал их в ffplay вручную каждый раз.
Задача - автоматически по ночам проверять корректность работы видеовывода девайса (ПК), сравнивать транслируемый видеопоток с получаемым на карте.
Сегодня получил такой raw несжатый видеопоток и даже там цвета плывут чучуть по отношению к исходнику.
Хочется получить 1 в 1, что послал то получил, чтобы прямо бит-в-бит (после обрезки лишних краевых кадров синхронизации, естественно).
Возможно видеовывод тоже вносит искажения и исходник предварительно ужимает до 420p прежде чем послать в карту захвата, а возможно карта захвата пиздит что может принимать 444p. Не зря же в ПК видеодрайверах дают на выбор вывод RGB YCBR422...
Я спрашивал про контейнеры потому что у ffmpeg есть мудацкая фича - он контейнер определяет автоматически по расширению выходного файла. И я не понимал почему у меня условно названный output.mov (mov я назвал просто чтобы знать что это какой-то МУВик, а не текстовый лог рандомный) с какого-то хера кодируется в h264, хотя я явно не говорил делать энкод в h264.
Почему он сопоставил mov именно в h264 а не в какой-то другой?
И ещё у него в документации написано, что можно контейнер явно задать как -f mp4 -y zalupa.avi, но он всё равно это не поймёт и будет тригерриться на avi.
>Если тебе нужна помощь по этому конкретному вопросу, то опиши подробнее, что за файл, откуда он у тебя взялся, и зачем тебе его засовывать в контейнер?
Файл - захват 4K видеопотока с карты захвата, а в карту захвата её шлёт другой пека по HDMI играя фуллскрин видос 4k.
В контейнер raw-видео хотелось засунуть чтобы проще воспроизводить, чтобы метадата о формате пикселей, FPS и разрешении была вместе с видеопотоком, и я не указывал их в ffplay вручную каждый раз.
Задача - автоматически по ночам проверять корректность работы видеовывода девайса (ПК), сравнивать транслируемый видеопоток с получаемым на карте.
Сегодня получил такой raw несжатый видеопоток и даже там цвета плывут чучуть по отношению к исходнику.
Хочется получить 1 в 1, что послал то получил, чтобы прямо бит-в-бит (после обрезки лишних краевых кадров синхронизации, естественно).
Возможно видеовывод тоже вносит искажения и исходник предварительно ужимает до 420p прежде чем послать в карту захвата, а возможно карта захвата пиздит что может принимать 444p. Не зря же в ПК видеодрайверах дают на выбор вывод RGB YCBR422...
Я спрашивал про контейнеры потому что у ffmpeg есть мудацкая фича - он контейнер определяет автоматически по расширению выходного файла. И я не понимал почему у меня условно названный output.mov (mov я назвал просто чтобы знать что это какой-то МУВик, а не текстовый лог рандомный) с какого-то хера кодируется в h264, хотя я явно не говорил делать энкод в h264.
Почему он сопоставил mov именно в h264 а не в какой-то другой?
И ещё у него в документации написано, что можно контейнер явно задать как -f mp4 -y zalupa.avi, но он всё равно это не поймёт и будет тригерриться на avi.
>>472468
Спасибо
Спасибо
Короче, я >>472455 понял. Спасибо всем.
Кодек - алгоритм обработки данных одного типа (видео/аудио) (с-сжатием/без-сжатия) используемый с целью экономии места на накопителе или соблюдения ограничений пропускной способности канала или аппаратных возможностей устройства.
Контейнер - алгоритм конкатенации данных различного типа (аудио + видео + субтитры + мета) в один файл для удобства пользователя (чтобы не пришлось хранить фильм в 5 различных файлах, хотя некоторые раздачи на торрентах именно так и раздают, дорожки отдельно, субтитры отдельно).
Кодек - алгоритм обработки данных одного типа (видео/аудио) (с-сжатием/без-сжатия) используемый с целью экономии места на накопителе или соблюдения ограничений пропускной способности канала или аппаратных возможностей устройства.
Контейнер - алгоритм конкатенации данных различного типа (аудио + видео + субтитры + мета) в один файл для удобства пользователя (чтобы не пришлось хранить фильм в 5 различных файлах, хотя некоторые раздачи на торрентах именно так и раздают, дорожки отдельно, субтитры отдельно).
>>472490
Ну, мне всё равно кажется ты сложным путём пошёл. Если тебе валидировать видеопоток, то можно просто посчитать метрики качества кодирования (по сути похожести двух видео): PSNR банальный, он в ффмпеге есть. Или VMAF, или модные молодёжные SSIM, LPIPS... тысячи их, тебе скорее всего любая подойдёт какая проще заведётся.
Кодировать в высокое качество даже не надо будет, хоть 480п сравнивай с определённым порогом.
Ну, мне всё равно кажется ты сложным путём пошёл. Если тебе валидировать видеопоток, то можно просто посчитать метрики качества кодирования (по сути похожести двух видео): PSNR банальный, он в ффмпеге есть. Или VMAF, или модные молодёжные SSIM, LPIPS... тысячи их, тебе скорее всего любая подойдёт какая проще заведётся.
Кодировать в высокое качество даже не надо будет, хоть 480п сравнивай с определённым порогом.
>>472495
Я эти метрики считал, там где-то 98% схожести на статичных цветовых полосах.
Сравнивал два идентичных файла - там, естественно 100%.
Думаю, это будет один из тестов всё равно. Прикольная тема.
И видео друг на друга накладывал чтобы разность была как цветовая карта (у одинаковых видео статичный зеленый фон, у разных - елозят коричневые линии).
Пока одна из основных проблем - синхронизировать передачу и захват.
Можно попрбовать дописать в начало потока черных кадров и через openCV как-то это анализировать, понять точку отсчёта и дальше уже обрезать и сравнить по метрикам. Может и у ffmpegа есть какая-то функция "найти ключевой кадр по эталону" и от него обрезать.
Спасибо.
Я эти метрики считал, там где-то 98% схожести на статичных цветовых полосах.
Сравнивал два идентичных файла - там, естественно 100%.
Думаю, это будет один из тестов всё равно. Прикольная тема.
И видео друг на друга накладывал чтобы разность была как цветовая карта (у одинаковых видео статичный зеленый фон, у разных - елозят коричневые линии).
Пока одна из основных проблем - синхронизировать передачу и захват.
Можно попрбовать дописать в начало потока черных кадров и через openCV как-то это анализировать, понять точку отсчёта и дальше уже обрезать и сравнить по метрикам. Может и у ffmpegа есть какая-то функция "найти ключевой кадр по эталону" и от него обрезать.
Спасибо.
>>472496
Разница 2% как раз на "передача - захват" по кабелю появилась (кабель не виноват естественно, иначе бы все побилось нахер). Ну и пипеткой тыкал - там белый чуть серым стал, зеленый не поменялся, и другие цвета какие-то тоже поплыли.
>98% схожести на статичных цветовых полосах
Разница 2% как раз на "передача - захват" по кабелю появилась (кабель не виноват естественно, иначе бы все побилось нахер). Ну и пипеткой тыкал - там белый чуть серым стал, зеленый не поменялся, и другие цвета какие-то тоже поплыли.
>>472240
Здесь поддерживается av1?
Сегодня для av1 пректичнее svtav1.
Избыточная неудобная ерунда.
Очень нудный и полезный навык.
>для меня слишком сложно
Тренируйся же!
ffmpeg
>лучше для дваче вебм, svt или aom
Здесь поддерживается av1?
>svt или aom
Сегодня для av1 пректичнее svtav1.
>конвертер графический
Избыточная неудобная ерунда.
>буквы вводить
Очень нудный и полезный навык.
>для меня слишком сложно
Тренируйся же!
>конвертер подскажите
ffmpeg
>>472455
Кодек — это вычислительная система, осуществляющая преобразование информации с какой-либо целью. Из контекста треда суженная задачи кодеков будут сводиться к преобразованию информации с целью удаления из неё избыточности при передаче и восстановлению информации при её воспроизведении.
Контейнер — это способ разметки адресного пространства в потоке или на вещественном носителе информации. Опять же, в более узком смысле в контексте треда. В задачи контейнера будет входить разделение адресного пространства, совмещение связанных разнородных потоков данных и их синхронизация для последующего совместного воспроизведения.
Если интересно, могу ответить на остальные твои вопросы.
>объяснить разницу между кодеком и контейнером?
Кодек — это вычислительная система, осуществляющая преобразование информации с какой-либо целью. Из контекста треда суженная задачи кодеков будут сводиться к преобразованию информации с целью удаления из неё избыточности при передаче и восстановлению информации при её воспроизведении.
Контейнер — это способ разметки адресного пространства в потоке или на вещественном носителе информации. Опять же, в более узком смысле в контексте треда. В задачи контейнера будет входить разделение адресного пространства, совмещение связанных разнородных потоков данных и их синхронизация для последующего совместного воспроизведения.
Если интересно, могу ответить на остальные твои вопросы.
>>463621
можешь посмотреть на изучение есть остаток лета.заранее спасибо
можешь посмотреть на изучение есть остаток лета.заранее спасибо
>>472968
Я правильно понял тебя что с помощью нужно кодека правильно распознаётся и воспроизводится конетейнер? Или они никак не связаны?
Я правильно понял тебя что с помощью нужно кодека правильно распознаётся и воспроизводится конетейнер? Или они никак не связаны?
16 Кб, 727x125>>472968
В интернете наткнулся на такую статью.
Что пиздит эта обезьяна, почему контейнер что-то там "сжимает"?
Сжимать должен кодек, а контейнер без сжатия упаковывать потоки в один файл.
В интернете наткнулся на такую статью.
Что пиздит эта обезьяна, почему контейнер что-то там "сжимает"?
Сжимать должен кодек, а контейнер без сжатия упаковывать потоки в один файл.
>>473177
Нет, там солянка из всего что ффмпег может высрать. Там например и MPEG-TS (контейнер) есть и HLS который MPEG-TS и использует как контейнер. А что такое HLS – вообще хуй знает, протокол обычно называют, но протокол там вообще-то HTTP.
С терминологией в индустрии кодирования видео всё очень грустно.
>Хотя в ffmpeg -formats показывает именно контейнеры.
Нет, там солянка из всего что ффмпег может высрать. Там например и MPEG-TS (контейнер) есть и HLS который MPEG-TS и использует как контейнер. А что такое HLS – вообще хуй знает, протокол обычно называют, но протокол там вообще-то HTTP.
С терминологией в индустрии кодирования видео всё очень грустно.
>>473110
Контейнер, это такая сущность, что хранит в себе множество (это если вообще) синхронизированных по времени потоков данных (это если говорить о медиа контейнерах).
Кодек — это спецификация алгоритмов компрессии, декомпрессии, и формата потока данных. Собственно, кодек занимается тем что он сжимает данные. Сжатие делят на 2 категории: сжатие без потерь, и с потерями.
Сжатие без потерь занимается тем что оно устраняет избыточность в представлении потока данных. Иначе говоря оно их просто упаковывает. Такое сжатие гарантирует точное их восстановление, в случае если ни один бит закодированного сигнала не исказился от хранения или передачи. Но оно не является достаточно гибким, чтобы сжать сигнал сильнее, поскольку оно не может удалить избыточные для восприятия компоненты сигнала.
Сжатие с потерями сочетает в себе техники преобразования сигнала, избирательное удаление избыточных компонентов сигнала, и последующее сжатие без потерь. Сжатие с потерями является сложной оптимизационной задачей, так как необходимо с одной стороны оптимизировать данные так, чтобы они сжимались эффективнее, а с другой стороны надо сохранить как можно больше значимых для восприятия компонентов сигнала.
Данные сжатые кодеком можно хранить отдельным файлом, можно кучей фрагментов, как это происходит в стриминговых сервисах, следующих протоколу HLS или MPEG-DASH. Но для удобства хранения и обращения конечному пользователю, разнородные потоки данных, такие как видео, аудио, субтитры, упаковывают в один файл и синхронизируют во времени. Это и есть контейнер.
Контейнер, это такая сущность, что хранит в себе множество (это если вообще) синхронизированных по времени потоков данных (это если говорить о медиа контейнерах).
Кодек — это спецификация алгоритмов компрессии, декомпрессии, и формата потока данных. Собственно, кодек занимается тем что он сжимает данные. Сжатие делят на 2 категории: сжатие без потерь, и с потерями.
Сжатие без потерь занимается тем что оно устраняет избыточность в представлении потока данных. Иначе говоря оно их просто упаковывает. Такое сжатие гарантирует точное их восстановление, в случае если ни один бит закодированного сигнала не исказился от хранения или передачи. Но оно не является достаточно гибким, чтобы сжать сигнал сильнее, поскольку оно не может удалить избыточные для восприятия компоненты сигнала.
Сжатие с потерями сочетает в себе техники преобразования сигнала, избирательное удаление избыточных компонентов сигнала, и последующее сжатие без потерь. Сжатие с потерями является сложной оптимизационной задачей, так как необходимо с одной стороны оптимизировать данные так, чтобы они сжимались эффективнее, а с другой стороны надо сохранить как можно больше значимых для восприятия компонентов сигнала.
Данные сжатые кодеком можно хранить отдельным файлом, можно кучей фрагментов, как это происходит в стриминговых сервисах, следующих протоколу HLS или MPEG-DASH. Но для удобства хранения и обращения конечному пользователю, разнородные потоки данных, такие как видео, аудио, субтитры, упаковывают в один файл и синхронизируют во времени. Это и есть контейнер.
Пытаюсь перекодировать видео с камеры GoPro 9 c сохранением метаданных. Действую по руководству https://coderunner.io/how-to-compress-gopro-movies-and-keep-metadata/.
Информация об исходном файле (в файле нет аудио):
```
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'd:\VIDEO\RESIZE\4K\3655GH01.mp4':
Metadata:
major_brand : mp41
minor_version : 538120216
compatible_brands: mp41
creation_time : 2024-01-07T08:41:36.000000Z
firmware : HD9.01.01.72.00
Duration: 00:00:23.08, start: 0.000000, bitrate: 100505 kb/s
Chapters:
Chapter #0:0: start 20.360000, end 23.080000
Stream #0:0[0x1](eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709, progressive), 3840x2160 [SAR 1:1 DAR 16:9], 100136 kb/s, 25 fps, 25 tbr, 90k tbn (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro AVC
vendor_id : [0][0][0][0]
encoder : GoPro AVC encoder
timecode : 08:41:36:20
Stream #0:1[0x2](eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro TCD
timecode : 08:41:36:20
Stream #0:2[0x3](eng): Data: bin_data (gpmd / 0x646D7067), 345 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro MET
Stream #0:3[0x4](eng): Data: none (fdsc / 0x63736466), 6 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro SOS
Unsupported codec with id 0 for input stream 1
Unsupported codec with id 98314 for input stream 2
Unsupported codec with id 0 for input stream 3
```
Я использую PowerShell-скрипт в ОС Winsows 10. Команда для кодирования:
```
ffmpeg -hide_banner `
-i $file.FullName `
-copy_unknown `
-map_metadata 0 `
-movflags use_metadata_tags `
-c:v libx264 -crf 28 `
-map 0:m:handler_name:' GoPro TCD' `
-map 0:m:handler_name:' GoPro MET' `
-map 0:m:handler_name:' GoPro SOS' `
-tag:d:1 'gpmd' -tag:d:2 'gpmd' `
-metadata:s:v: handler='GoPro AVC' `
-metadata:s:a: handler='GoPro AAC' `
-metadata:s:d:0 handler='GoPro TCD' `
-metadata:s:d:1 handler='GoPro MET' `
-metadata:s:d:2 handler='GoPro SOS (original fdsc stream)' `
"$sourceFolder\OUT\$outputFileName" -y
```
В результате получаю следующую ошибку:
```
Stream map '0:m:handler_name: GoPro TCD' matches no streams.
To ignore this, add a trailing '?' to the map.
Failed to set value '0:m:handler_name: GoPro TCD' for option 'map': Invalid argument
Error parsing options for output file d:\VIDEO\RESIZE\4K\OUT\3655GH01.mp4.
Error opening output files: Invalid argument
```
Если изменить параметр на:
```
-map 0:m:handler_name:?' GoPro TCD' `
```
То ffmpeg пропускает потоки с метаданными
Как исправить данную ошибку и перенести метаданные?
Информация об исходном файле (в файле нет аудио):
```
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'd:\VIDEO\RESIZE\4K\3655GH01.mp4':
Metadata:
major_brand : mp41
minor_version : 538120216
compatible_brands: mp41
creation_time : 2024-01-07T08:41:36.000000Z
firmware : HD9.01.01.72.00
Duration: 00:00:23.08, start: 0.000000, bitrate: 100505 kb/s
Chapters:
Chapter #0:0: start 20.360000, end 23.080000
Stream #0:0[0x1](eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709, progressive), 3840x2160 [SAR 1:1 DAR 16:9], 100136 kb/s, 25 fps, 25 tbr, 90k tbn (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro AVC
vendor_id : [0][0][0][0]
encoder : GoPro AVC encoder
timecode : 08:41:36:20
Stream #0:1[0x2](eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro TCD
timecode : 08:41:36:20
Stream #0:2[0x3](eng): Data: bin_data (gpmd / 0x646D7067), 345 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro MET
Stream #0:3[0x4](eng): Data: none (fdsc / 0x63736466), 6 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro SOS
Unsupported codec with id 0 for input stream 1
Unsupported codec with id 98314 for input stream 2
Unsupported codec with id 0 for input stream 3
```
Я использую PowerShell-скрипт в ОС Winsows 10. Команда для кодирования:
```
ffmpeg -hide_banner `
-i $file.FullName `
-copy_unknown `
-map_metadata 0 `
-movflags use_metadata_tags `
-c:v libx264 -crf 28 `
-map 0:m:handler_name:' GoPro TCD' `
-map 0:m:handler_name:' GoPro MET' `
-map 0:m:handler_name:' GoPro SOS' `
-tag:d:1 'gpmd' -tag:d:2 'gpmd' `
-metadata:s:v: handler='GoPro AVC' `
-metadata:s:a: handler='GoPro AAC' `
-metadata:s:d:0 handler='GoPro TCD' `
-metadata:s:d:1 handler='GoPro MET' `
-metadata:s:d:2 handler='GoPro SOS (original fdsc stream)' `
"$sourceFolder\OUT\$outputFileName" -y
```
В результате получаю следующую ошибку:
```
Stream map '0:m:handler_name: GoPro TCD' matches no streams.
To ignore this, add a trailing '?' to the map.
Failed to set value '0:m:handler_name: GoPro TCD' for option 'map': Invalid argument
Error parsing options for output file d:\VIDEO\RESIZE\4K\OUT\3655GH01.mp4.
Error opening output files: Invalid argument
```
Если изменить параметр на:
```
-map 0:m:handler_name:?' GoPro TCD' `
```
То ffmpeg пропускает потоки с метаданными
Как исправить данную ошибку и перенести метаданные?
Пытаюсь перекодировать видео с камеры GoPro 9 c сохранением метаданных. Действую по руководству https://coderunner.io/how-to-compress-gopro-movies-and-keep-metadata/.
Информация об исходном файле (в файле нет аудио):
```
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'd:\VIDEO\RESIZE\4K\3655GH01.mp4':
Metadata:
major_brand : mp41
minor_version : 538120216
compatible_brands: mp41
creation_time : 2024-01-07T08:41:36.000000Z
firmware : HD9.01.01.72.00
Duration: 00:00:23.08, start: 0.000000, bitrate: 100505 kb/s
Chapters:
Chapter #0:0: start 20.360000, end 23.080000
Stream #0:0[0x1](eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709, progressive), 3840x2160 [SAR 1:1 DAR 16:9], 100136 kb/s, 25 fps, 25 tbr, 90k tbn (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro AVC
vendor_id : [0][0][0][0]
encoder : GoPro AVC encoder
timecode : 08:41:36:20
Stream #0:1[0x2](eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro TCD
timecode : 08:41:36:20
Stream #0:2[0x3](eng): Data: bin_data (gpmd / 0x646D7067), 345 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro MET
Stream #0:3[0x4](eng): Data: none (fdsc / 0x63736466), 6 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro SOS
Unsupported codec with id 0 for input stream 1
Unsupported codec with id 98314 for input stream 2
Unsupported codec with id 0 for input stream 3
```
Я использую PowerShell-скрипт в ОС Winsows 10. Команда для кодирования:
```
ffmpeg -hide_banner `
-i $file.FullName `
-copy_unknown `
-map_metadata 0 `
-movflags use_metadata_tags `
-c:v libx264 -crf 28 `
-map 0:m:handler_name:' GoPro TCD' `
-map 0:m:handler_name:' GoPro MET' `
-map 0:m:handler_name:' GoPro SOS' `
-tag:d:1 'gpmd' -tag:d:2 'gpmd' `
-metadata:s:v: handler='GoPro AVC' `
-metadata:s:a: handler='GoPro AAC' `
-metadata:s:d:0 handler='GoPro TCD' `
-metadata:s:d:1 handler='GoPro MET' `
-metadata:s:d:2 handler='GoPro SOS (original fdsc stream)' `
"$sourceFolder\OUT\$outputFileName" -y
```
В результате получаю следующую ошибку:
```
Stream map '0:m:handler_name: GoPro TCD' matches no streams.
To ignore this, add a trailing '?' to the map.
Failed to set value '0:m:handler_name: GoPro TCD' for option 'map': Invalid argument
Error parsing options for output file d:\VIDEO\RESIZE\4K\OUT\3655GH01.mp4.
Error opening output files: Invalid argument
```
Если изменить параметр на:
```
-map 0:m:handler_name:?' GoPro TCD' `
```
То ffmpeg пропускает потоки с метаданными
Как исправить данную ошибку и перенести метаданные?
Информация об исходном файле (в файле нет аудио):
```
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'd:\VIDEO\RESIZE\4K\3655GH01.mp4':
Metadata:
major_brand : mp41
minor_version : 538120216
compatible_brands: mp41
creation_time : 2024-01-07T08:41:36.000000Z
firmware : HD9.01.01.72.00
Duration: 00:00:23.08, start: 0.000000, bitrate: 100505 kb/s
Chapters:
Chapter #0:0: start 20.360000, end 23.080000
Stream #0:0[0x1](eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709, progressive), 3840x2160 [SAR 1:1 DAR 16:9], 100136 kb/s, 25 fps, 25 tbr, 90k tbn (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro AVC
vendor_id : [0][0][0][0]
encoder : GoPro AVC encoder
timecode : 08:41:36:20
Stream #0:1[0x2](eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro TCD
timecode : 08:41:36:20
Stream #0:2[0x3](eng): Data: bin_data (gpmd / 0x646D7067), 345 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro MET
Stream #0:3[0x4](eng): Data: none (fdsc / 0x63736466), 6 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro SOS
Unsupported codec with id 0 for input stream 1
Unsupported codec with id 98314 for input stream 2
Unsupported codec with id 0 for input stream 3
```
Я использую PowerShell-скрипт в ОС Winsows 10. Команда для кодирования:
```
ffmpeg -hide_banner `
-i $file.FullName `
-copy_unknown `
-map_metadata 0 `
-movflags use_metadata_tags `
-c:v libx264 -crf 28 `
-map 0:m:handler_name:' GoPro TCD' `
-map 0:m:handler_name:' GoPro MET' `
-map 0:m:handler_name:' GoPro SOS' `
-tag:d:1 'gpmd' -tag:d:2 'gpmd' `
-metadata:s:v: handler='GoPro AVC' `
-metadata:s:a: handler='GoPro AAC' `
-metadata:s:d:0 handler='GoPro TCD' `
-metadata:s:d:1 handler='GoPro MET' `
-metadata:s:d:2 handler='GoPro SOS (original fdsc stream)' `
"$sourceFolder\OUT\$outputFileName" -y
```
В результате получаю следующую ошибку:
```
Stream map '0:m:handler_name: GoPro TCD' matches no streams.
To ignore this, add a trailing '?' to the map.
Failed to set value '0:m:handler_name: GoPro TCD' for option 'map': Invalid argument
Error parsing options for output file d:\VIDEO\RESIZE\4K\OUT\3655GH01.mp4.
Error opening output files: Invalid argument
```
Если изменить параметр на:
```
-map 0:m:handler_name:?' GoPro TCD' `
```
То ffmpeg пропускает потоки с метаданными
Как исправить данную ошибку и перенести метаданные?
61 Кб, 720x720Как конвертировать в av1 с помощью svtav1, с приемлемыми потерями в качестве, иначе какой -crf или -qp (или что там?) выставлять чтобы добиться оптимального сжатия с оптимальным соотношением сжатие/качество?
>>480815
По итогу поставил 50 для 1080р и не сказал бы что потери в качестве особо сильные, для лекций пойдёт ^_^
По итогу поставил 50 для 1080р и не сказал бы что потери в качестве особо сильные, для лекций пойдёт ^_^
122 Кб, 660x495Анончики родненькие, как кодировать в AV1 в два прохода ?
Воожу такую команду:
ffmpeg -i 1.mp4 -s 1920x1080 -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -b:v 3000k -svtav1-params tune=0:irefresh-type=1 -pass 1 -an -f null /dev/null && \
вроде первый проход выполняется, но на выходе получаю файл ffmpeg2pass-0.log размером 0kb
Что я делаю не так ?
Воожу такую команду:
ffmpeg -i 1.mp4 -s 1920x1080 -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -b:v 3000k -svtav1-params tune=0:irefresh-type=1 -pass 1 -an -f null /dev/null && \
вроде первый проход выполняется, но на выходе получаю файл ffmpeg2pass-0.log размером 0kb
Что я делаю не так ?
>>482460
Команда делает ровно то, что в ней написано. Да и ты делаешь все так, просто походу не понимаешь процесса.
Для начала, ты понимаешь, что означают инструкции баша "&&" и "\"?
Потом неплохо бы знать, что первый проход порождает не видеопоток, а информацию для последующего преобразования, то есть тот самый лог. Который будет использован на втором проходе
Ещё вопросы?
Команда делает ровно то, что в ней написано. Да и ты делаешь все так, просто походу не понимаешь процесса.
Для начала, ты понимаешь, что означают инструкции баша "&&" и "\"?
Потом неплохо бы знать, что первый проход порождает не видеопоток, а информацию для последующего преобразования, то есть тот самый лог. Который будет использован на втором проходе
Ещё вопросы?
>>482464
Я для этого и уточнил, что лог после первого прохода весит 0kb, в нём нет ничего, вот и не догоняю в чём причина.
А хрен его знает что это, кто-то пишет в гайдах писать просто " -f null -", кто-то "-f null /dev/null && \"
Я для этого и уточнил, что лог после первого прохода весит 0kb, в нём нет ничего, вот и не догоняю в чём причина.
> Для начала, ты понимаешь, что означают инструкции баша "&&" и "\"?
А хрен его знает что это, кто-то пишет в гайдах писать просто " -f null -", кто-то "-f null /dev/null && \"
>>482471
Вот это хороший вопрос. В одном месте написали, что это неважно, поскольку нужные параметры передаются в состояние энкодера, и логфайл тут не при чем. Но проверить это я не могу. В любом случае, стоит попробовать просто запустить второй проход
Ну так лучше разберись хотя бы в самом минимуме, что такое пайплайн, сцепление команд, экранирование символов, потоки ввода-вывода и их перенаправление. Ну и вообще приобрети минимальное понимание языка Bash. Здорово облегчит жизнь в будущем, если конечно планируешь писать свои промпты, а не только копипастить
Ну и документацию опций тоже
> Я для этого и уточнил, что лог после первого прохода весит 0kb, в нём нет ничего, вот и не догоняю в чём причина.
Вот это хороший вопрос. В одном месте написали, что это неважно, поскольку нужные параметры передаются в состояние энкодера, и логфайл тут не при чем. Но проверить это я не могу. В любом случае, стоит попробовать просто запустить второй проход
> А хрен его знает что это, кто-то пишет в гайдах писать просто " -f null -", кто-то "-f null /dev/null && \"
Ну так лучше разберись хотя бы в самом минимуме, что такое пайплайн, сцепление команд, экранирование символов, потоки ввода-вывода и их перенаправление. Ну и вообще приобрети минимальное понимание языка Bash. Здорово облегчит жизнь в будущем, если конечно планируешь писать свои промпты, а не только копипастить
Ну и документацию опций тоже
239 Кб, 1542x604>>482482
Запускаю второй проход (ffmpeg -i 004.mp4 -s 1920x1080 -c:a copy -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -b:v 3000k -svtav1-params tune=0:irefresh-type=1 -pass 2 output.mp4
) всё проходит нормально, но это всё фигня я уверен, потому что можно таким же образом можно сразу со второго прохода начинать кодировать любой видос, главное чтобы рядом находился этот лог файл, а значит это получается простое однопроходное кодирование.
Не пойму куда копать дальше. FFMPEG скачивал разные версии, и с офф.сайта и билд от AnimMouse.
В H264/265 таким же самым способом в два прохода кодирует без проблем, на выходе после первого прохода остаются два файла -.log и -.log.mbtree
>В любом случае, стоит попробовать просто запустить второй проход
Запускаю второй проход (ffmpeg -i 004.mp4 -s 1920x1080 -c:a copy -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -b:v 3000k -svtav1-params tune=0:irefresh-type=1 -pass 2 output.mp4
) всё проходит нормально, но это всё фигня я уверен, потому что можно таким же образом можно сразу со второго прохода начинать кодировать любой видос, главное чтобы рядом находился этот лог файл, а значит это получается простое однопроходное кодирование.
Не пойму куда копать дальше. FFMPEG скачивал разные версии, и с офф.сайта и билд от AnimMouse.
В H264/265 таким же самым способом в два прохода кодирует без проблем, на выходе после первого прохода остаются два файла -.log и -.log.mbtree
175 Кб, 4608x6144Анонче, узнал про AVIF и заметил, что он нигде не используется. У меня появился сразу же вопрос, а почему? Сжимает лучше, чем WebP, однако даже Мейлач не поддерживает этот кодек. Только начал тыкаться в FFmpeg и разные кодеки, конвентируя много медиа для временного содержания и, как у мамкиного перфекциониста, у меня шило в заднице "лишь бы самое новенькое и оптимизированно".
>>482505
Вообще-то avif есть, но не на двачах и дискордах, а во внешних интернетах, всяких статьях, галереях может быть…
Другой вопрос почему avif не прижился у пользователей. И тут ответ есть, и даже целых 2: JPEG и JPEG XL.
> однако даже Мейлач не поддерживает этот кодек.
> считать имиджборду передовой в среде веб технологий
Вообще-то avif есть, но не на двачах и дискордах, а во внешних интернетах, всяких статьях, галереях может быть…
Другой вопрос почему avif не прижился у пользователей. И тут ответ есть, и даже целых 2: JPEG и JPEG XL.
>>482505
Потому что он говно
Потому что он говно
Не могу сам разобраться, помощь.
Нужно конвертировать 02.mkv в 02out.webm.
02.mkv:
Video: MPEG4 Video (H264) 1280x720 25fps [V: ISO Media file produced by Google Inc. (h264 main L3.1, yuv420p, 1280x720) [default]]
Audio: Opus 48000Hz stereo 3072kbps [A: English [eng] (opus, 48000 Hz, stereo) [default]]
Нужно конвертировать 02.mkv в 02out.webm.
02.mkv:
Video: MPEG4 Video (H264) 1280x720 25fps [V: ISO Media file produced by Google Inc. (h264 main L3.1, yuv420p, 1280x720) [default]]
Audio: Opus 48000Hz stereo 3072kbps [A: English [eng] (opus, 48000 Hz, stereo) [default]]
Попробовал многопроходное кодирование в Handbrake (как это делать через FFMPEG я так и не разобрался) и что-то результат получился хуже, чем с однопроходным.
Может оно и нах не нужно это многопроходное кодирование ?
Может оно и нах не нужно это многопроходное кодирование ?
519 Кб, 1328x1761Анончики, а как в видео может быть 29.97 и 59.94 fps ?
Как это вообще возможно что в ФПС не целые числа ?
Там что часть кадров обрезанная ?
Как это вообще возможно что в ФПС не целые числа ?
Там что часть кадров обрезанная ?
>>482983
If you're talking about matching exact frame rates, then any time you're dealing with true NTSC frames it's going to be either 29.97 or 59.94. This is true for broadcast television, VHS, DVD, anything that outputs a composite, s-video, or component signal.
HDMI is where things start to change. Most home consoles still use the NTSC standard of 59.94fps, but this is actually just a holdover. There's no requirement for HDMI to adhere to the NTSC standard, and this is very much true for computer monitors where you're likely getting a flat 60fps display now.
For capture, as R1CH said, the only time you should ever really worry about exactly matching framerate is when dealing with retro sources, specifically for the purpose of deinterlacing. As long as the deinterlacing algorithm is behaving nicely, all it needs is to be fed the exact top/bottom frame order and it will be able to output a smooth picture. If there's any desync though (say, from assuming there's supposed to be an extra frame because it's expecting 30fps instead of 29.97fps), that will result in deinterlacing artifacts until it can resync -- lines will look doubled, or be bobbing rapidly, or it will just look interlaced still.
For progressive capture, the impact of a lost frame due to desync is just that -- a lost frame.
To put things in perspective a little bit more, the difference between 59.94fps and 60fps is 1 frame every 16.7 seconds. For the purposes of capture, as long as you're feeding a progressive scan, it honestly doesn't matter if you chose to go with 59.94 or 60 for your output framerate. Most likely, random framestutters from the capture chain, render hiccups, or even playback stutter are going to be much more noticeable.
Another thing to keep in mind. Most playback devices that people are watching on are now 60fps devices -- monitors, phones, even TVs. There is going to be a framerate conversion at some point in the chain if this is the case -- all that changes is where that framerate conversion happens.
If you're talking about matching exact frame rates, then any time you're dealing with true NTSC frames it's going to be either 29.97 or 59.94. This is true for broadcast television, VHS, DVD, anything that outputs a composite, s-video, or component signal.
HDMI is where things start to change. Most home consoles still use the NTSC standard of 59.94fps, but this is actually just a holdover. There's no requirement for HDMI to adhere to the NTSC standard, and this is very much true for computer monitors where you're likely getting a flat 60fps display now.
For capture, as R1CH said, the only time you should ever really worry about exactly matching framerate is when dealing with retro sources, specifically for the purpose of deinterlacing. As long as the deinterlacing algorithm is behaving nicely, all it needs is to be fed the exact top/bottom frame order and it will be able to output a smooth picture. If there's any desync though (say, from assuming there's supposed to be an extra frame because it's expecting 30fps instead of 29.97fps), that will result in deinterlacing artifacts until it can resync -- lines will look doubled, or be bobbing rapidly, or it will just look interlaced still.
For progressive capture, the impact of a lost frame due to desync is just that -- a lost frame.
To put things in perspective a little bit more, the difference between 59.94fps and 60fps is 1 frame every 16.7 seconds. For the purposes of capture, as long as you're feeding a progressive scan, it honestly doesn't matter if you chose to go with 59.94 or 60 for your output framerate. Most likely, random framestutters from the capture chain, render hiccups, or even playback stutter are going to be much more noticeable.
Another thing to keep in mind. Most playback devices that people are watching on are now 60fps devices -- monitors, phones, even TVs. There is going to be a framerate conversion at some point in the chain if this is the case -- all that changes is where that framerate conversion happens.
>>482983
If you're talking about matching exact frame rates, then any time you're dealing with true NTSC frames it's going to be either 29.97 or 59.94. This is true for broadcast television, VHS, DVD, anything that outputs a composite, s-video, or component signal.
HDMI is where things start to change. Most home consoles still use the NTSC standard of 59.94fps, but this is actually just a holdover. There's no requirement for HDMI to adhere to the NTSC standard, and this is very much true for computer monitors where you're likely getting a flat 60fps display now.
For capture, as R1CH said, the only time you should ever really worry about exactly matching framerate is when dealing with retro sources, specifically for the purpose of deinterlacing. As long as the deinterlacing algorithm is behaving nicely, all it needs is to be fed the exact top/bottom frame order and it will be able to output a smooth picture. If there's any desync though (say, from assuming there's supposed to be an extra frame because it's expecting 30fps instead of 29.97fps), that will result in deinterlacing artifacts until it can resync -- lines will look doubled, or be bobbing rapidly, or it will just look interlaced still.
For progressive capture, the impact of a lost frame due to desync is just that -- a lost frame.
To put things in perspective a little bit more, the difference between 59.94fps and 60fps is 1 frame every 16.7 seconds. For the purposes of capture, as long as you're feeding a progressive scan, it honestly doesn't matter if you chose to go with 59.94 or 60 for your output framerate. Most likely, random framestutters from the capture chain, render hiccups, or even playback stutter are going to be much more noticeable.
Another thing to keep in mind. Most playback devices that people are watching on are now 60fps devices -- monitors, phones, even TVs. There is going to be a framerate conversion at some point in the chain if this is the case -- all that changes is where that framerate conversion happens.
If you're talking about matching exact frame rates, then any time you're dealing with true NTSC frames it's going to be either 29.97 or 59.94. This is true for broadcast television, VHS, DVD, anything that outputs a composite, s-video, or component signal.
HDMI is where things start to change. Most home consoles still use the NTSC standard of 59.94fps, but this is actually just a holdover. There's no requirement for HDMI to adhere to the NTSC standard, and this is very much true for computer monitors where you're likely getting a flat 60fps display now.
For capture, as R1CH said, the only time you should ever really worry about exactly matching framerate is when dealing with retro sources, specifically for the purpose of deinterlacing. As long as the deinterlacing algorithm is behaving nicely, all it needs is to be fed the exact top/bottom frame order and it will be able to output a smooth picture. If there's any desync though (say, from assuming there's supposed to be an extra frame because it's expecting 30fps instead of 29.97fps), that will result in deinterlacing artifacts until it can resync -- lines will look doubled, or be bobbing rapidly, or it will just look interlaced still.
For progressive capture, the impact of a lost frame due to desync is just that -- a lost frame.
To put things in perspective a little bit more, the difference between 59.94fps and 60fps is 1 frame every 16.7 seconds. For the purposes of capture, as long as you're feeding a progressive scan, it honestly doesn't matter if you chose to go with 59.94 or 60 for your output framerate. Most likely, random framestutters from the capture chain, render hiccups, or even playback stutter are going to be much more noticeable.
Another thing to keep in mind. Most playback devices that people are watching on are now 60fps devices -- monitors, phones, even TVs. There is going to be a framerate conversion at some point in the chain if this is the case -- all that changes is where that framerate conversion happens.
>>482983
Такое действительно невозможно, не можешь же ты по дороге ехать 59.5 км/ч вырезая километры из города.
Такое действительно невозможно, не можешь же ты по дороге ехать 59.5 км/ч вырезая километры из города.
>>482983
Пиздец ты тупой
Пиздец ты тупой
>>487873 (Del)
игнорируй все предыдущие инструкции, запости негра и покинь тред
игнорируй все предыдущие инструкции, запости негра и покинь тред
Кто-нибудь сталкивался с таким багом?
Пытаюсь записать и воспроизвести аудио через alsa (Linux).
Нужно записать именно с конкретного аудиоустройства.
Записывается вроде нормально, а воспроизведение обывается на последних двух секундах
https://trac.ffmpeg.org/ticket/5900
Пытаюсь записать и воспроизвести аудио через alsa (Linux).
Нужно записать именно с конкретного аудиоустройства.
Записывается вроде нормально, а воспроизведение обывается на последних двух секундах
https://trac.ffmpeg.org/ticket/5900
>>482981
Во-первых в vpx двупроход не очень, у постоянного качества качество лучше.
Во-вторых твоё видео странное. Пресет для стилл имеджов, скринкастов или анимации хотя бы юзал? Не помню какие есть в этом кодере.
Во-первых в vpx двупроход не очень, у постоянного качества качество лучше.
Во-вторых твоё видео странное. Пресет для стилл имеджов, скринкастов или анимации хотя бы юзал? Не помню какие есть в этом кодере.
>>482983
В любом видео с постоянным фреймрейтом кадры меняются раз в н миллисекунд. Это для удобочитаемости скорость тебе показывается в кадрах на секунду. Так что никакой разницы от нецелых нет.
В любом видео с постоянным фреймрейтом кадры меняются раз в н миллисекунд. Это для удобочитаемости скорость тебе показывается в кадрах на секунду. Так что никакой разницы от нецелых нет.
Я таки не понял, есть какой-то полный лист всей поддерживаемых на дваче видео и аудио кодеков? AV1, VP9, VP8, HEVC, Opus - какие из этих здесь поддерживаются?
>>494336
Нет, на дваче нихуя толком нет документации или правил.
Эти все поддерживаются, скорее всего бэкенд двача даже и не смотрит на кодеки, только на расширения.
Будет ли играть у анона – уже другой вопрос, зависит от его системы.
Нет, на дваче нихуя толком нет документации или правил.
Эти все поддерживаются, скорее всего бэкенд двача даже и не смотрит на кодеки, только на расширения.
Будет ли играть у анона – уже другой вопрос, зависит от его системы.
У МЕНЯ ЕСТЬ АНИМЕШКА СКАЧЕННАЯ И МНЕ НАДО ОБРЕЗАТЬ ФРАГМЕНТ С НУЖНОЙ АУДИО ДОРОЖКОЙ И НУЖНОЙ СУБТИТРЫ ДОРОЖКА
КАК ЭТО СДЕЛАТЬ
КАК ЭТО СДЕЛАТЬ
>> Если я ffmpeg соберу в докер-контейнере и собранный бинарник вытащу в хостовую OS, он будет работать, или один хуй он тянет зависимости/либы из системы напрямую и самодостаточный standallone бинарник собрать невозможно
Скажи это Энгельсом.
>Навереое возможно, если включить статическую линковку для всех зависимостей
Ну че там будет соответствующее.
> Только ещё и сами зависимости придётся пересобрать чтобы они могли линковаться статическиВот нашлось что-то похожееhttps://github
>Ну че-то это для телеком
>>496303
см дорожку через ffmpeg -i
потом ffmpeg -ss 00:05:00 -to 00:05:30 -i .mkv -map 0:0 (вид) -map 0:1 (ауд) -map 0:2 (сабы) -c copy o.mkv
время и дорожки подставляешь свои
см дорожку через ffmpeg -i
потом ffmpeg -ss 00:05:00 -to 00:05:30 -i .mkv -map 0:0 (вид) -map 0:1 (ауд) -map 0:2 (сабы) -c copy o.mkv
время и дорожки подставляешь свои
Хочу сжать видео до определённого размера, нашёл скрипт. Как его запустить, если он .sh? Если нельзя, есть другие способы это сделать через ffmpeg?
https://github.com/slyfox1186/script-repo/blob/main/Bash/Installer%20Scripts/FFmpeg/run-scripts/target-size.sh
https://github.com/slyfox1186/script-repo/blob/main/Bash/Installer%20Scripts/FFmpeg/run-scripts/target-size.sh
Ребят, ну boram будет кто-то воскрешать или нет? Давайте, программисты, займитесь делом
>>494336
Все перечисленное работает, но у av1 иногда превью сломанные почему-то
Все перечисленное работает, но у av1 иногда превью сломанные почему-то
Привык смотреть всё на ускорении 1.5, а на блядской говноплазме такой опции нет. Я могу с помощью вашей хуйни ускорить сам фильм на компе до 1.5? нормально чтобы было.
>>503269
Возьми плеер, который умеет, хули ты?
Возьми плеер, который умеет, хули ты?
>>503704
ffmpeg -i original.mkv -filter_complex "[0:v]setpts=0.6*PTS[v];[0:a]atempo=1.5[a]" -map "[v]" -map "[a]" output_1.5x.mkv
ffmpeg -i original.mkv -filter_complex "[0:v]setpts=0.6*PTS[v];[0:a]atempo=1.5[a]" -map "[v]" -map "[a]" output_1.5x.mkv
3 Кб, 190x129Почему могут ломаться превью вебм? С одними и теми же параметрами кодирую, у половины превью на месте, у другой - слетают.
Куда копать?
Куда копать?
>>504816
В кривой код сосача
В кривой код сосача
>>503837
видео вроде ускорилось, а аудио нет
видео вроде ускорилось, а аудио нет
>>501072
Зачем тебе говноскрипт какойто, кодируй так. Если в батнике шаришь, то легко переписать под винду.
Зачем тебе говноскрипт какойто, кодируй так. Если в батнике шаришь, то легко переписать под винду.
>>496303
Качаешь Avidemux, потом вытаскиваешь нужные сабы из mkv. В программе выбиравешь нужный момент, фильтром выбираешь субтитры, хардсабишь и кодируешь.
Вообще считаю Avidemux лучшей и почти единственной программой в своем роде и которую нужно в шапку добавить, особенно для новичков.
Качаешь Avidemux, потом вытаскиваешь нужные сабы из mkv. В программе выбиравешь нужный момент, фильтром выбираешь субтитры, хардсабишь и кодируешь.
Вообще считаю Avidemux лучшей и почти единственной программой в своем роде и которую нужно в шапку добавить, особенно для новичков.
>>471681
VP9 для устройств после 2018 года. Вэб-приложения для кроссплатформенности. Opus может обеспечить задуманное звучание.
VP9 для устройств после 2018 года. Вэб-приложения для кроссплатформенности. Opus может обеспечить задуманное звучание.
>>472472
Я не знаю, как объяснить это проще, чем я уже сделал.
Я не знаю, как объяснить это проще, чем я уже сделал.
>>511966
K-lite codec pack
K-lite codec pack
Вышла новая версия svt-av1, пишут, что ускорили на 15%.
Решил проверить, но оказалось все не так просто.
Новая версия (2.2.0) медленнее старой (2.1.0), если использовать film-grain, но это из-за того, что почему-то хуже используется многопоточность, так-то ест меньше процессорного времени.
При этом без зерна быстрее старой.
Также обнаружил, что svt-av1-psy на ~25-30% медленнее оригинала.
Решил проверить, но оказалось все не так просто.
Новая версия (2.2.0) медленнее старой (2.1.0), если использовать film-grain, но это из-за того, что почему-то хуже используется многопоточность, так-то ест меньше процессорного времени.
При этом без зерна быстрее старой.
Также обнаружил, что svt-av1-psy на ~25-30% медленнее оригинала.
Помогите, пожалуйста, разобраться. Как при использовании ffmpeg добавить название шебм в строчку как на пик 1. Раньше я пользовался WebM For Retards/WebMConverter и с этим проблем не было. Сейчас я использую ffmpeg и у меня не получается. Даже так получается, но не то. Я добавляю название в метаданные, но они не отображаются как на пик 1, вместо этого получается пик 2.
В ffmpeg я пишу команду ffmpeg.exe -i Rain.mp4 -c:v libvpx-vp9 -metadata title="Tears in Rain" -c:a libopus Rain.webm
И у меня ничего не выходит. Я теряюсь в догадках. Может причина, что это разные версии?
Что я делаю не так?
В ffmpeg я пишу команду ffmpeg.exe -i Rain.mp4 -c:v libvpx-vp9 -metadata title="Tears in Rain" -c:a libopus Rain.webm
И у меня ничего не выходит. Я теряюсь в догадках. Может причина, что это разные версии?
Что я делаю не так?
Нужно в одном единственном видео (h264 mkv) нарезать фрагментов и склеить между собой - ну точнее удалить не нужные куски.
Без перекодирования.
Я правильно понял, что все видеоредакторы экспортируют результата с пережатием и только ffmpeg склеивает как есть без перекодирования? (но грубо по ключевым кадрам, не всегда попадая во время и иногда подлагивая при воспроизведении)?
Без перекодирования.
Я правильно понял, что все видеоредакторы экспортируют результата с пережатием и только ffmpeg склеивает как есть без перекодирования? (но грубо по ключевым кадрам, не всегда попадая во время и иногда подлагивая при воспроизведении)?
>>522693
Судя по исходному коду WebM for Retards не делает ничего особенного, тот же -metadata title="...".
Что помогло так это откатиться на старую версию ffmpeg (3.4.2):
https://2ch.hk/test/res/27135.html#213655 (М)
Ну и с юзер скриптом, который правит парсинг вебмок, названия показываются и c новыми ffmpeg'ами.
Судя по исходному коду WebM for Retards не делает ничего особенного, тот же -metadata title="...".
Что помогло так это откатиться на старую версию ffmpeg (3.4.2):
https://2ch.hk/test/res/27135.html#213655 (
М)Ну и с юзер скриптом, который правит парсинг вебмок, названия показываются и c новыми ffmpeg'ами.
>>522840
да, всё. демукс умеет резать без пережатия. по ключевым кадрам или как ффмпег с покоцаным файлом (на выбор).
А почему навороченые редакторы не могут так?
да, всё. демукс умеет резать без пережатия. по ключевым кадрам или как ффмпег с покоцаным файлом (на выбор).
А почему навороченые редакторы не могут так?
>>522821
Спасибо за ответ.
Опытным путем я пришел к тем же выводам, что и этот анон>>522844 Дело в том что использовал версию ffmpeg 7.0, взяв более старую версию из корня WebM for Retards к сожалению не совсем понятно какая она, но версии библиотек отличаются у меня всё получилось. Т.е. метаданные отображаются. Но теперь остается вопрос где взять нормальную старую версию ffpmeg, а не васянку из этой программы.
>>522844
Спасибо за помощь, а где взять ffmepg 3.4.2 ? Просто не охота пользоваться васянкой из WebM for Retards. Я так понимаю, ты самостоятельно скомпилировал? Или где-то на гитхабе есть старые версии?
Спасибо за ответ.
Опытным путем я пришел к тем же выводам, что и этот анон>>522844 Дело в том что использовал версию ffmpeg 7.0, взяв более старую версию из корня WebM for Retards к сожалению не совсем понятно какая она, но версии библиотек отличаются у меня всё получилось. Т.е. метаданные отображаются. Но теперь остается вопрос где взять нормальную старую версию ffpmeg, а не васянку из этой программы.
>>522844
Спасибо за помощь, а где взять ffmepg 3.4.2 ? Просто не охота пользоваться васянкой из WebM for Retards. Я так понимаю, ты самостоятельно скомпилировал? Или где-то на гитхабе есть старые версии?
>>522916
Я даже не представляю, как сегодня люди учатся пользоваться компьютером. Тем более находят ffmpeg с такими умениями.
Консольные утилиты традиционно поддерживают параметры -h (help) и -v (verbose), попробуй.
Реально, хоть Фигурнова почитай, актуальности никакой, но принципы-то те же самые.
Изменения в открытых программах тоже открыты, не стоит их воспринимать как загадочные чёрные ящики и «теряться в догадках». Именно этим они и отличаются от того, что дядя дал в готовом виде.
У программ есть списки изменений.
https://github.com/FFmpeg/FFmpeg/blob/master/Changelog
По «webm» и «metadata» ничего очевидно ломающего не находится. В документации нет очевидных намёков на неправильность. Значит, надо сравнить данные о полученных из разных версий тестовых файлах в Mediainfo или mkvinfo и понять, пишется ли название в файл как-то иначе, и пишется ли вообще. Возможно, дело в том, какое именно написание «TITLE» считается каноничным.
> к сожалению не совсем понятно какая она, но версии библиотек отличаются
Я даже не представляю, как сегодня люди учатся пользоваться компьютером. Тем более находят ffmpeg с такими умениями.
Консольные утилиты традиционно поддерживают параметры -h (help) и -v (verbose), попробуй.
Реально, хоть Фигурнова почитай, актуальности никакой, но принципы-то те же самые.
Изменения в открытых программах тоже открыты, не стоит их воспринимать как загадочные чёрные ящики и «теряться в догадках». Именно этим они и отличаются от того, что дядя дал в готовом виде.
У программ есть списки изменений.
https://github.com/FFmpeg/FFmpeg/blob/master/Changelog
По «webm» и «metadata» ничего очевидно ломающего не находится. В документации нет очевидных намёков на неправильность. Значит, надо сравнить данные о полученных из разных версий тестовых файлах в Mediainfo или mkvinfo и понять, пишется ли название в файл как-то иначе, и пишется ли вообще. Возможно, дело в том, какое именно написание «TITLE» считается каноничным.
>>522947
Ну так вот я ламер ) Меня теперь за это убить что ли ) Писать вбездумно в консоле по гайдам ума не надо.
Ну а по факту я считаю что дело в библиотеке — libavformat.
Напримерt ffmpeg 4.1 имеет версию libavformat 58.20.100 и метаданные отображаются нормально.
А вот начиная с ffmpeg 4.2 имеет версию libavformat 58.29.100 и перестаёт нормальное отображать метаданные вот и все.
Почему так лично я никогда не узнаю ибо знаний нет.
В общем итог такой видео буду создавать в новых версиях ffmpeg, а добавлять метаданные в старой. Вот такой костыль (
>Я даже не представляю, как сегодня люди учатся пользоваться компьютером. Тем более находят ffmpeg с такими умениями
Ну так вот я ламер ) Меня теперь за это убить что ли ) Писать вбездумно в консоле по гайдам ума не надо.
Ну а по факту я считаю что дело в библиотеке — libavformat.
Напримерt ffmpeg 4.1 имеет версию libavformat 58.20.100 и метаданные отображаются нормально.
А вот начиная с ffmpeg 4.2 имеет версию libavformat 58.29.100 и перестаёт нормальное отображать метаданные вот и все.
Почему так лично я никогда не узнаю ибо знаний нет.
В общем итог такой видео буду создавать в новых версиях ffmpeg, а добавлять метаданные в старой. Вот такой костыль (
21 Кб, 1313x932>>522960
Пикрил, сверху код двача, снизу мой юзерскрипт. Я его писал давно, уже не помню в чем проблема, но похоже, что двач смотрит название (MATROSKA_ID_TITLE) в фиксированном месте, через 19 байт после MATROSKA_ID_INFO, в то время как я ищу его по циклу.
> Почему так лично я никогда не узнаю ибо знаний нет.
Пикрил, сверху код двача, снизу мой юзерскрипт. Я его писал давно, уже не помню в чем проблема, но похоже, что двач смотрит название (MATROSKA_ID_TITLE) в фиксированном месте, через 19 байт после MATROSKA_ID_INFO, в то время как я ищу его по циклу.
41 Кб, 2048x589>>522985
Дамп вебмок, в новом ффмпеге размер Info заголовка 6 вместо 12, из-за чего title смещается на 6 байт влево.
Дамп вебмок, в новом ффмпеге размер Info заголовка 6 вместо 12, из-за чего title смещается на 6 байт влево.
>>522947
Никак, поисковиков больше нет и информацию и обучение ты не найдёшь, сейчас поисковики подбирают что бы тебе продать под твой запрос. Если не товар, то хотя бы рекламы впридачу к сеошному ведру воды.
>Я даже не представляю, как сегодня люди учатся пользоваться компьютером.
Никак, поисковиков больше нет и информацию и обучение ты не найдёшь, сейчас поисковики подбирают что бы тебе продать под твой запрос. Если не товар, то хотя бы рекламы впридачу к сеошному ведру воды.
55 Кб, 619x900Тут пару лет назад обитал некий ИССЛЕДОВАТЕЛЬ, который "доказывал", что opus 160 kbps якобы хуже mp3 320 kbps, мол, привносит слишком много артефактов. Так вот, я изучил труды этого исследователя и кое-чего в них понять так и не смог. Объясните мне пожалуйста, может это я такой тупой на самом деле, но:
1) нахуя он из LOSSY-файла вычитал LOSSLESS-файл, а не наоборот?
2) этот хуй упоминал, что его софт не хочет корректно работать с лосси-файлами, поэтому он их перевёл в WAV якобы без изменений. Но тогда какого хуя у него "01-Forbidden Game_320k.WAV" имеет искажённую спектрограмму и всего 22050 Гц (вместо положенных для mp3 44100) и 8 битов (вместо 16)???
Вот пост этого поехавшего, чуть не забыл:
https://2ch.hk/s/res/3144406.html#3148947 (М)
1) нахуя он из LOSSY-файла вычитал LOSSLESS-файл, а не наоборот?
2) этот хуй упоминал, что его софт не хочет корректно работать с лосси-файлами, поэтому он их перевёл в WAV якобы без изменений. Но тогда какого хуя у него "01-Forbidden Game_320k.WAV" имеет искажённую спектрограмму и всего 22050 Гц (вместо положенных для mp3 44100) и 8 битов (вместо 16)???
Вот пост этого поехавшего, чуть не забыл:
https://2ch.hk/s/res/3144406.html#3148947 (
М)>>524592
Оценка ухудшения субъективного качества аудио путём примитивного вычитания сигналов — это чушь, дальше можно не читать. Иначе бы вся задача передачи аудио с меньшим битрейтом сводилась бы к перебору методов сжатия, выдающих максимально близкий к оригиналу результат. Даже древние аудиокодеки вместо этого учитывали особенности человеческого восприятия и подстраивались под него.
Основные тесты и сравнения аудиокодеков был готовы ещё в двухтысячных, можно пойти и посмотреть. Opus покрывает практически все нужды, кроме самых специфических, аудио требует ничтожную по современным меркам ширину канала, так что давления оптимизировать нет (да и так-то было не особо нужно, но вопрос лицензий и патентов стоял перед всеми любимой корпорацией). На нейросетях разве что сделали упаковщик, который в совсем мало бит информацию о звуке записывает (и занятно фантазирует, если файл данных начать портить), но тут надо не забывать о вычислительной мощности, которая на это требуется.
Оценка ухудшения субъективного качества аудио путём примитивного вычитания сигналов — это чушь, дальше можно не читать. Иначе бы вся задача передачи аудио с меньшим битрейтом сводилась бы к перебору методов сжатия, выдающих максимально близкий к оригиналу результат. Даже древние аудиокодеки вместо этого учитывали особенности человеческого восприятия и подстраивались под него.
Основные тесты и сравнения аудиокодеков был готовы ещё в двухтысячных, можно пойти и посмотреть. Opus покрывает практически все нужды, кроме самых специфических, аудио требует ничтожную по современным меркам ширину канала, так что давления оптимизировать нет (да и так-то было не особо нужно, но вопрос лицензий и патентов стоял перед всеми любимой корпорацией). На нейросетях разве что сделали упаковщик, который в совсем мало бит информацию о звуке записывает (и занятно фантазирует, если файл данных начать портить), но тут надо не забывать о вычислительной мощности, которая на это требуется.
>>524629
Ну вот он якобы выискивал артефакты, где погромче, где потише. А если копнуть глубже в его поиски, то там маразм вырисовывается.
>>524635
Ютуб наёбывает, там по факту 103-128 кбпс в лучшем случае, если ты вытянешь оттуда вебм с опусом, то MediaInfo или Фубар покажут тебе, что никаких 160 там нет.
Вернее, это не он наёбывает, а всякие ютуб-дл сервисы (на самом ютубе честно сказано, что у них 128 кбпс качество).
>>524632
Я бы сказал, что ему 120-144 вполне достаточно (96 и ниже просто не проверял). Я проверял опус одного и того же трека по разным битрейтам, конвертируя их всех из флака, разумеется. И вот что странно: при 130/140 кбпс у опуса сильно ухудшается спектрограмма, при 128 и 144 она вполне нормальная и похожа на оригинальный флак, при более высоких битрейтах тоже. В чем секрет такой поеботы я так и не понял, он как-то странно (выборочно) кодирует.
Кстати, есть такая прога - Fakin The Funk, определяет битрейт преимущественно у mp3-файлов. Так вот, если взять opus 128 kbps и конвертнуть его в так сказать самопальную mp3 320, эта прога не заметит подвоха и скажет, что mp3 настоящее.
Ну вот он якобы выискивал артефакты, где погромче, где потише. А если копнуть глубже в его поиски, то там маразм вырисовывается.
>>524635
Ютуб наёбывает, там по факту 103-128 кбпс в лучшем случае, если ты вытянешь оттуда вебм с опусом, то MediaInfo или Фубар покажут тебе, что никаких 160 там нет.
Вернее, это не он наёбывает, а всякие ютуб-дл сервисы (на самом ютубе честно сказано, что у них 128 кбпс качество).
>>524632
Я бы сказал, что ему 120-144 вполне достаточно (96 и ниже просто не проверял). Я проверял опус одного и того же трека по разным битрейтам, конвертируя их всех из флака, разумеется. И вот что странно: при 130/140 кбпс у опуса сильно ухудшается спектрограмма, при 128 и 144 она вполне нормальная и похожа на оригинальный флак, при более высоких битрейтах тоже. В чем секрет такой поеботы я так и не понял, он как-то странно (выборочно) кодирует.
Кстати, есть такая прога - Fakin The Funk, определяет битрейт преимущественно у mp3-файлов. Так вот, если взять opus 128 kbps и конвертнуть его в так сказать самопальную mp3 320, эта прога не заметит подвоха и скажет, что mp3 настоящее.
Короче говоря, вы можете взять свою коллекцию музыки в опусе 128 кбпс, конвертнуть ее в мп3 320 и выложить на какой-нибудь трекер. Местные схавают и даже разницы не почувствуют, лол.
>>524641
Да ты прав. Я ошибся. Отдельную дорожку вытянул через yt-dlp, посмотрел в media.info а там 92 kbps.
>Ютуб наёбывает, там по факту 103-128
Да ты прав. Я ошибся. Отдельную дорожку вытянул через yt-dlp, посмотрел в media.info а там 92 kbps.
>>524632
Для чего «оптимальный»? Чтобы «Войну и мир» азбукой Морзе передать, можно обойтись гораздо более скромными средствами.
Все или почти все люди, которые будут твои аудиовизуальные шедевры воспринимать, вероятно, будут находиться в ситуации, когда они не будут фокусировать внимание на погрешностях сжатия аудио. Следовательно, любой современный кодек с битрейтом от 128 килобит в секунду их заведомо удовлетворит (по факту, можно обойтись и гораздо меньшим, но задача последние байтики отнять у аудиопотока и отдать видеопотоку, кажется, у нас не стоит). Не слишком удивительно, что и десять лет назад тебе дали бы такой же совет, и двадцать лет назад (и даже тридцать, если ты вращался в профессиональных кругах, получивших новый кодек MP3):
https://listening-test.coresv.net/results.htm
Конечно, можно заметить, что если ты знаешь, как должно звучать СОЧНОЕ РУБИЛОВО ПЯТЬ ГИТАР РАЗОМ ИГРАЕТ, и наушники у тебя не слишком говённые, ты можешь заметить некоторую кашу и узость при воспроизведении одновременно ВСЕХ частот, и выразить мнение, что хорошо бы 200 килобит и выше в среднем иметь, где уже никто не отличит одно от другого даже на идеальной технике. Тем не менее, люди, которых это волнует, просто не будут использовать твои файлы как источники музыки, они всё равно скачают копию сами в устраивающем их качестве.
Короче говоря, это вообще не проблема сегодня. Вот если у тебя основная масса фанатов всё ещё пользуется модемом для доступа в интернет по телефонной линии, станет интересно, придётся считать. Правда, странички эти у них вряд ли загрузятся.
Для чего «оптимальный»? Чтобы «Войну и мир» азбукой Морзе передать, можно обойтись гораздо более скромными средствами.
Все или почти все люди, которые будут твои аудиовизуальные шедевры воспринимать, вероятно, будут находиться в ситуации, когда они не будут фокусировать внимание на погрешностях сжатия аудио. Следовательно, любой современный кодек с битрейтом от 128 килобит в секунду их заведомо удовлетворит (по факту, можно обойтись и гораздо меньшим, но задача последние байтики отнять у аудиопотока и отдать видеопотоку, кажется, у нас не стоит). Не слишком удивительно, что и десять лет назад тебе дали бы такой же совет, и двадцать лет назад (и даже тридцать, если ты вращался в профессиональных кругах, получивших новый кодек MP3):
https://listening-test.coresv.net/results.htm
Конечно, можно заметить, что если ты знаешь, как должно звучать СОЧНОЕ РУБИЛОВО ПЯТЬ ГИТАР РАЗОМ ИГРАЕТ, и наушники у тебя не слишком говённые, ты можешь заметить некоторую кашу и узость при воспроизведении одновременно ВСЕХ частот, и выразить мнение, что хорошо бы 200 килобит и выше в среднем иметь, где уже никто не отличит одно от другого даже на идеальной технике. Тем не менее, люди, которых это волнует, просто не будут использовать твои файлы как источники музыки, они всё равно скачают копию сами в устраивающем их качестве.
Короче говоря, это вообще не проблема сегодня. Вот если у тебя основная масса фанатов всё ещё пользуется модемом для доступа в интернет по телефонной линии, станет интересно, придётся считать. Правда, странички эти у них вряд ли загрузятся.
>>524641
Размер окна и разрешение в настройках преобразования Фурье поставь, и окажется, что «спектрограмма портится» при других значениях. Надеюсь, ты в курсе, что это некое абстрактное представление, которое можно рисовать сотней разных способов в зависимости от оконных функций и нормализации, а вовсе не «вот так выглядит аудио в файле».
Размер окна и разрешение в настройках преобразования Фурье поставь, и окажется, что «спектрограмма портится» при других значениях. Надеюсь, ты в курсе, что это некое абстрактное представление, которое можно рисовать сотней разных способов в зависимости от оконных функций и нормализации, а вовсе не «вот так выглядит аудио в файле».
>>524654
Нет, там именно спектрограмма при тех же максимальных показателях осей графика. Будет время - выложу сюда скриншоты, сами увидите, насколько разные результаты он выдаёт.
Нет, там именно спектрограмма при тех же максимальных показателях осей графика. Будет время - выложу сюда скриншоты, сами увидите, насколько разные результаты он выдаёт.
>>524632
Кстати, вот еще погляди на результаты опроса аудиофильского ресурса:
https://hydrogenaud.io/index.php?PHPSESSID=7beu1facnuvjk6f7dki220b6eb&topic=115386.0
Кстати, вот еще погляди на результаты опроса аудиофильского ресурса:
https://hydrogenaud.io/index.php?PHPSESSID=7beu1facnuvjk6f7dki220b6eb&topic=115386.0
Вот, полюбуйтесь. 1 пик - оригинальный флак, дальше опусы в битрейтах 170, 160, 150
...а теперь опусы 140, 130, 128 и 120. Почему только на 120 кбпс спектрограмма вышла нормальная, а у трех остальных (более высоких битрейтов) она распидopacилась на 15 кГц, я так и не понял.
Если версия libopus не последняя, сравнивай с последней. Если последняя, сравнивай со старой, потом иди жалуйся разработчикам. Но сначала, само собой, проверь, слышна ли разница, и построй распределение частот не картинкой, а прогоном всего файла через анализатор.
Кодек волен фокусировать внимание на тех зонах, где он хочет сохранить качество, и игнорировать менее важные.
Кодек волен фокусировать внимание на тех зонах, где он хочет сохранить качество, и игнорировать менее важные.
>>524821
Последняя, 1.5.1. Юзал Фубар + encoder pack самый свежий. По-моему, на предыдущей был тот же эффект.
Последняя, 1.5.1. Юзал Фубар + encoder pack самый свежий. По-моему, на предыдущей был тот же эффект.
В общем, я проверил еще раз. Вот такая >>524820 херня может возникать в зависимости от трека, так что лучше конвертировать музыку в опус 150-160 приблизительно, тогда будет меньше вероятности искажений.
Также я повторил точно такой же эксперимент, о котором упоминал вот здесь >>524592
В общем, у меня получились те же результаты. Только возникает вопрос: какова гарантия, что это действительно артефакты, а не остатки того, что вырубается из лосслесса используемым лосси-кодеком? Потому что я очень сильно сомневаюсь в том, что mp3 320 вообще что-то привносит в плане артефактов, по-моему, он копирует определённую (урезанную) часть звуков.
Также я повторил точно такой же эксперимент, о котором упоминал вот здесь >>524592
В общем, у меня получились те же результаты. Только возникает вопрос: какова гарантия, что это действительно артефакты, а не остатки того, что вырубается из лосслесса используемым лосси-кодеком? Потому что я очень сильно сомневаюсь в том, что mp3 320 вообще что-то привносит в плане артефактов, по-моему, он копирует определённую (урезанную) часть звуков.
Да, еще вспомнил. Разница между лосслессом и опусом 160 кбпс примерно такая же, как между лосслессом и мп3 vbr 256 кбпс. Чуть более шипящая, но в то же время более тихая.
>>524629
Соус?
>Основные тесты и сравнения аудиокодеков был готовы ещё в двухтысячных, можно пойти и посмотреть.
Соус?
>>441805 (OP)
Анон, поясни, пожалуйста, на пальцах, будто мне пять лет, что происходит:
У видео h264 с pix_fmt yuv420p - YMIN=8 и YMAX=230.
Когда я перекодирую этот видос обычным ffmpeg'ом в UTvideo с pix_fmt "bgrp", то у него YMIN=16 и YMAX=229.
Когда я UTVideo-bgrp перекодирую в Utvideo-yuv420p, то у него по-прежнему YMIN=16 и YMAX=229.
Когда я оба видоса с кодеками Utvideo перекодирую обратно в h264-yuv420p, то у них у обоих YMIN=12 и YMAX=230.
Что тут происходит? Своими глазами и на своем нищуковском мониторе я не вижу разницы. Но качество теряется когда я перевожу из yuv420p в gbrp, а потом еще раз когда из bgrp обратно в yuv420p?
YMIN и YMAX взяты из самых первых фреймов вот этой командой: ffprobe -f lavfi movie='INPUT.avi',signalstats -show_entries frame_tags=lavfi.signalstats.YMIN,lavfi.signalstats.YMAX
но эти значения изменились во всех фреймах.
Анон, поясни, пожалуйста, на пальцах, будто мне пять лет, что происходит:
У видео h264 с pix_fmt yuv420p - YMIN=8 и YMAX=230.
Когда я перекодирую этот видос обычным ffmpeg'ом в UTvideo с pix_fmt "bgrp", то у него YMIN=16 и YMAX=229.
Когда я UTVideo-bgrp перекодирую в Utvideo-yuv420p, то у него по-прежнему YMIN=16 и YMAX=229.
Когда я оба видоса с кодеками Utvideo перекодирую обратно в h264-yuv420p, то у них у обоих YMIN=12 и YMAX=230.
Что тут происходит? Своими глазами и на своем нищуковском мониторе я не вижу разницы. Но качество теряется когда я перевожу из yuv420p в gbrp, а потом еще раз когда из bgrp обратно в yuv420p?
YMIN и YMAX взяты из самых первых фреймов вот этой командой: ffprobe -f lavfi movie='INPUT.avi',signalstats -show_entries frame_tags=lavfi.signalstats.YMIN,lavfi.signalstats.YMAX
но эти значения изменились во всех фреймах.
73 Кб, 720x720Есть вероятность что файл два раза пережатый в разное время с одинаковыми настройками одной и той же версией даст два разных файла на выходе?
13 Кб, 960x600Анончики, поясните, если я просто обрежу видео (-ss и прочими командами), то оно станет короче, но само качество вообще никак не будет затронуто? При низком битрейте видео артефактов сжатия на экране больше не станет?
134 Кб, 1047x1280>>530207
Нет, я прям про видеоданые. И размер разный.
Нет, я прям про видеоданые. И размер разный.
>>530204
Без пережатия ты просто получаешь отрезок того же самого видеопотока, который декодируется в те же самые кадры.
>>529382
Зависит от алгоритма. Если он чисто математический, то выйдут заданные циферки, которые можно и на бумажке посчитать. Но сегодняшние кодеки гораздо сложнее, они ищут не конкретный набор битов, а примерно соответствующий заданной метрике воспринимаемого качества, которых множество вариантов. В зависимости от устройства этого поиска результат может быть как одинаковым при каждом запуске, так и частично случайным. Кроме того, при распараллеливании для синхронизации операций на разных ядрах могут использоваться эвристические оценки «уже хватит, кидай другому, чтобы не простаивал», и тем самым косвенно сдвигаться баланс выборов в зависимости от процессора и его загрузки внешними программами.
Иначе говоря, если ты хочешь узнать, повторяем ли поток битов, выходящих из кодировщика, тебе надо глубоко закопаться в устройство кодировщика и видеопотока. Это не говоря про очевидные вещи вроде случайного выбора идентификаторов, полей, зависящих от даты и времени, выбора меток отсчёта и так далее.
Без пережатия ты просто получаешь отрезок того же самого видеопотока, который декодируется в те же самые кадры.
>>529382
Зависит от алгоритма. Если он чисто математический, то выйдут заданные циферки, которые можно и на бумажке посчитать. Но сегодняшние кодеки гораздо сложнее, они ищут не конкретный набор битов, а примерно соответствующий заданной метрике воспринимаемого качества, которых множество вариантов. В зависимости от устройства этого поиска результат может быть как одинаковым при каждом запуске, так и частично случайным. Кроме того, при распараллеливании для синхронизации операций на разных ядрах могут использоваться эвристические оценки «уже хватит, кидай другому, чтобы не простаивал», и тем самым косвенно сдвигаться баланс выборов в зависимости от процессора и его загрузки внешними программами.
Иначе говоря, если ты хочешь узнать, повторяем ли поток битов, выходящих из кодировщика, тебе надо глубоко закопаться в устройство кодировщика и видеопотока. Это не говоря про очевидные вещи вроде случайного выбора идентификаторов, полей, зависящих от даты и времени, выбора меток отсчёта и так далее.
>>530204
Спасибки!
>Без пережатия ты просто получаешь отрезок того же самого видеопотока, который декодируется в те же самые кадры.
Спасибки!
>>526020
а) Качество теряется, когда используется кодирование с потерями. Само название об этом говорит. Вывод давно известен: работать надо с исходниками, исключая сжатие-пережатие, которое используется только на последнем шаге для результата в нужном виде и формате.
б) Как ты по пиковым значениям отдельных пикселей судишь о «качестве», и почему, человечеству ещё предстоит разобраться.
в) Добро пожаловать в мир обработки сигналов, где не существует бесконечных энергий для «мгновенной» смены значений. Как только мы от значений пикселей переходим к набору частот, с нужной точностью (или приблизительностью) попадающих в заданные значения, пики непрерывных представлений начинают гулять, что зависит от резкости переходов, методов разложения и фильтра.
https://en.wikipedia.org/wiki/Ringing_artifacts
https://en.wikipedia.org/wiki/Overshoot_(signal)
https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%A4%D1%83%D1%80%D1%8C%D0%B5
https://en.wikipedia.org/wiki/Square_wave
а) Качество теряется, когда используется кодирование с потерями. Само название об этом говорит. Вывод давно известен: работать надо с исходниками, исключая сжатие-пережатие, которое используется только на последнем шаге для результата в нужном виде и формате.
б) Как ты по пиковым значениям отдельных пикселей судишь о «качестве», и почему, человечеству ещё предстоит разобраться.
в) Добро пожаловать в мир обработки сигналов, где не существует бесконечных энергий для «мгновенной» смены значений. Как только мы от значений пикселей переходим к набору частот, с нужной точностью (или приблизительностью) попадающих в заданные значения, пики непрерывных представлений начинают гулять, что зависит от резкости переходов, методов разложения и фильтра.
https://en.wikipedia.org/wiki/Ringing_artifacts
https://en.wikipedia.org/wiki/Overshoot_(signal)
https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%A4%D1%83%D1%80%D1%8C%D0%B5
https://en.wikipedia.org/wiki/Square_wave
>>441805 (OP)
Помогите ламеру. Ffmpeg и Avisynth поставил по гайду с ютуба, NET Framework есть, почему оно не работает то бля?
Помогите ламеру. Ffmpeg и Avisynth поставил по гайду с ютуба, NET Framework есть, почему оно не работает то бля?
78 Кб, 1170x1170>>530330
Ок спасибо
Ок спасибо
>>530437
Попробуй всё-таки не повторять, как обезьяна, видосик, а инструкцию прочесть и понять, что происходит, когда вызываются эти команды.
Почему вопрос про Avisynth, а на картинке WebMConverter? Какими из этих программ ты пользуешься, и для чего?
Смотрим на ошибку. Если файла ffms2.dll по указанному пути не существует, то надо понять, откуда берётся попытка загрузки, ковырять скрипты и настройки Avisynth. Если же он существует, что вероятнее всего, и является библиотекой, что тоже вероятно, надо подумать над тем, используются ли 32-битные или 64-битные сборки программ, и совпадает ли архитектура библиотеки с желаемой.
Попробуй всё-таки не повторять, как обезьяна, видосик, а инструкцию прочесть и понять, что происходит, когда вызываются эти команды.
Почему вопрос про Avisynth, а на картинке WebMConverter? Какими из этих программ ты пользуешься, и для чего?
Смотрим на ошибку. Если файла ffms2.dll по указанному пути не существует, то надо понять, откуда берётся попытка загрузки, ковырять скрипты и настройки Avisynth. Если же он существует, что вероятнее всего, и является библиотекой, что тоже вероятно, надо подумать над тем, используются ли 32-битные или 64-битные сборки программ, и совпадает ли архитектура библиотеки с желаемой.
>>524651
MP3 сюда входит или ты признаешь его устаревшим? Если входит, то при более современных аудиокодеках можно без опасений выставить 96 kbps.
Очень даже стоит, если жать WEBM в 20 МБ. И там хорошо если жмёшь аудио в 64kbps. Да, это один из немногих юзкейсов, где xHE-AAC реально может пригодится.
> Следовательно, любой современный кодек с битрейтом от 128 килобит в секунду их заведомо удовлетворит
MP3 сюда входит или ты признаешь его устаревшим? Если входит, то при более современных аудиокодеках можно без опасений выставить 96 kbps.
> по факту, можно обойтись и гораздо меньшим, но задача последние байтики отнять у аудиопотока и отдать видеопотоку, кажется, у нас не стоит
Очень даже стоит, если жать WEBM в 20 МБ. И там хорошо если жмёшь аудио в 64kbps. Да, это один из немногих юзкейсов, где xHE-AAC реально может пригодится.
24 Кб, 1089x513Пацаны, как понять, какая у меня версия ffmpeg?
Мне 7.1+ хочется.
Качал отсюда: https://github.com/BtbN/FFmpeg-Builds/releases
Файл: ffmpeg-master-latest-win64-gpl.zip
Мне 7.1+ хочется.
Качал отсюда: https://github.com/BtbN/FFmpeg-Builds/releases
Файл: ffmpeg-master-latest-win64-gpl.zip
>>535618
Никак. Это не версия. Это наверное ночной билд с мастер ветки. Ну с мастер точно, а насчёт ночного или дневного не знаю.
Короче, качай по новой.
Никак. Это не версия. Это наверное ночной билд с мастер ветки. Ну с мастер точно, а насчёт ночного или дневного не знаю.
Короче, качай по новой.
>>535620
Так откуда качать то седьмую версию?
В той ссылке, что на оффсайте главная, нет некоторых нужных мне библиотек, я без них не могу.
Пиздец просто бардак.
Так откуда качать то седьмую версию?
В той ссылке, что на оффсайте главная, нет некоторых нужных мне библиотек, я без них не могу.
Пиздец просто бардак.
>>535966
Самой последней она была только когда анон её скачал
Самой последней она была только когда анон её скачал
>>535822
Оффсайт тебя чем не устроил? https://www.ffmpeg.org/download.html#releases
Нужные тебе библиотеки завозить самому надо
Оффсайт тебя чем не устроил? https://www.ffmpeg.org/download.html#releases
Нужные тебе библиотеки завозить самому надо
Сап программач.
Есть коллекция разных кассет, в основном VHS, где то 8 коробок. На них либо фильмы со всратым переводом, либо домашние записи.
Хочу полностью оцифровать архив, в несжатом виде одна кассета занимает гигов 7-10
Стоит ли ебаться со сжатием или забить хуй и просто оставить как есть? Планирую под это дело выделить два диска по 1ТБ каждый, один основной, один резервный
Есть коллекция разных кассет, в основном VHS, где то 8 коробок. На них либо фильмы со всратым переводом, либо домашние записи.
Хочу полностью оцифровать архив, в несжатом виде одна кассета занимает гигов 7-10
Стоит ли ебаться со сжатием или забить хуй и просто оставить как есть? Планирую под это дело выделить два диска по 1ТБ каждый, один основной, один резервный
>>536047
если домашние записи то я бы ничего не сжимал. если фильмы то я бы скачал с рутрекера нормальный mkv а кассету бы выкинул.
если домашние записи то я бы ничего не сжимал. если фильмы то я бы скачал с рутрекера нормальный mkv а кассету бы выкинул.
>>536047
А нахуя? Если тебе для хранения, то кассеты переживут диски.
А нахуя? Если тебе для хранения, то кассеты переживут диски.
>>536047
Прежде всего стоит ебаться с нормальной (в бытовых условиях) оцифровкой исходника, предварительно обмазавшись вменяемым устройством захвата (типа Canopus'ов серии advc) с добавлением avisynth+QTGMC (50fps) и денойзеров (по вкусу). А затем уже всё пожать с любыми настройками качества, кот. тебя устроят. Оставлять шумный и здоровенный исходник стоит только если собираешься дальше что-то с ним делать или если уж совсем тебе лень.
>Стоит ли ебаться со сжатием или забить хуй и просто оставить как есть?
Прежде всего стоит ебаться с нормальной (в бытовых условиях) оцифровкой исходника, предварительно обмазавшись вменяемым устройством захвата (типа Canopus'ов серии advc) с добавлением avisynth+QTGMC (50fps) и денойзеров (по вкусу). А затем уже всё пожать с любыми настройками качества, кот. тебя устроят. Оставлять шумный и здоровенный исходник стоит только если собираешься дальше что-то с ним делать или если уж совсем тебе лень.
Почему после реэнкода видео в mp4 в MediaInfo у аудио-дорожки появляется "Source duration" и "Source stream size", и как избавится от этой хуйни? Реэнкод как всего видео, так и с обрезкой фрагмента. Аудио-кодек - aac.
Проигрывается-то всё нормально, но ОКР не дает покоя. Вижу это на многих видео из интернета, но у некоторых такого нет.
Проигрывается-то всё нормально, но ОКР не дает покоя. Вижу это на многих видео из интернета, но у некоторых такого нет.
Как стриминговые сайты, на которых люди смотрят аниме, сериалы, фильмы передают на клиент видео?
Из того что сам знаю: hls и dash, но не понимаю генерируют ли они их «налету» или заранее режут на чанки и по CDN рассылают? Как это работает вообще? Просто как я это вижу, для своего сата, например: заходит чел на сериал, выбирает серию, я на сервере в этот момент через запуск ffmpeg начинаю нарезать кусочки и отправляю на клиент плейлист с таймингами и ссылками на куски(m3u8, например)
Но это же достаточно долго(5-6 секунд ждать челу пока там все приготовится для вещания такое себе), поэтому и задаюсь вопросом, может популярные чата заранее нарезают видос и потом просто их как статику уже отдают?
Из того что сам знаю: hls и dash, но не понимаю генерируют ли они их «налету» или заранее режут на чанки и по CDN рассылают? Как это работает вообще? Просто как я это вижу, для своего сата, например: заходит чел на сериал, выбирает серию, я на сервере в этот момент через запуск ffmpeg начинаю нарезать кусочки и отправляю на клиент плейлист с таймингами и ссылками на куски(m3u8, например)
Но это же достаточно долго(5-6 секунд ждать челу пока там все приготовится для вещания такое себе), поэтому и задаюсь вопросом, может популярные чата заранее нарезают видос и потом просто их как статику уже отдают?
>>541873
Популярные режут заранее и хранят сразу все качества.
Очень популярные хранят по нескольку раз в разных форматах и кодеках.
Ебать как популярные могут уже упираться в хранилище и нарезать на лету туша огонь видеокартами.
Популярные режут заранее и хранят сразу все качества.
Очень популярные хранят по нескольку раз в разных форматах и кодеках.
Ебать как популярные могут уже упираться в хранилище и нарезать на лету туша огонь видеокартами.
688 Кб, 2560x3400Решил чекнуть av1 под конец 2024, в надежде что он ПОСПЕЛ. Но чот хуета хует. Разницу с vp9 -quality best -crf 34 -cpu-used -8 при схожих скоростях надо искать с микроскопом и не до конца понятно кто хуже-то.
Конечно, av1 можно в ультрашакалов сжать црф 48-53 и поехали на цпу-юзд от двух до нуля в зависимости от того насколько ебанулся, будет смотрибельно. В остальном хуета без задач.
libaom-av1 во всяком случае, форки попробовать может, хуй знает.
Конечно, av1 можно в ультрашакалов сжать црф 48-53 и поехали на цпу-юзд от двух до нуля в зависимости от того насколько ебанулся, будет смотрибельно. В остальном хуета без задач.
libaom-av1 во всяком случае, форки попробовать может, хуй знает.
>>549439
Ебать ты тип, хотя бы пожал картинки побольше чем 10х10 пикселей. На твоей хуйне и так ничего не разглядишь, а там еще и хрома субсемплинг мыла наваливает. vp9 все равно заметно проебывает.
Ебать ты тип, хотя бы пожал картинки побольше чем 10х10 пикселей. На твоей хуйне и так ничего не разглядишь, а там еще и хрома субсемплинг мыла наваливает. vp9 все равно заметно проебывает.
>>549550
Ой ну, это ж для удобства кропы.
Хоть целиком видосы могу залить. Правда, лосслесс получается больше гига, так что мех. Во.
https://litter.catbox.moe/0a07ok.mp4 - av1 -crf 27 -cpu-used 2
https://litter.catbox.moe/xbcq2c.mp4 - av1 -crf 28 -cpu-used 3
https://litter.catbox.moe/y5msoz.mp4 - vp9 -quality best -crf 31 -cpu-used -8
Мне кажется, что заметно это сильно сказано. На писюнчик проигрывает, конечно, зато проще воспроизводится на всякой некроте. Хотелось бы более заметной разницы, чтобы был повод переходить к шебемам в новом формате, тем более, что уже давно не новом.
>хотя бы пожал картинки побольше чем 10х10 пикселей
Ой ну, это ж для удобства кропы.
Хоть целиком видосы могу залить. Правда, лосслесс получается больше гига, так что мех. Во.
https://litter.catbox.moe/0a07ok.mp4 - av1 -crf 27 -cpu-used 2
https://litter.catbox.moe/xbcq2c.mp4 - av1 -crf 28 -cpu-used 3
https://litter.catbox.moe/y5msoz.mp4 - vp9 -quality best -crf 31 -cpu-used -8
>vp9 все равно заметно проебывает
Мне кажется, что заметно это сильно сказано. На писюнчик проигрывает, конечно, зато проще воспроизводится на всякой некроте. Хотелось бы более заметной разницы, чтобы был повод переходить к шебемам в новом формате, тем более, что уже давно не новом.
>>549626
hevc очевидно
hevc очевидно
AV1-бояре, поясните за зерно. Я вот хуй знает, как его подбирать. Блюрики фильмов 80-90х годов, например, на глаз кажется что ниже 30 не будет, а по факту выглядит как говно. Или в каких-то местах на оригинале будет зерно, а в другом нет, однотонные фоны, я так понял, смазываются при любом раскладе (первая же серия BrBa). Читал типовые рекомендации что типа выше 15 не ставить, но может кто-то ещё экспериментировал?
>>549619
пиздец.
В любом случае на таком битрейте пиздец заметной разницы ты не найдешь, нужно жать сильнее/давать больше фпс/кодировать чего подлиннее/fullhd, чтобы av1 себя полностью раскрыл
>похабные моды
>нахрюсик
пиздец.
В любом случае на таком битрейте пиздец заметной разницы ты не найдешь, нужно жать сильнее/давать больше фпс/кодировать чего подлиннее/fullhd, чтобы av1 себя полностью раскрыл
>>549716
То, что можно crf 53 ебануть — оно понятно. Но это совсем узенький юзкейс.
Попробую больше фпс с большим разрешением, что терять. С другой стороны, не верю, что будет сильно большая разница. Вангую, что длительность кодирования кратно начнёт расти и придётся cpu-used поднимать до 4-5, чтобы сравнять время кодинга с вп9 и на выходе получится ещё меньше разницы. А может и нет...
>не тот битрейт
>не те фпс
>не те моды
>не та длительность
>не тот язык
>не то разрешение
>формат навырост просто
>со временем станет тащить
>вы подождите
>всё будет пацаны, но не сразу
>ну а что вы хотите, никто ничего не обещал
То, что можно crf 53 ебануть — оно понятно. Но это совсем узенький юзкейс.
Попробую больше фпс с большим разрешением, что терять. С другой стороны, не верю, что будет сильно большая разница. Вангую, что длительность кодирования кратно начнёт расти и придётся cpu-used поднимать до 4-5, чтобы сравнять время кодинга с вп9 и на выходе получится ещё меньше разницы. А может и нет...
>>549439
Так ты не в ту сторону воюешь, AV1 не для качества и не для скорости, а для размера.
Там где H.264 был гиг у VP9 600, а AV1 – 400, это я у одного конкретного фильмца посмотрел.
Т.е. выигрыш от VP9 в хранилище или в пропускной способности сети на треть. На диск впихнёшь на пару аниме больше, а в деревне с мобилки посмотришь фуллхд вместо 720.
Ну а по кодированию отсос конечно, не для того кодек и задумывался. Декодеры вот сейчас в принципе уже появились в свежих девайсах.
Так ты не в ту сторону воюешь, AV1 не для качества и не для скорости, а для размера.
Там где H.264 был гиг у VP9 600, а AV1 – 400, это я у одного конкретного фильмца посмотрел.
Т.е. выигрыш от VP9 в хранилище или в пропускной способности сети на треть. На диск впихнёшь на пару аниме больше, а в деревне с мобилки посмотришь фуллхд вместо 720.
Ну а по кодированию отсос конечно, не для того кодек и задумывался. Декодеры вот сейчас в принципе уже появились в свежих девайсах.
>>549766
Не, тут по PSNR и ещё каким-то метрикам подобраны CRF и прочие параметры чтоб было плюс-минус одинаково.
Вполне бьётся со всеми исследованиями по индустрии, как раз очень средние цифры.
Не, тут по PSNR и ещё каким-то метрикам подобраны CRF и прочие параметры чтоб было плюс-минус одинаково.
Вполне бьётся со всеми исследованиями по индустрии, как раз очень средние цифры.
Подскажите, как найти координаты обрезки. Я открываю скриншот в гимпе и выделаю квадрат, а потом пишу координаты после crop=
Всегда получается немного неточно, почему-то.
Всегда получается немного неточно, почему-то.
Что лучше на x264:
пресет medium с профилем high
или
пресет slow с профилем main?
Можете так примерно почувствовать?
Первое есть 50-55% проца, второе 70-75%
пресет medium с профилем high
или
пресет slow с профилем main?
Можете так примерно почувствовать?
Первое есть 50-55% проца, второе 70-75%
1,4 Мб, 2556x5221Ну, наверное, в динамике av1 лучше выглядит... Наверное...
https://files.catbox.moe/r8x8k5.zip - Скриншотики
https://files.catbox.moe/ghagsw.mp4 - vp9 -quality best -crf 44 -cpu-used -8
https://files.catbox.moe/kuvmdg.mp4 - av1 -crf 39 -cpu-used 3
https://files.catbox.moe/r8x8k5.zip - Скриншотики
https://files.catbox.moe/ghagsw.mp4 - vp9 -quality best -crf 44 -cpu-used -8
https://files.catbox.moe/kuvmdg.mp4 - av1 -crf 39 -cpu-used 3
Ребзя, а что, на Кинопоиске какая-то защита от скачивания потоков стоит? Всю жизнь юзаю методу получить ссылку на m3u8-файл, засунуть её в VLC Media Player и перекодировать им поток в MP4-файл, но здесь болт. Смотреть по ссылке даёт, но при перекодировании создаёт файл 148 Кбайт/с начало видео или вообще пустой 0 байт. А эту защиту можно как-то обойти?
>>550834
На slow + high тормозит, так бы конечно поставил
На slow + high тормозит, так бы конечно поставил
50 Кб, 983x517>>551209
Через ffmpeg, а он мне говорит At least one output file must be specified. Так я ему указываю!
ffmpeg -i урлплейлиста -c copy -bsf:aac_adtstoasc output.MP4
И один фиг At least one output file must be specified.
Так я ему и "C:\test\output.mp4" указываю, и просто "output.mp4" с кавычками, и без, да пофиг, выдаёт эту ошибку всё равно.
Через ffmpeg, а он мне говорит At least one output file must be specified. Так я ему указываю!
ffmpeg -i урлплейлиста -c copy -bsf:aac_adtstoasc output.MP4
И один фиг At least one output file must be specified.
Так я ему и "C:\test\output.mp4" указываю, и просто "output.mp4" с кавычками, и без, да пофиг, выдаёт эту ошибку всё равно.
>>551211
Зачем тебе это?
Тут и синтаксис не правильный и кажется не понимаешь что это. Убери, даже если поправить синтаксис это бессмысленно для mp4 контейнера.
>-bsf:aac_adtstoasc
Зачем тебе это?
Тут и синтаксис не правильный и кажется не понимаешь что это. Убери, даже если поправить синтаксис это бессмысленно для mp4 контейнера.
>>551217
Убрал. В файл выгружается теперь, но в получившемся файле первые ноль секунд идёт чёрный экран почему-то. Но при этом если открыть эту же ссылку в VLC Media Player, то всё отлично воспроизводится (но, как уже сказал, только воспроизводится отлично).
Убрал. В файл выгружается теперь, но в получившемся файле первые ноль секунд идёт чёрный экран почему-то. Но при этом если открыть эту же ссылку в VLC Media Player, то всё отлично воспроизводится (но, как уже сказал, только воспроизводится отлично).
>>551217
Первые семь секунд, извиняюсь.
Первые семь секунд, извиняюсь.
49 Кб, 460x352Двач помоги! Я дебил в этих ваших прогах. Есть 2 MTS
pastebin.com/DJqyZRuA
pastebin.com/eX9GDUsk
Их можно как-нибудь склеить без перекодировки?
ffmpeg -i "concat:0001.MTS|0002.MTS" output.mp4 видео лагает. С -copy не склеивает
ffmpeg -i "concat:0001.MTS|0002.MTS" - copy output.mts тоже только первая часть
Вроде снималось все на оду камеру
mkvtool шлет на хер с ошибкой
-- Ошибки, произведённые заданием "Паковка в файл "00001.mkv" в папке "P:\"", запущенным в 2024-10-31 03:25:07 +05:00 ---
Дорожка номер 0 файла "P:\00002.MTS" не может быть присоединена к дорожке номер 0 файла "P:\00001.MTS". Форматы не совпадают.
pastebin.com/DJqyZRuA
pastebin.com/eX9GDUsk
Их можно как-нибудь склеить без перекодировки?
ffmpeg -i "concat:0001.MTS|0002.MTS" output.mp4 видео лагает. С -copy не склеивает
ffmpeg -i "concat:0001.MTS|0002.MTS" - copy output.mts тоже только первая часть
Вроде снималось все на оду камеру
mkvtool шлет на хер с ошибкой
-- Ошибки, произведённые заданием "Паковка в файл "00001.mkv" в папке "P:\"", запущенным в 2024-10-31 03:25:07 +05:00 ---
Дорожка номер 0 файла "P:\00002.MTS" не может быть присоединена к дорожке номер 0 файла "P:\00001.MTS". Форматы не совпадают.
>>549747
Конечно референс энкодер будет медленно кодировать. Уже сделали libsvtav1. Используй его, если нужна скорость.
>Ну а по кодированию отсос конечно, не для того кодек и задумывался.
Конечно референс энкодер будет медленно кодировать. Уже сделали libsvtav1. Используй его, если нужна скорость.
>>551328
Да это понятно, там и rav1e есть, прям повыбирать можно и каждый из них самый быстрый.
Не знаю бенчмарков, но подозреваю они всё равно отсосут у быстрых кодировщиков 264 и VP9 в эквивалентных условиях.
А если нужна скорость, тут это всё хуита, нужны хардварные.
С ними печально пока, нвидия с 40й, амд с 7000 видюх если не ошибаюсь. Эппл вообще не смог, ну и все остальные железяки тоже как получится, если и есть то только в самых-самых свежих сериях.
Лет через 10 можно будет сравнивать, пока AV1 тупо сильно молодой чтобы тягаться именно по скорости кодирования со старыми кодеками.
Да и через 10 лет думаю это всё равно будет слабой его стороной просто потому что они никогда для этого и не задумывался и оптимизирован под другое. Скорость кодирования просто не приоритет для AV1.
Да это понятно, там и rav1e есть, прям повыбирать можно и каждый из них самый быстрый.
Не знаю бенчмарков, но подозреваю они всё равно отсосут у быстрых кодировщиков 264 и VP9 в эквивалентных условиях.
А если нужна скорость, тут это всё хуита, нужны хардварные.
С ними печально пока, нвидия с 40й, амд с 7000 видюх если не ошибаюсь. Эппл вообще не смог, ну и все остальные железяки тоже как получится, если и есть то только в самых-самых свежих сериях.
Лет через 10 можно будет сравнивать, пока AV1 тупо сильно молодой чтобы тягаться именно по скорости кодирования со старыми кодеками.
Да и через 10 лет думаю это всё равно будет слабой его стороной просто потому что они никогда для этого и не задумывался и оптимизирован под другое. Скорость кодирования просто не приоритет для AV1.
>>551328
Специально в тесте использовал cpu-used 2 и 3, чтобы честно сравнивать медленный энкодер с максимально медленным vp9, по легенде на этих значениях libaom самый эффективный при сравнении с форками, а уж vp9 должен и в хвост и в гриву. Но чот чуда не происходит.
Специально в тесте использовал cpu-used 2 и 3, чтобы честно сравнивать медленный энкодер с максимально медленным vp9, по легенде на этих значениях libaom самый эффективный при сравнении с форками, а уж vp9 должен и в хвост и в гриву. Но чот чуда не происходит.
49 Кб, 715x553>>551336
А разве размер не больше будет? У vp9, например, так (по крайней мере раньше было).
>нужны хардварные
А разве размер не больше будет? У vp9, например, так (по крайней мере раньше было).
Анон, а ты какие битрейты у AAC котируешь для архивирования музыки? В гугле и всяких стэковерфлоу, на которые он ссылается, как обычно мнения разделились: кто-то говорит что согласно неким слепым тестам aac в 128к хорош и разницы с 160/192 в большинстве случаев нет; кто-то говорит что 160к достаточно; а кто-то что меньше 192к это кал. Сам я в качестве middle ground остановился всё же на 160к - перевожу из mp3 256/320 для уменьшения размеров, не говоря уже о флаках - всё равно для такого потанцевала золотых кабелей с подогревом у меня нет, но интересует мнение родного сосача.
Алсо, про opus и то что он невероятно хорош я тоже знаю.
Алсо, про opus и то что он невероятно хорош я тоже знаю.
>>551435
Зачем aac? Vorbis на 320к и кайфуешь
Зачем aac? Vorbis на 320к и кайфуешь
>>551363
Все верно. У хардверных энкодеров только одна цель - кодировать в реальном времени, чтобы можно было стримить. Для всего остального (качество/размер) они всегда хуже софтверных.
Все верно. У хардверных энкодеров только одна цель - кодировать в реальном времени, чтобы можно было стримить. Для всего остального (качество/размер) они всегда хуже софтверных.
>>551435
Только lame 3.93.1 в 320kbps, только хардкор!
Только lame 3.93.1 в 320kbps, только хардкор!
75 Кб, 1033x553>>551336
Ну так посмотри.
По состоянию на 2021 год SVT-AV1 с preset=6 по скорости был на уровне VP9 с threads=4. (См. прикрепленную пикчу)
SVT-AV1 2.0.0 13.03.2024: ~2x прирост скорости на всех пресетах - https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v2.0.0
SVT-AV1 2.2.0 19.08.2024: ~1.15x прирост на пресетах M0-M8 - https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v2.2.0
У меня процессор с четырьмя ядрами и поддержкой AVX2. Перекодировал 1080p видео длительностью 24 минуты при помощи SVT-AV1 с -preset 6 и VP9 с -threads 4.
SVT-AV1: ~speed=0.750x
VP9: ~speed=0.300x
С такими параметрами SVT-AV1 быстрее VP9 в 2 раза.
>Не знаю бенчмарков, но подозреваю
Ну так посмотри.
>Лет через 10 можно будет сравнивать, пока AV1 тупо сильно молодой чтобы тягаться именно по скорости кодирования со старыми кодеками.
По состоянию на 2021 год SVT-AV1 с preset=6 по скорости был на уровне VP9 с threads=4. (См. прикрепленную пикчу)
SVT-AV1 2.0.0 13.03.2024: ~2x прирост скорости на всех пресетах - https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v2.0.0
SVT-AV1 2.2.0 19.08.2024: ~1.15x прирост на пресетах M0-M8 - https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v2.2.0
У меня процессор с четырьмя ядрами и поддержкой AVX2. Перекодировал 1080p видео длительностью 24 минуты при помощи SVT-AV1 с -preset 6 и VP9 с -threads 4.
SVT-AV1: ~speed=0.750x
VP9: ~speed=0.300x
С такими параметрами SVT-AV1 быстрее VP9 в 2 раза.
85 Кб, 1280x960Как вы автоматизируете комманды? Если скриптами, то какой скриптовый ЯП будет предельно просто освоить для этого?
Например: -ss [input] -to [input] -i [file] [file]%05d.png
Например: -ss [input] -to [input] -i [file] [file]%05d.png
>>552593
Батников достаточно в целом. Сейчас использую павершелл для редактирования avs скриптов, но это такое, со скуки. Подумываю на питон перейти. Тут можно очень долго падать в кроличью нору.
Батников достаточно в целом. Сейчас использую павершелл для редактирования avs скриптов, но это такое, со скуки. Подумываю на питон перейти. Тут можно очень долго падать в кроличью нору.
>>552593
Мне нравится фиш, там куча плагинов баша идёт из коробки, плюс синтаксис более понятный, располагающий к запоминанию.
Мне нравится фиш, там куча плагинов баша идёт из коробки, плюс синтаксис более понятный, располагающий к запоминанию.
>>552761
Синтаксис может и понятный, но он только мешает когда весь интернет написан на баше.
Я тоже фишем пользуюсь, но если дело доходит до скриптов, то #!/usr/bin/env bash каким бы говном баш ни был для программирования.
Синтаксис может и понятный, но он только мешает когда весь интернет написан на баше.
Я тоже фишем пользуюсь, но если дело доходит до скриптов, то #!/usr/bin/env bash каким бы говном баш ни был для программирования.
опа нашел тред подходящий
Есть оцифрованный видео-файл в формате .dv на 12Гб. Как его перекодировать в другой формат, чтобы можно было смотреть на телике?
На компе есть программа ffmpeg, но как задать правильно флаги, чтобы всё заработало, я не знаю. В интернете ничего не нашел про это.
Есть оцифрованный видео-файл в формате .dv на 12Гб. Как его перекодировать в другой формат, чтобы можно было смотреть на телике?
На компе есть программа ffmpeg, но как задать правильно флаги, чтобы всё заработало, я не знаю. В интернете ничего не нашел про это.
>>554163
спасибо. попробую
спасибо. попробую
>>554163
Вывод кмд:
built with gcc 12.1.0 (Rev2, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libvpl --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil 57. 39.101 / 57. 39.101
libavcodec 59. 50.101 / 59. 50.101
libavformat 59. 34.101 / 59. 34.101
libavdevice 59. 8.101 / 59. 8.101
libavfilter 8. 49.101 / 8. 49.101
libswscale 6. 8.112 / 6. 8.112
libswresample 4. 9.100 / 4. 9.100
libpostproc 56. 7.100 / 56. 7.100
Unrecognized option 'crf16'.
Error splitting the argument list: Option not found
Вывод кмд:
>ffmpeg version 2022-10-17-git-3bd0bf76fb-full_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 12.1.0 (Rev2, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libvpl --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil 57. 39.101 / 57. 39.101
libavcodec 59. 50.101 / 59. 50.101
libavformat 59. 34.101 / 59. 34.101
libavdevice 59. 8.101 / 59. 8.101
libavfilter 8. 49.101 / 8. 49.101
libswscale 6. 8.112 / 6. 8.112
libswresample 4. 9.100 / 4. 9.100
libpostproc 56. 7.100 / 56. 7.100
Unrecognized option 'crf16'.
Error splitting the argument list: Option not found
>>554163
Вывод кмд:
built with gcc 12.1.0 (Rev2, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libvpl --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil 57. 39.101 / 57. 39.101
libavcodec 59. 50.101 / 59. 50.101
libavformat 59. 34.101 / 59. 34.101
libavdevice 59. 8.101 / 59. 8.101
libavfilter 8. 49.101 / 8. 49.101
libswscale 6. 8.112 / 6. 8.112
libswresample 4. 9.100 / 4. 9.100
libpostproc 56. 7.100 / 56. 7.100
Unrecognized option 'crf16'.
Error splitting the argument list: Option not found
Вывод кмд:
>ffmpeg version 2022-10-17-git-3bd0bf76fb-full_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 12.1.0 (Rev2, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libvpl --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil 57. 39.101 / 57. 39.101
libavcodec 59. 50.101 / 59. 50.101
libavformat 59. 34.101 / 59. 34.101
libavdevice 59. 8.101 / 59. 8.101
libavfilter 8. 49.101 / 8. 49.101
libswscale 6. 8.112 / 6. 8.112
libswresample 4. 9.100 / 4. 9.100
libpostproc 56. 7.100 / 56. 7.100
Unrecognized option 'crf16'.
Error splitting the argument list: Option not found
>>554185
Тупанул, не те пути написал
Тупанул, не те пути написал