FFmpeg и общий кодирования видео тред №6 /ffmpeg/
Аноним (Microsoft Windows 10: Chromium based)
29/04/22 Птн 15:46:16
№
1
В прошлый раз мы снова почти не срались за кодеки весь тред, а культурно помогали друг другу с ffmpeg.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Подробный разбор режимов кодирования основных кодеков читай тут: 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
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
Тред №0: https://2ch.hk/s/arch/2020-08-05/res/2591244.html
Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html
Тред №2: https://2ch.hk/s/arch/2021-09-23/res/2979843.html
Тред №3: https://2ch.hk/s/arch/2021-11-13/res/3029626.html
Тред №4: https://2ch.hk/s/arch/2022-03-10/res/3056070.html
Тред №5: https://2ch.hk/s/res/3101682.html
Попробовал тупо
ffmpeg -i RPReplay_Final1651382370.MP4 -t 167 repl.webm
- пыхтит на небольшом файле полчаса. Куда -hwaccel писать, чтоб быстра было? Ну или вообще как делать вебм-ки из mp4?
Купить нормальный процессор.
Не делай вебмки, они не открываются на ipad’е в сафари + больше девайсов поддерживают аппаратное декодирование h264.
> Не делай вебмки, они не открываются на ipad’е в сафари
На моей РустерОС тоже, плак-плак.
ffmpeg -i RPReplay_Final1651382370.MP4 -t 167 -vcodec vp8 -acodec opus -b:a 128k -b:v 0 -crf 30 repl.webm
Гайд по кодированию в первом посте
>>3145080
Полное дерьмо
>>3145074
Все девайсы поддерживают vp9, эпло мусор идёт нахуй сразу
Не ври, аппаратной поддержки vp8/9 в моем thinkpad’е 2012 года нет.
>аряя дайте поддержку а мое старое говно
Ебало имейджнули?
Ох уж эти токсичные фанатики, готовые забить на большинство девайсов только потому что "старое говно" или "эпло мусор".
Хорошо хоть люди, выкладывающие фильмы и сериалы на торренты, не такие неадекваты.
>Ох уж эти токсичные фанатики, готовые забить на большинство девайсов только потому что "старое говно"
Ты додик или притворяешься? Тогда кодека этого не было, соответственно в древних процессорах как говно мамонта, аппаратного кодирования тоже не могло быть. А то что эплодауны не могут кодек в говнобраузер добавить, чтобы хотя бы тупо воспроизводить, это исключительно проблемы япле и их гоев.
>Хорошо хоть люди, выкладывающие фильмы и сериалы на торренты, не такие неадекваты.
Да-да. Ведь там не h264 10 bit, аппаратно которое вообще почти нигде не реализовано. И всё давно выкладывают в hevc 10 bit.
Да, всё что старее, старое говно.
Выблядки из эпл специально не добавляют поддержку самого лучшего кодека - у которого лучшая степень сжатия, свободного, без патентов, над которым работают множество компаний. Так что эту компанию можно смело слать нахуй
Почему гуглофоны не снимают в VP9? Почему в h.265?
Лучше же по всем параметрам!
Мыльные VP9 и AV1 нужны только для экономии дискового пространства Youtube.
Потому что vp9 для кодирования и максимального сжатия, а не для записи в реальном времени.
Почему онлайн кинотеатры показывают не в VP9?
Почему сайты с порнухой не в VP9?
Где в дикой природе увидеть VP9 кроме борд и ютюба?
Уточняй, декодирование или энкодирование имеешь в виду под аппаратным ускорением.
>>3146077
Потому что нету нормального кодировщика для vp9. Имеющийся кодирует на уровне x264, но требует в намного больше времени. С av1 эта проблема решена
> С av1 эта проблема решена
Где сайты с AV1?
Гайд жопный кал вообще. Новичок ничего не поймет и плюнет. Нахрена на него скидывать сразу какие-то параметры кодирования, если он даже базу не знает.
А нахрена? Фильмы вечность будут в vp9 кодироваться, тем более в экшн сценах. Да и у них не всех стоит жёсткой цели минимальную ширину канала ставить. Проще готовые h264, h265 крутить.
>>3146076
Смотря какие. На redgif для более длинных роликов кодируется в vp9.
>>3146077
А где они ещё могут быть? Разве что на сайтах встраивают вместо гиф.
С какой скоростью кодирует этот svt-av1 примерно? Aom просто миллиард лет это делает.
>эксперт уровня /s/
Тут даже логику не надо применять, чтоб понять почему.
Первый проход нужен чтобы кодировщик понял из чего состоит видео, как оно сжимается в каждом месте, он пробует сжать по твоим параметрам, и записывает информацию в отдельный файл. Если не написать степень сжатия, он сожмет по умолчанию, crf 28. В итоге во втором проходе ты напишешь другое значение, и его данные не совпадут, потому что он в первый раз рассчитывал на другие значения, и будет хуже качество
Вроде понятно, спасибо
В некоторых видео ключевые кадры находятся слишком далеко друг от друга. Мне нужно увеличить их количество - один ключевой кадр на 1 или 2 секунды, при этом не потеряв в качестве видео. То есть желательно никак не менять пиксели, а вместо этого "взболтать" структуру кадров.
Было бы неплохо ещё и закодировать его в кодек с лучшим сжатием, но вряд ли это возможно без потери качества. Транскодирование в lossless сделает файл ещё более жирным.
Нахуя? От этого точно потеряется качество. С помощью команды -g 30, число кадров раз в которую ставится ключевой кадр
>От этого точно потеряется качество
Почему? По идее, он должен декодировать промежуточные кадры, но не показывать их на экране готовыми картинками, как плеер, а сохранить эти картинки в ключевые кадры.
Можно в ffv1 закодировать, это кодек без потерь где нет промежуточных кадров, только ключевые
>Latest release Version 3 (FFV1.3) 3 August 2013; 8 years ago
Вменяемым сжатием даже не пахнет.
Что надо подправить, чтобы они открывались?
Попробуй перепаковать.
Ты еблан, там несколько версий есть, 3 активно развивается. И даже первая сжимает без потерь лучше чем 264 и 265
> без потерь лучше чем 264 и 265
UT – 2,48 ГБ.
FFV1 со стандартным GOP 250 – 1,85 ГБ.
FFV1 с GOP 1 – 1,86 ГБ.
Декодирование UT нагружает i3 7100 на 10-15%.
Декодирование FFV1 нагружает i3 7100 на 55-60%.
Пробовал
-map 0
-disposition:a:0 default (поставить японскую по умолчанию)
-disposition:a:1 none (убрать значение по умолчанию для дубляжа)
эффекта не возымело. Как так вообще получилось, что после склейки вторая дорожка тоже стала дефолтной?
Оказалось, что вместо
-disposition:a:x none
нужно
-disposition:a:x 0
так как none не задокументированный аргумент, о чем индус на стаке не удосужился упомянуть. Как итог у меня не работало, билд от BtBN.
Если есть видеокарта NVIDIA,то вроде -hwaccel cuda
8 там что-ли
Он работает на любом процессоре
Работать то работает. Я так понял, что на новых процах он работает сильно быстрее, нет?
Нет, он очень медленный, но для av1 с его топ качеством это быстро
Да не сказать что очень. Вот сравнение preset 5 с vp9 good.
Как кстати время кодирования вывести?
У меня скрипт на питоне, который все видео ищет в папке, где лежит, и по очереди кодирует.
> Гайд по кодированию от анона из треда №5 (принимается критика)
В пособии по AV1 сказано «Пресеты 1-3 для экстремально эффективного сжатия», исправь на «0-3».
Поставь картинку https://people.videolan.org/~unlord/SVT-AV1_BD-rate.png (из обсуждения https://old.reddit.com/r/AV1/comments/r1sv22/av1_the_opus_of_video_codecs_discuss/ взятую) для визуального понимания того, какой пресет SVT-AV1 опережает по скорости привычные пресеты x264, x265, libvpx, и того ещё, насколько при этом растёт соотношение качества и объёма файла.
> Гайд по кодированию от анона из треда №5 (принимается критика): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
Убери вот эту беспруфную хуйню в разделе Opus. Выделил жирным и подчеркнул
> Оптимальный битрейт 160k, используется на ютубчике, по тестам звучит лучше чем 320k mp3
Объяснять и доказывать, надеюсь не нужно. Мп3 320 это уровень качества, который уже неотличим от лосслесс в 99% случаев. Опус хорош только на низких битрейтах своей дикой скоростью кодирования и относительно низким количеством слышимых артефактов. Он никогда не был полной заменой музыкальных кодеков
На 256/320кбит опус проигрывает и ворбису, и мп3. Чтобы 160кбит опус давал меньше артефактов чем мп3 320 это вообще бред. Только если сравнивать с первой версией мп3 из 1993 года, может быть где-то там
Большей тупости не читал, какие-о кодеки музыкальные, лол.
"Музыкальные" очевидно те, где артефактов почти не слышно, либо вообще не слышно по всему спектру на не слишком огромных битрейтах
Опус к ним не относится. Его применяют только на ютубе и в приложениях для голосовой связи
Алсо тащи пруфы, где там опус 160кбит превосходит 320кбит мп3
Если методику не знаешь — берешь исходник в любом лосслес формате, конвертишь в опус и мп3. С помощью спец софта вычитаешь из сигнала опуса сигнал лосслес и из мп3 лосслес. Получаешь отдельно артефакты для опкса и для мп3, и вбрасываешь их сюда + скриншоты спектрограмм артефактов
Глупость это хуета написанная про маняпревосходство опуса над всем сущим. Его удел это низкие битрейты, например длинные вебмки, которые с трудом помещаются в лимит даже без звука. Или вебм в которых музыкальная составляющая вообще не играет роли, например если в ролике в основном просто пиздеж голосом
> Получаешь отдельно артефакты для опкса и для мп3, и вбрасываешь их сюда + скриншоты спектрограмм артефактов
Ну так и вбрось, раз утверждаешь, только желательно тесты не на реалтеке в мат. плату встроенном делай, чтобы наводок от хардвари избежать.
> например если в ролике в основном просто пиздеж голосом
> Opus — последнее слово в области lossy кодирования аудио. Сочетает в себе новейшие разработки — низколатентный кодек CELT от Xiph.Org и ориентированный на речь кодек SILK, разработанный Skype. Оба эти кодера в значительной степени модифицированы и благодаря этому очень эффективно взаимодействуют. Opus может не только незаметно переключаться между реализациями SILK и CELT, но также и работать в гибридном режиме — когда SILK кодирует диапазон до 8 кГц с линейным предсказанием, а CELT — всё что выше, с использованием МДКП.
> Opus отличается наиболее совершенной на сегодня психоакустической моделью и непревзойдённой гибкостью битрейта (от 1 до 256 кбит/с на канал, с приращением ±0.4 кбит/с).
Всё так. Если почитать ветку, я пишу о том же самом
>>3148609
> Ну так и вбрось, раз утверждаешь
На гитхабе абсолютно беспруфное утверждение сенсационного характера. Так что ждём пруфов сначала от автора того утверждения. Либо пусть убирает сомнительную информацию
> только желательно тесты не на реалтеке в мат. плату
Кодирование на процессоре выполняется. Это сравнение можно вообще без звуковой карты выполнить только с помощью монитора и мышки
Даже если слушать, искажения от реалтека будут несравнимо малы по сравнению с артефактами опуса 160кбит. Современные цапы практически невозможно отличить вслепую, кроме самых самых хуевых цапов. Реалтеки 700-1000 серии к самым хуевым не относятся
> На гитхабе абсолютно беспруфное утверждение сенсационного характера. Так что ждём пруфов сначала от автора того утверждения.
Не, ну про 160 opus и 320 mp3 неотличимое, здесь будет посос, по спектрограммам уж точно. Это автор какую-то хуйню прогнал непроверенную. Никогда не верьте гайдам с двача.
>Мп3 320 это уровень качества, который уже неотличим от лосслесс в 99% случаев
Ничего подобного. Тестов в инете полно. Плюс в мп3 есть баг, который в начале добавляет пустоту.
>>3148594
>>3148605
>>3148609
>>3148643
>>3148648
>>3148686
>пук пук ты пук
>нет ты пук пук я не пук
Ну так что, пруфы хоть от одной из сторон будут, или продолжите пердеть в лужу? Понимаю, что в /s/ беспруфное тявканье в норме, но уж так жидко серить под себя не следует.
Плохие твики? Старая винда? Разверни утверждение.
Зачем-то хостит вредоносные твики, хоть и предостерегает от использования.
Действительно странный, постил бы просто полезные твики и не смущал анончиков
На винде криво отображаются, никакой клеартуп не спасает, вот на маке отлично.
Держи пруфы
https://wiki.hydrogenaud.io/index.php?title=Opus
http://listening-test.coresv.net/results.htm
Тесты причём старые, современный opus ещё лучше выдает результаты, где-то на форумах есть новые тесты
>>3148695
Проиграл с долбоеба, этот архив был создан когда подняли скандал, чтоб легче было сделать обратную разработку, т.к. в старых версиях не был накинут обфускатор
> На 256/320кбит опус проигрывает и ворбису, и мп3. Чтобы 160кбит опус давал меньше артефактов чем мп3 320 это вообще бред. Только если сравнивать с первой версией мп3 из 1993 года, может быть где-то там
Ебать дегенерат https://wiki.xiph.org/OpusFAQ
> шапки
Значение знаешь?
> listening test
А где спектрограмма, полученная с помощью RMMA? Вот сюда её давай.
> Проиграл с долбоеба, этот архив был создан когда подняли скандал, чтоб легче было сделать обратную разработку, т.к. в старых версиях не был накинут обфускатор
Зачем вообще это хостить, зачем вообще этому делать обратную разработку, лол.
> Тесты причём старые, современный opus ещё лучше выдает результаты, где-то на форумах есть новые тесты
> --bitrate 96
Так это и сравнивали на битрейте 96 кбпс, ты давай сравнение опущ 160 и мрз 320.
>>3148772
Нет, год рождения
https://hydrogenaud.io/index.php?topic=117489.0
Короче, может opus 160 звучит и не лучше mp3 320, но точно не хуже, разницу отличить невозможно
> Короче, может opus 160 звучит и не лучше mp3 320, но точно не хуже, разницу отличить невозможно
Тогда правь шапку, охуевший.
https://disk.yandex.ru/d/s853E0oB1v_v6Q — тут результаты в виде двух файлов с артефактами + исходник
OPUS 160k хуже чем MP3 320k, т.к. дает гораздо больше слышимых артефактов на большей громкости
https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md — отсюда надо убрать ложный кусок текста "используется на ютубчике, по тестам звучит лучше чем 320k mp3"
На скриншотах видно графики спектра и примерную громкость
Методика тестирования: TLDR вычитаем из лосси файла файл с лосслесс, получаем чистые артефакты. Сравниваем громкость и количество артефактов
Опираемся на научный факт — если взять сигнал f(x) и сложить с инвертированным сигналом inv(f(x)), на выходы мы получим ничего. То есть сигналы полностью друг друга компенсируют.
Таким образом, если мы берем файл кодированный в OPUS 160k, и вычтем из него инвертированный по фазе файл lossless качества, например flac или wav, на выходе мы получим разницу между этими двумя файлами. Это и будут артефакты кодирования. Чтобы упростить задачу, оба файла непосредственно перед вычитанием переводятся из STEREO в MONO.
Команды использовал следующие
ffmpeg -i <lossless_file> -acodec libopus -b:a 160k <lossy_ogg_file> — получение OPUS файла
ffmpeg -i <lossless_file> -acodec mp3 -b:a 320k <lossy_mp3_file> — получение MP3 файла
Из-за особенностей софта, также mp3 и opus потребовалось перевести в промежуточный формат wav, так как он отказывался правильно работать со сжатыми файлами
ffmpeg -i <lossy_file> <lossy_file.wav> — получение wav файла с содержимым lossy файла
Естественно, перед тестами, я убедился, что последняя команда не вносит никаких изменений в сам сигнал. Просто вычел из исходного lossless файла конвертированный lossless.wav и получил отсутствие сигнала, как и должно быть.
Очевидные проблемы при вычитании — у нас частотный диапазон OPUS и MP3 ограничен 20khz по верхей границе, а lossless нет, это значит что при вычитании помимо артефактов мы получим ещё кусок исходного файла на частотах выше 20кгц. Поэтому конечном файле с помощью lowpass фильтра Чебышева отрезаны частоты выше 20кгц
>>3148751
Одна ссылка не открывается. Во второй MP3 кодируют с параметром v5, это 130кбит/сек
В ОППосте же висит информация, что OPUS 160кбит якобы лучше, чем MP3 320кбит. То что он лучше мп3 130кбит я не отрицаю
Артефакты артефактами, но нужно ещё психоакустическую модель учитывать.
В данном случае, какая бы пиздатая психоакустическая модель не была, артефакты опуса играют очень громко, их будет слышно так или иначе. В каких-то треках ты это не заметишь, а в каких-то сразу услышишь грязь. У мп3 320 же тихое шуршание и я не спорю, что на 160кбит у мп3 результат был бы хуже
> на 160кбит у мп3 результат был бы хуже
А на 320кбит у опуса? И что там у него с частой дискретизации, вроде 44100 раньше не умел и автоматически повышал до 48000, что как бы не улучшало какчества.
У опуща максимум 350.
Меня интересуют артефакты, не с точки зрения звука, я слушаю пердёжь из гениусов за 100 рублей, а в том, насколько хорошо кодек адаптирован к высоким битрейтам или его психосексуальная модель вносит типичные опусовские искажения на любом битрейте, а не по мере необходимости.
> А на 320кбит у опуса?
Сегодня уже лень это делать, может завтра вечером ещё дополнительно поогоню опус, ворбис, аац на 320кбит
> И что там у него с частой дискретизации, вроде 44100 раньше не умел и автоматически повышал до 48000
Это не брал в расчет, при ресемплинге артефакты "микроскопические" по сравнению с любым кодеком в 320кбит. Не уверен, можно ли их вообще услышать в реальных условиях
Твой математический тест полная хуйня, можешь сколько угодно сидеть и что-то там вычитать, это ни о чём не говорит.
Имеет вес только субъективные прослушивания у разных людей в слепую
Вслепую опус 160 кбит будет точно также хуже, чем мп3 320. В самых вырожденных случаях они будут неотличимы, но никак не лучше
Лосси wav еще погоняй, базарю, хорошая тема.
Добавил в ту же папку ещё opus 320, vorbis 320 артефакты.
Пик1 - опус
Пик 2 - мп3
Пик 3 - ворбис
Ну разницу тут уже с лупой нужно искать. У опуса на 320кбит чисто по плотности искажений всё хуже, да ещё и распределение идет больше на средние частоты. Ворбис и мп3 тут адекватнее справляются мп3 на самом деле не так плох, дохуя он уводит в низкие частоты, где артефакты почти невозможно расслышать, и в самые верхние, где ситуация аналогичная
Но по факту на 320кбит я уже не отличаю нихуя эти файлы от lossless. Как ни старался, не слышу разницу. Даже 160кбит опус с трудом могу отличить, и то не на любой песне.
AAC не получилось. Подозреваю проблема в конкретном кодеке, либо расчете времени файла у ффмпег. После кодирования я получаю расхождение в 0.013сек, которое руками искать я ебал если честно
А Wav попробовал пожать. Не нашел способов, кроме как перевести в 8 бит и снизить sample rate. Но если снизить sample rate до 320кбит/сек, качество падает просто пиздец. Хз может есть какие-то лосси кодеки, но я не нашел
По твоим графикам ничего не понятно, ты там мог чего угодно нарисовать.
Нашёл ссылку на картинку:
https://i-viaplay-com.akamaized.net/viaplay-prod/342/548/1574760460-8b604476d0e29d15c099dc0d82b55fbe84dc06a3.jpg?width=1600&height=900
Написано ведь, что jpg. А скачивается webp.
Причём, если удалить из ссылки всё после вопросительного знака включительно, то будет уже 1920x1080, а не 1600x900.
Что это за жидовские фокусы? Как оно работает в плане формата и разрешения? И где здесь исходник?
Сервер принимает запрос, парсит путь, параметры, твой юзер агент и решает, что выдавать тебе отталкиваясь от этого.
Если хочешь jpg, качай wget’ом или curl’ом или меняй юзер агент в браузере.
Исходник может быть jpg, а webp уже из него сделан, а может исходник в лосслесс формате и жпг и вебп сделаны из него, но судя картинке вряд ли.
Спасибо, вроде оригинал курлыкнулся.
Так это, файлы же есть на послушать
Если нужны выводы, то чисто по графикам и прочей хуйне
Все что ниже 192кбит — это opus
Выше 192кбит — vorbis, mp3, возможно aac
В зависимости от трека/наушников, запросто может быть такое, что опус 160кбит неотличим от лосслесс
test
test
Твой файл слегка поломан, 2 байта удалены из заголовка и 6 байт добавлено в конец, из-за чего картинка не открывается в сафари.
Я думал, может двач правит, но эти >>3149270>>3149272 две загрузились без изменений.
Ну ладно, заменю твоим. Скачал через curl -O, хз почему поломано. Просто хотелось jpg без лишнего перекодирования.
Jpg всегда нужно оптимизировать с помощью pingo, пару мегабайт экономит, и всякие такие ошибки исправляет
>В ОППосте же висит информация, что OPUS 160кбит якобы лучше, чем MP3 320кбит. То что он лучше мп3 130кбит я не отрицаю
Вот именно. За это я и ценю opus. Когда-то давно сжал коллекцию музыки в opus 240 kbps на телефон, по логике "если mp3@320 - идеал, mp3@256 - почти-идеал без слышимых потерь для большинства, а opus более современный и эффективный, то opus@240 и сожмёт хорошо, и качество не потеряется".
Алсо, opus не принимает 44100 hz, нужно ресемплировать в 48000. От плохого ресемплирования звук паршивый.
ffmpeg -c:a libopus -b:a 240k -filter:a "aresample=48000:resampler=soxr:precision=33"
>Когда-то давно сжал коллекцию музыки в opus 240 kbps на телефон
>Телефон
Ахахах, долбоёбина
Тупой дегрель, желаю скорее кирпича твою телефончику. Опус был, есть и будет самым требовательным к ресурсам, тем более зависимым от заряда батареек. Да я уж лучше в lossy tak/flac тогда для телефонов сожму, с ~ 300 битрейтом и оно, что самое смешное, будет лучше любой lossy параши, которую вы тут обсуждаете из треда в тред, а дальше этой мейнстримной хуеты, конечно же, никто и не смотрел. Как и в случае топового (lossless) tak над ссаным (lossless) flac с очень уёбищными минусами потерь метаданных и прочим (у флака). Продолжайте жрать говно и выбирать менее вонючее, лол. У меня всё.
> очень уёбищными минусами потерь метаданных и прочим (у флака)
У FLAC есть контейнер для тэгов Vorbis comment, есть ли такой у TAK? ТАК васянщина чистой воды. FLAC пилится нормальной организацией, которая явила миру ворбис и опус, а ещё FLAC начал своё повсеместное распространение, чего так никогда не получит. Сколько его плееров могут воспроизвести? Один?
> Алсо, opus не принимает 44100 hz, нужно ресемплировать в 48000. От плохого ресемплирования звук паршивый.
Лол ты никогда не услышишь разницы, вот это манявнушение. В факе про это есть
>>3150830
>>3150833
Ебать шизоида рвёт, что тут забыл, клуб поехавших аудиофилов не здесь
TAK пропретарщина, а этот достаточно когда куча свободных аналогов, даже Apple lossless, хоть эпл не выкладывает обновления исходного кода
Его автор вроде как хотел открыть.
Согласен, пиписитарщина, но автор его из года в год ноется, что ему за столько лет надоело и хочет открывать, хз когда уже.
>>3150833
Когда завезут нормальный искоробки режим подхвата всех метаданных у исходника, которые не будут обрезаться с упаковкой во flac и распаковкой обратно, не применяя при этом отдельный неудобный преф (который еще и не узнать, сжимался ли флак с этим префом или без). И когда будут нормальные скорость/размер максимального сжатия и молниеносная распковка в исходник - тогда и приходи, лол. По поводу первого минуса - вся соль в том, что васяны-релизеры, коих, блять, 99%, знать не знают про этот преф - итого вся музыка, кторая изначально была в диджитал исходниках - у них проёбана нещадно, ибо без него - оно уже не вернет тебе истинный размер исходника и комментарии. Иными словами, часть данных проёбется. Существенный минус. Что самое смешное - его учитывают все сторонние васянские лосслесс, искоропки поддерживая данные, даже вавпак, но только не флак. Нахуй и в пизду.
> И когда будут нормальные скорость/размер максимального сжатия и молниеносная распковка в исходник - тогда и приходи, лол.
Попробуй FLACCL что ли тогда.
>Сколько его плееров могут воспроизвести? Один?
Все относительно популярные. На основе ffmpeg его либо искоропки, либо плагином. На андроиде аналогично.
>Vorbis comment, есть ли такой у TAK?
APEv2 уже у пориджей не котируется или чё? Честно говоря, мне теги никогда не были нужны, так что я даже не смотрел. Любой адекватный плеер умеет в filename и cover.jpg (пориджевую хуйню мелкобуквенную чтоб не чистить и не видеть какой-нибудь naturewave с сохранением оригинальных названий на японском, блять https://bandcamp.com/EmbeddedPlayer/album=3972823002/size=large/bgcol=ffffff/linkcol=333333/transparent=true/ ).
>названий на японском, блять
Согласен, обосрался. Там китайский
> APEv2
Он для Monkey's Audio.
Нет, там японский. По крайней мере, имя исполнителя. Может это просто кунъёми запись.
>желаю скорее кирпича твою телефончику
Кирпич от прослушиваемых кодеков, вот это реально - лол.
>Опус был, есть и будет самым требовательным к ресурсам, тем более зависимым от заряда батареек
Ни разу не замечал за своим телефоном ни нехватки производительности, ни нехватки батареи.
Впрочем и музыку я почти не слушаю. Спустя время понял, что от прослушивания музыки на телефоне никаких положительных эмоций не получишь.
>над ссаным (lossless) flac с очень уёбищными минусами потерь метаданных и прочим (у флака).
О какой потери данных ты говоришь? Если я возьму исходный флак, закодирую в mp3/opus/ogg/tak, и затем обратно во flac - потеряю часть метаданных?
Почему меня вообще должно это волновать, если все lossless файлы, которые можно взять из интернета, во flac - то есть там уже терять нечего? ape, wav и alac встречаются намного реже, tak я кажется ни разу не видел. А кодировать исходники во flac не нужно, так как есть более эффективные кодеки.
>ты никогда не услышишь разницы, вот это манявнушение. В факе про это есть
Кажется, вместо паршивого звука, в кодированном файле звук стал ощутимо тише. С -filter:a "aresample=48000:resampler=soxr:precision=33" громкость была как в оригинале.
>этой мейнстримной хуеты
Которую используют гиганты Google и Apple, следственно развивают её.
>О какой потери данных ты говоришь?
Нет. В исходнике (а исходник у flac - wav) может быть часть данных, комметарии и прочий довесок от исполнителя, которые довольно таки часто туда что-то пишут. Эти данные проебутся, когда ты этот wav упакуешь во flac и распакуешь, например, обратно, потому что нужна отдельная команда, которой никогда не было в дефолте. И распаковывать нужно тоже с этим параметром, иначе проебётся. А как я блять узнаю то есть/нет? Васяны посчитали что нинужно - значит нинужно. Нахуй и в пизду флак, в таком случае. Исходник должен быть исходником, то есть этичным, не тронутым (если я захочу flac обратно в wav перевести и не проебать часть байтов). Но ладно я, хорошо, теперь я это знаю и учитываю эту еблю, но как быть с дебичами, которые пакуют флаки и куда-нибудь вбрасывают? Ведь он так популярен. Соответственно - масштаб обосрамса у флак слишком очевиден над остальными lossless.
>>3150852
Но оно только скорости прибавит, не размер сжатия же? Да и жирно слишком в сравнении, лол, когда так поддерживает любым некроговном и искоропки имеет несколько режимов оптимизаций под процы, от древнего говна мамонта mmx до современных, то есть в любых случаях работает быстро. Нахуй, это шах и мат над всеми lossless, ибо что еще нужно, если не размер сжатия с адекватной скоростью.
FLAC сам по себе является исходником, если качаешь музыку с файлообменников/торрентов. Те, кто выложил flac, берут его из исходного CD, реже винила или кассет. На CD разве есть комментарии, да вообще хоть какие-то теги? Исходником так же может быть файл из интернет-магазина, но Bandcamp например изначально предлагает скачать и в wav, и в flac, и в других форматах, и в комментариях к файлам Bandcamp всегда будет "Visit http://artist.bandcamp.com".
>Васяны посчитали что нинужно
А ffmpeg и официальный енкодер https://ftp.osuosl.org/pub/xiph/releases/flac/?C=M;O=D ?
> 9.50 метров tak вместо 10.40 метров flac
Несущественно. Сравните с FLACCL, который на OpenCL пожалуйста, там можно указать, сколько ядер использовать при кодировании, да и вообще всё продвинуто, как я посмотрел.
>На CD разве есть комментарии, да вообще хоть какие-то теги?
Скорее всего он о джиттер-коррекции. Мегабородатом меме из мира аудиофилов начала 00-х.
Не, ты уж извини, конечно, но это вчерашний день. В эпоху интернета стал популярен не CD, а диджитал, его еще WEB отмечают. Понятное дело, что мейнстримную часть музыки это не так сильно коснулось, но кто угорел по сервисам и прочим стриминговым площадкам с поддержкой lossless и pcm (в том числе приобретение), где музыканты заводят себе авторские страницы и выкладывают контент в первозданном виде без третьих лиц/без перекодирования (а то и вовсе без лейблов) - это имеет место быть, именно в таких случаях и могут попадаться авторские метаданные. А вообще, оригинало/md5 шизы меня должны понять, почему это так важно не проебать.
>FLAC сам по себе является исходником, если качаешь музыку с файлообменников/торрентов.
Это не совсем является исходником, тебе упаковали просто. Исходное в WAV/AIF/AIFF.
Градация у дисков такая: Есть исходное wav/aif/aiff от музыканта -> этот wav передаётся звуковику, который сводит и убирает все кривости -> потом это отдаётся обратно автору -> автор передаёт полученный мастеринг на лейбл, при необходимости там тоже могут что-то править/подрезать/делать всякие radio edit/extended/etc -> далее с лейбла передают это сторонним васянам, которые клепают CD/кассеты, либо лейбл их делает сам, то есть без третьих лиц -> потом уже пираты рипуют диск сразу же во flac, для экономии места.
А у диджитал всё тоже самое, кроме последних двух -> после этого либо лейбл публикует его как диджитал релиз, либо автор вообще без лейблов его выпускает (а то и вовсе без мастеринга, не суть).
Итого мы покупаем этот диджитал в исходном/авторском формате и видим там различные записи в метаданных, а чтоб их не проебать и упаковать с ними в lossless (flac/tak/alac/wavpack) для экономии места и если надо - то и распаковать обратно и чтоб файл не проебал часть байтов - флаку нужен отдельный преф, остальным - не нужно, всё искоропки. И вот васяны, кто релизит и вбрасывает - не знают об этом - в результате у некоторых коллекционеров музла горит (и не от васянов, а скорее от долбоебизма флака с очень очевидным минусом).
Бля, сколько можно разжевывать, лол.
>всегда будет Visit
Не всегда, на самом деле. И это только у тех форматов, которые поддерживают теги, а wav официально не поддерживает (у адекватного музыканта исходник всегда без потерь, то есть wav/aif/aiff (pcm) не суть). И учитывая что тегов в wav нет и делается это любым кустарным методом, то там нет заголовков и прочего - комментарии в таком случае всего лишь условны и могут быть расположены где, как угодно и любым методом. А вообще, Bandcamp на самом деле, хоть и сасный, но бляяять, они поощряют транскод, который никак не узнаешь, кроме как параноиком в спектры каждой скачки/покупки заглядывать, да-да. Короче, не идеальный он, но все пердят и пользуются.
>>3151022
Честно говоря, я последний раз тестами занимался года два назад, точно не припомню где он больше всего прироста давал с -p4m и максимальным flac (какой там, забыл уже, -8?). То ли в эмбиент музыке, то ли в прочих вещах где много статичного монохрома типо того же эмбиент-хауса/лоуфай хауса/дип/etc. А у бодрой электроники разница будет не так сильно заметна. Помню что некоторые релизы https://truthradio.bandcamp.com/music сильно отличались в размере (скачанные wav 16/24бит кодируя в максимальные прессеты tak и flac), была разница от 1 до 4 мб, может и больше, я забыл уже всё.
>Однако теги flac не сохраняются вообще, ни один из них
У Tak другие теги - APEv2. Нужна мокропися, наверное, чтоб вмержить их автоматически. Бгг эти ссаные теги, возня мух извечная. Официальная тулза Tak вообще только wav должна поддерживать для конвертации в Tak, а раз их там нет, то
то будут только те что были.
Flac - 315170816 байт (с учётом размера кластеров - 4 Кб)
Tak - 280956928 байт (с учётом размера кластеров - 4 Кб)
Разница - 1.121
Или же - 89.144 %
Команды:
Первая - fd -e flac -x flac -d {} {}.wav
Вторая - fd -e wav -x takc -e -pMax -tn4 {} {}.tak
Во время выполнения второй команды (непосредственно кодирования в tak) компьютер изрядно лагал, кстати.
>Не, ты уж извини, конечно, но это вчерашний день. В эпоху интернета стал популярен не CD, а диджитал, его еще WEB отмечают
Процентов 80 минимум из того что доступно у пиратов - всё ещё взято с CD, винила или кассет. А если брать классическую музыку, старых (даже относительно) авторов, то там все 98 получатся.
>музыканты заводят себе авторские страницы и выкладывают контент в первозданном виде без третьих лиц/без перекодирования (а то и вовсе без лейблов)
Я такого ни разу не видел. Интересную мне музыку ищу у пиратов, нахожу либо flac, либо mp3, реже - aac, ogg, ape, wav, aiff, alac, wv.
>флаку нужен отдельный преф
Какой?
Комментарии - это ведь тег. Такой же тег, как и исполнитель/альбом/трек/название. Если васян заполнил все прочие теги, то почему тег комментария не заполнен? А если всё на месте - то зачем беспокоиться о байтовой неточности? Те, кому нужна байтовая точность, могут хоть CD покупать, хоть у автора напрямую - у богатых свои причуды.
Комментарии не обязательно должны храниться в метаданных, их можно разместить на странице с релизом, или в интервью, на личном сайте.
>они поощряют транскод
>у адекватного музыканта исходник всегда без потерь
В чём проблема транскодировать lossless в lossless, если качаешь lossless, и lossless в lossy, если качаешь lossy?
>Нужна мокропися, наверное, чтоб вмержить их автоматически
Для flac есть metaflac, в котором есть --export-tags-to=FILE, в сочетании с утилитой fd можно массово экспортировать теги для всех флаков в папке и подпапках, затем сконвертировать flac в tak, присовокупив теги отдельной опцией на этапе кодирования tak. Но есть ли аналоги metaflac для других кодеков - я не проверял. И главное - "продвинутый" tak не принимает ничего, кроме wav. А значит для любого другого кодека нужно будет либо создавать временные файлы wav, которые займут дополнительное место на диске, которого может и не быть, поэтому придётся разделить процесс кодирования всей библиотеки на несколько этапов, в перерывах удаляя временные wav и уже ненужные flac, либо воспользоваться stdout (flac.exe -dc input.flac | Takc.exe -e - output.tak), но декодер flac, и возможно декодеры других кодеков, не поддерживают операции с множеством файлов, а значит для этого нужна будет утилита такая как fd - fd -e flac -x flac.exe -dc input.flac | Takc.exe -e - output.tak , однако разделитель команд "|" будет работать некорректно в такой вот команде внутри команды (-x), поэтому ничего не выйдет.
Короче, Tak нинужон обычному пользователю, твёрдо и чётко: исходных wav у рядового слушателя единицы, а массово кодировать имеющиеся flac/ape/alac в tak ради экономии 11%, отказываясь от тегов и засирая диск временными файлами - хуйня а не идея.
>отказываясь от тегов и засирая диск временными файлами
Не отказываясь от тегов*
Совсем уже запутался в этом пердолинге.
11% - цифра немаленькая, но из-за кучи временных файлов процесс кодирования может растянуться надолго.
Да объяснили же тебе, у flac совсем другие теги и вот вам еще один ёбаный обосрамс, вместо того чтоб пилить совместимые универсальные - васяны просто плодят хуергу из пустого в порожнее. Это не проблема TAK вообще, а APEv2 и того, откуда ты пиздишь теги. Бери изначально музло с apev2 тегами, либо пиши вручную фубаром, он хоть в пакетное редактирование может.
>Короче, Tak нинужон обычному пользователю, твёрдо и чётко:
Ты так интересно это говоришь, словно opus, vorbis, vp9, av1, которые тут мусолятся - прям нужны обычному пользователю, ага. Так такая же экзотика, только в сфере аудио, но хотя бы быстрая. Нет смысла уже, наверное, писать еще про одну фичу комбинирования файлов путем lossy wav (ужатый в tak или flac) с частичным lossless файлом, который еще больше выигрывает в хранении места. На простом языке - есть wav размером в 30мб - если мы его сожмем в какой-нибудь lossless получим 15мб, а так же сожмем еще и в какой-нибудь lossy размером 7мб. 15+7=22мб хранения. А вот комбинирующий режим - в эти 15мб уместит и lossless и lossy - двумя файлами. lossy вариант не будет требовать втрого файла и будет играть как есть, а вот lossless файл будет требовать рядом с ним еще и lossy файл. Плееры вроде того же фубара комбинируют на лету и ты можешь слушать что хочешь, хоть lossy, хоть lossless. Режим аналогичен Wavpack hybrid, только у wavpack он говно каличное, а здесь всё хорошо. Еще один шах и мат по сжатию, учитывая как прозрачен качеством lossy wav и который можно пожать еще и во flac/tak. Ладно уж, сказал, всё равно ж никто не станет эти безызвестные вещи пробовать.
> Так такая же экзотика
Opus и FLAC уже давно нет, их даже в браузеры по умолчанию добавили, а все видео на YT вообще в опусе в качестве звуковой дорожки.
> васяны просто плодят хуергу из пустого в порожнее
Как раз-таки у флака, опуса и ворбис стандартизированные теги, называется это чудо Vorbis Comments и отлично задокументировано.
Да, но что-то как дело касается переноса тегов - так сразу пук среньк писикак, ниработает.
Всё ещё лучше чем IDv3 и APEv2.
А у нас ютуб в качестве сервиса онлайн видео подразумевается людьми? Кому из так называемых обычных людей вообще известно какой там формат-то, блять. Раз уж спиздели про боычных, то обычные как жали свой калич в v0 mp3 и avc/avi, так и будут это делать еще ближайшие лет 50, лол. Не стоит мешать мух с котлетами. Разве я не прав? Что сейчас мейнстрим в 2к22 на раздачах в lossy - конечно же пиздоглазый мертвый mp3, был есть и будет, куда уж там, opus, ага.
Не спорю, наверное. Просто мне нинужно))
>боычных
сильно не бейте только, лол
>>3151217
На самом деле работает, в тот раз я, видимо, неправильно переносил. Что вообще может быть сложного в копировании текста из файла в файл в 2к22?
Нужно было сначала создать в файлах .tak нужные мне теги с любым значением (предположим - "0"), и только после этого импортировать теги из текстового файла, предварительно экспортировав их туда из исходников flac. Во время экспорта нужно выбрать сортировку по столбцу "Путь" (потому-что в .tak никаких тегов не будет). Сам шаблон такой:
$filename(txt,utf-8)$loop(%path%)%title% |^#(@@($#|#)) %artist% |^#(@@($#|#)) %albumartist% |^#(@@($#|#)) %album% |^#(@@($#|#)) %year% |^#(@@($#|#)) %genre% |^#(@@($#|#)) %track% |^#(@@($#|#)) %TRACKTOTAL% |^c1#(@@($#|#)) %comment% |^c2#(@@($#|#)) %URL% |^#(@@($#|#)) %PERFORMER% |^#(@@($#|#)) %DESCRIPTION% |^#(@@($#|#)) %discnumber% |^#(@@($#|#)) %disctotal% |^#(@@($#|#)) %barcode%
$loopend()
Такой же на импорт, но без лишнего в начале и в конце.
>>3151250
>А вот комбинирующий режим - в эти 15мб уместит и lossless и lossy - двумя файлами. lossy вариант не будет требовать втрого файла и будет играть как есть, а вот lossless файл будет требовать рядом с ним еще и lossy файл
Звучит, как чёрная магия.
Практично - не нужно лишний раз перекодировать, когда нужен lossy. Закончилось место на диске - удалил lossless-файл, lossy-файл остался - проблема решена.
Как опробовать эту фичу?
Ебать дебил, ты музыка слушаешь или теги читаешь? Вообще похуй, название файла достаточно, есть имя и название композиции. Главное что музыка без сжатия и всё
>комбинирующий режим
Блин, любопытная тема.
>Какой самый качественный метод масштабирования?
Для уменьшения - супервыборка. Для увеличения - бикубический.
scale_npp=1280:720:interp_algo=super от nvidia
Я уменьшу с UltraHD до FullHD после топаза, как в ffmpeg прописать супервыборку?
>>3151693
У меня Radeon.
>У меня Radeon.
Тогда помянем. Используй тупо lanczos и не парься. Либо пердоль через avisynth/vapoursynth, там полно разной чепухи.
>Я уменьшу с UltraHD до FullHD после топаза, как в ffmpeg прописать супервыборку?
Если ты заранее уменьшаешь, через топаз, тогда зачем тебе скейлить еще через ffmpeg?
Я не уменьшаю заранее..
> Есть исходное wav/aif/aiff от музыканта -> этот wav передаётся звуковику, который сводит и убирает все кривости
По моему там одним единственным wav файлом не обойтись. Там по идее должен быть файл проекта, с расставленными по времени семплами, готовыми лупами, и прочимим эффектами.
А уже сведённое аудио врятли можно пофиксить.
В каком кодеке хранят видео платные онлайн-кинотеатры (ivi, netflix и другие)? H265 в браузерах нет.
Где вообще используется h265?
> Где вообще используется h265?
BluRay, стриминг в мобильные приложения, … В общем везде, где аппаратное декодирование важнее проблем с лицензированием кодека.
Можешь попробовать добавить blur, чтобы смягчить артефакты.
> Можешь попробовать добавить blur
Это тоже самое, что снижать разрешение. А вообще ему деблокер нужен. А поскольку деблокер в декодере очевидно не справляется, то тут могут помочь только искусственные нейронные сети.
>>3154414
Да мне не качество надо исправить, а просто ужать ещё немного. А кодировщик вместо этого усирается, пытаясь идеально сохранить все артефакты оригинального видео и выходит худшее качество при большем объёме. Конечно, самое простое решение это посмотреть какой битрейт в оригинальном видео и кодировать с VBT пониже или под нужный размер. Но я хочу crf.
Твоё видео наверняка кодировалось под битрейт (не исключено что постоянный), а ты тут с crf мучаешься.
Ну ставь тогда CRF повыше и жми сильнее, кто ж мешает? Но если даже CRFом выходит худшее качество при большем объёме, то уже ничегос этим не поделаешь. Попробуй пресет помедленее. Попробуй 2 прохода, если жмёшь в VP9. Попробуй кодек поэффективнее.
>>3154794
Нейронки пока глупенькие, у самого топаз сейчас на фоне пыхтит. Ими есть смысл именно улучшать изначально неплохое качество, а не пытаться восстановить шакалы твиттера, как в случае анона. Попробовать можно, но очень сомневаюсь, что в этом будет толк. Хотя мы не видели сабж, может там всё не так плохо.
>Ну ставь тогда CRF повыше и жми сильнее, кто ж мешает?
Да это понятно. Я просто надеялся на хинты какие-то, тайные знания, чтобы не ебаться с перебором.
Аноны, а есть какие-нибудь апскейлеры видео для высоких разрешений? Интересует 4К -> 8К/12К. Хочется качество получше обычного ланкоша, но в то же время толстые нейросети типа Топаза или ESRGAN не подходят из-за производительности. Пытался нагуглить использование быстрых реалтайм апскейлеров типа RAVU, но нихуя не гуглится в связке с энкодером, только анимешный вайфу2х нашёл. Это вообще выполнимая задача или в любом случае я буду часовой видос конвертить сутки в 12К?
> часовой видос конвертить сутки в 12К
Это же очень быстро.
а нет нахой таких, чтобы быстро. Любая нейросетка будет долго работать. Да и зачем такие апскейлы вообще нужны, тысячу лет будешь их рендерить. Попробуй посмотреть VSGAN.
И непонятно тебе для чего? Видео в реалтайме смотреть или что?
Еще есть Red Giant Shooter Instant 4K и только в старых версиях, но не знаю есть ли там 12к, да даже 8к.
> а нет нахой таких, чтобы быстро
Но ведь в MPV есть NNEDI3 и RAVU, которые работают в реалтайме и могут как раз то что я хочу. Да хотя бы амдэшный FSR, всё лучше ланкоша.
> И непонятно тебе для чего?
360-видео апскейлить. Когда полусфера в 2К/4К, кроп в 60 градусов выглядит как 720р-пиздец с бикубиком.
>NNEDI3
Я думал, это дэинтерлейсер скрипт для avisynth нет?
>RAVU
первый раз слышу о таком.
>Да хотя бы амдэшный FSR
явно давно запилили фигню какую-нибудь на нем, по типу magpie. Он же опенсорс.
>360-видео апскейлить. Когда полусфера в 2К/4К, кроп в 60 градусов выглядит как 720р-пиздец с бикубиком.
А, тогда понятно, есть причины.
> явно давно запилили фигню какую-нибудь на нем, по типу magpie
Ну вот я нихуя не нагуглил. В ffmpeg есть поддержка CUDA, но там максимум что реализовали - аппаратный ланкош...
Как шейдером обработать видео я не нашел, вангую через avisynth что-то можно, но чувствую там пердолинг неимоверный будет.
>В ffmpeg есть поддержка CUDA, но там максимум что реализовали - аппаратный ланкош...
Supersampling же еще есть.
>вангую через avisynth что-то можно
Забыл кстати. Юзай hybrid от selur. Там куча говна с апскейлами через avisynth/vapoursynth. Но чтобы получить сборку с VSGAN как раз, про который говорил, надо писать разрабу, потому что весит дохрена.
Да и вообще через него кодировать приятно. Тыкаешь галочки и скрипт сам пишется, можно посмотреть в последнем окне. FFMPEG тоже конечно умеет через ави и вапор работать, но сам скрипт придется самому писать.
> ланкоша
>>3155773
> ланкоша
>>3155796
> ланкош
Заебал, ты специально в каждом посте это слово коверкаешь? Ланцош.
> hybrid от selur
Вот это то что я и хотел, благодарю. Но желаемого результата я всё равно не получил. Самое лучше что получилось - шарп aWArp + дехало + ланкош. 4К -> 8К в 10 фпс конвертит. А все быстрые нейросетки не справляются с моим мылом, хуже чем шарп + дехало выдают картинку. Топаз хорош, но там 2 секунды на кадр...
>>3155867
Не ебёт, мне ланкош нравится больше.
>Самое лучше что получилось - шарп aWArp + дехало + ланкош. 4К -> 8К в 10 фпс конвертит.
Ну тут уж ты много хочешь... 10 фпс отличный результат как по мне. Для реалтайма надо искать какие-нибудь шейдеры для плеера glsl по типу anime4k. Но ESRGAN конечно вообще конкурентов нет. Долго фиксили и тренировали, еще и самому можно тренировать.
>Топаз хорош, но там 2 секунды на кадр...
Это еще быстро. Я в 6 секунд кодирую. Знаю чувака, который купил 4 штуки 3090 на выходе ее, чтобы целые фильмы по 2-2.5 часа кодировать и апскйелить быстро. На что только люди не пойдут для дрочки на качество.
Я тоже однажды один видосик на 1:30 минуты конвертил месяц. без пизды. И еще признаюсь, сам фильм конвертил еще на старых версиях, уже тогда был слишком офигенный результат. Особенно для реальных людей, прямо все волосы, все реснички идеально дорисовываются как настоящие, как будто через ультрачеткую линзу фотоаппарата смотришь.
> Real-ESRGAN
Я тоже пробовал его обучать и тоже не мог побороть замыливание текстур. Обычный ESRGAN страдает овершарпом, а в Real как на твоём первом пике - забор полностью уничтожен, так и у меня часто бывало фоны просто нахуй удаляло, потому что у меня датасет со скудными фонами или вообще без них. А ведь если начну фонов больше делать, то он начнёт обучаться тому что мне не надо.
>а в Real как на твоём первом пике - забор полностью уничтожен
Ну так специально показали, чтобы знали что он агрессивный. Все-таки частицы мелкие прям.
> Но ESRGAN конечно вообще конкурентов нет
> проёбана сеть, по лестницам можно спустится в ад, с глазами в одной руке, потому что для просмотра подобного они не нужны
> Знаю чувака, который купил 4 штуки 3090 на выходе ее, чтобы целые фильмы по 2-2.5 часа кодировать и апскйелить быстро
Читал другого, который купил две 3090, но из-за глюков оборудования(у части пользователей программы вылетает в разные промежутки времени, у этого вылетает моментально) не может ничего апскейлить.
Есть ли большой гайд по кодекам со сравнениями, скриншотами и т.д.
Av1 лучший из лучших, h265 нормальный, vp9 медленное говно, h264 средний
> h265 нормальный, Av1 и vp9 медленное говно, h264 средний
>Av1 лучший из лучших
хорошая шутка
>h265 нормальный
пипитарный ж
>vp9 медленное говно
Но у тебя ав1 лучший из лучших!
>h264 средний
>средний
Белены объелся?
В том и дело что svt-av1 за одинаковое время выдаст файл выглядий лучше, чем vp9 (libvpx)
Да, средний, картинка начинает разваливаться в пиксельную кашу
Почему видеорелизы в HDR (BT.2020) нельзя просто взять и отобразить / проиграть в SDR (BT.709)? Почему всегда столько еботни и цвета все равно другие?
Я, считайте, павер юзер, но родом из мира цифрового аудио, а не видео. Звук, записанный с большей глубиной / битностью (16 бит vs 24 vs 32 бита на сэмпл), можно тупо обрезать / транкейтнуть по значениям и вот тебе будет 16, сделанное из 32. По вкусу - дизеринг, который желателен либо не нужен в зависимости от того, что там в 32-битном файле. Сами же значения сэмплов просто представлены с большей или меньшей точностью, в качестве интегеров или флоатов, но преобразование из одного в другое - вполне однозначное (пусть и с потерей качества).
А почему т.н. "HDR" картинку нельзя просто и однозначно превратить в "SDR"? Почему нельзя просто обрезать наиболее светлые и наиболее черные значения диапазона, которые выходят за рамки диапазона SDR, и уменьшить битность представления тех цветов/оттенков, которые таки входят в диапазон SDR, и получить ту же самую картинку, просто лишенную этой дополнительной точности?
Вот у меня видеокарта(?) и монитор(?) не умеют в HDR, и поэтому 4K-блюреи (которые почти все поголовно в HDR) выглядят серыми и блёклыми. На трекерах есть раздачи релиз-групп, которые конвертируют 4K HDR блюреи в 4K SDR рипы (либо 8-битный цвет и кодек H264, либо 10-битный и H265). В описании такого релиза есть умные слова, типа:
> Converted from 10 bit HDR to 10 bit SDR using tripple mixed Hable-Reinhard-JJ per scene+frame analysis algorithm
А в результате картинка отличается от релиза этого же самого фильма, но официального 1080p SDR от самой студии. Другие оттенки (больше всего заметно на красном) + немного потусклее + чуть-чуть более синее. Пикрил - один и тот же кадр из ремукса официального блюрея 1080p и из конверта HDR->SDR из блюрея 4K. Откройте в разных вкладках и пощёлкайте туда-сюда для наглядности.
В общем, какие технические препятствия мешают "однозначно" переводить HDR в SDR, пусть и с лосси потерей передачи наиболее насыщенных цветов и тонкостей полутонов? Почему оно ВОТ ТАК?
> А почему т.н. "HDR" картинку нельзя просто и однозначно превратить в "SDR"? Почему нельзя просто обрезать наиболее светлые и наиболее черные значения диапазона, которые выходят за рамки диапазона SDR, и уменьшить битность представления тех цветов/оттенков, которые таки входят в диапазон SDR, и получить ту же самую картинку, просто лишенную этой дополнительной точности?
Почему нельзя? Можно, тогда ты получаешь
> Вот у меня видеокарта(?) и монитор(?) не умеют в HDR, и поэтому 4K-блюреи (которые почти все поголовно в HDR) выглядят серыми и блёклыми
Ты же звуковик, была у меня как-то проблема перевести 5 или 7 к 1 в стерео и я знатно заебался, потому что простым конвертом получал еботерию в итоге поебавшись с кучей фильтров и не осилив задачу(конечно я бы смог, просто не захотел, утешаю себя я) пришлось скачать уже релиз в стерео и перемуксить звук. А всего то ебать, надо было все слить в 2 канала из 7, говно вопрос же
>потому что простым конвертом получал еботерию
Смотря что за "еботерию". Вообще в стерео (обычные L+R каналы) сводится, суммируя сигналы из каждого из оригинальных 5.1 или 7.1 каналов в нужной тебе пропорции. Но если авторы оригинального звука - криворукие ебланы, то могут вылезти неожиданные проблемы (принципиально похожие на моно-несовместимость у стереозвука, типа несовпадения фаз или еще какой-нибудь подобной хуйни).
> Почему нельзя? Можно, тогда ты получаешь
Ну, я предполагал, что HDR-цвет устроен как-то так: есть возможность закодировать значения оттенков от ЕБАТЬТЕМНО до ЕБАТЬЯРКО с точностью 1000000 возможных значений, а SDR - только оттенки от ТЕМНОНОНЕОЧЕНЬ до ЯРКОНОНЕОЧЕНЬ с точностью всего 1000. Тогда все возможные значения, которые есть в SDR, явным образом "содержатся в" списке возможных значений в HDR. И тогда при конвертации HDR->SDR ты получишь потерю точности передачи полутонов, а самые темные и яркие участки будут тупо черными и белыми, но сами значения, которые могут существовать в SDR, останутся такими, какие есть. И, возможно, всё вот это касается не только яркости, но и других параметров цвета.
А на практике я вижу, что:
- наивное открытие HDR-видео очень сильно колбасит цвета (неудивительно, ведь диапазон от условного 0 до условного 1 соответствует совсем разным диапазонам яркостей / других параметров цвета)
- шаманство релиз-групп, "переводящих" HDR-релизы в SDR, все равно ебет цвета и оттенки, пусть и не так сильно.
Я ожидал, что исходник HDR и сделанный из него SDR должны выглядеть одинаково на HDR-железе. А на скринах выше видно, что там даже красный цвет стал другим (хоть я смотрю на это и на SDR-железе). Грубо говоря, значение цвета 123.323 не округлилось до 123 или 120 (потеря точности), а стало каким-нибудь 156.
Ну внутрянок хдра я не знаю, никогда даже релизов таких не пробовал, хотя у меня и карта и монитор и кабель и даже виндевс поддерживает хдр, так что не смогу тебе пояснить как всё реально устроено и какими формулами нужно приводить цвета в сдр. Очевидно одно, подход в лоб не работает.
>хотя у меня и карта и монитор и кабель и даже виндевс поддерживает хдр
Вот те два скрина в пнг у тебя на таком сетапе выглядят по-разному, верно? На одном красный цвет в купальниках более малиновый, на другом более оранжевый, + очень легкая синеватая дымка поверх всего?
Из конвертера картинка лучше. Чуть тусклее, но зато больше деталей видно. В ремуксе детали либо недосвечены, либо пересвечены.
> Почему всегда столько еботни и цвета все равно другие?
Потому что это невозможно. У тебя в SDR просто меньше цветов, чем есть в 2020, это конверсия с потерями. Во всех плеерах разные алгоритмы конверта, но все они не идеальные.
> Почему нельзя просто обрезать наиболее светлые и наиболее черные значения диапазона, которые выходят за рамки диапазона SDR, и уменьшить битность представления тех цветов/оттенков, которые таки входят в диапазон SDR, и получить ту же самую картинку, просто лишенную этой дополнительной точности?
Потому что у тебя тогда будут дикие засветы/чернота, а цвета из HDR просто не существуют в SDR-пространстве, можно только примерно похожий влепить.
> отличается от релиза этого же самого фильма
Потому что маппинг цветов на SDR - дело выбора конкретного алгоритма и вкуса.
> Почему оно ВОТ ТАК?
Просто смотри на экране с поддержкой HDR10. Уже 2022 год, блять. Ты бы ещё спросил как в игре 2004 года сделать графон как в UE5.
Может быть и так, тут спорить не буду. Пожалуй, переформулирую мой вопрос так:
Вот у студии есть мастер-файл фильма на пару терабайт. Предполагаю, он 3840x1600 (2.35:1, "4K") и т.н. HDR. Это оригинальное финальное отрендеренное видео, из которого потом делаются видеопотоки для блюрея и прочих нужд.
Из этого мастер-файла сделаны:
- видео для 4K блюрея, 3840x2160 (с черными полосами до 16:9), "HDR"
- видео для обычного блюрея, 1920x1080, "SDR" с меньшим динамическим диапазоном цветов
Несмотря на то, что в версии "HDR" будут поярче самые яркие места и потемнее самые темные, плюс больше видно деталей и полутонов, красный цвет купальника Даддарио всё равно должен быть одного и того же оттенка? На железе с поддержкой HDR, если открыть оба видеофайла, цвета должны быть одинаковы?
В данном случае я вижу, что, когда (сторонняя релиз-группа) конвертнула 4K HDR в 4K SDR, съехали оттенки цветов. Съехали несильно, и я даже соглашусь, что это вряд ли важно, но разница с официальной 1080p SDR версией видна. В 1080p у Даддарио купальник с малиновым оттенком, в 4K - с оранжевым. Поэтому мой вопрос такой:
– получается, кто-то проебался при конвертировании HDR в SDR?
– проебалась студия при создании SDR 1080p блюрея, или проебалась релиз-группа, сделавшая 4K SDR из 4K HDR?
– как такое вообще возможно, что при уменьшении динамического диапазона (и глубины/точности представления) смогли получиться два разных результата, отличающихся цветами? Разве преобразование HDR->SDR не должно быть однозначным, приводящим к одному и тому же результату? Почему в одном случае исходный цвет из HDR-кадра стал малиновым, а в другом оранжевым?
Пока писал свой ответ тому анону (см. выше), ты успел запостить свой. Отвечу тебе:
> У тебя в SDR просто меньше цветов, чем есть в 2020, это конверсия с потерями.
> а цвета из HDR просто не существуют в SDR-пространстве
Да, это так, я в своих ночных сообщениях так и написал. Я вполне признаЮ, что пространство HDR шире (и, полагаю, более детализировано), чем SDR. Однако вопрос в том, почему у студии Paramount получился малиновый купальник, а у анонов из релиз-группы SWTYBLZ - оранжевый. Очевидно, оба получившихся цвета присутствуют в пространстве SDR. Но они же слишком далеко друг от друга, чтобы утверждать, что это разные способы округлить значение цвета из HDR-исходника до ближайших существующих цветов в SDR. Между этими двумя есть огромное количество разных цветов, можно градиент нарисовать.
> Потому что маппинг цветов на SDR - дело выбора конкретного алгоритма и вкуса.
Вот в этом и весь вопрос. В смысле блин дело вкуса? Если у меня есть число 0.256765765756 (очень точное, HDR) и мне нужно его округлить до сотых, чтобы записать в формате, где возможны только сотые (SDR), то я могу получить 0.25 или 0.26, в зависимости от метода округления, но никак не 0.42. Как здесь может быть "дело вкуса"?
Потому что цветовое пространство не линейное. А тебя один цвет при разной яркости выглядит по разному, например красный может варьироваться от черно-бардового в тени до бледно-бело-красного на свету. А тут у тебя при конверте яркость срезается в разы. Когда ты видишь серые скрины HDR-кинца - это и есть "просто линейно сдвинуть цвета", пикрилейтед. Вот в этом и есть вся сложность - подобрать подходящий цвет при том что яркость уже совсем другая, алгоритм же не знает какой там на самом деле цвет. Для этого пилят сложные алгоритмы, которые угадывают что красный на картинке при таком-то количестве нит должен выглядеть вот так при другом.
>маппинг цветов на SDR - дело выбора конкретного алгоритма и вкуса
Двачую. Это как проявка raw-фото в jpg. Идеального алгоритма не существует. Дело вкуса.
Алсо, я вот с плойки 2020 PS5 не умеет в SDR конверчу в 709 вот таким фильтром в ffmpeg:
> zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p
Получается видеорилейтед, на глаз цвета вполне похожи, хоть и не идеальны.
Да, я понимаю, что при - назовём это так - "наивном ужимании" всего более широкого диапазона HDR в SDR у тебя картинка будет серая и не контрастная, т.к. значения ультраглубокого черного (которых так-то мало) станут черными, значения темных цветов станут темновато-серыми, значения светлых цветов станут светловато-серыми, и только самый ярчайший белый станет белым.
Но я предлагал / предполагал не такое ужимание, а отсечение тех наиболее ярких и наиболее темных областей диапазона, которых нет в SDR, и округление оставшихся цветов до ближайших существующих в SDR. Вот нарисовал хуйню, см. пикрил hdr sdr 1.png (здесь имею в виду такое преобразование для каждой из компонент цвета, будь там HSL, YCbCr или что-то ещё).
Мне представляется, что это вполне однозначное и "повторяемое" преобразование. Если принять диапазон SDR за [0;1], то значение -1 из HDR сконвертируется в 0, -0.5 - в 0, 0 - в 0, 0.1111 - в 0.1, 0.52 - в 0.5, 0.77 - в 0.8, 1.2 - в 1, 100500 - в 1. Единственная возможность получить разные результаты в разных конвертерах - разные способы округления чисел (вверх или вниз или еще как, добавлять дизеринг или нет). То есть из 0.55 можно получить округление до 0.5 или до 0.6, но никак не до 0.9.
А на практике я вижу, что у Paramount и у пиратов SWTYBLZ получились разные цвета при конвертации в SDR, то есть одна из черепашек таки врёт. "Некий" исходный цвет из HDR стал малиновым у одних и оранжевым у других. То есть кто-то из них сделал так, как на моем ВТОРОМ пикриле hdr sdr 2.png.
> Это как проявка raw-фото в jpg. Идеального алгоритма не существует. Дело вкуса.
Аналогию я понял, и в мире звука / обработки сигналов такого полно (ну буквально ремастер с теми или иными целями) - но ведь это уже получается сознательное вмешательство во внешний вид кадра, а не просто сухая лосси-конвертация из более широкого диапазона в более узкий. Я понимаю необходимость color grading (?) при создании фильма, т.е. при обработке нейтральных исходных кадров с камеры, чтобы придать фильму нужный внешний вид, да хоть в желтый все покрасить, потому что у нас лето во Флориде. Но зачем художественное вмешательство при перегоне готового фильма из HDR в SDR?
P.S. Я понимаю, что это переходит в какой-то нездоровый аутизм и вы все можете спросить "да нахуя тебе это, анон" (и будете правы). Но замечаю такое в SDR-релизах уже не в первый раз + логика этого разнится с привычной мне логикой обработки сигналов из мира звука, где лосси-перегон в формат представления с меньшей битностью или частотой дискретизации является вполне хорошо определенной и предсказуемой операцией, а все сознательные художественные изменения результата - совершенно отдельный процесс, не нужный при конвертации).
> отсечение тех наиболее ярких и наиболее темных областей диапазона
Так ты не знаешь оригинальную нелинейность гаммы. Ну отсёк ты его по краям, а в центре у тебя всё равно цвета не маппятся в нужные. В любом случае это "по вкусу" на глаз будет подгоняться, либо извращённой хуитой типа нейросетей.
>а в центре у тебя всё равно цвета не маппятся в нужные
В смысле не мапятся? Я понимаю, что HDR содержит 100500 оттенков красного, а SDR - только 100. Неужели нельзя мапнуть цвет на ближайший существующий в SDR красный, а не на какой-то еще другой красный?
Или вот в этих словах...
> ты не знаешь оригинальную нелинейность гаммы
...ты имеешь в виду, что восприятие картинки глазом зависит от кривой гаммы экранов у тебя и у монтажёра в его оригинальной студии, и поэтому на мониторе с HDR оригинальный красный из HDR-видео и красный из одного из этих SDR-видео будут выглядеть одинаково на глаз?
И означает ли это, что, так как монтажёр фильма (и софт на его компе) знают "оригинальную нелинейность гаммы", то SDR-версия, которую он сделал вручную(?) в своей студии как раз выглядит идентично HDR-версии на его экране в том, что касается цветов, пусть и с потерей детализации градиентов и самых ярких и темных областей?
Можешь пояснить за параметры?
>И учитывая что тегов в wav нет
Foobar умеет записывать в вавки так называемый RIFF INFO Chunk, который поддерживает все стандартные поля типа артист, тайтл, элбум и прочее. Это читается как теги и фубаром, и винампом, да и много ещё чем.
- мимокрок, знаю, что некрореплай
> ты имеешь в виду
В том смысле что при съёмке цвета маппятся определённым образом. Когда ты не знаешь как их смапили, ты не знаешь какой там оригинальный цвет. Соответственно ты не можешь просто смаппить его в другое цветовое пространство, только "на глаз" подогнать. Ты ещё учти, что у алгоритма конвертирования нет "глаз", чтоб посмотреть похоже оно на то что в HDR или нет. И так же учти что по хорошему надо не срезать по краям диапазон, а сжимать а так всегда делают с кинцом и делают, что тоже цвета смещает.
>>3158313
Ну там самое главное tonemap=hable. На пиках - хабл и ACES смаппленные RAW->HDR->SDR, и оригинал - смаппленый RAW->SDR.
>по хорошему надо не срезать по краям диапазон, а сжимать
Если честно, это меня как раз здорово смутило в твоем предыдущем сообщении, и как раз по этой причине. Если сжать весь диапазон от самого темного HDR-цвета до самого яркого в SDR-диапазон от умеренно темного до умеренно яркого, то как и получится типичная серая блёклая картинка, как ты запостил скрин выше вот тут >>3158278 , потому что "просто темные" оттенки уедут в темно-серые, а "просто светлые" в светло-серые.
Если тот человек, который делал для Paramount 1080p SDR версию для блюрея, в своей студии откроет на экране в видеоплеере оригинальный фильм HDR и свою SDR версию, то малиново-красный цвет купальника там будет выглядеть одинаково (если он сознательно его не перекрашивал)? А, в свою очередь, более "оранжевая" версия от SWTYBLZ будет выглядеть на его экране неправильно? Но при этом где-то в мире существует монитор, на котором как раз "оранжевая" версия от SWTYBLZ выглядит так же, как HDR - по крайней мере, по мнению алгоритма в том кодеке, который они применили?
Вдогонку, по поводу слов про нелинейность гаммы. В играх, даже в старых, вышедших задолго до эпохи HDR, нередко есть настройка гаммы, от "ебать темно ничего не видно" до "всё серое и выцветшее". Это как-то связано со всем этим? В том смысле, что итоговую похожесть картинки на некий идеальный референс (цветов, яркости и пр.) все равно определяет только индивидуальная настройка под конкретный монитор?
> потому что "просто темные" оттенки уедут в темно-серые, а "просто светлые" в светло-серые
Для этого и надо маппить нелинейно, как на пикрилейтед. А если срезать, то теряются детали на засветах/черноте.
> "оранжевая" версия от SWTYBLZ выглядит так же, как HDR
Она нигде не выглядит так же, просто тот васян не хотел или не мог сравнить с HDR на глаз. А алгоритм не может "видеть", ему для этого нужен какой-то внешний референс чтоб сравнивать.
>А если срезать, то теряются детали на засветах/черноте.
Теряются, но хуле поделать, это ограничение конечного формата. Так-то и при перегоне из HD в 320x240 теряются детали изображения. ¯\_(ツ)_/¯ Идея понятна, но не уверен, что "согласен" со средствами достижения цели. Вот на моих скринах из Baywatch в версии 1080p SDR плохо видно детали пейзажа за окнами, потому что ярко и засвечено. Но тут, как бы, а хуле поделать-то? Заметно менее яркая / более детальная прорисовка задника будет выглядеть странно, потому что глаз человека ожидает огромного контраста между людьми в помещении и ярким пейзажем снаружи.
кстати, этот задник - графон, на самом деле за окнами был зелёный экран
> А алгоритм не может "видеть", ему для этого нужен какой-то внешний референс чтоб сравнивать.
А что, реально взять HDR-релиз в 3840x2160, скормить его алгоритму и дать в качестве референса официальный блюрей SDR 1920x1080, чтобы сохранились оттенки цветов и яркость? То есть, "возьми детализацию из 4K HDR релиза, а по поводу цветов сверяйся с 1080 SDR"?
Сам я вряд ли буду этим заниматься, но если да, то странно, почему так не делают.
Да. Всё серое - это ты получишь если смаппить линейно. Можно смаппить по нелинейным, типа хабла или ACES, но как видишь там тоже не попадает в цвета.
> в старых, вышедших задолго до эпохи HDR, нередко есть настройка гаммы
Только формулы разные бывают. Там может быть сильно сложнее квадратичной функции.
Под референсом я имею ввиду изображение этих двух форматов в каком-то одном. Например RAW-фото картинки на экране в HDR и SDR. Это то что ты на глаз можешь сделать и алгоритм - нет.
Не много не по теме, но я сравнил твои скрины, и пришел к выводу, что релиз группы картинка лучше.
Во первых там контрастность будет выше (из-за чего сиськи выглядят объёмнее).
Во вторых на твоей 1080p SDR кожа зеленит. А у транскода нет этого избыточного зелёного, из-за чего кожа выглядит более загорелой. (Хотя кто его знает, как оно там объективно по цветам. У меня TN монитор, мог и перекосоёбить цвета.)
Ну почему не по теме, норм.
Но мне кажется, что у релиз-группы получилось темнее и заметно холоднее. Особенно хорошо видно на пейзаже за окном и на серой вертикальной поверхности стола позади ног. 1080 с блюрея теплее и ярче, чуточку желтоватый. 4K SDR от релиз-группы холоднее и тусклее. (а вот кожа таки да, немного зеленоватая в 1080 и немного красноватая в 4K).
Имхо, главный минус самопального HDR->SDR от SWTYBLZ - голубоватая дымка, которая покрывает всё. Видел такое и в других их релизах. Насколько это заметно при просмотре человеком, который не видел "тру референс" в виде официального 1080 SDR с блюрея - хз. Насколько это "важно" - тем более хз. Но при сравнении эта разница очевидна.
Аргумент про контраст и сиськи важный, да. :D
Вообще, возможно, Baywatch был не лучшим примером для вот этого всего, т.к. в этом фильме 4K - фейковый и просто апспкейл из 2K, это хорошо видно при рассмотрении деталей кадра в настоящем масштабе 1:1 на экране, всё либо мыльное, либо "лесенки" идут отчетливо с шагом в 2 пикселя, особенно обводка зеленого экрана вокруг плеч Скалы. Но существуют и честные 4K фильмы. Тащемта, всё вот это вот началось с того, что я решил сделать гифку с Даддарио и полез за качественным исходником.
А нахуя нам это видево?
Полюбоваться артефактами aomenc на битрейте 80 kbps, и, возможно даже, словить артефакт компрессии от libopus 80kbps.
-a " -c:a libopus -b:a 80k " -v " --cpu-used=2 --sb-size=64 --end-usage=vbr --target-bitrate=80 --aq-mode=1 " -ff " -vf scale=320:-2 "
Иди нахуй со своим авианом ебучим
В чём причина того что ты сагрился на av1an?
То что это ненужный хохляцкий костыль, svt-av1 нагружает все ядра без всякой хуйни
Так ведь svt даёт не такую качественную картинку как aomenc. Или у тебя пунктик на хохлах?
>-c:a libopus -b:a 80k
Просрал весь битрейт на опус, хотя вплоть до 17кбс не слышно даже значимых артефактов, сам проверял. Сейчас мб даже лучше.
>--cpu-used=2
не максимальные настройки nuff said
>--aq-mode=1
не mode 2
И как я понял еще без 2pass.
Учись, сынизде. При этом сделано на древней версии 1.5 года назад.
Заебись научил, чо.
> И как я понял еще без 2pass.
У av1an для aomenc там по дефолту стоит 2pass.
> Просрал весь битрейт на опус
Для music video самое то. Твои 17 kbps годятся разве что для говорящих голов.
>>--aq-mode=1
>не mode 2
просвети, в чём разница?
Ситуация аналогичная посту выше. Хотя моё видео у меня открывается.
В общем посмотрел я твоё видео. 48 kbps это конечно мощно, но для 360p этого очень мало. В своё время 3gp с таким битрейтом кодировали, так там разрешение было около 144p, и всё равно шакалы лезли.
>>3158864
фурифокс чушки как всегда SOSNOOLEY.
Вероятно потому что нет поддержки mkv. В хроме есть.
> Вероятно потому что нет поддержки mkv
Оба видео matroska,webm, у них только одно не открывается.
ну фиг знает. У меня тоже некоторые с mkv не открывались. Может из-за тегов. Danmachi webm переведена с mkv орига.
Не будь скорбным хромодауном.
Поздравляю. Ты попался под влияние софтошиза. Для обратного становления человеком форматно диск нулями и поставь софт для белых людей, а не рабов пердоговна.
> Вероятно потому что нет поддержки mkv
Ну не совсем. То видео успешно проигрывается ровно 2 секунды. После чего - то, что на скрине.
Можешь сделать ещё ярлык Open page in Chrome.
А мне это не нужно делать, дегрельный. Для особо одарённых объясняю: те сайты, которые макаки пишут только под сром в лисе запускаются в рамках расширения webcompat, так что не серь подсибя больше так обильно.
Благо, такого говна критически мало, то есть, для ff пользователей не плачевно.
Набери about:compat и убедись.
> сделать ещё ярлык
И это не ярлык, дегрельный.
Но кодеки гугла даже рядом не стоят по возможностям с h.264.
Что такое квантование ты можешь почитать и в википедии. Квантование изображения приводит к уменьшению глубины цвета.
Другое дело, если перед квантованием произвести какое-то преобразование изображения. Самое популярное преобразование это ДКП. А вот уже квантование ДКП коэффициентов приводит к другой, менее заметной деградации изображения. Хотя практика применения JPEG показывает, что большой квантователь также приводит к уменьшению глубины цвета.
скачай обс и не пердолься.
>>3151250
>>3151147
>>3151137
Возвращаясь к этому обсуждению кодека TAk:
Сегодня захотел записать длинный текст в комментарии к альбому flac-файлов. Плеер - Foobar2000, для просмотра тегов использую плагин Text Display - в дефолтном просмотрщике тегов много мусора (MD5 суммы, например), который никак не скрыть, Text Display же полностью настраивается. Текст был по большей части на русском языке. Сохранив тег, я этот текст не увидел. Перевёл на английский язык, вставил - текст виден. Короткие тексты на русском были видны. И, кажется, многострочные тексты в комментарии не показывались, если на русском.
Виной проблемы был плагин - через редактор тегов, встроенный в foobar, эти теги видны.
Однако, я вставил тот же длинный русский текст в комментарий к mp3-файлу. И в mp3 он виден.
Перекодировал flac в tak, перенёс теги. Текст на русском стал виден вне зависимости от длинны. Ещё и парочку мегабайт сэкономил.
Вывод - TAK намного лучше работает с тегами, FLAC - попущен.
> FLAC - попущен
Скорее ты, так как не осилил Vorbis Comments, а делал всё через ветпаськи, бгг
И где я должен был найти решение проблемы с Vorbis Comments? Я ведь даже не знаю, что это за проблема - в тегах, в кодировке, или в том как разные программы читают теги, или в чём-то ещё. Я просто не знаю, куда копать, у меня нет вводных, чтобы вбить поисковый запрос и найти информацию о решении проблемы.
>ветпаськи
Что именно ветпаська, и по какому критерию? Для меня ветпаська - это CCleaner, Avast, Driver Booster.
> Что именно ветпаська, и по какому критерию?
Вот это:
> плагин Text Display
> дефолтном просмотрщике тегов foobar2000
А вот это:
Не ветпась.
>> плагин Text Display
Позволяет смотреть только нужные мне теги, а не всю существующую в компьютерном мире хуиту, от файлового пути до md5-сумм (очень нужно во время прослушивания!).
По твоей логике и компьютеры не нужны - это одна огромная ветпась! У людей есть калькуляторы и пишущие машинки, значит компьютеры нинужны. Вообще, технический прогресс нинужон.
Ну сиди тогда без нормальных UTF-8 тегов стандарта теггирования кодеков от Xiph.org, используя вместо этого васянский суррогат.
Предпочту легковесные TAK-файлы в сочетании с удобным Text Display.
vorbiscomment только для ogg файлов, судя по
>Failed to open file as Vorbis: Input is not an Ogg bitstream.
>В хомке
Файл из исходников?
>собери свежую версию vorbis-tools
Не знаю, как.
Из-за чего произошла проблема, с которой я столкнулся? Из-за кодировки (доисторическая кодировка, не выдерживает много букв кириллицы)?
Кодировка UTF-8, если через Vorbiscomment делать, так как этот стандарт предусматривает кодировку UTF-8. Скорее всего, твой плагин в какой-то другой кодировке это пишет, иди стандарт теггирования применяет другой.
>Скорее всего, твой плагин в какой-то другой кодировке это пишет, иди стандарт теггирования применяет другой.
Мой плагин - Text Display - показывает теги в удобном настраиваемом окне. Теги записывал через Properties в контекстном меню Foobar2000. Через Mp3tag так же записывал. Через metaflac так же записывал.
Проблема в том, как Text Display читает теги. Но в mp3, tak, и возможно других форматах, он читает тот же самый текст. А вот во flac вместо текста - точка. Я лучше перекодирую свою музыку в TAK, параллельно сэкономив на дисковом пространстве, чем буду наворачивать дефолтный кал и каждый раз отвлекаться на ненужные мне мне данные, которые никак не скрыть.
Ахаха! Дефолтный вьювер тегов Selection Properties тоже не осиливает длинный текст на кириллице, вот только не осиливает его ни в одном формате - flac, mp3, tak. Text Display этот текст только в flac не осиливает. Оригинал оказался хуже "васянки", бгг.
Ваш DA не DA, а Made in China переделка оригинала.
Я в курсе что порт порезан, но хоть графон завезли на бета версии трехи (2.5). Серия именно с этой части стала многострадальной хуйней, конвикшн они вообще три раза с нуля переделывали, лол. Итого вышла опять темной сранью после светлой DA, чего не скажешь про изначальные дропы концептов конвикшн, которые в каких-то журналах были показаны бомжом главного героя.
> Итого вышла опять темной сранью после светлой DA
Оригинальная DA была тёмной. Это в китайском порте все миссии днём сделали, что порушило весь концепт SC.
Я в курсе, мне это наоборот зашло. В киношном блэклисте тоже светло, как и в дропнутой версии конвикшна.
>DA
Саунд дизайн там кстати хороший. Еще и free dl от автора, но lossless не сливает, жадина https://michaelmccann.io/projects/splinter-cell-double-agent-soundtrack/
Говорят у будующих Intel ARC будет аппаратный кодировщик AV1. Да, немного не по теме, но аппаратное кодирование AV1 сделает ненужным кодирование в VP9.
> Какое железо нужно для быстрого кодирования VP9?
Без разниц, хватит средней мощности это говно все равно не умеет в распараллеливание ресурсов, ядер и нагрузки на них.
> Есть ли поддержка ускорения этого кодека у нвидиа?
Нет, только у интуля вроде есть в последних процессорах.
>пик
А качество у нвидии не хуже?
Software > Nvenc > QSV > AMD VCE
> если ресайзить видос с сохранением пропорций, то не всегда это возможно из-за того, что одна из сторон будет не целым числом.
А ты возьми и округли до целого. ffmpeg должен в метаданных прописать истинное соотношение сторон.
> только у интуля вроде есть в последних процессорах
Интересно как на плойке аппаратное кодирование в VP9 работает. Там же фактически рязань стоит.
С помощью GPU, дегрельный.
Почему тогда на пука нельзя?
Есть какой-то простой метод как это сделать, или проще будет тупо скачать с торрентов в другом формате даже с учётом затрат времени на поиск?
Ты бы ещё конечную цель написал. Уж явно не со скуки ты это придумал.
>проще будет тупо скачать с торрентов в другом формате даже с учётом затрат времени на поиск?
Конечно проще. Сотни гигабайт ты будешь рендерить на своей домашней пеке до второго пришествия, если есть цель сохранить качество.
Купил телик а он дивикс не читает, а у меня коллекция киношек на внешнем харде вся по пизде из-за этого.
> Конечно проще.
Я подозревал, но надеялся вдруг есть простой выход.
Если так ценна коллекция, то купи приставку, которая читает то что тебе нужно. А может на телик можно поставить приложение, которое читает? Я с теликами не очень.
Это и есть самый простой выход.
Просто берёшь и без задней мысли кодируешь, не понимаю твой вопрос, делай 1 фреймовые видео циклом, затем циклом обратно все видео в пгн гони или что ты конкретно хочешь?
Что за нейросеть?
ffmpeg -i 1.mkv -vframes 1 -c:v libx264 out.mkv
ffmpeg -i out.mkv out.png
>>3166787
> делай 1 фреймовые видео циклом
> ffmpeg -i 1.mkv -vframes 1 -c:v libx264 out.mkv
Можете примерно почувствовать сколько будет конвертить 10к хайрез пикчей таким способом? Если сутки, то это не мой вариант я это буду делать явно не раз и не два, в жипеги я за 30 минут жал скриптом на C#.
> Что за нейросеть?
Real-ESRGAN, на жипегах уже сделал 500к итераций, результат получился сильно лучше топаза.
> Можете примерно почувствовать сколько будет конвертить 10к хайрез пикчей таким способом
Ну 7к хуйрез из png в webp lossless у меня что-то вроде получаса на 3.6 хасвелле ушло, не думаю, что в 264 дольше будет кодировать. В любом случае поставь, да посмотри, устраивает тебя время или нет. Других вариантов особо не видно.
X264 хорошо масштабируется. Время кодирование целиком зависит от твоего процессора.
Если 10000 картинок лучше их конвертировать как непрерывное видео, для честности с -g 1, каждый кадр будет сжат по отдельности
Получается всего 5 минут и сжиматься будет минут 10-15
Нужно взять пачки по 50 кадров, объединить в отдельные кадры (просто среднее по 50 кадрам, чтобы шум убрать), и после склеить в нормальное видео из таких кадров.
Я бы мог разрезать на отдельные кадры и сделать вручную программой, но по оценке разрезанное на картинки видео будет занимать около 300 гб - у меня столько нету. А если я просто ставлю фпс в 0.1, то он скипает кадры, а не берёт среднее по кадрам.
Есть функция, которая такое умеет?
Может есть биндинг ffmpeg под питон в котором я смогу разобраться (в идеале - мне нужна функция "извлечь кадр из исходного видео" и "записать кадр в выходное видео") и где смогу такое написать и он без сохранения на диск сможет объединять группы кадров и записывать обратно? Посоветуйте что-то, пожалуйста. В описании всяких фильтров по типу fps или setpts ничего не вижу.
Чё вообще еблан? Это называется frame blending https://unix.stackexchange.com/questions/178503/ffmpeg-interpolate-frames-or-add-motion-blur
Я то откуда знаю как это называется?
Я могу написать код, если у меня есть массивы пикселей, а догадаться как это люди назвали...
Спасибо, сработал tmix как надо.
А подскажешь ещё штуку? Нужно из кадров получать среднюю яркость, и видео затемнять-осветлять выравнивая отдельные кадры до одинаковой яркости. Если оно как-то сможет сделать это интеллектуально не просто умножая яркости на 0.8, а правя кривые и делая гистограмму более равномерное - то только лучше. Хотя и тупое умножение на 0.8 или на 1.2 подойдёт, даже если там светлые части засветятся, главное чтобы средняя яркость всего кадра была такая же.
А почему tmix а не tblend?
Не, такую шизу я вообще не знаю
Потому что tblend интерполирует 2 кадра и дорисовывает промежуточные между ними, насколько я понял, больше нужно для увеличения фпс (по крайне мере такое было в примерах использования tblend)
А tmix именно что складывает (или проводит другие операции) над группами кадров - там было именно то, что мне нужно, и даже операцию сложения можно было указать, зачем что-то ещё искать?
Запись видео и кодирование на видеокарте
Аноним (Microsoft Windows 10: Firefox based)
26/06/22 Вск 13:19:55
№
303
Какие параметры использовать для записи видео?
Как скомпилировать FFmpeg с поддержкой nvenc? На сайте Nvidia пишут, что для этого нужны тяжёлые программы git и mingw, а для Visual Studio и вовсе нужен аккаунт майков, чтобы скачать. Сборка gyan.dev, пишут, поддерживает nvenc, но у меня ошибка:
>Unrecognized hwaccel: nvenc.
>Supported hwaccels: cuda dxva2 qsv d3d11va
а если использовать -hwaccel cuda, то качество будет супер-низким.
Помогите разобраться, аноны.
>Как скомпилировать FFmpeg с поддержкой nvenc?
А тебе точно не подойдут готовые бинарники, которые уже его поддерживают? Если ты просто хочешь записывать видео, а не компилировать всякое - obs уже умеет писать через nvenc уже больше пяти лет точно.
>Имеет ли смысл
Да, некоторые игры ты в 60 фпс другим способом и не запишешь толком. Но соотношения размера файла и качества очень плохое, это как h264 с ultrafast-пресетом
>Какие параметры использовать для записи видео?
Ставь режим с постоянным параметром квантизация (-vcodec h264_nvenc -rc constqp -qp 20) с циферкой порядка 15-25, лучший режим для записи, так как вне зависимости от динамичности сцены и разрешения оно возьмёт битрейта сколько понадобится. Более продвинутый crf на видеокарте не работает, к сожалению.
Не надо записывать видео через ffmpeg, для этого есть Nvidia experience
>А тебе точно не подойдут готовые бинарники, которые уже его поддерживают?
Не подойдут - как я писал выше, моя сборка не поддерживает hwaccel nvenc. Ещё не поддерживает filter:v scale_npp . То есть в сборке нет компонентов, отвечающих за работу с чипом записи в карте.
>Но соотношения размера файла и качества очень плохое, это как h264 с ultrafast-пресетом
Грустно.
И ещё один вопрос - как записывать аудио вместе с видео? Через gdigrab звука нет. И что лучше - gdigrab или dshow?
Говнина, болтающаяся в фоне. Оффлайн-программа, требующая логина, в принципе не достйна находиться где-либо, кроме как на помойке.
Ебать дебил
Она потребляет намного меньше ресурсов чем ffmpeg и obs при записи
>>3168180
С помощью этой штуки можно собрать со всей этой нвидиа хуйней, я пробовал https://github.com/m-ab-s/media-autobuild_suite
>Nvidia experience
Убогое нестабильное говно, которое ещё и дрочит диск постоянно, так как не может писать в оперативку.
Это тупо для домохозяек. Минимум опций, из коробки что-то там вроде как пишет и похуй. Проигрываю, когда всякие ИгРоВыЕ ЖуРнАлИсТы со стопгейма жалуются "ой, у меня вот почему-то нормально не захватывалась игра" и на футажах потоянно проблёскивает рабочий стол сквозь игру и постоянно видно значок записи, который вообще захватываться не должен.
Я уже не говорю, что с obs я пишу отдельно звук игры, винды, микрофона, voip, плеера. Причём сейчас для этого есть плагин, который позволяет перехватывать звук конкретного приложения из виндовской апишки, хотя я это делаю с помощью войсмитра.
>>3168039
Ставишь OBS studio и выбираешь кодировщик NVENC? Что за изобретение велосипеда ты там устроил?
>Она потребляет намного меньше ресурсов чем ffmpeg и obs при записи
Каких ресурсов ещё? Мы про те 3% процессора, которые потребляет OBS при записи нвенком или ты мои кудах ядра решил поберечь?
> Убогое нестабильное говно, которое ещё и дрочит диск постоянно, так как не может писать в оперативку.
Долбоеб, у тебя 100 Гб оперативки?
Можно выбрать рамдиск
> Я уже не говорю, что с obs я пишу отдельно звук игры, винды, микрофона, voip, плеера. Причём сейчас для этого есть плагин, который позволяет перехватывать звук конкретного приложения из виндовской апишки, хотя я это делаю с помощью войсмитра.
А так же домофона, уличной камеры, соседского жучка, первого канала и объявления электричек
>>3168400
Обс отжирает 20-30% ГПУ при записи в отличии от нвидии
В чём причина истерики? Ты лично для нвидии это говно писал или что?
Нет. Он просто верный подсос невидии.
>Обс отжирает 20-30%
Да.
>в отличии от нвидии
Нет, точно так же. Затестил сейчас. Диапазон точно такой же. Кадется у нвидии в среднем на пару процентов меньше, но это в рамках погрешности.
>что с obs я пишу отдельно звук игры
Оно научилось? Подскажи как такое включить?
>>3168461
>Долбоеб, у тебя 100 Гб оперативки?
А какой у тебя битрейт? 20к? 1 гб всё ещё хватит на 5ять с лишним минут видео.
>Обс отжирает 20-30% ГПУ при записи в отличии от нвидии
Это очень странно, в чём смысл видеокартовского энкодера, если в одной программе оно потребляет меньше ресурсов чем в другой?
Ещё как вариант там пресет nvenc стоит самый плохой и риалтаймовый, это и оправдывает пару процентов...
Ну и счётчики gpu врут - ты запустишь одну программу, где рисуется два квадрата двухмерных - и это съест 20-30 процентов gpu, потому что оно не может корректно определить нагрузку на себя.
> Это очень странно, в чём смысл видеокартовского энкодера, если в одной программе оно потребляет меньше ресурсов чем в другой?
В том что обс делает дополнительные операции, он ещё рисует сцену чтобы можно было добавлять оверлеи и другие штуки
> А какой у тебя битрейт? 20к? 1 гб всё ещё хватит на 5ять с лишним минут видео.
50 мегабит нвидиа рекомендует для обычного качества 1080p
>Оно научилось? Подскажи как такое включить?
https://obsproject.com/forum/resources/win-capture-audio.1338/
Но я делаю иначе. У меня стоит voicemeeter. Он добавляет в систему три виртуальных аудиоустройства и микширует с них звук уже на реальное физическое. Программы разные вывожу на разные устройства и пишу их. Но, если нужна только запись, то плагина хватит.
>>3168766
О нет! Что же делать? Может писать на диск в таком случае? В контейнер mkv, потому что мп4 при некорректном сохранении тебе ручкой помашет. Можно в mkv в хуитке от нвидиа сохранять?
>>3168765
>50 мегабит нвидиа рекомендует для обычного качества 1080p
Не рекомендует, а не позволяет поставить больше. Не говоря уже об отсутствии cqp.
>50 мегабит нвидиа рекомендует для обычного качества 1080p
Это абсолютный оверкилл даже для шутера со вращающимися сценами постоянными. Если про программный h264 речь.
И я хочу режим по типу crf - с постоянным качеством, который адаптивно подстроит битрейт под сложность сцены, фпс и размер кадра. Постоянный битрейт нужен только для стримов, где нужен примерно равный битрейт, чтобы не было буферизаций и поток данных был ожидаемый. Хотя по факту на тот же твитч можно стримить в crf-режиме с переменным битрейтом, и всё работает без особых проблем. По крайне мере работало 2 года назад.
>>3168776
>Он добавляет в систему три виртуальных аудиоустройства
А дополнительной задержки в 50 мс условных не возникает?
>А дополнительной задержки в 50 мс условных не возникает?
Возникает задержка, не помню насколько большая. Писал в обс микрофон напрямую и на выходе войсмитра, потом в видеоредакторе смотрел дорожки. Задержка не большая, но мониторинг себя сделать не получится. Хотя его никак через винду не сделаешь. Если на твоей карте есть ASIO (настоящий), то задержки будут ниже.
Это для пердоликов и шизиков. Если задача только писать звук на разные дорожки, то всё что нужно это обс+плагин.
>Это абсолютный оверкилл даже для шутера со вращающимися сценами постоянными. Если про программный h264 речь.
Какой програмный, если мы тут рендер на гпу обсуждаем?
>И я хочу режим по типу crf
CQP в obs. Это не crf, но с задачей справляется.
> Как скомпилировать FFmpeg с поддержкой nvenc?
Я тебе скинуть могу, либо используй ffmpeg media suite он сам всё соберет, ты только выбери галочки, только долговато еще.
> Причём сейчас для этого есть плагин, который позволяет перехватывать звук конкретного приложения из виндовской апишки, хотя я это делаю с помощью войсмитра
А какой плагин то юзал? Я просто пердолю через воисмитер тоже, но там ведь самая минимальная задержка по всем каналам у меня получилась 480мс. Довольно много по звуку задержка.
> Да, некоторые игры ты в 60 фпс другим способом и не запишешь толком. Но соотношения размера файла и качества очень плохое, это как h264 с ultrafast-пресетом
Хреню не неси людям тут. Давно обсудили, что качества уровня x264 ~medium-fast, на высоких битрейтах так тем более пох.
Вот и получается, что обс на винде использует стандартные апи, которые фпс жрут.
Еще по дефолту в GFN стоят хорошие высокие настройки качества с достаточно хорошим весом, зато четкая картинка, когда он не тупит. Настройки вроде только через реестр можно сменить.
Поэтому пишу через nvenc obs в 12-14к битрейта для фуллхд. 20мин видео апекс с кучей движения всего 1 гиг весит, на уровне или чуть выше ютуба.
Это вообще не уровень Ютуба лол
>технология нвидия по захвату экрана, который качественный и не забирает фпс вообще есть только в geforce experience на винде
Пиздабол.
FFmpeg умеет
https://docs.nvidia.com/video-technologies/video-codec-sdk/ffmpeg-with-nvidia-gpu/
RTSS умеет
https://www.guru3d.com/files-details/rtss-rivatuner-statistics-server-download.html
>and hardware accelerated H.264 encoding via Intel QuickSync, NVIDIA NVENC
> который качественный и не забирает фпс вообще
Это все лосслесс vfw-кодаки делают, тот же lagarith. Шизище...
Так же OBS:
https://www.nvidia.com/en-us/geforce/guides/broadcasting-guide/
>Encoder: Hardware (NVENC).
Поясните, есть ли открытые легкие кодеки, которые не теряют качество? Думаю, может весь зоопарк формат своих домашних видео привести к единобразию и место уменьшить, или без потери качество не удастся сделать?
Ну и нахуя ты мне энкодинг nvenc притащил, дибилоид. В слова хоть вчитывайся.
>Это все лосслесс vfw-кодаки делают, тот же lagarith. Шизище...
И что это? К чему это? Кто из нас шиз-то?
никому не нужно что ли?
> никому не нужно что ли?
Это
но ведь AV1 мыльное говно писал один плеч итт
количество физических ядер или количество потоков (логических процессоров)?
-preset 0 - качественнее жмёт или качественнее картинку не портит
как сделать, чтобы не было мыла?
ав1 так же нахуй никому не нужен
толкьо av1, только хардкор?
Не имеет к количеству ядер никакого отношения. При больших значениях он жмёт быстрее, но хуже, и наоборот, при маленьких значениях жмёт дольше, но лучше.
а качество картинки зависит от CRF, да?
а кто-то пробовал жать с пресетами 1-3. как долго?
это цветовой охват?
нет смысла конвертить из 709 в 2020?
ну я в Davicni вижу настройку этой штуки. там есть 709, 2020, вроде 601
что из этого выбирать, если сорц - ролики из порнолаба?
-svtav1-params
?
Unrecognized option '-svtav1-params'.
Error splitting the argument list: Option not found
С этими параметрами не начинался кодинг
Это тоже самое что просто увеличить разрешение у картинки с низким разрешением. Конвертнув в 2020 цвета же останутся от 709
Что у тебя за древняя версия ffmpeg? Обнови, у неё намного лучше качество
Нужно существенно повысить глубину цвета что-бы прежние цвета сохранились без искажений.
ffmpeg version 5.0 - у меня вот эта. а какая последняя. на сайте эта
>>3171317
пью арипипразол
Пока нового аппаратного кодека не запилят, либо пока h266 не будет таким же быстрым как h264 и лучше качество, значит ненужны.
> там есть 709, 2020, вроде 601
Это цветовое пространство. 709 для hd fullhd, 2020 4k, 601 вроде всё что ниже hd.
> soft pulldown
аппаратный не раньше 5000 серии geforce
Причем, какой-то конвертер на базе ffmpeg кодирует без проблем.
>какой-то конвертер на базе ffmpeg кодирует без проблем
Запускаешь его конвертить длинный файл, открываешь процесс ffmpeg и смотришь параметры командной строки, при помощи Process Explorer или Process Hacker. Потом просто запускаешь ffmpeg отдельно с теми же параметрами.
> ab 128k
> пук пук у нас ошибка
Пользовался бы ты консольным ffmpeg, он бы тебе выдал что-то вроде invalid option "-ab", после чего ты пошел бы гуглить мануалы и узнал бы что этот параметр пишется как -b:a.
> -strict -experimental
> -q:v
Зачем?
>>3174421
Набуя? Все адекватные проигрыватели умеют в интерполяцию. Ты этим только увеличишь размер файла и обосрешь качество.
В интерполяцию по векторам движения как это делает -vf minterpolate? Я пробовал запустить mpv с таким фильтром. Скорость рендеринга кадров делает невозможным просмотр видео в реалтайме, поэтому без кодирования тут не обойтись.
https://nmkd.itch.io/flowframes попробуй это
Может как хочешь писать, дэбил.
Спасибо лучший
Если тупо аниме смотреть в плеере, то SVP. Еще есть старые interframe тот же SVP, и также старый framerateconverter. Сейчас есть RIFE, который во flowframes есть, лучший на сегодня, еще и быстрый пипец, правда фиксить мануально надо. Либо через avisynth/vapoursynth пердолить, либо в hybrid от selur. Раньше был еще супер медленный DAIN. Другие внимания не стоят пока.
Как это не нужен? Тот же aomenc --cpu-used=5 сравним с медленными пресетами x265, как по времени кодирования, так и по качеству картинки.
А вот rav1e вместе с svt-av1 не нужны, да.
Не стоит ориентироваться на vmaf, он даёт больше баллов мыльной картинке. Aom точно будет хуже и медленнее x265, а вот svt-av1 лучше
Напиши характеристики компьютера
Да ничем. JPEG это кодек сжатия с потерями. JPEG Interchange File Format это формат файла для храниния данных закодированных кодеком JPEG. .jpg это расширение файла ещё с досовских времен, когда древняя файловая система FAT не могла хранить больше трёх символов в расширении.
Joint pictures expert group
Ты читать не умеешь? Или отсебятину пишешь?
Или ты один из тех кто жмёт в джипеги все пикчи без разбору?
Знатоки, есть вопрос.
Возможно ли каким-либо образом распараллелить кодирование webm vp9? Быть может кто-то просто знает возможно ли это в целом, пусть даже технической реализации нет Меня достало, что, когда я хочу получить высшее качество с наименьшим размером, я должен сидеть и смотреть час как у меня одно ядро в сотку долбится.
Лучшее сжатие и распараллеливание это в принципе противоположности. Выбери 1 стул.
Можно разрезать его на куски, с помощью хохляцкой перемоги av1an. Будут нагружены все ядра. Кстати не ставь quality best
А вообще кодируй в svt-av1, выйдет быстрее и качественнее, и так же поддерживается в браузерах.
> 100 мб за 1 минуту
Нифига ты офигел. 100 ему много за минуту. Перекодируй потом если тебе прям малый размер нужен после записи. Я вообще настроил прямо в притык и то чуть мыльно за 20 минут примерно 1 гиг.
Была прога какая-то, тоже на куски режет, только через жопу работать стала почему-то.
https://github.com/Alkl58/NotEnoughAV1Encodes
> Aom точно будет хуже и медленнее x265, а вот svt-av1 лучше
Базаришь? Вот тебе 4 картинки, скажи где тут aom, а где svt?
Потому что 320 это максимальный битрейт для MP3.
Но ведь одинаково говно на картинках, можно кодек покачественнее посмотреть?
Дауны потому что, дефолтом разработки и развития все последние версии в lame давным давно стал vbr v0, на cbr хуй клали еще с нулевых и правильно. vbr - Стандарт сука!
Bandcamp кстати именно его и предлагает дефолтом, всегда! но для уточек держит и cbr, бгг.
С помощью mp3packer можно уменьшить размер таких файлов без потерь
По одной какой-то абстрактной картинке ничего нельзя сказать. Кодеки предназначены для сжатия видео снятых в реальной жизни
разве mp3 не уже с потерями?
ворбис же
Да, но режим cbr занимает лишнее место, даже если звук на самом деле может весить меньше
Кому нужен VBR MP3, когда есть AAC и Opus?
Я и говорю, не нужен >>3178013
Но ты скажи это всем басс бустед гречневым и прочим нормисам, попробуй, лол. Потому и mp3 не умрет никогда.
Опус нахуй послан с девайсами от заряда зависимыми.
Не нравиться Opus, юзай AAC, или Vorbis если поддержка есть. Просто маяться с конвертацией в AAC под Linux мне не очень хочется. А с учётом того что Opus жмёт даже лучше обеих кодеков, ну в общем совсем не хочется.
Есть ли тут человек, который готов помочь разобраться в некоторых вещах?
> Есть ли документация на русском? Понимаю, что это маразм, но нужно разобраться в некоторых вещах
От той, что есть понятнее не станет.
> Есть ли тут человек, который готов помочь разобраться в некоторых вещах
Ты с сажей в тред пришёл. Почему просто не написать интересующий вопрос?
>Есть ли документация на русском? Понимаю, что это маразм, но нужно разобраться в некоторых вещах
Переводчик для кого придумали?
Сажу выключить забыл.
В общем есть 3 видео. Нужно объединить в один файл, но аудио должно быть в разных потоках.
ffmpeg -i 1.mp4 -i 2.mp4 -i 3.mp4 ^
-filter_complex "[0:v][0:a][1:v][1:a][2:v][2:a]concat=n=3:v=1:a=3[outv][outa]" ^
-map "[outv]" -map "[outa]" result.mp4
Как мне распределить аудио по потокам или раз я указал a=3, то он сам распределить последовательно?
Давай по буквам, я такого не делал и не понимаю концепции, что с видео? У тебя 3 видео, ты их хочешь склеить в 1? Но чтобы к первой части полученного объединённого видео звук был на одной дорожке, ко второй части на второй и к третьей на 3?
Объедини виде отдельно, сделай 3 дорожки длинной с полученное видео, добавив пустоту в нужных местах, залей дорожки с помощью map, то что ты сейчас рожаешь выглядит не здорово.
Я не очень понимаю как это сделать
Ну видео так, если разрешение идентичное
ffmpeg -i 1.mp4 -i 2.mp4 -i 3.mp4 -filter_complex "[0:v][1:v][2:v]concat=n=3:v=1[out]" -map "[out]" -y 4.mp4
Со звуком сложнее, adelay работать совсем не хочет, apad тоже мудит, в общем если не лень, то с помощью areverse и apad можно вот так вредительствовать
1.
ffmpeg -i скленное видео -i источник аудио 1 -af "apad" -shortest -vn дорожка 1
3.
ffmpeg -i источник аудио 3 -af "areverse" -vn дорожка 3
ffmpeg -i скленное видео -i дорожка 3 -af "apad" -shortest -vn дорожка 3.1
ffmpeg -i дорожка 3/1 -af "areverse" -vn дорожка 3
2.
ffmpeg -i источник аудио 2 -af "areverse" -vn дорожка 2
ffmpeg -i скленное видео -i дорожка 2 -af "apad=pad_len=количество фреймов, когда начинается звуе" -shortest -vn дорожка 2.1
ffmpeg -i дорожка 2.1 -af "areverse" -vn дорожка 2
ffmpeg -i скленное видео -i дорожка 2 -af "apad" -shortest -vn дорожка 2.1
Склеиваем
ffmpeg -i скленное видео -i дорожка 1 -i дорожка 2.1 -i дорожка 3 -map 0:v -map 1 -map 2 -map 3 -c copy результат.mp4
Кучи промежуточных файлов потому что ffmpeg срёт ошибками, если пытаешься сделать реверс и апад одновременно. Пользуйся.
> количество фреймов, когда начинается звуе
Или там не фреймы, не помню, в общем придётся приловчится, чтобы попасть в нужный тайминг.
> ffmpeg -i скленное видео -i дорожка 2 -af "apad=pad_len=количество фреймов, когда начинается звуе" -shortest
Здесь sortest не нужен из-за явного указания окончания тишины
> ffmpeg -i скленное видео -i дорожка 2 -af "apad=pad_len=количество фреймов, когда начинается звуе" -shortest -vn дорожка 2.1
И вообще комманда похожа на говно, наверняка можно просто нажать apad и установить таймер -t в секундах(тишана от начала+длительность звуковой дорожки), вместо дебильного pad_len
>>3178861
ffmpeg -i скленное видео -i дорожка 2 -af "apad" -t время тишины до начала+длительность звука -vn дорожка 2.1
Для начала узнать как ты это получаешь
>скленное видео
Не пойму вот чего, откуда у тебя склеенное видео, когда 4.mp4 у тебя без звука?
А что не так? От него нужна только общая продолжительность, а звука в нём быть и не должно.
Я все равно пока не до конца это понимаю. Можешь расписать командами, если представить что у меня есть файл video1.mp4, video2 и video3
Так там же и расписано командами, но ок
ffmpeg -i video1.mp4 -i video2.mp4 -i video3.mp4 -filter_complex "[0:v][1:v][2:v]concat=n=3:v=1[out]" -map "[out]" -y video4.mp4
ffmpeg -i video4.mp4 -i video1.mp4 -af "apad" -shortest -vn audio1.mp4
ffmpeg -i video2.mp4 -af "areverse" -vn audio2.mp4
ffmpeg -i video4.mp4 -i audio2.mp4 -af "apad" -t(время тишины+длительность audio2.mp4) -vn audio2.1.mp4
ffmpeg -i audio2.1.mp4 -af "areverse" -vn audio2.mp4
ffmpeg -i video4.mp4 -i audio2.mp4 -af "apad" -shortest -vn audio2.1.mp4
ffmpeg -i video3.mp4 -af "areverse" -vn audio3.mp4
ffmpeg -i video4.mp4 -i audio3.mp4 -af "apad" -shortest -vn audio3.1.mp4
ffmpeg -i audio3.1.mp4 -af "areverse" -vn audio3.mp4
ffmpeg -i video4.mp4 -i audio1.mp4 -i audio2.1.mp4 -i audio3.mp4 -map 0:v -map 1 -map 2 -map 3 -c copy video5.mp4
>>3178956
Решил проверить и сразу ошибка
> -shortest -vn
Вместе не работают, придётся использовать -t время фрагмента
ffmpeg -hide_banner -i video1.mp4 -i video2.mp4 -i video3.mp4 -filter_complex "[0:v][1:v][2:v]concat=n=3:v=1[out]" -map "[out]" -y video4.mp4
ffmpeg -hide_banner -i video1.mp4 -af "apad" -t 2.069 -vn -y audio1.mp4
ffmpeg -hide_banner -i video2.mp4 -af "areverse" -vn -y audio2.mp4
ffmpeg -hide_banner -i audio2.mp4 -af "apad" -t 4.138 -vn -y audio2.1.mp4
ffmpeg -hide_banner -i audio2.1.mp4 -af "areverse" -vn -y audio2.mp4
ffmpeg -hide_banner -i audio2.mp4 -af "apad" -t 6.207 -vn -y audio2.1.mp4
ffmpeg -hide_banner -i video3.mp4 -af "areverse" -vn -y audio3.mp4
ffmpeg -hide_banner -i audio3.mp4 -af "apad" -t 6.207 -y audio3.1.mp4
ffmpeg -hide_banner -i audio3.1.mp4 -af "areverse" -vn -y audio3.mp4
ffmpeg -hide_banner -i video4.mp4 -i audio1.mp4 -i audio2.1.mp4 -i audio3.mp4 -map 0:v -map 1:a -map 2:a -map 3:a -c copy -y video5.mp4
del audio1.mp4
del audio2.mp4
del audio2.1.mp4
del audio3.mp4
del audio3.1.mp4
> ffmpeg -hide_banner -i video1.mp4 -af "apad" -t 6.207 -vn -y audio1.mp4
То есть во время фрагмента я указываю время первого видео, второго и третьего?
ffmpeg -re -stream_loop -1 -i video1.mp4 -i audio1.mp3 -map 0:v -map 1:a -f flv rtmp://b.rtmp.youtube.com/live2/ключ
Когда аудио заканчивается, оно не стартует заново, а просто зависает. В консоли стрим типа идет, ошибок нет, а по факту стрим как-будто завис
Тебе надо чтобы все 3 звуковые дорожки были идентичной длинны с video4.mp4, с 1 и 3 всё ясно, со второй тебе нужно указать время первого фрагмента + время второго, чтобы получить тишину до начала второго фрагмента, а затем к полученному результату ещё добавить тишина с конца второго фрагмента по конец третьего, получив таким образом дорожку, состоящую из тишина + звуковая дорожка видео 2 + тишина до конца видео. Я не знаю как проще объяснить.
>ffmpeg -hide_banner -i video1.mp4 -af "apad" -t 6.207 -vn -y audio1.mp4
Я про вот эти значения -t. Откуда ты их взял?
Длительность video1.mp4+video2.mp4+video3.mp4
Для каких целей тебе вообще такое странное видео понадобилось?
Я про то, что это в целом рандомные цифры для примера. Там я указываю время своего видео?
>Для начала узнать как ты это получаешь
Вот так:
ffmpeg –i C:\Users\2\Hernya.mkv Hernya.mp4
Вероятно ты пытаешься запихнуть в mp4 формат, который туда запихнуть нельзя.
У тебя символ '–' не правильный, надо так '-'
Спасибо, помогло. Но, как оказалось, на одноядерном атлоне перекодировать видосы - гиблое дело. Он уже перегрелся, а перекодировано 2 минуты из 32.
Их просто склеить надо массово
Тут больше вопрос, как мне связать видео_1 с аудио_1. Я не шарю, за написание скриптов
ffmpeg -i video1 -i audio -map 0 -map 1 -c copy result
Да я знаю как склеить, я не понимаю, как мне это сделать массово. Чтобы video_1.mp4 склеить с audio_1.aac, video_2.mp4 с audio_2.aac и т.д.
Пусть просвещаются лучшим и мощнейшим инструментарием. ffmpeg лучший редактор, ffplay лучший плеер. Нодискасс.
SETLOCAL ENABLEDELAYEDEXPANSION
ECHO !DATE! !TIME! - НАЧАЛО
FOR /F "delims=" I IN ('DIR /A:D /B /S /O:N') DO (
SET "FLDR=I"
SET "FLDP=~dpI"
FOR /F "delims=" J IN ('DIR /A-D /B /S /O:S "!FLDR!\"') DO (
SET "TFLN=J"
SET "OFLM=~nJ"
SET "FEXT=%%~xJ"
IF !FEXT:~1! EQU mp4 (
ffmpeg -hide_banner -i "!TFLN!" -i "!FLDR!\audio!OFLM:~5!.aac" -map 0:v -map 1:a -c copy "!FLDR!\!OFLM!_va!FEXT!"
)
)
)
ECHO !DATE! !TIME! - КОНЕЦ
Ну да, на что я надеялся, а [code] на абучане не пашет?[/code]
Ну или как-то так
>>3179296
Но у тебя правда видео должны иметь идентичные названия и аудио к ним тоже, в данном случае ~5 это удаление первых 5 символов в имени файла video1, останется только 1, которая будет использована для склеивания с файлом audio1.aac
Золотая середина ДЛЯ ЧЕГО? Это так не работает. Подбирай под свои цели.
И ведь нигде нет фильмов в высоком разрешении с нормальной картинкой. Везде если выше 1080 - только этот мусор.
Нафига ты в принципе кодируешь без уточнения параметров?
> Windows 7
> Ultra HD моник
Тебе не кажется такое сочетание странным? Ты либо ОС обнови, либо 1080p моник на место верни.
Не так странно, как люди в s до сих пор обращающие внимание на юзерагент. Ты новенький?
Я ньюфаг, что за параметры?
-vcodec
-acodec
-b:v
-b:a
-crf
-preset
-cpu-used
-vf "scale=1280:-2"
-ac
…
и самое главное:
-map
Для ОБЫЧНОГО видео, не для аниме или что там ещё бывает. Мне цифра нужна, 25, 30, 35.
> ffmpeg -hide_banner -i video1.mp4 -af "apad" -t 2.069 -vn -y audio1.mp4
> ffmpeg -hide_banner -i video2.mp4 -af "areverse" -vn -y audio2.mp4
> ffmpeg -hide_banner -i audio2.mp4 -af "apad" -t 4.138 -vn -y audio2.1.mp4
> ffmpeg -hide_banner -i audio2.1.mp4 -af "areverse" -vn -y audio2.mp4
> ffmpeg -hide_banner -i audio2.mp4 -af "apad" -t 6.207 -vn -y audio2.1.mp4
> ffmpeg -hide_banner -i video3.mp4 -af "areverse" -vn -y audio3.mp4
> ffmpeg -hide_banner -i audio3.mp4 -af "apad" -t 6.207 -y audio3.1.mp4
> ffmpeg -hide_banner -i audio3.1.mp4 -af "areverse" -vn -y audio3.mp4
> ffmpeg -hide_banner -i video4.mp4 -i audio1.mp4 -i audio2.1.mp4 -i audio3.mp4 -map 0:v -map 1:a -map 2:a -map 3:a -c copy -y video5.mp4
> del audio1.mp4
> del audio2.mp4
> del audio2.1.mp4
> del audio3.mp4
> del audio3.1.mp4
Вы шизофреники, в курсе?
А в чём проблема 7 и uhd?
Да, да, я
Проблема в том, что на семёрке сидят либо деды-пердеды, не признающие десятку, либо нищеброды на некропекарнях. Притом первое не исключает второго.
А ещё проблема в том, что для гейминга в 2K или даже 4K нужно современное железо, которое нищебродам на некропеках недоступно. Ну и наконец, даже у десяточки с масштабированием интерфейса дела говорят не очень. А про семёрку я вообще молчу.
> Firefox based
> пыльмун не бейсед
Обычного видео не существует, не выдумывай.
RF 18-22 for 480p/576p Standard Definition1
RF 19-23 for 720p High Definition2
RF 20-24 for 1080p Full High Definition3
RF 22-28 for 2160p 4K Ultra High Definition4
Почаны, помогите
Перед аудио стрим луп допиши
>А если очень хочется повыёбываться, то lossy tak или lossy flac
Качество звука будет не ощутимо от lossless? А места сколько займёт? Что по тегам?
Научи меня кодировать в них.
Рациональнее спрашивать почему MP3 всё ещё жив. Vorbis и AAC с поставленной задачей справляются не хуже, а проблема аппаратной совместимости стала куда менее актуальной.
Потому что у меня плеер за 30 рублей.
Нужно через bat-скрипт сыграть частоту 60 гц на протяжении одной секунды с громкостью программно увеличенной на 15 Дб. Какую команду ffplay/ffmpeg использовать?
Я на QBasic такое в школе писал, на пару строк будет, а ffmpeg для этого наверно не очень подходит.
>Я на QBasic такое в школе писал, на пару строк будет
А вот в 2022 супертехнологии так не позволяют. Нельзя такого написать, потому что в звуковых картах больше нет синтераторов. Нужен звук - сначала сгенери wav-ку с ним, а потом её проигрывай. Дико уебищно, да? Прогресс, жри, сука.
>не уметь в веб-архив
https://web.archive.org/web/20220710011113/https://www.ffmpeg.org/
>не мочь поддерживать аптайм серверов
Тьфу на вас, жмупинусники.
>https://www.animmouse.com/p/ffmpeg-binaries/
Что это нонейм? В официальном источнике только две ссылки:
1. https://www.gyan.dev/ffmpeg/builds/
2. https://github.com/BtbN/FFmpeg-Builds/releases
Изначально хотел сынтерполировать 29.97 фпс в 60 через rife, но после непосредственно разжатия видео на кадры и интерполяции синхронизация аудио/видео по пизде пошла, видео раньше примерно на 70 мс. Мб pts где-то проебался, не ебу. Хотел про параметры vsync почитать, а тут вот в архив лезть пришлось.
>после непосредственно разжатия видео на кадры и интерполяции
И еще после сборки всего этого в один файл, конечно же.
Короче оказалось, что ffmpeg криво нарезал видео через input seeking и первые 12 кадров почему-то оказались одинаковыми, извлечение с -vsync 0 их убрало, и видео не на 70 мс, а на 400 мс раньше получилось.
ffmpeg -y -ss 01:11:37 -i e.ts -t 232 -map 0:v -map 0:a -c:v copy -c:a copy cut.mkv
ТАК КАКОГО ЖЕ ХУЯ OUTPUT SEEKING ВЫДАЕТ 7 ОДИНАКОВЫХ КАДРОВ В НАЧАЛЕ? А? А? А?
ffmpeg -y -i e.ts -ss 01:11:37 -t 232 -map 0:v -map 0:a -c:v copy -c:a copy cut.mkv
В пизду, спать пойду.
Тем не менее, в официальном источнике того васяна нет. Тут как с KeePass. Есть васяны, которые одобрены на официальном уровне непосредственно разработчиком/разработчиками оригинала, раз позволили представлять свой проект на сайте. И к слову, BtbN оказался не такой уж и васян, раз на нём держится репозиторий в GitHub с 30к звёздами.
Потому что с -c:copy ffmpeg может резать только по ключевым кадрам. Хочешь, чтобы порезал ровно - перекодируй.
Подскажите во что лучше пережать и в какое разрешение будет адекватно, учитывая околонулевую художественную ценность фото. Мама хочет отвезти бабушке показать, но 25гб это перебор.
Вообще охуел, что камеры в жпг снимают.
Можно сжать в jpeg xl. Качество будет охуенным с маленьким размером.
Оно избыточно в данном случае имхо. Это просто фотографии людей на свадьбе, там не надо 4000х3000.
>>3181531
А телефон изкаробки прожуёт его? Мама поедет в пердь и с телефона бабушке покажет. Сторонние просмотрщики ставить мало смысла - мама, ожидаемо, не очень с техникой, там типичная история с яркостью 200, 9999 вкладов в браузере и пуши со всех посещённых сайтов.
Нет, не избыточное, не надо ничего шакалить блять! А то хочешь приблизить и всё в пикселях
Не прожуёт, надо ставить что-то стороннее.
Ну сколько мне jpeg xl без пережатия сэкономит? 5гб?
Можно любое качество поставить, хоть в гигабайт
ПЕРЕКАТ
ПЕРЕКАТ
ПЕРЕКАТ
ПЕРЕКАТ
https://2ch.hk/s/res/3181555.html
https://2ch.hk/s/res/3181555.html
https://2ch.hk/s/res/3181555.html
https://2ch.hk/s/res/3181555.html
https://2ch.hk/s/res/3181555.html