400 Кб, 2000x2000FFmpeg и общий кодирования видео тред №14
В прошлый раз мы как всегда срались про кодеки, особенно про качество AV1, а после бамплимита анон разработал интересную программу.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
https://www.youtube.com/watch?v=chOgKT3aHBE
https://www.youtube.com/watch?v=9kaIXkImCAM
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Подробный разбор режимов кодирования основных кодеков читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда (частично устарело): https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s
Актуальный гайд по кодированию от анона из треда №5 (принимается критика, её было много в предыдущих тредах): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и просвещаем неофитов ffmpeg.
P.S. Для проверки отображения на дваче вашего нестандартного медиаконтента специально существует аж целая доска: https://2ch.su/test/ Просьба проводить тесты там, а не ИТТ.
Тред №0: https://2ch.su/s/arch/2020-08-05/res/2591244.html
Тред №1: https://2ch.su/s/arch/2021-02-25/res/2816778.html
Тред №2: https://2ch.su/s/arch/2021-09-23/res/2979843.html
Тред №3: https://2ch.su/s/arch/2021-11-13/res/3029626.html
Тред №4: https://2ch.su/s/arch/2022-03-10/res/3056070.html
Тред №5: https://2ch.su/s/arch/2022-06-29/res/3101682.html
Тред №6: https://2ch.su/s/arch/2022-09-16/res/3144406.html
Тред №7: https://2ch.su/s/arch/2022-11-14/res/3181555.html
Тред №8: https://2ch.su/s/arch/2023-04-27/res/3205384.html
Тред №9: https://2ch.su/s/arch/2023-07-25/res/3239508.html
Тред №10: https://2ch.su/s/arch/2023-12-08/res/3301315.html
Тред №11: https://2ch.su/s/arch/2024-06-09/res/3365343.html
Тред №12: https://2ch.su/s/arch/2025-06-25/res/3441805.html
Тред №13: https://2ch.su/s/res/3600915.html
В прошлый раз мы как всегда срались про кодеки, особенно про качество AV1, а после бамплимита анон разработал интересную программу.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
https://www.youtube.com/watch?v=chOgKT3aHBE
https://www.youtube.com/watch?v=9kaIXkImCAM
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Подробный разбор режимов кодирования основных кодеков читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда (частично устарело): https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s
Актуальный гайд по кодированию от анона из треда №5 (принимается критика, её было много в предыдущих тредах): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и просвещаем неофитов ffmpeg.
P.S. Для проверки отображения на дваче вашего нестандартного медиаконтента специально существует аж целая доска: https://2ch.su/test/ Просьба проводить тесты там, а не ИТТ.
Тред №0: https://2ch.su/s/arch/2020-08-05/res/2591244.html
Тред №1: https://2ch.su/s/arch/2021-02-25/res/2816778.html
Тред №2: https://2ch.su/s/arch/2021-09-23/res/2979843.html
Тред №3: https://2ch.su/s/arch/2021-11-13/res/3029626.html
Тред №4: https://2ch.su/s/arch/2022-03-10/res/3056070.html
Тред №5: https://2ch.su/s/arch/2022-06-29/res/3101682.html
Тред №6: https://2ch.su/s/arch/2022-09-16/res/3144406.html
Тред №7: https://2ch.su/s/arch/2022-11-14/res/3181555.html
Тред №8: https://2ch.su/s/arch/2023-04-27/res/3205384.html
Тред №9: https://2ch.su/s/arch/2023-07-25/res/3239508.html
Тред №10: https://2ch.su/s/arch/2023-12-08/res/3301315.html
Тред №11: https://2ch.su/s/arch/2024-06-09/res/3365343.html
Тред №12: https://2ch.su/s/arch/2025-06-25/res/3441805.html
Тред №13: https://2ch.su/s/res/3600915.html
> Кодек AV2 продемонстрировал снижение битрейта на 30% при уровне качества AV1
https://www.opennet.ru/opennews/art.shtml?num=64033
>>652453
Что ты с ним будешь делать?
Что ты с ним будешь делать?
>>653050
Значит ли это, что битрейт надо поднимать до 30%, чтобы избежать "качества" AV1?
Значит ли это, что битрейт надо поднимать до 30%, чтобы избежать "качества" AV1?
>>653117
Вряд ли, ав1 ни на одном битрейте мыльной парашей не перестаёт быть, значит и саксесор должен эту же философию перенять.
Вряд ли, ав1 ни на одном битрейте мыльной парашей не перестаёт быть, значит и саксесор должен эту же философию перенять.
(Не знаю, где спросить, тут или в /pr. Сразу скажу, что регистраций во всяких нейрочатах нет, там спросить не могу, так что спрошу тут)
Есть дохуя пикч весом от 3 до 6 мб (почти 1 тб в общем весе). Нужно осовбодить место. Нужно разом все пикчи сжать до минимального "читабельного" разрешения, т.е. чтобы весило до 1 мб, но при этом не шакальные пиксели были. И главное чтобы оригинал пикчи сразу удалялся и оставалась сжатая копия. Как сделать? Удалять не вариант. По отдельности каждый файл вручную сжимать и удалять ориг, оставляя копию не вариант, это займет +100500 часов, а то и дней. Помогите пожалуйста шарящие.
Есть дохуя пикч весом от 3 до 6 мб (почти 1 тб в общем весе). Нужно осовбодить место. Нужно разом все пикчи сжать до минимального "читабельного" разрешения, т.е. чтобы весило до 1 мб, но при этом не шакальные пиксели были. И главное чтобы оригинал пикчи сразу удалялся и оставалась сжатая копия. Как сделать? Удалять не вариант. По отдельности каждый файл вручную сжимать и удалять ориг, оставляя копию не вариант, это займет +100500 часов, а то и дней. Помогите пожалуйста шарящие.
>>653320
Попробуй duck.ai
Скриптами, но у тебя довольно много неизвестных ("читабельное разрешение", "не шакальные пиксели", формат пикч, ОС...), представление о которых есть только у тебя.
>Сразу скажу, что регистраций во всяких нейрочатах нет, там спросить не могу
Попробуй duck.ai
>Как сделать?
Скриптами, но у тебя довольно много неизвестных ("читабельное разрешение", "не шакальные пиксели", формат пикч, ОС...), представление о которых есть только у тебя.
>>653320
jpegli от гугла почти как jpegxl, но в нормальном и поддерживаемым расширением везде. А не говно в .jxl
https://github.com/google/jpegli
jpegli от гугла почти как jpegxl, но в нормальном и поддерживаемым расширением везде. А не говно в .jxl
https://github.com/google/jpegli
>>653320
JPEG XL, AVIF, WebP.
https://github.com/libjxl/libjxl
https://github.com/AOMediaCodec/libavif
https://developers.google.com/speed/webp/docs/precompiled
Выбери формат который тебе больше нравится и подходит, пожми для теста десяток картинок чтобы определить для себя "читабельное" качество, после чего через PowerShell пройдись по нужной папке.
JPEG XL пока не так сильно распространён и поддерживается, но он крутой. Я использую WebP, с AVIF не сильно знаком, но в некоторых случаях он вроде бы сжимает лучше WebP.
Скрипт для примера.
https://pastebin.com/raw/Jw576Lxw
Он пройдётся по всем файлам из папки "C:\Users\User\Pictures\Hatsune Miku" и перекодирует их в WebP формат с качеством "-q 85" в папку "C:\Users\User\Pictures\Hatsune Miku_Processed", при успешном перекодировании файл удаляется, структура папок сохраняется, в конце цикла удаляет папку если она пуста.
JPEG XL, AVIF, WebP.
https://github.com/libjxl/libjxl
https://github.com/AOMediaCodec/libavif
https://developers.google.com/speed/webp/docs/precompiled
Выбери формат который тебе больше нравится и подходит, пожми для теста десяток картинок чтобы определить для себя "читабельное" качество, после чего через PowerShell пройдись по нужной папке.
JPEG XL пока не так сильно распространён и поддерживается, но он крутой. Я использую WebP, с AVIF не сильно знаком, но в некоторых случаях он вроде бы сжимает лучше WebP.
Скрипт для примера.
https://pastebin.com/raw/Jw576Lxw
Он пройдётся по всем файлам из папки "C:\Users\User\Pictures\Hatsune Miku" и перекодирует их в WebP формат с качеством "-q 85" в папку "C:\Users\User\Pictures\Hatsune Miku_Processed", при успешном перекодировании файл удаляется, структура папок сохраняется, в конце цикла удаляет папку если она пуста.
>>653320
Попроси чатГПТ написать тебе бантик, который жмёт всё в папке в жпегли на дистансе ~0.5 и удаляет оригинал. Проверь на тестовой папке.
Попроси чатГПТ написать тебе бантик, который жмёт всё в папке в жпегли на дистансе ~0.5 и удаляет оригинал. Проверь на тестовой папке.
>>653381
Вебп 420 кал. Авиф мыльная медленная параша. ЖпегХЛ умер нахуй, перспективы воскрешения минимальны. Из экзотики только хэйк остаётся норм вариант.
Вебп 420 кал. Авиф мыльная медленная параша. ЖпегХЛ умер нахуй, перспективы воскрешения минимальны. Из экзотики только хэйк остаётся норм вариант.
>>653385
Было бы за чем наблюдать...
Было бы за чем наблюдать...
>>653384
Он умер только в хроме. Софт его поддерживает, даже адобе. Еще недавно японцы запилили аппаратный кодировщик.
> ЖпегХЛ умер
Он умер только в хроме. Софт его поддерживает, даже адобе. Еще недавно японцы запилили аппаратный кодировщик.
>>653384
Серьезно? Только яблоко его продвигает (продвигало?), и они теперь "мертвый" жрегхл поддерживают из коробки на своих устройствах.
> хэйк остаётся норм вариант
Серьезно? Только яблоко его продвигает (продвигало?), и они теперь "мертвый" жрегхл поддерживают из коробки на своих устройствах.
>>653401
>>653407
Я вангую, что у хейка будет поддержка везде — на базе того что ведро с айосью его поддерживают — а с жпегXL пока влажненько выглядит, что в долгой перспективе он выживет. С хейком всё просто и понятно, тогда как XL привязан к обязательному колорменеджменту со своими наркоманскими профилями цветовых пространств. Но это гадание на кофейной гуще, конечно.
>>653407
Я вангую, что у хейка будет поддержка везде — на базе того что ведро с айосью его поддерживают — а с жпегXL пока влажненько выглядит, что в долгой перспективе он выживет. С хейком всё просто и понятно, тогда как XL привязан к обязательному колорменеджменту со своими наркоманскими профилями цветовых пространств. Но это гадание на кофейной гуще, конечно.
>>653320
Одна строчка в каком нибудь nconvert.
Одна строчка в каком нибудь nconvert.
>>653320
nconvert -recurse -D -out webp -ratio -rflag decr -resize fill 1920 1080 *
Вот, например, рекурсивно пройдет по каталогам, все картинки конвертнет в webp, и до кучи все крупные картинки впишет в фулл ашди, оригиналы удалит.
nconvert -recurse -D -out webp -ratio -rflag decr -resize fill 1920 1080 *
Вот, например, рекурсивно пройдет по каталогам, все картинки конвертнет в webp, и до кучи все крупные картинки впишет в фулл ашди, оригиналы удалит.
Есть кто шарит и тестил, насколько svt av1 3.1.2 лучше чем старый 2.3.0? Расскажите все плюсы, минусы, что по качеству и есть ли смысл обновляться.
>>654489
Мне сложно сказать насколько, но обновиться определенно стоит. Плюсы - оптимизация, новые настройки и улучшения с экспериментальной версии, фиксы каких-то багов. Минусов никаких.
Мне сложно сказать насколько, но обновиться определенно стоит. Плюсы - оптимизация, новые настройки и улучшения с экспериментальной версии, фиксы каких-то багов. Минусов никаких.
Увожаемые анончики, подскажите пожалуйста команду которой можно к видео картинку превью добавить или может как-то можно указать кадр который будет использоваться для превью.
>>655044
Насколько я знаю превьюха выбирается случайным образом из начала видео и задать ее нельзя.
Насколько я знаю превьюха выбирается случайным образом из начала видео и задать ее нельзя.
325 Кб, 451x676>>655090
Гугл направил меня в этот тред, сказал что он для таких вопросов создан.
Гугл направил меня в этот тред, сказал что он для таких вопросов создан.
>>655118
Пиздишь.
Пиздишь.
>>655095
Это не так. С торрентов я качал мультики с такими картинками. Можно попробовать:
ffmpeg -i video -i audio -i mjpeg -map 0:v -map 0:a -map 1:v
где первый источник видео, второй аудио, третий картинка в mjpeg.
Это не так. С торрентов я качал мультики с такими картинками. Можно попробовать:
ffmpeg -i video -i audio -i mjpeg -map 0:v -map 0:a -map 1:v
где первый источник видео, второй аудио, третий картинка в mjpeg.
331 Кб, mp4,694x480, 0:08
>>655404
А почему превью этой вебм отличается на двух браузерах? В Firefox одно превью, в Edge другое.
А почему превью этой вебм отличается на двух браузерах? В Firefox одно превью, в Edge другое.
>>655717
Без понятия.
Без понятия.
>>655717
После многочисленных жалоб на скримеры, кодеры макабы накодили так, что превьюшка генерируется из случайного кадра видоса. Видимо из-за различий в алгоритме рандомайзера, в разных браузерах генерируется разная превьюшка.
Но это чисто предположение.
После многочисленных жалоб на скримеры, кодеры макабы накодили так, что превьюшка генерируется из случайного кадра видоса. Видимо из-за различий в алгоритме рандомайзера, в разных браузерах генерируется разная превьюшка.
Но это чисто предположение.
>>655858
>>655717
Эти картинки на сервере макабы генерятся, поехавшие https://2ch.su/s/thumb/3652226/17608648848370s.jpg
>>655717
Эти картинки на сервере макабы генерятся, поехавшие https://2ch.su/s/thumb/3652226/17608648848370s.jpg
>>653368
На изображения жёсткие, если без регистрации.
На изображения жёсткие, если без регистрации.
Пиздец попробовал aotuv vorbis и opus просто идет нахуй на любом битрейте. Опус по ощущением с каждым годом более говно, потому что гуглу важна скорость наверное, чем качество сжатия. Как уже писал раньше на 28к битрейта все кодировал и не было искажений, а сейчас на 64к присутствуют.
>>655717
Я не то имел в виду. И запутал вас. У меня вопрос в другом, а именно в кадрах этой вебм-ки, почему перевязанный Сэм Лейк в Edge появляется на 7 секунде, а в Firefox уже на 3-ей?
Я не то имел в виду. И запутал вас. У меня вопрос в другом, а именно в кадрах этой вебм-ки, почему перевязанный Сэм Лейк в Edge появляется на 7 секунде, а в Firefox уже на 3-ей?
>>657166
Думаю кто-то криво слепил видео. Потому что у видео start_time с 4 секунды, а у аудио с 0.013991. Плееры вообще это видео сразу с 4 секунды запускают, обрезав часть аудио.
Думаю кто-то криво слепил видео. Потому что у видео start_time с 4 секунды, а у аудио с 0.013991. Плееры вообще это видео сразу с 4 секунды запускают, обрезав часть аудио.
>>657160
Вчитайся в сообщение еще раз, я не про обычный ворбис писал. И про опус не я один говорю, потому что гуглу похуй и даже в видео звук говно стал, потому что всегда через ytdlp качал 249, а щас он говно.
Вчитайся в сообщение еще раз, я не про обычный ворбис писал. И про опус не я один говорю, потому что гуглу похуй и даже в видео звук говно стал, потому что всегда через ytdlp качал 249, а щас он говно.
>>657448
Ну и давно "aotuv vorbis" какие-то приросты в качестве имел? В 2008? Акстись.
То что гугол хуй пойми как жмёт, никак не влияет на доступный тебе енкодер опуса, который никак не меняется. Главная фича опуса это нулевой лэйтенси, никто не будет удивлён если его в некоторых сценариях нагнёт ворбис или аац по качеству. И вообще, опус и ворбис ориентированы на битрейты в районе 96+кбпс, ниже они будут сраться, а ты просто уши почистил и услышал шакалов.
Для экстремально низких битрейтов exhale придумали, попробуй ещё попросишь.
Ну и давно "aotuv vorbis" какие-то приросты в качестве имел? В 2008? Акстись.
То что гугол хуй пойми как жмёт, никак не влияет на доступный тебе енкодер опуса, который никак не меняется. Главная фича опуса это нулевой лэйтенси, никто не будет удивлён если его в некоторых сценариях нагнёт ворбис или аац по качеству. И вообще, опус и ворбис ориентированы на битрейты в районе 96+кбпс, ниже они будут сраться, а ты просто уши почистил и услышал шакалов.
Для экстремально низких битрейтов exhale придумали, попробуй ещё попросишь.
>>657733
Выиграл все тесты в 2023.
Правки вносятся в репозиторий, а оттуда уже всем бомжам, то есть везде будет одинаково.
Херня вообще им не пользуюсь, и поддержка хромает в хромовиках.
>Ну и давно "aotuv vorbis" какие-то приросты в качестве имел? В 2008? Акстись
Выиграл все тесты в 2023.
>То что гугол хуй пойми как жмёт, никак не влияет на доступный тебе енкодер опуса
Правки вносятся в репозиторий, а оттуда уже всем бомжам, то есть везде будет одинаково.
>Для экстремально низких битрейтов exhale придумали
Херня вообще им не пользуюсь, и поддержка хромает в хромовиках.
>>658124
Блять, да ну нахуй, ты жив до сих пор? Я тебя уже столько раз вижу, снова зашел спустя пару лет, опять здесь!
>бuджuджu
Блять, да ну нахуй, ты жив до сих пор? Я тебя уже столько раз вижу, снова зашел спустя пару лет, опять здесь!
>>658126
Это подражатель, настоящий чел, который так подписывался, повесился после деанона. Витя его звали...
Это подражатель, настоящий чел, который так подписывался, повесился после деанона. Витя его звали...
>>658126
А куда мне статься? Даже прирос в своём благополучии, приобретя в сентябре 2023 года пека за 180 тыщ., сейчас вот по классическим брендам угорел и собираю себе на костюм и пальто из ЦУМа, на гойботе повысили тоже после проведенной мной проверки предоставления учреждениями льгот СВОшникам, бuджuджu
> ты жив до сих пор
А куда мне статься? Даже прирос в своём благополучии, приобретя в сентябре 2023 года пека за 180 тыщ., сейчас вот по классическим брендам угорел и собираю себе на костюм и пальто из ЦУМа, на гойботе повысили тоже после проведенной мной проверки предоставления учреждениями льгот СВОшникам, бuджuджu
Блядь! Ненавижу анимЭ! То кодеки были какие-то ебанутые х264 10бит. Теперь нашёл субтитры которые 20 МЕГАБАЙТ! На один эпизод! Ебучий урод! У меня плеер вылетел от этой хуйни. Понарисовал какой-то хуйни! С таким рисованием проще было хардсаб сделать.
>>658946
То кодеки были какие-то ебанутые х264 10бит.
Все давно перекодируют в hevc и даже av1 всего за 150-200мб за серию, на няше достаточно поискать. Да и надо совсем древний проц иметь, чтобы x264 10бит не тянул.
Перекодируй в srt
То кодеки были какие-то ебанутые х264 10бит.
Все давно перекодируют в hevc и даже av1 всего за 150-200мб за серию, на няше достаточно поискать. Да и надо совсем древний проц иметь, чтобы x264 10бит не тянул.
>Теперь нашёл субтитры которые 20 МЕГАБАЙТ!
Перекодируй в srt
>>658946
Представляю как ты знатно охуеешь увидев субтитры на 600 метров (в несжатом виде)! Весь видеоряд этого видоса векторный и сделан из субтитров - https://nyaa.land/view/1276567
>Теперь нашёл субтитры которые 20 МЕГАБАЙТ!
Представляю как ты знатно охуеешь увидев субтитры на 600 метров (в несжатом виде)! Весь видеоряд этого видоса векторный и сделан из субтитров - https://nyaa.land/view/1276567
>>658946
Представляю как ты знатно охуеешь увидев субтитры на 600 метров (в несжатом виде)! Весь видеоряд этого видоса векторный и сделан из субтитров - nyaa.land/view/1276567
>Теперь нашёл субтитры которые 20 МЕГАБАЙТ!
Представляю как ты знатно охуеешь увидев субтитры на 600 метров (в несжатом виде)! Весь видеоряд этого видоса векторный и сделан из субтитров - nyaa.land/view/1276567
>>658946
Анимубляди должны страдать.
Анимубляди должны страдать.
>>664218
Никому ты не нужен, шиз.
Никому ты не нужен, шиз.
Ребят, я начал разрабатывать очередной gui для ffmpeg. Может быть готово где-то через пол года (я говнокодер). Поддержите меня. Я сейчас читаю книгу по разработке графических интерфейсов. Программа будет похожа на boram, так как он мне больше всего нравился, но он не обновляется
>>666966
Уже придумали за тебя в виде FFmpeg Batch AV Converter в котором есть буквально всё практически. Настолько, что этот гуи можно адаптировать под exe других прог, единственный косяк постоянный параметр -i
Уже придумали за тебя в виде FFmpeg Batch AV Converter в котором есть буквально всё практически. Настолько, что этот гуи можно адаптировать под exe других прог, единственный косяк постоянный параметр -i
>>666984
Не хочу вайн ставить для неё, там есть функция кроп в интерфейсе? На скринах не увидел. Мне эта фича в boram нравилась, но её блядь нигде нет, чтобы было так же удобно. Ну и минус конечно, что нет нормальной сборки под линукс
Что это значит вообще? Зачем это?
>FFmpeg Batch AV Converter
Не хочу вайн ставить для неё, там есть функция кроп в интерфейсе? На скринах не увидел. Мне эта фича в boram нравилась, но её блядь нигде нет, чтобы было так же удобно. Ну и минус конечно, что нет нормальной сборки под линукс
>Настолько, что этот гуи можно адаптировать под exe других прог
Что это значит вообще? Зачем это?
>>667025
Ну так и скажи тебе хочется заняться бессмысленным ненужным пердолингом, и больше некуда время тратить. На уровне челов, который в миллионный раз пилят фронтенд для yt-dlp. В avidemux тоже кроп есть через avisynth можно прям линии ставить как тебе надо, в xvid4psp тоже есть кроп.
Ну так и скажи тебе хочется заняться бессмысленным ненужным пердолингом, и больше некуда время тратить. На уровне челов, который в миллионный раз пилят фронтенд для yt-dlp. В avidemux тоже кроп есть через avisynth можно прям линии ставить как тебе надо, в xvid4psp тоже есть кроп.
>>666966
Не нужно.
Не нужно.
>>664068
Мало ли что можно. Не значит что это нужно.
Сейчас анимубляди вперди всех жмут в AV1, который в моём "старом" (5 лет) телефоне железно не поддерживается. Но вроде он хотя бы существует и развивается, а не как х264 10бит мертвонерождённый.
Мало ли что можно. Не значит что это нужно.
Сейчас анимубляди вперди всех жмут в AV1, который в моём "старом" (5 лет) телефоне железно не поддерживается. Но вроде он хотя бы существует и развивается, а не как х264 10бит мертвонерождённый.
>>667027
Ну оно как минимум мне нужно, потому что boram нормально без ебли с устаревшими зависимостями не запускается, а все остальные мне не нравятся. Для себя я попердолиться не против, а там уже мне не особо важно, понадобится она кому-нибудь или нет. Ну и плюс будет какой-то опыт и проект. У меня в вузе средний проект выглядит как тудушник или календарь дней рождения
Ну короче спасибо всем за поддержку аноны, как всегда мощно обосрали
Ну оно как минимум мне нужно, потому что boram нормально без ебли с устаревшими зависимостями не запускается, а все остальные мне не нравятся. Для себя я попердолиться не против, а там уже мне не особо важно, понадобится она кому-нибудь или нет. Ну и плюс будет какой-то опыт и проект. У меня в вузе средний проект выглядит как тудушник или календарь дней рождения
Ну короче спасибо всем за поддержку аноны, как всегда мощно обосрали
>>667170
Ты довел меня до слез
Ты довел меня до слез
>>666966
Борам конечно дело свое делал, но это ужасающая электронопараша, даже автор уже не хочет уже разбираться в своем говнокоде.
Борам конечно дело свое делал, но это ужасающая электронопараша, даже автор уже не хочет уже разбираться в своем говнокоде.
>>667386
Автор в принципе прекратил активность на гитхабе. Может быть, он умер.
Автор в принципе прекратил активность на гитхабе. Может быть, он умер.
Там это, ваш ffmpeg протёк.
https://habr.com/ru/news/965518/
Если коротко, гугл находит слишком много уязвимостей, мы не успеваем их исправлять, а гугл через 90 дней выкладывает их в открытый доступ. Дайте деняк или прекратите искать уязвимости в нашем открытом коде, ежедневно проверяемом тысячами квалифицированных экспертов, всем же известно, что в СПО не может быть так много уязвимостей.
https://habr.com/ru/news/965518/
Если коротко, гугл находит слишком много уязвимостей, мы не успеваем их исправлять, а гугл через 90 дней выкладывает их в открытый доступ. Дайте деняк или прекратите искать уязвимости в нашем открытом коде, ежедневно проверяемом тысячами квалифицированных экспертов, всем же известно, что в СПО не может быть так много уязвимостей.
>>668252
Какие нахрен уязвимости в оффлайновой программе? Или ффмпег сообщает гуглу о том как я шебм с неграми конвертирую часами?
Какие нахрен уязвимости в оффлайновой программе? Или ффмпег сообщает гуглу о том как я шебм с неграми конвертирую часами?
40 Кб, 828x959>>668252
>Там это, ваш ffmpeg протёк
>ИИ-система нашла баг в системе декодированием кодека LucasArts Smush, в частности первых 10–20 кадров Rebel Assault 2, игры 1995 года
>>668254
ffmpeg библиотеки например в хроме и фурифоксе используются, ты открываешь видео, а оно крашит твой таб или даже весь браузер, норм тебе такое?
Гугл наверняка ffmpeg еще и для перекодирования видео на ютубе использует.
ffmpeg библиотеки например в хроме и фурифоксе используются, ты открываешь видео, а оно крашит твой таб или даже весь браузер, норм тебе такое?
Гугл наверняка ffmpeg еще и для перекодирования видео на ютубе использует.
>>668258
Дальше что? Че то не нравится, пишите с нуля свое, делайте форк, не ебет, это опенсорс. Че-то можете предложить? Сделайте коммит.
Дальше что? Че то не нравится, пишите с нуля свое, делайте форк, не ебет, это опенсорс. Че-то можете предложить? Сделайте коммит.
Ну челы правильно написали. Куча пидорах компаний, у которых обороты больше триллионов и не вложили даже копеечку, и абузят опенсорс.
>>669321
У себя исправят и патчи зажмут.
У себя исправят и патчи зажмут.
Хоть кто-нибудь может объяснить мне феномен фиолетового выцветания видеозаписей с регистраторов.
>>669434
Вероятно это плёнка ик-фильтра начинает терять свои свойства и пропускать ик-излучение.
Вероятно это плёнка ик-фильтра начинает терять свои свойства и пропускать ик-излучение.
44 Кб, 2200x540Делаю вот так когда не могу найти подходящего мелкого релиза какого-нибудь сериала что бы закинуть в телефон и смотреть. Нормально или что-то ещё можно добавить? Главное быстро и мелко и достаточное качество.
>>669497
Почему не hevc c bframes? Хотя я свою библиотеку в av1_nvenc с cqvbr 34 кодирую с bf 7 и кучей подстроек, либо c svt-av1 он тоже достаточно быстрый.
Почему не hevc c bframes? Хотя я свою библиотеку в av1_nvenc с cqvbr 34 кодирую с bf 7 и кучей подстроек, либо c svt-av1 он тоже достаточно быстрый.
Шарящие аноны, можно ли одним только ffmpeg решить такую задачу?
Задача: поделить видео на части при существенной смене кадра. Есть видео, типа слайдшоу, с переменной длиной слайдов. Нужно порезать это видео по слайдам. Но картинка на каждом слайде статичная не полностью, примерно 80% экрана остаются неизменными. Общая длина видео - чуть больше десяти часов, количество слайдов - примерно тысяча. Руками это будет адски долго и мучительно делать.
Пока на ум приходит только вытащить фреймы, и найти таймкоды изменений сторонними решениями (можно и самому скрипт написать, несложно). Но это костыльно - сохранять больше двух миллионов фреймов как отдельные картинки. Для raw не хватит места, а жать каждый фрейм - сколько времени уйдёт на одно только это, и ведь потом их ещё перебирать.
Может есть более адекватное решение?
Задача: поделить видео на части при существенной смене кадра. Есть видео, типа слайдшоу, с переменной длиной слайдов. Нужно порезать это видео по слайдам. Но картинка на каждом слайде статичная не полностью, примерно 80% экрана остаются неизменными. Общая длина видео - чуть больше десяти часов, количество слайдов - примерно тысяча. Руками это будет адски долго и мучительно делать.
Пока на ум приходит только вытащить фреймы, и найти таймкоды изменений сторонними решениями (можно и самому скрипт написать, несложно). Но это костыльно - сохранять больше двух миллионов фреймов как отдельные картинки. Для raw не хватит места, а жать каждый фрейм - сколько времени уйдёт на одно только это, и ведь потом их ещё перебирать.
Может есть более адекватное решение?
>>669563
ffmpeg divide video when scene change
ffmpeg divide video when scene change
710 Кб, 1280x576>>652226 (OP)
Как с lossless AV1 совместить AAC аудиодорожку из M4A и PNG пикчу в MP4? Цвета проёбываются, пикча вся ядерно-зелёная. Конкретно прописывать rgb24 пробовал.
Stream #0:0: Video: png, rgb24(pc, gbr/bt709/iec61966-2-1), 1280x576 [SAR 3779:3779 DAR 20:9], 25 fps, 25 tbr, 25 tbn
Как с lossless AV1 совместить AAC аудиодорожку из M4A и PNG пикчу в MP4? Цвета проёбываются, пикча вся ядерно-зелёная. Конкретно прописывать rgb24 пробовал.
Stream #0:0: Video: png, rgb24(pc, gbr/bt709/iec61966-2-1), 1280x576 [SAR 3779:3779 DAR 20:9], 25 fps, 25 tbr, 25 tbn
>>669706
-c:v libaom-av1 -aom-params lossless=1
С libx265/4 просто крашит при проигрывании везде на телефоне, на ПК не пробовал.
-c:v libaom-av1 -aom-params lossless=1
С libx265/4 просто крашит при проигрывании везде на телефоне, на ПК не пробовал.
>>669706
ffmpeg.exe -i videvo.mkv -i audivo.mka -i piccha.png -map 0 -map 1 -map 2 -c copy govno.mkv
ffmpeg.exe -i videvo.mkv -i audivo.mka -i piccha.png -map 0 -map 1 -map 2 -c copy govno.mkv
>>669563
Либо как написали ffmpeg нарезка по scene changes, threshhold выставлять можно вручную. Для scene changes также есть скрипты на питоне. Либо если просто вес видео снизить или чтото подобное до deduplication frame сделать.
Либо как написали ffmpeg нарезка по scene changes, threshhold выставлять можно вручную. Для scene changes также есть скрипты на питоне. Либо если просто вес видео снизить или чтото подобное до deduplication frame сделать.
>>669706
Кодировать в 4:4:4 или 4:2:2
Кодировать в 4:4:4 или 4:2:2
С какими настройками сжать .mov в .mp4 примерно в два раза по размеру файла, а лучше в три, потери допустимы, но хотелось бы сохранить детали. Исходные параметры mov - 720p, битрейт 1700, размер файла 1.2гб, продолжительность около часа.
>>670178
Ты чего грубый-то такой, епта. Как будто я каждый день этой хуетой пользуюсь. Сейчас попробую, спасибо.
Ты чего грубый-то такой, епта. Как будто я каждый день этой хуетой пользуюсь. Сейчас попробую, спасибо.
>>670179
-c:a copy можешь попробовать добавить. Не факт что сработает, смотря какое аудио в mov.
-c:a copy можешь попробовать добавить. Не факт что сработает, смотря какое аудио в mov.
>>670184
В два раза с небольшим сжал, аудио-визуально норм. Для аудио сделал бегающий битрейт, получилось еще немножко дожать. Спасибо.
В два раза с небольшим сжал, аудио-визуально норм. Для аудио сделал бегающий битрейт, получилось еще немножко дожать. Спасибо.
40 Мб, webm,1920x1080, 7:38
>>670177
Пресет можешь выставить 2, будет немного качественнее, но ощутимо медленнее.
Keyint я ставлю х20 от частоты кадров, можно выставить х10 ради чуть более быстрой перемотки.
CRF надо подбирать, чем больше тем компактнее, но ниже качество. Я подбираю на быстром пресете 10, можно примерно почувствовать каким будет битрейт на тех же настройках на более медленном пресете.
>ffmpeg -i Input.mov -pix_fmt yuv420p10le -c:v libsvtav1 -preset 4 -crf 35 -svtav1-params tune=0:keyint=480:qp-scale-compress-strength=3:enable-qm=1:qm-min=0:qm-max=8 -c:a libopus -b:a 64k TMP.mp4
Пресет можешь выставить 2, будет немного качественнее, но ощутимо медленнее.
Keyint я ставлю х20 от частоты кадров, можно выставить х10 ради чуть более быстрой перемотки.
CRF надо подбирать, чем больше тем компактнее, но ниже качество. Я подбираю на быстром пресете 10, можно примерно почувствовать каким будет битрейт на тех же настройках на более медленном пресете.
>>670177
В svt-av1 10bit crf 32-36, preset 4-6.
В svt-av1 10bit crf 32-36, preset 4-6.
Сап.
Вот можно скачать видео yt-dlp, с результатом все в порядке, можно продолжить скачивание с момента прерывания, но: более медленное скачивание и постфиксинг удваивает использование диска.
Я нагуглил способ качать ффмпегом -
ffmpeg -protocol_whitelist file,http,https,tcp,tls,crypto -ss 00:00:00.00 -i "ссылка" -to 60:02:00.00 -c copy имя.mp4
Если скачивание оборвалось, то только заново начинать или делать отдельный файл с момента обрыва. Но такое редко бывает.
Но есть постоянный раздражающий момент: не скачиваются первые где-то 2 секунды или даже со 2 секунды скачан звук, а видео только с 5 появляется.
Можно что-то поправить, чтобы скачивание было с самого начала?
Вот можно скачать видео yt-dlp, с результатом все в порядке, можно продолжить скачивание с момента прерывания, но: более медленное скачивание и постфиксинг удваивает использование диска.
Я нагуглил способ качать ффмпегом -
ffmpeg -protocol_whitelist file,http,https,tcp,tls,crypto -ss 00:00:00.00 -i "ссылка" -to 60:02:00.00 -c copy имя.mp4
Если скачивание оборвалось, то только заново начинать или делать отдельный файл с момента обрыва. Но такое редко бывает.
Но есть постоянный раздражающий момент: не скачиваются первые где-то 2 секунды или даже со 2 секунды скачан звук, а видео только с 5 появляется.
Можно что-то поправить, чтобы скачивание было с самого начала?
>>671941
Хуй знает что ты качаешь, хуй знает что ты качаешь, хуй знает что ты качаешь. Ещё отрезаешь там чего-то.
Скачивание не медленное. С хуя ли оно медленное? Через один и тот же интернет качает. Можно сразу несколько частей параллельно качать.
Можно отключить постфикс в ют-длп. Надо только прочитать редме.
Я когда-то вообще качал партсы через загрузчик и потом слепливал их ффмпегом.
А можно что б ют-длп не удалял скачанные партсы, тогда потом он сможет подхватить старые партсы и качать новые, надо только промежуточное и готовое видео удалить (если оно появилось).
Хуй знает что ты качаешь, хуй знает что ты качаешь, хуй знает что ты качаешь. Ещё отрезаешь там чего-то.
Скачивание не медленное. С хуя ли оно медленное? Через один и тот же интернет качает. Можно сразу несколько частей параллельно качать.
Можно отключить постфикс в ют-длп. Надо только прочитать редме.
Я когда-то вообще качал партсы через загрузчик и потом слепливал их ффмпегом.
А можно что б ют-длп не удалял скачанные партсы, тогда потом он сможет подхватить старые партсы и качать новые, надо только промежуточное и готовое видео удалить (если оно появилось).
>>652226 (OP)
Я один люблю аутировать пережимая всякую медиа хуйню?
Я один люблю аутировать пережимая всякую медиа хуйню?
>>670177
FFprobe на файл лучше кидай.
FFprobe на файл лучше кидай.
3,8 Мб, mp4,500x490, 4:01
>>671967
Ну вот такой батник попробуй:
ffmpeg -i Input.m4a -vn -c:a copy TMP.aac
ffmpeg -framerate 1/X -i Img.png -i TMP.aac -c:v libx264 -r 1 -c:a copy Out.mp4
del TMP.aac
Вместо X во второй строке длительность аудио в секундах.
Ну вот такой батник попробуй:
ffmpeg -i Input.m4a -vn -c:a copy TMP.aac
ffmpeg -framerate 1/X -i Img.png -i TMP.aac -c:v libx264 -r 1 -c:a copy Out.mp4
del TMP.aac
Вместо X во второй строке длительность аудио в секундах.
>>671945
Воды с кика и твича. Про отрезание я ничего не писал.
Не медленное, а медленнее чем ффмпегом. На винде разница вроде небольшая, я даже не приглядывался. А вот на лине скорость скачивания у ффмпег команды оказалась в 1.5 выше чем на винде и теперь разница с yt-dlp, где скорость осталась такой же, стала большой, где-то x2. Только я не
а просто "yt-dlp разрешение ссылка" делаю, там последовательное скачивание, может параллельно кусками будет супер быстро, но я не умею, а мне и так норм.
Сырой файл заметно больше постфиксного и у него нет метаданных или их части.
Ну я про это и писал, только скачивая последовательно будет один парт он же промежуточный, просто к нему дальше будет прилепляться.
> Хуй знает что ты качаешь, хуй знает что ты качаешь, хуй знает что ты качаешь. Ещё отрезаешь там чего-то.
Воды с кика и твича. Про отрезание я ничего не писал.
> Скачивание не медленное. С хуя ли оно медленное?
Не медленное, а медленнее чем ффмпегом. На винде разница вроде небольшая, я даже не приглядывался. А вот на лине скорость скачивания у ффмпег команды оказалась в 1.5 выше чем на винде и теперь разница с yt-dlp, где скорость осталась такой же, стала большой, где-то x2. Только я не
> Можно сразу несколько частей параллельно качать
а просто "yt-dlp разрешение ссылка" делаю, там последовательное скачивание, может параллельно кусками будет супер быстро, но я не умею, а мне и так норм.
> Можно отключить постфикс в ют-длп
Сырой файл заметно больше постфиксного и у него нет метаданных или их части.
> А можно что б ют-длп не удалял скачанные партсы, тогда потом он сможет подхватить старые партсы и качать новые, надо только промежуточное и готовое видео удалить (если оно появилось).
Ну я про это и писал, только скачивая последовательно будет один парт он же промежуточный, просто к нему дальше будет прилепляться.
>>672050
Это делается гораздо проще.
ffmpeg -loop 1 -framerate 1 -i img.png -i aud.mp4 -map 0:v:0 -map 1:a:0 -c:v libx264 -pix_fmt yuv420p -c:a copy -shortest outname.mp4
-map нужно если вместо непосредственно аудио-файла подсовывать видео-файл с аудио дорожкой с отбрасыванием самого видео, но в таком случае надо следить чтобы аудио в видосе было aac.
Это делается гораздо проще.
ffmpeg -loop 1 -framerate 1 -i img.png -i aud.mp4 -map 0:v:0 -map 1:a:0 -c:v libx264 -pix_fmt yuv420p -c:a copy -shortest outname.mp4
-map нужно если вместо непосредственно аудио-файла подсовывать видео-файл с аудио дорожкой с отбрасыванием самого видео, но в таком случае надо следить чтобы аудио в видосе было aac.
>>676354
Тому шо там хуета какя-то а не гайд. Надо сделать лучше, но всем лень.
Тому шо там хуета какя-то а не гайд. Надо сделать лучше, но всем лень.
5,3 Мб, webm,1280x720, 0:52
>>676354
Потому что ты древнее говно десяти лет откуда-то откапал.
Потому что ты древнее говно десяти лет откуда-то откапал.
>>676558
У меня AV1 на процессоре обрабатывает 5 минутное видео 100 лет через libaom-av1, а видеокарта не поддерживает его, только декодирование.
У меня AV1 на процессоре обрабатывает 5 минутное видео 100 лет через libaom-av1, а видеокарта не поддерживает его, только декодирование.
40 Мб, webm,1920x1080, 10:13
>>676559
libaom ее тоже потерял никогда и не был актуален из-за скорости кодирования с выходом оптимизированного SVT-AV1.
libaom ее тоже потерял никогда и не был актуален из-за скорости кодирования с выходом оптимизированного SVT-AV1.
>>676564
libsvtav1 в ffmeg, увидел, затестил, охуенный. Спасибо за информацию, быстро перекодировал и по размеру видео лучше намного.
>SVT-AV1
libsvtav1 в ffmeg, увидел, затестил, охуенный. Спасибо за информацию, быстро перекодировал и по размеру видео лучше намного.
Для libsvtav1 нужно что то специфическое скачивать или хватит полного билда с гитхаба? У меня он нормально не хочет ничего кодировать, на выходе получается каша с нечитаемыми словами, на вп9 лучше получается.
>>676754
Не нужно.
Ты бы показал что получается и написал как кодировал.
Не нужно.
>на выходе получается каша с нечитаемыми словами
Ты бы показал что получается и написал как кодировал.
>>676768
Уже поздно, дня через три, может четыре напишу.
Уже поздно, дня через три, может четыре напишу.
>>676564
Согласен на андрюше своем кодирую видео через termux прям огромное счастье, скорость даже на 778g на пресетах 2-4, которые использую на пк изумительная. Выходит около 8-12 фпс в сек.
Согласен на андрюше своем кодирую видео через termux прям огромное счастье, скорость даже на 778g на пресетах 2-4, которые использую на пк изумительная. Выходит около 8-12 фпс в сек.
>>677028
ffmpeg -i -c:v libsvtav1 -crf 32 -preset 4 -g 120 -pix_fmt yuv420p10le -vf scale=-1:720:sws_flags=lanczos -svtav1-params tune=0:film-grain=8 -c:a libopus -ab 80k -ar 48000
ffmpeg -i -c:v libsvtav1 -crf 32 -preset 4 -g 120 -pix_fmt yuv420p10le -vf scale=-1:720:sws_flags=lanczos -svtav1-params tune=0:film-grain=8 -c:a libopus -ab 80k -ar 48000
>>677029
Это лыжи не едут, или я долбаеб?
>libsvtav1 в ffmpeg, увидел, затестил, охуенный
>Перегруженное говно устаревшее.
>и что использовать?
>-c:v libsvtav1
Это лыжи не едут, или я долбаеб?
>>677040
Ты посты путаешь как будто. Перегружен гайд и написан всрато, плюс кодеки там древние. Про svtav1 ни слова, бтв есть даже лучше форки чем svt-av1, надо искать на дискорд каналах. SVT-AV1-HDR
Ты посты путаешь как будто. Перегружен гайд и написан всрато, плюс кодеки там древние. Про svtav1 ни слова, бтв есть даже лучше форки чем svt-av1, надо искать на дискорд каналах. SVT-AV1-HDR
>>677050
А, да, у меня почему то не тот пост отобразился, на который ты ответил.
А, да, у меня почему то не тот пост отобразился, на который ты ответил.
Сеолько ffmpeg должен весить? Вот есть у меня с гитхаба который весит 120мб, а есть на 86. Это почему так?
>>677150
Прочитай информацию в том репозитории, откуда скачиваешь.
В консоль при запуске выводится информация о конфигурации, запусти два разных и посмотри разницу.
Прочитай информацию в том репозитории, откуда скачиваешь.
В консоль при запуске выводится информация о конфигурации, запусти два разных и посмотри разницу.
>>677150
Нет какой-то твердой цифры, ты (или автор билда) при сборке задаешь набор библиотек которые войдут в билд. Я вот этот беру.
https://github.com/AnimMouse/ffmpeg-autobuild/releases
>должен весить
Нет какой-то твердой цифры, ты (или автор билда) при сборке задаешь набор библиотек которые войдут в билд. Я вот этот беру.
https://github.com/AnimMouse/ffmpeg-autobuild/releases
>>677171
Ну попробуй найди. В чем собственно проблема? Разве 110 Мб это так много?
Ну попробуй найди. В чем собственно проблема? Разве 110 Мб это так много?
>>677150
Есть версия с вшитыми либами в каждый экзешник, а есть версия где либы отдельно от экзешников.
Есть версия с вшитыми либами в каждый экзешник, а есть версия где либы отдельно от экзешников.
>>677150
Моя сборка весит 47М, 20М после upx.
Если вырезать всё, кроме аудио, то будет намного меньше.
Но проще взять lame, как выше посоветовали.
Моя сборка весит 47М, 20М после upx.
Если вырезать всё, кроме аудио, то будет намного меньше.
Но проще взять lame, как выше посоветовали.
>>677440
Можно попробовать что-нибудь вроде
lame --decode --mp3input -t - - | oggenc -r --ignorelength -o output.ogg -
Можно попробовать что-нибудь вроде
lame --decode --mp3input -t - - | oggenc -r --ignorelength -o output.ogg -
>>677456
Нашел на диске версию ffmpeg, которая весит всего 151 кб. В папке аирдроида была. Справляется с конвертом в вавку наотлично, а большего от нее и не надо.
Нашел на диске версию ffmpeg, которая весит всего 151 кб. В папке аирдроида была. Справляется с конвертом в вавку наотлично, а большего от нее и не надо.
-c:v libx264 -preset ultrafast -qp 0 -c:a pcm_s16le output.mp4
Вот это же быстро и без артефактов?
Я так через жопу собираю видео. Сначала нарезаю кусочки вот таким образом, потом склеиваю их все вместе и уже кодирую со сжатием.
Вот это же быстро и без артефактов?
Я так через жопу собираю видео. Сначала нарезаю кусочки вот таким образом, потом склеиваю их все вместе и уже кодирую со сжатием.
>>677553
Норм
Норм
>>677472
Скорее всего это версия без встроеных либ, а либы откуда то из path подхватываются. Так что это по сути тот же тяжеловесный комбайн.
Скорее всего это версия без встроеных либ, а либы откуда то из path подхватываются. Так что это по сути тот же тяжеловесный комбайн.
>>677553
pcm_s16le заменить на flac или alac похуй. Иначе мп4 глючит.
pcm_s16le заменить на flac или alac похуй. Иначе мп4 глючит.
Заморочился темой кодирования идеальной mp3. Делюсь наблюдениями.
Поскольку каждый человек слышит по своему, то вместо использования своей необъективной психоакустики, сделал программу, которая сравнивает два wav-файла и выдает среднюю разность уровней семплов (попугаи). Чем попугаев меньше, тем лучше.
Как оказалось, последний кодек lame режет верхние частоты, что никуда не годится. Нашел что кодек lame 3.93.1 может не резать верхние частоты по ключу -k.
Дальше начал эксперименты с основными параметрами кодирования и определил лучшие: -mj -b320 -q0 -k
В кодеке есть еще куча дополнительных параметров тонкой настройки, но я в них не ковырялся. Наверное возможно сделать лучше.
На скринах спектры оригинала и кодированных с параметрами -mj -b320 -q0 -k в lame 3.93.1 (136 попугаев) и в lame 3.100.1 (233 попугаев).
Трек выбрал потяжелее (Rammstein - Deutschland), чтобы было видно больше артефактов кодирования на спектрах. В менее тяжелых треках спектр у lame 3.93.1 может совсем мало отличаться от оригинала.
Поскольку каждый человек слышит по своему, то вместо использования своей необъективной психоакустики, сделал программу, которая сравнивает два wav-файла и выдает среднюю разность уровней семплов (попугаи). Чем попугаев меньше, тем лучше.
Как оказалось, последний кодек lame режет верхние частоты, что никуда не годится. Нашел что кодек lame 3.93.1 может не резать верхние частоты по ключу -k.
Дальше начал эксперименты с основными параметрами кодирования и определил лучшие: -mj -b320 -q0 -k
В кодеке есть еще куча дополнительных параметров тонкой настройки, но я в них не ковырялся. Наверное возможно сделать лучше.
На скринах спектры оригинала и кодированных с параметрами -mj -b320 -q0 -k в lame 3.93.1 (136 попугаев) и в lame 3.100.1 (233 попугаев).
Трек выбрал потяжелее (Rammstein - Deutschland), чтобы было видно больше артефактов кодирования на спектрах. В менее тяжелых треках спектр у lame 3.93.1 может совсем мало отличаться от оригинала.
>>677630
Разве это не common knowledge еще с середины нулевых?
Хз, обычно раньше на жоинт стерео плевались и строго в -m s кодировали.
>Как оказалось, последний кодек lame режет верхние частоты, что никуда не годится. Нашел что кодек lame 3.93.1 может не резать верхние частоты
Разве это не common knowledge еще с середины нулевых?
>и определил лучшие: -mj
Хз, обычно раньше на жоинт стерео плевались и строго в -m s кодировали.
>>677669
C -ms на cbr чуть больше попугаев показывает. Значит жоинт стерео высвобождает битрейт на более качественное кодирование.
>обычно раньше на жоинт стерео плевались и строго в -m s кодировали
C -ms на cbr чуть больше попугаев показывает. Значит жоинт стерео высвобождает битрейт на более качественное кодирование.
>>677669
Наверное. Жаль что сейчас все форматы режут верхние частоты, оправдывая это тем что они не слышны человеком. Но по моему все равно косвенное воздействие этих частот человек чувствует. Не надо их срезать.
>Разве это не common knowledge еще с середины нулевых?
Наверное. Жаль что сейчас все форматы режут верхние частоты, оправдывая это тем что они не слышны человеком. Но по моему все равно косвенное воздействие этих частот человек чувствует. Не надо их срезать.
19 Кб, 682x240>>677630
Люди не слышат частоты выше 20к - это идеальный максимум который к тому же не у каждого может быть, а чувствительность сильнее всего в детском возрасте и со временем она только падает. Кодировать частоты выше этого уровня бессмысленно в любом случае и это лишь расходует ресурсы на бесполезные и ненужные частоты которые режут все лосси кодеки даже с максимальным битрейтом.
Mp3, а конкретно lame, всё это время развивался и свежие версии на тех же самых битрейтах гораздо качественнее старых, тем более 2002 года, не говоря уже о том что сам по себе mp3 уже давно устарел - есть AAC и opus.
Люди не слышат частоты выше 20к - это идеальный максимум который к тому же не у каждого может быть, а чувствительность сильнее всего в детском возрасте и со временем она только падает. Кодировать частоты выше этого уровня бессмысленно в любом случае и это лишь расходует ресурсы на бесполезные и ненужные частоты которые режут все лосси кодеки даже с максимальным битрейтом.
Mp3, а конкретно lame, всё это время развивался и свежие версии на тех же самых битрейтах гораздо качественнее старых, тем более 2002 года, не говоря уже о том что сам по себе mp3 уже давно устарел - есть AAC и opus.
>>677687
В интернете куча abx тестов не чувствуют этого.
>Но по моему все равно косвенное воздействие этих частот человек чувствует
В интернете куча abx тестов не чувствуют этого.
14 Мб, mp4,1280x720, 1:00
>>677717
Эх, вот бы мне не слышать писк от электроники.
Видеокарта, мышка, монитор, даже посудомойка, всё пищит.
Эх, вот бы мне не слышать писк от электроники.
Видеокарта, мышка, монитор, даже посудомойка, всё пищит.
288 Кб, 1080x1800>>677764
Так они пищат на 5-10 кгц. Скачай на телефон какой-нибудь анализатор звука и посмотри. Очень удобная штука.
Ещё можешь скачать генератор и послушать до сколько килогерц ты слышишь.
Так они пищат на 5-10 кгц. Скачай на телефон какой-нибудь анализатор звука и посмотри. Очень удобная штука.
Ещё можешь скачать генератор и послушать до сколько килогерц ты слышишь.
>>677722
Если устройство воспроизводит высокие частоты, то они же физически есть, а значит влияют на кожу, на тело в целом. Пусть их напрямую не слышит слух, но они добавляют настоящести. К тому же есть биения близких частот, что придает окрас слышимому звуку, улучшает атаку.
Если устройство воспроизводит высокие частоты, то они же физически есть, а значит влияют на кожу, на тело в целом. Пусть их напрямую не слышит слух, но они добавляют настоящести. К тому же есть биения близких частот, что придает окрас слышимому звуку, улучшает атаку.
>>677773
Печально.
16.1K едва слышу.
https://www.szynalski.com/tone-generator/
> Так они пищат на 5-10 кгц.
Печально.
> Ещё можешь скачать генератор и послушать до сколько килогерц ты слышишь.
16.1K едва слышу.
https://www.szynalski.com/tone-generator/
>>677717
Форматом заявлено что он поддерживает такую то частоту дискретизации, а по факту там меньше. Получается наебалово. Можно же было оставить все частоты, но много битрейта на неслышимые частоты не расходовать, так чут чут. Или хотя бы дать возможность выбора при кодировании, фильтровать или нет.
>Кодировать частоты выше этого уровня бессмысленно в любом случае и это лишь расходует ресурсы на бесполезные и ненужные частоты которые режут все лосси кодеки даже с максимальным битрейтом.
Форматом заявлено что он поддерживает такую то частоту дискретизации, а по факту там меньше. Получается наебалово. Можно же было оставить все частоты, но много битрейта на неслышимые частоты не расходовать, так чут чут. Или хотя бы дать возможность выбора при кодировании, фильтровать или нет.
>>677717
Я сравнивал lame 3.93.1 и в lame 3.100.1 на треках без высоких частот - lame 3.93.1 показал меньше попугаев, а значит он более качественный.
>Mp3, а конкретно lame, всё это время развивался и свежие версии на тех же самых битрейтах гораздо качественнее старых, тем более 2002 года
Я сравнивал lame 3.93.1 и в lame 3.100.1 на треках без высоких частот - lame 3.93.1 показал меньше попугаев, а значит он более качественный.
>>677783
Единственное, что ты смог показать, это свое скудоумие.
Единственное, что ты смог показать, это свое скудоумие.
241 Кб, mp4,400x300, 0:26
короче походу двачерский плеер меньше чем 2 фпс плохо поддерживает.
то есть надо например создать видео из статичной картинки и аудио, надо всё равно прописывать -framerate 2
пример с которым создал видрил
ffmpeg -loop 1 -framerate 2 -i image.jpg -i audio.m4a -c:v libx264 -tune stillimage -pix_fmt yuv420p -vf "scale='iw-mod(iw,2)':'ih-mod(ih,2)'" -preset placebo -crf 30 -c:a copy -shortest -movflags +faststart output2.mp4
то есть надо например создать видео из статичной картинки и аудио, надо всё равно прописывать -framerate 2
пример с которым создал видрил
ffmpeg -loop 1 -framerate 2 -i image.jpg -i audio.m4a -c:v libx264 -tune stillimage -pix_fmt yuv420p -vf "scale='iw-mod(iw,2)':'ih-mod(ih,2)'" -preset placebo -crf 30 -c:a copy -shortest -movflags +faststart output2.mp4
>>678042
Все что я делал в 1 фпс из картинки нормально постилось и воспроизводилось. Не знаю о чем ты.
Все что я делал в 1 фпс из картинки нормально постилось и воспроизводилось. Не знаю о чем ты.
>>678046
includeadb - у меня нет этих файлов в папке. И эксешних 100кбайтовый работает отдельно без проблем, безо всяких длл конвертит из мп3 в вав.
includeadb - у меня нет этих файлов в папке. И эксешних 100кбайтовый работает отдельно без проблем, безо всяких длл конвертит из мп3 в вав.
>>678049
Ну ладно.
Ну ладно.
>>678047
Можешь команду скинуть, у меня почему то не всегда работает. Или попробуй в моей 2 на 1 заменить. Хз может дело в чем то другом
Можешь команду скинуть, у меня почему то не всегда работает. Или попробуй в моей 2 на 1 заменить. Хз может дело в чем то другом
>>678078
видимо дело в отсутствии -movflags +faststart
я ожидал что сразу воспроизведётся а надо ждать пока всё прогрузится
видимо дело в отсутствии -movflags +faststart
я ожидал что сразу воспроизведётся а надо ждать пока всё прогрузится
>>678101
А нет, дело в аудио. с m4a не работает превью а с aac да. если надо с m4a надо ставить framerate 2.
А нет, дело в аудио. с m4a не работает превью а с aac да. если надо с m4a надо ставить framerate 2.
Решит я тут коллекцию всяких шебмочек пережать с двача. И внатуре совсем с ума что ли сошел тот кто эту мп4 делал. Просто удивительное рядом. Сравните размер до и после.
>>678157
И размер коллекции вышел в 5 раз меньше, чем был, с незначительной потерей качества. Как же av1 ебет.
И размер коллекции вышел в 5 раз меньше, чем был, с незначительной потерей качества. Как же av1 ебет.
>>678160
Эм, я в хмедиа ковертил.
Кста при пережатии порнухи у меня больше разница выходит - до 10-20 раз меньше размер. Само собой по большей части из-за статичного фона в большинстве порнухи, а ав1 умеет сильно на этом экономить. Но и пережимаю все в 720р, но квантайзер выше делаю - 43.
Эм, я в хмедиа ковертил.
Кста при пережатии порнухи у меня больше разница выходит - до 10-20 раз меньше размер. Само собой по большей части из-за статичного фона в большинстве порнухи, а ав1 умеет сильно на этом экономить. Но и пережимаю все в 720р, но квантайзер выше делаю - 43.
38,9 Мб, mp4,356x356, 7:35
>>678164
Ну вот тут да. У меня тоже несколько попалось, которые не ужимались или даже больше становились. Ну такие я фильтрую и оставляю старую мп4. Ну можно еще попариться и уменьшить фпс и разрешение.
Ну вот тут да. У меня тоже несколько попалось, которые не ужимались или даже больше становились. Ну такие я фильтрую и оставляю старую мп4. Ну можно еще попариться и уменьшить фпс и разрешение.
5,9 Мб, webm,356x356, 7:35
>>678164
Ой, чет тупанул и не с той папки файл автоматом вкинул. Норм ужалась она.
Ой, чет тупанул и не с той папки файл автоматом вкинул. Норм ужалась она.
>>678163
хм, а я shutter encoder использую, про эту прогу не знал, попробую может она лучше
хм, а я shutter encoder использую, про эту прогу не знал, попробую может она лучше
А вот пример, где видеопоток даже больше вышел у ав1. Так что эту мп4 смысла пережимать нет.
6,4 Мб, mp4,640x360, 0:58
И вот этот больше вышел. Ну тут похожу сложная сцена с этими масляными разводами на воде, вот и пережимается хуже. Но если квантайзер побольше поставить то может и пережмется норм.
7,4 Мб, mp4,1024x576, 0:53
>>678260
Для архива сгодится. А если не найдешь оригинал, то нейросетка восстановит.
Для архива сгодится. А если не найдешь оригинал, то нейросетка восстановит.
Были же раньше времена...
https://files.scene.org/view/demos/groups/farb-rausch/fr-030_candytron_final.zip
https://files.scene.org/view/demos/groups/farb-rausch/fr-030_candytron_final.zip
>>678312
Чую. Мыльных шакалов много вылезло.
Чую. Мыльных шакалов много вылезло.
Вот на AVC качество, визуально без потерь - crf 18, шакалы на гране терпимости - crf 23. А как с этим дело обстоит у AV1?
2,1 Мб, webm,960x540, 0:41
>>678311
Никак, это был CRF 50.
Я длину GoP на 15 секунд выставил.
>А ты как при 43 ужал?
Никак, это был CRF 50.
>у меня вышло больше
Я длину GoP на 15 секунд выставил.
интересно сможет кто ни будь сжать чтобы было меньше и выглядело не хуже а то и получше? звук можно не трогать
8 Кб, 433x566>>678389
А что она дает? У меня ток такое есть.
А что она дает? У меня ток такое есть.
>>678492
Для двача сойдёт
Для двача сойдёт
791 Кб, webm,720x540, 0:26
>>678489
попробовал ещё раз, вроде качество примерно то же, но поменьше на ~90 кб
вот использованные команды если что
ffmpeg -i test.mp4 -vf "mpdecimate,hqdn3d=1.5:1.5:6:6,format=yuv420p10le" -color_range tv -colorspace bt709 -color_primaries bt709 -color_trc bt709 -c:v libsvtav1 -preset 0 -crf 48 -svtav1-params tune=0:enable-qm=1:qm-min=10:qm-max=15:aq-mode=2:enable-variance-boost=1:variance-boost-strength=4:film-grain=15:film-grain-denoise=1:enable-overlays=1:enable-cdef=1:qp-scale-compress-strength=3:sharpness=0:enable-tf=1:scd=1:lookahead=120:keyint=960:pred-struct=2 -c:a copy -frame_duration 60 -movflags +faststart -fps_mode vfr z.mp4
попробовал ещё раз, вроде качество примерно то же, но поменьше на ~90 кб
вот использованные команды если что
ffmpeg -i test.mp4 -vf "mpdecimate,hqdn3d=1.5:1.5:6:6,format=yuv420p10le" -color_range tv -colorspace bt709 -color_primaries bt709 -color_trc bt709 -c:v libsvtav1 -preset 0 -crf 48 -svtav1-params tune=0:enable-qm=1:qm-min=10:qm-max=15:aq-mode=2:enable-variance-boost=1:variance-boost-strength=4:film-grain=15:film-grain-denoise=1:enable-overlays=1:enable-cdef=1:qp-scale-compress-strength=3:sharpness=0:enable-tf=1:scd=1:lookahead=120:keyint=960:pred-struct=2 -c:a copy -frame_duration 60 -movflags +faststart -fps_mode vfr z.mp4
729 Кб, webm,720x540, 0:26
ещё минус 63кб
дальше только стоит менять variance-boost-strength=(2/3/4)
enable-qm=1:qm-min=(5/10)
nlmeans, ну и crf
в остальном всё равно придётся менять разрешение и аудио, дальше либо слишком долго ждать либо уже картинка кукольной будет
дальше только стоит менять variance-boost-strength=(2/3/4)
enable-qm=1:qm-min=(5/10)
nlmeans, ну и crf
в остальном всё равно придётся менять разрешение и аудио, дальше либо слишком долго ждать либо уже картинка кукольной будет
>>678511
забыл добавить
ffmpeg -i test.mp4 -vf "mpdecimate,nlmeans=s=5.0:p=9:r=21,format=yuv420p10le" -color_range tv -colorspace bt709 -color_primaries bt709 -color_trc bt709 -c:v libsvtav1 -preset 0 -crf 48 -svtav1-params tune=0:enable-qm=1:qm-min=5:qm-max=15:aq-mode=2:enable-variance-boost=1:variance-boost-strength=3:film-grain=15:film-grain-denoise=1:enable-overlays=1:enable-cdef=1:qp-scale-compress-strength=3:sharpness=0:enable-tf=1:scd=1:lookahead=120:keyint=10s:pred-struct=2 -c:a copy -frame_duration 60 -movflags +faststart -fps_mode vfr z1.mp4
забыл добавить
ffmpeg -i test.mp4 -vf "mpdecimate,nlmeans=s=5.0:p=9:r=21,format=yuv420p10le" -color_range tv -colorspace bt709 -color_primaries bt709 -color_trc bt709 -c:v libsvtav1 -preset 0 -crf 48 -svtav1-params tune=0:enable-qm=1:qm-min=5:qm-max=15:aq-mode=2:enable-variance-boost=1:variance-boost-strength=3:film-grain=15:film-grain-denoise=1:enable-overlays=1:enable-cdef=1:qp-scale-compress-strength=3:sharpness=0:enable-tf=1:scd=1:lookahead=120:keyint=10s:pred-struct=2 -c:a copy -frame_duration 60 -movflags +faststart -fps_mode vfr z1.mp4
>>678512
Ухудшает компрессию.
Дефолтные значения, указывать не обязательно.
Не работает.
Не работает в режиме CRF (правда тестил я еще до выхода 3.х.х).
>enable-overlays=1
>enable-variance-boost=1:variance-boost-strength=3
Ухудшает компрессию.
>aq-mode=2
>sharpness=0
>enable-cdef=1
>enable-tf=1
>pred-struct=2
Дефолтные значения, указывать не обязательно.
>scd=1
Не работает.
>lookahead=120
Не работает в режиме CRF (правда тестил я еще до выхода 3.х.х).
Как же охуенно ютуб жмет самым охуенным кодеком, охуеть просто!
Анчоусы, помогите
Скачал аудиокнигу, она в формате нескольких mp3 файлов
Пытался спросить у нейродебила как их объединить в m4b, на что он дал такую команду
На что ffmpeg мне выдал ошибки
Дальше нейродебил начал нести чушь
Как конвертнуть? mp3 конвертнуть во что-то другое?
Скачал аудиокнигу, она в формате нескольких mp3 файлов
Пытался спросить у нейродебила как их объединить в m4b, на что он дал такую команду
>ffmpeg -f concat -safe 0 -i mylist.txt -c copy book.m4b
На что ffmpeg мне выдал ошибки
>Could not find tag for codec mp3 in stream #0, codec not currently supported in container
>Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
Дальше нейродебил начал нести чушь
Как конвертнуть? mp3 конвертнуть во что-то другое?
>>678542
я пытался баланс найти между качеством и сжатием. естественно если надо совсем в нулину сжать можно кое что убрать но тогда и субьективно качество чуть похуже будет
а lookahead всё равно влияет на расрпеделение квантователя внутри кадров хотя на нулевом пресете и так большое окно анализа
я пытался баланс найти между качеством и сжатием. естественно если надо совсем в нулину сжать можно кое что убрать но тогда и субьективно качество чуть похуже будет
а lookahead всё равно влияет на расрпеделение квантователя внутри кадров хотя на нулевом пресете и так большое окно анализа
>>678627
Для копирования в конкате нужен тот же самый кодек на выход с одинаковыми параметрами вроде битрейта у входных файлов.
Либо ffmpeg -f concat -safe 0 -i mylist.txt -c copy book.mp3 то есть на выходе будет mp3
Либо реэнкодить в aac: ffmpeg -f concat -safe 0 -i mylist.txt -c:a aac book.m4b
Для копирования в конкате нужен тот же самый кодек на выход с одинаковыми параметрами вроде битрейта у входных файлов.
Либо ffmpeg -f concat -safe 0 -i mylist.txt -c copy book.mp3 то есть на выходе будет mp3
Либо реэнкодить в aac: ffmpeg -f concat -safe 0 -i mylist.txt -c:a aac book.m4b
>>678634
О том и речь. enable-overlays и enable-variance-boost улучшают качество, но за счет прироста битрейта. Если вместо этих опций поднять битрейт до того же значения через повышение qm-min/qm-max или снижение crf оценка VMAF будет немного выше.
Я выставлял 24, 72, 120, вообще убирал - на выходе получались одинаковые файлы, до байта. Как будто на CRF он его игнорирует.
Вот на VBR небольшое влияние было.
>баланс найти между качеством и сжатием
О том и речь. enable-overlays и enable-variance-boost улучшают качество, но за счет прироста битрейта. Если вместо этих опций поднять битрейт до того же значения через повышение qm-min/qm-max или снижение crf оценка VMAF будет немного выше.
>а lookahead всё равно влияет
Я выставлял 24, 72, 120, вообще убирал - на выходе получались одинаковые файлы, до байта. Как будто на CRF он его игнорирует.
Вот на VBR небольшое влияние было.
>>678646
Это пробовал, другая ошибка была
Получилось просто mp3 -> m4a все конвертнуть и их потом в m4b
Осталось придумать как бы на главы разбить все это дело
> ffmpeg -f concat -safe 0 -i mylist.txt -c:a aac book.m4b
Это пробовал, другая ошибка была
Получилось просто mp3 -> m4a все конвертнуть и их потом в m4b
Осталось придумать как бы на главы разбить все это дело
>>678580
А почему так? Нах вп9 нужен? Могли бы освободить мощностей (и места бы больше было) для ав1, и пресет получше выставить. Зачем они это делают?
А почему так? Нах вп9 нужен? Могли бы освободить мощностей (и места бы больше было) для ав1, и пресет получше выставить. Зачем они это делают?
>>679064
VP9 потому что аппаратное декодирование AV1 есть еще не у всех. Кодируют 360р как попало скорее всего потому что в таком качестве почти никто не смотрит.
Каким был исходник мы не знаем. Ну и выдергивать статичные кадры из динамичной сцены, да еще и длительностью в 0.65 секунды абсолютно бессмысленно.
VP9 потому что аппаратное декодирование AV1 есть еще не у всех. Кодируют 360р как попало скорее всего потому что в таком качестве почти никто не смотрит.
Каким был исходник мы не знаем. Ну и выдергивать статичные кадры из динамичной сцены, да еще и длительностью в 0.65 секунды абсолютно бессмысленно.
>>679064
Потому что цель не слепое следование хайпу как у местой ав1-лахты, а вариативность чтобы как можно больше пользователей имело доступ к контенту.
Потому что цель не слепое следование хайпу как у местой ав1-лахты, а вариативность чтобы как можно больше пользователей имело доступ к контенту.
>>679086
Там такая же каша и в более высоких разрешениях. И в 1080p, только чуть менее заметная.
Ага, настолько бессысленно, что аж в комментах под этим трейлером многие были настолько в ахуе от качества сжатия, что не поленились об этом отписать. Наверно в 144p смотрели, ага!
>Кодируют 360р как попало скорее всего потому что в таком качестве почти никто не смотрит.
Там такая же каша и в более высоких разрешениях. И в 1080p, только чуть менее заметная.
>Ну и выдергивать статичные кадры из динамичной сцены, да еще и длительностью в 0.65 секунды абсолютно бессмысленно.
Ага, настолько бессысленно, что аж в комментах под этим трейлером многие были настолько в ахуе от качества сжатия, что не поленились об этом отписать. Наверно в 144p смотрели, ага!
>>679121
Эм, а как вп9 в этом помогает? Для остальных хватит и h264. Какая то тупость нереальная. Разве не так?
Эм, а как вп9 в этом помогает? Для остальных хватит и h264. Какая то тупость нереальная. Разве не так?
>>679086
360 очень много смотрят на маленьких экранах, в режимах картинки-в-картинки и всяких автоплейных карточках которые они суют не спрашивая.
Но кодировать там можно на отъебись, это так.
>>679182
Тоже не, H.264 жирный. И сейчас уже есть клиенты которые H.264 не умеют, а VP9 умеют. Линуксы красноглазые в основном, но и аппаратные платформы встречаются.
Тут не какая-то бинарная задачка что одно лучше чем другое, а сложные поиски баланса между зрителями, траффиком, хранилищем и процессорным временем.
Но сейчас все чешут репу что делать с тремя кодеками в переходном состоянии, вполне вероятно что мы скоро придём либо к паре AV1+H.264, либо AV1+VP9, а третий помрёт. и начнём чесать репу что делать с H.266, AV2 и AVS3
У ВК Видео доклад был недавно. Видео вроде нет публично, но презентацию можешь полистать: https://vtconf.com/talks/7658d5759967410aa3def6cea5e00434/ там VP9 гасят по чуть-чуть например.
360 очень много смотрят на маленьких экранах, в режимах картинки-в-картинки и всяких автоплейных карточках которые они суют не спрашивая.
Но кодировать там можно на отъебись, это так.
>>679182
Тоже не, H.264 жирный. И сейчас уже есть клиенты которые H.264 не умеют, а VP9 умеют. Линуксы красноглазые в основном, но и аппаратные платформы встречаются.
Тут не какая-то бинарная задачка что одно лучше чем другое, а сложные поиски баланса между зрителями, траффиком, хранилищем и процессорным временем.
Но сейчас все чешут репу что делать с тремя кодеками в переходном состоянии, вполне вероятно что мы скоро придём либо к паре AV1+H.264, либо AV1+VP9, а третий помрёт. и начнём чесать репу что делать с H.266, AV2 и AVS3
У ВК Видео доклад был недавно. Видео вроде нет публично, но презентацию можешь полистать: https://vtconf.com/talks/7658d5759967410aa3def6cea5e00434/ там VP9 гасят по чуть-чуть например.
Какие параметры использовать на экстремально низких битрейтах? Например фильм 1.5-2 часа вжать в 40 мегов двача.
>>679881
Разрешение по любому придется понижать, звук в моно 8-10к.
Если делать через VBR (120 минут в 40 Мб это примерно 45.5kbs на видео + звук) то как-то так:
Надо учитывать что однопроходный VBR недодаст битрейта, а в два прохода ffmpeg не умеет. Плюс CRF выдает немного лучшее качество в том же битрейте и несколько быстрее.
Если делать через CRF то -с:b 38k заменяется на -crf 60 - но тут проблема в том что выходной битрейт зависит от контента и ты можешь как сильно недобрать, так и перебрать. Факап.
Поэтому придется разбивать (достаточно таймкоды определить) фильм на десяток кусков по 10-15 минут (в идеале по смене сцены), и кодировать их по отдельности подгоняя crf в большую или меньшую стороны. А потом склеить куски через -concat. Врядли ты готов так заморачиваться ради того чтобы понтануться на двоще.
В любом случае качество видео и звука будет помойным, а время кодирования измеряться десятками/сотнями минут.
>Например фильм 1.5-2 часа вжать в 40 мегов двача.
Разрешение по любому придется понижать, звук в моно 8-10к.
Если делать через VBR (120 минут в 40 Мб это примерно 45.5kbs на видео + звук) то как-то так:
>ffmpeg -i Input.mp4 -vf "scale=768:432" -pix_fmt yuv420p10le -c:v libsvtav1 -preset 2 -с:b 38k -svtav1-params tune=0:keyint=480:qp-scale-compress-strength=3:enable-qm=1:qm-min=0:qm-max=8:enable-dlf=2 -ac 1 -c:a libopus -b:a 8k TMP.mp4
Надо учитывать что однопроходный VBR недодаст битрейта, а в два прохода ffmpeg не умеет. Плюс CRF выдает немного лучшее качество в том же битрейте и несколько быстрее.
Если делать через CRF то -с:b 38k заменяется на -crf 60 - но тут проблема в том что выходной битрейт зависит от контента и ты можешь как сильно недобрать, так и перебрать. Факап.
Поэтому придется разбивать (достаточно таймкоды определить) фильм на десяток кусков по 10-15 минут (в идеале по смене сцены), и кодировать их по отдельности подгоняя crf в большую или меньшую стороны. А потом склеить куски через -concat. Врядли ты готов так заморачиваться ради того чтобы понтануться на двоще.
В любом случае качество видео и звука будет помойным, а время кодирования измеряться десятками/сотнями минут.
103 Кб, 800x800>>679932
Благодарю.
Да, наверное не стоит, все равно такие шакалы смотреть никто не выдержит.
Благодарю.
>Врядли ты готов так заморачиваться ради того чтобы понтануться на двоще.
Да, наверное не стоит, все равно такие шакалы смотреть никто не выдержит.
34,7 Мб, webm,342x192, 90:08
>>679881
Примерно так. Вполне смотрибельно на небльшом экранчике. Это ж сколько фильмов можно на 1 двд запихать, вы только вдумайтесь! ~126 фильмов Вся коллекция человечества лучших фильмов влезет уже на десяток двд! Вдумайтесь какая экономия. А мелкие детали мозг дорисует, или нейросетка в будущем.
Примерно так. Вполне смотрибельно на небльшом экранчике. Это ж сколько фильмов можно на 1 двд запихать, вы только вдумайтесь! ~126 фильмов Вся коллекция человечества лучших фильмов влезет уже на десяток двд! Вдумайтесь какая экономия. А мелкие детали мозг дорисует, или нейросетка в будущем.
>>680030
А с ав2 еще пиздаче будет.
А с ав2 еще пиздаче будет.
>>677630
Там еще помимо этого в mp3 старый баг с добавлением пустоты в начале файла вроде. Хз зачем нужен mp3 в 2026.
>Разве это не common knowledge еще с середины нулевых?
Там еще помимо этого в mp3 старый баг с добавлением пустоты в начале файла вроде. Хз зачем нужен mp3 в 2026.
>>678159
Я так порнушку на телефоне перекодировал, фотки видео мемы и размер уменьшился на 40 гигов. av1+jpegli ебет.
Я так порнушку на телефоне перекодировал, фотки видео мемы и размер уменьшился на 40 гигов. av1+jpegli ебет.
>>681227
И на качество звука мне насрать, речь понятна - более чем достаточно.
И на качество звука мне насрать, речь понятна - более чем достаточно.
>>681227
VBR вместо CBR. Если ставишь низкий битрейт (24k это уже низкий) лучше в моно кодировать, по ощущениям так меньше искажений.
VBR вместо CBR. Если ставишь низкий битрейт (24k это уже низкий) лучше в моно кодировать, по ощущениям так меньше искажений.
12,7 Мб, mp4,700x700, 8:43
норм?
исходник из flac перевёл в vbr opus 192кб, (12.3мб)
ну и склеил с обложкой чтобы видео получилось (12.7мб)
ffmpeg -loop 1 -framerate 1 -i сщмук.jpg -i output.opus -c:v libx265 -pix_fmt yuv420p10le -preset placebo -crf 45 -g 150 -c:a copy -shortest -movflags +faststart hidria.mp4
по тестам libx265 именно когда статичный кадр всегда весит меньше при прочих равных, даже меньше av1. можно ещё ужать? или только crf занижать? а он и так низкий
исходник из flac перевёл в vbr opus 192кб, (12.3мб)
ну и склеил с обложкой чтобы видео получилось (12.7мб)
ffmpeg -loop 1 -framerate 1 -i сщмук.jpg -i output.opus -c:v libx265 -pix_fmt yuv420p10le -preset placebo -crf 45 -g 150 -c:a copy -shortest -movflags +faststart hidria.mp4
по тестам libx265 именно когда статичный кадр всегда весит меньше при прочих равных, даже меньше av1. можно ещё ужать? или только crf занижать? а он и так низкий
хотя ещё можно gop сделать выше, хоть 9999, но тогда перемотка будет страдать. ну и разрешение понизить
7,1 Мб, mp4,512x512, 7:32
>>681372
С видео вообще ничего делать не нужно, у тебя там и так битрейт 3k. А вот использование HEVC нежелательно, у части пользователей не воспроизвелется в браузере. Используйуй AVC.
Звук можно ужимать до 96-128k, разницу с 192k все равно никто не услышит.
С видео вообще ничего делать не нужно, у тебя там и так битрейт 3k. А вот использование HEVC нежелательно, у части пользователей не воспроизвелется в браузере. Используйуй AVC.
Звук можно ужимать до 96-128k, разницу с 192k все равно никто не услышит.
>>681385
я услышу. 192 это более менее прозрачный звук при переводе из flac. (так и храню муз архив на пк)
понижаю битрейт только если не укладываюсь в 40 мб
>разницу с 192k все равно никто не услышит
я услышу. 192 это более менее прозрачный звук при переводе из flac. (так и храню муз архив на пк)
понижаю битрейт только если не укладываюсь в 40 мб
>>681395
Что? Хз о чём / ком ты.
Что? Хз о чём / ком ты.
>>681390
Ну раз для себя - оставляй как нравится. Но с видео заморачиваться смысла нет, это пара процентов от общего битрейта.
Ну раз для себя - оставляй как нравится. Но с видео заморачиваться смысла нет, это пара процентов от общего битрейта.
>>681398
да вот только почему то видео avc на дваче не работает (локально всё ок) с framerate 1 если аудио не aac. приходится ставить framerate 2 если аудио opus/m4a что веса накидывает.
ffmpeg -loop 1 -framerate 1 -i image.jpg -i audio.opus -c:v libx264 -tune stillimage -pix_fmt yuv420p10le -preset placebo -crf 45 -g 150 -c:a copy -shortest -movflags +faststart output.mp4
поэтому то я и использую HEVC
сам попробуй. ну или это я что то не так делаю.
да вот только почему то видео avc на дваче не работает (локально всё ок) с framerate 1 если аудио не aac. приходится ставить framerate 2 если аудио opus/m4a что веса накидывает.
ffmpeg -loop 1 -framerate 1 -i image.jpg -i audio.opus -c:v libx264 -tune stillimage -pix_fmt yuv420p10le -preset placebo -crf 45 -g 150 -c:a copy -shortest -movflags +faststart output.mp4
поэтому то я и использую HEVC
сам попробуй. ну или это я что то не так делаю.
2,3 Мб, mp4,512x512, 3:11
>>681405
Видео что я скинул выше - AVC в 1fps + Opus. И оно, и все остальные что я делал работают без проблем.
Видео что я скинул выше - AVC в 1fps + Opus. И оно, и все остальные что я делал работают без проблем.
>>681413
Избавься от 10 бит для начала.
У меня кстати нормально показывается.
> Stream #0:0[0x1](und): Video: h264 (High 10) (avc1 / 0x31637661), yuv420p10le(pc, bt470bg/unknown/unknown, progressive), 700x700 [SAR 1:1 DAR 1:1], 5 kb/s, 1 fps, 1 tbr, 16384 tbn (default)
Избавься от 10 бит для начала.
У меня кстати нормально показывается.
25,9 Мб, mp4,700x700, 16:55
>>681416
хмм, надо же магия, и правда дело было в битах.
всего то yuv420 а не yuv420p10le и всё заработало, спасибо.
хотя вес всё равно побольше hevc, но похоже это цена за совместимость
ffmpeg -loop 1 -framerate 1 -i cover.jpg -i output5.opus -c:v libx264 -tune stillimage -pix_fmt yuv420p -preset placebo -crf 45 -g 150 -c:a copy -shortest -movflags +faststart hidrian8+9-264.mp4
хмм, надо же магия, и правда дело было в битах.
всего то yuv420 а не yuv420p10le и всё заработало, спасибо.
хотя вес всё равно побольше hevc, но похоже это цена за совместимость
ffmpeg -loop 1 -framerate 1 -i cover.jpg -i output5.opus -c:v libx264 -tune stillimage -pix_fmt yuv420p -preset placebo -crf 45 -g 150 -c:a copy -shortest -movflags +faststart hidrian8+9-264.mp4
25,6 Мб, mp4,700x700, 16:55
>>681422
поменьше 25.5 мб вместо 25.8 на placebo, но и картинка чуть пошакальнее, хотя на таком crf в статике значения особо нет
поменьше 25.5 мб вместо 25.8 на placebo, но и картинка чуть пошакальнее, хотя на таком crf в статике значения особо нет
сам opus если что 25.1 весит
Как сделать изменение частоты кадров? Чтобы не константа, а плавно менялось, как результат какой-нибудь матфункции. Например, fps = 2t, где t это время и принадлежит [t1, t2].
>>681523
Или посложнее функции. t2, например
Или посложнее функции. t2, например
>>681537
Не за что.
Не за что.
>>681250
Жирновато выходит! Я эти ролики то смотрю раз с 10 лет, чисто в архив и пох.
>crf 38 максимум
Жирновато выходит! Я эти ролики то смотрю раз с 10 лет, чисто в архив и пох.
>>682595
Не легче, история как никак. И надо хранить, чтобы не забыть.
Не легче, история как никак. И надо хранить, чтобы не забыть.
>>678157
Щас всего за тыщу за терабайт можно взять неплохие жесткие диски. За две тыщи за терабайт можно взять два диска. Бэкапишь между ними и хранишь там свой мусор сколько хочешь.
Щас всего за тыщу за терабайт можно взять неплохие жесткие диски. За две тыщи за терабайт можно взять два диска. Бэкапишь между ними и хранишь там свой мусор сколько хочешь.
>>652226 (OP)
Возможно не туда пишу. Хочу скачать вот https://www.youtube.com/watch?v=_bQ_u5mKLko это видео - но у него ограничение по возрасту стоит, ничего не помогает. Может кто-нибудь из вас его скачать и в тред в виде webm закинуть?
Возможно не туда пишу. Хочу скачать вот https://www.youtube.com/watch?v=_bQ_u5mKLko это видео - но у него ограничение по возрасту стоит, ничего не помогает. Может кто-нибудь из вас его скачать и в тред в виде webm закинуть?
53 Кб, 895x531>>682885
Шутишь?
> Щас всего за тыщу за терабайт можно взять неплохие жесткие диски. За две тыщи за терабайт можно взять два диска. Бэкапишь между ними и хранишь там свой мусор сколько хочешь.
Шутишь?
>>683113
Так ты не 1тб смотри, а минимум 4тб, там по 3к за 1тб. Если ты бохатый, то нормально. Если не бохатый, то милости прошу на авиту, бери вилку и чисти. Моё личное мнение, лучше два б/у диска с авиты чем один новый из магазина.
Так ты не 1тб смотри, а минимум 4тб, там по 3к за 1тб. Если ты бохатый, то нормально. Если не бохатый, то милости прошу на авиту, бери вилку и чисти. Моё личное мнение, лучше два б/у диска с авиты чем один новый из магазина.
>>683173
Телепатией выбирать? А если посылку как джим керри доставят и продаван будет не при чем?
Телепатией выбирать? А если посылку как джим керри доставят и продаван будет не при чем?
Правильно я понимаю, что при уменьшении изображения, метод супервыборки аналогичен методу свертки билинейным фильтром?
701 Кб, 1190x1343>>684517
Лучший кодек, работайте, братья.
Лучший кодек, работайте, братья.
Есть аудиодорожка, она в несколько раз длиннее видеодорожки, есть гифка, она будет видеодорожкой по итогу. Я хочу, чтобы гифка была зациклена до конца аудиодорожки (гифка короче, опять же), но не занимала лишнее место одними и теми же кадрами при этом. Это вообще реально? Libsvtav1 желательно, нейронка не помогла.
>>682889
Закажи.
Закажи.
>>684703
Должно быть реально. Попробуй принудительно установить точную длину источника:
ffmpeg -i видео -i источник_аудио -to 00:11:22.500
Должно быть реально. Попробуй принудительно установить точную длину источника:
ffmpeg -i видео -i источник_аудио -to 00:11:22.500
Как рендерить видео в Reaper без потери качества?
Загружаю в рипер видос в формате mp4, скорость потока 2377 кб/с.
Редактирую
Рендерю в mp4. Разрешение оставляю оригинальное, качество выставляю 2500 кб/с - на выходе картинка какая-то зашакаленная по сравнению с оригиналом - словно глубина цвета меньше и картинка местами едва заметными квадратиками идёт.
Пробовал выставлять качество потока 5000, менять контейнер с h.264 на mpeg2, менять resample mode - никакого толка.
ЧЯДНТ?
Загружаю в рипер видос в формате mp4, скорость потока 2377 кб/с.
Редактирую
Рендерю в mp4. Разрешение оставляю оригинальное, качество выставляю 2500 кб/с - на выходе картинка какая-то зашакаленная по сравнению с оригиналом - словно глубина цвета меньше и картинка местами едва заметными квадратиками идёт.
Пробовал выставлять качество потока 5000, менять контейнер с h.264 на mpeg2, менять resample mode - никакого толка.
ЧЯДНТ?
>>685403
Кодируешь видео как угодно, потом копируешь звуковой поток с этого видео и видеопоток с исходника в конечный файл.
Кодируешь видео как угодно, потом копируешь звуковой поток с этого видео и видеопоток с исходника в конечный файл.
>>685549
На том скрине что ты приложил я не вижу нужных тебе настроек. Есть выпадающий список options, поищи там что-то вроде -c:v copy, -qp 0 или lossless=1. Если нет значит скорее всего никак, скачай ffmpeg и просто копируй видеопоток с исходника.
На том скрине что ты приложил я не вижу нужных тебе настроек. Есть выпадающий список options, поищи там что-то вроде -c:v copy, -qp 0 или lossless=1. Если нет значит скорее всего никак, скачай ffmpeg и просто копируй видеопоток с исходника.
>>685584
Ща попробую, спасибо
>Есть выпадающий список options, поищи там что-то вроде -c:v copy, -qp 0 или lossless=1.
Ща попробую, спасибо
Чёта лосслесс кут обосрался резать мои видео с телефона. И чёта резать их самому через ффмпег тоже не получается. Ничего не попадает по ключевым кадрам. Как ему указать что вот с этого ключевого кадра отрезать до туда-то? В плеере по кадрам переключаешься туда-сюда, миллисекунды скачут как хрен пойми, вбиваешь их в ффмпег, он то нормально режет, то оставляет в начале секунду статичного кадра. Нестабильно. Можно пережать всё видео целиком и потом резать по ключевым в лосслесс кат, наверно сработает. Но тогда уж можно резать через ффмпег и не по ключевым, всё равно ж перекод.
Я сейчас режу видео и кодирую части супербыстро без потерь, а потом собираю все части вместе и кодирую их уже с потерями.
Красивыми видеоредакторами я так и не научился пользоваться.
Я сейчас режу видео и кодирую части супербыстро без потерь, а потом собираю все части вместе и кодирую их уже с потерями.
Красивыми видеоредакторами я так и не научился пользоваться.
>>691123
Ставь -ss перед -i. Будет выбирать ключевые кадры.
ffmpeg -ss 15 -i video.mkv -to 33 -c copy video_copy.mkv
Ставь -ss перед -i. Будет выбирать ключевые кадры.
ffmpeg -ss 15 -i video.mkv -to 33 -c copy video_copy.mkv
258 Кб, 2000x2000>>691269
Неожиданно, что heic там побеждает, с другой стороны, там свой особенный датасет и своя метрика, пусть даже и построенная на существующих признанных.
Неожиданно, что heic там побеждает, с другой стороны, там свой особенный датасет и своя метрика, пусть даже и построенная на существующих признанных.
>>691637
В основном этот выигрыш за счёт того что хэйк смог в 12 битные файлы, тогда как авиф почему-то обосрался выше 10 бит подняться. Плюс у хейка "complexity=100" слоупочное, наверное, что-то дополнительно смогло выиграть. А может просто реализация в libheif лучше, чем в libavif и надо было ей и авиф сжимать. Много чего может быть, так-то они практически одинаковые, близкая к погрешности разница.
Меня больше результат жпег-хл удивил.
В основном этот выигрыш за счёт того что хэйк смог в 12 битные файлы, тогда как авиф почему-то обосрался выше 10 бит подняться. Плюс у хейка "complexity=100" слоупочное, наверное, что-то дополнительно смогло выиграть. А может просто реализация в libheif лучше, чем в libavif и надо было ей и авиф сжимать. Много чего может быть, так-то они практически одинаковые, близкая к погрешности разница.
Меня больше результат жпег-хл удивил.
>>691199
Видео с моего телефона сасунг.
ffmpeg.exe -ss 24:34 -to 25:47 -i "xxx.mp4" -c copy "xxx.mp4"
ffmpeg.exe -i "xxx.mp4" -ss 24:34 -to 25:47 -c copy "xxx.mp4"
В первом случае вроде должен резать по ключевым, но режет точно там где указано. Может быть остаётся невидимый огрызок до начала видео? Как проверить? Попробовал сдвинуть ss на 24:33.5 и получил точно такой же размер файла до байта, на время на 0,5 секунды длиннее.WinMerge показал что файлы почти совсем полностью одинаковые, только несколько байт отличаются. Вот такое наебалово! При склейке через concat file 'xxx.mp4' тоже хуйня получается, дёргается в местах склейки.
Во втором случае режет по следующему ключевому, первые пол секунды отсутствуют.
То есть режет либо до, оставляя невидимое начало, либо после, оставляя отсутствие кадров. Вертел на хую такие фокусы. Лучше буду резать в супер-быстро без-потерь и кодировать при склеивании.
А вот если писать
ffmpeg.exe -ss 24:34 -to 25:47 -i "xxx.mp4" -c copy "xxx.ts"
То режет до и не скрывает начало. И потом конкатом можно объединить в мп4 и ничего не глючит и не дёргается.
С мкв кстати тоже так же работает. Ну ок. Значит проблема была в том что я копировал стримы в мп4.
А как ты написал
ffmpeg -ss 15 -i video.mkv -to 33 -c copy video_copy.mkv
Лучше вообще не писать. Если писать -ss до -i, то -to после -i отсчитывает время в уже укороченном видео. Это вводит в заблуждение. Лучше тогда писать -t.
Мне кажется я изучаю какую-то хуйню уже давно разжёванную и описанную, но нигде не вижу где это прочитать.
Видео с моего телефона сасунг.
ffmpeg.exe -ss 24:34 -to 25:47 -i "xxx.mp4" -c copy "xxx.mp4"
ffmpeg.exe -i "xxx.mp4" -ss 24:34 -to 25:47 -c copy "xxx.mp4"
В первом случае вроде должен резать по ключевым, но режет точно там где указано. Может быть остаётся невидимый огрызок до начала видео? Как проверить? Попробовал сдвинуть ss на 24:33.5 и получил точно такой же размер файла до байта, на время на 0,5 секунды длиннее.WinMerge показал что файлы почти совсем полностью одинаковые, только несколько байт отличаются. Вот такое наебалово! При склейке через concat file 'xxx.mp4' тоже хуйня получается, дёргается в местах склейки.
Во втором случае режет по следующему ключевому, первые пол секунды отсутствуют.
То есть режет либо до, оставляя невидимое начало, либо после, оставляя отсутствие кадров. Вертел на хую такие фокусы. Лучше буду резать в супер-быстро без-потерь и кодировать при склеивании.
А вот если писать
ffmpeg.exe -ss 24:34 -to 25:47 -i "xxx.mp4" -c copy "xxx.ts"
То режет до и не скрывает начало. И потом конкатом можно объединить в мп4 и ничего не глючит и не дёргается.
С мкв кстати тоже так же работает. Ну ок. Значит проблема была в том что я копировал стримы в мп4.
А как ты написал
ffmpeg -ss 15 -i video.mkv -to 33 -c copy video_copy.mkv
Лучше вообще не писать. Если писать -ss до -i, то -to после -i отсчитывает время в уже укороченном видео. Это вводит в заблуждение. Лучше тогда писать -t.
Мне кажется я изучаю какую-то хуйню уже давно разжёванную и описанную, но нигде не вижу где это прочитать.
>>691972
Так у тебя транспортный стрим, попробуй сначала превратить его в обычный файл копированием всего (без попыток что-то отрезать) и только потом резать файл по ключевым кадрам.
Так у тебя транспортный стрим, попробуй сначала превратить его в обычный файл копированием всего (без попыток что-то отрезать) и только потом резать файл по ключевым кадрам.
>>692016
Чего? Мп4 это транспортный стрим? Или х265 это транспортный стрим?
У меня мп4 файл с телефона самсунг, внутри х265 и аац. Во что ты хочешь его там превратить?
Чего? Мп4 это транспортный стрим? Или х265 это транспортный стрим?
У меня мп4 файл с телефона самсунг, внутри х265 и аац. Во что ты хочешь его там превратить?
>>691972
Для таких монтажёров, как мы, которые
Сделали AviSynth и VapourSynth.
Рекомендую использовать с https://github.com/vapoursynth/bestsource/releases
> Мне кажется я изучаю какую-то хуйню уже давно разжёванную и описанную, но нигде не вижу где это прочитать.
Для таких монтажёров, как мы, которые
> Красивыми видеоредакторами так и не научились пользоваться
Сделали AviSynth и VapourSynth.
Рекомендую использовать с https://github.com/vapoursynth/bestsource/releases
>>692025
Про стрим ты сам написал и подчеркнул, что вот с расширением ts то всё работает. Когда ты получаешь некий стрим по UDP, неважно в каком формате, целостность файла не гарантируется, там пропуски могут быть, а ты его ещё и резать пытаешься по ключевым кадрам.
Про стрим ты сам написал и подчеркнул, что вот с расширением ts то всё работает. Когда ты получаешь некий стрим по UDP, неважно в каком формате, целостность файла не гарантируется, там пропуски могут быть, а ты его ещё и резать пытаешься по ключевым кадрам.
>>692071
Я про стрим ничего не писал. Я просто видео на телефон снял, скопировал на компуктер и режу его.
Я про стрим ничего не писал. Я просто видео на телефон снял, скопировал на компуктер и режу его.
34 Кб, 355x404>>691881
Попробовал с его параметрами avif vs jxl на этих датасетах:
https://imagecompression.info/test_images/ (RGB 16 bit)
https://people.xiph.org/~xiphmont/demo/daala/update1files/
Считал только ssimulacra2, jxl значительно лучше жмет на rgb 16, на daala разницы почти нет.
>Меня больше результат жпег-хл удивил.
Попробовал с его параметрами avif vs jxl на этих датасетах:
https://imagecompression.info/test_images/ (RGB 16 bit)
https://people.xiph.org/~xiphmont/demo/daala/update1files/
Считал только ssimulacra2, jxl значительно лучше жмет на rgb 16, на daala разницы почти нет.
188 Кб, 2000x2000>>692109
По этому 16 битному тесту у меня тоже выходит, что JXL лучше сжимает, хз даже. Маловато пикч в нём, но тут надо подбирать другую скорость, чтобы можно было потестить на большем количестве хайрезных фоток...
Очевидный минус этого датасета, что мы измеряем насколько хорошо они справляются с сохранением исошумов по итогу, а avif первым делом их подчистить пытается при сжатии, такая гипотеза.
По этому 16 битному тесту у меня тоже выходит, что JXL лучше сжимает, хз даже. Маловато пикч в нём, но тут надо подбирать другую скорость, чтобы можно было потестить на большем количестве хайрезных фоток...
Очевидный минус этого датасета, что мы измеряем насколько хорошо они справляются с сохранением исошумов по итогу, а avif первым делом их подчистить пытается при сжатии, такая гипотеза.
>>685617
Спрашивается зачем тебе тогда вообще чтото кодировать если ты просто источник копируешь
Спрашивается зачем тебе тогда вообще чтото кодировать если ты просто источник копируешь
>>691123
скачай avidemux там режет по ключевым кадрам, можно даже найти через прогу нужный тайминг и просто через ffmpeg прогнать его. Хуй знает в ffmpeg не хватает нормальной функции чтобы показал тебе все ключевые кадры видео.
скачай avidemux там режет по ключевым кадрам, можно даже найти через прогу нужный тайминг и просто через ffmpeg прогнать его. Хуй знает в ffmpeg не хватает нормальной функции чтобы показал тебе все ключевые кадры видео.
>>692972
Изначально вопрос стоял так:
Reaper это программа для работы со звуком, ответ на вопрос - никак не рендерить, а просто скопировать если это возможно через какие-то опции в интерфейсе. Сам я с ней не работал поэтому примерно указал что искать.
Изначально вопрос стоял так:
>Как рендерить видео в Reaper без потери качества?
Reaper это программа для работы со звуком, ответ на вопрос - никак не рендерить, а просто скопировать если это возможно через какие-то опции в интерфейсе. Сам я с ней не работал поэтому примерно указал что искать.
>>692975
Во, заработало! Вроде ровно и хорошо нарезало.
Чёт я раньше качал что-то резать и там что-то не срослось. А сейчас прям залетело заебись.
> avidemux
Во, заработало! Вроде ровно и хорошо нарезало.
Чёт я раньше качал что-то резать и там что-то не срослось. А сейчас прям залетело заебись.
Вопросы к шарящим в работе кодеков, в частности H265 (HEVC).
Провёл для себя небольшие сравнительные тесты, и выявил странности в функционировании пресетов. Суть:
Кодирую libx265 с заданным CRF 15, тестовое видео 4 минуты, blu-ray, даунскейл в 720р. Отличаются только пресеты.
Получаю:
1) medium, 7.5 минут, 171 МБ;
2) slow, 23 минуты, 186 МБ;
3) slower, 55 минут, 188 МБ;
4) veryslow, 90 минут, 187 МБ;
Мануал ffmpeg на тему x264/x265 говорит, что CRF задаёт качество, а пресет влияет на уровень сжатия и скорость кодирования. Соответственно, по логике, при одном и том же CRF я должен получать на выходе ~одинаковое качество, а размер файла (битрейт) должен уменьшаться от быстрых к медленным пресетам.
Результаты демонстрируют, что это совсем не так. На быстрых пресетах и размер меньше, и качество, очевидно, хуже. Т.е. всё-таки пресеты влияют на качество. При этом, совершенно не понятна взаимосвязь CRF vs preset. В чём тут тогда логика, и как пользователю оперировать с данными параметрами?
Алсо, каким образом можно численно проанализировать полученные видео на качество, в сравнении с оригиналом?
Провёл для себя небольшие сравнительные тесты, и выявил странности в функционировании пресетов. Суть:
Кодирую libx265 с заданным CRF 15, тестовое видео 4 минуты, blu-ray, даунскейл в 720р. Отличаются только пресеты.
Получаю:
1) medium, 7.5 минут, 171 МБ;
2) slow, 23 минуты, 186 МБ;
3) slower, 55 минут, 188 МБ;
4) veryslow, 90 минут, 187 МБ;
Мануал ffmpeg на тему x264/x265 говорит, что CRF задаёт качество, а пресет влияет на уровень сжатия и скорость кодирования. Соответственно, по логике, при одном и том же CRF я должен получать на выходе ~одинаковое качество, а размер файла (битрейт) должен уменьшаться от быстрых к медленным пресетам.
Результаты демонстрируют, что это совсем не так. На быстрых пресетах и размер меньше, и качество, очевидно, хуже. Т.е. всё-таки пресеты влияют на качество. При этом, совершенно не понятна взаимосвязь CRF vs preset. В чём тут тогда логика, и как пользователю оперировать с данными параметрами?
Алсо, каким образом можно численно проанализировать полученные видео на качество, в сравнении с оригиналом?
>>693148
Хули за тебя должен читать первый же гайд по этой хуйне?
https://trac.ffmpeg.org/wiki/Encode/H.265
Хули за тебя должен читать первый же гайд по этой хуйне?
> Note that CRF values are different based on which preset you select, a "slower" preset generates more compression/bit, but may increase filesize.
> If you compare "ultrafast" with "veryslow" at the same CRF value, "veryslow" may generate a larger file, with overall better compression.
https://trac.ffmpeg.org/wiki/Encode/H.265
>>693154
Там они сами себе противоречат.
Вот приходит рандомный человек, читает азы. Вроде с ходу всё просто и понятно. Потом тут же пишут, что всё вообще не так, а хуй пойми как. Ебитесь сами, и понимайте как хотите.
Там они сами себе противоречат.
>Choose a CRF. CRF affects the quality.
>Choose a preset. The default is medium. The preset determines compression options and efficiency and therefore affects encoding speed and size.
Вот приходит рандомный человек, читает азы. Вроде с ходу всё просто и понятно. Потом тут же пишут, что всё вообще не так, а хуй пойми как. Ебитесь сами, и понимайте как хотите.
34 Кб, 640x259>>693148
Вопрос снят. Сам нагуглил. До сего дня даже не слышал ни про какие метрики. Делюсь результатами. Может, будет для кого-то полезно. Выводы делаю такие:
1) CRF ниже 15 не имеет смысла.
2) пресеты медленнее чем slow не нужны.
3) Оптимальный битрейт/качество за разумное время - crf около 20 + preset slow.
Вряд ли открыл что-то новое, кроме как для себя. Вроде как мои результаты в целом соответствуют бенчмаркам энтузиастов.
>Алсо, каким образом можно численно проанализировать полученные видео на качество, в сравнении с оригиналом?
Вопрос снят. Сам нагуглил. До сего дня даже не слышал ни про какие метрики. Делюсь результатами. Может, будет для кого-то полезно. Выводы делаю такие:
1) CRF ниже 15 не имеет смысла.
2) пресеты медленнее чем slow не нужны.
3) Оптимальный битрейт/качество за разумное время - crf около 20 + preset slow.
Вряд ли открыл что-то новое, кроме как для себя. Вроде как мои результаты в целом соответствуют бенчмаркам энтузиастов.
40 Мб, webm,1920x872, 6:58
>>693148
>>693155
>>693177
Пресет отвечает за эффективность сжатия - соотношение качества полученного видео к битрейту. CRF по сути управляет выходным битрейтом.
Для одного и того же пресета: чем выше битрейт - тем выше качество.
Для одного и того же битрейта: чем медленнее пресет - тем выше качество.
С учетом даунскейла до 720p - как-то медленно выходит, ты точно процессор полностью нагрузил? Алсо если нет каких-то аппаратных ограничений на воспроизведение - глянь в сторону AV1.
>>693155
>>693177
>При этом, совершенно не понятна взаимосвязь CRF vs preset. В чём тут тогда логика, и как пользователю оперировать с данными параметрами?
Пресет отвечает за эффективность сжатия - соотношение качества полученного видео к битрейту. CRF по сути управляет выходным битрейтом.
Для одного и того же пресета: чем выше битрейт - тем выше качество.
Для одного и того же битрейта: чем медленнее пресет - тем выше качество.
>за разумное время
С учетом даунскейла до 720p - как-то медленно выходит, ты точно процессор полностью нагрузил? Алсо если нет каких-то аппаратных ограничений на воспроизведение - глянь в сторону AV1.
>>693199
У меня комп 2014 года. Камень 4790K.
Как-то пробовал из интереса, там скорость кодирования такая, что надо неделю ждать. Неюзабельно. Мне кажется, даже на современной пеке там не сильно веселее, если энкодер референсный программный, а не аппаратный.
Так-то мне для просмотра на старой ТВ-приставке, у которой максимум h264 и h265. Никаких AV1, VVC и т.п.
>С учетом даунскейла до 720p - как-то медленно выходит, ты точно процессор полностью нагрузил?
У меня комп 2014 года. Камень 4790K.
>если нет каких-то аппаратных ограничений на воспроизведение - глянь в сторону AV1.
Как-то пробовал из интереса, там скорость кодирования такая, что надо неделю ждать. Неюзабельно. Мне кажется, даже на современной пеке там не сильно веселее, если энкодер референсный программный, а не аппаратный.
Так-то мне для просмотра на старой ТВ-приставке, у которой максимум h264 и h265. Никаких AV1, VVC и т.п.
>>693204
ну на скорости 4 и 6 норм, почти как h264. хотя я тестил на коротких файлах - там разница минимальна по весу и качеству при одиноковом битрейте (потому что я всегда минимально достойно выглядящий низкий ставлю, это где то crf от 24 до 36) . выигрышь у av1 идёт на больших файлах. а если надо сжать короткий ролик быстро - старичок avc.
> там скорость кодирования такая, что надо неделю ждать
ну на скорости 4 и 6 норм, почти как h264. хотя я тестил на коротких файлах - там разница минимальна по весу и качеству при одиноковом битрейте (потому что я всегда минимально достойно выглядящий низкий ставлю, это где то crf от 24 до 36) . выигрышь у av1 идёт на больших файлах. а если надо сжать короткий ролик быстро - старичок avc.
>>693206
хотя я юзал av1 svt. libaom получше сжимает особенно на низких скоростях. но и это дольше конечно. я пока с пресетами игрался у меня всё термопаста засохла на проце а я недавно менял.
хотя я юзал av1 svt. libaom получше сжимает особенно на низких скоростях. но и это дольше конечно. я пока с пресетами игрался у меня всё термопаста засохла на проце а я недавно менял.
>>693207
Ванильный svt? Форки не пробовал?
https://github.com/Uranite/svt-av1-tritium
https://github.com/juliobbv-p/svt-av1-hdr
Ванильный svt? Форки не пробовал?
https://github.com/Uranite/svt-av1-tritium
https://github.com/juliobbv-p/svt-av1-hdr
>>693375
Жопочтец? Речь не про комп.
Жопочтец? Речь не про комп.
НАПОМИНАЮ
21.11.2025 11:12 (MSK)
Компании HP и Dell в ряде современных ноутбуков намеренно отключили аппаратное декодирование видео с использованием видеокодека HEVC (H.265), хотя используемые процессоры AMD и Intel технически поддерживают эту возможность. HP упоминает об отключении аппаратного ускорения HEVC в спецификациях некоторых моделей ProBook и EliteBook. У Dell ситуация менее прозрачная - официальные спецификации не содержат предупреждений, однако служба поддержки компании подтверждает, что HEVC недоступен на базовых конфигурациях без дискретной графики, 4K-экрана или пакета мультимедийных лицензий.
Обе компании отказались объяснять причины такого решения. Предполагается, что отключение вызвано стремлением сократить лицензионные расходы: с января увеличиваются лицензионные отчисления за каждое устройство с поддержкой HEVC, и отключение функции позволяет производителям формально избежать дополнительных платежей.
21.11.2025 11:12 (MSK)
Компании HP и Dell в ряде современных ноутбуков намеренно отключили аппаратное декодирование видео с использованием видеокодека HEVC (H.265), хотя используемые процессоры AMD и Intel технически поддерживают эту возможность. HP упоминает об отключении аппаратного ускорения HEVC в спецификациях некоторых моделей ProBook и EliteBook. У Dell ситуация менее прозрачная - официальные спецификации не содержат предупреждений, однако служба поддержки компании подтверждает, что HEVC недоступен на базовых конфигурациях без дискретной графики, 4K-экрана или пакета мультимедийных лицензий.
Обе компании отказались объяснять причины такого решения. Предполагается, что отключение вызвано стремлением сократить лицензионные расходы: с января увеличиваются лицензионные отчисления за каждое устройство с поддержкой HEVC, и отключение функции позволяет производителям формально избежать дополнительных платежей.
Че там av2/amv уже скомпилил тестил ктото? 50% к сжатию av1 уже имбово звучит, еще svt-av1 4.0.1 вышла, но по сути новая версия это просто все функции интузиастов с svt-av1-psy спиздили в мэйнлайн.
Какая самая лешевая видеокарта для апаратного кодирования AV1, мне нужно, аниме, фильмы, сериалы перегнать в него для жкономии места. Не на проце тоде неплозо идет, но когда я пробовал в hevc на вилюхе мне там под тысячу кадров в секунду делала, а на проце в ав1 под 200-300 только.
>>693816
Это значит что за сутки ты почти год своего аниме перемолотишь.
Нахуй тебе быстрее?
Пока видеокарту тебе доставлять будут ты натранскодишь больше времени контента чем тебе жить останется.
>200-300 только
Это значит что за сутки ты почти год своего аниме перемолотишь.
Нахуй тебе быстрее?
Пока видеокарту тебе доставлять будут ты натранскодишь больше времени контента чем тебе жить останется.
> FFmpeg Batch AV Converter
Не зря почитал тредю, удобная программа, как раз искал способ конвертировать много файлов за раз
И чот бегло поглядел по пресетам видео, не увидел в списке ваш новомодный AV1, такой же непонятный и неуловимый как для аудио DSD вроде бы, со странной частотой дискретизации в 1.5 МГц
А чего ShotCut с настройками по умолчанию для HEVC сжимает сильнее, чем HEVC из FFMpeg?
Ой чот мне не нравится, что на выходе 900 МБ вместо приятных 200МБ, ой фу ваш ffmpeg
Ой чот мне не нравится, что на выходе 900 МБ вместо приятных 200МБ, ой фу ваш ffmpeg
>>694368
Нет, я настроек не знаю и потому приходится просто экспериментировать чтобы и качество не всратое и вес небольшой, в ShotCut настроек по умолчанию за глаза, но я не нашёл как сразу несколько файлов пережать
Нет, я настроек не знаю и потому приходится просто экспериментировать чтобы и качество не всратое и вес небольшой, в ShotCut настроек по умолчанию за глаза, но я не нашёл как сразу несколько файлов пережать
>>694484
ффмпег всё умеет.
ффмпег всё умеет.
>>694484
Умеет, но если у тебя остаётся всего одна дорожка, то как-то так:
ffmpeg -hide_banner -i video.mp4 -i audio1.opus -i audio2.opus \
-map 0:v -map 1:a -map 2:a \
-metadata:s:a:0 language="ru" -metadata:s:a:0 title="Первая дорожка" \
-metadata:s:a:1 language="ru" -metadata:s:a:1 title="Вторая дорожка" \
-c copy -y video_out.mkv
Умеет, но если у тебя остаётся всего одна дорожка, то как-то так:
ffmpeg -hide_banner -i video.mp4 -i audio1.opus -i audio2.opus \
-map 0:v -map 1:a -map 2:a \
-metadata:s:a:0 language="ru" -metadata:s:a:0 title="Первая дорожка" \
-metadata:s:a:1 language="ru" -metadata:s:a:1 title="Вторая дорожка" \
-c copy -y video_out.mkv
>>694550
Благодарю, попробую
И ещё вопрос. Результат сжатия видеокартой, конкретно серии 6000, может отличаться, от результата процессором при одинаковых настройках?
Благодарю, попробую
И ещё вопрос. Результат сжатия видеокартой, конкретно серии 6000, может отличаться, от результата процессором при одинаковых настройках?
>>694568
Разные библиотеки используется, значит будет отличаться. Причём сильно, на GPU качество всегда заметно хуже при одинаковом размере файла.
>Результат сжатия видеокартой, конкретно серии 6000, может отличаться, от результата процессором при одинаковых настройках
Разные библиотеки используется, значит будет отличаться. Причём сильно, на GPU качество всегда заметно хуже при одинаковом размере файла.
>>694607
Там не библиотеки, там готовый независимый модуль кодировщика куплен и вставлен в схему чипа на этапе производства. Он аппаратно реализует все нужные части алгоритма, на входе получает буфер в памяти с кадрами, на выходе выдаёт готовый сжатый поток видео в другой буфер.
Бытовые кодировщики (в компьютерах, смартфонах, приставках и прочем) в первую очередь нацелены на работу в реальном времени (с маленькой задержкой). Как они используются? Видосик снимают смартфоном, он сразу кодируется и сохраняется. По видеосвязи общаются, видео с камеры кодируется и сразу улетает. Игру или фильм передают на другое устройство в нужном формате (или на сервис вещания в интернете), всё то же самое. Их задача выдавать достаточное для типичных условий просмотра качество и при этом не быть слишком сложными/дорогими в производстве. Профили сжатия для того и стандартизированы заранее, чтобы сложные в реализации части на каких-то устройствах можно было без вреда опустить. Подразумевается, что если кому-то и нужно качество повыше, то почти всегда можно достичь этого, задрав аппаратному кодировщику битрейт. Для вылизывания параметров сжатия они не предназначены, поскольку многие детали там просто фиксированы.
А если надо и быстро, и максимально качественно, и чтобы работало 24 часа в сутки, то есть студийная техника, которая стоит как автомобиль.
Там не библиотеки, там готовый независимый модуль кодировщика куплен и вставлен в схему чипа на этапе производства. Он аппаратно реализует все нужные части алгоритма, на входе получает буфер в памяти с кадрами, на выходе выдаёт готовый сжатый поток видео в другой буфер.
Бытовые кодировщики (в компьютерах, смартфонах, приставках и прочем) в первую очередь нацелены на работу в реальном времени (с маленькой задержкой). Как они используются? Видосик снимают смартфоном, он сразу кодируется и сохраняется. По видеосвязи общаются, видео с камеры кодируется и сразу улетает. Игру или фильм передают на другое устройство в нужном формате (или на сервис вещания в интернете), всё то же самое. Их задача выдавать достаточное для типичных условий просмотра качество и при этом не быть слишком сложными/дорогими в производстве. Профили сжатия для того и стандартизированы заранее, чтобы сложные в реализации части на каких-то устройствах можно было без вреда опустить. Подразумевается, что если кому-то и нужно качество повыше, то почти всегда можно достичь этого, задрав аппаратному кодировщику битрейт. Для вылизывания параметров сжатия они не предназначены, поскольку многие детали там просто фиксированы.
А если надо и быстро, и максимально качественно, и чтобы работало 24 часа в сутки, то есть студийная техника, которая стоит как автомобиль.
Зачем вы тут ковыряетесь, если профессионалы сто лет назад выяснили, сколько битрейта хватит на CD Quality?
>>694644
Я flac, если он есть, на диски пишу, даже 700 1000 бит рейт за глаза
Есть и старые диски с качеством как на картинке, конечно звучит отлично, но место не резиновое
Я flac, если он есть, на диски пишу, даже 700 1000 бит рейт за глаза
Есть и старые диски с качеством как на картинке, конечно звучит отлично, но место не резиновое
>>694607
Значит мне не показалось, получается ситуация как с рендерингом на видео и процессором в каком нибудь vray
Буду экспериментировать дальше, видяха конечно быстрее, даже процессора 3950
Значит мне не показалось, получается ситуация как с рендерингом на видео и процессором в каком нибудь vray
Буду экспериментировать дальше, видяха конечно быстрее, даже процессора 3950
>>694646
Ну шутка-то в том, что даже 128 кб/с, который пафосно называли неотличимым от оригинала, на самом деле не годился, а тут WMA в 64 кб/с, который булькал и дзынькал ничуть не меньше, чем MP3 первых лет на таком же битрейте. Только LAME потом годами оптимизировали, чтобы артефакты как можно лучше скрывать на типичных звуках, а WMA вскоре стал не слишком нужным. Нахальство Microsoft, которая тогда пыталась подмять под себя весь мир и все индустрии сразу, не знало границ.
В интерфейсе Windows Media Player для сохранения музыки с дисков уже скромнее были и рекомендовали 128 килобит.
Ну шутка-то в том, что даже 128 кб/с, который пафосно называли неотличимым от оригинала, на самом деле не годился, а тут WMA в 64 кб/с, который булькал и дзынькал ничуть не меньше, чем MP3 первых лет на таком же битрейте. Только LAME потом годами оптимизировали, чтобы артефакты как можно лучше скрывать на типичных звуках, а WMA вскоре стал не слишком нужным. Нахальство Microsoft, которая тогда пыталась подмять под себя весь мир и все индустрии сразу, не знало границ.
В интерфейсе Windows Media Player для сохранения музыки с дисков уже скромнее были и рекомендовали 128 килобит.
>>694236
Надо попробовать. Есть ещё Shutter Encoder, тоже надстройка над ffmpeg
>>693816
Думаешь видеокарта будет дешевле ещё одного жёсткого диска?
>FFmpeg Batch AV Converter
Надо попробовать. Есть ещё Shutter Encoder, тоже надстройка над ffmpeg
>>693816
>Какая самая лешевая видеокарта для апаратного кодирования AV1, мне нужно, аниме, фильмы, сериалы перегнать в него для жкономии места.
Думаешь видеокарта будет дешевле ещё одного жёсткого диска?
>>693816
Ты мне напоминаешь человека, который когда-то отсканировал семейные фото в 1024×768 (потому что это же ПОЛНЫЙ ЭКРАН МАКСИМАЛЬНОЕ КАЧЕСТВО БОЛЬШЕ НЕ ПОНАДОБИТСЯ) и сделал АВТОУРОВНИ, чтобы на мониторе разглядеть тёмные места можно было. Вот, а теперь эти файлы как-то уже совсем стыдно выглядят.
Ты не понимаешь, что в сжатии с потерями важен не новый или старый кодек, а формулировка задачи, выбор критериев, которым должны соответствовать результаты (объём, качество, максимальная скорость чтения или передачи и так далее). Если ты не знаешь, что ты хочешь получить, то просто зря потратишь время и электричество.
Для того, чтобы сделать «точно так же, но меньше объёмом за счёт нового кодека», нужно сначала определить, сколько это «точно так же», сколько в файле «качества». Это, в общем, не решаемая задача. Либо мы можем попробовать использовать сам анализатор кодировщика, чтобы оценивать сложность данных по сравнению с «типичными» (в современных кодеках проделана такая работа), но тогда надо как-то игнорировать артефакты сжатия и фильтрации (добавление шума), не считать их полезными данными, в отличие от оригинальных деталей изображения (а как их отличишь?). Либо можно в лоб взять большое число отрывков из разных мест, посчитать какую-то визуальную метрику для оригинала, перекодировать с какими-то настройками, посчитать метрику для результата, и корректировать настройки, пока не не станет достаточно близко. Это и будет «примерно такое же качество» (но только для этой метрики). Но вообще это всё глупости, и для каждого следующего перекодирования надо потратить не меньше времени на оценку заметности ухудшений, чем тратил автор предыдущего. Ты будешь сидеть и подбирать параметры для каждого фильма? Сомневаюсь.
Вообще, вся эта затея глупа ещё и потому, что о перекодировании начинают думать, когда результат становится на порядок или хотя бы в несколько раз меньше оригинала. Что-то мне подсказывает, что пережимать фильмы до состояния экранки, зато маленькой, ты всё-таки не готов. А от ужатия с новыми настройками или кодеками на несколько процентов при прочих равных может выиграть только гигантский архив вроде YouTube (где эти проценты превращаются в ящики, полные жёстких дисков, на которых можно сэкономить), которому есть выгода потратиться на работу. У тебя от освобождения 10% диска ситуация кардинально не поменяется. Так что либо займись разбором и уборкой, либо прими, что имеющиеся варианты тебя устраивают, важны, будут храниться, и расширяй объём хранения.
Ты мне напоминаешь человека, который когда-то отсканировал семейные фото в 1024×768 (потому что это же ПОЛНЫЙ ЭКРАН МАКСИМАЛЬНОЕ КАЧЕСТВО БОЛЬШЕ НЕ ПОНАДОБИТСЯ) и сделал АВТОУРОВНИ, чтобы на мониторе разглядеть тёмные места можно было. Вот, а теперь эти файлы как-то уже совсем стыдно выглядят.
Ты не понимаешь, что в сжатии с потерями важен не новый или старый кодек, а формулировка задачи, выбор критериев, которым должны соответствовать результаты (объём, качество, максимальная скорость чтения или передачи и так далее). Если ты не знаешь, что ты хочешь получить, то просто зря потратишь время и электричество.
Для того, чтобы сделать «точно так же, но меньше объёмом за счёт нового кодека», нужно сначала определить, сколько это «точно так же», сколько в файле «качества». Это, в общем, не решаемая задача. Либо мы можем попробовать использовать сам анализатор кодировщика, чтобы оценивать сложность данных по сравнению с «типичными» (в современных кодеках проделана такая работа), но тогда надо как-то игнорировать артефакты сжатия и фильтрации (добавление шума), не считать их полезными данными, в отличие от оригинальных деталей изображения (а как их отличишь?). Либо можно в лоб взять большое число отрывков из разных мест, посчитать какую-то визуальную метрику для оригинала, перекодировать с какими-то настройками, посчитать метрику для результата, и корректировать настройки, пока не не станет достаточно близко. Это и будет «примерно такое же качество» (но только для этой метрики). Но вообще это всё глупости, и для каждого следующего перекодирования надо потратить не меньше времени на оценку заметности ухудшений, чем тратил автор предыдущего. Ты будешь сидеть и подбирать параметры для каждого фильма? Сомневаюсь.
Вообще, вся эта затея глупа ещё и потому, что о перекодировании начинают думать, когда результат становится на порядок или хотя бы в несколько раз меньше оригинала. Что-то мне подсказывает, что пережимать фильмы до состояния экранки, зато маленькой, ты всё-таки не готов. А от ужатия с новыми настройками или кодеками на несколько процентов при прочих равных может выиграть только гигантский архив вроде YouTube (где эти проценты превращаются в ящики, полные жёстких дисков, на которых можно сэкономить), которому есть выгода потратиться на работу. У тебя от освобождения 10% диска ситуация кардинально не поменяется. Так что либо займись разбором и уборкой, либо прими, что имеющиеся варианты тебя устраивают, важны, будут храниться, и расширяй объём хранения.
>>693816
Ты мне напоминаешь человека, который когда-то отсканировал семейные фото в 1024×768 (потому что это же ПОЛНЫЙ ЭКРАН МАКСИМАЛЬНОЕ КАЧЕСТВО БОЛЬШЕ НЕ ПОНАДОБИТСЯ) и сделал АВТОУРОВНИ, чтобы на мониторе разглядеть тёмные места можно было. Вот, а теперь эти файлы как-то уже совсем стыдно выглядят.
Ты не понимаешь, что в сжатии с потерями важен не новый или старый кодек, а формулировка задачи, выбор критериев, которым должны соответствовать результаты (объём, качество, максимальная скорость чтения или передачи и так далее). Если ты не знаешь, что ты хочешь получить, то просто зря потратишь время и электричество.
Для того, чтобы сделать «точно так же, но меньше объёмом за счёт нового кодека», нужно сначала определить, сколько это «точно так же», сколько в файле «качества». Это, в общем, не решаемая задача. Либо мы можем попробовать использовать сам анализатор кодировщика, чтобы оценивать сложность данных по сравнению с «типичными» (в современных кодеках проделана такая работа), но тогда надо как-то игнорировать артефакты сжатия и фильтрации (добавление шума), не считать их полезными данными, в отличие от оригинальных деталей изображения (а как их отличишь?). Либо можно в лоб взять большое число отрывков из разных мест, посчитать какую-то визуальную метрику для оригинала, перекодировать с какими-то настройками, посчитать метрику для результата, и корректировать настройки, пока не не станет достаточно близко. Это и будет «примерно такое же качество» (но только для этой метрики). Но вообще это всё глупости, и для каждого следующего перекодирования надо потратить не меньше времени на оценку заметности ухудшений, чем тратил автор предыдущего. Ты будешь сидеть и подбирать параметры для каждого фильма? Сомневаюсь.
Вообще, вся эта затея глупа ещё и потому, что о перекодировании начинают думать, когда результат становится на порядок или хотя бы в несколько раз меньше оригинала. Что-то мне подсказывает, что пережимать фильмы до состояния экранки, зато маленькой, ты всё-таки не готов. А от ужатия с новыми настройками или кодеками на несколько процентов при прочих равных может выиграть только гигантский архив вроде YouTube (где эти проценты превращаются в ящики, полные жёстких дисков, на которых можно сэкономить), которому есть выгода потратиться на работу. У тебя от освобождения 10% диска ситуация кардинально не поменяется. Так что либо займись разбором и уборкой, либо прими, что имеющиеся варианты тебя устраивают, важны, будут храниться, и расширяй объём хранения.
Ты мне напоминаешь человека, который когда-то отсканировал семейные фото в 1024×768 (потому что это же ПОЛНЫЙ ЭКРАН МАКСИМАЛЬНОЕ КАЧЕСТВО БОЛЬШЕ НЕ ПОНАДОБИТСЯ) и сделал АВТОУРОВНИ, чтобы на мониторе разглядеть тёмные места можно было. Вот, а теперь эти файлы как-то уже совсем стыдно выглядят.
Ты не понимаешь, что в сжатии с потерями важен не новый или старый кодек, а формулировка задачи, выбор критериев, которым должны соответствовать результаты (объём, качество, максимальная скорость чтения или передачи и так далее). Если ты не знаешь, что ты хочешь получить, то просто зря потратишь время и электричество.
Для того, чтобы сделать «точно так же, но меньше объёмом за счёт нового кодека», нужно сначала определить, сколько это «точно так же», сколько в файле «качества». Это, в общем, не решаемая задача. Либо мы можем попробовать использовать сам анализатор кодировщика, чтобы оценивать сложность данных по сравнению с «типичными» (в современных кодеках проделана такая работа), но тогда надо как-то игнорировать артефакты сжатия и фильтрации (добавление шума), не считать их полезными данными, в отличие от оригинальных деталей изображения (а как их отличишь?). Либо можно в лоб взять большое число отрывков из разных мест, посчитать какую-то визуальную метрику для оригинала, перекодировать с какими-то настройками, посчитать метрику для результата, и корректировать настройки, пока не не станет достаточно близко. Это и будет «примерно такое же качество» (но только для этой метрики). Но вообще это всё глупости, и для каждого следующего перекодирования надо потратить не меньше времени на оценку заметности ухудшений, чем тратил автор предыдущего. Ты будешь сидеть и подбирать параметры для каждого фильма? Сомневаюсь.
Вообще, вся эта затея глупа ещё и потому, что о перекодировании начинают думать, когда результат становится на порядок или хотя бы в несколько раз меньше оригинала. Что-то мне подсказывает, что пережимать фильмы до состояния экранки, зато маленькой, ты всё-таки не готов. А от ужатия с новыми настройками или кодеками на несколько процентов при прочих равных может выиграть только гигантский архив вроде YouTube (где эти проценты превращаются в ящики, полные жёстких дисков, на которых можно сэкономить), которому есть выгода потратиться на работу. У тебя от освобождения 10% диска ситуация кардинально не поменяется. Так что либо займись разбором и уборкой, либо прими, что имеющиеся варианты тебя устраивают, важны, будут храниться, и расширяй объём хранения.
>>694663
Если человек знал что хотел, то результат своим требованиям в тот момент полностью соответствовал. А современные мониторы и объёмы хранилищ просто в них не входили.
> Ты мне напоминаешь человека, который когда-то отсканировал семейные фото в 1024×768 (потому что это же ПОЛНЫЙ ЭКРАН МАКСИМАЛЬНОЕ КАЧЕСТВО БОЛЬШЕ НЕ ПОНАДОБИТСЯ) и сделал АВТОУРОВНИ, чтобы на мониторе разглядеть тёмные места можно было. Вот, а теперь эти файлы как-то уже совсем стыдно выглядят.
Если человек знал что хотел, то результат своим требованиям в тот момент полностью соответствовал. А современные мониторы и объёмы хранилищ просто в них не входили.
>>693528
Ну так HEVC - лицензируемая параша, и с каждого устройства с его аппаратной поддержкой надо уплатить НОЛОГ за воздух, иначе суды, штрафы, санкции, гроб, кладбище. Поэтому у VVC-параши нет будущего, везде будет AV-1 (и H264).
Ну так HEVC - лицензируемая параша, и с каждого устройства с его аппаратной поддержкой надо уплатить НОЛОГ за воздух, иначе суды, штрафы, санкции, гроб, кладбище. Поэтому у VVC-параши нет будущего, везде будет AV-1 (и H264).
>>694722
Ну и чо теперь делать? У меня карта может только 265 кодировать, а ваш ав нет, ещё и проигрывателю плугин нужен
Ну его нахуй
Ну и чо теперь делать? У меня карта может только 265 кодировать, а ваш ав нет, ещё и проигрывателю плугин нужен
Ну его нахуй
>>694739
Если тебе в 1-ю очередь важно качество, то любые аппаратные кодеры - это кал, т.к. производят немало артефактов.
Если тебе в 1-ю очередь важно качество, то любые аппаратные кодеры - это кал, т.к. производят немало артефактов.
5 Кб, 154x109Как этим пользоваться? Точнее так, как это должно работать?
Чего я ожидаю: я указываю ему начальное и конечное время из некого видео и затем при запуске сжатия он заодно его и порежет
Чего получается на выходе: жмёт и обрезает
На кнопку нажимал, он ошибку выдаёт
Чего я ожидаю: я указываю ему начальное и конечное время из некого видео и затем при запуске сжатия он заодно его и порежет
Чего получается на выходе: жмёт и обрезает
На кнопку нажимал, он ошибку выдаёт
>>694955
Разобрался проблема была в том, что он не может или не хочет перезаписывать файл, так как я сохранял туда же и с тем же именем уже обрезанный файл есть в этом смысл, так как он сначала делает пустышку-заготовку с именем, а в процессе туда инфу заливает
Разобрался проблема была в том, что он не может или не хочет перезаписывать файл, так как я сохранял туда же и с тем же именем уже обрезанный файл есть в этом смысл, так как он сначала делает пустышку-заготовку с именем, а в процессе туда инфу заливает
>>695000
Да, в нём настройки по умолчанию дают результат, который меня устраивает, на данный момент я уже подобрал параметры, так что проблем нету
Да, в нём настройки по умолчанию дают результат, который меня устраивает, на данный момент я уже подобрал параметры, так что проблем нету
>>695035
так обычно и происходит это не способ плохой это просто ты не разобрался. (личное моё наблюдение) все способы которые обещают быстрый однокнопочный результат - компромиссные и уступают по качеству. а если хочешь лучше - надо разбираться. но в ffmpeg хорошо то что он универсален, один раз надо только разобраться и потом всю жизнь можно пользоваться в отличии от того чтобы прыгать от проге к проге и каждый раз заново учится с ней работать
так обычно и происходит это не способ плохой это просто ты не разобрался. (личное моё наблюдение) все способы которые обещают быстрый однокнопочный результат - компромиссные и уступают по качеству. а если хочешь лучше - надо разбираться. но в ffmpeg хорошо то что он универсален, один раз надо только разобраться и потом всю жизнь можно пользоваться в отличии от того чтобы прыгать от проге к проге и каждый раз заново учится с ней работать
>>695049
При старте обучения всегда идёт копирование рабочего примера, ещё лучше, если есть пример под конкретную задачу, а потом уже идёт рост вширь с изучением тонкостей
Я даже теорию придумал, два типа обучения
Обучение копированием - быстро, но нет гарантии запоминания
Обучение через открытие - некое самостоятельное исследование с набором небольших знаний, изучение всяких источников и потом на основе этого само открытие - долгий, неопределённый по затратам времени процесс, но результат запоминается навсегда
>>695181
Попробую
При старте обучения всегда идёт копирование рабочего примера, ещё лучше, если есть пример под конкретную задачу, а потом уже идёт рост вширь с изучением тонкостей
Я даже теорию придумал, два типа обучения
Обучение копированием - быстро, но нет гарантии запоминания
Обучение через открытие - некое самостоятельное исследование с набором небольших знаний, изучение всяких источников и потом на основе этого само открытие - долгий, неопределённый по затратам времени процесс, но результат запоминается навсегда
>>695181
Попробую
>>694663
хорошо так и оставлю 1.2 гб за 6 минутную серию аниме в 1080п, не ну что зачем мне экономить место и возиться с этиси кодеками и настройка, просто увеличу место, у меня же корпус бесконечный и три блока питания в каждом по 20 сата портов.
хорошо так и оставлю 1.2 гб за 6 минутную серию аниме в 1080п, не ну что зачем мне экономить место и возиться с этиси кодеками и настройка, просто увеличу место, у меня же корпус бесконечный и три блока питания в каждом по 20 сата портов.
>>652226 (OP)
Есть видеодорожка анимации с ютуба, хочу ровно по кадрам вырезать одну её часть. В картинки извлечь получилось, нужный диапазон кадров знаю. Хочу сделать это без перекодирования — MP4 (libdav1d) —> AVIF (libdav1d). Это реально?
Есть видеодорожка анимации с ютуба, хочу ровно по кадрам вырезать одну её часть. В картинки извлечь получилось, нужный диапазон кадров знаю. Хочу сделать это без перекодирования — MP4 (libdav1d) —> AVIF (libdav1d). Это реально?
>>696533
MP4 это видеоконтейнер, AVIF это формат хранения изображений. Очевидно нет, нельзя.
MP4 это видеоконтейнер, AVIF это формат хранения изображений. Очевидно нет, нельзя.
>>696533
Да, это реально. Поскольку и ваш исходный MP4 (AV1), и целевой AVIF используют один и тот же стандарт сжатия (AV1), вы можете просто перенести видеопоток в новый контейнер без перекодировки (remuxing).
Однако при работе «по кадрам» без перекодировки есть нюанс: обрезка возможна только по ключевым кадрам (I-frames).
Как это сделать:
Если нужно вырезать один кадр (статичный AVIF):
Убедитесь, что выбранный кадр является ключевым. Если это так, используйте команду:
ffmpeg -ss [время_или_номер] -i input.mp4 -frames:v 1 -c:v copy output.avif.
Если нужно вырезать диапазон (анимированный AVIF):
ffmpeg -ss [старт] -to [конец] -i input.mp4 -c:v copy output.avif.
Важно: Если вы начнете резку не с ключевого кадра, плееры могут отображать черный экран или артефакты до первого встреченного ключевого кадра.
Если нужно чтобы каждый кадр был отдельным изображением:
ffmpeg -ss [старт] -to [конец] -i input.mp4 -c:v copy output-%04d.avif
Да, это реально. Поскольку и ваш исходный MP4 (AV1), и целевой AVIF используют один и тот же стандарт сжатия (AV1), вы можете просто перенести видеопоток в новый контейнер без перекодировки (remuxing).
Однако при работе «по кадрам» без перекодировки есть нюанс: обрезка возможна только по ключевым кадрам (I-frames).
Как это сделать:
Если нужно вырезать один кадр (статичный AVIF):
Убедитесь, что выбранный кадр является ключевым. Если это так, используйте команду:
ffmpeg -ss [время_или_номер] -i input.mp4 -frames:v 1 -c:v copy output.avif.
Если нужно вырезать диапазон (анимированный AVIF):
ffmpeg -ss [старт] -to [конец] -i input.mp4 -c:v copy output.avif.
Важно: Если вы начнете резку не с ключевого кадра, плееры могут отображать черный экран или артефакты до первого встреченного ключевого кадра.
Если нужно чтобы каждый кадр был отдельным изображением:
ffmpeg -ss [старт] -to [конец] -i input.mp4 -c:v copy output-%04d.avif
>>696172
Именно, знать что-то не равно понимать и применять на практике.
Именно, знать что-то не равно понимать и применять на практике.
Требуется пояснение, почему разные файлы с одинаковой битностью сжимаются по разному? Неужели проблема в количестве кадров?
>>696909
Хуй знает о чём ты говоришь. Спрашивай нейросетку такие тупые вопросы.
> разные файлы
> сжимаются по разному
Хуй знает о чём ты говоришь. Спрашивай нейросетку такие тупые вопросы.
>>696909
Слишком много лишней информации на скриншотах и в тексте твоего поста, обрежь ещё сильнее картинки, а текст сократи до одного предложения в 30 символов. Чтобы уж точно было интересно разгадывать загадку-шизофазию, экструдированную из твоего пропитого стекломоем рта.
Слишком много лишней информации на скриншотах и в тексте твоего поста, обрежь ещё сильнее картинки, а текст сократи до одного предложения в 30 символов. Чтобы уж точно было интересно разгадывать загадку-шизофазию, экструдированную из твоего пропитого стекломоем рта.
>>696954
Либо ты даёшь нормальные вводные, с хотя бы двумя этими разными файлами, либо идёшь нахуй как жирное дерьмо
Либо ты даёшь нормальные вводные, с хотя бы двумя этими разными файлами, либо идёшь нахуй как жирное дерьмо
>>696909
такой ответ устроит? или ты не можкшь связать две взаимосвязанные вещи?
>разные файлы
>количестве кадров
такой ответ устроит? или ты не можкшь связать две взаимосвязанные вещи?
Организация Alliance for Open Media, известная по созданию видеоформатов AV1 и AV2, а также формата изображений AVIF, приступила к созданию нового открытого звукового кодека. Проект получил название Open Audio Codec или сокращенно OAC. Данная технология позиционируется как прямое развитие популярного формата Opus от организации Xiph.Org. В качестве эталонной реализации разработчики представили библиотеку liboac, которая базируется на исходном коде libopus и распространяется под свободной лицензией BSD.
Главная цель OAC заключается в качественной передаче звука и речи через интернет. Кодек отлично подходит для интерактивных задач, включая голосовую связь, видеоконференции, игровые чаты и удаленные музыкальные трансляции. Формат легко масштабируется, позволяя сжимать как высококачественную стереомузыку с высоким битрейтом, так и обычный голос в условиях ограниченной пропускной способности сети.
На данный момент проект находится на ранней стадии разработки. Создаваемый библиотекой битовый поток пока не рекомендуется использовать для распространения файлов, поскольку он содержит отладочную информацию и временно не поддерживает перемотку. Технические характеристики OAC во многом наследуют базовые возможности Opus версии 1.5. Новый кодек поддерживает битрейт от 6 до 510 килобит в секунду, частоту дискретизации от 8 до 48 килогерц и продолжительность кадров от 2.5 до 60 миллисекунд. Кроме того, реализована поддержка постоянного и переменного битрейта, работа с количеством каналов вплоть до 255, а также возможность кодирования как узкополосного, так и широкополосного звука. Разработчики предусмотрели алгоритмы восстановления звукового потока при потере пакетов данных и поддержку вычислений с плавающей и фиксированной запятой.
https://www.opennet.ru/opennews/art.shtml?num=64852
Главная цель OAC заключается в качественной передаче звука и речи через интернет. Кодек отлично подходит для интерактивных задач, включая голосовую связь, видеоконференции, игровые чаты и удаленные музыкальные трансляции. Формат легко масштабируется, позволяя сжимать как высококачественную стереомузыку с высоким битрейтом, так и обычный голос в условиях ограниченной пропускной способности сети.
На данный момент проект находится на ранней стадии разработки. Создаваемый библиотекой битовый поток пока не рекомендуется использовать для распространения файлов, поскольку он содержит отладочную информацию и временно не поддерживает перемотку. Технические характеристики OAC во многом наследуют базовые возможности Opus версии 1.5. Новый кодек поддерживает битрейт от 6 до 510 килобит в секунду, частоту дискретизации от 8 до 48 килогерц и продолжительность кадров от 2.5 до 60 миллисекунд. Кроме того, реализована поддержка постоянного и переменного битрейта, работа с количеством каналов вплоть до 255, а также возможность кодирования как узкополосного, так и широкополосного звука. Разработчики предусмотрели алгоритмы восстановления звукового потока при потере пакетов данных и поддержку вычислений с плавающей и фиксированной запятой.
https://www.opennet.ru/opennews/art.shtml?num=64852
>>697543
Просто вот эти диапазоны
точь-в-точь как у опуса, в сочетании с
наводит на подозрение что поелозят напильником, подвигают ползунки и назначат готовым без каких-либо фундаментальных изменений. А в опусе 44100, 22050, 11025 - нет, и это по словам разработчиков by design, мол мы супер-дупер разоптимизировали под 48000, остальное ненужно, ебитесь как хотите.
Просто вот эти диапазоны
> битрейт от 6 до 510 килобит в секунду
> частоту дискретизации от 8 до 48 килогерц
точь-в-точь как у опуса, в сочетании с
> как прямое развитие популярного формата Opus
> во многом наследуют базовые возможности Opus версии 1.5.
наводит на подозрение что поелозят напильником, подвигают ползунки и назначат готовым без каких-либо фундаментальных изменений. А в опусе 44100, 22050, 11025 - нет, и это по словам разработчиков by design, мол мы супер-дупер разоптимизировали под 48000, остальное ненужно, ебитесь как хотите.
>>697551
Для меня - да. Вопрос был - жать ли музяку для экономии места в опус. Ну и ответ поэтому вышел - нет, потому что музяка выходила сто лет в 44100, да сейчас значимая часть выходит, а задирать битрейт чтобы скомпенсировать потери на ресэмпле - не шибко много наэкономишь. Когда я это решал еще и поддержка опуса была далеко не везде.
Для меня - да. Вопрос был - жать ли музяку для экономии места в опус. Ну и ответ поэтому вышел - нет, потому что музяка выходила сто лет в 44100, да сейчас значимая часть выходит, а задирать битрейт чтобы скомпенсировать потери на ресэмпле - не шибко много наэкономишь. Когда я это решал еще и поддержка опуса была далеко не везде.
>>697593
Шо за хуйню я читаю. Во-первых, битрейт ортогонален сэмплрейту, потому что кодек всё делает в спектральной области. Если он, условно, видит две синусоиды, он их кодирует как две синусоиды независимо от того, в каком они сэмплрейте. Сэмплрейт в спектральной области это лишь масштабирующий коэффициент на шкале частот. Во-вторых, ресэмпл ты один хуй делаешь, но только если ты делаешь его при кодировании, то ты делаешь его один раз и без спешки, а если ты делаешь его при прослушивании, то ты его делаешь при каждом прослушивании и в риал тайме, т.е. более быстрыми = более грубыми алгоримами.
>задирать битрейт чтобы скомпенсировать потери на ресэмпле
Шо за хуйню я читаю. Во-первых, битрейт ортогонален сэмплрейту, потому что кодек всё делает в спектральной области. Если он, условно, видит две синусоиды, он их кодирует как две синусоиды независимо от того, в каком они сэмплрейте. Сэмплрейт в спектральной области это лишь масштабирующий коэффициент на шкале частот. Во-вторых, ресэмпл ты один хуй делаешь, но только если ты делаешь его при кодировании, то ты делаешь его один раз и без спешки, а если ты делаешь его при прослушивании, то ты его делаешь при каждом прослушивании и в риал тайме, т.е. более быстрыми = более грубыми алгоримами.
20 Кб, 669x474>>697637
Кодек получает синсоиду на сжатие после ресэмпла - а значит уже с потерями. Невыжно как он ее воспринимает теперь - она уже искажена.
Схуя ли?
Кодек получает синсоиду на сжатие после ресэмпла - а значит уже с потерями. Невыжно как он ее воспринимает теперь - она уже искажена.
> ресэмпл ты один хуй делаешь
Схуя ли?
>>697643
Значение имеет не эта менюшка, а какой кварц к ЦАПу припаян. ЦАПы под капотом тоже умеют делать ресэмплинг.
Ресэмплинг в теории можно сделать сколь угодно близким к идеалу. А на практике — настолько близким, чтобы выход алгоритма кодирования совпадал для обоих вариантов бит в бит. И ровно для этого и имеет смысл делать ресэмплинг не на лету, а заранее.
Значение имеет не эта менюшка, а какой кварц к ЦАПу припаян. ЦАПы под капотом тоже умеют делать ресэмплинг.
>Кодек получает синсоиду на сжатие после ресэмпла - а значит уже с потерями.
Ресэмплинг в теории можно сделать сколь угодно близким к идеалу. А на практике — настолько близким, чтобы выход алгоритма кодирования совпадал для обоих вариантов бит в бит. И ровно для этого и имеет смысл делать ресэмплинг не на лету, а заранее.
при слепых тестах 99% испытуемых считают 128кб vbr opus - практически неотличимым от flac оригинала / прозрачным. даже если повышать битрейт до 192 или 256, в итоге файл всё равно будет весить меньше аналогов.
>>697664
а при глухих тестах?
а при глухих тестах?
Вопрос не по теме треда, но спрошу здесь.
Вот на ютубе есть функция ускорения видео. При этом, звук не становится хай-питч, как при ускорении в обычном плеере. Собственно, а можно ли в MPC или ином видеоплеере добавить такую же функцию? По какому принципу это вообще реализовано?
Вот на ютубе есть функция ускорения видео. При этом, звук не становится хай-питч, как при ускорении в обычном плеере. Собственно, а можно ли в MPC или ином видеоплеере добавить такую же функцию? По какому принципу это вообще реализовано?
>>697666
Оконное преобразование Фурье. Сначала прямое, потом делают окна шире/реже или чаще/уже, и обратное.
>По какому принципу это вообще реализовано?
Оконное преобразование Фурье. Сначала прямое, потом делают окна шире/реже или чаще/уже, и обратное.
108 Кб, 644x335>>697676
Да ничё сложного, спектрограммы видел когда-нибудь? Вот делают сначала из аудиодорожки спектрограмму, потом сжимают её во времени или растягивают, чтобы частоты при этом никуда не съезжали, потом обратно превращают в звук.
Да ничё сложного, спектрограммы видел когда-нибудь? Вот делают сначала из аудиодорожки спектрограмму, потом сжимают её во времени или растягивают, чтобы частоты при этом никуда не съезжали, потом обратно превращают в звук.
>>697593
Потому что опус не для этого, дегенерат.
Он именно для речи и для передачи по сети задуман и заточен, поэтому там никаким тюнингом ни под хранение, ни под музыкальную индустрию и не пахнет. Зато почти реалтайм – а тебе это на кой чёрт?
Ну и этот новый опус ровно туда же двигается.
>жать ли музяку для экономии места в опус. Ну и ответ поэтому вышел - нет, потому что
Потому что опус не для этого, дегенерат.
Он именно для речи и для передачи по сети задуман и заточен, поэтому там никаким тюнингом ни под хранение, ни под музыкальную индустрию и не пахнет. Зато почти реалтайм – а тебе это на кой чёрт?
Ну и этот новый опус ровно туда же двигается.
>>697714
Для хранения – вообще что хочешь.
Любая эзотерическая хуйня, тебе же не надо чтобы кто-то кроме тебя это умел воспроизводить.
Vorbis наверное, но хуй знает точно. Я бы ёбнул пару треков конкретно твоих хотя бы в Vorbis, AAC, AC3, AVS2 и посмотрел.
Помимо AAC у MPEG ещё дохуя разных кодеков ебал в рот их номенклатуру да и у самого AAC уровней тоже хватает.
Для хранения – вообще что хочешь.
Любая эзотерическая хуйня, тебе же не надо чтобы кто-то кроме тебя это умел воспроизводить.
Vorbis наверное, но хуй знает точно. Я бы ёбнул пару треков конкретно твоих хотя бы в Vorbis, AAC, AC3, AVS2 и посмотрел.
Помимо AAC у MPEG ещё дохуя разных кодеков ебал в рот их номенклатуру да и у самого AAC уровней тоже хватает.
>>697664
Аас тоже кста.
Аас тоже кста.
>>697666
Time stretch.
Time stretch.
>>697726
А если электронная музыка?
А если электронная музыка?
>>697704
Ты бы не охладил траханье, углепластик?
На их собственном оффсайте
Так что не пизди тут.
> Потому что опус не для этого, дегенерат.
Ты бы не охладил траханье, углепластик?
На их собственном оффсайте
> It can scale from low bitrate narrowband speech to very high quality stereo music.
Так что не пизди тут.
>>697796
Дальше что?
>Opus Interactive Audio Codec
>Overview
>
>Opus is a totally open, royalty-free, highly versatile audio codec. Opus is unmatched for interactive speech and music transmission over the Internet, but is also intended for storage and streaming applications. It is standardized by the Internet Engineering Task Force (IETF) as RFC 6716 which incorporated technology from Skype’s SILK codec and Xiph.Org’s CELT codec.
>Technology
>
>Opus can handle a wide range of audio applications, including Voice over IP, videoconferencing, in-game chat, and even remote live music performances. It can scale from low bitrate narrowband speech to very high quality stereo music. Supported features are:
>
> Bitrates from 6 kb/s to 510 kb/s
> Sampling rates from 8 kHz (narrowband) to 48 kHz (fullband)
> Frame sizes from 2.5 ms to 60 ms
> Support for both constant bitrate (CBR) and variable bitrate (VBR)
> Audio bandwidth from narrowband to fullband
> Support for speech and music
> Support for mono and stereo
> Support for up to 255 channels (multistream frames)
> Dynamically adjustable bitrate, audio bandwidth, and frame size
> Good loss robustness and packet loss concealment (PLC)
> Floating point and fixed-point implementation
>
>You can read the full specification, including the reference implementation, in RFC 6716. An up-to-date implementation of the Opus standard is also available from the downloads page.
Дальше что?
Opus — это свободный аудиокодек с высокой степенью сжатия, созданный для универсального использования в интернете.
История:
Разработан в 2012 году организацией IETF (Инженерный совет интернета) в результате слияния двух кодеков: SILK (от Skype) для речи и CELT (от Xiph.Org) для музыки. Это объединение позволило ему одинаково хорошо работать с любым типом звука. В 2017 году он стал обязательным стандартом для браузеров и WebRTC (технологии потоковой передачи).
Предназначение (ключевые особенности):
1. Универсальность: Заменяет сразу несколько кодеков (MP3, AAC, Speex). Одинаково эффективно сжимает как человеческий голос (от 6 кбит/с), так и сложную музыку (до 510 кбит/с).
2. Низкая задержка: Идеален для стриминга, видеозвонков и онлайн-игр, так как имеет минимальную задержку при кодировании.
3. Открытость и бесплатность: В отличие от MP3 или AAC, за его использование не нужно платить лицензионные отчисления (патенты), поэтому он широко поддерживается всеми браузерами и приложениями (Discord, Spotify, YouTube).
История:
Разработан в 2012 году организацией IETF (Инженерный совет интернета) в результате слияния двух кодеков: SILK (от Skype) для речи и CELT (от Xiph.Org) для музыки. Это объединение позволило ему одинаково хорошо работать с любым типом звука. В 2017 году он стал обязательным стандартом для браузеров и WebRTC (технологии потоковой передачи).
Предназначение (ключевые особенности):
1. Универсальность: Заменяет сразу несколько кодеков (MP3, AAC, Speex). Одинаково эффективно сжимает как человеческий голос (от 6 кбит/с), так и сложную музыку (до 510 кбит/с).
2. Низкая задержка: Идеален для стриминга, видеозвонков и онлайн-игр, так как имеет минимальную задержку при кодировании.
3. Открытость и бесплатность: В отличие от MP3 или AAC, за его использование не нужно платить лицензионные отчисления (патенты), поэтому он широко поддерживается всеми браузерами и приложениями (Discord, Spotify, YouTube).
26 Кб, 851x346>>697817
>>697795
>>697800
>>697796
>>697795
>>697704
>>697593
>>697545
Дауны, о чём вы спорите?
По аудио форматам всё давно разжёвано:
https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio
Для музыки 320-500 кбит/с - лучше всего ogg (libvorbis).
Для всего остального - opus. Его единственный реальный недостаток - срез на 20 кГц, даже на высоких битрейтах.
По своему опыту - я за огг, потому что он древний, как говно мамонта, и поддерживается многими аппаратными плеерами, тв-приставками и т.п. (даже с битрейтом 500 кбит/с), в отличие от опуса, поддержка которого распространёна лишь на компах и смартфонах.
>>697795
>>697800
>>697796
>>697795
>>697704
>>697593
>>697545
Дауны, о чём вы спорите?
По аудио форматам всё давно разжёвано:
https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio
Для музыки 320-500 кбит/с - лучше всего ogg (libvorbis).
Для всего остального - opus. Его единственный реальный недостаток - срез на 20 кГц, даже на высоких битрейтах.
По своему опыту - я за огг, потому что он древний, как говно мамонта, и поддерживается многими аппаратными плеерами, тв-приставками и т.п. (даже с битрейтом 500 кбит/с), в отличие от опуса, поддержка которого распространёна лишь на компах и смартфонах.
>>694663
Мне кажется, если у него анимцо и задача в 3-5 раз ужать, то hevc (libx265) -preset medium -tune animation -crf по вкусу - норм решение.
Мне кажется, если у него анимцо и задача в 3-5 раз ужать, то hevc (libx265) -preset medium -tune animation -crf по вкусу - норм решение.
>>697880
Так частоты выше 20 кГц не воспринимаются человеком же. Зачем они тебе? Или это какая то аудиофильская приколюха типо даже если частоты не слышишь они всё равно могут как то влиять на прослушивание?
>срез на 20 кГц
Так частоты выше 20 кГц не воспринимаются человеком же. Зачем они тебе? Или это какая то аудиофильская приколюха типо даже если частоты не слышишь они всё равно могут как то влиять на прослушивание?
>>697910
Так и разницу между 128 и 320+ кбит/с не слышно. Зачем тебе такой высокий битрейт?
Так и разницу между 128 и 320+ кбит/с не слышно. Зачем тебе такой высокий битрейт?
>>697922
На opus? мне слышно, у меня хороший слух и наушники, хотя конечно не супер студийное оборудование ценой в квартиру. лично я храню в opus 256vbr, конвертируя flac в opus в foobar2000 через актуальную версию opus энкодера, с настройками --vbr --bitrate 256 --comp 10 --expect-loss 0 --ignorelength - %d. lossy и 32-bit float. ещё на всякий advanced limiter и resampler (dbpoweramp/ssrc) на 48к hz
На opus? мне слышно, у меня хороший слух и наушники, хотя конечно не супер студийное оборудование ценой в квартиру. лично я храню в opus 256vbr, конвертируя flac в opus в foobar2000 через актуальную версию opus энкодера, с настройками --vbr --bitrate 256 --comp 10 --expect-loss 0 --ignorelength - %d. lossy и 32-bit float. ещё на всякий advanced limiter и resampler (dbpoweramp/ssrc) на 48к hz
>>697880
Это достоинство. Это означает, что психоакустическая модель опуса сделана по науке, а не по чьей-то магической шизе.
>Его единственный реальный недостаток - срез на 20 кГц
Это достоинство. Это означает, что психоакустическая модель опуса сделана по науке, а не по чьей-то магической шизе.
27 Кб, mp4,1920x1080, 0:05
Генерируем тестовую таблицу с помощью ffmpeg.
ffmpeg -f lavfi -i smptebars=s=1920x1080 -c:v libx265 -pix_fmt yuv420p10le -x265-params "hdr10=1:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1):max-cll=1000,400:atc=16" -to 5 -y output_1000nits_smptebars.mkv
ffmpeg -f lavfi -i smptebars=s=1920x1080 -c:v libx265 -pix_fmt yuv420p10le -x265-params "hdr10=1:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1):max-cll=1000,400:atc=16" -to 5 -y output_1000nits_smptebars.mkv
>>697935
>>697924
Если говорить про битрейты 320+, то они и так дают чрезмерное качество, не отличимое от 192-256. Когда на 500 кбит/с срезаются 20 кГц - это и есть шиза. На таком битрейте нет проблемы сохранить 20-22 кГц. Да, разницы на слух всё-равно не будет, но тем не менее. Если битрейт не далёк от лосося, то и смысла ужиматься по частотам нет никакого. По статусу не положено, как говорится. Качество и так запредельное.
>>697924
Если говорить про битрейты 320+, то они и так дают чрезмерное качество, не отличимое от 192-256. Когда на 500 кбит/с срезаются 20 кГц - это и есть шиза. На таком битрейте нет проблемы сохранить 20-22 кГц. Да, разницы на слух всё-равно не будет, но тем не менее. Если битрейт не далёк от лосося, то и смысла ужиматься по частотам нет никакого. По статусу не положено, как говорится. Качество и так запредельное.
47 Кб, 450x639>>697986
Какой впечатляющий поток отборной шизы.
>Да, разницы на слух всё-равно не будет, но тем не менее. Если битрейт не далёк от лосося, то и смысла ужиматься по частотам нет никакого. По статусу не положено, как говорится. Качество и так запредельное.
Какой впечатляющий поток отборной шизы.
>>697880
"libopus"- Usable range ≥ 32 Kbps. Recommended range ≥ 64 Kbps.
Transparency (music): Very close at default (96 Kbps), but takes more (160+) to be real transparent.
Transparency (speech): ~ 32 Kbps.
Опус намного лучше.
"libopus"- Usable range ≥ 32 Kbps. Recommended range ≥ 64 Kbps.
Transparency (music): Very close at default (96 Kbps), but takes more (160+) to be real transparent.
Transparency (speech): ~ 32 Kbps.
Опус намного лучше.
>>698014
Я в слепом тесте разницы не услышал в мп3 между 320 и 192 на сложном треке с кучей высоких частот. Тесты были на e-mu 0204 и сенхах 598. Че уж говорить про более лучшие форматы как аас и опус.
Я в слепом тесте разницы не услышал в мп3 между 320 и 192 на сложном треке с кучей высоких частот. Тесты были на e-mu 0204 и сенхах 598. Че уж говорить про более лучшие форматы как аас и опус.
>>698017
Задача кодека жать аудио в соответствии с психоакустической моделью, а не удовлетворять твои представления о прекрасном. Это помимо прочего ещё и бессмысленно, сегодня тебе надо чтобы на выходе кодека были частоты >20кГц, а завтра чтобы на спектрограмме рисовались хуи.
Задача кодека жать аудио в соответствии с психоакустической моделью, а не удовлетворять твои представления о прекрасном. Это помимо прочего ещё и бессмысленно, сегодня тебе надо чтобы на выходе кодека были частоты >20кГц, а завтра чтобы на спектрограмме рисовались хуи.
Вот у меня лежат два файла, выкачанные с ютуба. Кодек, разумеется, OPUS.
Размер на диске 8 и 9 мб
Они же во FLAC занимают 21 и 25 мб.
Размер на диске 8 и 9 мб
Они же во FLAC занимают 21 и 25 мб.
2 Кб, 514x94>>698014
>>698017
>>698061
Да вы тут все шизики. Лично я про форматы с потерями забыл ещё в 2010 году, когда со стипендии купил себе винт аж на 1 ТБ. Тогда же перестал записывать на двд и сд. С тех пор вся музыка во флаке, теперь даже на смартфоне (256 ГБ + 1 ТБ сд карта). Сейчас у меня вся фонотека (80+% которой я практически не слушаю) - жалкие 1.8 ТБ, при доступных 14 ТБ. В подтверждение того, что я давно практикующий меломан, прилагаю счётчик фубара за последние ~15 лет.
В общем, в 2026 году не вижу ни малейшего смысла хранить музыку в лосси форматах. Разве что вы совсем уж отмороженные шизики-архиваторы, которым надо скачать и хранить ВСЮ музыку, 99+% которой вы ни разу не прослушаете.
Кстати, фильмы и сериалы на компе давно не храню, потому что за годы осознал, что повторно ничего не пересматриваю. Посему - скачал-посмотрел-удалил. Храню только музыку (концертники), но объём тоже смешной, ~800 ГБ.
>>698017
>>698061
Да вы тут все шизики. Лично я про форматы с потерями забыл ещё в 2010 году, когда со стипендии купил себе винт аж на 1 ТБ. Тогда же перестал записывать на двд и сд. С тех пор вся музыка во флаке, теперь даже на смартфоне (256 ГБ + 1 ТБ сд карта). Сейчас у меня вся фонотека (80+% которой я практически не слушаю) - жалкие 1.8 ТБ, при доступных 14 ТБ. В подтверждение того, что я давно практикующий меломан, прилагаю счётчик фубара за последние ~15 лет.
В общем, в 2026 году не вижу ни малейшего смысла хранить музыку в лосси форматах. Разве что вы совсем уж отмороженные шизики-архиваторы, которым надо скачать и хранить ВСЮ музыку, 99+% которой вы ни разу не прослушаете.
Кстати, фильмы и сериалы на компе давно не храню, потому что за годы осознал, что повторно ничего не пересматриваю. Посему - скачал-посмотрел-удалил. Храню только музыку (концертники), но объём тоже смешной, ~800 ГБ.
>>698077
Двачаю, вон на двух файлах выше - так везде, разница ну в три раза. Размер станет заметен, если пытаешься сохранить всю музыку мира.
Двачаю, вон на двух файлах выше - так везде, разница ну в три раза. Размер станет заметен, если пытаешься сохранить всю музыку мира.
>>698077
А бэкап? Когда он у тебя сдохнет - локти будешь кусать. У меня коллекция в 2х бэкапах.
А бэкап? Когда он у тебя сдохнет - локти будешь кусать. У меня коллекция в 2х бэкапах.
>>698077
У меня во флак только своя музыка, которую я написал, остальное - мп3, аас, огг и т.д.
У меня во флак только своя музыка, которую я написал, остальное - мп3, аас, огг и т.д.
>>698084
А, не, 332 kb/s. Чет плеер гонит мой. Но все равно 96 кб\с уже в 3 раза меньше, чем 320. Итого выйдет раз в 10 сохранение размера с таким же качеством.
А, не, 332 kb/s. Чет плеер гонит мой. Но все равно 96 кб\с уже в 3 раза меньше, чем 320. Итого выйдет раз в 10 сохранение размера с таким же качеством.
Так что терабайт или 100гб? Ощутимо? Еще как.
>>698080
Тебе сколько лет, мальчик? С годами всякое дерьмо начинается (работа, семья). Последние 8-10 лет если удаётся вечерком хоть час послушать музыку дома, сидя перед компом - это прям в диковинку. А так - смартфон+автомобиль.
>>698082
Нашёл кому рассказывать. В шкафу винтов на ~20 ТБ, не считая всякий антиквариат.
Тебе сколько лет, мальчик? С годами всякое дерьмо начинается (работа, семья). Последние 8-10 лет если удаётся вечерком хоть час послушать музыку дома, сидя перед компом - это прям в диковинку. А так - смартфон+автомобиль.
>>698082
Нашёл кому рассказывать. В шкафу винтов на ~20 ТБ, не считая всякий антиквариат.
>>698089
А у меня ток 3.5 где-то. И большая часть забита проном. Не могу себе позволить так раскидываться местом.
>В шкафу винтов на ~20 ТБ,
А у меня ток 3.5 где-то. И большая часть забита проном. Не могу себе позволить так раскидываться местом.
>>698090
Это остатки роскоши со старой РАБоты. Из списанных компов надёргал больше 100 кг железа, в т.ч. винтов.
Это остатки роскоши со старой РАБоты. Из списанных компов надёргал больше 100 кг железа, в т.ч. винтов.
16 Кб, 544x380>>698061
Что не так с частотой >20кГц?
Допустим формат у тебя по факту имеет 22050 Гц, то есть семплы выплевываются с частотой 44100 Гц.
Допустим, в оригинале был простой сигнал в 16 бит, сначала шли все нулевые семплы, потом с какого-то момента все 30000 пошли. То есть фронт прямой и резкий.
Теперь ты берешь и фильтруешь, отсекаешь все что выше 20кГц нахер. Что получается на выходе? Получается фронт не резкий, а размазанный. На семплах будет гребенка возле фронта.
>сегодня тебе надо чтобы на выходе кодека были частоты >20кГц
Что не так с частотой >20кГц?
Допустим формат у тебя по факту имеет 22050 Гц, то есть семплы выплевываются с частотой 44100 Гц.
Допустим, в оригинале был простой сигнал в 16 бит, сначала шли все нулевые семплы, потом с какого-то момента все 30000 пошли. То есть фронт прямой и резкий.
Теперь ты берешь и фильтруешь, отсекаешь все что выше 20кГц нахер. Что получается на выходе? Получается фронт не резкий, а размазанный. На семплах будет гребенка возле фронта.
>>697910
Да. Ты их сами частоты не слышишь. Но они влияют на слышимые частоты. Вдобавок, косвенно они ощутимы и придают звуку настоящети.
>Или это какая то аудиофильская приколюха типо даже если частоты не слышишь они всё равно могут как то влиять на прослушивание?
Да. Ты их сами частоты не слышишь. Но они влияют на слышимые частоты. Вдобавок, косвенно они ощутимы и придают звуку настоящети.
>>698164
У тебя динамик не идеальный. Такой резкий щелчок породит на нём точно такой же переходный процесс (и ты его точно так же не услышишь).
> сначала шли все нулевые семплы, потом с какого-то момента все 30000 пошли
У тебя динамик не идеальный. Такой резкий щелчок породит на нём точно такой же переходный процесс (и ты его точно так же не услышишь).
1,2 Мб, 1032x1212>>698164
Ты просто недоучка, который думает, что цифровой звук восстанавливается ступеньками. У нормальных пацанов цифровой сигнал типа "0, 0, 0, 0, 30000, 30000, 30000, ..." будет точно так же восстановлен с гребёнками и заваленным фронтом, потому что матан предписывает так его восстанавливать. У тебя будет на 0.01% более частая гребёнка и на 0.01% менее заваленный фронт, так это и работает.
Но ты эти 0.01% не услышишь, потому что мочёные не зря определили 20кГц как физиологический потолок слуха.
>>698174
По сути верно, но с уточнением, что этот переходный процесс возникнет даже до динамика, ещё на выходе ЦАПа.
>>698175
Не нужно. А вот идеальную ступеньку — нужно, потому что у идеальной ступеньки бесконечно широкий спектр.
>Допустим, в оригинале был простой сигнал в 16 бит, сначала шли все нулевые семплы, потом с какого-то момента все 30000 пошли. То есть фронт прямой и резкий. Теперь ты берешь и фильтруешь, отсекаешь все что выше 20кГц нахер. Что получается на выходе? Получается фронт не резкий, а размазанный. На семплах будет гребенка возле фронта.
Ты просто недоучка, который думает, что цифровой звук восстанавливается ступеньками. У нормальных пацанов цифровой сигнал типа "0, 0, 0, 0, 30000, 30000, 30000, ..." будет точно так же восстановлен с гребёнками и заваленным фронтом, потому что матан предписывает так его восстанавливать. У тебя будет на 0.01% более частая гребёнка и на 0.01% менее заваленный фронт, так это и работает.
Но ты эти 0.01% не услышишь, потому что мочёные не зря определили 20кГц как физиологический потолок слуха.
>>698174
По сути верно, но с уточнением, что этот переходный процесс возникнет даже до динамика, ещё на выходе ЦАПа.
>>698175
Не нужно. А вот идеальную ступеньку — нужно, потому что у идеальной ступеньки бесконечно широкий спектр.
>>698174
Да даже на мелких, но хороших, динамиках слышу что FLAC более трескучий чем MP3.
Да даже на мелких, но хороших, динамиках слышу что FLAC более трескучий чем MP3.
>>698181
Не, такое возможно, если в системе существует нелинейность. Но это лишь означает, что надо не больше частот покупать, а больше линейности.
Не, такое возможно, если в системе существует нелинейность. Но это лишь означает, что надо не больше частот покупать, а больше линейности.
>>698184
Ты не то сравниваешь. Сравнивай flac 44100 c фильтром 20кГц и без фильтра. Тогда это будет иметь отношение к разговору о слышимой полосе частот.
Ты не то сравниваешь. Сравнивай flac 44100 c фильтром 20кГц и без фильтра. Тогда это будет иметь отношение к разговору о слышимой полосе частот.
>>698178
Если у тебя формат внутри своего устройства ограничен верхней планкой 20k то не нужно, а если 22050 или больше, то нужно.
Если восстанавливать в повышенную частоту дискретизации, то нужны гребенки. Если если в аудиосистеме такая же частота, что и в формате, то нелинейные искажения только в аналоге будут от переходных процессов, а в цифре такой же сигнал.
>Не нужно. А вот идеальную ступеньку — нужно, потому что у идеальной ступеньки бесконечно широкий спектр.
Если у тебя формат внутри своего устройства ограничен верхней планкой 20k то не нужно, а если 22050 или больше, то нужно.
>У нормальных пацанов цифровой сигнал типа "0, 0, 0, 0, 30000, 30000, 30000, ..." будет точно так же восстановлен с гребёнками и заваленным фронтом, потому что матан предписывает так его восстанавливать.
Если восстанавливать в повышенную частоту дискретизации, то нужны гребенки. Если если в аудиосистеме такая же частота, что и в формате, то нелинейные искажения только в аналоге будут от переходных процессов, а в цифре такой же сигнал.
>>698187
Точно, надо попробовать. Вдруг это FLAC раскодируется с ошибками (без среза частот >20k хех мда).
Точно, надо попробовать. Вдруг это FLAC раскодируется с ошибками (без среза частот >20k хех мда).
37 Кб, 942x445>>698164
Хоть он и шиз, но и ты тоже пишешь хуйню.
На выходе любого ЦАПа стоит активный фильтр на ОУ, который подавляет всё что выше 20 кГц. Да, даже если ты пытаешься воспроизвести 96/192 кГц на канал. Обычно частота среза ~50 кГц, при этом в районе 20 кГц начинается спад в пределах -0.1 дб. Большинство производителей ЦАПов приводят рекомендуемый дизайн фильтра в даташитах, либо аппнотах. Пикрилейтед - из даташита CS4398. Кроме того, реальная конечная нагрузка (динамик/капсюль) обладает большим реактансом, и чистый меандр ты ну никак не получишь. Конечно, можно согласовать выходное сопротивление, но только для конкретной частоты.
Хоть он и шиз, но и ты тоже пишешь хуйню.
На выходе любого ЦАПа стоит активный фильтр на ОУ, который подавляет всё что выше 20 кГц. Да, даже если ты пытаешься воспроизвести 96/192 кГц на канал. Обычно частота среза ~50 кГц, при этом в районе 20 кГц начинается спад в пределах -0.1 дб. Большинство производителей ЦАПов приводят рекомендуемый дизайн фильтра в даташитах, либо аппнотах. Пикрилейтед - из даташита CS4398. Кроме того, реальная конечная нагрузка (динамик/капсюль) обладает большим реактансом, и чистый меандр ты ну никак не получишь. Конечно, можно согласовать выходное сопротивление, но только для конкретной частоты.
1,2 Мб, 1302x1842>>698190
Ты не понимаешь, как кодеки работают. Они сперва переводят всё в частоты, потом сжимают. И им гребёнка проще, потому что в ней меньше частот. То, что она для тебя более сложно выглядит, это только следствие твоего невежества.
Если восстанавливать идеально или хотя бы качественно, то нужны гребёнки. Чем дальше ты от гребёнок — тем дальше ты от корретно восстановленного аналогового сигнала.
Ещё раз, это матан так работает. По теореме отсчётов, существует только один способ восстановить сигнал из отсчётов, если он соответствует критерию Найквиста. Если ты от этого однозначного восстановлия отходишь — ты вносишь искажения в то, что содержится в цифровом представлении. И даже если тебе это кажется более "правильно", типа ступеньки более резкие — это только следствие твоего невежества, и никто с минимальными знаниями по теме в реальности так не делает.
>Если у тебя формат внутри своего устройства ограничен верхней планкой 20k то не нужно, а если 22050 или больше, то нужно.
Ты не понимаешь, как кодеки работают. Они сперва переводят всё в частоты, потом сжимают. И им гребёнка проще, потому что в ней меньше частот. То, что она для тебя более сложно выглядит, это только следствие твоего невежества.
>Если восстанавливать в повышенную частоту дискретизации, то нужны гребенки.
Если восстанавливать идеально или хотя бы качественно, то нужны гребёнки. Чем дальше ты от гребёнок — тем дальше ты от корретно восстановленного аналогового сигнала.
Ещё раз, это матан так работает. По теореме отсчётов, существует только один способ восстановить сигнал из отсчётов, если он соответствует критерию Найквиста. Если ты от этого однозначного восстановлия отходишь — ты вносишь искажения в то, что содержится в цифровом представлении. И даже если тебе это кажется более "правильно", типа ступеньки более резкие — это только следствие твоего невежества, и никто с минимальными знаниями по теме в реальности так не делает.
>>698202
Подключи прямо на выход ЦАПа спектроанализатор с полосой 1-10 МГц и попробуй сам догадаться.
>Нахрена такую подставу делать? Какой смысл?
Подключи прямо на выход ЦАПа спектроанализатор с полосой 1-10 МГц и попробуй сам догадаться.
>>698086
256кб/c vbr это слышимый предел для опуса даже если у тебя золотые уши. я тестил много и не заметил разнину с флаком. да я даже с 192кб vbr разницу только в 2 из 10 раз видел
256кб/c vbr это слышимый предел для опуса даже если у тебя золотые уши. я тестил много и не заметил разнину с флаком. да я даже с 192кб vbr разницу только в 2 из 10 раз видел
Чё то вы так opus и вообще все форматы засрали. Как будто ничего лучше musepack и не придумали
>>698233
Только собственные личные ансамбли, оркестры и композиторы играющие оригинальную музыку и любые высококлассные каверы в любом стиле по твоей просьбе, только хардкор.
Ну и тёплый, ламповый винил.
Только собственные личные ансамбли, оркестры и композиторы играющие оригинальную музыку и любые высококлассные каверы в любом стиле по твоей просьбе, только хардкор.
Ну и тёплый, ламповый винил.
>>698236
ну если лично я разницы не слышу, то стоит ли трястись? 256vbr опус мне за глаза. сколько пытался услышать разницу с флаком - не услышал. а вы сами решайте. musepack, vorbis, mp3 = устарели, форматы зомби. сейчас актуальны и обновляются только aac и opus, всё остальное lossless (а там только flac, ну и разве что WavPack и Monkey's но нахуя)
ну если лично я разницы не слышу, то стоит ли трястись? 256vbr опус мне за глаза. сколько пытался услышать разницу с флаком - не услышал. а вы сами решайте. musepack, vorbis, mp3 = устарели, форматы зомби. сейчас актуальны и обновляются только aac и opus, всё остальное lossless (а там только flac, ну и разве что WavPack и Monkey's но нахуя)
>>698237
Ну тупые, не то что некомпетентное диванное шизло с магическим мышлением вроде тебя.
Ну тупые, не то что некомпетентное диванное шизло с магическим мышлением вроде тебя.
13 Кб, 672x138>>698187
Сравнил. Разницы практически не слышу. Но как будто она есть. Видимо нужна топ аппаратура, чтобы понять.
>>698197
Ну вот я сжал во флак, оригинал и фильтровку. Фильтровка ужалась чуть хуже.
test это сгенерированные одиночные семплы 32767 через каждые четверть секунды
Сравнил. Разницы практически не слышу. Но как будто она есть. Видимо нужна топ аппаратура, чтобы понять.
>>698197
>Ты не понимаешь, как кодеки работают. Они сперва переводят всё в частоты, потом сжимают. И им гребёнка проще, потому что в ней меньше частот. То, что она для тебя более сложно выглядит, это только следствие твоего невежества.
Ну вот я сжал во флак, оригинал и фильтровку. Фильтровка ужалась чуть хуже.
test это сгенерированные одиночные семплы 32767 через каждые четверть секунды
>>698210
Вижу высокие частоты. Это для того чтобы плебеи их не слышали или для того что раз аппаратура говно, то нечаго наворачивать частот?
Вижу высокие частоты. Это для того чтобы плебеи их не слышали или для того что раз аппаратура говно, то нечаго наворачивать частот?
>>698328
Я про lossy-кодеки говорил. Надо было это уточнить, да. FLAC не использует психоакустическую модель и не раскладывает звук на частоты.
>Ну вот я сжал во флак
Я про lossy-кодеки говорил. Надо было это уточнить, да. FLAC не использует психоакустическую модель и не раскладывает звук на частоты.
Щас проверил диапазон частот, что я слышу своим слухом, на своей говноаппаратуре. Получилось примерно от 15 Гц, до 18000 Гц. У может до 19000 - что то там еле-еле меняется на пределе, если двигать головой перед динамиками.
Вывод такой. Что может что нибудь особенное будет ощущаться на >20кГц, но не на моей аппаратуре, точно.
Вывод такой. Что может что нибудь особенное будет ощущаться на >20кГц, но не на моей аппаратуре, точно.
>>698390
Если у тебя есть телефон, поставь на него Spectroid и посмотри спектр с микрофона, играя на колонки 21кГц (сэмплрейт поставь >48кГц, естественно). Увидишь, что твой динамик-пищалка эту частоту прекрасно играет, телефон её прекрасно слышит, а ты её не слышишь просто.
Если у тебя есть телефон, поставь на него Spectroid и посмотри спектр с микрофона, играя на колонки 21кГц (сэмплрейт поставь >48кГц, естественно). Увидишь, что твой динамик-пищалка эту частоту прекрасно играет, телефон её прекрасно слышит, а ты её не слышишь просто.
>>698425
А если лобные доли сформировались, то выше 16КГЦ
А если лобные доли сформировались, то выше 16КГЦ
>>698390
Вообще, то что осознанно не слышишь те частоты не значит что не воспринимаешь их совсем.
Попробуй вместо синусоиды музыку послушать в полном спектре и в обрезанном, скорее всего вслепую спокойно отличишь.
То же самое со светом, например. Близкие к видимому спектру ультрафиолет и инфракрасный ты не видишь, но от первого быстро глаза начинают болеть, а второй воспринимается как температура. Т.е. цвета ты не отличаешь, но организм на них реагирует.
Вообще, то что осознанно не слышишь те частоты не значит что не воспринимаешь их совсем.
Попробуй вместо синусоиды музыку послушать в полном спектре и в обрезанном, скорее всего вслепую спокойно отличишь.
То же самое со светом, например. Близкие к видимому спектру ультрафиолет и инфракрасный ты не видишь, но от первого быстро глаза начинают болеть, а второй воспринимается как температура. Т.е. цвета ты не отличаешь, но организм на них реагирует.
Есть один фильм в мкв, я из него достал одну дрожку нужную мне, потом остальные удалил, потом эту вшил обратно с перекодировкой в другой формат. На пк все работает как и хотелось. Телек лг 55олед позапрошлогодний вообще отказываетс яфайл открывать.
Я в этих вопросах нуб, выручай анон. и что опять с капчей из под куклы не грузится
Я в этих вопросах нуб, выручай анон. и что опять с капчей из под куклы не грузится
>>698609
Ты б хотя бы mediainfo своей перекодировки в другой формат полностью приложил.
Ты б хотя бы mediainfo своей перекодировки в другой формат полностью приложил.
>>698600
For all practical purposes in music listening, a 20 kHz low-pass filter is inaudible. The "cutoff" of, for example, 44.1 kHz digital audio (which cuts off at 22.05 kHz) is rarely noticed, and 20 kHz is often the standard, safe limit for mastering.
People generally start noticing a low-pass filter (LPF) cutoff in audio when it is set below
10–13 kHz for high-fidelity music, as this removes "air" and brilliance. For voice, audible degradation often begins around 5–7 kHz, while filters below 2–5 kHz make audio sound muffled or telephonic.
< 15 kHz (Subtle): Loss of "air," "sheen," or high-frequency brilliance.
10 kHz–12 kHz (Moderate): Loss of crispness and definition in percussion and vocals.
5 kHz–7 kHz (Noticeable): Audible dulling of voice, loss of articulation.
< 3 kHz (Severe): "Telephone" or "radio" effect, making sound muffled.
For all practical purposes in music listening, a 20 kHz low-pass filter is inaudible. The "cutoff" of, for example, 44.1 kHz digital audio (which cuts off at 22.05 kHz) is rarely noticed, and 20 kHz is often the standard, safe limit for mastering.
People generally start noticing a low-pass filter (LPF) cutoff in audio when it is set below
10–13 kHz for high-fidelity music, as this removes "air" and brilliance. For voice, audible degradation often begins around 5–7 kHz, while filters below 2–5 kHz make audio sound muffled or telephonic.
< 15 kHz (Subtle): Loss of "air," "sheen," or high-frequency brilliance.
10 kHz–12 kHz (Moderate): Loss of crispness and definition in percussion and vocals.
5 kHz–7 kHz (Noticeable): Audible dulling of voice, loss of articulation.
< 3 kHz (Severe): "Telephone" or "radio" effect, making sound muffled.
>>698609
Пересобери mkvmerge. ffmpeg не очень хорошо работает с мкв.
Пересобери mkvmerge. ffmpeg не очень хорошо работает с мкв.
55 Кб, 429x532Я вот не могу понять, а можно ffmpeg'ом увеличить fps в 2 раза? Чтобы кадры не тупо дублировались, а именно что генерировались новые кадры, как "среднее" между двумя оригинальными кадрами. Для более плавной картинки.
>>699912
Спасибо.
Спасибо.
В общем анон был прав, одного фымпега мало, достал нужную дорожку мквтул, пережал фымпегом, тзасунул обратно с удаление не нужных мквтул. Все ок. Спасибо за наводку.
389 Кб, 1000x500>>699912
Анончик, я в экстазе от этого дрянья! Попробовал кусочек старого концерта 25 фпс улучшить до 50 фпс, эффект фантастический. Будто проход в 4-е измерение.
Собственно, ещё вопрос, какие параметры данного фильтра дают максимальное качество? У меня сейчас вот так:
Анончик, я в экстазе от этого дрянья! Попробовал кусочек старого концерта 25 фпс улучшить до 50 фпс, эффект фантастический. Будто проход в 4-е измерение.
Собственно, ещё вопрос, какие параметры данного фильтра дают максимальное качество? У меня сейчас вот так:
>minterpolate=fps=50:mi_mode=mci:mc_mode=aobmc:me_mode=bidir:vsbmc=1
>>699950
Вкатывайся в ComfyUI если хочешь увидеть реально мощный улучшайзинг. Там можно понаставить разных нейроночек, которые днями будут ебать твою видеокарту на 100%, генерируя по кадру в 10 минут, зато результат - чистая магия. Есть и уплавнялки, и апскейлы, и фильтры, и т.д.
Вкатывайся в ComfyUI если хочешь увидеть реально мощный улучшайзинг. Там можно понаставить разных нейроночек, которые днями будут ебать твою видеокарту на 100%, генерируя по кадру в 10 минут, зато результат - чистая магия. Есть и уплавнялки, и апскейлы, и фильтры, и т.д.
9 Кб, 251x218Поясните, а если у исходника 23.976 фпс, то какое значение правильнее выбрать для интерполяции в 2 раза, 47.952, 48 или 50 фпс? Чтобы корректно воспроизводилось разными плеерами, в т.ч. разношёрстными ТВ/медиа-боксами.
Алсо, если я сделаю 47.952 фпс и загружу на ютуб, то сохранится ли данное значение, или ютуб сам изменит фреймрейт до некого стандартного значения, типа 24, 25, 50 фпс?
Нахуя вообще эти 23.976 фпс в 2026 году? Свежий блюрей! Это же наследие со времён аналогового NTSC телевидения и киноплёнки, вызванное измерениями всего и вся лаптями в имперской системе. Почему от этого бессмысленного древнего кала до сих пор не отказались? Неужели аппаратным BD плеерам по сей день нужно именно 23.976 фпс?
Алсо, если я сделаю 47.952 фпс и загружу на ютуб, то сохранится ли данное значение, или ютуб сам изменит фреймрейт до некого стандартного значения, типа 24, 25, 50 фпс?
Нахуя вообще эти 23.976 фпс в 2026 году? Свежий блюрей! Это же наследие со времён аналогового NTSC телевидения и киноплёнки, вызванное измерениями всего и вся лаптями в имперской системе. Почему от этого бессмысленного древнего кала до сих пор не отказались? Неужели аппаратным BD плеерам по сей день нужно именно 23.976 фпс?
>>703019
СТРОГО умножаешь fps исходника на 2 (и пересчитываешь кадры, чтобы было ровно в 2N а не 2N-1). Проверяешь время последнего кадра в соснольке.
Это моя боль, чуть шаг в сторону --- или индексация ломается, или звук с видео начинают расходиться.
СТРОГО умножаешь fps исходника на 2 (и пересчитываешь кадры, чтобы было ровно в 2N а не 2N-1). Проверяешь время последнего кадра в соснольке.
Это моя боль, чуть шаг в сторону --- или индексация ломается, или звук с видео начинают расходиться.
>>703019
Если не уверен и фпс является постоянным, а не вэриэбл, можешь попробовать перед интерполейтом сделать это:
-vf "setpts=(24000/1001)/24*PTS, fps=24, [твои фильтры]" -af "atempo=24 / (24000/1001)"
Вместо 23.976, что является просто округлением, лучше использовать математически верное (24000/1001).
Это увеличит фпс с практически незаметным ускорением и не добавит новых кадров.
Собственно, весь контент для ТВ в 23.976 (24000/1001) или 29.970 (30000/1001) фпс это замедленные 24 или 30 фпс.
Да, fps фильтр после setpts обязателен, т.к. без него в старых версиях ffmpeg значение фпс останется прежним (23.976 в данном случае), а в новых версиях из-за бага фпс вообще сбрасывается на дефолтные 25, что создаст новые дубликаты кадров.
Если не уверен и фпс является постоянным, а не вэриэбл, можешь попробовать перед интерполейтом сделать это:
-vf "setpts=(24000/1001)/24*PTS, fps=24, [твои фильтры]" -af "atempo=24 / (24000/1001)"
Вместо 23.976, что является просто округлением, лучше использовать математически верное (24000/1001).
Это увеличит фпс с практически незаметным ускорением и не добавит новых кадров.
Собственно, весь контент для ТВ в 23.976 (24000/1001) или 29.970 (30000/1001) фпс это замедленные 24 или 30 фпс.
Да, fps фильтр после setpts обязателен, т.к. без него в старых версиях ffmpeg значение фпс останется прежним (23.976 в данном случае), а в новых версиях из-за бага фпс вообще сбрасывается на дефолтные 25, что создаст новые дубликаты кадров.
>>703024
Поехавший? Между NTSC и вин7 аж 56 лет.
Последние NTSC ТВ-передатчики в СШП и других странах были отключены как раз в 2009-2012 годах, когда вышла вин7. Им на замену пришло цифровое HD вещание, которому пофигу на фпс.
Тем не менее, на дворе 2026 год, а 23.976 кадров так и остались "индустриальным стандартом". Просто потому что.
>>703066
Вот и я стремаюсь рассинхрона с аудио при таких манипуляциях.
>>703077
Спасибо, буду пробовать.
Не понятно, как устроен и как работает этот фильтр. Так что по аудио есть вопросы, которые надо анализировать экспериментально.
>Сейчас бы стандарты 2026 года обсудить сидя на Windows 7
Поехавший? Между NTSC и вин7 аж 56 лет.
Последние NTSC ТВ-передатчики в СШП и других странах были отключены как раз в 2009-2012 годах, когда вышла вин7. Им на замену пришло цифровое HD вещание, которому пофигу на фпс.
Тем не менее, на дворе 2026 год, а 23.976 кадров так и остались "индустриальным стандартом". Просто потому что.
>>703066
Вот и я стремаюсь рассинхрона с аудио при таких манипуляциях.
>>703077
Спасибо, буду пробовать.
>-af "atempo=24 / (24000/1001)"
Не понятно, как устроен и как работает этот фильтр. Так что по аудио есть вопросы, которые надо анализировать экспериментально.
>>703284
Так как изменение фпс происходит путем изменения таймстампов и ускорения, то то же самое нужно проделать с аудио чтобы избежать рассинхрона - ускорить его.
>Не понятно, как устроен и как работает этот фильтр.
Так как изменение фпс происходит путем изменения таймстампов и ускорения, то то же самое нужно проделать с аудио чтобы избежать рассинхрона - ускорить его.
>>703289
Не, я о том, что если мы ускоряем/замедляем аудио даже на мизерное значение, необходимо применять time stretching. Делает ли именно это или что-то иное данный фильтр - дока ффпмега молчит.
Не, я о том, что если мы ускоряем/замедляем аудио даже на мизерное значение, необходимо применять time stretching. Делает ли именно это или что-то иное данный фильтр - дока ффпмега молчит.
>>703329
Понятно, спасибо!
Понятно, спасибо!
ав1 иногда превращает кожу в замыленный пластик, это можно как-то пофиксить? пробовал менять crf, tune, enable-tf, enable-cdef, включал/отключал грейн и матрицы квантования, но ниче не работает.
1. оригинал
2. ав1 с crf10 и preset 6
3. x265 crf 18 preset medium просто для сравнения
1. оригинал
2. ав1 с crf10 и preset 6
3. x265 crf 18 preset medium просто для сравнения
>>703077
Полная хуйня, типичный совет от нейрослопа.
24000/10001 = 23.9760239760..., в то время как в видео прописано 23.976, и именно это значение используется, все кадры расставлены кратно ему. Как там передаётся в NTSC не имеет значения --- после всех перекодировок и обрезаний в цифре все кадры и все аудиодорожки выровнены именно по 23.976.
>-af "atempo=24 / (24000/1001)"
Полная хуйня, типичный совет от нейрослопа.
24000/10001 = 23.9760239760..., в то время как в видео прописано 23.976, и именно это значение используется, все кадры расставлены кратно ему. Как там передаётся в NTSC не имеет значения --- после всех перекодировок и обрезаний в цифре все кадры и все аудиодорожки выровнены именно по 23.976.
>>703405
И сейчас ты, конечно, принесешь примеры таких видео? А, впрочем, даже если и сможешь, то я просто скажу что и ты, и тот кто делал видос - криворукие долбоебы пытающиеся зачем-то спорить с общеизвестными фактами, а большинство видео имеют математически правильный 24000/1001 фпс хотя соглашусь, что изредка, может, и встречаются кривые поделия, ЕМНИП.
К слову, в самом ffmpeg для fps фильтра есть константы ntsc_film (24000/1001) и ntsc (30000/1001).
И сейчас ты, конечно, принесешь примеры таких видео? А, впрочем, даже если и сможешь, то я просто скажу что и ты, и тот кто делал видос - криворукие долбоебы пытающиеся зачем-то спорить с общеизвестными фактами, а большинство видео имеют математически правильный 24000/1001 фпс хотя соглашусь, что изредка, может, и встречаются кривые поделия, ЕМНИП.
К слову, в самом ffmpeg для fps фильтра есть константы ntsc_film (24000/1001) и ntsc (30000/1001).
Аноны, аопомогите как сжимать порно правильно,какой битрейт и прочее, у меня 6650xt если что, пробовал в handbrake
111 Кб, 1741x1039Как сжимаете аудио в opus? Обнаружил что нужно ДОВОЛЬНО СИЛЬНО понижать громкость перед экспортом чтобы избавиться от клиппинга. В итоге получается что opus в 2 раза тише чем mp3 (пикрил opus и flac)
>>703813
Вижу на пикче клипинг что сверху, что снизу. Осциллограмма, срезанная по линеечке, это и есть клипинг. Нормальная осциллограмма так не выглядит. Т.е. клипинг у тебя в исходнике, а не в опусе.
Вижу на пикче клипинг что сверху, что снизу. Осциллограмма, срезанная по линеечке, это и есть клипинг. Нормальная осциллограмма так не выглядит. Т.е. клипинг у тебя в исходнике, а не в опусе.
>>703936
Ок. Скорее всего, это явление Гиббса на срезанных верхушках исходника. При удалении психоакустической моделью высоких частот на этих срезах возникает переходный процесс, который и улетает за 0 dB. Если при воспроизведении его не слышно, лучше всего просто забить. Исходник уже всё равно проёбан.
>Под словом клиппинг он, наверное, имеет в виду повышение уровня и вылет за 0 dB после конвертирования в opus.
Ок. Скорее всего, это явление Гиббса на срезанных верхушках исходника. При удалении психоакустической моделью высоких частот на этих срезах возникает переходный процесс, который и улетает за 0 dB. Если при воспроизведении его не слышно, лучше всего просто забить. Исходник уже всё равно проёбан.
>>703760
Чтоб было места дохуя
Чтоб было места дохуя
по теореме котельникова файл с частотой дискретизации 44.1 кГц физически не может содержать полезный сигнал выше 22.05 кГц (ровно половина частоты дискретизации)
>>704506
Та там всё по этим пыльным талмудам и рассчитано было при разработке аудио сиди. 44.1 это теоретический идеал с нахлёстом в замкнутой системе, но при этом практический минимум.
С другой стороны, воспроизводящая консьюмерская техника в последние годы или стагнирует или деградирует, потому один хуй не с чего послушать разницу между 48к и 44.1к — цапы говно, наушники говно, колонки говно. За глаза и за уши порезанных спектров лосси форматов по итогу.
Та там всё по этим пыльным талмудам и рассчитано было при разработке аудио сиди. 44.1 это теоретический идеал с нахлёстом в замкнутой системе, но при этом практический минимум.
С другой стороны, воспроизводящая консьюмерская техника в последние годы или стагнирует или деградирует, потому один хуй не с чего послушать разницу между 48к и 44.1к — цапы говно, наушники говно, колонки говно. За глаза и за уши порезанных спектров лосси форматов по итогу.
>>703391
-svtav1-params film-grain-denoise=0/-svtav1-params film-grain=50?
https://trac.ffmpeg.org/wiki/Encode/AV1#Filmgrainsynthesis
-svtav1-params film-grain-denoise=0/-svtav1-params film-grain=50?
https://trac.ffmpeg.org/wiki/Encode/AV1#Filmgrainsynthesis
>>703019
Ты хочешь удвоить частоту кадров? Последнее, что помню, у FFmpeg был хреновый интерполятор, слишком много артефактов, а вот в AviSynth с SVPflow вполне норм, у меня даже хранятся несколько видосов с удвоенной частотой. Очевидно, что 25 желательно конвертировать в 50FPS, 29.97 в 60FPS, ну а 23.976 в 50FPS, т.к. наиболее близкое значение и не надо будет лишние кадры интерполировать. Телики и плееры обычно поддерживают 23.967/24/29.97/50/59.94/60.
Ты хочешь удвоить частоту кадров? Последнее, что помню, у FFmpeg был хреновый интерполятор, слишком много артефактов, а вот в AviSynth с SVPflow вполне норм, у меня даже хранятся несколько видосов с удвоенной частотой. Очевидно, что 25 желательно конвертировать в 50FPS, 29.97 в 60FPS, ну а 23.976 в 50FPS, т.к. наиболее близкое значение и не надо будет лишние кадры интерполировать. Телики и плееры обычно поддерживают 23.967/24/29.97/50/59.94/60.
>>704521
ну wavpack в режиме hybrid есть в принципе. при макс сжатии и битрейте в 400 звук прозрачный и меньше флака в 2-2.5 раза. а если создать ещё и файл коррекции то вот тебе тот же lossless. и хорошо когда есть большой запас по битрейту. в vorbis 500, aac 320, mp3 320, у opus 510 к тому же резкая обрезка на 20кгц и ресэмплинг в 48кгц (что как бы даёт понять что это именно lossy по духу и есть риск ошибок и они могут что то вырезать чтобы втиснуться в эти рамки и задыхаться в них, психоакустика и тд) а у wavpack лимит аж 2048 или около того и он изначально lossles, ничего не вырезает, лоупасса нет и не ресэмплит. а больше то ничего как будто и нет, если рассматривать хотя бы то что как никак обновляется и улучшается до сих пор.
больше реально ничего нет. либо старая экзотика без поддержки как musepack, либо проприетарный мусор либо те что режут звук по определению.
ну wavpack в режиме hybrid есть в принципе. при макс сжатии и битрейте в 400 звук прозрачный и меньше флака в 2-2.5 раза. а если создать ещё и файл коррекции то вот тебе тот же lossless. и хорошо когда есть большой запас по битрейту. в vorbis 500, aac 320, mp3 320, у opus 510 к тому же резкая обрезка на 20кгц и ресэмплинг в 48кгц (что как бы даёт понять что это именно lossy по духу и есть риск ошибок и они могут что то вырезать чтобы втиснуться в эти рамки и задыхаться в них, психоакустика и тд) а у wavpack лимит аж 2048 или около того и он изначально lossles, ничего не вырезает, лоупасса нет и не ресэмплит. а больше то ничего как будто и нет, если рассматривать хотя бы то что как никак обновляется и улучшается до сих пор.
больше реально ничего нет. либо старая экзотика без поддержки как musepack, либо проприетарный мусор либо те что режут звук по определению.
>>704921
Я долго надеялся, что кто-нибудь вытрясет сорцы musepack и продолжит его поддерживать, человечество не знает что потеряло.
А твои заёбы с вавпаком не понимаю. Формат недооценённый, конечно, но нахуй он тебе, как и запасы по битрейту. Всю музыку мира решил сохранить в максимальном качестве при минимальном размере? У меня флацковая библиотека ни разу не переваливала за терабайт, хотя немаленькая. Всю её на портатив скидывать тоже непонятно зачем, а если надо, то опус/qаац гуд инах в районе 144-192 битрейта.
Я долго надеялся, что кто-нибудь вытрясет сорцы musepack и продолжит его поддерживать, человечество не знает что потеряло.
А твои заёбы с вавпаком не понимаю. Формат недооценённый, конечно, но нахуй он тебе, как и запасы по битрейту. Всю музыку мира решил сохранить в максимальном качестве при минимальном размере? У меня флацковая библиотека ни разу не переваливала за терабайт, хотя немаленькая. Всю её на портатив скидывать тоже непонятно зачем, а если надо, то опус/qаац гуд инах в районе 144-192 битрейта.
>>704978
ну, если хочется можно использовать mpc и сейчас.
как пишется на оф сайте (текст недавний на 24 год):
Немногие в мире обладают передовыми техническими возможностями, необходимыми для настройки психоакустической модели, используемой Musepack, без негативного влияния на и без того исключительное качество звука. Нет намерения чинить то, что не сломано. Но как всегда, приветствуются любые дополнения к исходному коду.
я для любопытства сконвертил в фубаре 1 флак весом 126мб в 6 разных форматов. вот что получилось по весу:
1) mp3 41.9 мб (--noreplaygain -k -q 0 -b 320) вес самый низкий потому что cbr
2) opus 42.2 мб (--bitrate 320 --vbr --music ) плюс ресэмплер ardftsrc в 48кгц качество insane
3) musepack 42.5 мб (--xlevel --quality 10)
4) apple aac 44.6 мб (--quality 2 --lowpass 22000 --no-optimize -V 127 -i)
5) wavepack 55.5 мб (-i -q -hh -x6 -b400 -m) без корректировочного файла
6) vorbis 59.4 мб (-q10)
ну, если хочется можно использовать mpc и сейчас.
как пишется на оф сайте (текст недавний на 24 год):
Немногие в мире обладают передовыми техническими возможностями, необходимыми для настройки психоакустической модели, используемой Musepack, без негативного влияния на и без того исключительное качество звука. Нет намерения чинить то, что не сломано. Но как всегда, приветствуются любые дополнения к исходному коду.
я для любопытства сконвертил в фубаре 1 флак весом 126мб в 6 разных форматов. вот что получилось по весу:
1) mp3 41.9 мб (--noreplaygain -k -q 0 -b 320) вес самый низкий потому что cbr
2) opus 42.2 мб (--bitrate 320 --vbr --music ) плюс ресэмплер ardftsrc в 48кгц качество insane
3) musepack 42.5 мб (--xlevel --quality 10)
4) apple aac 44.6 мб (--quality 2 --lowpass 22000 --no-optimize -V 127 -i)
5) wavepack 55.5 мб (-i -q -hh -x6 -b400 -m) без корректировочного файла
6) vorbis 59.4 мб (-q10)
>>703019
Если ты занимаешься говноинтерполяцией (а тем более кадров, снятых с киношной выдержкой, вместо цифровой генерации мгновенных рендеров), то тебе уже насрать на результат, и нет смысла задумываться о частоте кадров.
Ты задаёшься вопросом о надписях на рукоятках на пульте управления ядерного реактора, а что происходит с ним самим, как бы и не важно.
>>703405
>>703433
Вы о сферической хрени в вакууме спорите. Если в студийной технике, работающей часами и днями, есть точные генераторы частоты (или даже вход внешнего источника, по которому синхронизируется всё оборудование), то в остальном мире полно материалов из цифровых источников, где может использоваться и ровно 60/50/30/25/24, и «типа 60/30/24 со скидкой на NTSC, но не точно как в NTSC, а просто похожая циферка, которая в нашем бытовом устройстве или кодировщике позволяла работать». Что есть, с тем и надо работать, понимая, каковы последствия, и как их избежать.
Более того, возникновение цифровых форматов со строго 24 кадрами в секунду в некоторых случаях приветствовалось как способ избежать конвертации и разъезжания туда-обратно при монтаже на телевизионной технике.
Смех в том, что когда классические фильмы выходили, и их крутили в кинотеатрах с плёнки, результат никогда не был таким точным. Смену бобин и неточности фокусировки проектора почему-то не воспроизводят на блюреях.
>>703813
У тебя какая-то проблема с импортом фалов, выводом графиков или их пониманием. Кодеки для аудио с громкостью ничего не делают (если совсем уж не завалить сигнал артефактами сжатия на низком битрейте). В Opus используется конверсия в 48 КГц, то есть несовместимым становится формат, а не уровень громкости.
>>704921
Шиза безграмотная. Бессмысленно дрочить лучше на письки, чем на байтики и циферки, а то вот так деградируешь до того, что не понимаешь разницу между сжатием с потерями и без.
Если ты занимаешься говноинтерполяцией (а тем более кадров, снятых с киношной выдержкой, вместо цифровой генерации мгновенных рендеров), то тебе уже насрать на результат, и нет смысла задумываться о частоте кадров.
Ты задаёшься вопросом о надписях на рукоятках на пульте управления ядерного реактора, а что происходит с ним самим, как бы и не важно.
>>703405
>>703433
Вы о сферической хрени в вакууме спорите. Если в студийной технике, работающей часами и днями, есть точные генераторы частоты (или даже вход внешнего источника, по которому синхронизируется всё оборудование), то в остальном мире полно материалов из цифровых источников, где может использоваться и ровно 60/50/30/25/24, и «типа 60/30/24 со скидкой на NTSC, но не точно как в NTSC, а просто похожая циферка, которая в нашем бытовом устройстве или кодировщике позволяла работать». Что есть, с тем и надо работать, понимая, каковы последствия, и как их избежать.
Более того, возникновение цифровых форматов со строго 24 кадрами в секунду в некоторых случаях приветствовалось как способ избежать конвертации и разъезжания туда-обратно при монтаже на телевизионной технике.
Смех в том, что когда классические фильмы выходили, и их крутили в кинотеатрах с плёнки, результат никогда не был таким точным. Смену бобин и неточности фокусировки проектора почему-то не воспроизводят на блюреях.
>>703813
У тебя какая-то проблема с импортом фалов, выводом графиков или их пониманием. Кодеки для аудио с громкостью ничего не делают (если совсем уж не завалить сигнал артефактами сжатия на низком битрейте). В Opus используется конверсия в 48 КГц, то есть несовместимым становится формат, а не уровень громкости.
>>704921
Шиза безграмотная. Бессмысленно дрочить лучше на письки, чем на байтики и циферки, а то вот так деградируешь до того, что не понимаешь разницу между сжатием с потерями и без.
44 Кб, 723x444>>705288
Если не уменьшать громкость при экспорте в opus - появляется много клиппинга. На солсике поэтому раздают опусы с уменьшенной раза в 2 громкостью. При экспорте в mp3 такой проблемы нет
>У тебя какая-то проблема с импортом фалов
Если не уменьшать громкость при экспорте в opus - появляется много клиппинга. На солсике поэтому раздают опусы с уменьшенной раза в 2 громкостью. При экспорте в mp3 такой проблемы нет
И опус и мп3 конвертирую во флак сразу же после скачивания, чтобы сохранить лосслесс звук, так как в лосси биты деградируют со временем из за гамма лучей из космоса или как эта хуйня называется не помню точно
>>707152
В нём ещё и динамический рэндж растёт, если по-тише делать перед сжатием. Только выигрываешь, короче.
В нём ещё и динамический рэндж растёт, если по-тише делать перед сжатием. Только выигрываешь, короче.
>>707152
Ты хочешь сказать, что самый популярный кодек делали идиоты, которые этого не заметили?
Или, может, долбоёбы, которые используют формат с плавающей точкой для заранее известного аудио, не понимают, что в нём не существует верхнего уровня громкости (точнее, он огромной и на практике не имеющей смысла величины), и что абстрактная нулевая точка задаётся произвольно, и что надо программы приводить в соответствие какому-то стандарту, если уж на то пошло?
Ты хочешь сказать, что самый популярный кодек делали идиоты, которые этого не заметили?
Или, может, долбоёбы, которые используют формат с плавающей точкой для заранее известного аудио, не понимают, что в нём не существует верхнего уровня громкости (точнее, он огромной и на практике не имеющей смысла величины), и что абстрактная нулевая точка задаётся произвольно, и что надо программы приводить в соответствие какому-то стандарту, если уж на то пошло?
>>707160
Анончик, выкладывай свои флак на торренты, надо помочь людям
Анончик, выкладывай свои флак на торренты, надо помочь людям
Поясните про
-b:v ???k
и
-sn -pass ?
Какое значение нужно выставлять для минимума/максимума качества? Использую этот пресет
ffmpeg -i in.mkv -c:v libvpx-vp9 -b:v ???k -threads 8 -g 128 -frame-parallel 0 -pix_fmt yuv420p -c:a libopus -b:a 128k -sn -pass ? -y out.webm
-b:v ???k
и
-sn -pass ?
Какое значение нужно выставлять для минимума/максимума качества? Использую этот пресет
ffmpeg -i in.mkv -c:v libvpx-vp9 -b:v ???k -threads 8 -g 128 -frame-parallel 0 -pix_fmt yuv420p -c:a libopus -b:a 128k -sn -pass ? -y out.webm
>>716258
тред перекатили
тред перекатили